Subject: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE

From: lear at cisco.com (Eliot Lear)
Date: Thu Sep 13 07:20:36 2007

SEQUENCE is used as a synchronization aid and as a change indicator.

However as a synchronization aid we already have DTSTAMP.

However as a change indicator there is already a requirement that attendee CUAs 
have to spot significant changes that are relevant to their calendar user, so 
SEQUENCE is not important.

Proposal: deprecate use of SEQUENCE.

At the very least if we choose not to do that, we should be much more explicit 
about when SEQUENCE is supposed to change (e.g. ORGANIZER MUST change SEQUENCE 
for these things (...) and SHOULD change SEQUENCE for these things (...) under 
certain circumstances.

---

From: Robert_Ransdell at notesdev.ibm.com (Robert Ransdell)
Date: Thu Sep 13 07:29:01 2007

Skipped content of type multipart/alternative

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Thu Sep 13 07:44:54 2007

Hi Robert,

--On September 13, 2007 10:27:47 AM -0400 Robert Ransdell 
<[email-masked]> wrote:

> The difference between a reschedule event and an update event is the
> sequence number.  That number must be bumped whenever you reschedule an
> event.  It means that the recipient must re-accept/decline.
> If chair just sends an update( say just a subject change),  the sequence
> number is not bumped but the DTSTAMP is.

If there is an  expectation of a reply to an update then the ORGANZIER 
would set PART-STAT back to NEEDS-ACTION and RSVP=TRUE. So doesn't that do 
the job of telling the attendee that they need to re-consider?

Plus what are the rules for changing SEQUENCE? Certainly any time change 
ought to result in it being bumped. But what about LOCATION or TRANSP? Or 
less obvious ones like SUMMARY or DESCRIPTION (the nature of the event 
could be totally change by a change in summary or description).

At the end of the day, its really up to the attendee's CUA to determine 
whether an update to an event is significant enough for that attendee to 
warrant a potential change in their status.

-- 
Cyrus Daboo

---

From: Robert_Ransdell at notesdev.ibm.com (Robert Ransdell)
Date: Thu Sep 13 07:57:43 2007

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Thu Sep 13 08:32:45 2007

Hi Robert,

--On September 13, 2007 10:56:32 AM -0400 Robert Ransdell 
<[email-masked]> wrote:

> If a event has changed in such a way the chair needs to send a
> reschedule, all existing responses become invalid.

OK so you are implying that the SEQUENCE number is being used by the 
ORGANIZER to track responses to different revisions of an event.

>  The chair bumps
> his/her sequence number.  The reschedules are sent out with this new
> sequence number.  When the invitee accepts/declines that seqence number
> is put on the response.  The chair now know who/how each invitee has
> responded to the reschedule event.
>

Right - but isn't the organizer also required to change each attendee's 
RSVP to TRUE? Or are you saying that a change in sequence number always 
requires a reply (even if there is ultimately no change in PART-STAT on the 
attendee's side)?

-- 
Cyrus Daboo

---

From: Robert_Ransdell at notesdev.ibm.com (Robert Ransdell)
Date: Thu Sep 13 08:40:33 2007

---

From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Thu Sep 13 09:27:18 2007

> reschedule, all existing responses become invalid.

Surely that depends on the change? If the chair decides were not meeting
in room 45, but the adjacent room 46, I don't want to have the bother of
having to re-confirm. Likewise if they just add an agenda item.

If the chair moves the venue from one city to another, or one day to
another, I do.

[Apologies for sending my original reply directly to Roger!]

-- 
Andy Mabbett
** via webmail **

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Thu Sep 13 09:30:45 2007

Hi Robert,

--On September 13, 2007 11:39:32 AM -0400 Robert Ransdell 
<[email-masked]> wrote:

> The way I understand that flag, it that it was mostly for  broadcast
> events and/or FYI invitees.  If it is FALSE than the recipient should not
> send back a response.

The definition in 2445bis is (and I don't think this changed from 2445 
either):

This parameter can be specified on properties with a
      CAL-ADDRESS value type.  The parameter identifies the expectation
      of a reply from the calendar user specified by the property value.
      This parameter is used by the "Organizer" to request a
      participation status reply from an "Attendee" of a group scheduled
      event or to-do.  If not specified on a property that allows this
      parameter, the default value is FALSE.

That implies to me that an Organizer really SHOULD (or even MUST) set 
RSVP=TRUE if a reply is expected back. Plus an Attendee SHOULD send back a 
reply when they get RSVP=TRUE.

-- 
Cyrus Daboo

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Thu Sep 13 09:37:24 2007

Hi Andy,

> If the chair moves the venue from one city to another, or one day to

But shouldn't that be YOUR preference as the Attendee? You might not think 
that going from room 45 to 46 is significant, but it might be for another 
attendee (e.g. room 46 does not have disabled accessibility but room 45 
does). Obviously this is not a feasible test today as we lack any detailed 
information about locations, but the VVENUE extension, for example, will 
address that.

Perhaps a better example would be removal of an agenda item. It maybe that 
your only reason for attending the meeting was that particular issue and 
now it is gone you don't need to attend.

My feeling is the Attendee's CUA always has to look at the difference 
between the new event and the existing one and then, based on user 
preferences or defaults, decide whether prompting the user for new state is 
needed. How a client figures that out is not easily defined right now. 
Certainly the "hint" that a change in SEQUENCE gives could be useful, but 
you cannot rely on that.

-- 
Cyrus Daboo

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Thu Sep 13 09:43:04 2007

-1

While one could argue that SEQUENCE is superfluous in iTIP messages
with METHOD:REQUEST. It is not the case for iTIP messages with
METHOD:REPLY. In a REPLY the SEQUENCE property specifies the
SEQUENCE number that was received from the Organizer in a REQUEST.
DTSTAMP doesn't work like that.

The Organizer needs to know to which revision of a component an
Attendee is replying to (SEQUENCE) and whether a most recent
reply has already been received from this Attendee (DTSTAMP).

Cheers,
Bernard

Eliot Lear wrote:
> However as a change indicator there is already a requirement that 
> attendee CUAs have to spot significant changes that are relevant to 
> their calendar user, so SEQUENCE is not important.
> 
> At the very least if we choose not to do that, we should be much more 
> explicit about when SEQUENCE is supposed to change (e.g. ORGANIZER MUST 
> change SEQUENCE for these things (...) and SHOULD change SEQUENCE for 
> these things (...) under certain circumstances.
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>

---

From: TimHare at comcast.net (Tim Hare)
Date: Mon Sep 17 09:44:47 2007

First - everyone who hasn't should read the _extensive_ discussions about
SEQUENCE, especially as related to recurrence sets,  in the archive. The
discussion is too complex to restate here succinctly.

Second - discussion about having to confirm or re-confirm is irrelevant.
SEQUENCE is intended, as I understand it, to allow CUAs to make sure they
have the correct version of an object. If your representation of the object
has SEQUENCE 3 and somehow you receive a SEQUENCE 1 copy, you know you can
ignore it.

Third- from the definitions of these two in our current version of
RFC2445bis (-07?) it appears that DTSTAMP specifies the creation date of the
iCalendar object representation (not the create date of the object in the
calendar store, whatever representation that uses), but does NOT indicate
revisions. From my reading of it, DTSTAMP would only change for a "revision"
if said "revision" consisted of deleting and recreating the iCalendar
object. SEQUENCE would and SHOULD change whenever the Organizer changes
something "significant".

----------------------------------------------------------------------------
-
3.8.7.2.  Date/Time Stamp

   Property Name:  DTSTAMP

   Purpose:  In the case of an iCalendar object that specifies a
      "METHOD" property, this property specifies the date and time that
      the instance of the iCalendar object was created.  In the case of
      an iCalendar object that doesn't specify a "METHOD" property, this
      property specifies the date and time that the information
      associated with the calendar component was last revised in the
      calendar store.

   Value Type:  DATE-TIME

   Property Parameters:  IANA and non-standard property parameters can
      be specified on this property.

   Conformance:  This property MUST be included in the "VEVENT",
      "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components.

   Description:  The value MUST be specified in the UTC time format.

      This property is also useful to protocols such as
      [I-D.ietf-calsify-rfc2447bis] that have inherent latency issues
      with the delivery of content.  This property will assist in the
      proper sequencing of messages containing iCalendar objects.

      In the case of an iCalendar object that specifies a "METHOD"
      property, this property is different than the "CREATED" and "LAST-
      MODIFIED" properties.  These two properties are used to specify
      when the particular calendar data in the calendar store was
      created and last modified.  This is different than when the
      iCalendar object representation of the calendar service
      information was created or last modified.

      In the case of an iCalendar object that doesn't specify a "METHOD"
      property, this property is equivalent to the "LAST-MODIFIED"
      property.

3.8.7.4.  Sequence Number

   Property Name:  SEQUENCE

   Purpose:  This property defines the revision sequence number of the
      calendar component within a sequence of revisions.

   Value Type:  INTEGER

   Property Parameters:  IANA and non-standard property parameters can
      be specified on this property.

   Conformance:  The property can be specified in "VEVENT", "VTODO" or
      "VJOURNAL" calendar component.

   Description:  When a calendar component is created, its sequence
      number is zero (US-ASCII decimal 48).  It is monotonically
      incremented by the "Organizer's" CUA each time the "Organizer"
      makes a significant revision to the calendar component.  When the
      "Organizer" makes changes to one of the following properties, the
      sequence number MUST be incremented:

      *  "DTSTART"

      *  "DTEND"

      *  "DURATION"

      *  "DUE"

      *  "RDATE"

      *  "RRULE"

      *  "EXDATE"

      *  "STATUS"

      In addition, changes made by the "Organizer" to other properties
      can also force the sequence number to be incremented.  The
      "Organizer" CUA MUST increment the sequence number whenever it
      makes changes to properties in the calendar component that the
      "Organizer" deems will jeopardize the validity of the
      participation status of the "Attendees".  For example, changing
      the location of a meeting from one locale to another distant
      locale could effectively impact the participation status of the
      "Attendees".

      The "Organizer" includes this property in an iCalendar object that
      it sends to an "Attendee" to specify the current version of the
      calendar component.

      The "Attendee" includes this property in an iCalendar object that
      it sends to the "Organizer" to specify the version of the calendar
      component that the "Attendee" is referring to.

      A change to the sequence number is not the mechanism that an
      "Organizer" uses to request a response from the "Attendees".  The
      "RSVP" parameter on the "ATTENDEE" property is used by the
      "Organizer" to indicate that a response from the "Attendees" is
      requested.
---------------------------------------------------------------------------

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bernard
Desruisseaux
Sent: Thursday, September 13, 2007 12:42 PM
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE

-1

While one could argue that SEQUENCE is superfluous in iTIP messages with
METHOD:REQUEST. It is not the case for iTIP messages with METHOD:REPLY. In a
REPLY the SEQUENCE property specifies the SEQUENCE number that was received
from the Organizer in a REQUEST.
DTSTAMP doesn't work like that.

The Organizer needs to know to which revision of a component an Attendee is
replying to (SEQUENCE) and whether a most recent reply has already been
received from this Attendee (DTSTAMP).

Cheers,
Bernard

Eliot Lear wrote:
> explicit about when SEQUENCE is supposed to change (e.g. ORGANIZER 
> MUST change SEQUENCE for these things (...) and SHOULD change SEQUENCE 
> for these things (...) under certain circumstances.

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Mon Sep 17 12:56:38 2007

Am Montag, 17. September 2007 schrieb Tim Hare:
> RFC2445bis (-07?) it appears that DTSTAMP specifies the creation date of
> the iCalendar object representation (not the create date of the object in
> the calendar store, whatever representation that uses), but does NOT
> indicate revisions. From my reading of it, DTSTAMP would only change for a
> "revision" if said "revision" consisted of deleting and recreating the
> iCalendar object. 

Actually, this is not clear to me. According to the RFC, the DTSTAMP is the 
date/time then that specific *iCalendar* object is created. If an application 
uses some other storage format and creates the iCalendar objects for calendar 
data exchange on the fly, shouldn't DTSTAMP be the date of that creation?

The DATE-MODIFIED would be the date of the last change, the CREATED would be 
the time of the initial creation of the event. And SEQUENCE needs to be 
incremented whenever a change significant for schedulling happens.

RFC 2445, section 4.8.7.2:
   Purpose: The property indicates the date/time that the instance of
   the iCalendar object was created.

RFC 2445bis-07, section 3.8.7.2:

Hmm, that last added sentence seems like a significant behavior change in the 
RFC. In particular, looking at the further description, I don't think it's 
entirely correct:

RFC 2445, section 4.8.7.2:
   This property is different than the "CREATED" and "LAST-MODIFIED"
   properties. These two properties are used to specify when the
   particular calendar data in the calendar store was created and last
   modified. This is different than when the iCalendar object
   representation of the calendar service information was created or
   last modified.

RFC 2445bis-07, section 3.8.7.2:

I read the old Purpose as DTSTAMP indicating when that iCalendar object was 
created from the data in the calendar store, while the new one indicates that 
it should be the time of the last modification.
The first paragraph of the new Description (and the old description) also 
indicates this, while the added paragraph in the new Description indicates 
something different. Maybe this should be further clarified. If DTSTAMP 
should really be the date of the last modification of the data in the 
calendar store, why do we need it at all?

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/

---

From: Bruce_Kahn at notesdev.ibm.com (Bruce Kahn)
Date: Fri Sep 28 14:21:13 2007

> However as a synchronization aid we already have DTSTAMP.

I'm playing catch up on this thread but I wanted to point out bits that 
may have been overlooked from what I can see.

DTSTAMP is defined as "The property indicates the date/time that the 
instance of the iCalendar object was created" and the descriptive text 
clarifies how it is different than the other timestamps like 
LAST-MODIFIED.  It is the date/time that the iCalendar object was created 
so its the date/time of when you created the Invite, Reply, etc. 

You can never safely assume that all clocks in the world will be in sync. 
So even if you were to try and use a timestamp to track sequencing of 
messages, it is not always reliably done.  Consider the simple case of a 
secretary with a different client machine (and thus different clock) or a 
user uses different computers (eg: Internet cafes/kiosks).   Since 
date/times can vary between 2 system, how can the Chair accurately tell if 
the ACCEPT was done before or after the DECLINE if it is possible that one 
clock is, say, 10 minutes behind the other?  Despite changing my 
participation status only 5 minutes later, it could appear as if I did the 
actions in reverse order than I actually did.

As Tim noted there was lots of talk over this in the original effort so 
see the archives for more info/background.

> At the very least if we choose not to do that, we should be much more 
explicit 
> for these things (...) and SHOULD change SEQUENCE for these things (...) 
under 

The text under SEQUENCE (Section 4.8.7.4 Sequence Number) has a pretty 
decent description of when to update SEQUENCE already.  In a nutshell, if 
the change affects the set of instances or the date/time of an entry then 
SEQUENCE must change. so that all responses to the "old" versions can be 
detected and properly ignored.  Changes that do not affect the date/time 
or instance set such as typo corrections or agenda changes do not require 
a change but they can (at the users discretion). 

What changes to the list do you think are in order?

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Warning: Dates in Calendar are closer than they appear.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20070928/571b01c6/attachment.htm

---

From: Bruce_Kahn at notesdev.ibm.com (Bruce Kahn)
Date: Fri Sep 28 14:48:25 2007

> requires a reply (even if there is ultimately no change in PART-STAT on 
the 

This was covered at length when we originally defined SEQUENCE.  There 
should be lots of meaty tidbits in the archives as to why we picked the 
set we did.

Essentially it boiled down to "If the change affects the scheduling 
aspects of an entry or set, you MUST increase the counter to invalidate 
all replies for the older date/time/set.  Any changes to that do not 
affect the scheduling aspects of the entry or set then you can increase 
the counter but you do not have to."  The reason being that there is a 
trade off to be made.   Only the user really can say if changing the 
LOCATION from "MA" to "WA" or "Room A" to "Room B" is really grounds for 
renegotiating participation with all the invitees!   (A 1 floor change may 
be no big deal but a 3 time zone change is.) 

If it is not significant then why would we want to force the user to 
increase SEQUENCE and thus have to renegotiate participation all over 
again??  That would just make the design inefficient and frustrate our 
users to no end.  So we left it up to the user.  The text in the RFC 
describes this as "when ever it makes changes to properties in the 
calendar component that the "Organizer" deems will jeopardize the validity 
of the participation status of the "Attendees"".  We seem to have not 
expressly pointed out the down side of doing this every time, probably 
assuming the reader would work it out themselves.

So, in answer to your question: No the Organizer is NOT required to change 
SEQUENCE if they change RSVP on ATTENDEEs.   I do not see RSVP setting 
changes as anything that would warrant renegotiating the even with all 
invitees.  However as an Organizer I have that right to change SEQUENCE 
and redo the entire process with everyone.  I would hope that any decent 
CUA would try to dissuade Organizers from gratuitously changing SEQUENCE; 
its bound to annoy the invitees who see no real scheduling related 
changes.

Bruce
Standard disclaimers apply, even where prohibited by law...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20070928/033c7849/attachment.html

To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
Date: Fri, 28 Sep 2007 17:47:32 -0400
From: "Bruce Kahn" <[email-masked]>

--=_alternative 007714C385257364_=
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Cyrus Daboo <[email-masked]> wrote on 09/13/2007 11:31:12 AM:

> Right - but isn't the organizer also required to change each attendee's=20
> RSVP to TRUE? Or are you saying that a change in sequence number always=20
> requires a reply (even if there is ultimately no change in PART-STAT on=20
the=20
> attendee's side)?

This was covered at length when we originally defined SEQUENCE.  There=20
should be lots of meaty tidbits in the archives as to why we picked the=20
set we did.

Essentially it boiled down to "If the change affects the scheduling=20
aspects of an entry or set, you MUST increase the counter to invalidate=20
all replies for the older date/time/set.  Any changes to that do not=20
affect the scheduling aspects of the entry or set then you can increase=20
the counter but you do not have to."  The reason being that there is a=20
trade off to be made.   Only the user really can say if changing the=20
LOCATION from "MA" to "WA" or "Room A" to "Room B" is really grounds for=20
renegotiating participation with all the invitees!   (A 1 floor change may =

be no big deal but a 3 time zone change is.)=20

If it is not significant then why would we want to force the user to=20
increase SEQUENCE and thus have to renegotiate participation all over=20
again??  That would just make the design inefficient and frustrate our=20
users to no end.  So we left it up to the user.  The text in the RFC=20
describes this as "when ever it makes changes to properties in the=20
calendar component that the "Organizer" deems will jeopardize the validity =

of the participation status of the "Attendees"".  We seem to have not=20
expressly pointed out the down side of doing this every time, probably=20
assuming the reader would work it out themselves.

So, in answer to your question: No the Organizer is NOT required to change =

SEQUENCE if they change RSVP on ATTENDEEs.   I do not see RSVP setting=20
changes as anything that would warrant renegotiating the even with all=20
invitees.  However as an Organizer I have that right to change SEQUENCE=20
and redo the entire process with everyone.  I would hope that any decent=20
CUA would try to dissuade Organizers from gratuitously changing SEQUENCE;=20
its bound to annoy the invitees who see no real scheduling related=20
changes.

Bruce
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Bruce Kahn                                INet:=20
Bruce=[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

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

<br><tt><font size=3D2>Cyrus Daboo &lt;[email-masked]&gt; wrote on 09/13/=
2007
11:31:12 AM:<br><br>&gt; Right - but isn't the organizer also required to c=
hange each attendee's
<br>&gt; RSVP to TRUE? Or are you saying that a change in sequence number a=
lways
<br>&gt; requires a reply (even if there is ultimately no change in PART-ST=
AT
on the <br>&gt; attendee's side)?<br></font></tt><br><font size=3D2 face=3D=
"sans-serif">This was covered at length when we originally
defined SEQUENCE. &nbsp;There should be lots of meaty tidbits in the archiv=
es
as to why we picked the set we did.</font><br><br><font size=3D2 face=3D"sa=
ns-serif">Essentially it boiled down to &quot;If
the change affects the scheduling aspects of an entry or set, you MUST
increase the counter to invalidate all replies for the older date/time/set.
&nbsp;Any changes to that do not affect the scheduling aspects of the entry
or set then you can increase the counter but you do not have to.&quot;
&nbsp;The reason being that there is a trade off to be made. &nbsp; Only
the user really can say if changing the LOCATION from &quot;MA&quot; to
&quot;WA&quot; or &quot;Room A&quot; to &quot;Room B&quot; is really grounds
for renegotiating participation with all the invitees! &nbsp; (A 1 floor
change may be no big deal but a 3 time zone change is.) &nbsp;</font><br><b=
r><font size=3D2 face=3D"sans-serif">If it is not significant then why would
we want to force the user to increase SEQUENCE and thus have to renegotiate
participation all over again?? &nbsp;That would just make the design ineffi=
cient
and frustrate our users to no end. &nbsp;So we left it up to the user.
&nbsp;The text in the RFC &nbsp;describes this as &quot;</font><tt><font si=
ze=3D2>when
ever it makes changes to properties in the calendar component that the
&quot;Organizer&quot; deems will jeopardize the validity of the participati=
on
status of the &quot;Attendees&quot;</font></tt><font size=3D2 face=3D"sans-=
serif">&quot;.
&nbsp;We seem to have not expressly pointed out the down side of doing
this every time, probably assuming the reader would work it out themselves.=
</font><br><br><font size=3D2 face=3D"sans-serif">So, in answer to your que=
stion: No the
Organizer is NOT required to change SEQUENCE if they change RSVP on ATTENDE=
Es.
&nbsp; I do not see RSVP setting changes as anything that would warrant
renegotiating the even with all invitees. &nbsp;However as an Organizer
I have that right to change SEQUENCE and redo the entire process with every=
one.
&nbsp;I would hope that any decent CUA would try to dissuade Organizers
from gratuitously changing SEQUENCE; its bound to annoy the invitees who
see no real scheduling related changes.</font><br><br><font size=3D2 face=
=3D"sans-serif">Bruce</font><br><font size=3D2 face=3D"sans-serif">=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>Br=
uce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce=5FKahn@notesdev=
.ibm.com<br>Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>IBM Software Group &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>Standard dis=
claimers apply, even where prohibited by law...</font><BR>
--=_alternative 007714C385257364_=--

To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
Date: Fri, 28 Sep 2007 17:20:17 -0400
From: "Bruce Kahn" <[email-masked]>

--=_alternative 0075082385257364_=
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Eliot Lear <[email-masked]> wrote on 09/13/2007 10:19:02 AM:

>=20

I'm playing catch up on this thread but I wanted to point out bits that=20
may have been overlooked from what I can see.

DTSTAMP is defined as "The property indicates the date/time that the=20
instance of the iCalendar object was created" and the descriptive text=20
clarifies how it is different than the other timestamps like=20
LAST-MODIFIED.  It is the date/time that the iCalendar object was created=20
so its the date/time of when you created the Invite, Reply, etc.=20

You can never safely assume that all clocks in the world will be in sync.=20
So even if you were to try and use a timestamp to track sequencing of=20
messages, it is not always reliably done.  Consider the simple case of a=20
secretary with a different client machine (and thus different clock) or a=20
user uses different computers (eg: Internet cafes/kiosks).   Since=20
date/times can vary between 2 system, how can the Chair accurately tell if =

the ACCEPT was done before or after the DECLINE if it is possible that one =

clock is, say, 10 minutes behind the other?  Despite changing my=20
participation status only 5 minutes later, it could appear as if I did the =

As Tim noted there was lots of talk over this in the original effort so=20
see the archives for more info/background.

> At the very least if we choose not to do that, we should be much more=20
explicit=20
> about when SEQUENCE is supposed to change (e.g. ORGANIZER MUST change=20
SEQUENCE=20
> for these things (...) and SHOULD change SEQUENCE for these things (...) =

under=20
> certain circumstances.

The text under SEQUENCE (Section 4.8.7.4 Sequence Number) has a pretty=20
decent description of when to update SEQUENCE already.  In a nutshell, if=20
the change affects the set of instances or the date/time of an entry then=20
SEQUENCE must change. so that all responses to the "old" versions can be=20
detected and properly ignored.  Changes that do not affect the date/time=20
or instance set such as typo corrections or agenda changes do not require=20
a change but they can (at the users discretion).=20

Bruce
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Bruce Kahn                                INet:=20
Bruce=[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Warning: Dates in Calendar are closer than they appear.

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

<br><tt><font size=3D2>Eliot Lear &lt;[email-masked]&gt; wrote on 09/13/2007
10:19:02 AM:<br><br>&gt; SEQUENCE is used as a synchronization aid and as a=
 change indicator.<br>&gt; <br>&gt; However as a synchronization aid we alr=
eady have DTSTAMP.<br></font></tt><br><font size=3D2 face=3D"sans-serif">I'=
m playing catch up on this thread
but I wanted to point out bits that may have been overlooked from what
I can see.</font><br><br><font size=3D2 face=3D"sans-serif">DTSTAMP is defi=
ned as &quot;</font><tt><font size=3D2>The
property indicates the date/time that the instance of the iCalendar object
was created&quot;</font></tt><font size=3D2 face=3D"sans-serif"> and the de=
scriptive
text clarifies how it is different than the other timestamps like LAST-MODI=
FIED.
&nbsp;It is the date/time that the iCalendar object was created so its
the date/time of when you created the Invite, Reply, etc. &nbsp;</font><br>=
<br><font size=3D2 face=3D"sans-serif">You can never safely assume that all
clocks in the world will be in sync. &nbsp;So even if you were to try and
use a timestamp to track sequencing of messages, it is not always reliably
done. &nbsp;Consider the simple case of a secretary with a different client
machine (and thus different clock) or a user uses different computers (eg:
Internet cafes/kiosks). &nbsp; Since date/times can vary between 2 system,
how can the Chair accurately tell if the ACCEPT was done before or after
the DECLINE if it is possible that one clock is, say, 10 minutes behind
the other? &nbsp;Despite changing my participation status only 5 minutes
later, it could appear as if I did the actions in reverse order than I
actually did.</font><br><br><font size=3D2 face=3D"sans-serif">As Tim noted=
 there was lots of talk
over this in the original effort so see the archives for more info/backgrou=
nd.</font><br><br><tt><font size=3D2>&gt; At the very least if we choose no=
t to do that,
we should be much more explicit <br>&gt; about when SEQUENCE is supposed to=
 change (e.g. ORGANIZER MUST change
SEQUENCE <br>&gt; for these things (...) and SHOULD change SEQUENCE for the=
se things
(...) under <br>&gt; certain circumstances.</font></tt><br><br><font size=
=3D2 face=3D"sans-serif">The text under SEQUENCE (Section 4.8.7.4
Sequence Number) has a pretty decent description of when to update SEQUENCE
already. &nbsp;In a nutshell, if the change affects the set of instances
or the date/time of an entry then SEQUENCE must change. so that all respons=
es
to the &quot;old&quot; versions can be detected and properly ignored. &nbsp=
;Changes
that do not affect the date/time or instance set such as typo corrections
or agenda changes do not require a change but they can (at the users discre=
tion).
</font><br><br><font size=3D2 face=3D"sans-serif">What changes to the list =
do you think
are in order?</font><br><br><font size=3D2 face=3D"sans-serif">Bruce</font>=
<br><font size=3D2 face=3D"sans-serif">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>Bruce Kahn &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce=5FKahn@notesdev=
.ibm.com<br>Messaging &amp; Collaboration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp;
&nbsp; &nbsp; Phone: 978.399.6496<br>IBM Software Group &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; FAX: and nothing but the FAX...<br>Warning: Dat=
es in Calendar are closer than they appear.</font><BR>
--=_alternative 0075082385257364_=--

Date: Fri, 28 Sep 2007 15:03:36 -0400
From: Cyrus Daboo <[email-masked]>
To: Ciny Joy <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] Re: Ietf-calsify Digest, Vol 38, Issue 10

Hi Ciny,

--On September 28, 2007 11:46:53 AM -0700 Ciny Joy <[email-masked]> wrote:

>     So was their a conclusion on the SEQUENCE, DTSTAMP discussion? I am
> especially interested in knowing which fields should be used to determine
> the latest update received in iMIP. Also, is there a proposal to
> standardize when these fields should be modified?

I am crafting a response to all the discussion that took place on this 
recently.

My conclusions are the following:

1) We do need SEQUENCE to properly allow an organizer to match up responses 
from attendees with the latest revisions sent out by the organizer.

2) Clarify that SEQUENCE is not meant to be any kind of indicator to the 
client that a response is needed. RSVP=TRUE must be used instead.

3) Clarify that clients must determine for themselves what constitutes a 
significant change to an event that would cause a new accept/decline prompt 
to be presented to a user. Clients may treat a change in SEQUENCE number as 
always causing a prompt, but should not rely solely on a change of SEQUENCE 
number.

4) Clarify under what circumstances SEQUENCE should change. There is 
currently some text on that in 2445bis, but I am tempted to suggest that 
really belongs in 2446bis in a single section dealing with SEQUENCE issues. 
The text here would list some properties for which changes MUST result in a 
sequence change, and others that MAY result in a change depending on the 
exact nature of the property change. I don't think we can go further than 
that.

I am working on putting together some text on this so that we can seek 
consensus on these points.

-- 
Cyrus Daboo

Date: Fri, 28 Sep 2007 11:46:53 -0700
From: Ciny Joy <[email-masked]>
Sender: [email-masked]
To: [email-masked]
Subject: [Ietf-calsify] Re: Ietf-calsify Digest, Vol 38, Issue 10

This is a multi-part message in MIME format.

--Boundary_(ID_Cvq3+VEg/dLKrQu15YVKiQ)
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

Hi,
    So was their a conclusion on the SEQUENCE, DTSTAMP discussion? I am 
especially interested in knowing which fields should be used to 
determine the latest update received in iMIP. Also, is there a proposal 
to standardize when these fields should be modified?

Thanks,
Ciny

[email-masked] wrote:
> Send Ietf-calsify mailing list submissions to
> 	[email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> or, via email, send a message with subject or body 'help' to
> 	[email-masked]
>
> You can reach the person managing the list at
> 	[email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Ietf-calsify digest..."
>
>
> Today's Topics:
>
>    1. Re: Issue 86: iTIP: DECPRECATE SEQUENCE (Reinhold Kainhofer)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 17 Sep 2007 21:55:26 +0200
> From: Reinhold Kainhofer <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain;  charset="ansi_x3.4-1968"
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFG7tuwTqjEwhXvPN0RAlm0AJ930xifJmWyss5SYLyPDBCYVuR0mgCeMwoT
> hTEwqIdhhNvLnFkGADqSyjo=
> =eXpA
> -----END PGP SIGNATURE-----
>
>
> ------------------------------
>
> End of Ietf-calsify Digest, Vol 38, Issue 10
> ********************************************
>   

--Boundary_(ID_Cvq3+VEg/dLKrQu15YVKiQ)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,<br>
&nbsp;&nbsp;&nbsp; So was their a conclusion on the SEQUENCE, DTSTAMP discussion? I am
especially interested in knowing which fields should be used to
determine the latest update received in iMIP. Also, is there a proposal
to standardize when these fields should be modified?<br>
<br>
Thanks,<br>
Ciny<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> wrote:
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">Send Ietf-calsify mailing list submissions to
	<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>

To subscribe or unsubscribe via the World Wide Web, visit
	<a class="moz-txt-link-freetext" href="http://lists.osafoundation.org/mailman/listinfo/ietf-calsify">http://lists.osafoundation.org/mailman/listinfo/ietf-calsify</a>
or, via email, send a message with subject or body 'help' to
	<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>

You can reach the person managing the list at
	<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ietf-calsify digest..."

Today's Topics:

   1. Re: Issue 86: iTIP: DECPRECATE SEQUENCE (Reinhold Kainhofer)

----------------------------------------------------------------------

Message: 1
Date: Mon, 17 Sep 2007 21:55:26 +0200
From: Reinhold Kainhofer <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
To: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
Message-ID: <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
Content-Type: text/plain;  charset="ansi_x3.4-1968"

  </pre>
  <blockquote type="cite">
    <pre wrap="">Third- from the definitions of these two in our current version of
    </pre>
  </blockquote>
  <pre wrap=""><!---->

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>, <a class="moz-txt-link-freetext" href="http://reinhold.kainhofer.com/">http://reinhold.kainhofer.com/</a>
 * Financial and Actuarial Mathematics, TU Wien, <a class="moz-txt-link-freetext" href="http://www.fam.tuwien.ac.at/">http://www.fam.tuwien.ac.at/</a>
 * K Desktop Environment, <a class="moz-txt-link-freetext" href="http://www.kde.org">http://www.kde.org</a>, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", <a class="moz-txt-link-freetext" href="http://www.jung-wien.at/">http://www.jung-wien.at/</a>

------------------------------

_______________________________________________
Ietf-calsify mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
<a class="moz-txt-link-freetext" href="http://lists.osafoundation.org/mailman/listinfo/ietf-calsify">http://lists.osafoundation.org/mailman/listinfo/ietf-calsify</a>

End of Ietf-calsify Digest, Vol 38, Issue 10
********************************************
  </pre>
</blockquote>
<br>
</body>
</html>

--Boundary_(ID_Cvq3+VEg/dLKrQu15YVKiQ)--

Date: Fri, 28 Sep 2007 13:34:54 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] we need a new jabber time

... as the current time and day is particularly bad for the chairs.  If 
you are interested in participating, please send your  availability to 
me (I don't yet have a good caldav client for f/b ;-).

From: Jonathan Lennox <[email-masked]>
Date: Thu, 27 Sep 2007 14:24:07 -0400
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] Reminder: WGLC for draft-ietf-calsify-rfc2445bis-07	ends TODAY
Cc: [email-masked]

On Thursday, September 27 2007, "Cyrus Daboo" wrote to "Jonathan Lennox, [email-masked]" saying:

> Hi Jonathan,
> 
> --On August 13, 2007 11:56:40 AM -0400 Jonathan Lennox 
> <[email-masked]> wrote:
> 
> > Add the text (wordsmithing as appropriate):
> >
> > +      If the local time when a nominal duration would end does not exist,
> > +      or occurs more than once, in the duration's timezone, it is
> > +      interpreted in the same manner as an explicit DATE-TIME value
> > +      describing that date and time, as specified in section 3.3.5.
> 
> Wordsmithed alternative that I think is clearer:
> 
>     If the local time determined by adding a nominal duration to a
>     DATE-TIME value does not exist, or occurs more than once, in the
>     timezone of the DATE-TIME value used, it is interpreted in the same
>     manner as an explicit DATE-TIME value describing that date and time, as
>     specified in section 3.3.5.
> 
> Other than that, I agree adding this would be good.

Well, this rule needs to apply not only when a nominal duration is added to
an explicit DATE-TIME, but also when a nominal duration is added to the
start time of a recurring event.

I can't think of a good, short way of saying "a date and time value, whether
calculated or explicitly specified", though.  Anyone?

-- 
Jonathan Lennox
[email-masked]

Date: Thu, 27 Sep 2007 13:05:04 -0400
From: Bernard Desruisseaux <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [Ietf-calsify] One last comment on exact vs. nominal durations

I take my words back!

-1

If one always want a nominal duration of 1 day (or N days)
then one should use DURATION instead.

Cheers,
Bernard

Bernard Desruisseaux wrote:
> Jonathan is right.  I wouldn't mind addressing this issue if
> someone wants to propose text.
> 
> Cheers,
> Bernard
> 
> Eliot Lear wrote:
>> Jonathan Lennox wrote:
>>> One other issue occured to me on exact vs. nominal durations.
>>>
>>> The definition of RRULE says:
>>>
>>>       If the duration of the recurring component is specified with the
>>>       "DTEND" or "DUE" property, then the same exact duration will apply
>>>       to all the members of the generated recurrence set.
>>>
>>> This is correct for DTEND or DUE specified with VALUE=DATE-TIME, but 
>>> I think
>>> it's wrong for DTEND or DUE (and thus also DTSTART) with VALUE=DATE.  In
>>> this latter case, I think it's clear that the desired outcome is always
>>> for the event to last a nominal number of days, not the exact 
>>> duration of
>>> time of the first instance of the recurrence set.
>>>
>>> Is this worth addressing?
>>>
>>>   
>>
>> Substantial

Date: Thu, 27 Sep 2007 11:20:14 -0400
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] Reminder: WGLC for draft-ietf-calsify-rfc2445bis-07 ends TODAY
Cc: [email-masked]

Hi Bernard,

--On September 27, 2007 11:12:32 AM -0400 Bernard Desruisseaux 
<[email-masked]> wrote:

> I'm proposing a slight change to cover the case where DTSTART
> is a date in local time (not UTC, no TZID):
>
>     If the local time determined by adding a nominal duration to a
>     DATE-TIME value does not exist, or occurs more than once, in the
>     timezone being used, it is interpreted in the same
>     manner as an explicit DATE-TIME value describing that date and time,
> as
>     specified in section 3.3.5.

+1

-- 
Cyrus Daboo

Date: Thu, 27 Sep 2007 11:12:32 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] Reminder: WGLC for draft-ietf-calsify-rfc2445bis-07 ends TODAY
Cc: [email-masked]

Cyrus Daboo wrote:
> Hi Jonathan,
> 
> --On August 13, 2007 11:56:40 AM -0400 Jonathan Lennox 
> <[email-masked]> wrote:
> 
>> Add the text (wordsmithing as appropriate):
>>
>> +      If the local time when a nominal duration would end does not 
>> exist,
>> +      or occurs more than once, in the duration's timezone, it is
>> +      interpreted in the same manner as an explicit DATE-TIME value
>> +      describing that date and time, as specified in section 3.3.5.
> 
> Wordsmithed alternative that I think is clearer:
> 
>    If the local time determined by adding a nominal duration to a
>    DATE-TIME value does not exist, or occurs more than once, in the
>    timezone of the DATE-TIME value used, it is interpreted in the same
>    manner as an explicit DATE-TIME value describing that date and time, as
>    specified in section 3.3.5.
> 
> Other than that, I agree adding this would be good.
> 

I'm proposing a slight change to cover the case where DTSTART
is a date in local time (not UTC, no TZID):

    If the local time determined by adding a nominal duration to a
    DATE-TIME value does not exist, or occurs more than once, in the
    timezone being used, it is interpreted in the same
    manner as an explicit DATE-TIME value describing that date and time, as
    specified in section 3.3.5.

Cheers,
Bernard

Date: Thu, 27 Sep 2007 11:05:55 -0400
From: Cyrus Daboo <[email-masked]>
To: Jonathan Lennox <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] Reminder: WGLC for draft-ietf-calsify-rfc2445bis-07	ends TODAY

Hi Jonathan,

--On August 13, 2007 11:56:40 AM -0400 Jonathan Lennox 
<[email-masked]> wrote:

> Add the text (wordsmithing as appropriate):
>
> +      If the local time when a nominal duration would end does not exist,
> +      or occurs more than once, in the duration's timezone, it is
> +      interpreted in the same manner as an explicit DATE-TIME value
> +      describing that date and time, as specified in section 3.3.5.

Wordsmithed alternative that I think is clearer:

    If the local time determined by adding a nominal duration to a
    DATE-TIME value does not exist, or occurs more than once, in the
    timezone of the DATE-TIME value used, it is interpreted in the same
    manner as an explicit DATE-TIME value describing that date and time, as
    specified in section 3.3.5.

Other than that, I agree adding this would be good.

-- 
Cyrus Daboo

Date: Thu, 27 Sep 2007 16:55:25 +0200
From: Eliot Lear <[email-masked]>
To: Nigel Swinson <[email-masked]>
Subject: Re: [Ietf-calsify] working group last call commentsfor draft-ietf-calsify-rfc2445bis-07.txt
Cc: CALSIFY Mailinglist <[email-masked]>

Nigel,

Please wade through the below.  Would others please comment as well?

>
>> Nigel's addition is not substantial.  It is repeating what is
>> already specified in section 4.6.5 "Time Zone Component" of
>> RFC 2445, that is:
>>
>>     The mandatory "DTSTART" property gives the effective onset date and
>>     local time for the time zone sub-component definition. "DTSTART" in
>>     this usage MUST be specified as a local DATE-TIME value.
>>
>> I'm not convinced we should repeat this information.
>>
>> No change done.
>>     
>
> The existing text has this:
>
>       ...  In
>       the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL
>       rule part MUST always be specified as a date with UTC time.  If
>       specified as a DATE-TIME value, then it MUST be specified in a UTC
>       time format. .......
>
> One of my objectives was to get rid of the second sentence, as I don't think
> it adds anything, and in the context of the whole paragraph it's confusing
> to know what the second sentence is even refering to.  If this second
> sentence is to stay could someone please explain what it adds?
>
> My second objective was indeed to correlate more fully the relationship
> between DTSTART and UNTIL as it says in 4.6.5.  The start of the paragraph
> has described this relationship in detail for DTSTART and UNTIL under normal
> circumstances, but then goes on to talk about the behaviour within the
> STANDARD/DAYLIGHT components.  I think either it should leave all the
> discussion of it's behaviour within STANDARD/DAYLIGHT to section 4.6.5, or
> complete the discussion by saying, as I had suggested, that UNTIL is always
> date with UTC time and DTSTART is always date with local time.
>
> My third objective was to cleanup the language of the last sentence.
>
> So please can we have either:
>
>        time.  If the "DTSTART" property is specified as a date with
>        UTC time or a date with local time and time zone reference, then
>        the UNTIL rule part MUST be specified as a date with UTC time.  In
>        the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL
>  -      rule part MUST always be specified as a date with UTC time.  If
>  -      specified as a DATE-TIME value, then it MUST be specified in a UTC
>  -      time format.  If not present, and the COUNT rule part is also not
>  +      rule part MUST always be specified as a date with UTC time, with the
>  +      "DTSTART" always represented as a date with local time.  If the
> UNTIL
>  +      and COUNT rule parts are not
>        present, the "RRULE" is considered to repeat forever.
>
> Or:
>
>        time.  If the "DTSTART" property is specified as a date with
>        UTC time or a date with local time and time zone reference, then
> -       the UNTIL rule part MUST be specified as a date with UTC time.  In
> -       the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL
> -       rule part MUST always be specified as a date with UTC time.  If
> -       specified as a DATE-TIME value, then it MUST be specified in a UTC
> -       time format.  If not present, and the COUNT rule part is also not
> +       the UNTIL rule part MUST be specified as a date with UTC time.
> +       If the UNTIL and COUNT rule parts are not
>        present, the "RRULE" is considered to repeat forever.
>
>   

Bernard will propose some cleaned up text to address your issues.

>>>> WRT to the text below I think we should either:
>>>> - Say BYSETPOS is only valid with Weekly, Monthly, Yearly rules,
>>>> - Specify what the "interval" for daily, hourly, minutely, secondly
>>>> means.
>>>> - Drop the new text, as I think the example is sufficient illustration.
>>>> - Change the example to illustrate what obscurity it was that lead to
>>>>         
> the
>   
>>>> need for the new text.
>>>>
>>>> My vote would be to drop some of the new text to become:
>>>>
>>>>       The BYSETPOS rule part specifies a COMMA character (US-ASCII
>>>>       decimal 44) separated list of values which corresponds to the nth
>>>>       occurrence within the set of recurrence instances specified by
>>>>         
> the
>   
>>>>       rule.  BYSETPOS operates on a set of recurrence instances in one
>>>> -      interval of the recurrence rule.  For a WEEKLY rule, the
>>>>         
> interval
>   
>>>> -      is one week, for a MONTHLY rule, one month, and for a YEARLY
>>>>         
> rule,
>   
>>>> -      one year.  Valid values are 1 to 366 or -366 to -1.  It MUST
>>>>         
> only
>   
>>>> +      interval of the recurrence rule.
>>>> +      Valid values are 1 to 366 or -366 to -1.  It MUST only
>>>>       be used in conjunction with another BYxxx rule part.  For example
>>>>       "the last work day of the month" could be represented as:
>>>>
>>>>         FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1
>>>>
>>>>       Each BYSETPOS value can include a positive (+n) or negative (-n)
>>>>       integer.  If present, this indicates the nth occurrence of the
>>>>       specific occurrence within the set of occurences specified by the
>>>>       rule.
>>>>         
>>> Substantial.
>>>       
>> Not changed.
>>     
>
> I think this is important, as currently we have it's an inconsistent level
> of specification, which I think leaves it vague what BYSETPOS means with
> daily, hourly, minutely, secondly.  Could people please comment/vote?
>   

There seems to be agreement.  Bernard will propose text.

>   
>>>> The phrase "special expand" is mentioned nowhere else in the document.
>>>>         
> I
>   
>>>> think the concept was better expressed by my suggestion from the 29th
>>>>         
> May.
>   
>>>> You merge the "Expand" cells in the Yearly/Monthly columns to
>>>>         
> illustrate
>   
>>>> that each creates a set, and when taken together it's the union of the
>>>>         
> sets.
>   
>>>> Also even with a numeric modifier on ByDay, it's still the case that
>>>> Monthly/Yearly + BYDAY will expand, and while it's true that numeric
>>>> modifiers on ByDay with yearly rules requires attention, I think it's
>>>> adequately dealt with in the paragraphs above on ByDay.  So I'd make
>>>>         
> it:
>   
>>>> -      BYDAY has some special behaviour depending on the FREQ value and
>>>> -      this is described in separate notes below the table.
>>>>
>>>>    +----------+--------+--------+-------+-------+------+-------+------+
>>>>    |          |SECONDLY|MINUTELY|HOURLY |DAILY  |WEEKLY|MONTHLY|YEARLY|
>>>>    +----------+--------+--------+-------+-------+------+-------+------+
>>>> -   |BYMONTH   |Limit   |Limit   |Limit  |Limit  |Limit |Limit
>>>>         
> |Expand|
>   
>>>> -
>>>>         
> +----------+--------+--------+-------+-------+------+-------+------+
>   
>>>> -   |BYWEEKNO  |N/A     |N/A     |N/A    |N/A    |N/A   |N/A
>>>>         
> |Expand|
>   
>>>> -
>>>>         
> +----------+--------+--------+-------+-------+------+-------+------+
>   
>>>> -   |BYYEARDAY |Limit   |Limit   |Limit  |N/A    |N/A   |N/A
>>>>         
> |Expand|
>   
>>>> -
>>>>         
> +----------+--------+--------+-------+-------+------+-------+------+
>   
>>>> -   |BYMONTHDAY|Limit   |Limit   |Limit  |Limit  |N/A   |Expand
>>>>         
> |Expand|
>   
>>>> -
>>>>         
> +----------+--------+--------+-------+-------+------+-------+------+
>   
>>>> -   |BYDAY     |Limit   |Limit   |Limit  |Limit  |Expand|Note 1 |Note
>>>>         
> 2|
>   
>>>> -
>>>>         
> +----------+--------+--------+-------+-------+------+-------+------+
>   
>>>> +   |BYMONTH   |Limit   |Limit   |Limit  |Limit  |Limit |Limit  |
>>>>         
> |
>   
>>>> +   +----------+--------+--------+-------+-------+------+-------+
>>>>         
> +
>   
>>>> +   |BYWEEKNO  |N/A     |N/A     |N/A    |N/A    |N/A   |N/A    |
>>>>         
> |
>   
>>>> +   +----------+--------+--------+-------+-------+------+-------+
>>>>         
> +
>   
>>>> +   |BYYEARDAY |Limit   |Limit   |Limit  |N/A    |N/A   |N/A
>>>>         
> |Expand|
>   
>>>> +   +----------+--------+--------+-------+-------+------+-------+
>>>>         
> +
>   
>>>> +   |BYMONTHDAY|Limit   |Limit   |Limit  |Limit  |N/A   |       |
>>>>         
> |
>   
>>>> +   +----------+--------+--------+-------+-------+------+Expand +
>>>>         
> +
>   
>>>> +   |BYDAY     |Limit   |Limit   |Limit  |Limit  |Expand|       |
>>>>         
> |
>   
>>>> +
>>>>         
> +----------+--------+--------+-------+-------+------+-------+------+
>   
>>>>    |BYHOUR    |Limit   |Limit   |Limit  |Expand |Expand|Expand |Expand|
>>>>    +----------+--------+--------+-------+-------+------+-------+------+
>>>>    |BYMINUTE  |Limit   |Limit   |Expand |Expand |Expand|Expand |Expand|
>>>>    +----------+--------+--------+-------+-------+------+-------+------+
>>>>    |BYSECOND  |Limit   |Expand  |Expand |Expand |Expand|Expand |Expand|
>>>>    +----------+--------+--------+-------+-------+------+-------+------+
>>>>    |BYSETPOS  |Limit   |Limit   |Limit  |Limit  |Limit |Limit  |Limit |
>>>>    +----------+--------+--------+-------+-------+------+-------+------+
>>>>
>>>> -      Note 1:  Limit if BYMONTHDAY is present, otherwise special
>>>>         
> expand
>   
>>>> -            for MONTHLY.
>>>> -
>>>> -      Note 2:  Limit if BYYEARDAY or BYMONTHDAY is present, otherwise
>>>> -            special expand for WEEKLY if BYWEEKNO present, otherwise
>>>> -            special expand for MONTHLY if BYMONTH present, otherwise
>>>> -            special expand for YEARLY.
>>>>
>>>> +      In YEARLY rules, BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY and
>>>>         
> BYDAY work
>   
>>>> +      together to expand the recurrence set.  Each on their own will
>>>>         
> specify
>   
>>>> +      a range of valid instances, and when used in combination it is
>>>>         
> the union
>   
>>>> +      of all ranges that create the required recurrence set.  So for
>>>>         
> example
>   
>>>> +      in a YEARLY rule BYDAY=MO will mean every Monday, and
>>>>         
> BYMONTHDAY=1 will
>   
>>>> +      mean the first of every month, so when used together they mean
>>>>         
> the first of
>   
>>>> +      every month, but only when it's a Monday.  It would not mean on
>>>>         
> the first
>   
>>>> +      of every month and also on every Monday.  Likewise in MONTHLY
>>>>         
> rules,
>   
>>>> +      BYMONTHDAY and BYDAY work together to expand the recurrence set.
>>>>
>>>>         
>>> Substantial and editorial.  The combining of boxes is editorial.
>>>       
>> Not changed for now.
>>
>>     
>
> Rather than give you lots more text to read, can I just urge you to (re)read
> the text above and provide opinions.  I think recurrence is the most
> complicated part of iCalendar, and think it's worth crafting the addition of
> the new table just a little more.
>   

Would people please comment on Nigel's proposed change?

Thanks!

Eliot

Date: Thu, 27 Sep 2007 15:29:44 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] jabber session in 1/2 hour

Today's topics will be RFC-2445bis status and RFC-2446bis status.

Thanks,

Eliot

Date: Mon, 24 Sep 2007 09:42:49 -0400
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] IANA registrations for "sub-components"
Cc: Calsify <[email-masked]>

Hi Bernard,

--On September 24, 2007 9:40:48 AM -0400 Bernard Desruisseaux 
<[email-masked]> wrote:

> I suggest that we move the definition of STANDARD and DAYLIGHT
> in sub-sections of section 3.6.5 Time Zone Component, that is,
>
>    3.6.5.1 Standard Time Component
>    3.6.5.2 Daylight Saving Time Component

I think that would be fine.

-- 
Cyrus Daboo

Date: Mon, 24 Sep 2007 09:40:48 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] IANA registrations for "sub-components"
Cc: Calsify <[email-masked]>

I suggest that we move the definition of STANDARD and DAYLIGHT
in sub-sections of section 3.6.5 Time Zone Component, that is,

   3.6.5.1 Standard Time Component
   3.6.5.2 Daylight Saving Time Component

Cheers,
Bernard

Cyrus Daboo wrote:
> Hi,
> In the process of updating the VAVAILABILITY spec to follow the new 
> 2445bis IANA registration process, I noticed the following issue: the 
> STANDARD and DAYLIGHT components (which only occur inside a VTIMEZONE) 
> are not "formally" registered using the component registration template 
> in 8.2.2, yet they are referenced as components in 8.3.1.
> 
> I think we need to accept that sub-components like these can effectively 
> be "registered" as part of the owning component assuming that they only 
> appear in one "owner".
> 
> Same issue arose with the AVAILABLE component that is a sub-component of 
> VAVAILABILITY.
> 

Date: Fri, 21 Sep 2007 22:54:48 -0400
From: Cyrus Daboo <[email-masked]>
To: Calsify <[email-masked]>
Subject: [Ietf-calsify] IANA registrations for "sub-components"

Hi,
In the process of updating the VAVAILABILITY spec to follow the new 2445bis 
IANA registration process, I noticed the following issue: the STANDARD and 
DAYLIGHT components (which only occur inside a VTIMEZONE) are not 
"formally" registered using the component registration template in 8.2.2, 
yet they are referenced as components in 8.3.1.

I think we need to accept that sub-components like these can effectively be 
"registered" as part of the owning component assuming that they only appear 
in one "owner".

Same issue arose with the AVAILABLE component that is a sub-component of 
VAVAILABILITY.

-- 
Cyrus Daboo

Date: Fri, 21 Sep 2007 09:21:28 +0300
From: Aki Niemi <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] [Fwd: Deployment of the Internet-Draft Submission Tool]

