Re: Status of the CALSCH working group (Alarms/SEQUENCE)
| Newsgroups | gmane.ietf.calendar |
|---|---|
| Message-ID | <OF1F0648F8.D436301F-ON85256DDA.00646C14-85256DDA.00666191@notesdev.ibm.com> |
Doug wrote on 11/07/2003 04:14:11 PM:
> > Alarms/SEQUENCE -- I remain confused: Can there be two identical
> > objects in the same calendar? If not, we should clearly say so.
>
> You can and iCAL has no such restriction on any component including
VALARMs.
Sorry, iCalendar does state that multiple repeat instances at the same
date/time are to be considered one:
Where
duplicate instances are generated by the "RRULE" and "RDATE"
properties, only one recurrence is considered. Duplicate instances
are ignored.
at least 4 times. There is also :
4. When the combination of the "RRULE" and "RDATE" properties on an
iCalendar object produces multiple instances having the same
start date/time, they should be collapsed to, and considered as,
a single instance.
in case you missed the other occurances.
You also expliclty restrictions in CAP with:
There MUST NOT BE more than one "BOOKED" state object in a calendar
for the same "UID". The "ADD" method value may create multiple
objects all in the "BOOKED" state for the same UID, however for the
purpose of this memo, they are the same object that simply have
multiple "VCALENDAR" components.
Essentially this says that there can not be any identical VEVENTS with the
same identifier that are BOOKD. Its interesting to note that CAP
disallows it with "MUST NOT" but then goes on to say "may". The first
line was correct, the later text removes the restriction of sorts and is
bad.
I have yet to hear any good justification for allowing "identical but
separate" VALARMs that match any practical view of things. Despite Dougs
and Marks claim, the only reason to have SEQUENCE (or ALARMID) on VALARMs
is for this rare usage case that currently noone actually has nor models
anyones actual behaviour or needs. Id like to apply KISS to this and move
CAP along... (Just like we disallow multiple copies of the same booked
entry, the same should go for alarms).
> Currently all components have a unique identifier within their context
> of usage.
Not totally true. An example of this is VDAYLIGHTs and VSTANDARDs in a
VTIMEZONE. The TZID of the VTIMEZONE is unique but the TZNAME (akin to
its identifier) is not unique. In fact the correct VDAYLIGHT/VSTANDARD is
found by selecting the subcomponent criteria that meet the requestors
needs (ie: when its in effect).
The ONLY case that seems to be demonstratable for SEQUENCE (nay, ALARMID)
is the case where there are multiple, identical VALARMs whose existance is
somewhat questionable, at least for me.
Bruce
===========================================================================
Bruce Kahn INet:
[email protected]
Messaging & Collaboration Phone: 978.399.6496
IBM Software Group FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...