Subject: RE: iCalendar Extension Process [Was: RE: Extensions To iCalendar ]

From: [email-masked]
Date: Tue, 13 Feb 2001 12:07:06 -0600

> After reading over section 7 again, I think we may need to 
> clarify a few
> issues in relation to adding extensions. 
> 
> Section 7.1 says that:
> 	New methods are registered bu publishing an RFC
> 	
> 	Changes to existing methods are registered by revising an RFC
> 
> However, section 7.2 does not describe where new properties 
> or changes to
> properties are registered. The process ends with submission 
> to the IANA
> via the method reviewer. Maybe I don't understand the IANA, 
> but I am not
> sure what "submitted" means. An RFC? A telephone call? Scrawled on a
> postcard? 
> 
> Should section 7.2 specify if new properties are published in a new or
> revised RFC?

Eric:

Of course, if the RFC is confusing, it should be clarified.

The intent was that an addition of a new METHOD value involved
implementation of a new scheduling workflow. This would definitely cause new
interoperability issues, so a RFC publication to define the new scheduling
semantics were needed.

Addition of a new property or parameter could be skipped in the context of
the existing METHOD RFCs (i.e., iTIP) with minimal interoperability issues
to the base iCalendar semantics. Hence, a simple submittal of the new
property/parameter define after fulfilling the process defined in Section
7.2 for review/comment seemed appropriate and a minimal overhead for
allowing registration of new properties and parameters.

I think that this was the original thinking. I don't see that the logic is
all that faulty.

-- Frank

---

From: John Stracke <[email-masked]>
Date: Tue, 13 Feb 2001 13:52:59 -0500

[email-masked] wrote:

> to the base iCalendar semantics.

I think the problem is that it may be hard to tell which proposals are minimal
and which aren't.  For this reason, it may be best to use the normal RFC
publication process rather than creating a reviewer.

The "method reviewer" process was based on the "access type reviewer" process
used for MIME (RFC-2048, section 3.2).  However, MIME access types are much
more straightforward than iCalendar properties.  The access type used for an
external-body is orthogonal to the content of the body, and indeed to
everything else about the message; it's just an address and scheme (like a
URL).  iCalendar properties, by contrast, can interact in surprising ways;
proposals to add new properties require more stringent review.  Properties are
more closely analogous to MIME headers, which can have pretty much any
semantics--and MIME does not provide a process for defining new arbitrary
headers.

Furthermore, looking more closely at RFC-2048, I see that it *does* require RFC
publication (though only Informational).

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |"The struggle is always worthwhile, if the end  |
[email-masked]|be worthwhile and the means honorable;          |
|                |foreknowledge of defeat is not sufficient reason|
|                |to withdraw from the contest." -- Adron         |
|                |e'Kieron, by Steven Brust                       |
\=================================================================/