From lear at cisco.com Mon Oct 1 06:20:21 2007 From: lear at cisco.com (Eliot Lear) Date: Mon Oct 1 06:22:04 2007 Subject: [Ietf-calsify] so does Tuesdays at 9:00am America/New_York work for everyone for a jabber session? Message-ID: <4700F415.5060500@cisco.com> The co-chairs need a new time. This would start next week, not this week. This week we'll continue on Thursday. Eliot From bernard.desruisseaux at oracle.com Mon Oct 1 07:01:11 2007 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Mon Oct 1 07:03:14 2007 Subject: [Ietf-calsify] Re: so does Tuesdays at 9:00am America/New_York work for everyone for a jabber session? In-Reply-To: <4700F415.5060500@cisco.com> References: <4700F415.5060500@cisco.com> Message-ID: <4700FDA7.8050305@oracle.com> Works for me. Eliot Lear wrote: > > The co-chairs need a new time. This would start next week, not this > week. This week we'll continue on Thursday. > > Eliot > From cyrus at daboo.name Mon Oct 1 14:15:32 2007 From: cyrus at daboo.name (Cyrus Daboo) Date: Mon Oct 1 14:16:56 2007 Subject: [Ietf-calsify] RDATE, EXDATE value types Message-ID: <5B4EA92784D447CA49FEC21A@caldav.corp.apple.com> Hi, Is the following legal: DTSTART;TZID=America/Tijuana:20050801T090000 EXDATE:20050801T090000 DTEND;TZID=America/Tijuana:20050801T100000 i.e. is it allowed to have an EXDATE (or RDATE for that matter) that is floating when the DTSTART is not floating (or vice versa)? Seems to me that should not be allowed. i.e.: if DTSTART is UTC or local time, then EXDATE/RDATE MUST also be UTC or localtime. if DTSTART is floating time, then EXDATE/RDATE MUST also be floating time. I couldn't find any text that explicitly spelled that out in 2445bis. -- Cyrus Daboo From jeffrey at osafoundation.org Mon Oct 1 14:18:37 2007 From: jeffrey at osafoundation.org (Jeffrey Harris) Date: Mon Oct 1 14:19:39 2007 Subject: [Ietf-calsify] RDATE, EXDATE value types In-Reply-To: <5B4EA92784D447CA49FEC21A@caldav.corp.apple.com> References: <5B4EA92784D447CA49FEC21A@caldav.corp.apple.com> Message-ID: <4701642D.7060209@osafoundation.org> I don't think this is specifically illegal, and I've squashed too many bugs involving mismatched DTSTART/EXDATEs. It'd be really lovely if we could add this as a requirement. Sincerely, Jeffrey From cyrus at daboo.name Mon Oct 1 14:20:15 2007 From: cyrus at daboo.name (Cyrus Daboo) Date: Mon Oct 1 14:21:29 2007 Subject: [Ietf-calsify] iTIP: persisting SEQUENCE number Message-ID: <216EB0EBBEB5AA669E3F6FEE@caldav.corp.apple.com> Hi folks, In trying to come up with some clarifying text for the SEQUENCE property I ran into the following situation: 1) Create a recurring meeting, Monday-Friday for five instances only. 2) Invite an attendee: this will send a REQUEST with SEQUENCE:0. 3) Override the Wednesday meeting by moving forward an hour. This will send a REQUEST for that instance only with SEQUENCE:1. 4) Delete the Thursday instance. This will send a CANCEL for that instance only. Question: what should the SEQUENCE number be for the CANCEL? There are two possibilities depending on how you read things: 1) SEQUENCE:1 - this is one more than SEQUENCE:0 which was the last sequence number used for the instance being cancelled. 2) SEQUENCE:2 - this is one more than the largest SEQUENCE sent in prior messages. The problem with this ambiguity is that two clients could interpret this differently, so that one sends out SEQUENCE:1 as per the first interpretation, but the second is expecting SEQUENCE:2 as per the second interpretation, so it discards the message as being out of date. My feeling is that when the ORGANIZER has to increment the SEQUENCE number they MUST use a value that is higher than the largest SEQUENCE previously sent for the entire recurrence set. Does that make sense? If not, why not? -- Cyrus Daboo From jeffrey at osafoundation.org Mon Oct 1 14:38:36 2007 From: jeffrey at osafoundation.org (Jeffrey Harris) Date: Mon Oct 1 14:39:39 2007 Subject: [Ietf-calsify] Modifications without masters Message-ID: <470168DC.2020105@osafoundation.org> Hi Folks, Is there anything in RFC2445bis that forbids a modification without an associated master in an iCalendar stream? That is, should it be legal to have a stream like: BEGIN:VCALENDAR VERSION:2.0 PRODID:Foo METHOD:PUBLISH BEGIN:VEVENT UID:55EF0E61@foo.com RECURRENCE-ID:20060311T200000 DTSTART:20060311T200000 END:VEVENT END:VCALENDAR without an associated master recurring event? Google Calendar's exported iCalendar frequently has such modifications without masters. Sincerely, Jeffrey From Robert_Ransdell at notesdev.ibm.com Mon Oct 1 14:49:11 2007 From: Robert_Ransdell at notesdev.ibm.com (Robert Ransdell) Date: Mon Oct 1 14:50:21 2007 Subject: [Ietf-calsify] iTIP: persisting SEQUENCE number In-Reply-To: <216EB0EBBEB5AA669E3F6FEE@caldav.corp.apple.com> Message-ID: Skipped content of type multipart/alternative From cyrus at daboo.name Mon Oct 1 14:53:21 2007 From: cyrus at daboo.name (Cyrus Daboo) Date: Mon Oct 1 14:54:40 2007 Subject: [Ietf-calsify] Modifications without masters In-Reply-To: <470168DC.2020105@osafoundation.org> References: <470168DC.2020105@osafoundation.org> Message-ID: Hi Jeffrey, --On October 1, 2007 2:38:36 PM -0700 Jeffrey Harris wrote: > Is there anything in RFC2445bis that forbids a modification without an > associated master in an iCalendar stream? > > That is, should it be legal to have a stream like: > > BEGIN:VCALENDAR > VERSION:2.0 > PRODID:Foo > METHOD:PUBLISH > BEGIN:VEVENT > UID:55EF0E61@foo.com > RECURRENCE-ID:20060311T200000 > DTSTART:20060311T200000 > END:VEVENT > END:VCALENDAR > > without an associated master recurring event? Google Calendar's > exported iCalendar frequently has such modifications without masters. You certainly need to be able to do that for METHOD:REQUEST - i.e. you invite an attendee to one instance of a recurring meeting only. iTIP does say that updates using PUBLISH are allowed, so I think the above is OK. However, was the event you quoted above exactly what they sent? If so why isn't there a DTEND or SUMMARY (I'm assuming that the event is supposed to represent some finite amount of time). What actually changed? The R-ID and DTSTART are the same... -- Cyrus Daboo From jeffrey at osafoundation.org Mon Oct 1 15:01:27 2007 From: jeffrey at osafoundation.org (Jeffrey Harris) Date: Mon Oct 1 15:02:30 2007 Subject: [Ietf-calsify] Modifications without masters In-Reply-To: References: <470168DC.2020105@osafoundation.org> Message-ID: <47016E37.7010700@osafoundation.org> Hi Cyrus, > iTIP does say that updates using PUBLISH are allowed, so I think the > above is OK. However, was the event you quoted above exactly what they > sent? If so why isn't there a DTEND or SUMMARY (I'm assuming that the > event is supposed to represent some finite amount of time). What > actually changed? The R-ID and DTSTART are the same... Sorry, I elided several lines for brevity. When I've gotten events like this from Google, they've typically had a matching DTSTART and RECURRENCE-ID, it's a complete event, but there are no other VEVENT's with a matching UID. I'm guessing in Google's case this is just a bug, not the intention, but I suppose calendar agents should accept events like this and treat them like a normal event until we get a matching master. Sincerely, Jeffrey From caleb at everyone.net Mon Oct 1 18:29:20 2007 From: caleb at everyone.net (Caleb Richardson) Date: Mon Oct 1 18:31:46 2007 Subject: [Ietf-calsify] iTIP: persisting SEQUENCE number Message-ID: <20071001182920.49175DAE@resin08.mta.everyone.net> Your theory seems to be consistent with Frank Dawson's view: http://www.imc.org/ietf-calendar/archive1/msg03546.html > Correct. The sequence number applies to any modifications > for the whole event definition. A change to an initial event > definition to, say add (via the ADD method) an occurrence, > would monotonically increment the sequence number. Effectively, > the sequence number represents the revision sequence for the > whole event definition. > > Note: The UID applies to the whole occurrence set (or whole event) also. Whether or not to bump the sequence number on CANCEL is a separate issue, I believe that it was discussed at great length on either this list or the old ietf-calendar list, with the resolution that it is ultimately the decision of the organizer. Both techniques make sense depending on the circumstances. Caleb Richardson Software Engineer Everyone.net caleb@everyone.net --- cyrus@daboo.name wrote: Hi folks, In trying to come up with some clarifying text for the SEQUENCE property I ran into the following situation: 1) Create a recurring meeting, Monday-Friday for five instances only. 2) Invite an attendee: this will send a REQUEST with SEQUENCE:0. 3) Override the Wednesday meeting by moving forward an hour. This will send a REQUEST for that instance only with SEQUENCE:1. 4) Delete the Thursday instance. This will send a CANCEL for that instance only. Question: what should the SEQUENCE number be for the CANCEL? There are two possibilities depending on how you read things: 1) SEQUENCE:1 - this is one more than SEQUENCE:0 which was the last sequence number used for the instance being cancelled. 2) SEQUENCE:2 - this is one more than the largest SEQUENCE sent in prior messages. The problem with this ambiguity is that two clients could interpret this differently, so that one sends out SEQUENCE:1 as per the first interpretation, but the second is expecting SEQUENCE:2 as per the second interpretation, so it discards the message as being out of date. My feeling is that when the ORGANIZER has to increment the SEQUENCE number they MUST use a value that is higher than the largest SEQUENCE previously sent for the entire recurrence set. Does that make sense? If not, why not? -- Cyrus Daboo _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From cyrus at daboo.name Mon Oct 1 20:41:41 2007 From: cyrus at daboo.name (Cyrus Daboo) Date: Mon Oct 1 20:43:01 2007 Subject: [Ietf-calsify] iTIP: persisting SEQUENCE number In-Reply-To: References: Message-ID: <0329E0768007F0FF51799535@cyrus-daboos-powerbook-g4-15.local> Hi Robert, --On October 1, 2007 5:49:11 PM -0400 Robert Ransdell wrote: > This has been a discussion in the past. OK, I have reviewed the discussion on this. Some comments (taking your comments out of order): > Previous recommendation was to not bump sequence number on CANCEL. I disagree this was the recommendation. In fact 2446 is very explicit in section 2.1.4 that SEQUENCE must be bumped on CANCEL (or ADD). The previous debates subsequent to publication of 2446 reached no consensus on whether this was a bug or not. My take on this is the following: it is vitally import that a cancel be correctly processed if messages are received out of order. Thus bumping the SEQUENCE number on CANCEL makes sense to avoid losing the cancel action if received out of order. I don't believe that relying on DTSTAMP to differentiate out of order messages in this situation is a good idea. > The iTip says you have to bump > by 2. However that leads to a problem. The CANCEL function and the > remove attendee function where combined. The problem arises if you need > to re-invite someone you have removed. If the chair bumped the sequence > number on the chair side to match the sequence sent to the removed > invitee, they would have to send out new invitees to all attendees. Bad > idea. However if the chair only bumps the sequence number on the > iCalendar CANCEL sent to the removed attendee, then they now have a > problem if there was a mistake and they have to re-invite them. I disagree that there is any problem in this. Again, my feeling on this is as follows: iTIP makes it clear that the ORGANIZER'S CUA has to persist on a per-ATTENDEE basis, the SEQUENCE/DTSTAMP values (section 2.1.5). What is important is that the CUA track what the next expected SEQUENCE/DTSTAMP reply for any one attendee is going to be. So, if the organizer sends out SEQUENCE:0 to two attendees A & B, then sends a CANCEL for one instance to B and bumps SEQUENCE to 1, then if A replies to that instance only with SEQUENCE:0 the organizer knows that that is a valid reply even though the SEQUENCE on the instance is 1. The "expected" sequence for the attendee A is still 0. Re-invite is not a problem. Send a REQUEST to B with SEQUENCE:2. Again this does not affect A in anyway as A's state is being persisted. Next: lets say you need to change the time of that instance, so a request goes out with SEQUENCE:3. Now the organizer will be expecting a SEQUENCE:3 reply from both A & B. So I think provided CUAs persist SEQUENCE/DTSTAMP for the next expected reply on a per-attendee basis this all works and does not require excessive message updates to be sent etc. Does that make sense? Did I miss something in my analysis? -- Cyrus Daboo From bernard.desruisseaux at oracle.com Mon Oct 1 20:42:20 2007 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Mon Oct 1 20:44:24 2007 Subject: [Ietf-calsify] RDATE, EXDATE value types In-Reply-To: <5B4EA92784D447CA49FEC21A@caldav.corp.apple.com> References: <5B4EA92784D447CA49FEC21A@caldav.corp.apple.com> Message-ID: <4701BE1C.3060507@oracle.com> Cyrus, I'm not aware of any restriction that would make this illegal. I see two options here: 1- Add restrictions similar to the ones we've added for the UNTIL rule part. Something like: The value of the EXDATE property MUST have the same value type as the "DTSTART" property. Furthermore, if the "DTSTART" property is specified as a date with local time, then the EXDATE property MUST also be specified as a date with local time. Else, if the "DTSTART" property is specified as a date with UTC time or a date with local time and time zone reference, then the EXDATE MUST be specified as either a date with UTC time or a date with local time and time zone reference. 2- Clarify that an EXDATE property specified as a date with local time does not exclude any recurrence instance when DTSTART is specified as a date with UTC time or as a date with local time and time zone reference. And the other way around... An EXDATE property specified as a date with UTC or a date with local time and time zone reference does not exclude any recurrence instance when DTSTART is specified as a date with local time. BTW, we should also consider the case of RECURRENCE-ID. Cheers, Bernard Cyrus Daboo wrote: > Hi, > Is the following legal: > > DTSTART;TZID=America/Tijuana:20050801T090000 > EXDATE:20050801T090000 > DTEND;TZID=America/Tijuana:20050801T100000 > > i.e. is it allowed to have an EXDATE (or RDATE for that matter) that is > floating when the DTSTART is not floating (or vice versa)? Seems to me > that should not be allowed. > > i.e.: > > if DTSTART is UTC or local time, then EXDATE/RDATE MUST also be UTC or > localtime. > if DTSTART is floating time, then EXDATE/RDATE MUST also be floating time. > > I couldn't find any text that explicitly spelled that out in 2445bis. > From Arnaud.Quillaud at Sun.COM Tue Oct 2 07:00:16 2007 From: Arnaud.Quillaud at Sun.COM (Arnaud Quillaud) Date: Tue Oct 2 07:02:07 2007 Subject: [Ietf-calsify] iTIP: persisting SEQUENCE number In-Reply-To: <0329E0768007F0FF51799535@cyrus-daboos-powerbook-g4-15.local> Message-ID: <0JPA004H0EWVZ280@fe-emea-10.sun.com> > -----Message d'origine----- > De : ietf-calsify-bounces@osafoundation.org > [mailto:ietf-calsify-bounces@osafoundation.org] De la part de > Cyrus Daboo > Envoy? : mardi 2 octobre 2007 05:42 > ? : Robert Ransdell > Cc : Calsify; ietf-calsify-bounces@osafoundation.org > Objet : Re: [Ietf-calsify] iTIP: persisting SEQUENCE number > > > Hi Robert, > > --On October 1, 2007 5:49:11 PM -0400 Robert Ransdell > wrote: > > > This has been a discussion in the past. > > OK, I have reviewed the discussion on this. Some comments > (taking your > comments out of order): > > > Previous recommendation was to not bump sequence number on CANCEL. > > I disagree this was the recommendation. In fact 2446 is very > explicit in > section 2.1.4 that SEQUENCE must be bumped on CANCEL (or > ADD). The previous > debates subsequent to publication of 2446 reached no > consensus on whether > this was a bug or not. > > My take on this is the following: it is vitally import that a > cancel be > correctly processed if messages are received out of order. > Thus bumping the > SEQUENCE number on CANCEL makes sense to avoid losing the > cancel action if > received out of order. I don't believe that relying on DTSTAMP to > differentiate out of order messages in this situation is a good idea. > > > The iTip says you have to bump > > by 2. However that leads to a problem. The CANCEL > function and the > > remove attendee function where combined. The problem > arises if you need > > to re-invite someone you have removed. If the chair > bumped the sequence > > number on the chair side to match the sequence sent to the removed > > invitee, they would have to send out new invitees to all attendees. > > Bad idea. However if the chair only bumps the sequence > number on the > > iCalendar CANCEL sent to the removed attendee, then they now have a > > problem if there was a mistake and they have to re-invite them. > > I disagree that there is any problem in this. > > Again, my feeling on this is as follows: iTIP makes it clear that the > ORGANIZER'S CUA has to persist on a per-ATTENDEE basis, the > SEQUENCE/DTSTAMP values (section 2.1.5). What is important is > that the CUA > track what the next expected SEQUENCE/DTSTAMP reply for any > one attendee is > going to be. > In the case of a CalDAV based CUA, how is the client supposed to persist this per ATTENDEE SEQUENCE information on the server (e.g. in the case where the organizer is using 2 cal clients) ? If CalDAV scheduling is used, the CUA may try to guess the right SEQUENCE by looking at the outbox history but that is not guaranteed to work as servers are not required to keep the outbox history. Arnaud Q > So, if the organizer sends out SEQUENCE:0 to two attendees A > & B, then > sends a CANCEL for one instance to B and bumps SEQUENCE to 1, > then if A > replies to that instance only with SEQUENCE:0 the organizer > knows that that > is a valid reply even though the SEQUENCE on the instance is 1. The > "expected" sequence for the attendee A is still 0. > > Re-invite is not a problem. Send a REQUEST to B with > SEQUENCE:2. Again this > does not affect A in anyway as A's state is being persisted. > > Next: lets say you need to change the time of that instance, > so a request > goes out with SEQUENCE:3. Now the organizer will be expecting > a SEQUENCE:3 > reply from both A & B. > > So I think provided CUAs persist SEQUENCE/DTSTAMP for the > next expected > reply on a per-attendee basis this all works and does not > require excessive > message updates to be sent etc. > > Does that make sense? Did I miss something in my analysis? > > -- > Cyrus Daboo > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > From lear at cisco.com Tue Oct 2 07:05:07 2007 From: lear at cisco.com (Eliot Lear) Date: Tue Oct 2 07:06:39 2007 Subject: [Ietf-calsify] RDATE, EXDATE value types In-Reply-To: <4701BE1C.3060507@oracle.com> References: <5B4EA92784D447CA49FEC21A@caldav.corp.apple.com> <4701BE1C.3060507@oracle.com> Message-ID: <47025013.404@cisco.com> Chair hat on. Unless we hear clear consensus that this will improve interoperability, the RFC2445bis is closed except for modifications necessary to accommodate changes to RFC2446bis. Eliot Bernard Desruisseaux wrote: > Cyrus, > > I'm not aware of any restriction that would make this illegal. > > I see two options here: > > 1- Add restrictions similar to the ones we've added for the UNTIL rule > part. Something like: > > The value of the EXDATE property MUST have the same value type as > the "DTSTART" property. Furthermore, if the "DTSTART" property is > specified as a date with local time, then the EXDATE property MUST > also be specified as a date with local time. Else, if the "DTSTART" > property is specified as a date with UTC time or a date with local > time and time zone reference, then the EXDATE MUST be specified as > either a date with UTC time or a date with local time and time zone > reference. > > 2- Clarify that an EXDATE property specified as a date with local time > does not exclude any recurrence instance when DTSTART is specified > as a date with UTC time or as a date with local time and time zone > reference. And the other way around... An EXDATE property specified > as a date with UTC or a date with local time and time zone reference > does not exclude any recurrence instance when DTSTART is specified > as a date with local time. > > BTW, we should also consider the case of RECURRENCE-ID. > > Cheers, > Bernard > > Cyrus Daboo wrote: >> Hi, >> Is the following legal: >> >> DTSTART;TZID=America/Tijuana:20050801T090000 >> EXDATE:20050801T090000 >> DTEND;TZID=America/Tijuana:20050801T100000 >> >> i.e. is it allowed to have an EXDATE (or RDATE for that matter) that >> is floating when the DTSTART is not floating (or vice versa)? Seems >> to me that should not be allowed. >> >> i.e.: >> >> if DTSTART is UTC or local time, then EXDATE/RDATE MUST also be UTC >> or localtime. >> if DTSTART is floating time, then EXDATE/RDATE MUST also be floating >> time. >> >> I couldn't find any text that explicitly spelled that out in 2445bis. >> > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > From bernard.desruisseaux at oracle.com Wed Oct 3 10:24:38 2007 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Wed Oct 3 10:45:36 2007 Subject: [Ietf-calsify] iTIP: persisting SEQUENCE number In-Reply-To: <0JPA004H0EWVZ280@fe-emea-10.sun.com> References: <0JPA004H0EWVZ280@fe-emea-10.sun.com> Message-ID: <4703D056.6020403@oracle.com> Hi Arnaud, Arnaud Quillaud wrote: > > Cyrus Daboo wrote: > >> Again, my feeling on this is as follows: iTIP makes it clear that the >> ORGANIZER'S CUA has to persist on a per-ATTENDEE basis, the >> SEQUENCE/DTSTAMP values (section 2.1.5). What is important is >> that the CUA >> track what the next expected SEQUENCE/DTSTAMP reply for any >> one attendee is >> going to be. >> > > In the case of a CalDAV based CUA, how is the client supposed to persist > this per ATTENDEE SEQUENCE information on the server (e.g. in the case > where the organizer is using 2 cal clients) ? If CalDAV scheduling is > used, the CUA may try to guess the right SEQUENCE by looking at the > outbox history but that is not guaranteed to work as servers are not > required to keep the outbox history. Currently, the CalDAV calendar-schedule draft only defines two new iCalendar parameters RECEIVED-SEQUENCE and RECEIVED-DTSTAMP to "persist" the value of the SEQUENCE and DTSTAMP properties that was specified in the most recent reply received from a given Attendee. Example: ATTENDEE;CN="Cyrus Daboo";PARTSTAT=ACCEPTED;RECEIVED-SEQUENCE=2; RECEIVED-DTSTAMP=20070214T123456Z:mailto:cyrus@example.com The purpose of these parameters is only to allow the handling of scheduling messages that arrive in an unexpected order (i.e., not at all what you are asking for) We are still debating whether there is a need for the Organizer to "persist" on a per Attendee basis the last SEQUENCE number sent to the Attendee. I believe we need to answer the following questions: 1- Is there a use case where the Organizer bumps the SEQUENCE number but doesn't send an update to any Attendee? 2- Is there a use case where the Organizer bumps the SEQUENCE number and only sends an update to some Attendees? [ The case of an Organizer adding new Attendees and only sending an update to those new Attendees would be an example *if* the Organizer (his CUA really) also bump the SEQUENCE number. According to iCalendar (though it should be "according to iTIP") the Organizer is not required to bump the SEQUENCE number here. If the SEQUENCE number is bumped, I would say that all the Attendees should receive an update... ] 3- Is there a use case where the Organizer would consider an Attendee reply that specifies a SEQUENCE number less than the current SEQUENCE number? Cheers, Bernard From lear at cisco.com Thu Oct 4 06:54:09 2007 From: lear at cisco.com (Eliot Lear) Date: Thu Oct 4 06:55:50 2007 Subject: [Ietf-calsify] last thursday jabber starts in 5 minutes Message-ID: <4704F081.8090900@cisco.com> From aki.niemi at nokia.com Wed Oct 17 05:20:14 2007 From: aki.niemi at nokia.com (Aki Niemi) Date: Wed Oct 17 05:31:26 2007 Subject: [Ietf-calsify] Jabber chat today at 9:30 EDT / 15:30 CEST Message-ID: <1192623614.15728.13.camel@scotty> Folks, let's continue the weekly jabber chats today. Last week we had some connectivity problems, but let's hope today things work better. Cheers, Aki From lear at cisco.com Wed Oct 17 06:49:44 2007 From: lear at cisco.com (Eliot Lear) Date: Wed Oct 17 06:51:02 2007 Subject: [Ietf-calsify] RFC 2445bis Issue 63: Consensus needed Message-ID: <471612F8.9020306@cisco.com> Dear all, On August 3rd, Bernard tried for the third time to gain consensus on this topic. Please comment now. We would like to close RFC2445bis and this is one of several niggling points remaining. Please state your preference as to which solution below you prefer. Thank you, Eliot -------------- next part -------------- An embedded message was scrubbed... From: Bernard Desruisseaux Subject: [Ietf-calsify] Issue 63: Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART Date: Fri, 03 Aug 2007 17:22:51 -0400 Size: 6464 Url: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20071017/b34e1abd/AttachedMessage.mht From aki.niemi at nokia.com Tue Oct 23 00:26:48 2007 From: aki.niemi at nokia.com (Aki Niemi) Date: Tue Oct 23 00:28:36 2007 Subject: [Ietf-calsify] Calsify WG jabber chat Message-ID: <1193124408.10121.0.camel@scotty> A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1528 bytes Desc: not available Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20071023/f03437bb/attachment.icz From aki.niemi at nokia.com Wed Oct 24 06:22:32 2007 From: aki.niemi at nokia.com (Aki Niemi) Date: Wed Oct 24 06:24:13 2007 Subject: [Ietf-calsify] Reminder: chat starts in 8 minutes Message-ID: <1193232152.5728.0.camel@scotty> Join at: xmpp:calsify@jabber.ietf.org Cheers, Aki From calsify at oliver-block.eu Wed Oct 24 06:52:04 2007 From: calsify at oliver-block.eu (calsify@oliver-block.eu) Date: Wed Oct 24 06:53:13 2007 Subject: [Ietf-calsify] confusing reference Message-ID: <200710241193233924.7634@block-online.eu> Hello everybody, I was just reading parts of draft-ietf-calsify-rfc2445bis-07.txt and would like to draw your attention to the following confusing sentence: The identifier is RECOMMENDED to be the identical syntax to the [RFC2822] addr-spec. The rest does describe the intended quite good (with just a little change (\"an\" instead of \"the\") so that the preceding sentence could be omitted. A good method to assure uniqueness is to put the domain name or a domain literal IP address of the host on which the identifier was created on the right hand side of [an] \"@\", and on the left hand side, put a combination of the current calendar date and time of day (i.e., formatted in as a DATE-TIME value) along with some other currently unique (perhaps sequential) identifier available on the system (for example, a process id number). Using a date/time value on the left hand side and a domain name or domain literal on the right hand side makes it possible to guarantee uniqueness since no two hosts should be using the same domain name or IP address at the same time. Best Regards, Oliver Block From bernard.desruisseaux at oracle.com Thu Oct 25 08:36:49 2007 From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux) Date: Thu Oct 25 08:39:34 2007 Subject: [Ietf-calsify] confusing reference In-Reply-To: <200710241193233924.7634@block-online.eu> References: <200710241193233924.7634@block-online.eu> Message-ID: <4720B811.8080309@oracle.com> +1 I would be happy to do the proposed change, and drop the normative reference to RFC 2822. Cheers, Bernard calsify@oliver-block.eu wrote: > Hello everybody, > > I was just reading parts of draft-ietf-calsify-rfc2445bis-07.txt and would like to > draw your attention to the following confusing sentence: > > The identifier is RECOMMENDED to be the > identical syntax to the [RFC2822] addr-spec. > > The rest does describe the intended quite good (with just a little change > (\"an\" instead of \"the\") so that the preceding sentence could be omitted. > > A good method to > assure uniqueness is to put the domain name or a domain literal IP > address of the host on which the identifier was created on the > right hand side of [an] \"@\", and on the left hand side, put a > combination of the current calendar date and time of day (i.e., > formatted in as a DATE-TIME value) along with some other currently > unique (perhaps sequential) identifier available on the system > (for example, a process id number). Using a date/time value on > the left hand side and a domain name or domain literal on the > right hand side makes it possible to guarantee uniqueness since no > two hosts should be using the same domain name or IP address at > the same time. > > Best Regards, > > Oliver Block > > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > From aki.niemi at nokia.com Mon Oct 29 04:14:30 2007 From: aki.niemi at nokia.com (Aki Niemi) Date: Mon Oct 29 04:15:55 2007 Subject: [Ietf-calsify] Issue 95: Multiple REQUEST-STATUS with conflicting status codes Message-ID: <1193656470.32436.9.camel@scotty> This is an issue we discussed on last week's jabber chat, filed as issue #95: Currently REQUEST-STATUS can appear more than once in a reply to a scheduling request. The problem is that the each of them can have a status code in a different category (short return code), e.g., it is currently ok to have a reply that indicates both 2.xx (success) and 3.xx (client error) return status codes. This seems like a bug. Proposal: restrict the REQUEST-STATUS return codes in a reply to the same category. Cheers, Aki Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8B70D7FC1F for ; Mon, 29 Oct 2007 04:15:54 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B6544142204 for ; Mon, 29 Oct 2007 04:14:59 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-50 required=4 tests=[AWL=0.900, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+dqk-bKrORz for ; Mon, 29 Oct 2007 04:14:53 -0700 (PDT) Received: from mgw-ext13.nokia.com (smtp.nokia.com [131.228.20.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id CE416142202 for ; Mon, 29 Oct 2007 04:14:52 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9TBEVEt001199 for ; Mon, 29 Oct 2007 13:14:46 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Oct 2007 13:14:39 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Oct 2007 13:14:39 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Oct 2007 13:14:39 +0200 Received: from [172.21.40.51] (esdhcp04051.research.nokia.com [172.21.40.51]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9TBEbkH002691 for ; Mon, 29 Oct 2007 13:14:38 +0200 From: Aki Niemi To: ietf-calsify@osafoundation.org Content-Type: text/plain Organization: Nokia-TP-MSW/Helsinki Date: Mon, 29 Oct 2007 13:14:30 +0200 Message-Id: <1193656470.32436.9.camel@scotty> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Oct 2007 11:14:39.0208 (UTC) FILETIME=[E583B680:01C81A1C] X-Nokia-AV: Clean Subject: [Ietf-calsify] Issue 95: Multiple REQUEST-STATUS with conflicting status codes X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2007 11:15:54 -0000 This is an issue we discussed on last week's jabber chat, filed as issue #95: Currently REQUEST-STATUS can appear more than once in a reply to a scheduling request. The problem is that the each of them can have a status code in a different category (short return code), e.g., it is currently ok to have a reply that indicates both 2.xx (success) and 3.xx (client error) return status codes. This seems like a bug. Proposal: restrict the REQUEST-STATUS return codes in a reply to the same category. Cheers, Aki Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id ADDAA80A23 for ; Thu, 25 Oct 2007 08:39:32 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D06B014220F for ; Thu, 25 Oct 2007 08:38:37 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-50 required=4 tests=[AWL=0.305, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiWCQm5B96qv for ; Thu, 25 Oct 2007 08:38:31 -0700 (PDT) Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5D91D142211 for ; Thu, 25 Oct 2007 08:38:31 -0700 (PDT) Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l9PFbuN4002070; Thu, 25 Oct 2007 10:37:57 -0500 Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l9P3Hg5W027691; Thu, 25 Oct 2007 09:37:56 -0600 Received: from bdesruis-ca.ca.oracle.com by acsmt350.oracle.com with ESMTP id 3320063271193326610; Thu, 25 Oct 2007 08:36:50 -0700 Message-ID: <4720B811.8080309@oracle.com> Date: Thu, 25 Oct 2007 11:36:49 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: calsify@oliver-block.eu Subject: Re: [Ietf-calsify] confusing reference References: <200710241193233924.7634@block-online.eu> In-Reply-To: <200710241193233924.7634@block-online.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2007 15:39:32 -0000 +1 I would be happy to do the proposed change, and drop the normative reference to RFC 2822. Cheers, Bernard calsify@oliver-block.eu wrote: > Hello everybody, > > I was just reading parts of draft-ietf-calsify-rfc2445bis-07.txt and would like to > draw your attention to the following confusing sentence: > > The identifier is RECOMMENDED to be the > identical syntax to the [RFC2822] addr-spec. > > The rest does describe the intended quite good (with just a little change > (\"an\" instead of \"the\") so that the preceding sentence could be omitted. > > A good method to > assure uniqueness is to put the domain name or a domain literal IP > address of the host on which the identifier was created on the > right hand side of [an] \"@\", and on the left hand side, put a > combination of the current calendar date and time of day (i.e., > formatted in as a DATE-TIME value) along with some other currently > unique (perhaps sequential) identifier available on the system > (for example, a process id number). Using a date/time value on > the left hand side and a domain name or domain literal on the > right hand side makes it possible to guarantee uniqueness since no > two hosts should be using the same domain name or IP address at > the same time. > > Best Regards, > > Oliver Block > > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D122080569 for ; Wed, 24 Oct 2007 06:53:11 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CFAD01421F9 for ; Wed, 24 Oct 2007 06:52:16 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.503 X-Spam-Level: X-Spam-Status: No, score=-1.503 tagged_above=-50 required=4 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, NO_REAL_NAME=0.961] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhDuBAQYaknX for ; Wed, 24 Oct 2007 06:52:10 -0700 (PDT) Received: from h1307246.stratoserver.net (block-online.eu [85.214.68.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 200041421F2 for ; Wed, 24 Oct 2007 06:52:09 -0700 (PDT) Received: (qmail 9496 invoked by uid 30); 24 Oct 2007 15:52:04 +0200 To: ietf-calsify@osafoundation.org Date: Wed, 24 Oct 2007 15:52:04 +0200 From: calsify@oliver-block.eu Message-ID: <200710241193233924.7634@block-online.eu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=UTF-8 Content-Transfer-Encoding: 8BIT Subject: [Ietf-calsify] confusing reference X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2007 13:53:11 -0000 Hello everybody, I was just reading parts of draft-ietf-calsify-rfc2445bis-07.txt and would like to draw your attention to the following confusing sentence: The identifier is RECOMMENDED to be the identical syntax to the [RFC2822] addr-spec. The rest does describe the intended quite good (with just a little change (\"an\" instead of \"the\") so that the preceding sentence could be omitted. A good method to assure uniqueness is to put the domain name or a domain literal IP address of the host on which the identifier was created on the right hand side of [an] \"@\", and on the left hand side, put a combination of the current calendar date and time of day (i.e., formatted in as a DATE-TIME value) along with some other currently unique (perhaps sequential) identifier available on the system (for example, a process id number). Using a date/time value on the left hand side and a domain name or domain literal on the right hand side makes it possible to guarantee uniqueness since no two hosts should be using the same domain name or IP address at the same time. Best Regards, Oliver Block Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 36AC37F9EA for ; Wed, 24 Oct 2007 06:24:11 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 565FD1421FC for ; Wed, 24 Oct 2007 06:23:16 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.691 X-Spam-Level: X-Spam-Status: No, score=-1.691 tagged_above=-50 required=4 tests=[AWL=0.908, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmaoVzul4xbi for ; Wed, 24 Oct 2007 06:23:13 -0700 (PDT) Received: from mgw-ext14.nokia.com (smtp.nokia.com [131.228.20.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 8E8A31421F9 for ; Wed, 24 Oct 2007 06:23:08 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9ODN4r9008102 for ; Wed, 24 Oct 2007 16:23:04 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 16:23:00 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 16:22:59 +0300 Received: from [10.162.253.8] (essapo-nirac2538.europe.nokia.com [10.162.253.8]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9ODMe1W021023 for ; Wed, 24 Oct 2007 16:22:54 +0300 From: Aki Niemi To: ietf-calsify@osafoundation.org Content-Type: text/plain Organization: Nokia-TP-MSW/Helsinki Date: Wed, 24 Oct 2007 16:22:32 +0300 Message-Id: <1193232152.5728.0.camel@scotty> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Oct 2007 13:22:59.0767 (UTC) FILETIME=[FF570470:01C81640] X-Nokia-AV: Clean Subject: [Ietf-calsify] Reminder: chat starts in 8 minutes X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2007 13:24:11 -0000 Join at: xmpp:calsify@jabber.ietf.org Cheers, Aki Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 622CD7FEF9 for ; Tue, 23 Oct 2007 00:28:34 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7F17D1421F9 for ; Tue, 23 Oct 2007 00:27:39 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -0.945 X-Spam-Level: X-Spam-Status: No, score=-0.945 tagged_above=-50 required=4 tests=[AWL=0.165, BAYES_05=-1.11] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DreVUvKKrqs for ; Tue, 23 Oct 2007 00:27:33 -0700 (PDT) Received: from mgw-ext14.nokia.com (smtp.nokia.com [131.228.20.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B3FCF1421F2 for ; Tue, 23 Oct 2007 00:27:32 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9N7R4qR007730; Tue, 23 Oct 2007 10:27:26 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 10:27:09 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 10:27:03 +0300 Received: from [172.21.41.73] (esdhcp04173.research.nokia.com [172.21.41.73]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9N7Qr2U016199; Tue, 23 Oct 2007 10:27:02 +0300 From: Aki Niemi To: ietf-calsify@osafoundation.org, Eliot Lear Content-Type: text/calendar; name=calendar.ics; charset=utf-8; METHOD=REQUEST Organization: Nokia-TP-MSW/Helsinki Date: Tue, 23 Oct 2007 07:26:48 +0000 Message-Id: <1193124408.10121.0.camel@scotty> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Oct 2007 07:27:03.0943 (UTC) FILETIME=[1BDD2170:01C81546] X-Nokia-AV: Clean Subject: [Ietf-calsify] Calsify WG jabber chat X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2007 07:28:34 -0000 BEGIN:VCALENDAR CALSCALE:GREGORIAN PRODID:-//Ximian//NONSGML Evolution Calendar//EN VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:/softwarestudio.org/Tzfile/Europe/Helsinki X-LIC-LOCATION:Europe/Helsinki BEGIN:STANDARD TZNAME:EET DTSTART:19701028T030000 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10 TZOFFSETFROM:+0300 TZOFFSETTO:+0200 END:STANDARD BEGIN:DAYLIGHT TZNAME:EEST DTSTART:19700330T040000 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3 TZOFFSETFROM:+0200 TZOFFSETTO:+0300 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:20071023T072226Z-6691-1000-1-1@scotty DTSTAMP:20071023T072647Z DTSTART;TZID=/softwarestudio.org/Tzfile/Europe/Helsinki:20071024T163000 DTEND;TZID=/softwarestudio.org/Tzfile/Europe/Helsinki:20071024T173000 TRANSP:OPAQUE SEQUENCE:2 SUMMARY:Calsify WG jabber chat LOCATION:xmpp:calsify@jabber.ietf.org DESCRIPTION:Weekly jabber chat for the Calsify WG. Template agenda: going through and closing issues on the WG issue tracker:\n\nhttp: //www.ofcourseimright.com/cgi-bin/roundup/calsify\n CLASS:PUBLIC ORGANIZER;CN=Aki Niemi:MAILTO:aki.niemi@nokia.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=CHAIR;PARTSTAT=ACCEPTED;RSVP=TRUE;CN=Aki Niemi;LANGUAGE=en:MAILTO:aki.niemi@nokia.com ATTENDEE;CUTYPE=GROUP;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION; RSVP=TRUE;LANGUAGE=en:MAILTO:ietf-calsify@osafoundation.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=CHAIR;PARTSTAT=NEEDS-ACTION;RSVP=TRUE; CN=Eliot Lear;LANGUAGE=en:MAILTO:lear@cisco.com RRULE:FREQ=WEEKLY;COUNT=1;INTERVAL=1;BYDAY=WE END:VEVENT END:VCALENDAR Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id C4CC780569 for ; Wed, 17 Oct 2007 06:51:00 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DEBF2142204 for ; Wed, 17 Oct 2007 06:50:05 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-50 required=4 tests=[AWL=0.541, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9cLZ1hvXVk3 for ; Wed, 17 Oct 2007 06:49:59 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6F43B1421FB for ; Wed, 17 Oct 2007 06:49:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.21,289,1188802800"; d="scan'208";a="24367337" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-1.cisco.com with ESMTP; 17 Oct 2007 06:49:48 -0700 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9HDnlce024077 for ; Wed, 17 Oct 2007 15:49:47 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp4659.cisco.com [10.61.82.50]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9HDnlUh013738 for ; Wed, 17 Oct 2007 13:49:47 GMT Message-ID: <471612F8.9020306@cisco.com> Date: Wed, 17 Oct 2007 15:49:44 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" X-Enigmail-Version: 0.95.3 Content-Type: multipart/mixed; boundary="------------040108070104000708010404" DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7291; t=1192628987; x=1193492987; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20RFC=202445bis=20Issue=2063=3A=20Consensus=20needed |Sender:=20; bh=vhmovQsiJfcUNi9tKESP4koeLrFoBYOueo0fWreVvvk=; b=OWpbTn2prGguMhRe3nv//IpM1M+aM1/EOH3JW/RqKkNHxywyJ12o15FftJcdb/0jAvQLI88f 2/K1kEtoeSIrGmYFWxcMDkky2xfMMzM+DzKFe1JrkPipqE+PtS4kend8; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); Subject: [Ietf-calsify] RFC 2445bis Issue 63: Consensus needed X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 13:51:00 -0000 This is a multi-part message in MIME format. --------------040108070104000708010404 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Dear all, On August 3rd, Bernard tried for the third time to gain consensus on this topic. Please comment now. We would like to close RFC2445bis and this is one of several niggling points remaining. Please state your preference as to which solution below you prefer. Thank you, Eliot --------------040108070104000708010404 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Attached Message" X-Account-Key: account2 X-Mozilla-Keys: Received: from xbh-ams-331.emea.cisco.com ([144.254.231.71]) by xmb-ams-335.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Aug 2007 23:24:15 +0200 Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Aug 2007 23:24:15 +0200 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Aug 2007 14:24:13 -0700 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 03 Aug 2007 14:24:13 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l73LOD3q014345; Fri, 3 Aug 2007 14:24:13 -0700 Received: from sj-inbound-b.cisco.com (sj-inbound-b.cisco.com [128.107.234.205]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l73LO8EB001050; Fri, 3 Aug 2007 21:24:13 GMT Received: from leilani.osafoundation.org ([204.152.186.93]) by sj-inbound-b.cisco.com with ESMTP; 03 Aug 2007 14:24:11 -0700 X-from-outside-Cisco: 204.152.186.93 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAAk6s0bMmLpdh2dsb2JhbACOEQEBCQonZg X-IronPort-AV: i="4.19,218,1183359600"; d="scan'208"; a="21625890:sNHT15635910" Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 7A44A80ACC; Fri, 3 Aug 2007 14:25:01 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id BF55880AC1 for ; Fri, 3 Aug 2007 14:24:59 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E7AD21421F7 for ; Fri, 3 Aug 2007 14:24:04 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-50 required=4 tests=[AWL=0.410, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IC5j1yyXxAQG for ; Fri, 3 Aug 2007 14:24:03 -0700 (PDT) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 3003C142206 for ; Fri, 3 Aug 2007 14:24:03 -0700 (PDT) Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l73LO0eP027928 for ; Fri, 3 Aug 2007 15:24:01 -0600 Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l734Du48030843 for ; Fri, 3 Aug 2007 15:24:00 -0600 Received: from dhcp-montreal-17fl-utilca-10-156-43-50.ca.oracle.com by acsmt350.oracle.com with ESMTP id 3094654721186176186; Fri, 03 Aug 2007 14:23:06 -0700 Message-ID: <46B39CAB.7070303@oracle.com> Date: Fri, 03 Aug 2007 17:22:51 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Calsify WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE Subject: [Ietf-calsify] Issue 63: Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org Authentication-Results: sj-dkim-1; header.From=bernard.desruisseaux@oracle.com; dkim=neutral Return-Path: ietf-calsify-bounces@osafoundation.org X-OriginalArrivalTime: 03 Aug 2007 21:24:13.0333 (UTC) FILETIME=[A3740C50:01C7D614] Disclaimer: This is the third time I bring up this issue. See: http://lists.osafoundation.org/pipermail/ietf-calsify/2006-November/001349.html http://lists.osafoundation.org/pipermail/ietf-calsify/2007-February/001522.html Cyrus recently brought up the fact that the deprecation of RANGE=THISANDFUTURE (Issue 48) might be an issue with unbounded recurring calendar components in the context of iTIP. I have already suggested a solution for the case where an organizer cancels all future recurrence instances of a recurring calendar component. See: http://lists.osafoundation.org/pipermail/ietf-calsify/2007-July/001746.html This time I would like to suggest a solution for the case where an organizer changes all future recurrence instances of a recurring calendar component: 1- Specify RDATE properties for all past recurrence instances and define exception components for them if needed. The number of past recurrence instances is always finite... 2- Remove EXDATE properties for any past recurrence instances. 3- Set DTSTART to the first recurrence instance to which you want the change to apply. The only issue here is that we need to clarify that RDATE can specify a value less than the value specified by DTSTART. Cheers, Bernard _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify --------------040108070104000708010404-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2EB0780569 for ; Wed, 17 Oct 2007 05:31:25 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 48227142202 for ; Wed, 17 Oct 2007 05:30:30 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.681 X-Spam-Level: X-Spam-Status: No, score=-1.681 tagged_above=-50 required=4 tests=[AWL=0.918, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Usq-sdj01s8c for ; Wed, 17 Oct 2007 05:30:24 -0700 (PDT) Received: from mgw-ext13.nokia.com (smtp.nokia.com [131.228.20.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 92DBA142203 for ; Wed, 17 Oct 2007 05:30:23 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9HCTvrD003160 for ; Wed, 17 Oct 2007 15:30:19 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Oct 2007 15:30:01 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Oct 2007 15:20:24 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Oct 2007 15:20:24 +0300 Received: from [172.21.40.72] (esdhcp04072.research.nokia.com [172.21.40.72]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9HCKGCX028120 for ; Wed, 17 Oct 2007 15:20:22 +0300 From: Aki Niemi To: "ietf-calsify@osafoundation.org" Content-Type: text/plain Organization: Nokia-TP-MSW/Helsinki Date: Wed, 17 Oct 2007 15:20:14 +0300 Message-Id: <1192623614.15728.13.camel@scotty> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2007 12:20:24.0510 (UTC) FILETIME=[182405E0:01C810B8] X-Nokia-AV: Clean Subject: [Ietf-calsify] Jabber chat today at 9:30 EDT / 15:30 CEST X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 12:31:25 -0000 Folks, let's continue the weekly jabber chats today. Last week we had some connectivity problems, but let's hope today things work better. Cheers, Aki Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 068AB809D5 for ; Thu, 4 Oct 2007 06:55:50 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2559114221D for ; Thu, 4 Oct 2007 06:54:55 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-50 required=4 tests=[AWL=0.566, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-lpSH7XDONG for ; Thu, 4 Oct 2007 06:54:50 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7D09A14220D for ; Thu, 4 Oct 2007 06:54:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.21,230,1188770400"; d="scan'208";a="154916577" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 04 Oct 2007 15:54:44 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l94DshYP011796 for ; Thu, 4 Oct 2007 15:54:43 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp82.cisco.com [10.61.64.82]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l94DshbR020383 for ; Thu, 4 Oct 2007 13:54:43 GMT Message-ID: <4704F081.8090900@cisco.com> Date: Thu, 04 Oct 2007 15:54:09 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2; t=1191506083; x=1192370083; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20last=20thursday=20jabber=20starts=20in=205=20minutes |Sender:=20; bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=; b=wUrZattPlBdwICGUBjmxampOsKw7Yuft6TBDb7nJczgM7XvwNG2yTYdlqBlSQZCaPmIZvdqY ODNNJpHKg+MyBYhdxzqpaL4UwCZYLEccZirBSW0gXp48oaDZeK9tElK4; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); Subject: [Ietf-calsify] last thursday jabber starts in 5 minutes X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2007 13:55:50 -0000 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6C38380A2C; Wed, 3 Oct 2007 10:45:32 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8B272142217; Wed, 3 Oct 2007 10:44:37 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-50 required=4 tests=[AWL=0.338, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRTxlkAh1JYV; Wed, 3 Oct 2007 10:44:31 -0700 (PDT) Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 045F1142213; Wed, 3 Oct 2007 10:44:30 -0700 (PDT) Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l93HiS8M004561; Wed, 3 Oct 2007 12:44:28 -0500 Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id l93FmWo8006240; Wed, 3 Oct 2007 11:44:27 -0600 Received: from inet-141-146-46-1.oracle.com by acsmt351.oracle.com with ESMTP id 3264528431191432281; Wed, 03 Oct 2007 10:24:41 -0700 Received: from [10.156.42.83] (/10.156.42.83) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Oct 2007 10:24:41 -0700 Message-ID: <4703D056.6020403@oracle.com> Date: Wed, 03 Oct 2007 13:24:38 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Arnaud Quillaud Subject: Re: RE : [Ietf-calsify] iTIP: persisting SEQUENCE number References: <0JPA004H0EWVZ280@fe-emea-10.sun.com> In-Reply-To: <0JPA004H0EWVZ280@fe-emea-10.sun.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE Cc: Calsify , CalDAV DevList X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2007 17:45:32 -0000 Hi Arnaud, Arnaud Quillaud wrote: > > Cyrus Daboo wrote: > >> Again, my feeling on this is as follows: iTIP makes it clear that the >> ORGANIZER'S CUA has to persist on a per-ATTENDEE basis, the >> SEQUENCE/DTSTAMP values (section 2.1.5). What is important is >> that the CUA >> track what the next expected SEQUENCE/DTSTAMP reply for any >> one attendee is >> going to be. >> > > In the case of a CalDAV based CUA, how is the client supposed to persist > this per ATTENDEE SEQUENCE information on the server (e.g. in the case > where the organizer is using 2 cal clients) ? If CalDAV scheduling is > used, the CUA may try to guess the right SEQUENCE by looking at the > outbox history but that is not guaranteed to work as servers are not > required to keep the outbox history. Currently, the CalDAV calendar-schedule draft only defines two new iCalendar parameters RECEIVED-SEQUENCE and RECEIVED-DTSTAMP to "persist" the value of the SEQUENCE and DTSTAMP properties that was specified in the most recent reply received from a given Attendee. Example: ATTENDEE;CN="Cyrus Daboo";PARTSTAT=ACCEPTED;RECEIVED-SEQUENCE=2; RECEIVED-DTSTAMP=20070214T123456Z:mailto:cyrus@example.com The purpose of these parameters is only to allow the handling of scheduling messages that arrive in an unexpected order (i.e., not at all what you are asking for) We are still debating whether there is a need for the Organizer to "persist" on a per Attendee basis the last SEQUENCE number sent to the Attendee. I believe we need to answer the following questions: 1- Is there a use case where the Organizer bumps the SEQUENCE number but doesn't send an update to any Attendee? 2- Is there a use case where the Organizer bumps the SEQUENCE number and only sends an update to some Attendees? [ The case of an Organizer adding new Attendees and only sending an update to those new Attendees would be an example *if* the Organizer (his CUA really) also bump the SEQUENCE number. According to iCalendar (though it should be "according to iTIP") the Organizer is not required to bump the SEQUENCE number here. If the SEQUENCE number is bumped, I would say that all the Attendees should receive an update... ] 3- Is there a use case where the Organizer would consider an Attendee reply that specifies a SEQUENCE number less than the current SEQUENCE number? Cheers, Bernard Return-Path: X-Original-To: Ietf-calsify@osafoundation.org Delivered-To: Ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 33543801B0 for ; Tue, 2 Oct 2007 07:06:39 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 536F114220A for ; Tue, 2 Oct 2007 07:05:44 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-50 required=4 tests=[AWL=0.569, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkXk25JnFXfX for ; Tue, 2 Oct 2007 07:05:37 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 78033142203 for ; Tue, 2 Oct 2007 07:05:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.21,220,1188770400"; d="scan'208";a="154703707" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 02 Oct 2007 16:05:34 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l92E5YU0010028; Tue, 2 Oct 2007 16:05:34 +0200 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp204.cisco.com [10.61.64.204]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l92E5VOj026728; Tue, 2 Oct 2007 14:05:31 GMT Message-ID: <47025013.404@cisco.com> Date: Tue, 02 Oct 2007 16:05:07 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Bernard Desruisseaux Subject: Re: [Ietf-calsify] RDATE, EXDATE value types References: <5B4EA92784D447CA49FEC21A@caldav.corp.apple.com> <4701BE1C.3060507@oracle.com> In-Reply-To: <4701BE1C.3060507@oracle.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2374; t=1191333934; x=1192197934; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Ietf-calsify]=20RDATE,=20EXDATE=20value=20types |Sender:=20; bh=RyA7UzZ4+5afXO0tQlyF2GnphX3NG7jJG+5mS/xgpac=; b=ahSfdhJMkR4YmokroyIbj/fhRi87jzRVXFU1hj8qqX6W4CoWxaqRF1oKqigfmL+HEvRnZ2ZF nvNG14dAV6Uu8ThcVB8ChObqqDNF44zhiU1wWB80aEd5X4PLfLqxQzdd; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); Cc: Calsify X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2007 14:06:39 -0000 Chair hat on. Unless we hear clear consensus that this will improve interoperability, the RFC2445bis is closed except for modifications necessary to accommodate changes to RFC2446bis. Eliot Bernard Desruisseaux wrote: > Cyrus, > > I'm not aware of any restriction that would make this illegal. > > I see two options here: > > 1- Add restrictions similar to the ones we've added for the UNTIL rule > part. Something like: > > The value of the EXDATE property MUST have the same value type as > the "DTSTART" property. Furthermore, if the "DTSTART" property is > specified as a date with local time, then the EXDATE property MUST > also be specified as a date with local time. Else, if the "DTSTART" > property is specified as a date with UTC time or a date with local > time and time zone reference, then the EXDATE MUST be specified as > either a date with UTC time or a date with local time and time zone > reference. > > 2- Clarify that an EXDATE property specified as a date with local time > does not exclude any recurrence instance when DTSTART is specified > as a date with UTC time or as a date with local time and time zone > reference. And the other way around... An EXDATE property specified > as a date with UTC or a date with local time and time zone reference > does not exclude any recurrence instance when DTSTART is specified > as a date with local time. > > BTW, we should also consider the case of RECURRENCE-ID. > > Cheers, > Bernard > > Cyrus Daboo wrote: >> Hi, >> Is the following legal: >> >> DTSTART;TZID=America/Tijuana:20050801T090000 >> EXDATE:20050801T090000 >> DTEND;TZID=America/Tijuana:20050801T100000 >> >> i.e. is it allowed to have an EXDATE (or RDATE for that matter) that >> is floating when the DTSTART is not floating (or vice versa)? Seems >> to me that should not be allowed. >> >> i.e.: >> >> if DTSTART is UTC or local time, then EXDATE/RDATE MUST also be UTC >> or localtime. >> if DTSTART is floating time, then EXDATE/RDATE MUST also be floating >> time. >> >> I couldn't find any text that explicitly spelled that out in 2445bis. >> > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > Return-Path: X-Original-To: Ietf-calsify@osafoundation.org Delivered-To: Ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 591BB7FCD2; Tue, 2 Oct 2007 07:02:06 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 794DE14220D; Tue, 2 Oct 2007 07:01:11 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-50 required=4 tests=[AWL=1.041, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StSmP2nhpcnA; Tue, 2 Oct 2007 07:01:04 -0700 (PDT) Received: from gmp-eb-mail-2.sun.com (gmp-eb-mail-2.sun.com [192.18.6.24]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 0A1D514220A; Tue, 2 Oct 2007 07:01:03 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l92E0n87023538; Tue, 2 Oct 2007 14:01:00 GMT Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JPA00I01AWVCP00@fe-emea-10.sun.com> (original mail from Arnaud.Quillaud@Sun.COM); Tue, 02 Oct 2007 15:00:49 +0100 (BST) Received: from KONE-JHY8LIXZ2A.Sun.COM ([129.150.117.134]) by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JPA004GSEWVZ280@fe-emea-10.sun.com>; Tue, 02 Oct 2007 15:00:32 +0100 (BST) Content-return: prohibited Date: Tue, 02 Oct 2007 16:00:16 +0200 From: Arnaud Quillaud Subject: RE : [Ietf-calsify] iTIP: persisting SEQUENCE number In-reply-to: <0329E0768007F0FF51799535@cyrus-daboos-powerbook-g4-15.local> Sender: Arnaud.Quillaud@Sun.COM To: Cyrus Daboo , Robert Ransdell Message-id: <0JPA004H0EWVZ280@fe-emea-10.sun.com> MIME-version: 1.0 X-Mailer: Sun Outlook Connector 7.2.310.1 Content-type: TEXT/PLAIN; CHARSET=Windows-1252 Content-transfer-encoding: QUOTED-PRINTABLE Cc: Calsify , ietf-calsify-bounces@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2007 14:02:06 -0000 > -----Message d'origine----- > De : ietf-calsify-bounces@osafoundation.org=20 > [mailto:ietf-calsify-bounces@osafoundation.org] De la part de=20 > Cyrus Daboo > Envoy=E9 : mardi 2 octobre 2007 05:42 > =C0 : Robert Ransdell > Cc : Calsify; ietf-calsify-bounces@osafoundation.org > Objet : Re: [Ietf-calsify] iTIP: persisting SEQUENCE number >=20 >=20 > Hi Robert, >=20 > --On October 1, 2007 5:49:11 PM -0400 Robert Ransdell=20 > wrote: >=20 > > This has been a discussion in the past. >=20 > OK, I have reviewed the discussion on this. Some comments=20 > (taking your=20 > comments out of order): >=20 > > Previous recommendation was to not bump sequence number on CANCEL= . >=20 > I disagree this was the recommendation. In fact 2446 is very=20 > explicit in=20 > section 2.1.4 that SEQUENCE must be bumped on CANCEL (or=20 > ADD). The previous=20 > debates subsequent to publication of 2446 reached no=20 > consensus on whether=20 > this was a bug or not. >=20 > My take on this is the following: it is vitally import that a=20 > cancel be=20 > correctly processed if messages are received out of order.=20 > Thus bumping the=20 > SEQUENCE number on CANCEL makes sense to avoid losing the=20 > cancel action if=20 > received out of order. I don't believe that relying on DTSTAMP to= =20 > differentiate out of order messages in this situation is a good ide= a. >=20 > > The iTip says you have to bump > > by 2. However that leads to a problem. The CANCEL=20 > function and the=20 > > remove attendee function where combined. The problem=20 > arises if you need > > to re-invite someone you have removed. If the chair=20 > bumped the sequence > > number on the chair side to match the sequence sent to the remove= d=20 > > invitee, they would have to send out new invitees to all attendee= s.=20 > > Bad idea. However if the chair only bumps the sequence=20 > number on the=20 > > iCalendar CANCEL sent to the removed attendee, then they now have= a=20 > > problem if there was a mistake and they have to re-invite them. >=20 > I disagree that there is any problem in this. >=20 > Again, my feeling on this is as follows: iTIP makes it clear that t= he=20 > ORGANIZER'S CUA has to persist on a per-ATTENDEE basis, the=20 > SEQUENCE/DTSTAMP values (section 2.1.5). What is important is=20 > that the CUA=20 > track what the next expected SEQUENCE/DTSTAMP reply for any=20 > one attendee is=20 > going to be. >=20 In the case of a CalDAV based CUA, how is the client supposed to pers= ist this per ATTENDEE SEQUENCE information on the server (e.g. in the= case where the organizer is using 2 cal clients) ?=20 If CalDAV scheduling is used, the CUA may try to guess the right SEQU= ENCE by looking at the outbox history but that is not guaranteed to w= ork as servers are not required to keep the outbox history. Arnaud Q > So, if the organizer sends out SEQUENCE:0 to two attendees A=20 > & B, then=20 > sends a CANCEL for one instance to B and bumps SEQUENCE to 1,=20 > then if A=20 > replies to that instance only with SEQUENCE:0 the organizer=20 > knows that that=20 > is a valid reply even though the SEQUENCE on the instance is 1. The= =20 > "expected" sequence for the attendee A is still 0. >=20 > Re-invite is not a problem. Send a REQUEST to B with=20 > SEQUENCE:2. Again this=20 > does not affect A in anyway as A's state is being persisted. >=20 > Next: lets say you need to change the time of that instance,=20 > so a request=20 > goes out with SEQUENCE:3. Now the organizer will be expecting=20 > a SEQUENCE:3=20 > reply from both A & B. >=20 > So I think provided CUAs persist SEQUENCE/DTSTAMP for the=20 > next expected=20 > reply on a per-attendee basis this all works and does not=20 > require excessive=20 > message updates to be sent etc. >=20 > Does that make sense? Did I miss something in my analysis? >=20 > --=20 > Cyrus Daboo >=20 > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org=20 > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >=20 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 02BE47F54A for ; Mon, 1 Oct 2007 20:44:23 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 251501421FD for ; Mon, 1 Oct 2007 20:43:28 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-50 required=4 tests=[AWL=0.806, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZk9t9HoxbZE for ; Mon, 1 Oct 2007 20:43:21 -0700 (PDT) Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5E9C31421FB for ; Mon, 1 Oct 2007 20:43:21 -0700 (PDT) Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l923h7jS026956; Mon, 1 Oct 2007 22:43:07 -0500 Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l91COaOj008868; Mon, 1 Oct 2007 21:43:07 -0600 Received: from inet-141-146-46-1.oracle.com by acsmt351.oracle.com with ESMTP id 3260196601191296542; Mon, 01 Oct 2007 20:42:22 -0700 Received: from [141.144.105.118] (/141.144.105.118) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Oct 2007 20:42:22 -0700 Message-ID: <4701BE1C.3060507@oracle.com> Date: Mon, 01 Oct 2007 23:42:20 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-calsify] RDATE, EXDATE value types References: <5B4EA92784D447CA49FEC21A@caldav.corp.apple.com> In-Reply-To: <5B4EA92784D447CA49FEC21A@caldav.corp.apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE Cc: Calsify X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2007 03:44:23 -0000 Cyrus, I'm not aware of any restriction that would make this illegal. I see two options here: 1- Add restrictions similar to the ones we've added for the UNTIL rule part. Something like: The value of the EXDATE property MUST have the same value type as the "DTSTART" property. Furthermore, if the "DTSTART" property is specified as a date with local time, then the EXDATE property MUST also be specified as a date with local time. Else, if the "DTSTART" property is specified as a date with UTC time or a date with local time and time zone reference, then the EXDATE MUST be specified as either a date with UTC time or a date with local time and time zone reference. 2- Clarify that an EXDATE property specified as a date with local time does not exclude any recurrence instance when DTSTART is specified as a date with UTC time or as a date with local time and time zone reference. And the other way around... An EXDATE property specified as a date with UTC or a date with local time and time zone reference does not exclude any recurrence instance when DTSTART is specified as a date with local time. BTW, we should also consider the case of RECURRENCE-ID. Cheers, Bernard Cyrus Daboo wrote: > Hi, > Is the following legal: > > DTSTART;TZID=America/Tijuana:20050801T090000 > EXDATE:20050801T090000 > DTEND;TZID=America/Tijuana:20050801T100000 > > i.e. is it allowed to have an EXDATE (or RDATE for that matter) that is > floating when the DTSTART is not floating (or vice versa)? Seems to me > that should not be allowed. > > i.e.: > > if DTSTART is UTC or local time, then EXDATE/RDATE MUST also be UTC or > localtime. > if DTSTART is floating time, then EXDATE/RDATE MUST also be floating time. > > I couldn't find any text that explicitly spelled that out in 2445bis. > Return-Path: X-Original-To: Ietf-calsify@osafoundation.org Delivered-To: Ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 1A1BB8050B; Mon, 1 Oct 2007 20:42:59 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3BDF81421FB; Mon, 1 Oct 2007 20:42:04 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-50 required=4 tests=[AWL=0.174, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypHdpNBtHtAF; Mon, 1 Oct 2007 20:41:57 -0700 (PDT) Received: from mulberrymail.com (piper.mulberrymail.com [151.201.22.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 708F5142203; Mon, 1 Oct 2007 20:41:57 -0700 (PDT) Received: from [10.0.1.3] (piper.mulberrymail.com [151.201.22.177] (may be forged)) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l923ffKk027390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2007 23:41:42 -0400 Date: Mon, 01 Oct 2007 23:41:41 -0400 From: Cyrus Daboo To: Robert Ransdell Subject: Re: [Ietf-calsify] iTIP: persisting SEQUENCE number Message-ID: <0329E0768007F0FF51799535@cyrus-daboos-powerbook-g4-15.local> In-Reply-To: References: X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Calsify , ietf-calsify-bounces@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2007 03:42:59 -0000 Hi Robert, --On October 1, 2007 5:49:11 PM -0400 Robert Ransdell wrote: > This has been a discussion in the past. OK, I have reviewed the discussion on this. Some comments (taking your comments out of order): > Previous recommendation was to not bump sequence number on CANCEL. I disagree this was the recommendation. In fact 2446 is very explicit in section 2.1.4 that SEQUENCE must be bumped on CANCEL (or ADD). The previous debates subsequent to publication of 2446 reached no consensus on whether this was a bug or not. My take on this is the following: it is vitally import that a cancel be correctly processed if messages are received out of order. Thus bumping the SEQUENCE number on CANCEL makes sense to avoid losing the cancel action if received out of order. I don't believe that relying on DTSTAMP to differentiate out of order messages in this situation is a good idea. > The iTip says you have to bump > by 2. However that leads to a problem. The CANCEL function and the > remove attendee function where combined. The problem arises if you need > to re-invite someone you have removed. If the chair bumped the sequence > number on the chair side to match the sequence sent to the removed > invitee, they would have to send out new invitees to all attendees. Bad > idea. However if the chair only bumps the sequence number on the > iCalendar CANCEL sent to the removed attendee, then they now have a > problem if there was a mistake and they have to re-invite them. I disagree that there is any problem in this. Again, my feeling on this is as follows: iTIP makes it clear that the ORGANIZER'S CUA has to persist on a per-ATTENDEE basis, the SEQUENCE/DTSTAMP values (section 2.1.5). What is important is that the CUA track what the next expected SEQUENCE/DTSTAMP reply for any one attendee is going to be. So, if the organizer sends out SEQUENCE:0 to two attendees A & B, then sends a CANCEL for one instance to B and bumps SEQUENCE to 1, then if A replies to that instance only with SEQUENCE:0 the organizer knows that that is a valid reply even though the SEQUENCE on the instance is 1. The "expected" sequence for the attendee A is still 0. Re-invite is not a problem. Send a REQUEST to B with SEQUENCE:2. Again this does not affect A in anyway as A's state is being persisted. Next: lets say you need to change the time of that instance, so a request goes out with SEQUENCE:3. Now the organizer will be expecting a SEQUENCE:3 reply from both A & B. So I think provided CUAs persist SEQUENCE/DTSTAMP for the next expected reply on a per-attendee basis this all works and does not require excessive message updates to be sent etc. Does that make sense? Did I miss something in my analysis? -- Cyrus Daboo Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 031D17FEF9 for ; Mon, 1 Oct 2007 18:31:45 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 25E3F142212 for ; Mon, 1 Oct 2007 18:30:50 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.074 X-Spam-Level: X-Spam-Status: No, score=-1.074 tagged_above=-50 required=4 tests=[AWL=1.526, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7kCJMhIfrEp for ; Mon, 1 Oct 2007 18:30:40 -0700 (PDT) Received: from omta14.mta.everyone.net (sitemail.everyone.net [216.200.145.35]) by laweleka.osafoundation.org (Postfix) with ESMTP id B026C142217 for ; Mon, 1 Oct 2007 18:30:40 -0700 (PDT) Received: from dm24.mta.everyone.net (bigiplb-dsnat [172.16.0.19]) by omta14.mta.everyone.net (Postfix) with ESMTP id 168DE45202 for ; Mon, 1 Oct 2007 18:29:40 -0700 (PDT) X-Eon-Dm: dm24 Received: by resin08.mta.everyone.net (EON-PICKUP) id resin08.46fc2f3f.8abf; Mon, 1 Oct 2007 18:29:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Message-Id: <20071001182920.49175DAE@resin08.mta.everyone.net> Date: Mon, 1 Oct 2007 18:29:20 -0700 From: "Caleb Richardson" To: Subject: Re: [Ietf-calsify] iTIP: persisting SEQUENCE number X-Eon-Sig: AQH1/7xHAZ7wBRcANwEAAAAB,c0dfb45bf4c5f8534a875e52c7708ac4 X-Originating-Ip: [208.184.100.2] X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: caleb@everyone.net List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2007 01:31:45 -0000 Your theory seems to be consistent with Frank Dawson's view: http://www.imc.org/ietf-calendar/archive1/msg03546.html > Correct. The sequence number applies to any modifications > for the whole event definition. A change to an initial event > definition to, say add (via the ADD method) an occurrence, > would monotonically increment the sequence number. Effectively, > the sequence number represents the revision sequence for the > whole event definition. > > Note: The UID applies to the whole occurrence set (or whole event) also. Whether or not to bump the sequence number on CANCEL is a separate issue, I believe that it was discussed at great length on either this list or the old ietf-calendar list, with the resolution that it is ultimately the decision of the organizer. Both techniques make sense depending on the circumstances. Caleb Richardson Software Engineer Everyone.net caleb@everyone.net --- cyrus@daboo.name wrote: Hi folks, In trying to come up with some clarifying text for the SEQUENCE property I ran into the following situation: 1) Create a recurring meeting, Monday-Friday for five instances only. 2) Invite an attendee: this will send a REQUEST with SEQUENCE:0. 3) Override the Wednesday meeting by moving forward an hour. This will send a REQUEST for that instance only with SEQUENCE:1. 4) Delete the Thursday instance. This will send a CANCEL for that instance only. Question: what should the SEQUENCE number be for the CANCEL? There are two possibilities depending on how you read things: 1) SEQUENCE:1 - this is one more than SEQUENCE:0 which was the last sequence number used for the instance being cancelled. 2) SEQUENCE:2 - this is one more than the largest SEQUENCE sent in prior messages. The problem with this ambiguity is that two clients could interpret this differently, so that one sends out SEQUENCE:1 as per the first interpretation, but the second is expecting SEQUENCE:2 as per the second interpretation, so it discards the message as being out of date. My feeling is that when the ORGANIZER has to increment the SEQUENCE number they MUST use a value that is higher than the largest SEQUENCE previously sent for the entire recurrence set. Does that make sense? If not, why not? -- Cyrus Daboo _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Return-Path: X-Original-To: Ietf-calsify@osafoundation.org Delivered-To: Ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E4EB77FCC8 for ; Mon, 1 Oct 2007 15:02:28 -0700 (PDT) Received: from [192.168.103.105] (adsl-75-5-124-98.dsl.pltn13.sbcglobal.net [75.5.124.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id EC05314220D for ; Mon, 1 Oct 2007 15:01:33 -0700 (PDT) Message-ID: <47016E37.7010700@osafoundation.org> Date: Mon, 01 Oct 2007 15:01:27 -0700 From: Jeffrey Harris User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Calsify Subject: Re: [Ietf-calsify] Modifications without masters References: <470168DC.2020105@osafoundation.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 22:02:29 -0000 Hi Cyrus, > iTIP does say that updates using PUBLISH are allowed, so I think the > above is OK. However, was the event you quoted above exactly what they > sent? If so why isn't there a DTEND or SUMMARY (I'm assuming that the > event is supposed to represent some finite amount of time). What > actually changed? The R-ID and DTSTART are the same... Sorry, I elided several lines for brevity. When I've gotten events like this from Google, they've typically had a matching DTSTART and RECURRENCE-ID, it's a complete event, but there are no other VEVENT's with a matching UID. I'm guessing in Google's case this is just a bug, not the intention, but I suppose calendar agents should accept events like this and treat them like a normal event until we get a matching master. Sincerely, Jeffrey Return-Path: X-Original-To: Ietf-calsify@osafoundation.org Delivered-To: Ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 984627FB47; Mon, 1 Oct 2007 14:54:38 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B924B142224; Mon, 1 Oct 2007 14:53:43 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-50 required=4 tests=[AWL=0.169, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gas20SiDAg+Y; Mon, 1 Oct 2007 14:53:33 -0700 (PDT) Received: from mulberrymail.com (piper.mulberrymail.com [151.201.22.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D3376142210; Mon, 1 Oct 2007 14:53:32 -0700 (PDT) Received: from caldav.corp.apple.com ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l91LrQRP024558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2007 17:53:28 -0400 Date: Mon, 01 Oct 2007 17:53:21 -0400 From: Cyrus Daboo To: Jeffrey Harris , Calsify Subject: Re: [Ietf-calsify] Modifications without masters Message-ID: In-Reply-To: <470168DC.2020105@osafoundation.org> References: <470168DC.2020105@osafoundation.org> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 21:54:38 -0000 Hi Jeffrey, --On October 1, 2007 2:38:36 PM -0700 Jeffrey Harris wrote: > Is there anything in RFC2445bis that forbids a modification without an > associated master in an iCalendar stream? > > That is, should it be legal to have a stream like: > > BEGIN:VCALENDAR > VERSION:2.0 > PRODID:Foo > METHOD:PUBLISH > BEGIN:VEVENT > UID:55EF0E61@foo.com > RECURRENCE-ID:20060311T200000 > DTSTART:20060311T200000 > END:VEVENT > END:VCALENDAR > > without an associated master recurring event? Google Calendar's > exported iCalendar frequently has such modifications without masters. You certainly need to be able to do that for METHOD:REQUEST - i.e. you invite an attendee to one instance of a recurring meeting only. iTIP does say that updates using PUBLISH are allowed, so I think the above is OK. However, was the event you quoted above exactly what they sent? If so why isn't there a DTEND or SUMMARY (I'm assuming that the event is supposed to represent some finite amount of time). What actually changed? The R-ID and DTSTART are the same... -- Cyrus Daboo Return-Path: X-Original-To: Ietf-calsify@osafoundation.org Delivered-To: Ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 74C69807CC; Mon, 1 Oct 2007 14:50:19 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 967CE142212; Mon, 1 Oct 2007 14:49:24 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.05 X-Spam-Level: X-Spam-Status: No, score=-1.05 tagged_above=-50 required=4 tests=[AWL=1.174, BAYES_00=-2.599, HTML_30_40=0.374, HTML_MESSAGE=0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LsESHhve+AC; Mon, 1 Oct 2007 14:49:17 -0700 (PDT) Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by laweleka.osafoundation.org (Postfix) with ESMTP id 995E9142210; Mon, 1 Oct 2007 14:49:17 -0700 (PDT) In-Reply-To: <216EB0EBBEB5AA669E3F6FEE@caldav.corp.apple.com> To: Cyrus Daboo Subject: Re: [Ietf-calsify] iTIP: persisting SEQUENCE number Message-ID: Date: Mon, 1 Oct 2007 17:49:11 -0400 From: "Robert Ransdell" Content-Type: multipart/related; boundary="=_related 0077DC0285257367_=" MIME-Version: 1.0 X-KeepSent: 849531CF:F06E9293-85257367:0076E168; name=$KeepSent; type=4 X-Mailer: Lotus Notes Build V703_08052007NP August 05, 2007 X-Disclaimed: 34939 Cc: Calsify , ietf-calsify-bounces@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 21:50:19 -0000 --=_related 0077DC0285257367_= Content-Type: multipart/alternative; boundary="=_alternative 0077DC0585257367_=" --=_alternative 0077DC0585257367_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable This has been a discussion in the past. The iTip says you have to bump by = 2. However that leads to a problem. The CANCEL function and the remove=20 attendee function where combined. The problem arises if you need to=20 re-invite someone you have removed. If the chair bumped the sequence=20 number on the chair side to match the sequence sent to the removed=20 invitee, they would have to send out new invitees to all attendees. Bad=20 idea. However if the chair only bumps the sequence number on the=20 iCalendar CANCEL sent to the removed attendee, then they now have a=20 problem if there was a mistake and they have to re-invite them. Previous recommendation was to not bump sequence number on CANCEL. [Ietf-calsify] iTIP: persisting SEQUENCE number Cyrus Daboo=20 to: Calsify 10/01/2007 05:26 PM Sent by: ietf-calsify-bounces@osafoundation.org Hi folks, In trying to come up with some clarifying text for the SEQUENCE property I = ran into the following situation: 1) Create a recurring meeting, Monday-Friday for five instances only. 2) Invite an attendee: this will send a REQUEST with SEQUENCE:0. 3) Override the Wednesday meeting by moving forward an hour. This will=20 send=20 a REQUEST for that instance only with SEQUENCE:1. 4) Delete the Thursday instance. This will send a CANCEL for that instance = only. Question: what should the SEQUENCE number be for the CANCEL? There are two possibilities depending on how you read things: 1) SEQUENCE:1 - this is one more than SEQUENCE:0 which was the last=20 sequence number used for the instance being cancelled. 2) SEQUENCE:2 - this is one more than the largest SEQUENCE sent in prior=20 messages. The problem with this ambiguity is that two clients could interpret this=20 differently, so that one sends out SEQUENCE:1 as per the first=20 interpretation, but the second is expecting SEQUENCE:2 as per the second=20 interpretation, so it discards the message as being out of date. My feeling is that when the ORGANIZER has to increment the SEQUENCE number = they MUST use a value that is higher than the largest SEQUENCE previously=20 sent for the entire recurrence set. Does that make sense? If not, why not? --=20 Cyrus Daboo =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify --=_alternative 0077DC0585257367_= Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
This has been a discussion in the pa= st.  The iTip says you have to bump by 2.  However that leads to a problem.  The CANCEL function and the remove attendee function where combined.  The problem arises if you need to re-invite someone you have removed.   If the chair bumped the sequence number on the chair side to match the sequence sent to the removed invitee, they would have to send out new invitees to all attendees. Bad idea.  However if the chair only bumps the sequence number on the iCalendar CANCEL sent to the removed attendee, then they now have a problem if there was a mistake and they have to re-invite them.


Previous recommendation was to not bump sequence number on CANCEL.



<= table width=3D100%>
[Ietf-calsify] iTIP: persisting SEQUENCE number

Cyrus Daboo to:Calsify
10/01/2007 05:26 PM

Sent by:ietf-calsify-bounces@osafoundation.org




<= hr>


Hi folks,
In trying to come up with so= me clarifying text for the SEQUENCE property I
ran into the following situation:

1) Create a recurring meetin= g, Monday-Friday for five instances only.
2) Invite an attendee: this wi= ll send a REQUEST with SEQUENCE:0.
3) Override the Wednesday meeting by = moving forward an hour. This will send
a REQUEST for that instance only with SEQUENCE:1.
4) Delete the= Thursday instance. This will send a CANCEL for that instance
only.

