Subject: SKiCal extensibility

From: [email-masked]
Date: Wed, 6 Sep 2000 22:46:38 -0400

Making sure that we learn a good lesson from iCalendar, I noticed that 
some of the new property parameters (and possibly the properties) have 
very very restrictive ABNFs  in that they do not allow for future 
expandability.  This is not good.

For example, section 2.6  Qualification status parameter has:

     qualstatparam = "QUALRULE" "=" *1("REQUIRED" / "NOTREQUIRED" / 
                     "RECOMMENDED" / "NOTRECOMMENDED" / "PROHIBITED" / 
                     "NOTPROHIBITED") 

(Please fold values to separate lines...) While this may appear OK at 
first pass, it precludes any new values that are not expressly put in the 
ABNF.  The lesson from iCalendar would make the ABNF:

     qualstatparam = "QUALRULE" "=" *1("REQUIRED" / "NOTREQUIRED" / 
                     "RECOMMENDED" / "NOTRECOMMENDED" / "PROHIBITED" / 
                     "NOTPROHIBITED" / x-name / iana-token ) 

so that new values (or experimantal ones) can be added w/o breaking some 
stricter interpretations!!

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: "Greg FitzPatrick" <[email-masked]>
Date: Fri, 8 Sep 2000 14:44:32 +0200

Good suggestion

Greg

Bruce:

Making sure that we learn a good lesson from iCalendar, I noticed that some
of the new property parameters (and possibly the properties) have very very
restrictive ABNFs  in that they do not allow for future expandability.  This
is not good.

(Please fold values to separate lines...) While this may appear OK at first
pass, it precludes any new values that are not expressly put in the ABNF.
The lesson from iCalendar would make the ABNF:

Bruce

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 08 Sep 2000 15:48:36 +0200

>stricter interpretations!!

there's actually another way to do this, too....

if the original ABNF is

   param = "FIRST" / "SECOND"

and you want to make it clear that you are extending a definition, you can
do it like this:

   param =/ "THIRD"

which means that param can have all the old values, and THIRD too.
Section 3.3 of RFC 2234.

And of course, when you reuse something in a new context, you can always say:

   paramv2 = param / "THIRD"

But in general, you want to include the iana-token thing unless you really, 
really want it to be a protocol error to specify an unknown value.

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Fri, 8 Sep 2000 17:00:37 +0200

Harold

Are you suggesting that we should have done this consequently when extending
RFC 2445?

Greg

-----Ursprungligt meddelande-----
Från: Harald Alvestrand [mailto:[email-masked]]
Skickat: den 8 september 2000 15:49
Till: Greg FitzPatrick; [email-masked]
Kopia: Ietf
Ämne: Re: SV: SKiCal extensibility

if the original ABNF is

   param =/ "THIRD"

And of course, when you reuse something in a new context, you can always
say: