Subject: [Ietf-calsify] Working Group Last Call: draft-ietf-calsify-rfc2445bis-07.txt

From: lear at cisco.com (Eliot Lear)
Date: Tue Jul 10 00:13:34 2007

Dear all,

Bernard has cranked out yet another iCalendar draft, and the chairs 
would like to congratulate him on putting together an excellent 
document, and thank him for his continued efforts.  We would also like 
to thank many contributors to improving this draft, including Cyrus 
Daboo, Nigel Swinson, Jonathan Lennox, and Reinhold Kainhofer, just to 
name a few (and apologies to those who I didn't list here).

draft-ietf-calsify-rfc2445bis-07 represents over 80 issues worth of 
changes, leaving open but a small handful.  Previously, we have reviewed 
the draft issue by issue.  As the draft becomes available for your 
review, we now ask a different question: is this draft ready for 
publication as a Proposed Standard?  What issues do you see that are 
show stoppers?  We ask that you consider this with the understanding 
that best is often the enemy of great, and that it is difficult to 
satisfy everyone in a "rough consensus" process.

As such, we ask that you support the work that this group has done, 
while taking the time to ensure that the work we have done here is 
something we will be proud of years from now.  And so we open Working 
Group Last Call on this document.  This last call will last for a month, 
and end on August 10th, after which we will expect an updated draft to 
address concerns raised.  And so please note that this specification is 
subject to change in the following ways, from this point forth:

    * Rough consensus for a change; these must be discussed on the list;
    * Moving of small portions of normative text between this document
      and rfc2446bis, as this group deems logical (these must be
      discussed on this list);
    * Changes required by shepherd review (I would expect these to be
      very few in number); substantial ones must be discussed on this list;
    * Changes required to clear IETF and IESG concerns; these should be
      discussed on this list; and
    * Insubstantial editorial corrections (nits); these can be sent
      directly to the editor.

Advancing a document through the IETF process is often like a tooth 
extraction without pain killers.  However, the process is designed to 
promote technical quality.  We the chairs will do our best to smooth the 
process.

Thank you all for your efforts to make this a great document.

The Chairs
Aki Niemi
Eliot Lear
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20070710/69dbc0ed/attachment.html

---

From: sla at ucolick.org (Steve Allen)
Date: Tue Jul 10 10:32:54 2007

In the context of metrology I wonder about the text in
3.8.1.6.  Geographic Position

It says
    The longitude and
    latitude values MAY be specified up to six decimal places, which
    will allow for accuracy to within one meter of geographical
    position.

This is only true if the geodetic datum is specified.

I point out the US DoD's instructional page to soldiers on this
http://earth-info.nima.mil/GandG/publications/horizdatum.html

At a more technical level I point out the partial list of datums in
use at
http://earth-info.nima.mil/GandG/publications/tm8358.1/tr83581b.html#ZZ23
where in the links to the graphics for table 2 it is immediately
evident that some older geodetic datums upon which available maps are
based differ by hundreds of meters from the more recent,
satellite-geodesy-based datums.

In much the same vein as quoting the standards documents for UTC, if
the values used in this field are to be believed at a level of 1
meter, then it is at the least necessary to require that the latitude
and longitude values be expressed in a standard geodetic datum created
no earlier than the year 1980.

--
Steve Allen                 <[email-masked]>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

---

From: lear at cisco.com (Eliot Lear)
Date: Tue Jul 10 10:39:12 2007

Steve,

Thanks for your comment.  Can you restate your point in a succinct 
proposed textual change?

Eliot

Steve Allen wrote:
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>

---

From: mrdemeanour at jackpot.uk.net (Mr. Demeanour)
Date: Tue Jul 10 10:43:44 2007

> Thanks for your comment.  Can you restate your point in a succinct 

If I read it correctly, it doesn't call for a textual change. It's
simply pointing out that six decimal places/one meter may be spurious
precision (one could add prose to that effect, of course).
> 
> Eliot
> 
> Steve Allen wrote:
>> In the context of metrology I wonder about the text in 3.8.1.6.
>> Geographic Position
>> 
>> It says The longitude and latitude values MAY be specified up to
>> six decimal places, which will allow for accuracy to within one
>> meter of geographical position.
>> 
>> evident that some older geodetic datums upon which available maps
>> are based differ by hundreds of meters from the more recent, 
>> In much the same vein as quoting the standards documents for UTC,
>> if the values used in this field are to be believed at a level of 1
>>  meter, then it is at the least necessary to require that the
>> latitude and longitude values be expressed in a standard geodetic
>> datum created no earlier than the year 1980.
>> 
>> -- Steve Allen                 <[email-masked]>
>> WGS-84 (GPS) UCO/Lick Observatory        Natural Sciences II, Room
>> 165    Lat +36.99855 University of California    Voice: +1 831 459
>> 3046           Lng -122.06015 Santa Cruz, CA 95064
>> http://www.ucolick.org/~sla/     Hgt +250 m

---

From: sla at ucolick.org (Steve Allen)
Date: Tue Jul 10 11:13:07 2007

On Tue 2007-07-10T19:38:03 +0200, Eliot Lear hath writ:
> Can you restate your point in a succinct
> proposed textual change?

Not for sure.  As written I don't know what it means nor how I would
come to agreement with other parties about what it means.

If I give you my latitude and longitude based on the USGS topo
maps on my wall it will be off by 100 meters from the WGS-84
coordinates in my .sig.

I'm not sure how exactly GEO is intended to be used, by machines
or humans, and I'm at a loss to reconcile the historical gotchas
other than by adding several sentences.

In the absence of further input about how this is expected to be used
I suppose I would suggest something like this:

The latitude and longitude MAY be expressed in any geodetic datum, but
if the application demands 1 meter precision then the parties
exchanging the information MUST agree on a particular datum.  In the
absence of agreement the coordinates SHOULD be interpreted as any one
of ITRF, WGS-84, ETRF, or some other post-1980 satellite-based
geodetic datum (all of which agree at the level of 1 m).

Here are some refs

ITRF
http://itrf.ensg.ign.fr/

WGS-84 is defined for the US GPS system
http://en.wikipedia.org/wiki/WGS84

ETRS is a product of EUREF
http://lareg.ensg.ign.fr/EUREF/

---

From: hardie at qualcomm.com (Ted Hardie)
Date: Tue Jul 10 12:10:26 2007

>maps on my wall it will be off by 100 meters from the WGS-84

Other IETF working groups have based their work on WGS-84,
and I'd suggest that one way forward it to state that WGS-84
is the default datum.  Parties could agree to interpret this
field according to another datum, but would do so according
to a private agreement outside this spec.

Would that solve the problem?
				Ted

---

From: sla at ucolick.org (Steve Allen)
Date: Tue Jul 10 12:52:42 2007

On Tue 2007-07-10T12:09:22 -0700, Ted Hardie hath writ:
> is the default datum.

WGS-84 is more US-centric than is required by an international
specification, especially given the expectation of the Galileo
Terrestrial Reference Frame GTRF
http://www.ggsp.eu/ggsp_gtrf.html

At the level of 1 m any of them will do.

Below the level of 1 m WGS-84 has changed and as of today does not
produce the same results as it did a decade ago.  This is geodetically
akin to the leap second -- the reference point changed -- except that
in the case of GEO the current language makes it clear that nobody cares.

---

From: andrew_dowden at softdesign.net.nz (Andrew N Dowden)
Date: Wed Jul 11 03:12:06 2007

3.3.10.  Recurrence Rule

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

Should the last line read?:

     .. BYWEEKNO or BYMONTHDAY rule parts ..
or
    .. BYWEEKNO or BYYEARDAY rule parts ..

Alternatively, does this make sense as is?

  SoftDesign Group
  Dowden Software Associates
  P O Box 31 132, Lower Hutt 5040, NEW ZEALAND

---

From: mikesamuel at gmail.com (Mike Samuel)
Date: Wed Jul 11 04:31:27 2007

Doesn't
  "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"
conflict with
  "The
      numeric value in a BYDAY rule part with the FREQ rule part set to
      YEARLY ...
      when the BYWEEKNO or BYMONTH rule parts are present."
?

Other than that, the original wording makes more sense to me.  It's
saying that numeric BYDAY's are treated as weeks within the year when
you've already specified a week within the month or you're filtering
by month.

It would be nice if it specified what BYDAY meant where FREQ=YEARLY
and none of (BYMONTH,BYWEEKNO,BYYEARDAY are present, so I would prefer
the last line read

  "when the BYMONTH rule part is not present".

Specifically, I still don't see
  RRULE:FREQ=YEARLY;BYDAY=1MO
fully specified.

mike

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Wed Jul 11 18:36:35 2007

Ouch!  I omited a single little word in the last sentence...

when the BYWEEKNO or BYMONTH rule parts are *** NOT *** present.

Sorry!

Thanks,
Bernard

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Wed Jul 11 19:09:18 2007

>  "when the BYMONTH rule part is not present".

+1

As I mentionned in my last mail, I had missed the "not".
Furthermore, there is no need to mention BYWEEKNO here
since the other statement forbids its use in this context.

BTW, I don't consider issue 11 fully closed.  During the
last Jabber session we didn't go through all of Nigel's
comment.

Thanks,
Bernard

---

From: andrew_dowden at softdesign.net.nz (Andrew N Dowden)
Date: Wed Jul 11 23:24:37 2007

> when the BYWEEKNO or BYMONTH rule parts are *** NOT *** present.
Thanks, that is what I hoped ..

I was trying to determine preference between:
    RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=3MO
or
    RRULE:FREQ=YEARLY;MONTH=1;BYDAY=3MO

and pondered the meaning (if any) of:
    RRULE:FREQ=YEARLY;BYDAY=3MO

  SoftDesign Group

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Fri Jul 13 12:36:31 2007

Folks,

I have uploaded the .html and .changes.html versions of the draft
on the IETF Tools web site at the following locations:

http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-07.html

http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-07.changes.html

The .change.html version of the draft should help you figure out
exactly what was changed in RFC 2445.

Cheers,
Bernard

Eliot Lear wrote:
> ------------------------------------------------------------------------
> 

-- 
Bernard Desruisseaux | Senior Manager, Software Development | 514.905.8696
Oracle Server Technologies
600 Blvd. de Maisonneuve W., Suite 1900 | Montreal, Quebec H3A 3J2
Bernard Desruisseaux | Chef senior du d?veloppement logiciel | 514.905.8696
Oracle Technologies serveurs
600, boul. de Maisonneuve Ouest, bureau 1900 | Montr?al (Qu?bec) H3A 3J2

Date: Fri, 13 Jul 2007 15:33:40 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] Working Group Last Call:	draft-ietf-calsify-rfc2445bis-07.txt
Cc: "[email-masked]" <[email-masked]>

Folks,

I have uploaded the .html and .changes.html versions of the draft
on the IETF Tools web site at the following locations:

http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-07.html

http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-07.changes.html

The .change.html version of the draft should help you figure out
exactly what was changed in RFC 2445.

Cheers,
Bernard

Eliot Lear wrote:
> ------------------------------------------------------------------------
> 

-- 
Bernard Desruisseaux | Senior Manager, Software Development | 514.905.8696
Oracle Server Technologies
600 Blvd. de Maisonneuve W., Suite 1900 | Montreal, Quebec H3A 3J2
Bernard Desruisseaux | Chef senior du développement logiciel | 514.905.8696
Oracle Technologies serveurs
600, boul. de Maisonneuve Ouest, bureau 1900 | Montréal (Québec) H3A 3J2

Date: Thu, 12 Jul 2007 15:50:56 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] no jabber today or next week

Please send your comments on RFC2445bis to the list at this point, and 
don't forget to consider changes to RFC2446bis.

Thanks,

Eliot

Ironport-Content-Filter: send-to-smtp
Date: Thu, 12 Jul 2007 18:23:28 +1200
From: Andrew N Dowden <[email-masked]>
Organization: Dowden Software Associates
To: ietf-calsify <[email-masked]>
Subject: Re: [Ietf-calsify] 3.3.10.  Recurrence Rule - typo or ambiguity?

  SoftDesign Group

Date: Wed, 11 Jul 2007 22:07:59 -0400
From: Bernard Desruisseaux <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] 3.3.10. Recurrence Rule - typo or ambiguity?
Cc: ietf-calsify <[email-masked]>

+1

Thanks,
Bernard

>> Alternatively, does this make sense as is?

Date: Wed, 11 Jul 2007 21:34:50 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Andrew N Dowden <[email-masked]>
Subject: Re: [Ietf-calsify] 3.3.10.  Recurrence Rule - typo or ambiguity?
Cc: ietf-calsify <[email-masked]>

Sorry!

Thanks,
Bernard

> Alternatively, does this make sense as is?

Date: Wed, 11 Jul 2007 13:29:01 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-caldav list <[email-masked]>, ietf-calsify list <[email-masked]>, ietf-calendar list <[email-masked]>
Subject: [Ietf-calsify] CalDAV Scheduling Requirements paper published by CalConnect
Reply-To: [email-masked]

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

