[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
iCalendar Extensions Proposal
Most of the contributors to the recent thread about how ( and if ) to
permit extensions to iCalendar have supported the idea of some formal
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
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?
Addition to 4.1, Content Lines:
ext-name = "EXT-" [extension-id "-"] 1*(ALPHA / DIGIT / "-")
; Reserved for names registered in other RFCs
Change to 126.96.36.199, Non-Standard properties.
[ Change use of "extension property" to "experimental property" ]
Additional section, 188.8.131.52, 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
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:
Addition to iTIP:
Add a REQUEST-STATUS value that indicates that a set of extension
properties is unsupported and has been ignored