Subject: [Ietf-calsify] ABNF vs tables.

From: Doug at Royer.com (Doug Royer)
Date: Tue Nov 8 13:11:33 2005

On the Jabber room, Cyrus said:
 >  1. Format of abnf vs tables. In 2445 pseudo abnf is used to describe
 > which components are allowed etc.
 >
 > In iTIP tables are used to describe the same thing.
 >
 > We should ideally standardise on one format or the other. What do
 > people think?

With all of the variations and options available in iTIP
the ABNF would be almost impossible to specify. A generic
ABNF is in iCal. The details of how and when to use specific
properties and parameters is described in iTIP tables.

Trying to specify all of the iTIP rules in ABNF would create
a huge ABNF syntax table that would be difficult to verify
as accurate.

It what is needed is clarification and reduction of iTIP entries
in things likes COUNTER. Many optional properties are included
with no guidline when they would be included or when they
should be excluded.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

---

From: dhc2 at dcrocker.net (Dave Crocker)
Date: Tue Nov 15 14:52:15 2005

> the ABNF would be almost impossible to specify. ...

Folks,

oh boy.

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?

d/

-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

---

From: tantek at technorati.com (Tantek Çelik)
Date: Tue Nov 15 17:06:54 2005

On Nov 15, 2005, at 2:52 PM, Dave Crocker 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.
>

+1

Well put Dave.

Thanks,

Tantek

--
Tantek ?elik
Chief Technologist, Technorati, Inc.

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Tue Nov 15 19:29:24 2005

Hi Dave,

--On November 15, 2005 2:52:10 PM -0800 Dave Crocker <[email-masked]> 
wrote:

> bother the list about it. especially since this issue has struck me as
> being a chronic issue with the calendaring work.
>

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

---

From: Doug at Royer.com (Doug Royer)
Date: Tue Nov 15 20:31:47 2005

Cyrus Daboo wrote:
> 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.

The syntax tables in iTIP along with the text description describe
procedures as well as content. So even if the 'unordered" ABNF
extension were added that you proposed, I still think it would be very
difficult to document iTIP in ABNF.

So I think that your proposal would fix iCal ABNF, I do not see
how it will it could help iTIP syntax tables. Because the iTIP
syntax tables describe when to include the iCal ABNF optional
elements.

-- 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4532 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20051115/0ac03040/smime.bin