<http://www.calconnect.org/publications/caldavschedulingrequirementsv1.1.pdf>/CalDAV 
Scheduling Requirements V1.1/ has been published by the CalDAV Technical 
Committee of the Calendaring and Scheduling Consortium. It presents a 
list of features in the form of requirements for the scheduling 
extensions to CalDAV [RFC 4791], that is, the extensions to the Web 
Distributed Authoring and Versioning (WebDAV) [RFC 2518] protocol to 
specify a standard way of exchanging and processing scheduling messages 
based on the iCalendar Transport-Independent Interoperability Protocol 
(iTIP) [RFC 2446].   The document is at 
http://www.calconnect.org/publications/caldavschedulingrequirementsv1.1.pdf.
-- 
*Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium*
+1 707 840 9391 (voice) � +1 707 498 2238 (mobile)
http://www.calconnect.org � [email-masked] 
<mailto:[email-masked]>

--------------090303050507070509070308
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<a
 href="http://www.calconnect.org/publications/caldavschedulingrequirementsv1.1.pdf"></a><i>CalDAV
Scheduling Requirements V1.1</i> has been published by the CalDAV
Technical Committee of the Calendaring and Scheduling Consortium. It
presents a list of features in the form of requirements for the
scheduling extensions to CalDAV [RFC 4791], that is, the extensions to
the Web Distributed Authoring and Versioning (WebDAV) [RFC 2518]
protocol to specify a standard way of exchanging and processing
scheduling messages based on the iCalendar Transport-Independent
Interoperability Protocol (iTIP) [RFC 2446].&nbsp;&nbsp; The document is at <a
 href="http://www.calconnect.org/publications/caldavschedulingrequirementsv1.1.pdf">http://www.calconnect.org/publications/caldavschedulingrequirementsv1.1.pdf</a>.<br>
<div class="moz-signature">-- <br>
<font size="-1"><b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>
</font></div>
</body>
</html>

--------------090303050507070509070308--

Date: Wed, 11 Jul 2007 13:30:27 +0200
From: "Mike Samuel" <[email-masked]>
To: "Andrew N Dowden" <[email-masked]>
Subject: Re: [Ietf-calsify] 3.3.10. Recurrence Rule - typo or ambiguity?
Cc: ietf-calsify <[email-masked]>
Reply-To: [email-masked]

Doesn't

mike

> Alternatively, does this make sense as is?

Ironport-Content-Filter: send-to-smtp
Date: Wed, 11 Jul 2007 22:10:57 +1200
From: Andrew N Dowden <[email-masked]>
Organization: Dowden Software Associates
To: ietf-calsify <[email-masked]>
Subject: [Ietf-calsify] 3.3.10.  Recurrence Rule - typo or ambiguity?

3.3.10.  Recurrence Rule

          .. The

  SoftDesign Group

Date: Tue, 10 Jul 2007 12:51:39 -0700
From: Steve Allen <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] GEO in draft-ietf-calsify-rfc2445bis-07.txt

Date: Tue, 10 Jul 2007 12:09:22 -0700
To: Steve Allen <[email-masked]>, [email-masked]
From: Ted Hardie <[email-masked]>
Subject: Re: [Ietf-calsify] GEO in draft-ietf-calsify-rfc2445bis-07.txt

>http://lareg.ensg.ign.fr/EUREF/

Date: Tue, 10 Jul 2007 11:12:08 -0700
From: Steve Allen <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] GEO in draft-ietf-calsify-rfc2445bis-07.txt

Here are some refs

ITRF
http://itrf.ensg.ign.fr/

Date: Tue, 10 Jul 2007 18:46:03 +0100
From: "Mr. Demeanour" <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] GEO in draft-ietf-calsify-rfc2445bis-07.txt

>> http://www.ucolick.org/~sla/     Hgt +250 m 

Date: Tue, 10 Jul 2007 19:38:03 +0200
From: Eliot Lear <[email-masked]>
To: Steve Allen <[email-masked]>
Subject: Re: [Ietf-calsify] GEO in draft-ietf-calsify-rfc2445bis-07.txt
Cc: [email-masked]

Steve,

Eliot

> no earlier than the year 1980.

Date: Tue, 10 Jul 2007 10:31:46 -0700
From: Steve Allen <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] GEO in draft-ietf-calsify-rfc2445bis-07.txt

It says
    The longitude and

Date: Tue, 10 Jul 2007 09:12:27 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Working Group Last Call: draft-ietf-calsify-rfc2445bis-07.txt

This is a multi-part message in MIME format.
--------------000704080604000100050705
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

The Chairs
Aki Niemi
Eliot Lear