Question: what should the SEQUENCE number be for the CANCE= L?

There are two possibilities depending on how you read things:
=
1) SEQUENCE:1 - this is one more than SEQUENCE:0 which was the last sequence number used for the instance being cancelled.
2) SEQUENCE:2 - = this is one more than the largest SEQUENCE sent in prior
messages.

The problem with this ambiguity is that two clients co= uld interpret this
differently, so that one sends out SEQUENCE:1 as per the first
inte= rpretation, but the second is expecting SEQUENCE:2 as per the second
interpretation, so it discards the message as being out of date.
My feeling is that when the ORGANIZER has to increment the SEQUENCE number
they MUST use a value that is higher than the largest SEQUENCE previous= ly
sent for the entire recurrence set.

Does that make sense? If not= , why not?

--
Cyrus Daboo

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Ietf-calsify mailing list
Ietf-c= alsify@osafoundation.org
http://lists.osafo= undation.org/mailman/listinfo/ietf-calsify


--=_alternative 0077DC0585257367_=-- --=_related 0077DC0285257367_=-- Return-Path: X-Original-To: Ietf-calsify@osafoundation.org Delivered-To: Ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 649FC802B8 for ; Mon, 1 Oct 2007 14:39:38 -0700 (PDT) Received: from [192.168.103.105] (adsl-75-5-124-98.dsl.pltn13.sbcglobal.net [75.5.124.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 33559142210 for ; Mon, 1 Oct 2007 14:38:43 -0700 (PDT) Message-ID: <470168DC.2020105@osafoundation.org> Date: Mon, 01 Oct 2007 14:38:36 -0700 From: Jeffrey Harris User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Calsify Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Ietf-calsify] Modifications without masters X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 21:39:38 -0000 Hi Folks, Is there anything in RFC2445bis that forbids a modification without an associated master in an iCalendar stream? That is, should it be legal to have a stream like: BEGIN:VCALENDAR VERSION:2.0 PRODID:Foo METHOD:PUBLISH BEGIN:VEVENT UID:55EF0E61@foo.com RECURRENCE-ID:20060311T200000 DTSTART:20060311T200000 END:VEVENT END:VCALENDAR without an associated master recurring event? Google Calendar's exported iCalendar frequently has such modifications without masters. Sincerely, Jeffrey Return-Path: X-Original-To: Ietf-calsify@osafoundation.org Delivered-To: Ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 58726806E0 for ; Mon, 1 Oct 2007 14:21:28 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7AFF6142212 for ; Mon, 1 Oct 2007 14:20:33 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-50 required=4 tests=[AWL=0.171, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Cfa2YsMgvV5 for ; Mon, 1 Oct 2007 14:20:27 -0700 (PDT) Received: from mulberrymail.com (piper.mulberrymail.com [151.201.22.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E1DFA14220E for ; Mon, 1 Oct 2007 14:20:26 -0700 (PDT) Received: from caldav.corp.apple.com ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l91LKKGW024156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 1 Oct 2007 17:20:22 -0400 Date: Mon, 01 Oct 2007 17:20:15 -0400 From: Cyrus Daboo To: Calsify Message-ID: <216EB0EBBEB5AA669E3F6FEE@caldav.corp.apple.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [Ietf-calsify] iTIP: persisting SEQUENCE number X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 21:21:28 -0000 Hi folks, In trying to come up with some clarifying text for the SEQUENCE property I ran into the following situation: 1) Create a recurring meeting, Monday-Friday for five instances only. 2) Invite an attendee: this will send a REQUEST with SEQUENCE:0. 3) Override the Wednesday meeting by moving forward an hour. This will send a REQUEST for that instance only with SEQUENCE:1. 4) Delete the Thursday instance. This will send a CANCEL for that instance only. Question: what should the SEQUENCE number be for the CANCEL? There are two possibilities depending on how you read things: 1) SEQUENCE:1 - this is one more than SEQUENCE:0 which was the last sequence number used for the instance being cancelled. 2) SEQUENCE:2 - this is one more than the largest SEQUENCE sent in prior messages. The problem with this ambiguity is that two clients could interpret this differently, so that one sends out SEQUENCE:1 as per the first interpretation, but the second is expecting SEQUENCE:2 as per the second interpretation, so it discards the message as being out of date. My feeling is that when the ORGANIZER has to increment the SEQUENCE number they MUST use a value that is higher than the largest SEQUENCE previously sent for the entire recurrence set. Does that make sense? If not, why not? -- Cyrus Daboo Return-Path: X-Original-To: Ietf-calsify@osafoundation.org Delivered-To: Ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8766A803E0 for ; Mon, 1 Oct 2007 14:19:38 -0700 (PDT) Received: from [192.168.103.105] (adsl-75-5-124-98.dsl.pltn13.sbcglobal.net [75.5.124.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 6E2CF14220E for ; Mon, 1 Oct 2007 14:18:43 -0700 (PDT) Message-ID: <4701642D.7060209@osafoundation.org> Date: Mon, 01 Oct 2007 14:18:37 -0700 From: Jeffrey Harris User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Calsify Subject: Re: [Ietf-calsify] RDATE, EXDATE value types References: <5B4EA92784D447CA49FEC21A@caldav.corp.apple.com> In-Reply-To: <5B4EA92784D447CA49FEC21A@caldav.corp.apple.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 21:19:38 -0000 I don't think this is specifically illegal, and I've squashed too many bugs involving mismatched DTSTART/EXDATEs. It'd be really lovely if we could add this as a requirement. Sincerely, Jeffrey Return-Path: X-Original-To: Ietf-calsify@osafoundation.org Delivered-To: Ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 0713B803E0 for ; Mon, 1 Oct 2007 14:16:55 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 297A6142212 for ; Mon, 1 Oct 2007 14:16:00 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-50 required=4 tests=[AWL=0.173, BAYES_00=-2.599, UPPERCASE_25_50=0] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtN9BXiplnvD for ; Mon, 1 Oct 2007 14:15:53 -0700 (PDT) Received: from mulberrymail.com (piper.mulberrymail.com [151.201.22.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 3404914220E for ; Mon, 1 Oct 2007 14:15:51 -0700 (PDT) Received: from caldav.corp.apple.com ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l91LFbaQ024072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 1 Oct 2007 17:15:46 -0400 Date: Mon, 01 Oct 2007 17:15:32 -0400 From: Cyrus Daboo To: Calsify Message-ID: <5B4EA92784D447CA49FEC21A@caldav.corp.apple.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [Ietf-calsify] RDATE, EXDATE value types X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 21:16:55 -0000 Hi, Is the following legal: DTSTART;TZID=America/Tijuana:20050801T090000 EXDATE:20050801T090000 DTEND;TZID=America/Tijuana:20050801T100000 i.e. is it allowed to have an EXDATE (or RDATE for that matter) that is floating when the DTSTART is not floating (or vice versa)? Seems to me that should not be allowed. i.e.: if DTSTART is UTC or local time, then EXDATE/RDATE MUST also be UTC or localtime. if DTSTART is floating time, then EXDATE/RDATE MUST also be floating time. I couldn't find any text that explicitly spelled that out in 2445bis. -- Cyrus Daboo Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A95DD7FE2D for ; Mon, 1 Oct 2007 07:03:13 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CC97C142203 for ; Mon, 1 Oct 2007 07:02:18 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-50 required=4 tests=[AWL=0.351, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoWUTirkDRl2 for ; Mon, 1 Oct 2007 07:02:12 -0700 (PDT) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 8E40314220E for ; Mon, 1 Oct 2007 07:02:12 -0700 (PDT) Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l91E1oqJ022296; Mon, 1 Oct 2007 08:01:50 -0600 Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id l916k94H023777; Mon, 1 Oct 2007 08:01:49 -0600 Received: from inet-141-146-46-1.oracle.com by acsmt351.oracle.com with ESMTP id 3257523941191247290; Mon, 01 Oct 2007 07:01:30 -0700 Received: from [10.156.42.83] (/10.156.42.83) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Oct 2007 07:01:30 -0700 Message-ID: <4700FDA7.8050305@oracle.com> Date: Mon, 01 Oct 2007 10:01:11 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eliot Lear References: <4700F415.5060500@cisco.com> In-Reply-To: <4700F415.5060500@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE Cc: "ietf-calsify@osafoundation.org" Subject: [Ietf-calsify] Re: so does Tuesdays at 9:00am America/New_York work for everyone for a jabber session? X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 14:03:13 -0000 Works for me. Eliot Lear wrote: > > The co-chairs need a new time. This would start next week, not this > week. This week we'll continue on Thursday. > > Eliot > Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 5D2187FFC4 for ; Mon, 1 Oct 2007 06:22:02 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7A1D31421FF for ; Mon, 1 Oct 2007 06:21:07 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-50 required=4 tests=[AWL=0.572, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHXWdshLqMfB for ; Mon, 1 Oct 2007 06:21:01 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id D549B1421F9 for ; Mon, 1 Oct 2007 06:20:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.21,217,1188770400"; d="scan'208";a="154585306" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 01 Oct 2007 15:20:57 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l91DKvMm008273; Mon, 1 Oct 2007 15:20:57 +0200 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp415.cisco.com [10.61.65.159]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l91DKlFp011331; Mon, 1 Oct 2007 13:20:52 GMT Message-ID: <4700F415.5060500@cisco.com> Date: Mon, 01 Oct 2007 15:20:21 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Cyrus Daboo , Alexey Melnikov , Bernard Desruisseaux , Aki Niemi , "ietf-calsify@osafoundation.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=128; t=1191244857; x=1192108857; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20so=20does=20Tuesdays=20at=209=3A00am=20America/New_York=20wor k=20for=20everyone=20for=0A=20a=20jabber=20session? |Sender:=20; bh=O3Z3QDDnq4OE8LkFRQnCjT4IeWY7OtTrmFD/WNBYI4o=; b=jVi+qpsIEM7VEc2aFJQNahWP0ArYa5UbyRcdm78aoO8vgbWiS3ZgwrdHp1x+NeehWCYedRWD KAeBWZIAF63Ls/MrqLy1QA/1JrxsVBduAO1DIkkVX2PwTEtLXKNdJA4n; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); Subject: [Ietf-calsify] so does Tuesdays at 9:00am America/New_York work for everyone for a jabber session? X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 13:22:02 -0000 The co-chairs need a new time. This would start next week, not this week. This week we'll continue on Thursday. Eliot