[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Focus attempt: Do new properties force a change in VERSION?
David replied on 06/17/2002 10:04:21 PM:
> perhaps incorrect, is that I would have to be able to parse any
> iCalendar content following that format defined in RFC2445 and that
> MUST be able to interpret any of the objects defined within the RFC.
Fairly accurate. You should be
able to parse ANYTHING that conforms to RFC 2445 but you may not be able
to interpret it for some reason (probably architectural in nature but not
For example, Outlook can parse an iTIP
REQUESTs that has RDATEs in it and it wont complain but they drop RDATEs
on the floor and the invitation is not flagged as being repeating. The
reason being that they internal design is more pattern centric and list
centric. Or your application may not have the concept of a Journal
it for whatever reason so you probably wont write any code to actually
process the VJOURNAL that you can easily parse.
> Regardless of what the VERSION description says
today, why do we support
> other IANA registered names if they would need to be added to the
> and the version number incremented?
This is NOT accurate. Its possible
for anyone (ie: SKiCAL) to draft up some new properties to add to the current
standard without needing to revise/increment VERSION. That however
does not preclude reving of VERSION if some properties are added if there
is a sufficient or compelling need to do so.
From the fragments Ive caught so far
I havent seen any such need for doing that just yet but perhaps its there.
So far Doug and I have gone back and forth (while being on the same
side of the fence I suspect) but no clarification from the "Pro revising"
> This is my first update to the mailing list,
so don't hit me too hard.
We stopped flaying former lurkers a
while ago... ;^)
Messaging & Collaboration
IBM Software Group
FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...