FYI.

-------- Original Message --------
Subject: Deployment of the Internet-Draft Submission Tool
Date: Wed, 19 Sep 2007 15:32:20 -0400
From: ext IETF Secretariat <[email-masked]>
Reply-To: [email-masked]
To: IETF Announcement list <[email-masked]>
CC: [email-masked]

The IETF Secretariat is pleased to announce the deployment of the
Internet-Draft Submission Tool (IDST)-Phase I.  The IDST is a Web-based
application that will allow an IETF participant to submit an
Internet-Draft online, obtain approval to post the draft (if necessary),
and make the draft immediately available to the community on the IETF
Web site without the assistance of the Secretariat (in most cases).

The URL for the IDST is:
https://datatracker.ietf.org/idst/upload.cgi

The URL for instructions for using the IDST is:
http://www.ietf.org/idsubmit_instructions.html

Although it will still be possible to submit your drafts by e-mail
(i.e., by sending them to [email-masked]), the tool is
available for use effective immediately, and we encourage you to submit
your drafts via the tool starting today.

If you have any questions about using the tool or wish to report a bug,
then please send a message to [email-masked].

Enjoy!!

The IETF Secretariat

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
Date: Mon, 17 Sep 2007 21:55:26 +0200

Cheers,
Reinhold

- -- 

