Subject: [Ietf-calsify] Issue 95: Multiple REQUEST-STATUS with conflicting status codes

From: aki.niemi at nokia.com (Aki Niemi)
Date: Mon Oct 29 04:15:55 2007

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

From: Aki Niemi <[email-masked]>
To: [email-masked]
Organization: Nokia-TP-MSW/Helsinki
Date: Mon, 29 Oct 2007 13:14:30 +0200
Subject: [Ietf-calsify] Issue 95: Multiple REQUEST-STATUS with conflicting status codes

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

Date: Thu, 25 Oct 2007 11:36:49 -0400
From: Bernard Desruisseaux <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] confusing reference
Cc: [email-masked]

+1

I would be happy to do the proposed change,
and drop the normative reference to RFC 2822.

Cheers,
Bernard

[email-masked] 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
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> 

To: [email-masked]
Date: Wed, 24 Oct 2007 15:52:04 +0200
From: [email-masked]
Subject: [Ietf-calsify] confusing reference

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: Aki Niemi <[email-masked]>
To: [email-masked]
Organization: Nokia-TP-MSW/Helsinki
Date: Wed, 24 Oct 2007 16:22:32 +0300
Subject: [Ietf-calsify] Reminder: chat starts in 8 minutes

Join at:

xmpp:[email-masked]

Cheers,
Aki

From: Aki Niemi <[email-masked]>
To: [email-masked], Eliot Lear <[email-masked]>
Organization: Nokia-TP-MSW/Helsinki
Date: Tue, 23 Oct 2007 07:26:48 +0000
Subject: [Ietf-calsify] Calsify WG jabber chat

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:[email-masked]
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:[email-masked]
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=CHAIR;PARTSTAT=ACCEPTED;RSVP=TRUE;CN=Aki 
 Niemi;LANGUAGE=en:MAILTO:[email-masked]
ATTENDEE;CUTYPE=GROUP;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;
 RSVP=TRUE;LANGUAGE=en:MAILTO:[email-masked]
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=CHAIR;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;
 CN=Eliot Lear;LANGUAGE=en:MAILTO:[email-masked]
RRULE:FREQ=WEEKLY;COUNT=1;INTERVAL=1;BYDAY=WE
END:VEVENT
END:VCALENDAR

Date: Wed, 17 Oct 2007 15:49:44 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] RFC 2445bis Issue 63: Consensus needed

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"

Date: Fri, 03 Aug 2007 17:22:51 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Issue 63: Section 4.8.5.3 Recurrence Date/Times:
	RDATE < DTSTART
Sender: [email-masked]

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
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

--------------040108070104000708010404--

From: Aki Niemi <[email-masked]>
To: "[email-masked]" <[email-masked]>
Organization: Nokia-TP-MSW/Helsinki
Date: Wed, 17 Oct 2007 15:20:14 +0300
Subject: [Ietf-calsify] Jabber chat today at 9:30 EDT / 15:30 CEST

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

Date: Thu, 04 Oct 2007 15:54:09 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] last thursday jabber starts in 5 minutes

Date: Wed, 03 Oct 2007 13:24:38 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Arnaud Quillaud <[email-masked]>
Subject: Re: RE : [Ietf-calsify] iTIP: persisting SEQUENCE number
Cc: Calsify <[email-masked]>, CalDAV DevList <[email-masked]>

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:[email-masked]

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

Date: Tue, 02 Oct 2007 16:05:07 +0200
From: Eliot Lear <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] RDATE, EXDATE value types
Cc: Calsify <[email-masked]>

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
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>

Content-return: prohibited
Date: Tue, 02 Oct 2007 16:00:16 +0200
From: Arnaud Quillaud <[email-masked]>
Subject: RE : [Ietf-calsify] iTIP: persisting SEQUENCE number
Sender: [email-masked]
To: Cyrus Daboo <[email-masked]>, Robert Ransdell <[email-masked]>
Cc: Calsify <[email-masked]>, [email-masked]

> -----Message d'origine-----
> De : [email-masked]=20
> [mailto:[email-masked]] De la part de=20
> Cyrus Daboo
> Envoy=E9 : mardi 2 octobre 2007 05:42
> =C0 : Robert Ransdell
> Cc : Calsify; [email-masked]
> 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
> <[email-masked]> 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
> [email-masked]=20
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>=20

Date: Mon, 01 Oct 2007 23:42:20 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] RDATE, EXDATE value types
Cc: Calsify <[email-masked]>

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

Date: Mon, 01 Oct 2007 23:41:41 -0400
From: Cyrus Daboo <[email-masked]>
To: Robert Ransdell <[email-masked]>
Subject: Re: [Ietf-calsify] iTIP: persisting SEQUENCE number
Cc: Calsify <[email-masked]>, [email-masked]

Hi Robert,

--On October 1, 2007 5:49:11 PM -0400 Robert Ransdell 
<[email-masked]> 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

Date: Mon, 1 Oct 2007 18:29:20 -0700
From: "Caleb Richardson" <[email-masked]>
To: <[email-masked]>
Subject: Re: [Ietf-calsify] iTIP: persisting SEQUENCE number
Reply-To: [email-masked]

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
[email-masked]

--- [email-masked] 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
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Mon, 01 Oct 2007 15:01:27 -0700
From: Jeffrey Harris <[email-masked]>
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] Modifications without masters

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

Date: Mon, 01 Oct 2007 17:53:21 -0400
From: Cyrus Daboo <[email-masked]>
To: Jeffrey Harris <[email-masked]>, Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] Modifications without masters

Hi Jeffrey,

