[Ietf-calsify] reduced RRULE propsoal

[Doug Royer]

Cyrus Daboo wrote:

> Hi Doug,
>
> --On Monday, September 13, 2004 12:07 PM -0600 Doug Royer 
> <Doug at royer.com> wrote:
>
>> I also would like to restrict an object to zero or one RRULEs.
>>
>> Limit RRULE to one 'BY' rule (as someone else said).
>
>
> Do we do away with BYSETPOS? If so, that prevents a recurrence such as 
> 'the first weekday of the month'. If we keep BYSETPOS then we need to 
> allow it in addition to other BYxxx's in the RRULE.

Good question. I could go ether way.

>
>> We can already have 2 or more objects with the same UID, DTSTAMP,
>> and SEQUENCE that represents more instances of the same series
>> of meetings.  (As done by the ADD method).
>
>
> Here is a general question on the interpretation of the uniqueness of 
> UID/SEQ/RID: what you are suggesting above is that a calstore can have 
> multiple components with the same UID, but with perhaps differing SEQ. 

If they have different SEQ values then they are different revisions of 
the same
series of entries. The largest SEQ value is the newest revision. (see iTIP).

If they have the same UID/SEQ/DTSTAMP then they are all part of ONE entry:
If you have a meeting every Monday at 2pm in LOCATION: ROOM-1. Easy.

Now next week you have to meet in ROOM-2.

So you send TWO new objects. The original with an EXDATE of next week.
And a SECOND object with ONE instance for Monday 2pm of next week
with LOCATION: ROOM-2.  Both objects have the same UID/SEQ/DTSTAMP.

> If so, how are you supposed to do synchronisation (between CUA/CS) 
> with those since its not possible to tell the difference between them 
> other than by perhaps looking at the other properties in each component? 

That is the current model. You tell the difference because they all have the
same UID/SEQ/DTSTAMP values.

>
> My interpretation of ADD in iTIP was that the CUA that receives the 
> ADD adjusts its copy of the original (master) component by adding an 
> appropriate RDATE for the new instance and then adds a RECURRENCE-ID 
> to its copy of the new instance and stores that. That way the 
> UID/SEQ/RID properties remain unique in the client's store and each 
> component/instance can be uniquely addressed and synchronised.

ADD was added because other things can change and there is no  way
to represent the odd entry (one or more)  in one object (LOCATION for 
example). There
is no way to add LOCATION (for example) to the RDATE or EXDATE
so the only way is to represent that instance in a separate object with
the same UID/SEQ/DTSTAMP.

If multiple objects have the same UID;/SEQ/DTSTAMP then they are all
part of one logical entry. If they are 100% the same, then they are just
duplicates of each other.

You can meet every week day at 2pm in room-1.
Then if only Friday changes to room-2, you would modify
the original object to say Monday-Thursday, LOCATION:room-1
and ADD a second object for Friday only, LOCATION:room-2
All with the same UID/SEQ/DTSTAMP.

If the UID is not the same - not the same object.

If UID is the same and SEQ is not the same - the newer SEQ wins and 
older versions
are replaced.

If UID and SEQ are the same and  DTSTAMP is not the same,
then newer DTSTAMP wins and older DTSTAMPS are replaced as iTIP
says they are newer revisions of the same entry (perhaps spelling error 
fixed).

If UID/SEQ/DTSTAMP are the same - then they are all part
of the same logical entry.

The problem is when an appointment evolves over time. There
needed to be a way to represent that this series of entries really
is the same. You only need RDATE/RRULE/EXDATE when only the
date/time changes. When other things change then you have to
specify the series in multiple objects with same UID/SEQ/DTSTAMP.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
Doug at Royer.com                 | Office: (208)520-4044
http://Royer.com/People/Doug   | Fax:    (866)594-8574
                               | Cell:   (208)520-4044

              We Do Standards - You Need Standards


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20040913/9f17d4db/smime.bin