From: "Tim Hare" <[email-masked]>
To: "'Bernard Desruisseaux'" <[email-masked]>, <[email-masked]>
Subject: RE: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
Date: Mon, 17 Sep 2007 00:14:24 -0400

   Property Name:  DTSTAMP

   Value Type:  DATE-TIME

3.8.7.4.  Sequence Number

   Property Name:  SEQUENCE

   Value Type:  INTEGER

      *  "DTSTART"

      *  "DTEND"

      *  "DURATION"

      *  "DUE"

      *  "RDATE"

      *  "RRULE"

      *  "EXDATE"

      *  "STATUS"

Tim Hare

-----Original Message-----

-1

Cheers,
Bernard

To: Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 87: iTIP: DEPRECATE COUNTER/DECLINE-COUNTER
Date: Fri, 14 Sep 2007 14:17:20 -0400
From: "Robert Ransdell" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, [email-masked]

--=_related 006476AE85257356_=
Content-Type: multipart/alternative;
	boundary="=_alternative 006476B085257356_="

--=_alternative 006476B085257356_=
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Let put it this way.  I have no metrics on usage of particular calendar=20
options.
However the Notes UI makes this available and I know of at least one=20
usage, since they were complaining the target vendor did not support=20
COUNTER.

Re: [Ietf-calsify] Issue 87: iTIP: DEPRECATE COUNTER/DECLINE-COUNTER