--On October 1, 2007 2:38:36 PM -0700 Jeffrey Harris 
<[email-masked]> 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:[email-masked]
> 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

To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] iTIP: persisting SEQUENCE number
Date: Mon, 1 Oct 2007 17:49:11 -0400
From: "Robert Ransdell" <[email-masked]>
Cc: Calsify <[email-masked]>, [email-masked]

--=_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:
[email-masked]

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
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

--=_alternative 0077DC0585257367_=
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<br><font size=3D2 face=3D"sans-serif">This has been a discussion in the pa=
st.
&nbsp;The iTip says you have to bump by 2. &nbsp;However that leads to
a problem. &nbsp;The CANCEL function and the remove attendee function where
combined. &nbsp;The problem arises if you need to re-invite someone you
have removed. &nbsp; 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. &nbsp;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.</font><br><br><br><font size=3D2 face=3D"sans-=
serif">Previous recommendation was to not bump
sequence number on CANCEL.</font><br><br><br><br><table width=3D100%><tr><t=
d><img src=3Dcid:=5F1=5F088FB514088FB12C0077DC0285257367><td width=3D100%><=
table width=3D100%><tr valign=3Dtop><td width=3D100%><font size=3D2 face=3D=
"sans-serif"><b>[Ietf-calsify] iTIP: persisting
SEQUENCE number</b></font></table><br><table width=3D100%><tr><td><font siz=
e=3D2 color=3D#e26200 face=3D"sans-serif"><b>Cyrus Daboo </b></font><td><fo=
nt size=3D2 color=3D#8f8f8f face=3D"sans-serif">to:</font><td><font size=3D=
2 face=3D"sans-serif">Calsify</font><td><div align=3Dright><font size=3D1 f=
ace=3D"sans-serif">10/01/2007 05:26 PM</font></div></table><br><table width=
=3D100%><tr><td><table width=3D100%><tr><td><font size=3D2 color=3D#8f8f8f =
face=3D"sans-serif">Sent by:</font><td width=3D100%><font size=3D2 color=3D=
#e26200 face=3D"sans-serif"><b>[email-masked]</b></=
font></table><br><td><div align=3Dright></div></table><br></table><br><br><=
hr><br><br><br><tt><font size=3D2>Hi folks,<br>In trying to come up with so=
me clarifying text for the SEQUENCE property
I <br>ran into the following situation:<br><br>1) Create a recurring meetin=
g, Monday-Friday for five instances only.<br>2) Invite an attendee: this wi=
ll send a REQUEST with SEQUENCE:0.<br>3) Override the Wednesday meeting by =
moving forward an hour. This will
send <br>a REQUEST for that instance only with SEQUENCE:1.<br>4) Delete the=
 Thursday instance. This will send a CANCEL for that instance
<br>only.<br><br>Question: what should the SEQUENCE number be for the CANCE=
L?<br><br>There are two possibilities depending on how you read things:<br>=
<br>1) SEQUENCE:1 - this is one more than SEQUENCE:0 which was the last <br=
>sequence number used for the instance being cancelled.<br>2) SEQUENCE:2 - =
this is one more than the largest SEQUENCE sent in prior
<br>messages.<br><br>The problem with this ambiguity is that two clients co=
uld interpret this
<br>differently, so that one sends out SEQUENCE:1 as per the first <br>inte=
rpretation, but the second is expecting SEQUENCE:2 as per the second
<br>interpretation, so it discards the message as being out of date.<br><br=
>My feeling is that when the ORGANIZER has to increment the SEQUENCE number
<br>they MUST use a value that is higher than the largest SEQUENCE previous=
ly
<br>sent for the entire recurrence set.<br><br>Does that make sense? If not=
, why not?<br><br>-- <br>Cyrus Daboo<br><br>=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<br>Ietf-calsify mailing list<br>Ietf-c=
[email-masked]<br></font></tt><a href=3D"http://lists.osafoundati=
on.org/mailman/listinfo/ietf-calsify"><tt><font size=3D2>http://lists.osafo=
undation.org/mailman/listinfo/ietf-calsify<br></font></tt></a><br><BR>
--=_alternative 0077DC0585257367_=--
--=_related 0077DC0285257367_=--

Date: Mon, 01 Oct 2007 14:38:36 -0700
From: Jeffrey Harris <[email-masked]>
To: Calsify <[email-masked]>
Subject: [Ietf-calsify] Modifications without masters

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:[email-masked]
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

Date: Mon, 01 Oct 2007 17:20:15 -0400
From: Cyrus Daboo <[email-masked]>
To: Calsify <[email-masked]>
Subject: [Ietf-calsify] iTIP: persisting SEQUENCE number

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

Date: Mon, 01 Oct 2007 14:18:37 -0700
From: Jeffrey Harris <[email-masked]>
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] RDATE, EXDATE value types

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

Date: Mon, 01 Oct 2007 17:15:32 -0400
From: Cyrus Daboo <[email-masked]>
To: Calsify <[email-masked]>
Subject: [Ietf-calsify] RDATE, EXDATE value types

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

Date: Mon, 01 Oct 2007 10:01:11 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Eliot Lear <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Re: so does Tuesdays at 9:00am America/New_York work for everyone for a jabber session?

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
> 

Date: Mon, 01 Oct 2007 15:20:21 +0200
From: Eliot Lear <[email-masked]>
To: Cyrus Daboo <[email-masked]>, Alexey Melnikov <[email-masked]>, Bernard Desruisseaux <[email-masked]>, Aki Niemi <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] so does Tuesdays at 9:00am America/New_York work for everyone for a jabber session?

The co-chairs need a new time.  This would start next week, not this 
week.  This week we'll continue on Thursday.

Eliot