iCalendar Extensions Proposal

[Eric Busboom <eric@xxxxxxxxxxxxxxxxxx>]

Most of the contributors to the recent thread about how ( and if ) to
permit extensions to iCalendar have supported the idea of some formal
extension mechanism. 

Additionally, several people noted that it is not necessary to declare
what extensions a component uses, as with an EXTENSIONS
property. Implementations are required to ignore properties that they
don't understand, and they can scan a component to discover extension
properties. 

I still want to have some way to group extension properties so that an
implementation can report in REQUESTS-STATUS that it has ignored an entire
set of properties. There is a big difference between "I don't support
ATTACH properties" and "I don't support any of the XXX extension
properties." One indicates a feature is unsupported and the other
indicates that an entire set of applications is not supported. 

So, it is probably sufficient to declare in iCalendar that all IANA
registered properties and parameters to be used in iCalendar components
that are not defined in iCalendar must include some prefix. The "EXT-"
prefix seems like a good choice, with a recommendation that it be followed
with another application-specific prefix as per the "X-" properties
recommendation. Thus, "EXT-SKI-"

So, how about the following changes?

eric.

----------------------------------------------------------------------------------------

Addition to 4.1, Content Lines:

     ext-name = "EXT-" [extension-id "-"] 1*(ALPHA / DIGIT / "-")
     ; Reserved for names registered in other RFCs


Change to 4.8.8.1, Non-Standard properties. 

  [ Change use of "extension property" to "experimental property" ]

Additional section, 4.8.8.2, Extension Properties

   Property Name: Any property name with an "EXT-" prefix

   Purpose: This class of property provides a framework for defining
   standard extension  properties.

   Value Type: Defined in property registration

   Property Parameters: Defined in property registration

   Conformance: Defined in property registration

   Description: 

   Extension properties are specified
   by property and/or property parameter names that have the
   prefix text of "EXT-" (the four character sequence: LATIN CAPITAL
   LETTERS E,X,T followed by the HYPEN-MINUS character). It is recommended
   that the prefix be followed by another prefix to identify the
   type of extension. This will facilitate readability of the
   extensions and minimize possible collision of names between different
   application. User agents that support this content type are expected to
   be able to parse the extension properties and property parameters but
   can ignore them.

   Extension properties must be registered with the IANA in an RFC.

   Format Definition: Defined in property registration.

   Example: The following might be an extension for an
   audio-clip form of subject property:


   EXT-ABC-MMSUBJ;EXT-ABC-MMSUBJTYPE=wave:http://load.noise.org/mysubj.wav

Addition to iTIP: 

  Add a REQUEST-STATUS value that indicates that a set of extension
  properties is unsupported and has been ignored