Eliot Lear=20
to:
Robert Ransdell
09/13/2007 12:45 PM

Cc:
Mike Douglass, "[email-masked]", ietf-calsify-bounces

(Chair hat off).

Robert Ransdell wrote:
>
> Notes supports Counter/Decline-Counter through iCalendar.

In my opinion this is not sufficient to NOT deprecate a feature.  Just=20
because you support it doesn't mean that anyone uses it.  If you believe=20
that people actually use it, that is a different kettle of fish.

Eliot

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

<br><font size=3D2 face=3D"sans-serif">Let put it this way. &nbsp;I have no
metrics on usage of particular calendar options.</font><br><font size=3D2 f=
ace=3D"sans-serif">However the Notes UI makes this available
and I know of at least one usage, since they were complaining the target
vendor did not support COUNTER.</font><br><br><br><br><table width=3D100%><=
tr><td><img src=3Dcid:=5F1=5F071F1854071F146C006476A985257356><td width=3D1=
00%><table width=3D100%><tr valign=3Dtop><td width=3D100%><font size=3D2 fa=
ce=3D"sans-serif"><b>Re: [Ietf-calsify] Issue
87: iTIP: DEPRECATE COUNTER/DECLINE-COUNTER</b></font></table><br><table wi=
dth=3D100%><tr><td><font size=3D2 color=3D#e26200 face=3D"sans-serif"><b>El=
iot Lear </b></font><td><font size=3D2 color=3D#8f8f8f face=3D"sans-serif">=
to:</font><td><font size=3D2 face=3D"sans-serif">Robert Ransdell</font><td>=
<div align=3Dright><font size=3D1 face=3D"sans-serif">09/13/2007 12:45 PM</=
font></div></table><br><table width=3D100%><tr><td><table width=3D100%><tr>=
<td><font size=3D1 color=3D#8f8f8f face=3D"sans-serif">Cc:</font><td width=
=3D100%><font size=3D1 face=3D"sans-serif">Mike Douglass, &quot;ietf-calsif=
[email-masked]&quot;,
ietf-calsify-bounces</font></table><br><td><div align=3Dright></div></table=
><br></table><br><br><hr><br><br><br><tt><font size=3D2>(Chair hat off).<br=
><br>Robert Ransdell wrote:<br>&gt;<br>&gt; Notes supports Counter/Decline-=
Counter through iCalendar.<br><br>In my opinion this is not sufficient to N=
OT deprecate a feature. &nbsp;Just
<br>because you support it doesn't mean that anyone uses it. &nbsp;If you b=
elieve
<br>that people actually use it, that is a different kettle of fish.<br><br=
>Eliot<br></font></tt><br><BR>
--=_alternative 006476B085257356_=--
--=_related 006476AE85257356_=--

