[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RFC 2445 Issue: ABNF doesn't currently allow registered extensions
After a pass or two on the SKiCal drafts I revisited the ABNF in the RFCs and I think we need to revise the published iCalendar ABNF so that extensions can be more easily added by efforts like SKiCal. Im sure that Harald can correct my ABNF mistakes but the format we used for our ABNF does not allow for adding just new values. Harald has noted that a proper way to extend an ABNF is to use the form:
param =/ "THIRD"
or
paramv2 = param / "THIRD"
to indicate that an addition is being done. However, the way we wrote up much of our ABNF in RFC 2445, this is not that simple.
For example, if we look at PARTSTAT (Section 4.2.12) you will see the following ABNF:
partstatparam = "PARTSTAT" "="
("NEEDS-ACTION" ; Event needs action
/ "ACCEPTED" ; Event accepted
/ "DECLINED" ; Event declined
/ "TENTATIVE" ; Event tentatively
; accepted
/ "DELEGATED" ; Event delegated
/ x-name ; Experimental status
/ iana-token) ; Other IANA registered
; status
; These are the participation statuses for a "VEVENT". Default is
; NEEDS-ACTION
partstatparam /= "PARTSTAT" "="
("NEEDS-ACTION" ; To-do needs action
/ "ACCEPTED" ; To-do accepted
/ "DECLINED" ; To-do declined
/ "TENTATIVE" ; To-do tentatively
; accepted
/ "DELEGATED" ; To-do delegated
/ "COMPLETED" ; To-do completed.
; COMPLETED property has
;date/time completed.
/ "IN-PROCESS" ; To-do in process of
; being completed
/ x-name ; Experimental status
/ iana-token) ; Other IANA registered
; status
; These are the participation statuses for a "VTODO". Default is
; NEEDS-ACTION
[Snip]
I can follow the intent of this ABNF, to describe 3 possible sets of values for PARTSTAT; one for vEvents, vToDos and VJournals. However, if I reread the ABNF, it appears that we are saying that parstatparam can be written as: "PARSTAT" "=" "ACCEPTED" "PARSTAT" "=" "IN-PROCESS". (Im sure Ill hear otherwise if Im misreading it!). Based on Haralds note on the SKiCal draft and ABNF, I think we really should have written the ABNF as:
partstatparam = "PARTSTAT" "=" partstatparamval
partstatparamval = ("NEEDS-ACTION" ; Event needs action
/ "ACCEPTED" ; Event accepted
/ "DECLINED" ; Event declined
/ "TENTATIVE" ; Event tentatively
; accepted
/ "DELEGATED" ; Event delegated
/ x-name ; Experimental status
/ iana-token) ; Other IANA registered
; status
; These are the participation statuses for a "VEVENT". Default is
; NEEDS-ACTION
partstatparamval /= ("NEEDS-ACTION" ; To-do needs action
/ "ACCEPTED" ; To-do accepted
/ "DECLINED" ; To-do declined
/ "TENTATIVE" ; To-do tentatively
; accepted
/ "DELEGATED" ; To-do delegated
/ "COMPLETED" ; To-do completed.
; COMPLETED property has
;date/time completed.
/ "IN-PROCESS" ; To-do in process of
; being completed
/ x-name ; Experimental status
/ iana-token) ; Other IANA registered
; status
; These are the participation statuses for a "VTODO". Default is
; NEEDS-ACTION
[Snip]
so that anyone can easily add values to PARTSTAT by simply using:
partstatparamvalSKi /= partstatparamval / ("DISCUSSED" .... ; Concept is discussed
or just
partstatparamval /= ("DISCUSSED" .... ; Concept is discussed
So, in a nutshell I think that the ABNF we used in malformed in that it does not allow for easy extensions later on because we used the form "name" "=" "list_of_values" in the ABNF instead of "name" "=" "valuelist" & valuelist = "list_of_values" form. We should correct this when we correct the other ABNF oversight...
Bruce
PS: Someone should double check the proper use of "/=" or "=/" in ABNF and make sure we do it right...
===========================================================================
Bruce Kahn INet: Bruce_Kahn@xxxxxxxx
Iris Associates Phone: 978.392.5335
Westford, MA, USA 01886 FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...