--------------000704080604000100050705
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
Dear all,<br>
<br>
Bernard has cranked out yet another iCalendar draft, and the chairs
would like to congratulate him on putting together an excellent
document, and thank him for his continued efforts.  We would also like
to thank many contributors to improving this draft, including Cyrus
Daboo, Nigel Swinson, Jonathan Lennox, and Reinhold Kainhofer, just to
name a few (and apologies to those who I didn't list here).<br>
<br>
draft-ietf-calsify-rfc2445bis-07 represents over 80 issues worth of
changes, leaving open but a small handful.  Previously, we have
reviewed the draft issue by issue.  As the draft
becomes available for your review, we now ask a different question: is
this draft ready for publication as a Proposed Standard?  What issues
do
you see that are show stoppers?  We ask that you consider this with the
understanding that best is often the enemy of great, and that it is
difficult to satisfy everyone in a "rough consensus" process.<br>
<br>
As such, we ask that you support the work that this group has done,
while taking the time to ensure that the work we have done here is
something we will be proud of years from now.  And so we open Working
Group Last Call on this document.  This last call will last for a
month, and end on August 10th, after which we will expect an updated
draft to address concerns raised.  And so please note that this
specification is subject to change in the
following ways, from this point forth:<br>
<ul>
  <li>Rough consensus for a change; these must be discussed on the list;</li>
  <li>Moving of small portions of normative text between this document
and rfc2446bis, as this group deems logical (these must be discussed on
this list); <br>
  </li>
  <li>Changes required by shepherd review (I would expect these to be
very few in number); substantial ones must be discussed on this list;<br>
  </li>
  <li>Changes required to clear IETF and IESG concerns; these should be
discussed on this list; and<br>
  </li>
  <li>Insubstantial editorial corrections (nits); these can be sent
directly to the editor.</li>
</ul>
Advancing a document through the IETF process is often like a tooth
extraction without pain killers.  However, the process is designed to
promote technical quality.  We the chairs will do our best to smooth
the process.<br>
<br>
Thank you all for your efforts to make this a great document.<br>
<br>
The Chairs<br>
Aki Niemi<br>
Eliot Lear
</body>
</html>

--------------000704080604000100050705--

Date: Tue, 10 Jul 2007 09:03:55 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] draft agenda

1.  Agenda Bashing (1 minute)
2.  Administrativia (Chairs - 3 minutes)
3.  RFC2445bis Status (Chairs - 5 minutes)
4.  RFC2446bis Discussion (Cyrus - the rest)

To: [email-masked]
From: [email-masked]
Date: Mon, 09 Jul 2007 17:15:01 -0400
Cc: [email-masked]
Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-07.txt 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Calendaring and Scheduling Standards Simplification Working Group of the IETF.

	Title		: Internet Calendaring and Scheduling Core Object Specification (iCalendar)
	Author(s)	: B. Desruisseaux
	Filename	: draft-ietf-calsify-rfc2445bis-07.txt
	Pages		: 177
	Date		: 2007-7-9
	
This document defines the iCalendar data format for representing and
   exchanging calendaring and scheduling information such as events, to-
   dos, journal entries and free/busy information, independent of any
   particular calendar service or protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-07.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-calsify-rfc2445bis-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-calsify-rfc2445bis-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-calsify-rfc2445bis-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-calsify-rfc2445bis-07.txt"; site="ftp.ietf.org";
	access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

Date: Mon, 09 Jul 2007 13:07:08 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] tracker is back up

http://www.ofcourseimright.com/cgi-bin/roundup/calsify/

Date: Fri, 06 Jul 2007 18:33:25 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-calendar list <[email-masked]>, ietf-calsify list <[email-masked]>, ietf-caldav list <[email-masked]>
Subject: [Ietf-calsify] My apologies for multiple CalConnect-related postings
Reply-To: [email-masked]

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

I seem to have screwed up somehow and posted our announcement of the 
vCard workshop and possibly the next Roundtable multiple times to at 
least one of these lists.

And to make it worse, many people are subscribed to two or more of them, 
and thus got an unnecessary flood of repeats.

I apologize for the mistake, however it occurred, and will do my best to 
not do it again.  I hope that the irritant didn't overcome the messages!

Apologies again,

Dave Thewlis
-- 
*Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium*
+1 707 840 9391 (voice) � +1 707 498 2238 (mobile)
http://www.calconnect.org � [email-masked] 
<mailto:[email-masked]>

--------------030804020304020806040400
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
I seem to have screwed up somehow and posted our announcement of the
vCard workshop and possibly the next Roundtable multiple times to at
least one of these lists.<br>
<br>
And to make it worse, many people are subscribed to two or more of
them, and thus got an unnecessary flood of repeats.<br>
<br>
I apologize for the mistake, however it occurred, and will do my best
to not do it again.&nbsp; I hope that the irritant didn't overcome the
messages!<br>
<br>
Apologies again,<br>
<br>
Dave Thewlis<br>
<div class="moz-signature">-- <br>
<font size="-1"><b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>
</font></div>
</body>
</html>

--------------030804020304020806040400--

Date: Fri, 06 Jul 2007 10:17:14 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: calconnect-l Reflector <[email-masked]>, ietf-calsify list <[email-masked]>
Subject: [Ietf-calsify] CalConnect vCard Workshop - September 18, 2007 - Cambridge, Massachusetts
Reply-To: [email-masked]

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

CalConnect invites you to a a one-day open workshop on vCard and what 
should be done about it on Tuesday, September 18, 2007, at M.I.T. in 
Cambridge, Massachusetts. This event is _open_ to vendors, customers, 
CalConnect members and non-members alike. There is no fee, but you 
_must_ register in advance and numbers are limited. Please see
http://www.calconnect.org/vcardworkshop.shtml for more information and 
links to the registration <http://www.calconnect.org/vcardreg.shtml> and 
logistics <http://www.calconnect.org/vcardworkshoplogistics.shtml> 
pages, a general discussion list 
<http://www.calconnect.org/vcardworkshoplist.shtml> about the workshop, 
and a questionnaire <http://www.calconnect.org/vcardquestionnaire.shtml> 
to give us more guidance to make the workshop as productive as possible.

 From the workshop introduction page:

