Subject: RFC-2445: ABNF/prose mismatch on parameters

From: John Stracke <[email-masked]>
Date: Tue, 13 Jul 1999 17:44:07 +0200

Something that came up in the meeting just now, that Pat asked be sent
to the list:

The ABNF in RFC-2445 specifies an ordering for the parameters of a
component: first the mandatory params, then the
"optional-and-can-occur-only-once" params, then the
"optional-and-can-occur-multiple-times" params.  This disagrees with the
prose.  Frank's recollection is that this ordering was accidental, a
side effect of the easiest way to write the ABNF.  The sense of the WG
meeting is that, when we go to Draft Standard, we should probably change
the ABNF to agree with the prose, opening up the spec so that parameters
can be in any order.

Opinions?

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/

---

From: [email-masked]
Date: Wed, 14 Jul 1999 09:25:50 GMT

John, thank you for posting this item to the list

---

From: [email-masked]
Date: Fri, 16 Jul 1999 20:48:24 GMT

John:
We should be able to correct the ABNF. Or at least get it much closer than 
merely allowing any combination. Putting the ocurrence rules and order of 
properties in the prose alone is inadequate.
-- Frank

---

From: [email-masked] (Robert Weiler)
Date: Fri, 16 Jul 1999 14:33:04 -0700 (PDT)

> properties in the prose alone is inadequate.

Can somebody post the section number in the draft were the faulty odering 
specification occurs? I just took a quick peek at through the ABNF for VEVENT, 
and I didn't see any explicit ordering of properties, but I could be looking in 
the wrong place.

Thanks,

Robert Weiler
Amplitude Software Corporation
415-659-3520

---

From: [email-masked]
Date: Mon, 19 Jul 1999 11:35:47 -0400

>specification occurs?

From RFC 2445, 4.6.1 Event Component:

     eventc     = "BEGIN" ":" "VEVENT" CRLF
                  eventprop *alarmc
                  "END" ":" "VEVENT" CRLF

     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

                )

John is referring to the 'blocking' used in the ABNF to separate the 
"dtend/duration" and "attach/attendee/..." parts from the 
"class/created/..." part.  I didnt check if this is the exact example he 
had in mind but the reference still applies.

(Have any ABNF gurus steped forward to help out w/this???)

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: [email-masked]
Date: Tue, 20 Jul 1999 16:57:13 GMT

Agree with Bruce's comment that we need to address the fact that the ABNF
is more restrictive (BUT CORRECT!) than the prose.
In SGML there was a "&" occurrence indicator that said that (e.g.,
"(a&b&c)") the content particles in a set can be in any order. If this was
in RFC2234 ABNF, it would make our assignment alot easier. As it is, Bruce
is correct, the obligatory ABNF for "any order" of properties will be nasty
for the more complex calendar component specifications.

Bruce's example of using the "eventc" ABNF is a representative one. I will
give this ABNF some more thought.

-- Frank

---

From: [email-masked]
Date: Thu, 22 Jul 1999 17:33:29 GMT

John:
It was both through the interop testing of iCalendar/iTIP/iMIP and also an
offline comment from one of our QE folks who read the ABNF.

BTW, I sent a note to Chris Newmann, who has previously mentored the WG on
some of the iCalendar ABNF. I asked him if he had any suggestions.

One approach could be to institutionalize in a "special" ABNF occurrence
indicator, such as "&" that indicates any order to a set of elements. For
example, rather than:

     token = *(a, b, c)    ...or...  *(a / b / c)

We might specify:

     token = *(a & b & c)

With an operator that we codify within the iCalendar specification. After
all, notations do evolve.

-- Frank

---

From: [email-masked] (Robert Weiler)
Date: Thu, 22 Jul 1999 11:43:30 -0700 (PDT)

I just skimmed RFC2234 (ABNF), and don't think there is any implied ordering 
in the iCal rules. The relevant section is 3.2 which describes alternatives. 
The slash character '/', does not imply any order.

The confusion may arise from section 3.5 which says a sequence group has 
contents that are STRICTLY ORDERED.  However, the examples in this section  
seem to imply that ordering is on the elements in the group, not the elements 
in a sequence included in the group. In other words,

(a *( b / c ) d)

matches ad, abd, acd, abcd, acbd, etc. which I think is what we want and 
matches the current specification. What appears to have happened is that 
RFC2234 overloads the word Sequence. Replace the phrase 'Sequence Group' with 
'Token Group' (which is how I think it was meant to be read), and the problem 
goes away.

Bob Weiler
Amplitude Software

