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

[Dan Winship <danw@xxxxxxxxxx>]

Go away or I will replace you with a very small procmail script[1]

        :0
        * ^From.*Bruce_Kahn
        | (formail -kr; echo "No, you're wrong! Neener neener neener!) | sendmail -t


[1] http://www.thinkgeek.com/tshirts/frustrations/374d/

On Tue, 2003-11-11 at 13:56, Mark Smith wrote:
> Bruce_Kahn@xxxxxxxxxxxxxxxx wrote:
> > 
> > Mark noted on 11/10/2003 08:46:22 PM:
> > > ICAL disallows two identical vevents because the uid distinguishes
> > > them. And ICAL defines if they have the same uid, then they are the
> > same
> > > object in a possible different state or time.
> > 
> > Actually the prohibition is on concurrent repeat instances which are
> > actually identified using both UID and RECURRENCE-ID but in a nutshell
> > this is basically it.
> > 
> > > ICAL does not disallow vevents that would be identical except for
> > the
> > > unique identifier.
> > 
> > Yep.  (See, Mark and I dont always disagree.)
> > 
> > Lets not forget that CAP currently has a prohibition on creating
> > duplicate BOOKED instances (CAP-12-e, p19):
> > 
> >    There MUST NOT BE more than one "BOOKED" state object in a calendar
> >   for the same "UID".
> 
> Which is completely unrelated to the topic of should valarms
> have a unique identifier. Whats your point?
>