Re: Status of the CALSCH working group (Alarms/SEQUENCE)

[email protected]
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...
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.