vCard is a well established standard for representing and transferring 
contact information on computer systems and mobile devices. Having been 
in use for a while, a number of areas of the specification have been 
noted as problematic and in need of revision for fixes or enhancements. 
To that end, CalConnect (the Calendaring & Scheduling Consortium) is 
hosting a one day vCard-focused workshop event at M.I.T. in Cambridge, 
Massachusetts in September with the goal of bringing together the key 
players to help move forward vCard revision efforts.

Note that an effort is already under way at the IETF (Internet 
Engineering Task Force) to develop a personal address book access 
protocol based on the CardDAV specification, and since that is based on 
vCard, a revision of the vCard specification will be taking place within 
the IETF. However, bringing together interested parties in a focused 
discussion at a workshop can help drive that effort and provide 
supporting input to it to ensure the specific needs of the key players 
is covered.

The goal of the workshop is two-fold. First to determine the real 
interest in revising the vCard specification, and second to determine 
what needs to be revised and how to go about doing that.

If you are not a CalConnect member, this is also an opportunity to stay 
on for Roundtable X <http://www.calconnect.org/roundtable10.shtml> as an 
observer, and we'd be delighted to have you; you will have to register 
separately for the Roundtable. 

Regardless of whether or not you are interested in attending the 
workshop, we would appreciate it very much if you would take a few 
minutes to fill out the questionnaire 
<http://www.calconnect.org/vcardquestionnaire.shtml>, as this will help 
provide the workshop participants with guidance as to the directions any 
progression on vCard should take.

-- 
*Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium*
+1 707 840 9391 (voice) � +1 707 498 2238 (mobile)
http://www.calconnect.org � [email-masked] 
<mailto:[email-masked]>

--------------000102050701090000030408
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
CalConnect invites you to a a one-day open workshop on vCard and what
should be done about it on Tuesday, September 18, 2007, at M.I.T. in
Cambridge, Massachusetts. This event is <u>open</u> to vendors,
customers, CalConnect members and non-members alike. There is no fee,
but you <u>must</u> register in advance and numbers are limited.
Please see <br>
<a href="http://www.calconnect.org/vcardworkshop.shtml">http://www.calconnect.org/vcardworkshop.shtml</a>
for more information and links to the <a
 href="http://www.calconnect.org/vcardreg.shtml">registration</a> and <a
 href="http://www.calconnect.org/vcardworkshoplogistics.shtml">logistics</a>
pages, a general <a
 href="http://www.calconnect.org/vcardworkshoplist.shtml">discussion
list</a> about the workshop, and a <a
 href="http://www.calconnect.org/vcardquestionnaire.shtml">questionnaire</a>
to give us more guidance to make the workshop as productive as possible.<br>
<br>
>From the workshop introduction page:<br>
<br>
<font color="#330099"><small>vCard is a well established standard for
representing and transferring contact information on computer systems
and mobile devices. Having been in use for a while, a number of areas
of the specification have been noted as problematic and in need of
revision for fixes or enhancements. To that end, CalConnect (the
Calendaring &amp; Scheduling Consortium) is hosting a one day
vCard-focused workshop event at M.I.T. in Cambridge, Massachusetts in
September with the goal of bringing together the key players to help
move forward vCard revision efforts.<br>
<br>
Note that an effort is already under way at the IETF (Internet
Engineering Task Force) to develop a personal address book access
protocol based on the CardDAV specification, and since that is based on
vCard, a revision of the vCard specification will be taking place
within the IETF. However, bringing together interested parties in a
focused discussion at a workshop can help drive that effort and provide
supporting input to it to ensure the specific needs of the key players
is covered.<br>
<br>
The goal of the workshop is two-fold. First to determine the real
interest in revising the vCard specification, and second to determine
what needs to be revised and how to go about doing that.</small></font><br>
<br>
<br>
If you are not a CalConnect member, this is also an opportunity to stay
on for <a href="http://www.calconnect.org/roundtable10.shtml">Roundtable
X</a> as an observer, and we'd be delighted to have you; you will have
to register separately for the Roundtable.&nbsp; <br>
<br>
Regardless of whether or not you are interested in attending the
workshop, we would appreciate it very much if you would take a few
minutes to fill out the <a
 href="http://www.calconnect.org/vcardquestionnaire.shtml">questionnaire</a>,
as this will help provide the workshop participants with guidance as to
the directions any progression on vCard should take.<br>
<br>
<br>
<div class="moz-signature">-- <br>
<font size="-1"><b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>
</font></div>
</body>
</html>

--------------000102050701090000030408--

Date: Fri, 06 Jul 2007 09:50:53 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-calsify list <[email-masked]>
Subject: [Ietf-calsify] Announcing CalConnect Roundtable X and Interoperability Test Event -September 17-21, Cambridge, Massachusetts
Reply-To: [email-masked]

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

*The Calendaring and Scheduling Consortium announces Roundtable X and  
IOP Test Event

*CalConnect would like to invite you to our Roundtable X and the 
associated CalConnect Interoperability Test Event, the week of September 
17-21, 2007, in Cambridge, Massachusetts, hosted by M.I.T.  Registration 
is now open for the Roundtable and/or the IOP test event.  Logistics and 
registration information may be found at 
http://www.calconnect.org/roundtable10.shtml and at 
http://www.calconnect.org/iopseptember2007.shtml

General schedule:  The IOP test will begin at noon Monday and run 
through noon Wednesday.  The Roundtable will begin at lunch on Wednesday 
and run through lunch on Friday.  We plan to offer optional practicums 
on the iCalendar RFCs (iCalendar/iTIP/iMIP) and on CalDAV on Wednesday 
morning prior to lunch. 

The IOP test event will involve both CalDAV and regular iCalendar, iMIP 
and iTIP interoperability testing scenarios.  In addition, plans and 
preliminary work for a Mobile Calendar IOP Test Event, and the scenarios 
associated with that event, will be covered.

Roundtables are largely comprised of technical committee sessions, which 
generally include reports on work accomplished or in progress, working 
sessions in a "committee of the whole" environment for all interested 
parties, and discussions about work to be undertaken.  Time is also set 
aside for BOFs either scheduled in advance, or impromptu at the meeting.

