[Ietf-calsify] variations and options

[Cyrus Daboo]

Hi Dave,

--On November 15, 2005 2:52:10 PM -0800 Dave Crocker <dhc2 at dcrocker.net> 
wrote:

> these statements raise such a large red flag with me, i feel compelled to
> bother the list about it. especially since this issue has struck me as
> being a chronic issue with the calendaring work.
>
> the more variations and options an Internet specification has, the higher
> the barrier to implementation and interoperability and, therefore, to use.
>
> why is that not a concern here?

I have to say that I am concerned about all the options and requirements in 
the iTIP document, and I think it would make sense to try and do something 
about that. One solution is to only document what is different from the 
base iCal requirements, rather than repeating those in many cases.

That said I do want to comment on one issue with ABNF and iCalendar. 
Currently 2445 uses what I call a pseudo-ABNF to describe the syntax for 
components. Its an ABNF like syntax that uses interspersed comments to 
define the restrictions, e.g.:

     eventprop  = *(

                ; the following are optional,
                ; but MUST NOT occur more than once

                class / created / description / dtstart / geo /
                last-mod / location / organizer / priority /
                dtstamp / seq / status / summary / transp /
                uid / url / recurid /

                ; either 'dtend' or 'duration' may appear in
                ; a 'eventprop', but 'dtend' and 'duration'
                ; MUST NOT occur in the same 'eventprop'

                dtend / duration /

                ; the following are optional,
                ; and MAY occur more than once

                attach / attendee / categories / comment /
                contact / exdate / exrule / rstatus / related /
                resources / rdate / rrule / x-prop

                )

I would much rather see the restrictions spelled out explicitly in ABNF (I 
guess I've spent too much time with protocols that do use ABNF that way).

The problem is that ABNF is missing a construct that iCalendar needs: 
namely an 'unordered list' construct that would allow the enclosed elements 
to appear in any order within the list, though with the prescribed 
restrictions on the number of times they may appear in the list.

If we assume that curly braces were used to indicate such a construct, then 
the example above would become:

     eventprop  = {

                ; the following are optional,
                ; but MUST NOT occur more than once

                *1class *1created *1description *1dtstart *1geo
                *1last-mod *1location *1organizer *1priority
                *1dtstamp *1seq *1status *1summary *1transp
                *1uid *1url *1recurid

                ; either 'dtend' or 'duration' may appear in
                ; a 'eventprop', but 'dtend' and 'duration'
                ; MUST NOT occur in the same 'eventprop'

                *1(dtend / duration)

                ; the following are optional,
                ; and MAY occur more than once

                *attach *attendee *categories *comment
                *contact *exdate *exrule *rstatus *related
                *resources *rdate *rrule *x-prop

                }

An ABNF syntax checker that understood the new construct would be able to 
verify an  the syntax of an eventprop element without having to understand 
the comments.

Do you think there is any need for such an extension to ABNF?

There are other places where such a construct might be useful. For example, 
RFC2822 Section 3.6 has a table that is very similar to the ones in iTIP. 
With a new construct it ought to be possible to express that in ABNF too.

-- 
Cyrus Daboo