Date: Fri, 14 Sep 2007 13:47:03 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] One last comment on exact vs. nominal durations
Cc: "[email-masked]" <[email-masked]>

Jonathan is right.  I wouldn't mind addressing this issue if
someone wants to propose text.

Cheers,
Bernard

Eliot Lear wrote:
> Jonathan Lennox wrote:
>> One other issue occured to me on exact vs. nominal durations.
>>
>> The definition of RRULE says:
>>
>>       If the duration of the recurring component is specified with the
>>       "DTEND" or "DUE" property, then the same exact duration will apply
>>       to all the members of the generated recurrence set.
>>
>> This is correct for DTEND or DUE specified with VALUE=DATE-TIME, but I 
>> think
>> it's wrong for DTEND or DUE (and thus also DTSTART) with VALUE=DATE.  In
>> this latter case, I think it's clear that the desired outcome is always
>> for the event to last a nominal number of days, not the exact duration of
>> time of the first instance of the recurrence set.
>>
>> Is this worth addressing?
>>
>>   
> 
> Substantial

Date: Fri, 14 Sep 2007 13:09:24 -0400
From: Bernard Desruisseaux <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 85: iTIP: No more RANGE=

Here's a third scenario.

Scenario 3:

   Attendee wants to change his participation status for
   all future recurrence instances of a recurring component
   defined with an unbounded RRULE.

   Solution:

   Attendee changes his participation status in the master
   component to specify the participation status that should
   apply to all the future recurrences instances. Attendee
   create exceptions components for all past recurrence instances
   (including the one specified by DTSTART in the master
   component) to specify his participation status in each one
   of them.  Again, there is always a finite number of past
   recurrence instances so we're okay.

Cheers,
Bernard

Bernard Desruisseaux wrote:
> So far we have identified two scenarios where RANGE=THISANDFUTURE
> was believed to be needed, and in each case we have proposed ways
> to do without it.
> 
> Scenario 1:
> 
>   Organizer cancels all future recurrence instances of a
>   recurring component defined with an unbounded RRULE.
> 
>   Solution:
> 
>   Organizer sends an updated version of the recurring
>   component with an RRULE property that specifies the
>   COUNT or UNTIL rule part to truncate the recurrence set.
> 
> 
> Scenario 2:
> 
>   Organizer changes all future recurrence instances of a
>   recurring calendar component defined with an unbounded
>   RRULE.
> 
>   Solution:
> 
>   Organizer sends an updated version of the recurring
>   component with:
> 
>     * RDATE properties for all past recurrence instances
>       and exception components for them if needed. Note:
>       the number of past recurrence instances is always
>       finite.
> 
>     * No EXDATE properties for past recurrence instances.
>       They would become useless anyway.
> 
>     * DTSTART set to the first recurrence instance to which
>       the change applies.
> 
> Once again, the only issue here is that we need to clarify
> that RDATE can specify a value less than the value specified
> by DTSTART (Issue 63).
> 
> Both scenarios were previously discussed here:
> 
> http://lists.osafoundation.org/pipermail/ietf-calsify/2007-July/001746.html
> http://lists.osafoundation.org/pipermail/ietf-calsify/2007-August/001780.html 
> 
> 
> Cheers,
> Bernard
> 
> Eliot Lear wrote:
>> [Cyrus posted these right into the tracker.]
>>
>> The RANGE= parameter has been removed in 2445bis, but iTIP has 
>> dependencies on it.
>>
>> We need to update iTIP to remove all dependencies on RANGE= and 
>> explain an alternative method to achieve the same result.

Date: Thu, 13 Sep 2007 18:47:21 -0300
From: "=?ISO-8859-1?Q?F=E1bio_Henrique_da_Silva?=" <[email-masked]>
To: "Eliot Lear" <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 87: iTIP: DEPRECATE COUNTER/DECLINE-COUNTER
Cc: "[email-masked]" <[email-masked]>, [email-masked]

------=_Part_22217_17165624.1189720041889
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Eliot,

What you suggest is to use REPLY as a way to suggest an alternative event
description (as COUNTER/DECLINE-COUNTER are special cases of replies) or to
exclude the "counter" feature from iTIP at all?

Cheers,

F=E1bio.

On 9/13/07, Eliot Lear <[email-masked]> wrote:
>
> (Chair hat off).
>
> Robert Ransdell wrote:
> >
> > Notes supports Counter/Decline-Counter through iCalendar.
>
> In my opinion this is not sufficient to NOT deprecate a feature.  Just
> because you support it doesn't mean that anyone uses it.  If you believe
> that people actually use it, that is a different kettle of fish.
>
> Eliot

------=_Part_22217_17165624.1189720041889
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Eliot,<br><br>What you suggest is to use REPLY as a way to suggest an alter=
native event description (as COUNTER/DECLINE-COUNTER are special cases of r=
eplies) or to exclude the &quot;counter&quot; feature from iTIP at all?<br>
<br>Cheers,<br><br>F=E1bio.<br><br><div><span class=3D"gmail_quote">On 9/13=
/07, <b class=3D"gmail_sendername">Eliot Lear</b> &lt;<a href=3D"mailto:lea=
[email-masked]">[email-masked]</a>&gt; wrote:</span><blockquote class=3D"gmail=
_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt=
 0pt 0.8ex; padding-left: 1ex;">
(Chair hat off).<br><br>Robert Ransdell wrote:<br>&gt;<br>&gt; Notes suppor=
ts Counter/Decline-Counter through iCalendar.<br><br>In my opinion this is =
not sufficient to NOT deprecate a feature.&nbsp;&nbsp;Just<br>because you s=
upport it doesn&#39;t mean that anyone uses it.&nbsp;&nbsp;If you believe
<br>that people actually use it, that is a different kettle of fish.<br><br=
>Eliot<br>_______________________________________________<br>Ietf-calsify m=
ailing list<br><a href=3D"mailto:[email-masked]">Ietf-calsi=
[email-masked]
</a><br><a href=3D"http://lists.osafoundation.org/mailman/listinfo/ietf-cal=
sify">http://lists.osafoundation.org/mailman/listinfo/ietf-calsify</a><br><=
/blockquote></div><br>

------=_Part_22217_17165624.1189720041889--

Date: Thu, 13 Sep 2007 16:16:30 -0400
From: Bernard Desruisseaux <[email-masked]>
To: CALSIFY Mailinglist <[email-masked]>
Subject: Re: [Ietf-calsify] working group last call comments for	draft-ietf-calsify-rfc2445bis-07.txt

Eliot Lear wrote:
> Dear all,
> 
> Working Group Last Call (WGLC) has now closed for 
> draft-ietf-calsify-rfc2445bis-07.txt.  We received two messages during 
> WGLC.  There are two forms of comments we will address: editorial and 
> substantial changes.  The editor may use his discretion accept or reject 
> editorial comments.  The working group must consider proposals for 
> substantial changes.  What follows is the chair's opinion as to what is 
> editorial and what is substantial:
> 
> On the 3rd of August, Bernard proposed a change to close Issue 63.   I 
> view this change as substantial and requiring working group input.
> 
> Now, breaking up Nigel Swinson's message of the 1st of August (thank 
> you, Nigel):
> 
>> Version 7 contains numerous additions of this form:
>>
>>     "Applications MUST treat x-name and iana-token value they don't
>>     recognized the same way as the XXXX value."
>>
>> I don't think this is gramatically correct.  I'd suggest:
>>
>>     "Applications MUST treat x-name and iana-token values they don't
>>     recognize the same way as they would the XXXX value."
>>   
> 
> Editorial.

Done.

> 
>> Or better still rely on the existing description of what the default 
>> value
>> is:
>>
>>     "Applications MUST ignore x-name and iana-token values they don't
>>     recognize and revert to the default value for the parameter."
>>   
> 
> Substantial if reverting means changing the actual text of the invitation.
> 
>> This comment applies to:
>> - 3.2.  Property Parameters
>> - 3.2.3.  Calendar User Type
>> - 3.2.9.  Free/Busy Time Type
>> - 3.2.12.  Participation Status
>> - 3.2.14.  Relationship Type
>> - 3.2.15.  Participation Role
>> - 3.2.19.  Value Data Types
>> - 3.8.1.3.  Classification
>> - 3.8.6.1.  Action
>>
>> 3.3.10.  Recurrence Rule
>>
>>       The UNTIL rule part defines a DATE or DATE-TIME value which bounds
>>       the recurrence rule in an inclusive manner.  If the value
>>       specified by UNTIL is synchronized with the specified recurrence,
>>       this DATE or DATE-TIME becomes the last instance of the
>>       recurrence.  The value of the UNTIL rule part 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 UNTIL rule part MUST also be specified as a date with local
>> -      time.  Else, if the "DTSTART" property is specified as a date with
>> +      time.  If the "DTSTART" property is specified as a date with
>>   
> 
> Editorial.

Done.

> 
>>       UTC time or a date with local time and time zone reference, then
>>       the UNTIL rule part MUST be specified as a date with UTC time.  In
>>       the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL
>> -      rule part MUST always be specified as a date with UTC time.  If
>> -      specified as a DATE-TIME value, then it MUST be specified in a UTC
>> -      time format.  If not present, and the COUNT rule part is also not
>> +      rule part MUST always be specified as a date with UTC time, 
>> with the
>> +      "DTSTART" always represented as a date with local time.  If the 
>> UNTIL
>> +      and COUNT rule parts are not
>>   
> 
> Substantial.

Nigel's addition is not substantial.  It is repeating what is
already specified in section 4.6.5 "Time Zone Component" of
RFC 2445, that is:

    The mandatory "DTSTART" property gives the effective onset date and
    local time for the time zone sub-component definition. "DTSTART" in
    this usage MUST be specified as a local DATE-TIME value.

I'm not convinced we should repeat this information.

No change done.

> 
>>       present, the "RRULE" is considered to repeat forever.
>>
>> Below I've re-ordered the sentences in addition to changing one word.  I
>> find changing from "the specific day" to "a specific day" helpful in 
>> warning
>> that 3MO in a yearly rule isn't necessarily "the 3rd Monday in the 
>> year" and
>> rather "a 3rd Monday in the year".  Later we go on to describe in more
>> detail how to interpret "a 3rd Monday in the year".
>>
>>       Each BYDAY value can also be preceded by a positive (+n) or
>>       negative (-n) integer.  If present, this indicates the nth
>> -      occurrence of the specific day within the MONTHLY or YEARLY
>> +      occurrence of a specific day within the MONTHLY or YEARLY

Done.