If you are not currently a member of the Consortium, you may attend a 
single Roundtable, or a single IOP test event, as an observer; see 
http://www.calconnect.org/observer.shtml for more information.

Both members and non-members may participate in the IOP test events.

If you think you might attend, it is advisable to book your hotel room 
early -- hotel rooms in Cambridge in September are hard to come by.

For more information, please call or e-mail me as below.

See you in Cambridge!

Dave Thewlis

-- 
*Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium*
+1 707 840 9391 (voice) � +1 707 498 2238 (mobile)
http://www.calconnect.org � [email-masked] 
<mailto:[email-masked]>

--------------060007090201050100040500
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">
<b>The Calendaring and Scheduling Consortium announces Roundtable X
and&nbsp; IOP Test Event<br>
<br>
</b>CalConnect would like to invite you to our Roundtable X and the
associated CalConnect Interoperability Test Event, the week of
September 17-21, 2007, in Cambridge, Massachusetts, hosted by M.I.T.&nbsp;
Registration is now open for the Roundtable and/or the IOP test event.&nbsp;
Logistics and registration information may be found at <a
 href="http://www.calconnect.org/roundtable10.shtml">http://www.calconnect.org/roundtable10.shtml</a>
and at <a href="http://www.calconnect.org/iopseptember2007.shtml">http://www.calconnect.org/iopseptember2007.shtml</a><br>
<br>
General schedule:&nbsp; The IOP test will begin at noon Monday and run
through noon Wednesday.&nbsp; The Roundtable will begin at lunch on
Wednesday and run through lunch on Friday.&nbsp; We plan to offer optional
practicums on the iCalendar RFCs (iCalendar/iTIP/iMIP) and on CalDAV on
Wednesday morning prior to lunch.&nbsp; <br>
<br>
The IOP test event will involve both CalDAV and regular iCalendar, iMIP
and iTIP interoperability testing scenarios.&nbsp; In addition, plans and
preliminary work for a Mobile Calendar IOP Test Event, and the
scenarios associated with that event, will be covered.<br>
<br>
Roundtables are largely comprised of technical committee sessions,
which generally include reports on work accomplished or in progress,
working sessions in a "committee of the whole" environment for all
interested parties, and discussions about work to be undertaken.&nbsp; Time
is also set aside for BOFs either scheduled in advance, or impromptu at
the meeting.<br>
<br>
If you are not currently a member of the Consortium, you may attend a
single Roundtable, or a single IOP test event, as an observer; see <a
 href="http://www.calconnect.org/observer.shtml">http://www.calconnect.org/observer.shtml</a>
for more information.<br>
<br>
Both members and non-members may participate in the IOP test events.<br>
<br>
If you think you might attend, it is advisable to book your hotel room
early -- hotel rooms in Cambridge in September are hard to come by.<br>
<br>
For more information, please call or e-mail me as below.<br>
<br>
See you in Cambridge!<br>
<br>
Dave Thewlis<br>
<br>
<div class="moz-signature">-- <br>
<font size="-1"><b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>
</font></div>
</body>
</html>

--------------060007090201050100040500--

Date: Thu, 05 Jul 2007 22:27:48 -0400
From: Cyrus Daboo <[email-masked]>
To: Calsify <[email-masked]>
Subject: [Ietf-calsify] Updated recurrence rule table

--==========052CEC7FF3409C7C28B1==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi folks,
During today's jabber session we discussed in detail Nigel Swinson's 
comments on the recurrence rule table I posted a while back. Whilst we have 
not gone through all his comments, there were some obvious fixes to the 
table and notes that needed to be done, and those are attached to this 
message. You can see the full discussion at: 
<http://www3.ietf.org/meetings/ietf-logs/calsify/2007-07-05.html>.

-- 
Cyrus Daboo

--==========052CEC7FF3409C7C28B1==========
Content-Type: text/plain; charset=utf-8; name="RRULEs processing"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="RRULEs processing"; size=5439

RRULE Processing

A particular BYxxx rule part may expand or limit the set of date/times =
generated by the rule. The expand or limit behaviour is governed by the =
FREQ value used for the rule.

Example:

	RRULE:FREQ=3DMONTHLY;BYMONTH=3D1,3,5;BYDAY=3DMO,TU

		The FREQ=3DMONTHLY value would match each of the twelve
		months in a year.

		The BYMONTH=3D1,3,5 rule part limits the matching months to just
		the 1st, 3rd and 5th in a year.

		The BYDAY=3DMO,TU rule part adds each Monday and Tuesday within
		the matching months to the recurrence set.

The table below shows the dependency of BYxxx rule part expand or limit =
behaviour on the FREQ value in the rule. When evaluating a rule, each BYxxx =
rule part MUST be evaluated in the order it appears in the table (i.e. =
BYMONTH evaluated before BYWEEKNO), irrespective of the expand or limit =
behaviour.

The term "N/A" means that the corresponding BYxxx rule part MUST NOT be =
used with the corresponding FREQ value.

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  | Limit  | Limit  | Limit  | Limit  | Limit  | 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  | Note 1 | Note 2  | Note 3 =
|
|----------+--------+--------+--------+--------+--------+---------+--------|=

|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 | Special expand for WEEKLY.                                |
|        |                                                           |
|        | A BYDAY rule part cannot have a numeric value in a        |
|        | FREQ=3DWEEKLY rule (i.e. 'MO', 'TU' etc is allowed, but     |
|        | '1MO', '2TU' is not allowed).                             |
|        |                                                           |
+--------+-----------------------------------------------------------|
| Note 2 | Limit if BYMONTHDAY is present, otherwise special expand  |
|        | for MONTHLY.                                              |
|        |                                                           |
|        | The numeric value in a BYDAY rule part in a FREQ=3DMONTHLY  |
|        | rule corresponds to an offset within the month.           |
|        |                                                           |
+--------+-----------------------------------------------------------|
| Note 3 | 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.                      |
|        |                                                           |
|        | A BYDAY rule part cannot have a numeric value in a        |
|        | FREQ=3DYEARLY rule (i.e. 'MO', 'TU' etc is allowed, but     |
|        | '1MO', '2TU' is not allowed), if BYWEEKNO is specified.   |
|        |                                                           |
|        | The numeric value in a BYDAY rule part in a FREQ=3DYEARLY   |
|        | rule with a BYMONTH present corresponds to an offset      |
|        | within the month.                                         |
|        |                                                           |
|        | The numeric value in a BYDAY rule part in a FREQ=3DYEARLY   |
|        | rule without BYWEEKNO or BYMONTH present corresponds to   |
|        | an offset within the year.                                |
|        |                                                           |
+--------+-----------------------------------------------------------+

