Subject: [Ietf-calsify] reduced RRULE propsoal

From: Doug at Royer.com (Doug Royer)
Date: Mon Sep 13 10:37:02 2004

I propose:

(1) We deprecate EXRULE. I have not seen a CUA that allows
the CU to create one. And it can be emulated with EXDATE.

(2) Allow recurrences only for:
      
    Day of month (Every 1st, 2nd, ...)
    Day of week  (Every Sunday, Monday, ...)

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | 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/d6764dd6/smime.bin

---

From: ellmann at wisc.edu (Curt Ellmann)
Date: Mon Sep 13 10:46:41 2004

Would annual recurring events e.g. each year on July 4th be supported?
Also, would biweekly or bimonthly events be allowed?

-curt.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Doug Royer
Sent: Monday, September 13, 2004 11:37 AM
To: [email-masked]
Subject: [Ietf-calsify] reduced RRULE propsoal

I propose:

      

--

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Sep 13 11:07:23 2004

>Also, would biweekly or bimonthly events be allowed?

(1) Annual:

    BYMONTH allows for that.

        DTSTART: 20040101
        RRULE:FREQ=YEARLY;BYMONTH=1

   Or they could be a series of RDATEs.

(2) Weekly or more than once a week.

   The BYDAY rule allow for comma separated values already.

    DTSTART:20040913T120000Z
    RRULE;FREQ=WEEKLY;BYDAY=MO,TH

(3) Monthly or more than once a month:

    MYMONTHDAY supports a comma separated list of dates already.

    DTART:20040913T120000Z
    RRULE:FREQ=MONTHLY;BYMONTHDAY=1,13

I also would like to restrict an object to zero or one RRULEs.

Limit RRULE to one 'BY' rule (as someone else said).

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).

Once we all agree, I can write up the new ABNF and submit it.

-- 

-------------- 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/2c4aeded/smime.bin

---

From: daboo at isamet.com (Cyrus Daboo)
Date: Mon Sep 13 11:49:45 2004

Hi Doug,

> 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.

> 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 
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?

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.

-- 
Cyrus Daboo

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Sep 13 12:26:15 2004

Cyrus Daboo wrote:

> Hi Doug,
>
> --On Monday, September 13, 2004 12:07 PM -0600 Doug Royer 
> <[email-masked]> wrote:
>
> 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.

> 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.

-- 

-------------- 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

---

From: Robert_Ransdell at notesdev.ibm.com ([email-masked])
Date: Mon Sep 13 12:46:42 2004

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/octet-stream
Size: 4696 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20040913/9d0a812d/smime.obj

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Sep 13 12:58:25 2004

[email-masked] wrote:

>Or you just send update using UID/SEQ/DTSTAMP and RID.  The RID is the 
>instance you want to change.
>  
>

I propose we deprecate that method of updates.

Just send the new objects as a replacement set.

Very few implementations support that model of changes. No real 
interoperablity.
Almost everyone sends entire replacement objects.

The 'OR' is part of the problem. More than one way to do the
same thing is causing some of the incompatibility problems.

-- 

-------------- 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/7097fe73/smime-0001.bin

---

From: Robert_Ransdell at notesdev.ibm.com ([email-masked])
Date: Mon Sep 13 13:06:53 2004

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/octet-stream
Size: 4696 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20040913/1d1c5b56/smime.obj