>>       "RRULE".  For example, within a MONTHLY rule, +1MO (or simply 1MO)
>>       represents the first Monday within the month, whereas -1MO
>> -      represents the last Monday of the month.  If an integer modifier
>> +      represents the last Monday of the month.  The
>> +      numeric value in a BYDAY rule part with the FREQ rule part set to
>> +      YEARLY corresponds to an offset within the month when the BYMONTH
>> +      rule part is present, and corresponds to an offset within the year
>> +      when the BYWEEKNO or BYMONTH rule parts are present.
>> +      If an integer modifier
>>   
> 
> This seems to be editorial.

Done.

> 
>>       is not present, it means all days of this type within the
>>       specified frequency.  For example, within a MONTHLY rule, MO
>>       represents all Mondays within the month.  The BYDAY rule part MUST
>>       NOT be specified with a numeric value when the FREQ rule part is
>>       not set to MONTHLY or YEARLY.  Furthermore, the BYDAY rule part
>>       MUST NOT be specified with a numeric value with the FREQ rule part
>> +      set to YEARLY when the BYWEEKNO rule part is specified.
>> -      set to YEARLY when the BYWEEKNO rule part is specified.  The
>> -      numeric value in a BYDAY rule part with the FREQ rule part set to
>> -      YEARLY corresponds to an offset within the month when the BYMONTH
>> -      rule part is present, and corresponds to an offset within the year
>> -      when the BYWEEKNO or BYMONTH rule parts are present.
>>
>>   
> Again, editorial.

Done.

> 
>>       The BYYEARDAY rule part specifies a COMMA character (US-ASCII
>>       decimal 44) separated list of days of the year.  Valid values are
>>       1 to 366 or -366 to -1.  For example, -1 represents the last day
>>       of the year (December 31st) and -306 represents the 306th to the
>>       last day of the year (March 1st).  The BYYEARDAY rule part MUST
>>       NOT be specified when the FREQ rule part is set to DAILY, WEEKLY,
>> -      and MONTHLY.
>> +     or MONTHLY.
>>   
> 
> While some might view this as substantial, I believe this is editorial 
> because the working group discussed the intent here in depth, and Nigel 
> is correct in my opinion as to our interpretation.

Done.

> 
>> I think there's too many negatives in what was there:
>>
>>       The BYWEEKNO rule part specifies a COMMA character (US-ASCII
>>       decimal 44) separated list of ordinals specifying weeks of the
>>       year.  Valid values are 1 to 53 or -53 to -1.  This corresponds to
>>       weeks according to week numbering as defined in [ISO.8601.2004].
>>       A week is defined as a seven day period, starting on the day of
>>       the week defined to be the week start (see WKST).  Week number one
>>       of the calendar year is the first week which contains at least
>>       four (4) days in that calendar year.  This rule part MUST NOT be
>> -      used when the FREQ rule part is not set to YEARLY.  For example, 3
>> +      used when the FREQ rule part is set to anything other than YEARLY.
>> +      For example, 3
>>   
> 
> Editorial.

Done.

> 
>>       represents the third week of the year.
>>
>> WRT to the text below I think we should either:
>> - Say BYSETPOS is only valid with Weekly, Monthly, Yearly rules,
>> - Specify what the "interval" for daily, hourly, minutely, secondly 
>> means.
>> - Drop the new text, as I think the example is sufficient illustration.
>> - Change the example to illustrate what obscurity it was that lead to the
>> need for the new text.
>>
>> My vote would be to drop some of the new text to become:
>>
>>       The BYSETPOS rule part specifies a COMMA character (US-ASCII
>>       decimal 44) separated list of values which corresponds to the nth
>>       occurrence within the set of recurrence instances specified by the
>>       rule.  BYSETPOS operates on a set of recurrence instances in one
>> -      interval of the recurrence rule.  For a WEEKLY rule, the interval
>> -      is one week, for a MONTHLY rule, one month, and for a YEARLY rule,
>> -      one year.  Valid values are 1 to 366 or -366 to -1.  It MUST only
>> +      interval of the recurrence rule.
>> +      Valid values are 1 to 366 or -366 to -1.  It MUST only
>>       be used in conjunction with another BYxxx rule part.  For example
>>       "the last work day of the month" could be represented as:
>>   
> 
> Substantial.

Not changed.

> 
>>         FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1
>>
>>       Each BYSETPOS value can include a positive (+n) or negative (-n)
>>       integer.  If present, this indicates the nth occurrence of the
>>       specific occurrence within the set of occurences specified by the
>>       rule.
>>
>> The phrase "special expand" is mentioned nowhere else in the document.  I
>> think the concept was better expressed by my suggestion from the 29th 
>> May.
>> You merge the "Expand" cells in the Yearly/Monthly columns to illustrate
>> that each creates a set, and when taken together it's the union of the 
>> sets.
>> Also even with a numeric modifier on ByDay, it's still the case that
>> Monthly/Yearly + BYDAY will expand, and while it's true that numeric
>> modifiers on ByDay with yearly rules requires attention, I think it's
>> adequately dealt with in the paragraphs above on ByDay.  So I'd make it:
>>
>> -      BYDAY has some special behaviour depending on the FREQ value and
>> -      this is described in separate notes below the table.
>>
>>    +----------+--------+--------+-------+-------+------+-------+------+
>>    |          |SECONDLY|MINUTELY|HOURLY |DAILY  |WEEKLY|MONTHLY|YEARLY|
>>    +----------+--------+--------+-------+-------+------+-------+------+
>> -   |BYMONTH   |Limit   |Limit   |Limit  |Limit  |Limit |Limit  |Expand|
>> -   +----------+--------+--------+-------+-------+------+-------+------+
>> -   |BYWEEKNO  |N/A     |N/A     |N/A    |N/A    |N/A   |N/A    |Expand|
>> -   +----------+--------+--------+-------+-------+------+-------+------+
>> -   |BYYEARDAY |Limit   |Limit   |Limit  |N/A    |N/A   |N/A    |Expand|
>> -   +----------+--------+--------+-------+-------+------+-------+------+
>> -   |BYMONTHDAY|Limit   |Limit   |Limit  |Limit  |N/A   |Expand |Expand|
>> -   +----------+--------+--------+-------+-------+------+-------+------+
>> -   |BYDAY     |Limit   |Limit   |Limit  |Limit  |Expand|Note 1 |Note 2|
>> -   +----------+--------+--------+-------+-------+------+-------+------+
>> +   |BYMONTH   |Limit   |Limit   |Limit  |Limit  |Limit |Limit  |      |
>> +   +----------+--------+--------+-------+-------+------+-------+      +
>> +   |BYWEEKNO  |N/A     |N/A     |N/A    |N/A    |N/A   |N/A    |      |
>> +   +----------+--------+--------+-------+-------+------+-------+      +
>> +   |BYYEARDAY |Limit   |Limit   |Limit  |N/A    |N/A   |N/A    |Expand|
>> +   +----------+--------+--------+-------+-------+------+-------+      +
>> +   |BYMONTHDAY|Limit   |Limit   |Limit  |Limit  |N/A   |       |      |
>> +   +----------+--------+--------+-------+-------+------+Expand +      +
>> +   |BYDAY     |Limit   |Limit   |Limit  |Limit  |Expand|       |      |
>> +   +----------+--------+--------+-------+-------+------+-------+------+
>>    |BYHOUR    |Limit   |Limit   |Limit  |Expand |Expand|Expand |Expand|
>>    +----------+--------+--------+-------+-------+------+-------+------+
>>    |BYMINUTE  |Limit   |Limit   |Expand |Expand |Expand|Expand |Expand|
>>    +----------+--------+--------+-------+-------+------+-------+------+
>>    |BYSECOND  |Limit   |Expand  |Expand |Expand |Expand|Expand |Expand|
>>    +----------+--------+--------+-------+-------+------+-------+------+
>>    |BYSETPOS  |Limit   |Limit   |Limit  |Limit  |Limit |Limit  |Limit |
>>    +----------+--------+--------+-------+-------+------+-------+------+
>>
>> -      Note 1:  Limit if BYMONTHDAY is present, otherwise special expand
>> -            for MONTHLY.
>> -
>> -      Note 2:  Limit if BYYEARDAY or BYMONTHDAY is present, otherwise
>> -            special expand for WEEKLY if BYWEEKNO present, otherwise
>> -            special expand for MONTHLY if BYMONTH present, otherwise
>> -            special expand for YEARLY.
>>
>> +      In YEARLY rules, BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY and 
>> BYDAY
>> work
>> +      together to expand the recurrence set.  Each on their own will
>> specify
>> +      a range of valid instances, and when used in combination it is the
>> union
>> +      of all ranges that create the required recurrence set.  So for
>> example
>> +      in a YEARLY rule BYDAY=MO will mean every Monday, and BYMONTHDAY=1
>> will
>> +      mean the first of every month, so when used together they mean the
>> first of
>> +      every month, but only when it's a Monday.  It would not mean on 
>> the
>> first
>> +      of every month and also on every Monday.  Likewise in MONTHLY 
>> rules,
>> +      BYMONTHDAY and BYDAY work together to expand the recurrence set.
>>   
> 
> 
> Substantial and editorial.  The combining of boxes is editorial.

Not changed for now.

> 
>> 3.6.  Calendar Components
>>
>>    An iCalendar object MUST include the "PRODID" and "VERSION" calendar
>>    properties.  In addition, it MUST include at least one calendar
>>    component.  Special forms of iCalendar objects are possible to
>>    publish just busy time (i.e., only a "VFREEBUSY" calendar component)
>>    or time zone (i.e., only a "VTIMEZONE" calendar component)
>>    information.  In addition, a complex iCalendar object that is used to
>>    capture a complete snapshot of the contents of a calendar is possible
>>    (e.g., composite of many different calendar components).  More
>>    commonly, an iCalendar object will consist of just a single "VEVENT",
>>    "VTODO" or "VJOURNAL" calendar component.  Applications MUST ignore
>> -   x-comp and iana-comp they don't recognized.
>> +   x-comp and iana-comp they don't recognize.
>>   
> 
> Editorial.

Done.

> 
>> 3.8.1.1.  Attachment
>>
>>    Conformance:  This property can be specified multiple times in a
>>       "VEVENT", "VTODO", "VJOURNAL" or "VALARM" calendar component with
>> -      the exception of AUDIO alarm which only allow this property to
>> +      the exception of AUDIO alarm which only allows this property to
>>       occur once.
>>   
> 
> Editorial.

Done.

> 
>> 3.8.2.3.  Date/Time Due
>>
>> -   Description:  This property defines the date and time that a to-do is
>> +   Description:  This property defines the date and time before which a
>>   
> 
> Editorial.

Done.

> 
>> to-do is
>>       expected to be completed.  For cases where this property is
>>       specified in a "VTODO" calendar component that also specifies a
>>       "DTSTART" property, the value type of this property MUST be the
>>       same as the "DTSTART" property, and the value of this property
>>       MUST be later in time than the value of the "DTSTART" property.
>>       Furthermore, this property MUST be specified as a date with local
>>       time if and only if the "DTSTART" property is also specified as a
>>       date with local time.
>>
>> 3.8.6.2.  Repeat Count
>> -   Description:  This property defines the number of time an alarm
>> +   Description:  This property defines the number of times an alarm
>>   
> 
> Editorial.

Done.

> 
>>       should be repeated after its initial trigger.  If the alarm
>>       triggers more than once, then this property MUST be specified
>>       along with the "DURATION" property.
>>
>> 3.8.7.2.  Date/Time Stamp
>>
>> -      property, this property is different than the "CREATED" and "LAST-
>> +      property, this property is different to the "CREATED" and "LAST-
>>   
> 
> Editorial.  Suggestion: "this property differs from".

Done.

Nigel: Thanks a lot!

Cheers,
Bernard

>> Nigel
> Thanks again,
> Eliot

Date: Thu, 13 Sep 2007 14:41:10 -0400
From: Bernard Desruisseaux <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 91: iTIP: VFREEBUSY reply does not allow zero	FREEBUSY properties

+1

Eliot Lear wrote:
> [From Cyrus:]
> 
> The restriction table of the VFREEBUSY reply method has FREEBUSY 1+. But 
> its quite possible to have a free-busy response where there is no busy 
> time being indicated.
> 
> Proposal: fix the table to use FREEBUSY 0+.

Date: Thu, 13 Sep 2007 14:21:20 -0400
From: Bernard Desruisseaux <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 85: iTIP: No more RANGE=

So far we have identified two scenarios where RANGE=THISANDFUTURE
was believed to be needed, and in each case we have proposed ways
to do without it.

Scenario 1:

   Organizer cancels all future recurrence instances of a
   recurring component defined with an unbounded RRULE.

   Solution:

   Organizer sends an updated version of the recurring
   component with an RRULE property that specifies the
   COUNT or UNTIL rule part to truncate the recurrence set.

Scenario 2:

   Organizer changes all future recurrence instances of a
   recurring calendar component defined with an unbounded
   RRULE.

   Solution:

   Organizer sends an updated version of the recurring
   component with:

     * RDATE properties for all past recurrence instances
       and exception components for them if needed. Note:
       the number of past recurrence instances is always
       finite.

     * No EXDATE properties for past recurrence instances.
       They would become useless anyway.

     * DTSTART set to the first recurrence instance to which
       the change applies.

Once again, the only issue here is that we need to clarify
that RDATE can specify a value less than the value specified
by DTSTART (Issue 63).

Both scenarios were previously discussed here:

http://lists.osafoundation.org/pipermail/ietf-calsify/2007-July/001746.html
http://lists.osafoundation.org/pipermail/ietf-calsify/2007-August/001780.html

Cheers,
Bernard

Eliot Lear wrote:
> [Cyrus posted these right into the tracker.]
> 
> The RANGE= parameter has been removed in 2445bis, but iTIP has 
> dependencies on it.
> 
> We need to update iTIP to remove all dependencies on RANGE= and explain 
> an alternative method to achieve the same result.

Date: Thu, 13 Sep 2007 18:42:15 +0200
From: Eliot Lear <[email-masked]>
To: Robert Ransdell <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 87: iTIP: DEPRECATE COUNTER/DECLINE-COUNTER
Cc: "[email-masked]" <[email-masked]>, [email-masked]

