RE: RFC 2445 contradiction [Was: Re: Extensions To iCalendar]

[Frank.Dawson@xxxxxxxxx]

> The broader question is: why do we have this kind of text in
> RFC2445? Shouldn't the association between properties and 
> components be
> left solely to RFC2446?
> 
> Would there be any detriment to removing the ABNF for the 
> components and
> the "Conformance" sections for the Properties? It seems that 
> both of these
> sections are redundant with RFC2446.

Eric:

Good question. But the question ought to be more one of what is the purpose
of iCalendar. Is it just a compendium of calendar properties and parameters?
Or is it the basic definition of an exchange format for calendar
information.

You came to iCalendar recently, but from the beginning it has always been an
exchange format for calendar information. This was also true about
vCalendar, that came before that. 

What iTIP (RFC 2446) gave us was the "verbs" beyond the default "PUBLISH"
implicit in the "nouns" defined by iCalendar (RFC 2445). There could very
well be other "verb" sets beyond iTIP. If we didn't have the basic component
structure that we have defined in the ABNF in iCalendar, we would have a
mess. Every set of "verbs" for scheduling would be based on a potentially
different concept of what an iCalendar object was. This would not be a sound
foundation upon which to build scheduling applications.

Basically, your suggestion would not foster the basic level of
interoperability that we have today with common support for iCalendar. I
strongly disagree with disabling the fundamental structure of iCalendar
which is to define both a setup of basic properties and parameter, but also
a set of calendar components that an iCalendar parser need understand.

-- Frank