--==========052CEC7FF3409C7C28B1==========--

Date: Thu, 05 Jul 2007 16:51:26 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.8.7.2 Date/Time Stamp: Purpose of DTSTAMP in the context of calendaring
Cc: Calsify WG <[email-masked]>

Cyrus Daboo wrote:
> Hi Bernard,
> 
> --On July 5, 2007 12:59:59 AM -0400 Bernard Desruisseaux 
> <[email-masked]> wrote:
> 
>> New text:
>>
>>  > 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.
> 
> Well "calendar store" is not defined anywhere.

I'm simply using the same terminology that is used in RFC 2445
when describing the "LAST-MODIFIED" property.

> Plus if I happen to use 
> iCalendar format as the native format in my calendar store this would 
> not hold true - i.e. DTSTAMP would not change when the calendar data 
> changed.

Whoever changes the iCalendar object should change the value of the
DTSTAMP property.  If a calendar user agent modifies an iCalendar
object in its local calendar store it should update the value of
DTSTAMP.  When a CalDAV client modifies an iCalendar object and
uploads it to a CalDAV server it should update the value of the
DTSTAMP property before uploading it to the server. Whether iCalendar
is used as the native format in your calendar store does not matter.

> 
> I am also a little unsure of what "created" means in the METHOD case.

Again, I simply used the same terminology that is used in RFC 2445.

> For instance, in at least one implementation I have done I create the 
> iTIP message for an event by copying that event. Are you saying that 
> when that happens a new DTSTAMP must be used?

My understanding is that DTSTAMP should be set to the time when a
iTIP messages is created/generated/rendered.

> If so, I think the term 
> "generated" might be better than "created".

I agree.  We should update the description of LAST-MODIFIED as well.

> Or we should be much more 
> explicit. In fact perhaps iTIP should state that every new iTIP message, 
> be it a PUBLISH, REQUEST, REPLY etc MUST have a new DTSTAMP generated 
> for it.

Ok.

> If we go down that route then maybe 2445 needs to say nothing 
> about DTSTAMP + METHOD.

But then how would DTSTAMP differ from LAST-MODIFIED in RFC2445?

Cheers,
Bernard

From: "Tim Hare" <[email-masked]>
To: "'Bernard Desruisseaux'" <[email-masked]>, "'Calsify WG'" <[email-masked]>
Subject: RE: [Ietf-calsify] Section 4.8.7.2 Date/Time Stamp: Purpose of DTSTAMPin the context of calendaring
Date: Thu, 5 Jul 2007 10:14:49 -0400

Sorry I can't make Jabber sessions, but here is an alternative text idea
regarding DTSTAMP.

Old text:

 > Purpose: The property indicates the date/time that the instance
 >    of the iCalendar object was created.

New text:

 > Purpose:  This property is used to determine the correct version of an
iCalendar
 > object to use, when presented with two different versions of the same
object. For
 > example, two iTIP REQUESTs to change meeting time for the same meeting
arrive,
 > or two different files with METHOD:PUBLISH are found describing the same
events. 
 > The object with the later DTSTAMP identifies the most recent copy and
MUST be used. 

With this new text, I would leave the old text about CREATED and
LAST-MODIFIED alone.

Tim Hare
Interested Bystander, Non-Inc.

Date: Thu, 05 Jul 2007 15:57:06 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] jabber starts shortly

[email-masked]

Date: Thu, 05 Jul 2007 09:23:23 -0400
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.8.7.2 Date/Time Stamp: Purpose of DTSTAMP	in the context of calendaring

Hi Bernard,

--On July 5, 2007 12:59:59 AM -0400 Bernard Desruisseaux 
<[email-masked]> wrote:

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

Well "calendar store" is not defined anywhere. Plus if I happen to use 
iCalendar format as the native format in my calendar store this would not 
hold true - i.e. DTSTAMP would not change when the calendar data changed.

I am also a little unsure of what "created" means in the METHOD case. For 
instance, in at least one implementation I have done I create the iTIP 
message for an event by copying that event. Are you saying that when that 
happens a new DTSTAMP must be used? If so, I think the term "generated" 
might be better than "created". Or we should be much more explicit. In fact 
perhaps iTIP should state that every new iTIP message, be it a PUBLISH, 
REQUEST, REPLY etc MUST have a new DTSTAMP generated for it. If we go down 
that route then maybe 2445 needs to say nothing about DTSTAMP + METHOD.

-- 
Cyrus Daboo

Date: Thu, 05 Jul 2007 00:59:59 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.8.7.2 Date/Time Stamp: Purpose of DTSTAMP in the context of calendaring

Here's the exact text change for this proposal.

Old text:

 > Purpose: The property indicates the date/time that the instance
 >    of the iCalendar object was created.

New text:

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

Old text:

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

New text:

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

Cheers,
Bernard

