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

[Bruce_Kahn at notesdev.ibm.com (Bruce Kahn)]

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

> SEQUENCE is used as a synchronization aid and as a change indicator.
> 
> 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 
> 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.

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: 
[e-mail]
Messaging & Collaboration                 Phone: [phone]
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  Fri Sep 28 14:47:32 2007
From: Bruce_Kahn at notesdev.ibm.com (Bruce Kahn)
Date: Fri Sep 28 14:48:25 2007
Subject: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
In-Reply-To: <[e-mail]>
References: <OFA93C8135.6C898380-ON85257355.005210FD-85257355.0052146A@LocalDomain>
	<[e-mail]>
Message-ID: <OF9FDFAF74.6A90A4B2-ON85257364.0075295C-85257364.0077B0E8@LocalDomain>

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

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

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
===========================================================================
Bruce Kahn                                INet: 
[e-mail]
Messaging & Collaboration                 Phone: [phone]
IBM Software Group                         FAX: and nothing but the FAX...
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

Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D975980A0F for <[e-mail]>; Fri, 28 Sep 2007 14:48:24 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 00DAE14220F for <[e-mail]>; Fri, 28 Sep 2007 14:47:30 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.537
X-Spam-Level: 
X-Spam-Status: No, score=-1.537 tagged_above=-50 required=4 tests=[AWL=0.862,  BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, HTML_MESSAGE=0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYgfAaEB+7C6 for <[e-mail]>; Fri, 28 Sep 2007 14:47:23 -0700 (PDT)
Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by laweleka.osafoundation.org (Postfix) with ESMTP id 66404142204 for <[e-mail]>; Fri, 28 Sep 2007 14:47:23 -0700 (PDT)
In-Reply-To: <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
Message-ID: <OF9FDFAF74.6A90A4B2-ON85257364.0075295C-85257364.0077B0E8@LocalDomain>
Date: Fri, 28 Sep 2007 17:47:32 -0400
From: "Bruce Kahn" <[e-mail]>
Content-Type: multipart/alternative; boundary="=_alternative 007714C385257364_="
References: <OFA93C8135.6C898380-ON85257355.005210FD-85257355.0052146A@LocalDomain> <[e-mail]>
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V85_09092007NP September 09, 2007
X-Disclaimed: 41999
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 28 Sep 2007 21:48:25 -0000

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

Cyrus Daboo <[e-mail]> 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=[e-mail]
Messaging & Collaboration                 Phone: [phone]
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;[e-mail]&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: [phone]<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_=--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E75737FFC4 for <[e-mail]>; Fri, 28 Sep 2007 14:21:10 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0FDA614220F for <[e-mail]>; Fri, 28 Sep 2007 14:20:16 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -0.675
X-Spam-Level: 
X-Spam-Status: No, score=-0.675 tagged_above=-50 required=4 tests=[AWL=1.923,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Cllf6YWMC8f for <[e-mail]>; Fri, 28 Sep 2007 14:20:09 -0700 (PDT)
Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1D10C1421FD for <[e-mail]>; Fri, 28 Sep 2007 14:20:09 -0700 (PDT)
In-Reply-To: <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
Message-ID: <OF5F4BF1CE.91046888-ON85257364.00733074-85257364.00753261@LocalDomain>
Date: Fri, 28 Sep 2007 17:20:17 -0400
From: "Bruce Kahn" <[e-mail]>
Content-Type: multipart/alternative; boundary="=_alternative 0075082385257364_="
References: <[e-mail]>
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V85_09092007NP September 09, 2007
X-Disclaimed: 18131
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 28 Sep 2007 21:21:11 -0000

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

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

> SEQUENCE is used as a synchronization aid and as a change indicator.
>=20
> 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=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 =

actions in reverse order than I actually did.

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

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

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=[e-mail]
Messaging & Collaboration                 Phone: [phone]
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;[e-mail]&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: [phone]<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_=--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id BEBB880A38 for <[e-mail]>; Fri, 28 Sep 2007 12:04:55 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DBDC314220F for <[e-mail]>; Fri, 28 Sep 2007 12:04:00 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.424
X-Spam-Level: 
X-Spam-Status: No, score=-2.424 tagged_above=-50 required=4 tests=[AWL=0.175,  BAYES_00=-2.599]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAeJAEbh8QDg for <[e-mail]>; Fri, 28 Sep 2007 12:03:52 -0700 (PDT)
Received: from mulberrymail.com (piper.mulberrymail.com [151.201.22.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id DF5AD14220C for <[e-mail]>; Fri, 28 Sep 2007 12:03:51 -0700 (PDT)
Received: from caldav.corp.apple.com ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l8SJ3g4q008782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Sep 2007 15:03:47 -0400
Date: Fri, 28 Sep 2007 15:03:36 -0400
From: Cyrus Daboo <[e-mail]>
To: Ciny Joy <[e-mail]>, [e-mail]
Subject: Re: [Ietf-calsify] Re: Ietf-calsify Digest, Vol 38, Issue 10
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 28 Sep 2007 19:04:55 -0000

Hi Ciny,

--On September 28, 2007 11:46:53 AM -0700 Ciny Joy <[e-mail]> 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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4A25B8061D for <[e-mail]>; Fri, 28 Sep 2007 11:47:56 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 65298142212 for <[e-mail]>; Fri, 28 Sep 2007 11:47:01 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.299
X-Spam-Level: 
X-Spam-Status: No, score=-1.299 tagged_above=-50 required=4 tests=[AWL=1.298,  BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9CQEwnGzlRx for <[e-mail]>; Fri, 28 Sep 2007 11:46:52 -0700 (PDT)
Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 84B58142209 for <[e-mail]>; Fri, 28 Sep 2007 11:46:52 -0700 (PDT)
Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l8SIkqqg016169 for <[e-mail]>; Fri, 28 Sep 2007 11:46:52 -0700 (PDT)
Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Fri, 28 Sep 2007 11:46:52 -0700 (PDT)
Received: from [129.150.16.201] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <[e-mail]> for [e-mail]; Fri, 28 Sep 2007 11:46:51 -0700 (PDT)
Date: Fri, 28 Sep 2007 11:46:53 -0700
From: Ciny Joy <[e-mail]>
In-reply-to: <[e-mail]>
Sender: [e-mail]
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_Cvq3+VEg/dLKrQu15YVKiQ)"
References: <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
Subject: [Ietf-calsify] Re: Ietf-calsify Digest, Vol 38, Issue 10
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 28 Sep 2007 18:47:56 -0000

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

[e-mail] wrote:
> Send Ietf-calsify mailing list submissions to
> 	[e-mail]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> or, via email, send a message with subject or body 'help' to
> 	[e-mail]
>
> You can reach the person managing the list at
> 	[e-mail]
>
> 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 <[e-mail]>
> Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
> To: [e-mail]
> Message-ID: <[e-mail]>
> Content-Type: text/plain;  charset="ansi_x3.4-1968"
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am Montag, 17. September 2007 schrieb Tim Hare:
>   
>> 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. 
>>     
>
> 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:
>    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.
>
> 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:
>       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.
>
> 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: [e-mail], 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/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFG7tuwTqjEwhXvPN0RAlm0AJ930xifJmWyss5SYLyPDBCYVuR0mgCeMwoT
> hTEwqIdhhNvLnFkGADqSyjo=
> =eXpA
> -----END PGP SIGNATURE-----
>
>
> ------------------------------
>
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>
> 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:[e-mail]">[e-mail]</a> wrote:
<blockquote
 cite="mid:[e-mail]"
 type="cite">
  <pre wrap="">Send Ietf-calsify mailing list submissions to
	<a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</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:[e-mail]">[e-mail]</a>

You can reach the person managing the list at
	<a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</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:[e-mail]">&lt;[e-mail]&gt;</a>
Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
To: <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
Message-ID: <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">&lt;[e-mail]&gt;</a>
Content-Type: text/plain;  charset="ansi_x3.4-1968"

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Montag, 17. September 2007 schrieb Tim Hare:
  </pre>
  <blockquote type="cite">
    <pre wrap="">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. 
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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:
   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.

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

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: <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</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>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFG7tuwTqjEwhXvPN0RAlm0AJ930xifJmWyss5SYLyPDBCYVuR0mgCeMwoT
hTEwqIdhhNvLnFkGADqSyjo=
=eXpA
-----END PGP SIGNATURE-----


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

_______________________________________________
Ietf-calsify mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</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)--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id CDB0C8095F for <[e-mail]>; Fri, 28 Sep 2007 04:36:17 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E9C5D142203 for <[e-mail]>; Fri, 28 Sep 2007 04:35:22 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 tagged_above=-50 required=4 tests=[AWL=0.576,  BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDrzzp8pg5Dw for <[e-mail]>; Fri, 28 Sep 2007 04:35:16 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 64A6D14220C for <[e-mail]>; Fri, 28 Sep 2007 04:35:16 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.21,209,1188770400"; d="scan'208";a="154409560"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 28 Sep 2007 13:35:15 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8SBZFT1032299 for <[e-mail]>; Fri, 28 Sep 2007 13:35:15 +0200
Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp4294.cisco.com [10.61.80.197]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8SBZEWo029139 for <[e-mail]>; Fri, 28 Sep 2007 11:35:15 GMT
Message-ID: <[e-mail]>
Date: Fri, 28 Sep 2007 13:34:54 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=203; t=1190979315; x=1191843315; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20we=20need=20a=20new=20jabber=20time |Sender:=20; bh=ehyzrdnuT41aEdebqvtFuevoH0dmwltTgIqgiQolgiY=; b=Dk6sEPTNZ+OTDtvlXQRil2BUXwWE9nKuR4IAU7ELG2mYGVZEMdGeFCa71x3CAHKyZooacfJ7 GdILR1dUbMeUImFpZQPoHf/KQutkfddGIfCFzLds7IvvasM24mlYIRt8;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); 
Subject: [Ietf-calsify] we need a new jabber time
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 28 Sep 2007 11:36:18 -0000

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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 932D0808F6 for <[e-mail]>; Thu, 27 Sep 2007 11:25:23 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B05B0142207 for <[e-mail]>; Thu, 27 Sep 2007 11:24:28 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.256
X-Spam-Level: 
X-Spam-Status: No, score=-1.256 tagged_above=-50 required=4 tests=[AWL=1.344,  BAYES_00=-2.599, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uh28ckTZB6zr for <[e-mail]>; Thu, 27 Sep 2007 11:24:22 -0700 (PDT)
Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 0ADB5142203 for <[e-mail]>; Thu, 27 Sep 2007 11:24:21 -0700 (PDT)
Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.13.6/8.13.6) with ESMTP id l8RIOG7i061190; Thu, 27 Sep 2007 14:24:16 -0400 (EDT) (envelope-from [e-mail])
Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.13.6/8.13.6/Submit) id l8RIO8VV061171; Thu, 27 Sep 2007 14:24:08 -0400 (EDT) (envelope-from lennox)
From: Jonathan Lennox <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Thu, 27 Sep 2007 14:24:07 -0400
To: Cyrus Daboo <[e-mail]>
Subject: Re: [Ietf-calsify] Reminder: WGLC for draft-ietf-calsify-rfc2445bis-07	ends TODAY
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.19 under Emacs 22.1.1
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 27 Sep 2007 18:25:24 -0000

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

> Hi Jonathan,
> 
> --On August 13, 2007 11:56:40 AM -0400 Jonathan Lennox 
> <[e-mail]> 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
[e-mail]


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 03D528087D for <[e-mail]>; Thu, 27 Sep 2007 10:06:54 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 21206142206 for <[e-mail]>; Thu, 27 Sep 2007 10:05:59 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.243
X-Spam-Level: 
X-Spam-Status: No, score=-2.243 tagged_above=-50 required=4 tests=[AWL=0.355,  BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id najzRij5DY9c for <[e-mail]>; Thu, 27 Sep 2007 10:05:52 -0700 (PDT)
Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B73E41421F1 for <[e-mail]>; Thu, 27 Sep 2007 10:05:52 -0700 (PDT)
Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l8RH5hJh014891; Thu, 27 Sep 2007 11:05:43 -0600
Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l8RGvWfW004380; Thu, 27 Sep 2007 11:05:40 -0600
Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3249557811190912720; Thu, 27 Sep 2007 10:05:20 -0700
Received: from [10.156.42.83] (/10.156.42.83) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 27 Sep 2007 10:05:20 -0700
Message-ID: <[e-mail]>
Date: Thu, 27 Sep 2007 13:05:04 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: [Ietf-calsify] One last comment on exact vs. nominal durations
References: <[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
X-Whitelist: TRUE
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 27 Sep 2007 17:06:54 -0000

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
>> _______________________________________________
>> Ietf-calsify mailing list
>> [e-mail]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>>
> 
> 



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 50B8E80A3A for <[e-mail]>; Thu, 27 Sep 2007 08:22:25 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6F5A3142215 for <[e-mail]>; Thu, 27 Sep 2007 08:21:30 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.417
X-Spam-Level: 
X-Spam-Status: No, score=-2.417 tagged_above=-50 required=4 tests=[AWL=0.182,  BAYES_00=-2.599]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYzUjqZ5Wwnb for <[e-mail]>; Thu, 27 Sep 2007 08:21:20 -0700 (PDT)
Received: from mulberrymail.com (piper.mulberrymail.com [151.201.22.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C2B7D142229 for <[e-mail]>; Thu, 27 Sep 2007 08:21:19 -0700 (PDT)
Received: from caldav.corp.apple.com ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l8RFKKeK025060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Sep 2007 11:20:22 -0400
Date: Thu, 27 Sep 2007 11:20:14 -0400
From: Cyrus Daboo <[e-mail]>
To: Bernard Desruisseaux <[e-mail]>
Subject: Re: [Ietf-calsify] Reminder: WGLC for draft-ietf-calsify-rfc2445bis-07 ends TODAY
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 27 Sep 2007 15:22:25 -0000

Hi Bernard,

--On September 27, 2007 11:12:32 AM -0400 Bernard Desruisseaux 
<[e-mail]> 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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id CC2C380A25 for <[e-mail]>; Thu, 27 Sep 2007 08:15:28 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id EA58E142224 for <[e-mail]>; Thu, 27 Sep 2007 08:14:33 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.238
X-Spam-Level: 
X-Spam-Status: No, score=-2.238 tagged_above=-50 required=4 tests=[AWL=0.360,  BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ieF4pmah2eW for <[e-mail]>; Thu, 27 Sep 2007 08:14:27 -0700 (PDT)
Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 97C90142215 for <[e-mail]>; Thu, 27 Sep 2007 08:14:27 -0700 (PDT)
Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l8RFDJoD013985; Thu, 27 Sep 2007 09:13:20 -0600
Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l8RE9Dp4004286; Thu, 27 Sep 2007 09:13:17 -0600
Received: from inet-141-146-46-1.oracle.com by acsmt351.oracle.com with ESMTP id 3249867121190905969; Thu, 27 Sep 2007 08:12:49 -0700
Received: from [10.156.42.83] (/10.156.42.83) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 27 Sep 2007 08:12:49 -0700
Message-ID: <[e-mail]>
Date: Thu, 27 Sep 2007 11:12:32 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Cyrus Daboo <[e-mail]>
Subject: Re: [Ietf-calsify] Reminder: WGLC for draft-ietf-calsify-rfc2445bis-07 ends TODAY
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
X-Whitelist: TRUE
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 27 Sep 2007 15:15:29 -0000

Cyrus Daboo wrote:
> Hi Jonathan,
> 
> --On August 13, 2007 11:56:40 AM -0400 Jonathan Lennox 
> <[e-mail]> 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





Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3332C7FCCF for <[e-mail]>; Thu, 27 Sep 2007 08:07:34 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 51ED41421FF for <[e-mail]>; Thu, 27 Sep 2007 08:06:39 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.415
X-Spam-Level: 
X-Spam-Status: No, score=-2.415 tagged_above=-50 required=4 tests=[AWL=0.184,  BAYES_00=-2.599]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUwIFp6OMVH0 for <[e-mail]>; Thu, 27 Sep 2007 08:06:32 -0700 (PDT)
Received: from mulberrymail.com (piper.mulberrymail.com [151.201.22.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id ABFBF142215 for <[e-mail]>; Thu, 27 Sep 2007 08:06:32 -0700 (PDT)
Received: from caldav.corp.apple.com ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l8RF60af024867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Sep 2007 11:06:03 -0400
Date: Thu, 27 Sep 2007 11:05:55 -0400
From: Cyrus Daboo <[e-mail]>
To: Jonathan Lennox <[e-mail]>, [e-mail]
Subject: Re: [Ietf-calsify] Reminder: WGLC for draft-ietf-calsify-rfc2445bis-07	ends TODAY
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 27 Sep 2007 15:07:34 -0000

Hi Jonathan,

--On August 13, 2007 11:56:40 AM -0400 Jonathan Lennox 
<[e-mail]> 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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 23FA680A03 for <[e-mail]>; Thu, 27 Sep 2007 07:56:58 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4321C14222C for <[e-mail]>; Thu, 27 Sep 2007 07:56:03 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.886
X-Spam-Level: 
X-Spam-Status: No, score=-1.886 tagged_above=-50 required=4 tests=[AWL=0.579,  BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HN11qtmw-zzZ for <[e-mail]>; Thu, 27 Sep 2007 07:55:51 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id EF60B142229 for <[e-mail]>; Thu, 27 Sep 2007 07:55:50 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.21,204,1188770400"; d="scan'208";a="154331060"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 27 Sep 2007 16:55:49 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8REtndp012699;  Thu, 27 Sep 2007 16:55:49 +0200
Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp673.cisco.com [10.61.66.161]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8REtmWo011756;  Thu, 27 Sep 2007 14:55:48 GMT
Message-ID: <[e-mail]>
Date: Thu, 27 Sep 2007 16:55:25 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: Nigel Swinson <[e-mail]>
Subject: Re: [Ietf-calsify] working group last call commentsfor draft-ietf-calsify-rfc2445bis-07.txt
References: <[e-mail]> <[e-mail]> <01b001c7fc6a$a15bf640$6401a8c0@nigelhome>
In-Reply-To: <01b001c7fc6a$a15bf640$6401a8c0@nigelhome>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11232; t=1190904949; x=1191768949; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20Re=3A=20[Ietf-calsify]=20working=20group=20last=20call=20comm entsfor=20draft-ietf-calsify-rfc2445bis-07.txt |Sender:=20; bh=VbR4sMRscXb8xnYl51aM7OTHxhkVKu0iPrNmfWfwOvM=; b=TzeUxmpYGI7jgbeWwsHnn2ApLvlLKY7pBP3TPQMkP9mHaMQOgwo8Onh/FLKFNVbq1oMM74ix 1+O5Pdq6Xt3M4GtenmZBbA9x8CP/tlv4e5OV3ns0EqyMVsODoJmI40Iz;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); 
Cc: CALSIFY Mailinglist <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 27 Sep 2007 14:56:58 -0000

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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 0B288806F7 for <[e-mail]>; Thu, 27 Sep 2007 06:31:10 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 117931421FF for <[e-mail]>; Thu, 27 Sep 2007 06:30:15 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.882
X-Spam-Level: 
X-Spam-Status: No, score=-1.882 tagged_above=-50 required=4 tests=[AWL=0.583,  BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvATl4fgf5p9 for <[e-mail]>; Thu, 27 Sep 2007 06:30:08 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 876491421FC for <[e-mail]>; Thu, 27 Sep 2007 06:30:08 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.21,203,1188770400"; d="scan'208";a="154319316"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 27 Sep 2007 15:30:07 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8RDU73e001930 for <[e-mail]>; Thu, 27 Sep 2007 15:30:07 +0200
Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp673.cisco.com [10.61.66.161]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8RDU6Wo004324 for <[e-mail]>; Thu, 27 Sep 2007 13:30:07 GMT
Message-ID: <[e-mail]>
Date: Thu, 27 Sep 2007 15:29:44 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=87; t=1190899807; x=1191763807; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20jabber=20session=20in=201/2=20hour |Sender:=20; bh=gZZTQPVsXsd6Z9c6CfWr1YBEcza5tHXtlJGXLvjia6o=; b=vS+fO5NrRsX/SIU7IRuLZilFp27ukfU0SMakUFUanad/358TPXWAt9WfD0CIWptJD14q2Pac 4rcjJwjbfFcTJmPffgi323veP1e85xYQlOugZLb/Ee6ZL3POCrUATDZY;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); 
Subject: [Ietf-calsify] jabber session in 1/2 hour
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 27 Sep 2007 13:31:10 -0000

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

Thanks,

Eliot


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9007A80902 for <[e-mail]>; Mon, 24 Sep 2007 07:09:31 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id AE817142228 for <[e-mail]>; Mon, 24 Sep 2007 07:08:36 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.412
X-Spam-Level: 
X-Spam-Status: No, score=-2.412 tagged_above=-50 required=4 tests=[AWL=0.187,  BAYES_00=-2.599]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X79knapRtnIh for <[e-mail]>; Mon, 24 Sep 2007 07:07:41 -0700 (PDT)
Received: from mulberrymail.com (piper.mulberrymail.com [151.201.22.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D38E0142211 for <[e-mail]>; Mon, 24 Sep 2007 07:07:40 -0700 (PDT)
Received: from caldav.corp.apple.com ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l8OE77Ix018968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Sep 2007 10:07:09 -0400
Date: Mon, 24 Sep 2007 09:42:49 -0400
From: Cyrus Daboo <[e-mail]>
To: Bernard Desruisseaux <[e-mail]>
Subject: Re: [Ietf-calsify] IANA registrations for "sub-components"
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: Calsify <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 24 Sep 2007 14:09:31 -0000

Hi Bernard,

--On September 24, 2007 9:40:48 AM -0400 Bernard Desruisseaux 
<[e-mail]> 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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9448D80898 for <[e-mail]>; Mon, 24 Sep 2007 06:42:15 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B3862142228 for <[e-mail]>; Mon, 24 Sep 2007 06:41:20 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.218
X-Spam-Level: 
X-Spam-Status: No, score=-2.218 tagged_above=-50 required=4 tests=[AWL=0.380,  BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Qc3QaLVEiuw for <[e-mail]>; Mon, 24 Sep 2007 06:41:14 -0700 (PDT)
Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 65E8C142211 for <[e-mail]>; Mon, 24 Sep 2007 06:41:14 -0700 (PDT)
Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l8ODexvH006991; Mon, 24 Sep 2007 07:41:01 -0600
Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l8ODcBaB019942; Mon, 24 Sep 2007 07:40:58 -0600
Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3238744701190641249; Mon, 24 Sep 2007 06:40:49 -0700
Received: from [10.156.42.83] (/10.156.42.83) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 24 Sep 2007 06:40:49 -0700
Message-ID: <[e-mail]>
Date: Mon, 24 Sep 2007 09:40:48 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Cyrus Daboo <[e-mail]>
Subject: Re: [Ietf-calsify] IANA registrations for "sub-components"
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
X-Whitelist: TRUE
Cc: Calsify <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 24 Sep 2007 13:42:15 -0000

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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 43C2380A1A for <[e-mail]>; Fri, 21 Sep 2007 19:55:54 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6864C14220C for <[e-mail]>; Fri, 21 Sep 2007 19:54:59 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.347
X-Spam-Level: 
X-Spam-Status: No, score=-2.347 tagged_above=-50 required=4 tests=[AWL=0.117,  BAYES_00=-2.599, FORGED_RCVD_HELO=0.135]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZPHOz19XLjT for <[e-mail]>; Fri, 21 Sep 2007 19:54:54 -0700 (PDT)
Received: from mulberrymail.com (piper.mulberrymail.com [151.201.22.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id A4F40142207 for <[e-mail]>; Fri, 21 Sep 2007 19:54:54 -0700 (PDT)
Received: from MACLAURIN-FOUR-THIRTY-THREE.MIT.EDU (piper.mulberrymail.com [151.201.22.177] (may be forged)) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l8M2sn8h022271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 21 Sep 2007 22:54:50 -0400
Date: Fri, 21 Sep 2007 22:54:48 -0400
From: Cyrus Daboo <[e-mail]>
To: Calsify <[e-mail]>
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: [Ietf-calsify] IANA registrations for "sub-components"
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 22 Sep 2007 02:55:54 -0000

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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E920C8086A for <[e-mail]>; Thu, 20 Sep 2007 23:23:02 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1B3EC142209 for <[e-mail]>; Thu, 20 Sep 2007 23:22:08 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.672
X-Spam-Level: 
X-Spam-Status: No, score=-1.672 tagged_above=-50 required=4 tests=[AWL=0.927,  BAYES_00=-2.599]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9oRp19s14MA for <[e-mail]>; Thu, 20 Sep 2007 23:22:04 -0700 (PDT)
Received: from mgw-ext12.nokia.com (smtp.nokia.com [131.228.20.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 7D5F2142207 for <[e-mail]>; Thu, 20 Sep 2007 23:22:04 -0700 (PDT)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8L6LmEf022875; Fri, 21 Sep 2007 09:21:59 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 21 Sep 2007 09:21:35 +0300
Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Sep 2007 09:21:35 +0300
Received: from [172.21.41.182] (esdhcp041182.research.nokia.com [172.21.41.182]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8L6LVQ5001434; Fri, 21 Sep 2007 09:21:33 +0300
Message-ID: <[e-mail]>
Date: Fri, 21 Sep 2007 09:21:28 +0300
From: Aki Niemi <[e-mail]>
User-Agent: Thunderbird 1.5.0.13 (X11/20070824)
MIME-Version: 1.0
To: [e-mail]
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Sep 2007 06:21:35.0446 (UTC) FILETIME=[A9140F60:01C7FC17]
X-Nokia-AV: Clean
Subject: [Ietf-calsify] [Fwd: Deployment of the Internet-Draft Submission Tool]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 21 Sep 2007 06:23:03 -0000

FYI.

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

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 [e-mail]), 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 [e-mail].

Enjoy!!

The IETF Secretariat


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 36E95808FA for <[e-mail]>; Mon, 17 Sep 2007 12:56:36 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5FDDA142229 for <[e-mail]>; Mon, 17 Sep 2007 12:55:41 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.43
X-Spam-Level: 
X-Spam-Status: No, score=-1.43 tagged_above=-50 required=4 tests=[AWL=1.169, BAYES_00=-2.599]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+eNEVXaey9T for <[e-mail]>; Mon, 17 Sep 2007 12:55:35 -0700 (PDT)
Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C6058142227 for <[e-mail]>; Mon, 17 Sep 2007 12:55:32 -0700 (PDT)
Received: from einstein.kainhofer.com (localhost [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l8HJtTAG022852 for <[e-mail]>; Mon, 17 Sep 2007 21:55:29 +0200
From: Reinhold Kainhofer <[e-mail]>
Organization: Vienna University of Technology
To: [e-mail]
Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
Date: Mon, 17 Sep 2007 21:55:26 +0200
User-Agent: KMail/1.9.6
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset="ansi_x3.4-1968"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 17 Sep 2007 19:56:36 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Montag, 17. September 2007 schrieb Tim Hare:
> 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. 

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

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

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: [e-mail], 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/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFG7tuwTqjEwhXvPN0RAlm0AJ930xifJmWyss5SYLyPDBCYVuR0mgCeMwoT
hTEwqIdhhNvLnFkGADqSyjo=
=eXpA
-----END PGP SIGNATURE-----


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4F9B280A4E for <[e-mail]>; Mon, 17 Sep 2007 09:44:37 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3BEEF14222B for <[e-mail]>; Mon, 17 Sep 2007 09:43:42 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: 0.085
X-Spam-Level: 
X-Spam-Status: No, score=0.085 tagged_above=-50 required=4 tests=[AWL=-0.417,  BAYES_00=-2.599, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_ID=1.393]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzTfzYp+Hzny for <[e-mail]>; Mon, 17 Sep 2007 09:43:37 -0700 (PDT)
Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [63.240.77.84]) by laweleka.osafoundation.org (Postfix) with ESMTP id 020941426FD for <[e-mail]>; Sun, 16 Sep 2007 21:13:55 -0700 (PDT)
Received: from thare (c-71-203-100-120.hsd1.fl.comcast.net[71.203.100.120]) by comcast.net (sccrmhc14) with SMTP id <2007091704135401400rj1nfe>; Mon, 17 Sep 2007 04:13:54 +0000
From: "Tim Hare" <[e-mail]>
To: "'Bernard Desruisseaux'" <[e-mail]>, <[e-mail]>
Subject: RE: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
Date: Mon, 17 Sep 2007 00:14:24 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
Thread-Index: Acf2JQfkShUplqX3Qi2mcVYzDZfkgQCuTUKA
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 17 Sep 2007 16:44:42 -0000

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: [e-mail]
[mailto:[e-mail]] On Behalf Of Bernard
Desruisseaux
Sent: Thursday, September 13, 2007 12:42 PM
To: [e-mail]
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:
> 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.
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> 

_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9D8DA80B20; Fri, 14 Sep 2007 11:18:21 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C2B0C14220A; Fri, 14 Sep 2007 11:17:26 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -0.436
X-Spam-Level: 
X-Spam-Status: No, score=-0.436 tagged_above=-50 required=4 tests=[AWL=0.671,  BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, HTML_50_60=0.134, HTML_IMAGE_ONLY_20=1.157, HTML_MESSAGE=0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INw1-MaRQw5Q; Fri, 14 Sep 2007 11:17:22 -0700 (PDT)
Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5B93F1421FD; Fri, 14 Sep 2007 11:17:22 -0700 (PDT)
In-Reply-To: <[e-mail]>
To: Eliot Lear <[e-mail]>
Subject: Re: [Ietf-calsify] Issue 87: iTIP: DEPRECATE COUNTER/DECLINE-COUNTER
Message-ID: <OF336CCF95.2A8517AE-ON85257356.00645044-85257356.006476B6@LocalDomain>
Date: Fri, 14 Sep 2007 14:17:20 -0400
From: "Robert Ransdell" <[e-mail]>
Content-Type: multipart/related; boundary="=_related 006476AE85257356_="
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V703_08052007NP August 05, 2007
X-Disclaimed: 2275
Cc: "[e-mail]" <[e-mail]>, [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 14 Sep 2007 18:18:22 -0000

--=_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, "[e-mail]", 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=
[e-mail]&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_=--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D741280AF9 for <[e-mail]>; Fri, 14 Sep 2007 10:49:41 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0A3F414220C for <[e-mail]>; Fri, 14 Sep 2007 10:48:47 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.213
X-Spam-Level: 
X-Spam-Status: No, score=-2.213 tagged_above=-50 required=4 tests=[AWL=0.385,  BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSqm7T5BU12D for <[e-mail]>; Fri, 14 Sep 2007 10:48:42 -0700 (PDT)
Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 740E614220A for <[e-mail]>; Fri, 14 Sep 2007 10:48:42 -0700 (PDT)
Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l8EHmXvm018181; Fri, 14 Sep 2007 12:48:33 -0500
Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id l8E8BnTo021482; Fri, 14 Sep 2007 11:48:33 -0600
Received: from inet-141-146-46-1.oracle.com by acsmt351.oracle.com with ESMTP id 3214247291189792025; Fri, 14 Sep 2007 10:47:05 -0700
Received: from [10.156.42.83] (/10.156.42.83) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 14 Sep 2007 10:47:05 -0700
Message-ID: <[e-mail]>
Date: Fri, 14 Sep 2007 13:47:03 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Eliot Lear <[e-mail]>
Subject: Re: [Ietf-calsify] One last comment on exact vs. nominal durations
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
X-Whitelist: TRUE
Cc: "[e-mail]" <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 14 Sep 2007 17:49:42 -0000

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
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> 



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 13D8A8092A for <[e-mail]>; Fri, 14 Sep 2007 10:10:57 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3B90F142213 for <[e-mail]>; Fri, 14 Sep 2007 10:10:02 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.207
X-Spam-Level: 
X-Spam-Status: No, score=-2.207 tagged_above=-50 required=4 tests=[AWL=0.391,  BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTdDRB32Hrc0 for <[e-mail]>; Fri, 14 Sep 2007 10:09:59 -0700 (PDT)
Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1530314220C for <[e-mail]>; Fri, 14 Sep 2007 10:09:58 -0700 (PDT)
Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l8EH9rnD009043 for <[e-mail]>; Fri, 14 Sep 2007 11:09:54 -0600
Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l8CHSodi018415 for <[e-mail]>; Fri, 14 Sep 2007 11:09:53 -0600
Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3214455651189789766; Fri, 14 Sep 2007 10:09:26 -0700
Received: from [10.156.42.83] (/10.156.42.83) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 14 Sep 2007 10:09:25 -0700
Message-ID: <[e-mail]>
Date: Fri, 14 Sep 2007 13:09:24 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: [Ietf-calsify] Issue 85: iTIP: No more RANGE=
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
X-Whitelist: TRUE
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 14 Sep 2007 17:10:57 -0000

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.
>> _______________________________________________
>> Ietf-calsify mailing list
>> [e-mail]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>>
> 
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> 



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 1B8AF80B6B for <[e-mail]>; Thu, 13 Sep 2007 14:48:20 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 43D93142201 for <[e-mail]>; Thu, 13 Sep 2007 14:47:25 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.464
X-Spam-Level: 
X-Spam-Status: No, score=-1.464 tagged_above=-50 required=4 tests=[AWL=0.761,  BAYES_00=-2.599, HTML_30_40=0.374, HTML_MESSAGE=0.001, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7StRhsWH1es for <[e-mail]>; Thu, 13 Sep 2007 14:47:23 -0700 (PDT)
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7C0C1142215 for <[e-mail]>; Thu, 13 Sep 2007 14:47:23 -0700 (PDT)
Received: by wa-out-1112.google.com with SMTP id j40so830150wah for <[e-mail]>; Thu, 13 Sep 2007 14:47:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=qTtclgiJ7O/wCIEsq4jeEFsKDXIOeCRUjlOF4fb8V2o=; b=G/qTr9u3vwd9Jgp5qxaXOigdGu9fkqQRBgGZp3G6wTG6flo0+zajwRgVDzW1KGy/9N5xSimLO3+g7lEJZfMSlU5ILUgHnxyK5u9PbSeIZsfYYII0WRhaRvSAtzJZ1GQ9S0ZoManFHFMnls3cN9JUc6W+RXF7MxjNpupGDYsa9CQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=qKrkimphflMbUrrrfiBjwIqkZ2kXvrbLbnuroOVVNxkfUJyW3sGO2oZ69AvPrAYSXAw7Yc7RJmIchCXRJAIQj5SKtLZT9b6hlycaz0FthxYzNGclYfI+PptLeSZA6uVBmgEDm988TxwCwHOcCkCnxc7nCOiIZGoEJj/SqsyY9kg=
Received: by 10.114.160.1 with SMTP id i1mr892291wae.1189720041898; Thu, 13 Sep 2007 14:47:21 -0700 (PDT)
Received: by 10.114.106.8 with HTTP; Thu, 13 Sep 2007 14:47:21 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 13 Sep 2007 18:47:21 -0300
From: "=?ISO-8859-1?Q?F=E1bio_Henrique_da_Silva?=" <[e-mail]>
To: "Eliot Lear" <[e-mail]>
Subject: Re: [Ietf-calsify] Issue 87: iTIP: DEPRECATE COUNTER/DECLINE-COUNTER
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_22217_17165624.1189720041889"
References: <OF01ABB3D2.9384D1FD-ON85257355.00554FA4-85257355.00555C9B@LocalDomain> <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2007 21:48:20 -0000

------=_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 <[e-mail]> 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
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>

------=_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=
[e-mail]">[e-mail]</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:[e-mail]">Ietf-calsi=
[e-mail]
</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--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 483CA7F8E0 for <[e-mail]>; Thu, 13 Sep 2007 13:19:03 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6FA89142213 for <[e-mail]>; Thu, 13 Sep 2007 13:18:08 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.779
X-Spam-Level: 
X-Spam-Status: No, score=-1.779 tagged_above=-50 required=4 tests=[AWL=0.819,  BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMRqUsmPAqtp for <[e-mail]>; Thu, 13 Sep 2007 13:18:03 -0700 (PDT)
Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5E211142212 for <[e-mail]>; Thu, 13 Sep 2007 13:18:03 -0700 (PDT)
Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l8DKI1Qf020082 for <[e-mail]>; Thu, 13 Sep 2007 15:18:01 -0500
Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l8DICvIH024928 for <[e-mail]>; Thu, 13 Sep 2007 14:18:01 -0600
Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3211137451189714592; Thu, 13 Sep 2007 13:16:32 -0700
Received: from [141.144.97.209] (/141.144.97.209) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 Sep 2007 13:16:32 -0700
Message-ID: <[e-mail]>
Date: Thu, 13 Sep 2007 16:16:30 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: CALSIFY Mailinglist <[e-mail]>
Subject: Re: [Ietf-calsify] working group last call comments for	draft-ietf-calsify-rfc2445bis-07.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
X-Whitelist: TRUE
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2007 20:19:03 -0000

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
>>
>>       In the case of an iCalendar object that specifies a "METHOD"
>> -      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

> 
>>       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.
>>
>> Cheers,
>>
>> Nigel
>>
>>   
> 
> Thanks again,
> 
> Eliot
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> 



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D472180BD0 for <[e-mail]>; Thu, 13 Sep 2007 11:43:17 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 07E20142219 for <[e-mail]>; Thu, 13 Sep 2007 11:42:23 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.765
X-Spam-Level: 
X-Spam-Status: No, score=-1.765 tagged_above=-50 required=4 tests=[AWL=0.833,  BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZCQDm30e6z7 for <[e-mail]>; Thu, 13 Sep 2007 11:42:18 -0700 (PDT)
Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1AF1914220A for <[e-mail]>; Thu, 13 Sep 2007 11:42:17 -0700 (PDT)
Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l8DIgFNM019209 for <[e-mail]>; Thu, 13 Sep 2007 12:42:16 -0600
Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l8DBQRQd007316 for <[e-mail]>; Thu, 13 Sep 2007 12:42:15 -0600
Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3211326421189708871; Thu, 13 Sep 2007 11:41:11 -0700
Received: from [141.144.97.209] (/141.144.97.209) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 Sep 2007 11:41:11 -0700
Message-ID: <[e-mail]>
Date: Thu, 13 Sep 2007 14:41:10 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: [Ietf-calsify] Issue 91: iTIP: VFREEBUSY reply does not allow zero	FREEBUSY properties
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
X-Whitelist: TRUE
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2007 18:43:17 -0000

+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+.
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> 



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 03F5980B53 for <[e-mail]>; Thu, 13 Sep 2007 11:22:57 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2BBBF1421FD for <[e-mail]>; Thu, 13 Sep 2007 11:22:02 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.758
X-Spam-Level: 
X-Spam-Status: No, score=-1.758 tagged_above=-50 required=4 tests=[AWL=0.840,  BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7QC27cqPUhx for <[e-mail]>; Thu, 13 Sep 2007 11:21:57 -0700 (PDT)
Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 9493F1421FB for <[e-mail]>; Thu, 13 Sep 2007 11:21:57 -0700 (PDT)
Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l8DILtRa021391 for <[e-mail]>; Thu, 13 Sep 2007 13:21:55 -0500
Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l8BIUNep018199 for <[e-mail]>; Thu, 13 Sep 2007 12:21:54 -0600
Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3211030531189707685; Thu, 13 Sep 2007 11:21:25 -0700
Received: from [141.144.112.22] (/141.144.112.22) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 Sep 2007 11:21:25 -0700
Message-ID: <[e-mail]>
Date: Thu, 13 Sep 2007 14:21:20 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: [Ietf-calsify] Issue 85: iTIP: No more RANGE=
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
X-Whitelist: TRUE
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2007 18:22:57 -0000

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.
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> 



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 795DA80BB4; Thu, 13 Sep 2007 09:43:31 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A10BD142219; Thu, 13 Sep 2007 09:42:36 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.853
X-Spam-Level: 
X-Spam-Status: No, score=-1.853 tagged_above=-50 required=4 tests=[AWL=0.612,  BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSjvo3sjVHmF; Thu, 13 Sep 2007 09:42:33 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 94FA0142213; Thu, 13 Sep 2007 09:42:32 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.20,250,1186351200"; d="scan'208";a="153079643"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 13 Sep 2007 18:42:31 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8DGgVIb017875;  Thu, 13 Sep 2007 18:42:31 +0200
Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp231.cisco.com [10.61.64.231]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8DGgQEN028045;  Thu, 13 Sep 2007 16:42:26 GMT
Message-ID: <[e-mail]>
Date: Thu, 13 Sep 2007 18:42:15 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: Robert Ransdell <[e-mail]>
Subject: Re: [Ietf-calsify] Issue 87: iTIP: DEPRECATE COUNTER/DECLINE-COUNTER
References: <OF01ABB3D2.9384D1FD-ON85257355.00554FA4-85257355.00555C9B@LocalDomain>
In-Reply-To: <OF01ABB3D2.9384D1FD-ON85257355.00554FA4-85257355.00555C9B@LocalDomain>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=333; t=1189701751; x=1190565751; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20Re=3A=20[Ietf-calsify]=20Issue=2087=3A=20iTIP=3A=20DEPRECATE= 20COUNTER/DECLINE-COUNTER |Sender:=20; bh=qpug+nJVjbd98xz8If2e+rOPYxGVzZcgmvmS3Z44Jj8=; b=KmZr/zcljF/gfbjv+cyevahkzdDAqV8UnGi1wNzuRPnY3uO9mGtlT7n7OIHmYMlfvYyJSjkh SWmfUfn6ysJnAFHFZdBtdV62e3BLLczWPpgZl9iXvyBOnzmk1TN1bDFQ;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); 
Cc: "[e-mail]" <[e-mail]>, [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2007 16:43:31 -0000

(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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id C82C280B87 for <[e-mail]>; Thu, 13 Sep 2007 09:43:03 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id F008F14220A for <[e-mail]>; Thu, 13 Sep 2007 09:42:08 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.751
X-Spam-Level: 
X-Spam-Status: No, score=-1.751 tagged_above=-50 required=4 tests=[AWL=0.847,  BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krZivzYHlHUr for <[e-mail]>; Thu, 13 Sep 2007 09:42:04 -0700 (PDT)
Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1F4751421FF for <[e-mail]>; Thu, 13 Sep 2007 09:42:04 -0700 (PDT)
Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l8DGg0Qo018181 for <[e-mail]>; Thu, 13 Sep 2007 10:42:00 -0600
Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l8CLNTdq003837 for <[e-mail]>; Thu, 13 Sep 2007 10:42:00 -0600
Received: from inet-141-146-46-1.oracle.com by acsmt351.oracle.com with ESMTP id 3210305871189701696; Thu, 13 Sep 2007 09:41:36 -0700
Received: from [141.144.112.22] (/141.144.112.22) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 Sep 2007 09:41:36 -0700
Message-ID: <[e-mail]>
Date: Thu, 13 Sep 2007 12:41:32 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
X-Whitelist: TRUE
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2007 16:43:03 -0000

-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:
> 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.
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> 



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3E47180BA2 for <[e-mail]>; Thu, 13 Sep 2007 09:37:22 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 66938142219 for <[e-mail]>; Thu, 13 Sep 2007 09:36:27 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.41
X-Spam-Level: 
X-Spam-Status: No, score=-2.41 tagged_above=-50 required=4 tests=[AWL=0.189, BAYES_00=-2.599]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ud-hGNAjWdKX for <[e-mail]>; Thu, 13 Sep 2007 09:36:23 -0700 (PDT)
Received: from mulberrymail.com (piper.mulberrymail.com [151.201.22.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 650F3142213 for <[e-mail]>; Thu, 13 Sep 2007 09:36:23 -0700 (PDT)
Received: from caldav.corp.apple.com ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l8DGaGEG001563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Sep 2007 12:36:19 -0400
Date: Thu, 13 Sep 2007 12:36:11 -0400
From: Cyrus Daboo <[e-mail]>
To: Andy Mabbett <[e-mail]>, [e-mail]
Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <OFA93C8135.6C898380-ON85257355.005210FD-85257355.0052146A@LocalDomain> <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2007 16:37:22 -0000

Hi Andy,

--On September 13, 2007 5:26:12 PM +0100 Andy Mabbett 
<[e-mail]> wrote:

>> If a event has changed in such a way the chair needs to send a
>> 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.

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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 69D2B80B9F for <[e-mail]>; Thu, 13 Sep 2007 09:30:44 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 90E60142212 for <[e-mail]>; Thu, 13 Sep 2007 09:29:49 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.407
X-Spam-Level: 
X-Spam-Status: No, score=-2.407 tagged_above=-50 required=4 tests=[AWL=0.192,  BAYES_00=-2.599]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2LvVxgSydGT for <[e-mail]>; Thu, 13 Sep 2007 09:29:44 -0700 (PDT)
Received: from mulberrymail.com (piper.mulberrymail.com [151.201.22.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 82E6A142213 for <[e-mail]>; Thu, 13 Sep 2007 09:29:44 -0700 (PDT)
Received: from caldav.corp.apple.com ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l8DGTO9h001501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Sep 2007 12:29:27 -0400
Date: Thu, 13 Sep 2007 12:29:19 -0400
From: Cyrus Daboo <[e-mail]>
To: Robert Ransdell <[e-mail]>
Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
Message-ID: <[e-mail]>
In-Reply-To: <OFFF7E368E.8F241700-ON85257355.00559940-85257355.00560498@LocalDomain>
References: <OFFF7E368E.8F241700-ON85257355.00559940-85257355.00560498@LocalDomain>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2007 16:30:44 -0000

Hi Robert,

--On September 13, 2007 11:39:32 AM -0400 Robert Ransdell 
<[e-mail]> 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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E23AB80B9F for <[e-mail]>; Thu, 13 Sep 2007 09:27:16 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 166FB142213 for <[e-mail]>; Thu, 13 Sep 2007 09:26:22 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.313
X-Spam-Level: 
X-Spam-Status: No, score=-2.313 tagged_above=-50 required=4 tests=[AWL=0.151,  BAYES_00=-2.599, FORGED_RCVD_HELO=0.135]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AzuTGkcZ4Kk for <[e-mail]>; Thu, 13 Sep 2007 09:26:17 -0700 (PDT)
Received: from lon-mail-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by laweleka.osafoundation.org (Postfix) with ESMTP id 36E93142212 for <[e-mail]>; Thu, 13 Sep 2007 09:26:17 -0700 (PDT)
Received: from crimson.gradwell.net ([193.111.200.19] helo=www.gradwell.com country=GB) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.254) id 46e964a4.150e9.732 for [e-mail]; Thu, 13 Sep 2007 17:26:12 +0100 (envelope-sender <[e-mail]>)
Received: from 80.249.57.38 (SquirrelMail authenticated user [e-mail]) by www.gradwell.com with HTTP; Thu, 13 Sep 2007 17:26:12 +0100 (BST)
Message-ID: <[e-mail]>
In-Reply-To: <OFA93C8135.6C898380-ON85257355.005210FD-85257355.0052146A@LocalDomain >
References: <[e-mail]> <OFA93C8135.6C898380-ON85257355.005210FD-85257355.0052146A@LocalDomain>
Date: Thu, 13 Sep 2007 17:26:12 +0100 (BST)
Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
From: "Andy Mabbett" <[e-mail]>
To: [e-mail]
User-Agent: SquirrelMail/1.5.1
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2007 16:27:17 -0000

On Thu, September 13, 2007 15:56, Robert Ransdell wrote:
> If a event has changed in such a way the chair needs to send a
> 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 **



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E644D80AF9 for <[e-mail]>; Thu, 13 Sep 2007 08:40:30 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 18CE8142219 for <[e-mail]>; Thu, 13 Sep 2007 08:39:36 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: 0.102
X-Spam-Level: 
X-Spam-Status: No, score=0.102 tagged_above=-50 required=4 tests=[AWL=0.163, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, HTML_40_50=0.496, HTML_IMAGE_ONLY_24=1.841, HTML_MESSAGE=0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmpqiincqYGo for <[e-mail]>; Thu, 13 Sep 2007 08:39:34 -0700 (PDT)
Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3BAC1142217 for <[e-mail]>; Thu, 13 Sep 2007 08:39:34 -0700 (PDT)
In-Reply-To: <[e-mail]>
To: Cyrus Daboo <[e-mail]>
Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
Message-ID: <OFFF7E368E.8F241700-ON85257355.00559940-85257355.00560498@LocalDomain>
Date: Thu, 13 Sep 2007 11:39:32 -0400
From: "Robert Ransdell" <[e-mail]>
Content-Type: multipart/related; boundary="=_related 0056049285257355_="
MIME-Version: 1.0
X-KeepSent: FF7E368E:8F241700-85257355:00559940; name=$KeepSent; type=4
X-Mailer: Lotus Notes Build V703_08052007NP August 05, 2007
X-Disclaimed: 54791
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2007 15:40:31 -0000

--=_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,

--On September 13, 2007 10:56:32 AM -0400 Robert Ransdell=20
<Robert=[e-mail]> 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=20
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=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=[e-mail]&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_=--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7DE7480BA3; Thu, 13 Sep 2007 08:33:23 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A345B142217; Thu, 13 Sep 2007 08:32:28 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -0.015
X-Spam-Level: 
X-Spam-Status: No, score=-0.015 tagged_above=-50 required=4 tests=[AWL=0.349,  BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, HTML_50_60=0.134, HTML_IMAGE_ONLY_28=1.9, HTML_MESSAGE=0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuOwY07I3Akh; Thu, 13 Sep 2007 08:32:24 -0700 (PDT)
Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by laweleka.osafoundation.org (Postfix) with ESMTP id B52331421F7; Thu, 13 Sep 2007 08:32:24 -0700 (PDT)
In-Reply-To: <[e-mail]>
To: Mike Douglass <[e-mail]>
Subject: Re: [Ietf-calsify] Issue 87: iTIP: DEPRECATE COUNTER/DECLINE-COUNTER
Message-ID: <OF01ABB3D2.9384D1FD-ON85257355.00554FA4-85257355.00555C9B@LocalDomain>
Date: Thu, 13 Sep 2007 11:32:22 -0400
From: "Robert Ransdell" <[e-mail]>
Content-Type: multipart/related; boundary="=_related 00555C9685257355_="
MIME-Version: 1.0
X-KeepSent: 01ABB3D2:9384D1FD-85257355:00554FA4; name=$KeepSent; type=4
X-Mailer: Lotus Notes Build V703_08052007NP August 05, 2007
X-Disclaimed: 29963
Cc: "[e-mail]" <[e-mail]>, [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2007 15:33:23 -0000

--=_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:
[e-mail]
09/13/2007 11:17 AM


Sent by:
[e-mail]







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
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>

--=20

Mike Douglass                           [e-mail]
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
[e-mail]
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>[e-mail]</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; [e-mail]<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; [e-mail]<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_=--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 07A6880BA3 for <[e-mail]>; Thu, 13 Sep 2007 08:32:43 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2FF21142213 for <[e-mail]>; Thu, 13 Sep 2007 08:31:48 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.404
X-Spam-Level: 
X-Spam-Status: No, score=-2.404 tagged_above=-50 required=4 tests=[AWL=0.195,  BAYES_00=-2.599]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdX9OdvMENGl for <[e-mail]>; Thu, 13 Sep 2007 08:31:43 -0700 (PDT)
Received: from mulberrymail.com (piper.mulberrymail.com [151.201.22.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C5C0B142217 for <[e-mail]>; Thu, 13 Sep 2007 08:31:42 -0700 (PDT)
Received: from caldav.corp.apple.com ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l8DFVIUe001109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Sep 2007 11:31:20 -0400
Date: Thu, 13 Sep 2007 11:31:12 -0400
From: Cyrus Daboo <[e-mail]>
To: Robert Ransdell <[e-mail]>
Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
Message-ID: <[e-mail]>
In-Reply-To: <OFA93C8135.6C898380-ON85257355.005210FD-85257355.0052146A@LocalDomain>
References: <OFA93C8135.6C898380-ON85257355.005210FD-85257355.0052146A@LocalDomain>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2007 15:32:43 -0000

Hi Robert,

--On September 13, 2007 10:56:32 AM -0400 Robert Ransdell 
<[e-mail]> 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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D415080BAB for <[e-mail]>; Thu, 13 Sep 2007 08:16:19 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id EC5A0142213 for <[e-mail]>; Thu, 13 Sep 2007 08:15:24 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.807
X-Spam-Level: 
X-Spam-Status: No, score=-1.807 tagged_above=-50 required=4 tests=[AWL=0.792,  BAYES_00=-2.599]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtfExS7LVUAz for <[e-mail]>; Thu, 13 Sep 2007 08:15:21 -0700 (PDT)
Received: from smtp8.server.rpi.edu (smtp8.server.rpi.edu [128.113.2.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2835914220A for <[e-mail]>; Thu, 13 Sep 2007 08:15:21 -0700 (PDT)
Received: from [128.113.124.138] (crustacean-10.dynamic.rpi.edu [128.113.124.138]) by smtp8.server.rpi.edu (8.13.1/8.13.1) with ESMTP id l8DFFJ6t016397 for <[e-mail]>; Thu, 13 Sep 2007 11:15:19 -0400
Message-ID: <[e-mail]>
Date: Thu, 13 Sep 2007 11:16:30 -0400
From: Mike Douglass <[e-mail]>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: [Ietf-calsify] Issue 87: iTIP: DEPRECATE COUNTER/DECLINE-COUNTER
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-RPI-SA-Score: undef - spam scanning disabled
X-CanItPRO-Stream: default
X-Canit-Stats-ID: Bayes signature not available
X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.228
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2007 15:16:20 -0000

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.
>
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>

-- 

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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 0CBDB80BAE for <[e-mail]>; Thu, 13 Sep 2007 07:57:41 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 32D0B142217 for <[e-mail]>; Thu, 13 Sep 2007 07:56:46 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: 0.134
X-Spam-Level: 
X-Spam-Status: No, score=0.134 tagged_above=-50 required=4 tests=[AWL=0.258, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, HTML_30_40=0.374, HTML_IMAGE_ONLY_28=1.9, HTML_MESSAGE=0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sv25JXXVdqO7 for <[e-mail]>; Thu, 13 Sep 2007 07:56:44 -0700 (PDT)
Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by laweleka.osafoundation.org (Postfix) with ESMTP id 33EB9142213 for <[e-mail]>; Thu, 13 Sep 2007 07:56:44 -0700 (PDT)
In-Reply-To: <[e-mail]>
To: Cyrus Daboo <[e-mail]>
Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
Message-ID: <OFA93C8135.6C898380-ON85257355.005210FD-85257355.0052146A@LocalDomain>
Date: Thu, 13 Sep 2007 10:56:32 -0400
From: "Robert Ransdell" <[e-mail]>
Content-Type: multipart/related; boundary="=_related 0052146385257355_="
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V703_08052007NP August 05, 2007
X-Disclaimed: 47319
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2007 14:57:41 -0000

--=_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,

--On September 13, 2007 10:27:47 AM -0400 Robert Ransdell=20
<Robert=[e-mail]> 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=20
would set PART-STAT back to NEEDS-ACTION and RSVP=3DTRUE. So doesn't that d=
o=20

the job of telling the attendee that they need to re-consider?

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=[e-mail]&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_=--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6432E80B7A for <[e-mail]>; Thu, 13 Sep 2007 07:44:53 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8C672142207 for <[e-mail]>; Thu, 13 Sep 2007 07:43:58 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.402
X-Spam-Level: 
X-Spam-Status: No, score=-2.402 tagged_above=-50 required=4 tests=[AWL=0.197,  BAYES_00=-2.599]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYf-rd2pFeLE for <[e-mail]>; Thu, 13 Sep 2007 07:43:52 -0700 (PDT)
Received: from mulberrymail.com (piper.mulberrymail.com [151.201.22.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5F365142212 for <[e-mail]>; Thu, 13 Sep 2007 07:43:52 -0700 (PDT)
Received: from caldav.corp.apple.com ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l8DEhV0p000635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Sep 2007 10:43:33 -0400
Date: Thu, 13 Sep 2007 10:43:26 -0400
From: Cyrus Daboo <[e-mail]>
To: Robert Ransdell <[e-mail]>, Eliot Lear <[e-mail]>
Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
Message-ID: <[e-mail]>
In-Reply-To: <OFC4DABC99.58CD7250-ON85257355.004F3848-85257355.004F72EF@LocalDomain>
References: <OFC4DABC99.58CD7250-ON85257355.004F3848-85257355.004F72EF@LocalDomain>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2007 14:44:53 -0000

Hi Robert,

--On September 13, 2007 10:27:47 AM -0400 Robert Ransdell 
<[e-mail]> 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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 5816580B53; Thu, 13 Sep 2007 07:28:54 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7EC2C142207; Thu, 13 Sep 2007 07:27:59 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: 0.198
X-Spam-Level: 
X-Spam-Status: No, score=0.198 tagged_above=-50 required=4 tests=[AWL=0.259, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, HTML_40_50=0.496, HTML_IMAGE_ONLY_24=1.841, HTML_MESSAGE=0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzyxDoqcMUbm; Thu, 13 Sep 2007 07:27:52 -0700 (PDT)
Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by laweleka.osafoundation.org (Postfix) with ESMTP id B7D61142201; Thu, 13 Sep 2007 07:27:52 -0700 (PDT)
In-Reply-To: <[e-mail]>
To: Eliot Lear <[e-mail]>
Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
Message-ID: <OFC4DABC99.58CD7250-ON85257355.004F3848-85257355.004F72EF@LocalDomain>
Date: Thu, 13 Sep 2007 10:27:47 -0400
From: "Robert Ransdell" <[e-mail]>
Content-Type: multipart/related; boundary="=_related 004F72E485257355_="
MIME-Version: 1.0
X-KeepSent: C4DABC99:58CD7250-85257355:004F3848; name=$KeepSent; type=4
X-Mailer: Lotus Notes Build V703_08052007NP August 05, 2007
X-Disclaimed: 60651
Cc: "[e-mail]" <[e-mail]>, [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2007 14:28:54 -0000

--=_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:
[e-mail]
09/13/2007 10:22 AM


Sent by:
[e-mail]







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=20
have to spot significant changes that are relevant to their calendar user, =

so=20
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=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
[e-mail]
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">[e-mail]</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=
[e-mail]</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_=--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D6F4280BAF for <[e-mail]>; Thu, 13 Sep 2007 07:25:45 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0B6B7142207 for <[e-mail]>; Thu, 13 Sep 2007 07:24:51 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.849
X-Spam-Level: 
X-Spam-Status: No, score=-1.849 tagged_above=-50 required=4 tests=[AWL=0.616,  BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqO3H4h3sb1u for <[e-mail]>; Thu, 13 Sep 2007 07:24:47 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0E6E1142201 for <[e-mail]>; Thu, 13 Sep 2007 07:24:46 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.20,250,1186351200"; d="scan'208";a="153063486"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 13 Sep 2007 16:24:25 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8DEOOvM009060 for <[e-mail]>; Thu, 13 Sep 2007 16:24:24 +0200
Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp231.cisco.com [10.61.64.231]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8DEOOEN008175 for <[e-mail]>; Thu, 13 Sep 2007 14:24:24 GMT
Message-ID: <[e-mail]>
Date: Thu, 13 Sep 2007 16:24:13 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=233; t=1189693464; x=1190557464; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20Issue=2091=3A=20iTIP=3A=20VFREEBUSY=20reply=20does=20not=20al low=20zero=20FREEBUSY=20properties |Sender:=20; bh=mMIKP5LvOKHMukpqZTmvf9jH4pZaIJzeW5s/rl5ryOE=; b=gNFAABPduQx6bBiJySssAST5AsahgeexMVT2X5uYdDRDUUD8vpmH78BvY1rV21IrcQ459Jsn xV3hFoUwwMRDaX59+Eb0zq6ADT0qv+x+3ldsPgyXGtjeSS/pxRiNLEUz;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); 
Subject: [Ietf-calsify] Issue 91: iTIP: VFREEBUSY reply does not allow zero FREEBUSY properties
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2007 14:25:46 -0000

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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A51DE80BA3 for <[e-mail]>; Thu, 13 Sep 2007 07:24:32 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CD383142207 for <[e-mail]>; Thu, 13 Sep 2007 07:23:37 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.846
X-Spam-Level: 
X-Spam-Status: No, score=-1.846 tagged_above=-50 required=4 tests=[AWL=0.619,  BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRimBPmzX6yZ for <[e-mail]>; Thu, 13 Sep 2007 07:23:34 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id F2377142201 for <[e-mail]>; Thu, 13 Sep 2007 07:23:33 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.20,250,1186351200"; d="scan'208";a="153063391"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 13 Sep 2007 16:23:33 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8DENXfZ008840 for <[e-mail]>; Thu, 13 Sep 2007 16:23:33 +0200
Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp231.cisco.com [10.61.64.231]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8DENWEN007847 for <[e-mail]>; Thu, 13 Sep 2007 14:23:32 GMT
Message-ID: <[e-mail]>
Date: Thu, 13 Sep 2007 16:23:21 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=672; t=1189693413; x=1190557413; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20Issue=2090=3A=20iTIP=3A=20better=20guidance=20to=20CUAs=20on= 20how=20to=20handle=20ADD/CANCEL |Sender:=20; bh=Jq3gPZokrKpMLXpcd9fU7YxwmlfHiepjUSwOOjhULqM=; b=LXgaiiNzb/5UZWpLwvmMMn9bPUZlVurYFD603IMIdTXX5rKeIS633SJlqoj9MyQOHolYV3OM 3Ou8m7WQbgdd8qpnYjIGml7B4klHXRkhgp3SPhS6hewWw2Gfj/+Qxgut;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); 
Subject: [Ietf-calsify] Issue 90: iTIP: better guidance to CUAs on how to handle ADD/CANCEL
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2007 14:24:32 -0000

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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E713C80B97 for <[e-mail]>; Thu, 13 Sep 2007 07:23:24 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1924B142201 for <[e-mail]>; Thu, 13 Sep 2007 07:22:30 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.842
X-Spam-Level: 
X-Spam-Status: No, score=-1.842 tagged_above=-50 required=4 tests=[AWL=0.623,  BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bsmjnoKKsQZ for <[e-mail]>; Thu, 13 Sep 2007 07:22:26 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id D651C142207 for <[e-mail]>; Thu, 13 Sep 2007 07:22:25 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.20,250,1186351200"; d="scan'208";a="153063206"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 13 Sep 2007 16:22:25 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8DEMOaT008417 for <[e-mail]>; Thu, 13 Sep 2007 16:22:24 +0200
Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp231.cisco.com [10.61.64.231]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8DEMOEN007363 for <[e-mail]>; Thu, 13 Sep 2007 14:22:24 GMT
Message-ID: <[e-mail]>
Date: Thu, 13 Sep 2007 16:22:13 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=269; t=1189693344; x=1190557344; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20Issue=2089=3A=20ADD=20description=20misleading |Sender:=20; bh=IKanJbEElp5JAga+vxGTJOiUnc+EmmCJroTqMcE7g1o=; b=aaIw1OeztKqbf/DSuSEp21RHjk21U3WvHRiqWVOV+5+TLg9rHnmZGpmIaAM3MMihrSDLu2vB /E49ru61pDVtLLA3O5pofB8T/bPLr91D7sgRjTt9aYzZ5n9l7IGhPsv+;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); 
Subject: [Ietf-calsify] Issue 89: ADD description misleading
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2007 14:23:30 -0000

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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6BE3C80B95 for <[e-mail]>; Thu, 13 Sep 2007 07:22:15 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 93FDE142207 for <[e-mail]>; Thu, 13 Sep 2007 07:21:20 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.838
X-Spam-Level: 
X-Spam-Status: No, score=-1.838 tagged_above=-50 required=4 tests=[AWL=0.627,  BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-Pf5LTLBAfl for <[e-mail]>; Thu, 13 Sep 2007 07:21:17 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 77937142201 for <[e-mail]>; Thu, 13 Sep 2007 07:21:17 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.20,250,1186351200"; d="scan'208";a="153063054"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 13 Sep 2007 16:21:16 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8DELGCp008000 for <[e-mail]>; Thu, 13 Sep 2007 16:21:16 +0200
Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp231.cisco.com [10.61.64.231]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8DELGEN006899 for <[e-mail]>; Thu, 13 Sep 2007 14:21:16 GMT
Message-ID: <[e-mail]>
Date: Thu, 13 Sep 2007 16:21:04 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=428; t=1189693276; x=1190557276; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20Issue=2088=3A=20iTIP=3A=20CANCEL=20definition |Sender:=20; bh=iBH6czmmVb/nX9qguXQ3TUTQsbzQOBKMJeRZHLWTawU=; b=Wh4AxSGoHlJHThAzPicTA8FE18+J3bC2XCFARmrN+dqokunIfPRsjNBGFop9eTUR0pAQH75V UbBGJwba3rmcJPooFyjjZEFW5WT/HKwT5asS9GHxJoFFP7s1eEFwmLiO;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); 
Subject: [Ietf-calsify] Issue 88: iTIP: CANCEL definition
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2007 14:22:15 -0000

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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6E75080B82 for <[e-mail]>; Thu, 13 Sep 2007 07:21:11 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 950B5142207 for <[e-mail]>; Thu, 13 Sep 2007 07:20:16 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.834
X-Spam-Level: 
X-Spam-Status: No, score=-1.834 tagged_above=-50 required=4 tests=[AWL=0.631,  BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCcFCPv8n+zG for <[e-mail]>; Thu, 13 Sep 2007 07:20:11 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9CE6B142201 for <[e-mail]>; Thu, 13 Sep 2007 07:20:11 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.20,250,1186351200"; d="scan'208";a="153062676"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 13 Sep 2007 16:20:10 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8DEKAGj007184 for <[e-mail]>; Thu, 13 Sep 2007 16:20:10 +0200
Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp231.cisco.com [10.61.64.231]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8DEK5EN005895 for <[e-mail]>; Thu, 13 Sep 2007 14:20:10 GMT
Message-ID: <[e-mail]>
Date: Thu, 13 Sep 2007 16:19:54 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=127; t=1189693210; x=1190557210; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20Issue=2087=3A=20iTIP=3A=20DEPRECATE=20COUNTER/DECLINE-COUNTER |Sender:=20; bh=S+f5xd5fwxlBMmy+ckd6Rq6AiZUA3W7Nz6g/baht5Qw=; b=W21RXMcFjDBbjJwL/HWzaRgHv64Zo3SfGhYRKiNwaelsdDGbVIF8Bi9doGIFqE3R/l1FtIDf sO1duzsmDpEZXwByTdkOvHdn6Nmv/Ausy6y4c5FfephO4SHDTGCQp0EY;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); 
Subject: [Ietf-calsify] Issue 87: iTIP: DEPRECATE COUNTER/DECLINE-COUNTER
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2007 14:21:11 -0000

[From Cyrus:]

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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 42A5C80B78 for <[e-mail]>; Thu, 13 Sep 2007 07:20:35 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6A9C5142217 for <[e-mail]>; Thu, 13 Sep 2007 07:19:40 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.829
X-Spam-Level: 
X-Spam-Status: No, score=-1.829 tagged_above=-50 required=4 tests=[AWL=0.636,  BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zCgtYR+ctDw for <[e-mail]>; Thu, 13 Sep 2007 07:19:36 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 65326142201 for <[e-mail]>; Thu, 13 Sep 2007 07:19:36 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.20,250,1186351200"; d="scan'208";a="153062333"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 13 Sep 2007 16:19:13 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8DEJD0T006432 for <[e-mail]>; Thu, 13 Sep 2007 16:19:13 +0200
Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp231.cisco.com [10.61.64.231]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8DEJDEN005167 for <[e-mail]>; Thu, 13 Sep 2007 14:19:13 GMT
Message-ID: <[e-mail]>
Date: Thu, 13 Sep 2007 16:19:02 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=632; t=1189693153; x=1190557153; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20Issue=2086=3A=20iTIP=3A=20DECPRECATE=20SEQUENCE |Sender:=20; bh=Zzafj0/IJeTV0ZT/dfDqfCaIWmnyH5z65YbEGQxQGZ4=; b=iyzR3/y5gh20gepb3JWG4DlDDXeVfkBmoH/P+px1kAKZAKzKa7jyYgw3bWON9aU1zzHFhh2Z NeclzFPEtmrl4SCDEjaGKVjulayIsWRhnsm/VinWe/Nd/MBjVFrL5w90;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); 
Subject: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2007 14:20:35 -0000

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.


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 5587B80B68 for <[e-mail]>; Thu, 13 Sep 2007 07:18:32 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7D57D142207 for <[e-mail]>; Thu, 13 Sep 2007 07:17:37 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.825
X-Spam-Level: 
X-Spam-Status: No, score=-1.825 tagged_above=-50 required=4 tests=[AWL=0.640,  BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mh04opF1N3Tc for <[e-mail]>; Thu, 13 Sep 2007 07:17:33 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id CBF67142201 for <[e-mail]>; Thu, 13 Sep 2007 07:17:32 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.20,250,1186351200"; d="scan'208";a="153062072"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 13 Sep 2007 16:17:32 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8DEHWSo025815 for <[e-mail]>; Thu, 13 Sep 2007 16:17:32 +0200
Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp231.cisco.com [10.61.64.231]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8DEHVEN004392 for <[e-mail]>; Thu, 13 Sep 2007 14:17:31 GMT
Message-ID: <[e-mail]>
Date: Thu, 13 Sep 2007 16:17:20 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=259; t=1189693052; x=1190557052; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20Issue=2085=3A=20iTIP=3A=20No=20more=20RANGE=3D |Sender:=20; bh=tAjTNaL53aXz0j4cAP5OESxNMBGZ68XK7rcboF7+Ybo=; b=iZKU9yS4lELwy9fMo/Nd/9C8cVx9sRXrlV0M2fNXmPsxTsR5x7cH9iRuQZbMt/8zO+jEsrnv K2w1hU0RNKZdLv5s3AaiDVEAc7JMSXnm+fRFCSTizHJ73SwZCbGONyTy;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); 
Subject: [Ietf-calsify] Issue 85: iTIP: No more RANGE=
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2007 14:18:32 -0000

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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B1B4A80A06 for <[e-mail]>; Thu, 13 Sep 2007 07:17:05 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D9726142217 for <[e-mail]>; Thu, 13 Sep 2007 07:16:10 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.821
X-Spam-Level: 
X-Spam-Status: No, score=-1.821 tagged_above=-50 required=4 tests=[AWL=0.644,  BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7F+rFQ+oOqne for <[e-mail]>; Thu, 13 Sep 2007 07:16:07 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0ED09142201 for <[e-mail]>; Thu, 13 Sep 2007 07:16:06 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.20,250,1186351200"; d="scan'208";a="153061737"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 13 Sep 2007 16:16:06 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8DEG6po025324;  Thu, 13 Sep 2007 16:16:06 +0200
Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp231.cisco.com [10.61.64.231]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8DEG3EN003781;  Thu, 13 Sep 2007 14:16:06 GMT
Message-ID: <[e-mail]>
Date: Thu, 13 Sep 2007 16:15:52 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: Cyrus Daboo <[e-mail]>
Subject: Re: [Ietf-calsify] iTIP issues in tracker
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=702; t=1189692966; x=1190556966; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20Re=3A=20[Ietf-calsify]=20iTIP=20issues=20in=20tracker |Sender:=20; bh=H1asnDxSkvKhuT8FcQY3HpXTUGxCTuj/Q/6MvjvUBKs=; b=iwny1dt0fZ0XLIIY8/YHK8b1F0YH+fmiZbLisbLmv5f7vNnMyJCv85kAz2AHuWJqqDQVgKL5 nilJAmwsmKrS8EiN2FIS++RG+5zYmXZcl/8fxLStuGM77VUwHOwk6+hW;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); 
Cc: Calsify WG <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2007 14:17:05 -0000

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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 23BC280B5D for <[e-mail]>; Thu, 13 Sep 2007 07:09:47 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4CA0A142219 for <[e-mail]>; Thu, 13 Sep 2007 07:08:52 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-50 required=4 tests=[AWL=0.200,  BAYES_00=-2.599]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOzKzIQqxpjO for <[e-mail]>; Thu, 13 Sep 2007 07:08:49 -0700 (PDT)
Received: from mulberrymail.com (piper.mulberrymail.com [151.201.22.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 6369C142217 for <[e-mail]>; Thu, 13 Sep 2007 07:08:49 -0700 (PDT)
Received: from caldav.corp.apple.com ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l8DE8eA9032680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 13 Sep 2007 10:08:45 -0400
Date: Thu, 13 Sep 2007 10:08:35 -0400
From: Cyrus Daboo <[e-mail]>
To: Calsify WG <[e-mail]>
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: [Ietf-calsify] iTIP issues in tracker
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2007 14:09:47 -0000

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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2413580B2B for <[e-mail]>; Thu, 13 Sep 2007 06:50:48 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4CDA4142224 for <[e-mail]>; Thu, 13 Sep 2007 06:49:53 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.817
X-Spam-Level: 
X-Spam-Status: No, score=-1.817 tagged_above=-50 required=4 tests=[AWL=0.648,  BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDSpa9agi8Yg for <[e-mail]>; Thu, 13 Sep 2007 06:49:48 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2B4A8142223 for <[e-mail]>; Thu, 13 Sep 2007 06:49:48 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.20,250,1186351200"; d="scan'208";a="153057698"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 13 Sep 2007 15:49:44 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8DDnhJw028038 for <[e-mail]>; Thu, 13 Sep 2007 15:49:43 +0200
Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp231.cisco.com [10.61.64.231]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8DDndEN021399 for <[e-mail]>; Thu, 13 Sep 2007 13:49:43 GMT
Message-ID: <[e-mail]>
Date: Thu, 13 Sep 2007 15:49:28 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=24; t=1189691384; x=1190555384; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20jabber=20in=2010=20minutes... |Sender:=20; bh=499rBCj1RrnHSUW8lpKkCfHoyJ3UCBhcFQ/lReK1kqM=; b=q4L9/IFqFiCfOymQdvXo67Fofe2np/dfC7RDB6ceobDcW+20jEnEVGDfvQGlQmrz2L3/WAm4 /qBCRprIZPTmbIlL7KJYYwffIFVnfPyZUQl99LNqHLmuqhDwbITlxCeb;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); 
Subject: [Ietf-calsify] jabber in 10 minutes...
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2007 13:50:48 -0000

See you then!

Eliot


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3817C80ABB for <[e-mail]>; Mon, 10 Sep 2007 23:13:00 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5DEA31421FB for <[e-mail]>; Mon, 10 Sep 2007 23:12:05 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.782
X-Spam-Level: 
X-Spam-Status: No, score=-1.782 tagged_above=-50 required=4 tests=[AWL=0.683,  BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16b3s49mFz6H for <[e-mail]>; Mon, 10 Sep 2007 23:12:00 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 079621421F6 for <[e-mail]>; Mon, 10 Sep 2007 23:11:59 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.20,235,1186351200";  d="eml'208?scan'208,208";a="152762613"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Sep 2007 08:11:59 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8B6BxF2018801 for <[e-mail]>; Tue, 11 Sep 2007 08:11:59 +0200
Received: from adsl-247-5-fixip.tiscali.ch (ams3-vpn-dhcp143.cisco.com [10.61.64.143]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8B6BwEN025374 for <[e-mail]>; Tue, 11 Sep 2007 06:11:58 GMT
Message-ID: <[e-mail]>
Date: Tue, 11 Sep 2007 08:12:06 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: multipart/mixed; boundary="------------060604060107040802090800"
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5856; t=1189491119; x=1190355119; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20[Fwd=3A=20Nomcom=202007-8=3A=20Nominations=20Deadline=20Exten ded=20to=20Sep=2017,=202007] |Sender:=20; bh=lGEkmcC07n44lhTyVeo5xfafd33aTNC1xWpgqrGmy+c=; b=ZhZT+N+qpMjlTssfPCVVXrku3+3AZv/vbSBZeY5nfIOYOYEy7zGcLn+ogI6brf6KPpLrnM1n YgiTyX3dUQ70ZRMq7hr3nGcj060p89t/GcV3X1/0hMVAu5AwLUFWd2tn;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); 
Subject: [Ietf-calsify] [Fwd: Nomcom 2007-8: Nominations Deadline Extended to Sep 17, 2007]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 11 Sep 2007 06:13:02 -0000

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"

X-Account-Key: account2
X-Mozilla-Keys: 
Received: from xbh-ams-332.emea.cisco.com ([144.254.231.87]) by
	xmb-ams-335.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 11 Sep 2007 07:48:01 +0200
Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by
	xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 11 Sep 2007 07:48:01 +0200
Received: from sj-iport-3.cisco.com ([171.71.176.72]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 10 Sep 2007 22:47:58 -0700
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-3.cisco.com with ESMTP; 10 Sep 2007 22:47:58 -0700
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8B5lvMn012367; 
	Mon, 10 Sep 2007 22:47:57 -0700
Received: from sj-inbound-f.cisco.com (sj-inbound-f.cisco.com
	[128.107.234.207])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8B5lvoP024100;
	Tue, 11 Sep 2007 05:47:57 GMT
X-from-outside-Cisco: 156.154.16.145
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAAACrJ5UacmhCRnmdsb2JhbACOGgEBAQEHBAYPGA
X-IronPort-AV: E=Sophos;i="4.20,235,1186383600"; d="scan'208";a="29668020"
Received: from stiedprmman1.ietf.org (HELO megatron.ietf.org)
	([156.154.16.145])
	by sj-inbound-f.cisco.com with ESMTP; 10 Sep 2007 22:47:54 -0700
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IUybE-0001YZ-Te; Tue, 11 Sep 2007 01:47:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IUybC-0001YC-2p; Tue, 11 Sep 2007 01:47:46 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IUybA-0007eU-Lk; Tue, 11 Sep 2007 01:47:46 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	l8B5lhbg019844
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Sep 2007 22:47:43 -0700
Received: from [10.50.65.180] (qconnect-10-50-65-180.qualcomm.com
	[10.50.65.180])
	by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	l8B5lgNv027649
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 10 Sep 2007 22:47:42 -0700
Message-ID: <[e-mail]>
Date: Mon, 10 Sep 2007 22:47:46 -0700
From: Lakshminath Dondeti <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: [e-mail]
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -4.0 (----)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: [e-mail]
Subject: Nomcom 2007-8: Nominations Deadline Extended to Sep 17, 2007
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working Group Chairs <wgchairs.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/wgchairs>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/wgchairs>,
	<mailto:[e-mail]?subject=subscribe>
Errors-To: [e-mail]
Authentication-Results: sj-dkim-3; header.From=[e-mail];
	dkim=neutral
Return-Path: [e-mail]
X-OriginalArrivalTime: 11 Sep 2007 05:47:58.0213 (UTC)
	FILETIME=[4E953B50:01C7F437]

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 [e-mail] 
or [e-mail].

thanks,
Lakshminath


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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4D1DD80A9B for <[e-mail]>; Mon, 10 Sep 2007 04:00:38 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 76C5A142203 for <[e-mail]>; Mon, 10 Sep 2007 03:59:43 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.84
X-Spam-Level: 
X-Spam-Status: No, score=-1.84 tagged_above=-50 required=4 tests=[AWL=0.760, BAYES_00=-2.599, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id As7YC+nxFHC3 for <[e-mail]>; Mon, 10 Sep 2007 03:59:39 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id B5AE6142202 for <[e-mail]>; Mon, 10 Sep 2007 03:59:38 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.20,230,1186351200";  d="ics'?scan'208";a="152681549"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 10 Sep 2007 12:59:38 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8AAxbdA005286 for <[e-mail]>; Mon, 10 Sep 2007 12:59:37 +0200
Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8AAxREZ025181 for <[e-mail]>; Mon, 10 Sep 2007 10:59:37 GMT
Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 10 Sep 2007 12:59:34 +0200
Received: from [212.254.247.5] ([10.61.66.80]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 12:59:34 +0200
Mime-Version: 1.0 (Apple Message framework v752.3)
To: CALSIFY Mailinglist <[e-mail]>
Message-Id: <[e-mail]>
Content-Type: multipart/mixed; boundary=Apple-Mail-1-661381474
From: Eliot Lear <[e-mail]>
Date: Mon, 10 Sep 2007 12:59:38 +0200
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 10 Sep 2007 10:59:34.0410 (UTC) FILETIME=[ABF8BEA0:01C7F399]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1645; t=1189421977; x=1190285977; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20iCal=20event=20invitation=3A=20IETF=20Calsify=20Jabber=20Sess ion |Sender:=20; bh=lx7J7yuSzEkszpYKjD0+axeED3ld+weTauVQnjSrRqI=; b=mNTSLznvapMh4tf1Cnfgtg+xLsH3OqSvtnCcLhdOPJry8Z1DXMYUTwCg/pc8cVlLyoGyaw8n CPgKZ3u/9+nHNJjqxUbhAXuvADx+98z3d6dYo5nS6u/pfzUscofdBdsv;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); 
Subject: [Ietf-calsify] iCal event invitation: IETF Calsify Jabber Session
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 10 Sep 2007 11:00:38 -0000

--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:[e-mail]=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:[e-mail]=0D=0AEND:VEVENT=0D=0AEND:VCALENDAR=0D=0A=

--Apple-Mail-1-661381474--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id C7EC180A5D for <[e-mail]>; Mon, 10 Sep 2007 03:57:59 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id F10D7142203 for <[e-mail]>; Mon, 10 Sep 2007 03:57:04 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.767
X-Spam-Level: 
X-Spam-Status: No, score=-1.767 tagged_above=-50 required=4 tests=[AWL=0.698,  BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YwBN2052Xmc for <[e-mail]>; Mon, 10 Sep 2007 03:57:01 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 587AE142202 for <[e-mail]>; Mon, 10 Sep 2007 03:57:01 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.20,230,1186351200"; d="scan'208";a="152681170"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 10 Sep 2007 12:57:00 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8AAv0GZ004384 for <[e-mail]>; Mon, 10 Sep 2007 12:57:00 +0200
Received: from adsl-247-5-fixip.tiscali.ch (ams3-vpn-dhcp592.cisco.com [10.61.66.80]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8AAuxEN024097 for <[e-mail]>; Mon, 10 Sep 2007 10:57:00 GMT
Message-ID: <[e-mail]>
Date: Mon, 10 Sep 2007 12:57:05 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=79; t=1189421820; x=1190285820; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20jabber=20sessions=20to=20start=20again=20this=20thursday |Sender:=20; bh=HN5yigXDfNZJGI4TI34ghth8yhOUYmmItLDkeoHxHGs=; b=SP6ii5DsrRhZ42UdscWBEq+WegblrKhbc3c1+uRaxOqlw0tMBvhXOW0LUZve0cZ+L9IjefyN ZPEBNfyh7+vF1sGI2IbY4Kf8lBNGemx/9WoPxaYbe7/oPWvdNmwBi53S;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); 
Subject: [Ietf-calsify] jabber sessions to start again this thursday
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 10 Sep 2007 10:57:59 -0000

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

Regards,

Eliot