(Chair hat off).

Robert Ransdell wrote:
>
> Notes supports Counter/Decline-Counter through iCalendar.

In my opinion this is not sufficient to NOT deprecate a feature.  Just 
because you support it doesn't mean that anyone uses it.  If you believe 
that people actually use it, that is a different kettle of fish.

Eliot

Date: Thu, 13 Sep 2007 12:41:32 -0400
From: Bernard Desruisseaux <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE

-1

Cheers,
Bernard

> these things (...) under certain circumstances.

Date: Thu, 13 Sep 2007 12:36:11 -0400
From: Cyrus Daboo <[email-masked]>
To: Andy Mabbett <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE

Hi Andy,

-- 
Cyrus Daboo

Date: Thu, 13 Sep 2007 12:29:19 -0400
From: Cyrus Daboo <[email-masked]>
To: Robert Ransdell <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
Cc: [email-masked]

Hi Robert,

-- 
Cyrus Daboo

Date: Thu, 13 Sep 2007 17:26:12 +0100 (BST)
Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
From: "Andy Mabbett" <[email-masked]>
To: [email-masked]

-- 
Andy Mabbett
** via webmail **

To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
Date: Thu, 13 Sep 2007 11:39:32 -0400
From: "Robert Ransdell" <[email-masked]>
Cc: [email-masked]

--=_related 0056049285257355_=
Content-Type: multipart/alternative;
	boundary="=_alternative 0056049285257355_="

--=_alternative 0056049285257355_=
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

The way I understand that flag, it that it was mostly for  broadcast=20
events and/or FYI invitees.  If it is FALSE than the recipient should not=20
send back a response.

Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE

Cyrus Daboo=20
to:
Robert Ransdell
09/13/2007 11:31 AM

Cc:
ietf-calsify, Eliot Lear

Hi Robert,

> reschedule, all existing responses become invalid.

OK so you are implying that the SEQUENCE number is being used by the=20
ORGANIZER to track responses to different revisions of an event.

> responded to the reschedule event.