> From: [email-masked]
> Subject: Re: RFC-2445: ABNF/prose mismatch on parameters
> To: John Stracke <[email-masked]>
> Cc: [email-masked]
> Date: Thu, 22 Jul 1999 17:33:29 GMT
> X-Priority: 3 (Normal)
> X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0a |May 4, 
1999) at 07/22/99 01:33:35 PM
> MIME-Version: 1.0
> List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
> List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>
> 
> 
> John:

---

From: Doug Royer <[email-masked]>
Date: Mon, 26 Jul 1999 08:49:08 -0700 (PDT)

> Date: Thu, 22 Jul 1999 11:43:30 -0700 (PDT)
> From: [email-masked] (Robert Weiler)
> 

RFC2445:

	Must all alarmc's be after {event,todo} prop's?

	Can there be any {event,todo} prop's after a VALARM?
	
---

     attach     = "ATTACH" attparam ":" uri  CRLF

     attach     =/ "ATTACH" attparam ";" "ENCODING" "=" "BASE64"
                   ";" "VALUE" "=" "BINARY" ":" binary

     attparam   = *(

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

                (";" fmttypeparam) /

If ENCODING exists, why MUST it be after 'attparam'?
Why MUST VALUE=BINARY come last?

There are more ...

-Doug
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
Pager:				[email-masked]
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: [email-masked]
Date: Mon, 26 Jul 1999 17:08:05 GMT

Doug (and others):
Current ABNF says:

Would the following combination of ABNF and comments be sufficient to 
address this issue? And then similar specification for other such 
instances in the ABNF?

     eventc     = "BEGIN" ":" "VEVENT" CRLF
                                 1*(eventprop / alarmc) ;Must have at 
least one eventprop
                           "END" ":" "VEVENT" CRLF

-- Frank

---

From: [email-masked]
Date: Mon, 26 Jul 1999 22:22:51 GMT

Folks:
Here is a reply from Chris Newman on the ABNF. THANKS, Chris.

-- Frank

>On Wed, 21 Jul 1999 [email-masked] wrote:
>> 1. Specify the numerous combinatorial alternatives.
>>
>> 3. Define a special operator (i.e., "&" like used in SGML to indicate
any
>> order to the elements of the set) in the iCalendar specification with
the
>> proper semantics. Declare this as an extension to the RFC 2234 ABNF for
use
>> in this document.
>
>I don't think either of these is a good idea.  (1) just makes things
>unnecessarily complex, and we considered (3) seriously when doing ABNF,
>but the interactions of that operator with other operators gets too
>complex.
>
>> 2. Add a comment to the individual ABNF tokens that "properties are
>> unordered, ABNF just can't express this".
>
>This was the approach used in RFC 822, it's certainly preferable to 1 & 3.
>
>The approach I prefer is to address the problem the same way unordered
>headers are addressed.  See section 3.6 of
>          draft-ietf-drums-msg-fmt-07.txt
>for an example.
>
>In particular, the ABNF uses something like:
>
>  *(param1 / param2 / param3)
>
>and a comment (or table as in the msg-fmt draft) states any restrictions
>on the number of occurances for a given parameter.
>
>                    - Chris

---

From: Doug Royer <[email-masked]>
Date: Tue, 27 Jul 1999 11:36:54 -0700 (PDT)

I think that does it.

> Date: Mon, 26 Jul 1999 17:08:05 GMT
> 
> Doug (and others):
>
> Current ABNF says:

-Doug

---

From: [email-masked]
Date: Tue, 27 Jul 1999 21:01:40 GMT

Everyone else agree with this change. If so, can I hear some "electronic 
hums" so we can get a concensus and close this item.
----- Forwarded by Pat R Egen/Egen Consulting/01 on 07/27/99 05:02 PM 
-----

Doug Royer <[email-masked]>
Sent by: [email-masked]
07/27/99 02:36 PM
Please respond to Doug Royer

        To:     [email-masked]
        cc: 
        Subject:        Re: RFC-2445: ABNF/prose mismatch on parameters

I think that does it.

-Doug
Mountain View, CA 94040                          Ham Radio: N6AAW, 
Aviation: PP-ASEL

---

From: Doug Royer <[email-masked]>
Date: Tue, 27 Jul 1999 14:13:08 -0700 (PDT)

hum - yes.

> From: [email-masked]
> Date: Tue, 27 Jul 1999 21:01:40 GMT
> X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0 
|March 30, 1999) at 07/27/99 05:01:42 PM, Serialize complete at 07/27/99 
05:01:42 PM

-Doug