SV: SV: SKiCal extensibility

["Greg FitzPatrick" <greg.fitzpatrick@xxxxxxxxxxxxx>]

Harold

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

Greg

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


At 14:44 08/09/2000 +0200, Greg FitzPatrick wrote:

>(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!!

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, alvestrand@xxxxxxxxx
+47 41 44 29 94
Personal email: Harald@xxxxxxxxxxxxx