Right - but isn't the organizer also required to change each attendee's=20
RSVP to TRUE? Or are you saying that a change in sequence number always=20
requires a reply (even if there is ultimately no change in PART-STAT on=20
the=20
attendee's side)?

--=20
Cyrus Daboo

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

<br><font size=3D2 face=3D"sans-serif">The way I understand that flag, it t=
hat
it was mostly for &nbsp;broadcast events and/or FYI invitees. &nbsp;If
it is FALSE than the recipient should not send back a response.</font><br><=
br><br><br><table width=3D100%><tr><td><img src=3Dcid:=5F1=5F0939914809398D=
600056049285257355><td width=3D100%><table width=3D100%><tr valign=3Dtop><t=
d width=3D100%><font size=3D2 face=3D"sans-serif"><b>Re: [Ietf-calsify] Iss=
ue
86: iTIP: DECPRECATE SEQUENCE</b></font></table><br><table width=3D100%><tr=
><td><font size=3D2 color=3D#e26200 face=3D"sans-serif"><b>Cyrus Daboo </b>=
</font><td><font size=3D2 color=3D#8f8f8f face=3D"sans-serif">to:</font><td=
><font size=3D2 face=3D"sans-serif">Robert Ransdell</font><td><div align=3D=
right><font size=3D1 face=3D"sans-serif">09/13/2007 11:31 AM</font></div></=
table><br><table width=3D100%><tr><td><table width=3D100%><tr><td><font siz=
e=3D1 color=3D#8f8f8f face=3D"sans-serif">Cc:</font><td width=3D100%><font =
size=3D1 face=3D"sans-serif">ietf-calsify, Eliot Lear</font></table><br><td=
><div align=3Dright></div></table><br></table><br><br><hr><br><br><br><tt><=
font size=3D2>Hi Robert,<br><br>--On September 13, 2007 10:56:32 AM -0400 R=
obert Ransdell <br>&lt;Robert=[email-masked]&gt; wrote:<br><br=
>&gt; If a event has changed in such a way the chair needs to send a<br>&gt=
; reschedule, all existing responses become invalid.<br><br>OK so you are i=
mplying that the SEQUENCE number is being used by the <br>ORGANIZER to trac=
k responses to different revisions of an event.<br><br>&gt; &nbsp;The chair=
 bumps<br>&gt; his/her sequence number. &nbsp;The reschedules are sent out =
with this
new<br>&gt; sequence number. &nbsp;When the invitee accepts/declines that s=
eqence
number<br>&gt; is put on the response. &nbsp;The chair now know who/how eac=
h invitee
has<br>&gt; responded to the reschedule event.<br>&gt;<br><br>Right - but i=
sn't the organizer also required to change each attendee's
<br>RSVP to TRUE? Or are you saying that a change in sequence number always
<br>requires a reply (even if there is ultimately no change in PART-STAT on
the <br>attendee's side)?<br><br>-- <br>Cyrus Daboo<br><br></font></tt><br>=
<BR>
--=_alternative 0056049285257355_=--
--=_related 0056049285257355_=--

To: Mike Douglass <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 87: iTIP: DEPRECATE COUNTER/DECLINE-COUNTER
Date: Thu, 13 Sep 2007 11:32:22 -0400
From: "Robert Ransdell" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, [email-masked]

--=_related 00555C9685257355_=
Content-Type: multipart/alternative;
	boundary="=_alternative 00555C9685257355_="

--=_alternative 00555C9685257355_=
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Notes supports Counter/Decline-Counter through iCalendar.

Re: [Ietf-calsify] Issue 87: iTIP: DEPRECATE COUNTER/DECLINE-COUNTER

Mike Douglass=20
to:
[email-masked]
09/13/2007 11:17 AM

Sent by:
[email-masked]

I implemented COUNTER and DECLINE-COUNTER and would like to see them=20
retained.

What would you propose as an alternative?

The lack of use of some features may be more of a symptom of poor=20
interoperability overall than an indication they are not useful.

Eliot Lear wrote:
> [From Cyrus:]
>
> Its my belief that COUNTER/DECLINE-COUNTER are rarely used and that we=20
> can remove them from this revision.
>
> =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
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

--=20

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

=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 00555C9685257355_=
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<br><font size=3D2 face=3D"sans-serif">Notes supports Counter/Decline-Count=
er
through iCalendar.</font><br><br><br><br><table width=3D100%><tr><td><img s=
rc=3Dcid:=5F1=5F08E0484C08E0446400555C9685257355><td width=3D100%><table wi=
dth=3D100%><tr valign=3Dtop><td width=3D100%><font size=3D2 face=3D"sans-se=
rif"><b>Re: [Ietf-calsify] Issue
87: iTIP: DEPRECATE COUNTER/DECLINE-COUNTER</b></font></table><br><table wi=
dth=3D100%><tr><td><font size=3D2 color=3D#e26200 face=3D"sans-serif"><b>Mi=
ke Douglass </b></font><td><font size=3D2 color=3D#8f8f8f face=3D"sans-seri=
f">to:</font><td><font size=3D2 face=3D"sans-serif">ietf-calsify@osafoundat=
ion.org</font><td><div align=3Dright><font size=3D1 face=3D"sans-serif">09/=
13/2007 11:17 AM</font></div></table><br><table width=3D100%><tr><td><table=
 width=3D100%><tr><td><font size=3D2 color=3D#8f8f8f face=3D"sans-serif">Se=
nt by:</font><td width=3D100%><font size=3D2 color=3D#e26200 face=3D"sans-s=
erif"><b>[email-masked]</b></font></table><br><td><=
div align=3Dright></div></table><br></table><br><br><hr><br><br><br><tt><fo=
nt size=3D2>I implemented COUNTER and DECLINE-COUNTER and would
like to see them <br>retained.<br><br>What would you propose as an alternat=
ive?<br><br>The lack of use of some features may be more of a symptom of po=
or <br>interoperability overall than an indication they are not useful.<br>=
<br>Eliot Lear wrote:<br>&gt; [From Cyrus:]<br>&gt;<br>&gt; Its my belief t=
hat COUNTER/DECLINE-COUNTER are rarely used and that
we <br>&gt; can remove them from this revision.<br>&gt;<br>&gt; =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>&gt; Ietf-cals=
ify mailing list<br>&gt; [email-masked]<br>&gt; </font></tt=
><a href=3D"http://lists.osafoundation.org/mailman/listinfo/ietf-calsify"><=
tt><font size=3D2>http://lists.osafoundation.org/mailman/listinfo/ietf-cals=
ify<br>&gt;<br><br>-- <br><br>Mike Douglass &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; [email-masked]<br>Senior Systems Programmer<br>=
Communication &amp; Collaboration Technologies &nbsp; &nbsp; &nbsp;518
276 6780(voice) 2809<br>(fax)<br>Rensselaer Polytechnic Institute 110 8th S=
treet, Troy, NY 12180<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-calsify@osafound=
ation.org<br></font></tt><a href=3D"http://lists.osafoundation.org/mailman/=
listinfo/ietf-calsify"><tt><font size=3D2>http://lists.osafoundation.org/ma=
ilman/listinfo/ietf-calsify<br></font></tt></a></a><br><BR>
--=_alternative 00555C9685257355_=--
--=_related 00555C9685257355_=--

Date: Thu, 13 Sep 2007 11:31:12 -0400
From: Cyrus Daboo <[email-masked]>
To: Robert Ransdell <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
Cc: [email-masked]

Hi Robert,

-- 
Cyrus Daboo

Date: Thu, 13 Sep 2007 11:16:30 -0400
From: Mike Douglass <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 87: iTIP: DEPRECATE COUNTER/DECLINE-COUNTER

I implemented COUNTER and DECLINE-COUNTER and would like to see them 
retained.

What would you propose as an alternative?

The lack of use of some features may be more of a symptom of poor 
interoperability overall than an indication they are not useful.

Eliot Lear wrote:
> [From Cyrus:]
>
> Its my belief that COUNTER/DECLINE-COUNTER are rarely used and that we 
> can remove them from this revision.
>

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
Date: Thu, 13 Sep 2007 10:56:32 -0400
From: "Robert Ransdell" <[email-masked]>
Cc: [email-masked]

--=_related 0052146385257355_=
Content-Type: multipart/alternative;
	boundary="=_alternative 0052146385257355_="

--=_alternative 0052146385257355_=
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

If a event has changed in such a way the chair needs to send a reschedule, =

all existing responses become invalid.  The chair bumps his/her sequence=20
number.  The reschedules are sent out with this new sequence number.  When =

the invitee accepts/declines that seqence number is put on the response.=20
The chair now know who/how each invitee has responded to the reschedule=20
event.

Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE

Cyrus Daboo=20
to:
Robert Ransdell, Eliot Lear
09/13/2007 10:47 AM

Cc:
ietf-calsify

Hi Robert,

> number is not bumped but the DTSTAMP is.

If there is an  expectation of a reply to an update then the ORGANZIER=20
would set PART-STAT back to NEEDS-ACTION and RSVP=3DTRUE. So doesn't that d=
o=20

Plus what are the rules for changing SEQUENCE? Certainly any time change=20
ought to result in it being bumped. But what about LOCATION or TRANSP? Or=20
less obvious ones like SUMMARY or DESCRIPTION (the nature of the event=20
could be totally change by a change in summary or description).

At the end of the day, its really up to the attendee's CUA to determine=20
whether an update to an event is significant enough for that attendee to=20
warrant a potential change in their status.

--=20
Cyrus Daboo

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

<br><font size=3D2 face=3D"sans-serif">If a event has changed in such a way
the chair needs to send a reschedule, all existing responses become invalid.
&nbsp;The chair bumps his/her sequence number. &nbsp;The reschedules are
sent out with this new sequence number. &nbsp;When the invitee accepts/decl=
ines
that seqence number is put on the response. &nbsp;The chair now know who/how
each invitee has responded to the reschedule event.</font><br><br><br><br><=
table width=3D100%><tr><td><img src=3Dcid:=5F1=5F08E2059408E201AC0052146285=
257355><td width=3D100%><table width=3D100%><tr valign=3Dtop><td width=3D10=
0%><font size=3D2 face=3D"sans-serif"><b>Re: [Ietf-calsify] Issue
86: iTIP: DECPRECATE SEQUENCE</b></font></table><br><table width=3D100%><tr=
><td><font size=3D2 color=3D#e26200 face=3D"sans-serif"><b>Cyrus Daboo </b>=
</font><td><font size=3D2 color=3D#8f8f8f face=3D"sans-serif">to:</font><td=
><font size=3D2 face=3D"sans-serif">Robert Ransdell, Eliot Lear</font><td><=
div align=3Dright><font size=3D1 face=3D"sans-serif">09/13/2007 10:47 AM</f=
ont></div></table><br><table width=3D100%><tr><td><table width=3D100%><tr><=
td><font size=3D1 color=3D#8f8f8f face=3D"sans-serif">Cc:</font><td width=
=3D100%><font size=3D1 face=3D"sans-serif">ietf-calsify</font></table><br><=
td><div align=3Dright></div></table><br></table><br><br><hr><br><br><br><tt=
><font size=3D2>Hi Robert,<br><br>--On September 13, 2007 10:27:47 AM -0400=
 Robert Ransdell <br>&lt;Robert=[email-masked]&gt; wrote:<br><=
br>&gt; The difference between a reschedule event and an update event is th=
e<br>&gt; sequence number. &nbsp;That number must be bumped whenever you re=
schedule
an<br>&gt; event. &nbsp;It means that the recipient must re-accept/decline.=
<br>&gt; If chair just sends an update( say just a subject change), &nbsp;t=
he
sequence<br>&gt; number is not bumped but the DTSTAMP is.<br><br>If there i=
s an &nbsp;expectation of a reply to an update then the ORGANZIER
<br>would set PART-STAT back to NEEDS-ACTION and RSVP=3DTRUE. So doesn't th=
at
do <br>the job of telling the attendee that they need to re-consider?<br><b=
r>Plus what are the rules for changing SEQUENCE? Certainly any time change
<br>ought to result in it being bumped. But what about LOCATION or TRANSP?
Or <br>less obvious ones like SUMMARY or DESCRIPTION (the nature of the eve=
nt
<br>could be totally change by a change in summary or description).<br><br>=
At the end of the day, its really up to the attendee's CUA to determine
<br>whether an update to an event is significant enough for that attendee to
<br>warrant a potential change in their status.<br><br>-- <br>Cyrus Daboo<b=
r><br></font></tt><br><BR>
--=_alternative 0052146385257355_=--
--=_related 0052146385257355_=--

Date: Thu, 13 Sep 2007 10:43:26 -0400
From: Cyrus Daboo <[email-masked]>
To: Robert Ransdell <[email-masked]>, Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
Cc: [email-masked]

Hi Robert,

-- 
Cyrus Daboo

To: Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
Date: Thu, 13 Sep 2007 10:27:47 -0400
From: "Robert Ransdell" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, [email-masked]

--=_related 004F72E485257355_=
Content-Type: multipart/alternative;
	boundary="=_alternative 004F72E685257355_="

--=_alternative 004F72E685257355_=
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

No.
The difference between a reschedule event and an update event is the=20
sequence number.  That number must be bumped whenever you reschedule an=20
event.  It means that the recipient must re-accept/decline.
If chair just sends an update( say just a subject change),  the sequence=20
number is not bumped but the DTSTAMP is.

[Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE

Eliot Lear=20
to:
[email-masked]
09/13/2007 10:22 AM

Sent by:
[email-masked]

However as a change indicator there is already a requirement that attendee =

CUAs=20
have to spot significant changes that are relevant to their calendar user, =

so=20

At the very least if we choose not to do that, we should be much more=20
explicit=20
about when SEQUENCE is supposed to change (e.g. ORGANIZER MUST change=20
SEQUENCE=20
for these things (...) and SHOULD change SEQUENCE for these things (...)=20
under=20
certain circumstances.
=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 004F72E685257355_=
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<br><font size=3D2 face=3D"sans-serif">No.</font><br><font size=3D2 face=3D=
"sans-serif">The difference between a reschedule
event and an update event is the sequence number. &nbsp;That number must
be bumped whenever you reschedule an event. &nbsp;It means that the recipie=
nt
must re-accept/decline.</font><br><font size=3D2 face=3D"sans-serif">If cha=
ir just sends an update( say just
a subject change), &nbsp;the sequence number is not bumped but the DTSTAMP
is.</font><br><br><br><br><br><table width=3D100%><tr><td><img src=3Dcid:=
=5F1=5F06EC7DD406EC79EC004F72E185257355><td width=3D100%><table width=3D100=
%><tr valign=3Dtop><td width=3D100%><font size=3D2 face=3D"sans-serif"><b>[=
Ietf-calsify] Issue 86:
iTIP: DECPRECATE SEQUENCE</b></font></table><br><table width=3D100%><tr><td=
><font size=3D2 color=3D#e26200 face=3D"sans-serif"><b>Eliot Lear </b></fon=
t><td><font size=3D2 color=3D#8f8f8f face=3D"sans-serif">to:</font><td><fon=
t size=3D2 face=3D"sans-serif">[email-masked]</font><td><di=
v align=3Dright><font size=3D1 face=3D"sans-serif">09/13/2007 10:22 AM</fon=
t></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 widt=
h=3D100%><font size=3D2 color=3D#e26200 face=3D"sans-serif"><b>ietf-calsify=
[email-masked]</b></font></table><br><td><div align=3Dright></d=
iv></table><br></table><br><br><hr><br><br><br><tt><font size=3D2>SEQUENCE =
is used as a synchronization aid and as a
change indicator.<br><br>However as a synchronization aid we already have D=
TSTAMP.<br><br>However as a change indicator there is already a requirement=
 that attendee
CUAs <br>have to spot significant changes that are relevant to their calend=
ar user,
so <br>SEQUENCE is not important.<br><br>Proposal: deprecate use of SEQUENC=
E.<br><br>At the very least if we choose not to do that, we should be much =
more explicit
<br>about when SEQUENCE is supposed to change (e.g. ORGANIZER MUST change S=
EQUENCE
<br>for these things (...) and SHOULD change SEQUENCE for these things (...)
under <br>certain circumstances.<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-calsify@os=
afoundation.org<br></font></tt><a href=3D"http://lists.osafoundation.org/ma=
ilman/listinfo/ietf-calsify"><tt><font size=3D2>http://lists.osafoundation.=
org/mailman/listinfo/ietf-calsify<br></font></tt></a><br><BR>
--=_alternative 004F72E685257355_=--
--=_related 004F72E485257355_=--

Date: Thu, 13 Sep 2007 16:24:13 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Issue 91: iTIP: VFREEBUSY reply does not allow zero FREEBUSY properties

[From Cyrus:]

The restriction table of the VFREEBUSY reply method has FREEBUSY 1+. But its quite 
possible to have a free-busy response where there is no busy time being indicated.

Proposal: fix the table to use FREEBUSY 0+.

Date: Thu, 13 Sep 2007 16:23:21 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Issue 90: iTIP: better guidance to CUAs on how to handle ADD/CANCEL

[From Cyrus:]

Currently there is little explanation as to what exactly should happen to a 
local event when a CANCEL or ADD is received - at least in terms of changes to 
iCalendar data. We should clarify this behavior:

ADD - insert the new component into the recurrence set by adding an RDATE to the 
"master" component, and adding a RECURRENCE-ID to the new component and catenate 
the new component into the "master" set.

CANCEL - add an EXDATE into the "master" component corresponding to the 
RECURRENCE-ID specified in the cancelled component. If there is an overridden 
component for that RECURRENCE-ID, remove that component from the "master" set.

Date: Thu, 13 Sep 2007 16:22:13 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Issue 89: ADD description misleading

[From Cyrus:]

The description for the ADD method implies it can be used to modify existing 
instances, but that is wrong. Its intent is to only allow new instances to be 
added to a recurrence set (i.e. addition of RDATE's). Description text must be 
clarified.

Date: Thu, 13 Sep 2007 16:21:04 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Issue 88: iTIP: CANCEL definition

[From Cyrus:]

The description for each CANCEL method describes how to cancel a range of 
meetings. Since RANGE= is no longer supported that mode of operation is out. The 
alternative is to send multiple RECURRENCE-IDs. However, 2445(bis) only allows a 
single RECURRENCE-ID per component. We need to fix the current texts to state that 
multiple components, one per recurrence instance being cancelled, have to be sent.

Date: Thu, 13 Sep 2007 16:19:54 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Issue 87: iTIP: DEPRECATE COUNTER/DECLINE-COUNTER

[From Cyrus:]

Its my belief that COUNTER/DECLINE-COUNTER are rarely used and that we can remove 
them from this revision.

Date: Thu, 13 Sep 2007 16:19:02 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE

Date: Thu, 13 Sep 2007 16:17:20 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Issue 85: iTIP: No more RANGE=

[Cyrus posted these right into the tracker.]

The RANGE= parameter has been removed in 2445bis, but iTIP has dependencies on it.

We need to update iTIP to remove all dependencies on RANGE= and explain an 
alternative method to achieve the same result.

Date: Thu, 13 Sep 2007 16:15:52 +0200
From: Eliot Lear <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] iTIP issues in tracker
Cc: Calsify WG <[email-masked]>

Cyrus,

Thanks for these.  I will post these issues separately in short order.

Eliot
> Hi folks,
> I have added a bunch of issue to the tracker relating to the iTIP 
> revision:
>
> 85: iTIP: No more RANGE=
> 86: iTIP: SEQUENCE
> 87: iTIP: COUNTER/DECLINE-COUNTER
> 88: iTIP: CANCEL definition
> 89: iTIP: ADD description misleading
> 90: iTIP: better guidance to CUAs on how to handle ADD/CANCEL
> 91: iTIP: VFREEBUSY reply does not allow zero FREEBUSY properties
>
> These are all open for discussion. Some contain proposals from me on 
> how to fix (mostly the trivials ones). Some are controversial so 
> please comment as we need feedback from implementers on all this.
>
>

Date: Thu, 13 Sep 2007 10:08:35 -0400
From: Cyrus Daboo <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] iTIP issues in tracker

Hi folks,
I have added a bunch of issue to the tracker relating to the iTIP revision:

85: iTIP: No more RANGE=
86: iTIP: SEQUENCE
87: iTIP: COUNTER/DECLINE-COUNTER
88: iTIP: CANCEL definition
89: iTIP: ADD description misleading
90: iTIP: better guidance to CUAs on how to handle ADD/CANCEL
91: iTIP: VFREEBUSY reply does not allow zero FREEBUSY properties

These are all open for discussion. Some contain proposals from me on how to 
fix (mostly the trivials ones). Some are controversial so please comment as 
we need feedback from implementers on all this.

-- 
Cyrus Daboo

Date: Thu, 13 Sep 2007 15:49:28 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] jabber in 10 minutes...

See you then!

Eliot

Date: Tue, 11 Sep 2007 08:12:06 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] [Fwd: Nomcom 2007-8: Nominations Deadline Extended to Sep 17, 2007]

This is a multi-part message in MIME format.
--------------060604060107040802090800
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Dear All,

The IETF process demands participation.  Part of that means identifying 
potential leaders within and even outside of the organization.  Please 
help by nominating those who you believe would serve well as stewards 
and leaders for the various positions that are open this round (one in 
each area on the IESG, several IAB positions, and an IAOC position).

Eliot

--------------060604060107040802090800
Content-Type: message/rfc822;
	name="Nomcom 2007-8: Nominations Deadline Extended to Sep 17, 2007.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
	filename*0="Nomcom 2007-8: Nominations Deadline Extended to Sep 17,
	2007"; filename*1=".eml"

Date: Mon, 10 Sep 2007 22:47:46 -0700
From: Lakshminath Dondeti <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Nomcom 2007-8: Nominations Deadline Extended to Sep 17, 2007

Folks,

Many of you responded well to the reminder calls for nominations sent 
recently.  There was also an up-tick in the nominations acceptances as 
well (in some cases).  The nomcom appreciates the community's response 
very much.

However, we are still short in a few areas; at the moment, we have the 
following numbers of nominations: 3 4 4 6 6 10 12 21 44 (some of these 
folks have already rejected the nominations; I haven't had the time to 
update the numbers yet).

The numbers on acceptances are still *very* low; in 3 (or may be 4) 
areas, we have only ONE candidate so far.

In the discussions on this topic, it was argued that folks may be still 
returning from their summer vacations.  Some candidates have hinted that 
it may take some more time to get the necessary approvals.  Keeping 
those considerations in mind, I am extending the nominations deadline to 
Sep 17, 2007 AOE.  Candidates are requested to consider the chance to 
serve the IETF and accept the nominations.  The questionnaires are now 
due Sep 24, 2007 AOE.

Here is the link to nominate: 
https://tools.ietf.org/group/nomcom/07/nominate
You may also send nominations or comments via email to [email-masked] 
or [email-masked].

thanks,
Lakshminath

--------------060604060107040802090800--

To: CALSIFY Mailinglist <[email-masked]>
From: Eliot Lear <[email-masked]>
Date: Mon, 10 Sep 2007 12:59:38 +0200
Subject: [Ietf-calsify] iCal event invitation: IETF Calsify Jabber Session

--Apple-Mail-1-661381474
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Eliot Lear has invited you to the iCal event: IETF Calsify Jabber  
Session, scheduled for September 13, 2007 at 4:00 PM (Europe/Zurich).  
To accept or decline this invitation, click the link below.

--Apple-Mail-1-661381474
Content-Transfer-Encoding: quoted-printable
Content-Type: text/calendar; x-unix-mode=0644; name=iCal-20070910-125933.ics
Content-Disposition: attachment;
	filename=iCal-20070910-125933.ics

BEGIN:VCALENDAR=0D=0APRODID:-//Apple=20Computer\,=20Inc//iCal=202.0//EN=0D=
=0AMETHOD:REQUEST=0D=0ACALSCALE:GREGORIAN=0D=0AVERSION:2.0=0D=0A=
BEGIN:VTIMEZONE=0D=0ATZID:Europe/Zurich=0D=0A=
LAST-MODIFIED:20070910T105933Z=0D=0ABEGIN:DAYLIGHT=0D=0A=
DTSTART:20070325T010000=0D=0ATZOFFSETTO:+0200=0D=0ATZOFFSETFROM:+0000=0D=0A=
TZNAME:CEST=0D=0AEND:DAYLIGHT=0D=0ABEGIN:STANDARD=0D=0A=
DTSTART:20071028T030000=0D=0ATZOFFSETTO:+0100=0D=0ATZOFFSETFROM:+0200=0D=0A=
TZNAME:CET=0D=0AEND:STANDARD=0D=0AEND:VTIMEZONE=0D=0ABEGIN:VEVENT=0D=0A=
ATTENDEE;CN=3D"CALSIFY=20=
Mailinglist";RSVP=3DTRUE:mailto:Ietf-calsify@osafound=0D=0A=20ation.org=0D=
=0ALOCATION:[email-masked]=0D=0ADTSTAMP:20070910T105927Z=0D=0A=
UID:2C717D30-AF16-4188-B23D-F914DB049DA9=0D=0ASEQUENCE:9=0D=0A=
DTSTART;TZID=3DEurope/Zurich:20070913T160000=0D=0ASUMMARY:IETF=20Calsify=20=
Jabber=20Session=0D=0ADTEND;TZID=3DEurope/Zurich:20070913T170000=0D=0A=
DESCRIPTION:Agenda:\n\nRFC=202446bis\n=0D=0AORGANIZER;CN=3D"Eliot=20=
Lear":mailto:[email-masked]=0D=0AEND:VEVENT=0D=0AEND:VCALENDAR=0D=0A=

--Apple-Mail-1-661381474--

Date: Mon, 10 Sep 2007 12:57:05 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] jabber sessions to start again this thursday

4:00pm.  The primary topic is expected to be RFC2446bis.

Regards,

Eliot