Bernard Desruisseaux wrote:
> In section 4.8.7.2 Date/Time Stamp of RFC 2445 it says:
> 
>  > Purpose: The property indicates the date/time that the instance of
>  > the iCalendar object was created.
>  >
>  > [...]
>  >
>  > Description: The value MUST be specified in the UTC time format.
>  >
>  > This property is also useful to protocols such as [IMIP] that have
>  > inherent latency issues with the delivery of content. This property
>  > will assist in the proper sequencing of messages containing iCalendar
>  > objects.
>  >
>  > 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.
> 
> As was discussed at the Calsify WG meeting in Prague, I believe we
> need to clarify the purpose of the "DTSTAMP" property.
> 
> I believe the current definition of the "DTSTAMP" property make
> sense in the context of scheduling, but not so for calendaring
> (i.e., calendar access).
> 
> According to the current definition, a CalDAV server that doesn't
> store the iCalendar representation of calendar resources should
> always return iCalendar objects with the "DTSTAMP" property set to
> the current time with the consequence that the ETag (see section
> 3.11 Entity Tags of RFC 2616) of all the calendar resources would
> change every second! Clearly, no serious CalDAV server implementation
> would do such a thing. Returning iCalendar objects with the "DTSTAMP"
> property set to the last modification time of the calendar resource
> would seem more appropriate.
> 
> One way to address this issue would be to make the "DTSTAMP" property
> optional in all calendar components in the iCalendar specifications,
> but to make it mandatory in all calendar components in the iTIP
> specification. Actually, it might have been the original intent.
> RFC 2445 was ambiguous on whether "DTSTAMP" is mandatory or optional.
> (see issues 37, 38, 39 and 40). iTIP, on the other hand, was clear
> that "DTSTAMP" is required in all calendar components.
> 
> In my opinion, we should not go back on the consensus made earlier
> by this WG to clarify that "DTSTAMP" is required in all calendar
> components. Some calendaring applications may actually find it useful
> to always have a "DTSTAMP" property in all calendar components.
> Remember that the "LAST-MODIFIED" property is optional in all calendar
> components.
> 
> In order to address this issue in a way that preserves backward
> compatibility with existing iCalendar applications, I propose to
> modify the definition of the "DTSTAMP" property to specify that in
> the context of calendaring (i.e., iCalendar object with no "METHOD"
> property) its value may be set to the date and time that the calendar
> component was last revised in the calendar store (i.e., same
> definition as LAST-MODIFIED), but that in the context of scheduling
> its value should be set to the date and time where the scheduling
> message (i.e., iCalendar object with a METHOD property) was created.
> 
> Cheers,
> Bernard

-- 
Bernard Desruisseaux | Senior Manager, Software Development | 514.905.8696
Oracle Server Technologies
600 Blvd. de Maisonneuve W., Suite 1900 | Montreal, Quebec H3A 3J2
Bernard Desruisseaux | Chef senior du d�veloppement logiciel | 514.905.8696
Oracle Technologies serveurs
600, boul. de Maisonneuve Ouest, bureau 1900 | Montr�al (Qu�bec) H3A 3J2

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: Should we bring back the RANGE parameter?
Date: Wed, 4 Jul 2007 22:19:45 +0200

Am Mittwoch, 4. Juli 2007 schrieb Cyrus Daboo:
> Hi Bernard,
>
> --On July 4, 2007 11:46:33 AM -0400 Bernard Desruisseaux
>
> <[email-masked]> wrote:
> > At the last Jabber session you said you were tempted to bring back the
> > RANGE parameter to allow an Organizer to cancel all future recurrence
> > instances of a recurring component defined with an unbounded RRULE.

Apart from the technical issues and the semantics, looking at a practical 
point: 
How many calendaring applications and server have implemented or might be 
using the RANGE concept now or in the future?

Cheers,
Reinhold

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

Date: Wed, 04 Jul 2007 22:15:28 +0200
From: Eliot Lear <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] tracker is down for now

i've had database problems.  i am still working to get them up.  
apologies for the inconvenience.

Date: Wed, 04 Jul 2007 15:17:04 -0400
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Cc: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Re: Should we bring back the RANGE parameter?

Hi Bernard,

--On July 4, 2007 11:46:33 AM -0400 Bernard Desruisseaux 
<[email-masked]> wrote:

> At the last Jabber session you said you were tempted to bring back the
> RANGE parameter to allow an Organizer to cancel all future recurrence
> instances of a recurring component defined with an unbounded RRULE.
>
> While I understand that most applications don't handle arbitrary
> modifications to the RRULE property nicely, I believe it shouldn't
> be difficult to handle truncation of unbounded RRULE properly with
> the simple addition of a COUNT or UNTIL rule part.

There is a semantic difference between sending a REQUEST that changes a 
rule vs sending a CANCEL to remove instances.

Consider: an existing event with a series of overridden instances. The 
attendee's client will have the master event stored with the rrule, plus 
all the instances. Now the Organizer sends out a CANCEL that uses RANGE - 
in that case it is obvious that any overridden instances whose 
RECURRENCE-ID overlaps the RANGE are to be removed. Now consider the 
alternative you propose: in that case the Organizer has to send not only 
the modified master event with the RRULE but also ALL overridden instances 
that are not being cancelled. That would be very inefficient.

So the important thing here is that its better to update a recurring event 
in iTIP by sending diffs. As soon as you try and change the rule you have 
to send out the entire set of valid instances. CANCEL, ADD and a REQUEST 
that uses RECURRENCE-ID are effectively "diffs" to the original set.

In any case it is not just CANCEL that is an issue here. A more common case 
is an ongoing meeting where the location changes, or where an attendee is 
added or removed and those changes are ongoing. How do you do that without 
RANGE=THISANDFUTURE?

I realize that there are issues with multiple RANGE's in the same event 
set, but how else can we support a use case like this?

I believe that we can pin down the semantics of RANGE=THISANDFUTURE enough 
to do what we need (I don't care about THISANDPRIOR).

-- 
Cyrus Daboo

Date: Wed, 04 Jul 2007 11:46:33 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Should we bring back the RANGE parameter?

Cyrus,

At the last Jabber session you said you were tempted to bring back the
RANGE parameter to allow an Organizer to cancel all future recurrence
instances of a recurring component defined with an unbounded RRULE.

While I understand that most applications don't handle arbitrary
modifications to the RRULE property nicely, I believe it shouldn't
be difficult to handle truncation of unbounded RRULE properly with
the simple addition of a COUNT or UNTIL rule part.

In my opinion, this would be much simpler than trying to address
the 4 issues that were raised with the RANGE parameter in the
following thread:

http://lists.osafoundation.org/pipermail/ietf-calsify/2006-October/001239.html

and, more importantly, expect applications to support it.

Cheers,
Bernard