Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12
From: Julian Reschke <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Cc: [email-masked], CalDAV DevList <[email-masked]>
Date: Thu, 27 Apr 2006 22:42:03 +0200
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>

Lisa Dusseault wrote:
> Thanks for the input.  Speaking as a document author here, I'm confident 
> we've made a decent set of tradeoffs, balancing possible risks against 
> benefits, and attempting to minimize the risks too.
> 
> The basic risk is that any requirements related to ETags may conflict 
> with future requirements.  We've attempted to minimize this risk by 
> making only one requirement -- that servers MUST NOT return strong ETags 
> if they have changed the data provided to be stored.  We believe that 
> this requirement is quite within the spirit of ETag design.   We didn't 
> make any requirements about weak ETags, nor did we require any behavior 
> that future specs might make illegal.  Since today with HTTP it's 
> perfectly acceptable not to return an ETag at all, future requirements 
> on ETags would at least have to work with a huge deployed base of HTTP 
> servers that don't return any ETag on PUT responses.
> 
> Thus, any future ETag-related requirements that invalidated this CalDAV 
> requirement, would also conflict with the huge deployed base of HTTP.  I 

How so?

A potential requirement of an XyzDav spec to return ETags even though 
the content was rewritten wouldn't be in conflict with HTTP at all. It 
would just be impossible to implement a resource that's both compliant 
to CalDAV and XyzDav.

This is why I think CalDav uses the wrong approach. There's a simple way 
to give CalDav clients that piece of information and which is guaranteed 
to be compatible with other specs, and that's what CalDav should do.

Or, alternatively, it could just stay silent and let that other spec 
work out the solution, instead of trying to come up with a fait accompli.

 > ...

Best regards, Julian

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12
Date: Thu, 27 Apr 2006 13:25:54 -0700
To: Julian Reschke <[email-masked]>
Cc: [email-masked], CalDAV DevList <[email-masked]>

Thanks for the input.  Speaking as a document author here, I'm  
confident we've made a decent set of tradeoffs, balancing possible  
risks against benefits, and attempting to minimize the risks too.

The basic risk is that any requirements related to ETags may conflict  
with future requirements.  We've attempted to minimize this risk by  
making only one requirement -- that servers MUST NOT return strong  
ETags if they have changed the data provided to be stored.  We  
believe that this requirement is quite within the spirit of ETag  
design.   We didn't make any requirements about weak ETags, nor did  
we require any behavior that future specs might make illegal.  Since  
today with HTTP it's perfectly acceptable not to return an ETag at  
all, future requirements on ETags would at least have to work with a  
huge deployed base of HTTP servers that don't return any ETag on PUT  
responses.

Thus, any future ETag-related requirements that invalidated this  
CalDAV requirement, would also conflict with the huge deployed base  
of HTTP.  I find that sufficiently unlikely as to be an acceptable  
risk to take.  Any standard we write has some risk of making  
requirements that are in conflict with future spec requirements and  
so we always take this kind of risk.

I do hope that new work on ETags and PUT will clarify this situation  
further for all protocols, and if it becomes desirable to re-issue  
CalDAV to make use of that general work, I'll be happy to re-issue it.

Lisa

On Apr 27, 2006, at 3:30 AM, Julian Reschke wrote:

> Hi,
>
> I note that draft 12 of caldav still makes requirements that are  
> potentially incompatible with HTTP:
>
> Quoting <http://greenbytes.de/tech/webdav/draft-dusseault- 
> caldav-12.html#rfc.section.5.3.4.p.4>:
>
> "In the case where the data stored by a server as a result of a PUT  
> request is not equivalent by octet equality to the submitted  
> calendar object resource, the behavior of the ETag response header  
> is undefined, with the exception that a strong entity tag MUST NOT  
> be returned in the response. As a result, clients may need to  
> retrieve the modified calendar object resource (and ETag) as a  
> basis for further changes, rather than use the calendar object  
> resource it had sent with the PUT request."
>
> This is a requirement that is not in RFC2616. Adding this to CalDav  
> may make it impossible to implement resources that are both  
> compliant to CalDav and other HTTP based specifications (which may  
> have a different opinion about ETags in PUT responses).
>
> If CalDav clients *really* require knowledge about this situation,  
> please define it in a way that will not potentially be in conflict  
> with other specifications, such as by adding a *new* response  
> header, indicating that content was not rewritten (as proposed in  
> <http://lists.osafoundation.org/pipermail/ietf-caldav/2006-April/ 
> 000787.html> two weeks ago).
>
> Best regards, Julian
>
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Thu, 27 Apr 2006 10:21:50 -0400
From: Bernard Desruisseaux <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] [Fwd: Last Call: 'Calendaring Extensions to WebDAV (CalDAV)' to Proposed Standard (draft-dusseault-caldav)]

-------- Original Message --------
Subject: Last Call: 'Calendaring Extensions to WebDAV (CalDAV)' to Proposed  Standard (draft-dusseault-caldav)
Date: Wed, 26 Apr 2006 17:01:38 -0400
From: The IESG <[email-masked]>
Reply-To: [email-masked]
To: IETF-Announce <[email-masked]>

The IESG has received a request from an individual submitter to consider the
following document:

- 'Calendaring Extensions to WebDAV (CalDAV) '
    <draft-dusseault-caldav-12.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2006-05-24.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-dusseault-caldav-12.txt

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce

Date: Thu, 27 Apr 2006 10:21:32 -0400
From: Bernard Desruisseaux <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] [Fwd: I-D ACTION:draft-dusseault-caldav-12.txt]

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

-------- Original Message --------
Subject: I-D ACTION:draft-dusseault-caldav-12.txt
Date: Wed, 26 Apr 2006 15:50:01 -0400
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Calendaring Extensions to WebDAV (CalDAV)
	Author(s)	: L. Dusseault, et al.
	Filename	: draft-dusseault-caldav-12.txt
	Pages		: 109
	Date		: 2006-4-26
	
This document specifies a set of methods, headers, message bodies,
properties, and reports that define calendar access extensions to the
WebDAV protocol.  The new protocol elements are intended to make
WebDAV-based calendaring and scheduling an interoperable standard
that supports calendar access, calendar management, calendar sharing,
and calendar publishing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-dusseault-caldav-12.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-dusseault-caldav-12.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-dusseault-caldav-12.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.

--------------020309050503000001020909
Content-Type: Message/External-body;
 name="draft-dusseault-caldav-12.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-dusseault-caldav-12.txt"

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

--------------020309050503000001020909
Content-Type: text/plain;
	name*0="file:///C|/DOCUME%7E1/BDESRU%7E1.ST-/LOCALS%7E1/TEMP/nsmail.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
	filename*0="file:///C|/DOCUME%7E1/BDESRU%7E1.ST-/LOCALS%7E1/TEMP/nsmail.";
	filename*1="txt"

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--------------020309050503000001020909--

Date: Thu, 27 Apr 2006 09:37:16 -0400
From: Bernard Desruisseaux <[email-masked]>
To: venkat <[email-masked]>
Subject: Re: [Ietf-caldav] caldav protocol - doubt
Cc: [email-masked]

Hi Venkat,

The CALDAV:time-range XML element specifies a search criteria. That
is, a condition a calendar object resource must match in order to be
returned in a calendaring report response.

The CALDAV:limit-freebusy-set XML element specifies which FREEBUSY
property values of a VFREEBUSY component should be returned in a
calendaring report response.

Here's 2 different use cases:

If you are only interested in free busy information in a given time
range, you would specify this time range in the CALDAV:time-range
XML element nested in the CALDAV:filter element in order to select
all the VFREEBUSY components that contain free busy information in
that time range, and you would also specify the same time range in
the CALDAV:limit-freebusy-set XML element to filter out the FREEBUSY
property outside the time range that is of interest to you.

If you are searching for VFREEBUSY components that defines FREEBUSY
property values in a given time range and that you want you want to
receive all the FREEBUSY property values of the matched VFREEBUSY
components (i.e., even the FREEBUSY property values outside your
specified time range), but that your CalDAV client only supports
date values between 1990 and 2038, you might want to specify this
time range in the CALDAV:limit-freebusy-set to avoid receiving
FREEBUSY property values outside this time range.

Cheers,
Bernard

venkat wrote:
> 
> 
> Hi,
> 
> I am trying to understand the CalDAV protocol and build a small prototype.
> 
> In the following example, why are two time ranges(limit-freebusy-set, time-range) required? 
> How should it be handled if they are different?
> 
> <?xml version="1.0" encoding="utf-8" ?>
>    <C:calendar-query xmlns:D="DAV:"
>                  xmlns:C="urn:ietf:params:xml:ns:caldav">
>      <D:prop>
>        <C:calendar-data>
>          <C:limit-freebusy-set start="20060102T000000Z"
>                                  end="20060103T000000Z"/>
>        </C:calendar-data>
>      </D:prop>
>      <C:filter>
>        <C:comp-filter name="VCALENDAR">
>          <C:comp-filter name="VFREEBUSY">
>            <C:time-range start="20060102T000000Z"
>                            end="20060103T000000Z"/>
>          </C:comp-filter>
>        </C:comp-filter>
>      </C:filter>
>    </C:calendar-query>
> 
> Thanks
> Venkat
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Thu, 27 Apr 2006 05:40:27 -0700 (PDT)
From: venkat <[email-masked]>
To: [email-masked]
Subject: [Ietf-caldav] caldav protocol - doubt

--0-806199334-1146141627=:92162
Content-Type: text/plain; charset=us-ascii

-- DIV {margin:0px} --> Hi,

I am trying to understand the CalDAV protocol and build a small prototype.

In the following example, why are two time ranges(limit-freebusy-set, time-range) required? 
How should it be handled if they are different?

<?xml version="1.0" encoding="utf-8" ?>
   <C:calendar-query xmlns:D="DAV:"
                 xmlns:C="urn:ietf:params:xml:ns:caldav">
     <D:prop>
       <C:calendar-data>
         <C:limit-freebusy-set start="20060102T000000Z"
                                 end="20060103T000000Z"/>
       </C:calendar-data>
     </D:prop>
     <C:filter>
       <C:comp-filter name="VCALENDAR">
         <C:comp-filter name="VFREEBUSY">
           <C:time-range start="20060102T000000Z"
                           end="20060103T000000Z"/>
         </C:comp-filter>
       </C:comp-filter>
     </C:filter>
   </C:calendar-query>

Thanks
Venkat

 

--0-806199334-1146141627=:92162
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><div><style type="text/css">-- DIV {margin:0px} --></style><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><div> <pre><font size="3">Hi,<br><br>I am trying to understand the CalDAV protocol and build a small prototype.<br><br>In the following example, why are two time ranges(limit-freebusy-set, time-range) required? <br>How should it be handled if they are different?<br><br>&lt;?xml version="1.0" encoding="utf-8" ?&gt;<br>   &lt;C:calendar-query xmlns:D="DAV:"<br>                 xmlns:C="urn:ietf:params:xml:ns:caldav"&gt;<br>     &lt;D:prop&gt;<br>       &lt;C:calendar-data&gt;<br>         &lt;C:limit-freebusy-set <span style="font-weight: bold;">start="20060102T000000Z"</span><br style="font-weight:
 bold;"><span style="font-weight: bold;">                                 end="20060103T000000Z"</span>/&gt;<br>       &lt;/C:calendar-data&gt;<br>     &lt;/D:prop&gt;<br>     &lt;C:filter&gt;<br>       &lt;C:comp-filter name="VCALENDAR"&gt;<br>         &lt;C:comp-filter name="VFREEBUSY"&gt;<br>           &lt;C:time-range <span style="font-weight: bold;">start="20060102T000000Z"</span><br style="font-weight: bold;"><span style="font-weight: bold;">                           end="20060103T000000Z"</span>/&gt;<br>         &lt;/C:comp-filter&gt;<br>       &lt;/C:comp-filter&gt;<br>     &lt;/C:filter&gt;<br>   &lt;/C:calendar-query&gt;<br><br>Thanks<br>Venkat<br><br><br><br><br><br><br><br><br><br><br><br><br></font><br><br><br><br><br><br><br><br><br><br><br></pre> </div></div></div></div></div></body></html>
--0-806199334-1146141627=:92162--

Date: Thu, 27 Apr 2006 12:30:19 +0200
From: Julian Reschke <[email-masked]>
To: [email-masked], CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12

Hi,

I note that draft 12 of caldav still makes requirements that are 
potentially incompatible with HTTP:

Quoting 
<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-12.html#rfc.section.5.3.4.p.4>:

"In the case where the data stored by a server as a result of a PUT 
request is not equivalent by octet equality to the submitted calendar 
object resource, the behavior of the ETag response header is undefined, 
with the exception that a strong entity tag MUST NOT be returned in the 
response. As a result, clients may need to retrieve the modified 
calendar object resource (and ETag) as a basis for further changes, 
rather than use the calendar object resource it had sent with the PUT 
request."

This is a requirement that is not in RFC2616. Adding this to CalDav may 
make it impossible to implement resources that are both compliant to 
CalDav and other HTTP based specifications (which may have a different 
opinion about ETags in PUT responses).

If CalDav clients *really* require knowledge about this situation, 
please define it in a way that will not potentially be in conflict with 
other specifications, such as by adding a *new* response header, 
indicating that content was not rewritten (as proposed in 
<http://lists.osafoundation.org/pipermail/ietf-caldav/2006-April/000787.html> 
two weeks ago).

Best regards, Julian

Date: Tue, 18 Apr 2006 09:38:02 -0400
From: Cyrus Daboo <[email-masked]>
To: Jay Batson <[email-masked]>
Subject: Re: [Ietf-caldav] I-D ACTION:draft-dusseault-caldav-11.txt  (fwd)
Cc: CalDAV DevList <[email-masked]>

Hi Jay,

--On April 18, 2006 8:35:54 AM -0400 Jay Batson <[email-masked]> 
wrote:

> In summary, my thoughts on the requirements:
> - Permit changes to DB on either side (client/server) while clients/
> servers are not connected;

This is certainly allowed with CalDAV as it stands today.

> - Ability for one side (client or server; probably client in the  context
> of CalDAV) to detect which objects (events, todos, ...) to  detect
> modifications made at the other end while disconnected;

Again possible right now. The crude approach would be to do a PROPFIND 
Depth:1 on a calendar collection requesting the DAV:getetag property and 
then use the results to compare with the items cached locally. The client 
can then use the multiget report to fetch those items that have changed or 
are new, and can upload its changed or new items.

This is not ideal from a network bandwidth standpoint when calendars get 
large (as they undoubtedly will do). In that case clients can be smarter 
about using the calendar-query report with time-range option to refresh 
portions of their cache in a 'paged' manner (e.g. on initial connect 
refresh one month either side of the current 'view' the user has set, then 
refresh other time ranges either on demand or in the background).

> - Ability for one side (ditto) to inform the other of changes made  while
> disconnected;

Notifications of changes (even whilst the client thinks it is connected) 
are not supported right now. We do plan on addressing that at some point.

> - Ability for the side doing the detection/informing to perform user-
> directed conflict resolution, and set the DB on both ends to  contained
> the result.

Right now the client is responsible for conflict resolution - that I think 
is the right solution as in many cases the user will need to be consulted 
about how to resolve a conflict.

> - Do the detection/informing/updating in a bandwidth-efficient manner;

We need not include a more efficient synchronization facility in CalDAV for 
various reasons. However, as I've mentioned previously, I did put together 
a 'prototype' solution in CardDAV with the hopes that that would be 
critiqued and ultimately lead to a solution in CalDAV (which would have to 
be done as an extension). So I would certainly welcome feedback on that 
feature in CardDAV with a view to having something similar for CalDAV.

-- 
Cyrus Daboo

From: Jay Batson <[email-masked]>
Subject: Re: [Ietf-caldav] I-D ACTION:draft-dusseault-caldav-11.txt  (fwd)
Date: Tue, 18 Apr 2006 08:35:54 -0400
To: Jari Urpalainen <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

Without (being capable of) expressing a solution preference, I want  
to make sure the authors have sufficient "evidence on the list" that  
-- as part of the basic requirements -- CalDAV must provide an  
acceptable, efficient way for calendaring clients to be capable of  
"offline use using cached calendars & change detection-resolution (on  
reconnect)" mentioned by Julian.

This is, as you're all painfully aware, a difficult thing to do  
efficiently.  There are obvious tradeoffs:
- Good:  Client-side detection of changes, & conflict resolution,  
scales well (by moving the processing to the client);
- Bad:  If designed badly, client-side detection of changes can lead  
to a significant amount of network traffic to obtain necessary  
information from the server to perform the sync / resolution.  There  
are still a significant number of places where CalDAV (and HTTP) are  
going to be used over dial-up where you can't simply assume "free,  
high-speed bandwidth" for all the client/server interactions.
- (Of course, server-side resolution has the opposite problems).
- Version tags are good, and historically many products have been  
built using this method.  The devil-in-the-details question is always  
"How granular should the version tags be?  Per-field, per-object  
(e.g. VEVENT), or per-Calendar?"  Again, with processing / bandwidth  
tradeoffs being the obstacles.

I'm technical enough to know the problem, and need, exists, and have  
been involved at an engineering-management level with two commercial  
products that have solved the problem (MeetingMaker, and Chirp).  So  
I know it can be done; but you're better off not asking me to design  
the solution.  I'm not *that* technical.  :-)

In summary, my thoughts on the requirements:
- Permit changes to DB on either side (client/server) while clients/ 
servers are not connected;
- Ability for one side (client or server; probably client in the  
context of CalDAV) to detect which objects (events, todos, ...) to  
detect modifications made at the other end while disconnected;
- Ability for one side (ditto) to inform the other of changes made  
while disconnected;
- Ability for the side doing the detection/informing to perform user- 
directed conflict resolution, and set the DB on both ends to  
contained the result.
- Do the detection/informing/updating in a bandwidth-efficient manner;

Cheers
-jb

On Apr 18, 2006, at 2:58 AM, Jari Urpalainen wrote:

> On Sat, 2006-04-15 at 10:17 +0200, ext Julian Reschke wrote:
>> Lisa Dusseault wrote:
>>>
>>> On Apr 14, 2006, at 12:56 PM, Julian Reschke wrote:
>>>
>>>>> happen, some clients might always do a GET (poor performance) and
>>>>> others might always not (poor interoperability).
>>>>
>>>> Just tell clients to do conditional GETs with the cache  
>>>> validator they
>>>> got upon PUT. The client may not have the same content octet-for- 
>>>> octet
>>>> as the server, but besides that I see no problem (yet).
>>>
>>> Yes, but that's exactly it, there's confusion about what the cache
>>> validator they got upon PUT means, or in what cases the server is
>>> allowed to return it.   Many clients cache calendar items for  
>>> offline
>>> use, and if the server has added its own custom properties or  
>>> modified
>>> data, that may well need to be available offline as well.
>>
>> Currently, there's no way to find out. If this is a requirement,  
>> CalDAV
>> will either have to rely on draft-whitehead-http-etag solving that
>> problem, or come up with its own solution.
>>
>> I'd prefer the former approach, because solving this once and for all
>> HTTP based specs certainly is better.
>>
>> If CalDAV wants to do its own thing, it must make sure that it  
>> doesn't
>> contradict other specs, on which it builds or that servers may  
>> want to
>> implement in parallel with CalDAV. A safe way to do that for now  
>> would
>> be to add a new response header that contains just that piece of
>> information, such as:
>>
>> 	X-Content-Rewritten: "T" / "F"
>>
>> Best regards, Julian
>
> We had similar ambiquities/difficulties with ETags in XCAP, where  
> adding
> new headers were not the preferred way to solve this kind of issues.
> That said, as I have also previously said that 5.3.4 section was
> somewhat difficult to understand and incorrect (rfc2616 reference  
> and no
> clear why reasoning of ETag behavior), I agree with Julian that a new
> X-header or a normative reference to draft-whitehead-http-etag is a
> better way to solve this issue, and certainly the latter option the  
> best
> one.
> br,
> Jari
>
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

-------------
Jay Batson
[email-masked]
+1-978-824-0111 (w)
+1-978-758-1599 (m)

Subject: Re: [Ietf-caldav] I-D ACTION:draft-dusseault-caldav-11.txt  (fwd)
From: Jari Urpalainen <[email-masked]>
To: ext Julian Reschke <[email-masked]>
Date: Tue, 18 Apr 2006 09:58:40 +0300
Cc: CalDAV DevList <[email-masked]>

On Sat, 2006-04-15 at 10:17 +0200, ext Julian Reschke wrote:
> Lisa Dusseault wrote:
> > 
> > On Apr 14, 2006, at 12:56 PM, Julian Reschke wrote:
> > 
> >>> happen, some clients might always do a GET (poor performance) and 
> >>> others might always not (poor interoperability).
> >>
> >> Just tell clients to do conditional GETs with the cache validator they 
> >> got upon PUT. The client may not have the same content octet-for-octet 
> >> as the server, but besides that I see no problem (yet).
> > 
> > Yes, but that's exactly it, there's confusion about what the cache 
> > validator they got upon PUT means, or in what cases the server is 
> > allowed to return it.   Many clients cache calendar items for offline 
> > use, and if the server has added its own custom properties or modified 
> > data, that may well need to be available offline as well.
> 
> Currently, there's no way to find out. If this is a requirement, CalDAV 
> will either have to rely on draft-whitehead-http-etag solving that 
> problem, or come up with its own solution.
> 
> I'd prefer the former approach, because solving this once and for all 
> HTTP based specs certainly is better.
> 
> If CalDAV wants to do its own thing, it must make sure that it doesn't 
> contradict other specs, on which it builds or that servers may want to 
> implement in parallel with CalDAV. A safe way to do that for now would 
> be to add a new response header that contains just that piece of 
> information, such as:
> 
> 	X-Content-Rewritten: "T" / "F"
> 
> Best regards, Julian

We had similar ambiquities/difficulties with ETags in XCAP, where adding
new headers were not the preferred way to solve this kind of issues.
That said, as I have also previously said that 5.3.4 section was
somewhat difficult to understand and incorrect (rfc2616 reference and no
clear why reasoning of ETag behavior), I agree with Julian that a new
X-header or a normative reference to draft-whitehead-http-etag is a
better way to solve this issue, and certainly the latter option the best
one. 
br,
Jari 

Date: Sat, 15 Apr 2006 10:17:49 +0200
From: Julian Reschke <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] I-D ACTION:draft-dusseault-caldav-11.txt  (fwd)
Cc: CalDAV DevList <[email-masked]>

Lisa Dusseault wrote:
> 
> On Apr 14, 2006, at 12:56 PM, Julian Reschke wrote:
> 
>> Lisa Dusseault wrote:
>>> On Apr 14, 2006, at 12:27 PM, Julian Reschke wrote:
>>>> Lisa Dusseault wrote:
>>>>> Unfortunately, that just does not solve the problem for CalDAV, 
>>>>> which is likely to have interoperability problems if we don't make 
>>>>> firm
>>>>
>>>> ...such as...?
>>> The near certainty, from talking to implementors, that some CalDAV 
>>> servers will add their own iCalendar properties to the body of the 
>>> iCalendar resources that clients create, and the undesirability of 
>>> clients always having to do GET after a PUT just to see whether this 
>>> in fact happened.  If we don't explain how to see whether this didn't
>>
>> Why would they need to do that?
> 
> Usually it's a bunch of concerns for backward compatibility with 
> existing systems -- e.g. compatibility with a limited set of timezone 
> definitions.  Timezones complicate this problem, as with so many other 
> problems.

Misunderstanding. What I meant was: why would the client need to know 
whether the server rewrote the entry? This would only be relevant if 
clients use an ETag returned upon PUT for a conditional GET with byte 
range header afterwards.

>>> happen, some clients might always do a GET (poor performance) and 
>>> others might always not (poor interoperability).
>>
>> Just tell clients to do conditional GETs with the cache validator they 
>> got upon PUT. The client may not have the same content octet-for-octet 
>> as the server, but besides that I see no problem (yet).
> 
> Yes, but that's exactly it, there's confusion about what the cache 
> validator they got upon PUT means, or in what cases the server is 
> allowed to return it.   Many clients cache calendar items for offline 
> use, and if the server has added its own custom properties or modified 
> data, that may well need to be available offline as well.

Currently, there's no way to find out. If this is a requirement, CalDAV 
will either have to rely on draft-whitehead-http-etag solving that 
problem, or come up with its own solution.

I'd prefer the former approach, because solving this once and for all 
HTTP based specs certainly is better.

If CalDAV wants to do its own thing, it must make sure that it doesn't 
contradict other specs, on which it builds or that servers may want to 
implement in parallel with CalDAV. A safe way to do that for now would 
be to add a new response header that contains just that piece of 
information, such as:

	X-Content-Rewritten: "T" / "F"

Best regards, Julian

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] I-D ACTION:draft-dusseault-caldav-11.txt  (fwd)
Date: Fri, 14 Apr 2006 16:32:16 -0700
To: Julian Reschke <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

On Apr 14, 2006, at 12:56 PM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>> On Apr 14, 2006, at 12:27 PM, Julian Reschke wrote:
>>> Lisa Dusseault wrote:
>>>> Unfortunately, that just does not solve the problem for CalDAV,  
>>>> which is likely to have interoperability problems if we don't  
>>>> make firm
>>>
>>> ...such as...?
>> The near certainty, from talking to implementors, that some CalDAV  
>> servers will add their own iCalendar properties to the body of the  
>> iCalendar resources that clients create, and the undesirability of  
>> clients always having to do GET after a PUT just to see whether  
>> this in fact happened.  If we don't explain how to see whether  
>> this didn't
>
> Why would they need to do that?

Usually it's a bunch of concerns for backward compatibility with  
existing systems -- e.g. compatibility with a limited set of timezone  
definitions.  Timezones complicate this problem, as with so many  
other problems.

>
>> happen, some clients might always do a GET (poor performance) and  
>> others might always not (poor interoperability).
>
> Just tell clients to do conditional GETs with the cache validator  
> they got upon PUT. The client may not have the same content octet- 
> for-octet as the server, but besides that I see no problem (yet).

Yes, but that's exactly it, there's confusion about what the cache  
validator they got upon PUT means, or in what cases the server is  
allowed to return it.   Many clients cache calendar items for offline  
use, and if the server has added its own custom properties or  
modified data, that may well need to be available offline as well.

lisa

Date: Fri, 14 Apr 2006 21:56:49 +0200
From: Julian Reschke <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] I-D ACTION:draft-dusseault-caldav-11.txt  (fwd)
Cc: CalDAV DevList <[email-masked]>

Lisa Dusseault wrote:
> 
> On Apr 14, 2006, at 12:27 PM, Julian Reschke wrote:
> 
>> Lisa Dusseault wrote:
>>> Unfortunately, that just does not solve the problem for CalDAV, which 
>>> is likely to have interoperability problems if we don't make firm
>>
>> ...such as...?
> 
> The near certainty, from talking to implementors, that some CalDAV 
> servers will add their own iCalendar properties to the body of the 
> iCalendar resources that clients create, and the undesirability of 
> clients always having to do GET after a PUT just to see whether this in 
> fact happened.  If we don't explain how to see whether this didn't 

Why would they need to do that?

> happen, some clients might always do a GET (poor performance) and others 
> might always not (poor interoperability).

Just tell clients to do conditional GETs with the cache validator they 
got upon PUT. The client may not have the same content octet-for-octet 
as the server, but besides that I see no problem (yet).

> ...

Best regards, Julian

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] I-D ACTION:draft-dusseault-caldav-11.txt  (fwd)
Date: Fri, 14 Apr 2006 12:37:57 -0700
To: Julian Reschke <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

On Apr 14, 2006, at 12:27 PM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>> Unfortunately, that just does not solve the problem for CalDAV,  
>> which is likely to have interoperability problems if we don't make  
>> firm
>
> ...such as...?

The near certainty, from talking to implementors, that some CalDAV  
servers will add their own iCalendar properties to the body of the  
iCalendar resources that clients create, and the undesirability of  
clients always having to do GET after a PUT just to see whether this  
in fact happened.  If we don't explain how to see whether this didn't  
happen, some clients might always do a GET (poor performance) and  
others might always not (poor interoperability).

>
>> requirements about modifying resources on PUT.  Relying on  
>> RFC2518bis, which has been through WG last call, is one thing;  
>> relying on the etag draft is another.
>
> OK, minimally it must not make incorrect statements about what  
> RFC2616 says. If CalDAV really has additional requirements  
> (which?), then CalDAV of course could impose them.

Thx.
Lisa

Date: Fri, 14 Apr 2006 21:27:53 +0200
From: Julian Reschke <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] I-D ACTION:draft-dusseault-caldav-11.txt  (fwd)
Cc: CalDAV DevList <[email-masked]>

Lisa Dusseault wrote:
> Unfortunately, that just does not solve the problem for CalDAV, which is 
> likely to have interoperability problems if we don't make firm 

...such as...?

> requirements about modifying resources on PUT.  Relying on RFC2518bis, 
> which has been through WG last call, is one thing; relying on the etag 
> draft is another.

OK, minimally it must not make incorrect statements about what RFC2616 
says. If CalDAV really has additional requirements (which?), then CalDAV 
of course could impose them.

Best regards, Julian

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] I-D ACTION:draft-dusseault-caldav-11.txt  (fwd)
Date: Fri, 14 Apr 2006 12:20:05 -0700
To: Julian Reschke <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

On Apr 14, 2006, at 11:51 AM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>> Should we simply remove the claim about what RFC2616 says and  
>> continue to make these requirements?  (If not, do you have a  
>> proposal for solving the problem?)
>
> I think neither CalDAV nor RFC2518bis should make any statements  
> about this issue, but draft-whitehead-http-etag. This who care  
> about this issue should join the discussion on the HTTP mailing list.
>

Unfortunately, that just does not solve the problem for CalDAV, which  
is likely to have interoperability problems if we don't make firm  
requirements about modifying resources on PUT.  Relying on  
RFC2518bis, which has been through WG last call, is one thing;  
relying on the etag draft is another.

Lisa

Date: Fri, 14 Apr 2006 20:51:51 +0200
From: Julian Reschke <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] I-D ACTION:draft-dusseault-caldav-11.txt  (fwd)
Cc: CalDAV DevList <[email-masked]>

Lisa Dusseault wrote:
> Should we simply remove the claim about what RFC2616 says and continue 
> to make these requirements?  (If not, do you have a proposal for solving 
> the problem?)

I think neither CalDAV nor RFC2518bis should make any statements about 
this issue, but draft-whitehead-http-etag. This who care about this 
issue should join the discussion on the HTTP mailing list.

Best regards, Julian

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] I-D ACTION:draft-dusseault-caldav-11.txt  (fwd)
Date: Fri, 14 Apr 2006 11:34:28 -0700
To: Julian Reschke <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

On Apr 14, 2006, at 7:02 AM, Julian Reschke wrote:
>
>> As required by [RFC2616], a response to a PUT request with a  
>> strong entity tag MUST mean that the server will return on a  
>> subsequent GET request a calendar object resource that is  
>> equivalent by octet equality.
>
> No, that's not in RFC2616.
>
>> A response to a PUT request MUST NOT contain an ETag response  
>> header field if the server will return on a subsequent GET request  
>> a calendar object resource that is not equivalent by octet  
>> equality to the submitted calendar object resource. In this case,  
>> the client SHOULD retrieve the new entity (and ETag) as a basis  
>> for further changes, rather than use the entity it had sent with  
>> the PUT request.
>
> Again, not in RFC2616.

Should we simply remove the claim about what RFC2616 says and  
continue to make these requirements?  (If not, do you have a proposal  
for solving the problem?)

Lisa

Date: Fri, 14 Apr 2006 16:02:45 +0200
From: Julian Reschke <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-caldav] I-D ACTION:draft-dusseault-caldav-11.txt  (fwd)
Cc: CalDAV DevList <[email-masked]>

Cyrus Daboo wrote:
> Hi folks,
> A new version of the draft is now available. This addresses almost all 
> of the comments we've received to date (just some from Jeff's last 
> message still to address). At this point it is our intention to submit 
> this to the IESG as soon as possible.
> 
> Note that there have been some important changes since -10 - please 
> check the Changes section for full details.
> ...

I appreciate the change moving to RFC2518bis, and requiring level 3 
compliance. Hopefully now all CalDAV implementors are busy looking at 
the Changes section for RFC2518bis as well :-) (see 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-14.html#rfc.section.E>).

One thing I still think is broken in CalDAV are the ETag requirements in 
Section 5.3.4 
(<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-11.html#calendar-etag>).

In particular:

> As required by [RFC2616], a response to a PUT request with a strong entity tag MUST mean that the server will return on a subsequent GET request a calendar object resource that is equivalent by octet equality.

No, that's not in RFC2616.

> A response to a PUT request MUST NOT contain an ETag response header field if the server will return on a subsequent GET request a calendar object resource that is not equivalent by octet equality to the submitted calendar object resource. In this case, the client SHOULD retrieve the new entity (and ETag) as a basis for further changes, rather than use the entity it had sent with the PUT request.

Again, not in RFC2616.

Best regards, Julian

Date: Wed, 12 Apr 2006 13:42:34 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-caldav list <[email-masked]>
Subject: [Ietf-caldav] CalConnect Roundtable VI -- May 22-25, Cambridge, Massachusetts - The Calendaring and Scheduling Consortium
Reply-To: [email-masked]

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

*Come to Cambridge for CalConnect's Sixth Roundtable!*

This is a reminder that The Calendaring and Scheduling Consortium's 
Roundtable VI and associated interoperability testing event will be 
hosted by IBM/Lotus in Cambridge, Massachusetts, on May 22-25.  
Registration is now open for both the Roundtable and the IOP testing 
event (see below). 

The *interoperability testing event* will be all day Monday, May 22, and 
Tuesday morning the 23rd.  This event will offer IOP testing against the 
RFCs and extensive CalDAV testing, and will also focus on testing 
Free/Busy support.

The Consortium will offer a *Practicum on Tuesday morning* from 
9:30-12:00 to all Roundtable registrants (member representatives and 
observers), comprising two one-hour overview/levelset sessions on 
iCalendar Specifications and on CalDAV (the new calendaring access 
protocol).  The goal of these sessions is to provide a basic level of 
familiarity and understanding of iCalendar and CalDAV to any attendees 
who are not involved with the specifications and may wish to know more.

Tuesday afternoon is planned to be an in-depth *workshop on Mobile 
Calendaring*, with the goal of better identifying actual vendor and 
customer requirements for mobile interoperable calendaring and 
scheduling and helping to identify use cases, requirements, and a 
consensus vision statement for mobile calendaring in the future.  The 
workshop will be open to all attendees.

Wednesday, and Thursday morning, will be dedicated to *Technical 
Committee sessions* in areas such as CalDAV, Realtime (calendaring 
server-to-server protocols and requirements), Event Publication,  Use 
Case development, and  Authentication, plus a Plenary meeting of the 
Consortium.  All attendees are welcome to participate in any TC sessions 
which interest them. 

Registration is now open for the IOP testing event and for the 
Roundtable (separate registration required).  For more information and 
logistics see http://www.calconnect.org/roundtable6.html and 
http://www.calconnect.org/iopmay2006.html. 

To register for the Roundtable or IOP testing, see 
http://www.calconnect.org/roundtablereg.html (1) and
http://www.calconnect.org/iopreg.html (2).

(1) Please note that if you register by _May 5_ you will get a discount 
on your registration fee for the Roundtable.

(2) If you are a Consortium Member doing interoperability testing, you 
are also eligible for a 10% discount by agreeing to attend three 
consecutive IOP testing events (the discount applies for all three events).

Please contact me if you have any questions. 

See you in May!

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

--------------060307020200050108060703
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>Come to Cambridge for CalConnect's Sixth Roundtable!</b><br>
<br>
This is a reminder that The Calendaring and Scheduling Consortium's
Roundtable VI and associated interoperability testing event will be
hosted by IBM/Lotus in Cambridge, Massachusetts, on May 22-25.&nbsp;
Registration is now open for both the Roundtable and the IOP testing
event (see below).&nbsp; <br>
<br>
The <b>interoperability testing event</b> will be all day Monday, May
22, and Tuesday morning the 23rd.&nbsp; This event will offer IOP testing
against the RFCs and extensive CalDAV testing, and will also focus on
testing Free/Busy support.<br>
<br>
The Consortium will offer a <b>Practicum on Tuesday morning</b> from
9:30-12:00 to all Roundtable registrants (member representatives and
observers), comprising two one-hour overview/levelset sessions on
iCalendar Specifications and on CalDAV (the new calendaring access
protocol).&nbsp;
The goal of these sessions is to provide a basic level of familiarity
and understanding of iCalendar and CalDAV to any attendees who are not
involved with the specifications and may wish to know more.<br>
<br>
Tuesday afternoon is planned to be an in-depth <b>workshop on Mobile
Calendaring</b>, with the goal of better identifying actual vendor and
customer
requirements for mobile interoperable calendaring and scheduling and
helping to identify use cases, requirements, and a consensus vision
statement for mobile calendaring in the future.&nbsp; The workshop will be
open to all attendees.<br>
<br>
Wednesday, and Thursday morning, will be dedicated to <b>Technical
Committee sessions</b> in areas such as CalDAV, Realtime (calendaring
server-to-server protocols and requirements), Event Publication,&nbsp; Use
Case development, and&nbsp; Authentication, plus a Plenary meeting of the
Consortium.&nbsp; All attendees are welcome to participate in any TC
sessions which interest them.&nbsp; <br>
<br>
Registration is now open for the IOP testing event and for the
Roundtable (separate registration required).&nbsp; For more information and
logistics see <a href="http://www.calconnect.org/roundtable6.html">http://www.calconnect.org/roundtable6.html</a>
and <a href="http://www.calconnect.org/iopmay2006.html">http://www.calconnect.org/iopmay2006.html</a>.&nbsp;
<br>
<br>
To register for the Roundtable or IOP testing, see <a
 href="http://www.calconnect.org/roundtablereg.html">http://www.calconnect.org/roundtablereg.html</a>
(1) and <br>
<a href="http://www.calconnect.org/iopreg.html">http://www.calconnect.org/iopreg.html</a>
(2).<br>
<br>
<br>
(1) Please note that if you register by <u>May 5</u> you will get a
discount on your registration fee for the Roundtable. <br>
<br>
(2) If you are a Consortium Member doing interoperability testing, you
are also eligible for a 10% discount by agreeing to attend three
consecutive IOP testing events (the discount applies for all three
events).<br>
<br>
Please contact me if you have any questions.&nbsp; <br>
<br>
See you in May!<br>
<br>
Dave Thewlis<br>
<div class="moz-signature">-- <br>
<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>
</div>
</body>
</html>

--------------060307020200050108060703--

Date: Tue, 11 Apr 2006 17:39:07 -0700
From: Dan Mosedale <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections
Cc: CalDAV DevList <[email-masked]>

Chiming in a bit late here, but I would tend to lean slightly in favor 
of the existing, slightly more restrictive semantics.  My thinking is 
merely that simplicity really does help real-world 
adoption/implementation, and various folks have pointed out ways that 
loosening this restriction is likely at add complexity which would then 
require additional specification to ensure that all implementors do the 
sam thing, which adds even more complexity.

Dan

Date: Mon, 10 Apr 2006 16:00:04 -0400
From: Cyrus Daboo <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] I-D ACTION:draft-dusseault-caldav-11.txt  (fwd)

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

Hi folks,
A new version of the draft is now available. This addresses almost all of 
the comments we've received to date (just some from Jeff's last message 
still to address). At this point it is our intention to submit this to the 
IESG as soon as possible.

Note that there have been some important changes since -10 - please check 
the Changes section for full details.

------------ Forwarded Message -----------
Date: April 10, 2006 3:50:01 PM -0400
From: [email-masked]
To: [email-masked]
Subject: I-D ACTION:draft-dusseault-caldav-11.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Calendaring Extensions to WebDAV (CalDAV)
	Author(s)	: L. Dusseault, et al.
	Filename	: draft-dusseault-caldav-11.txt
	Pages		: 109
	Date		: 2006-4-10

---------- End Forwarded Message ----------

-- 
Cyrus Daboo

--==========6D310EE7F3F4E1E807AC==========
Content-Type: message/rfc822; name="I-D ACTION:draft-dusseault-caldav-11.txt "

To: [email-masked]
Cc: 
From: [email-masked]
Date: Mon, 10 Apr 2006 15:50:01 -0400
Subject: I-D ACTION:draft-dusseault-caldav-11.txt 
Reply-To: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Calendaring Extensions to WebDAV (CalDAV)
	Author(s)	: L. Dusseault, et al.
	Filename	: draft-dusseault-caldav-11.txt
	Pages		: 109
	Date		: 2006-4-10
	
This document specifies a set of methods, headers, message bodies,
properties, and reports that define calendar access extensions to the
WebDAV protocol.  The new protocol elements are intended to make
WebDAV-based calendaring and scheduling an interoperable standard
that supports calendar access, calendar management, calendar sharing,
and calendar publishing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-dusseault-caldav-11.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-dusseault-caldav-11.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-dusseault-caldav-11.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-dusseault-caldav-11.txt

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

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

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

--==========6D310EE7F3F4E1E807AC==========--

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Caldav sync approach comments
Date: Fri, 7 Apr 2006 23:09:38 +0200
To: CalDAV DevList <[email-masked]>

On Apr 7, 2006, at 22:40, Kervin L. Pierre wrote:
> The resulting calendar would 'consistant' from a
> CalDAV data point-of-view, but may not be from the
> user's or client's point-of-view.
>
> In other words there is no way to apply a set of
> offline changes to the calendar atomically.

I see your point. Though _IMO_ its not a real world issue. The client 
should just collect failed PUTs and present them to the user (and offer 
him to revert, add-a-copy, merge or overwrite [see iSync]). If you do 
so, it will be correct from the users point-of-view :-)

Remember that the user needs to make such a decision anyway. Even if 
you place a lock, you would first need to present the user a view of 
conflicting items which he needs to resolve. Pessimistic vs optimistic 
is mostly a matter whether your show that before or after the sync :-)

Summary: I don't think a pessimistic atomic lock provides a lot of 
real-world advantages over the optimistic locks (unless the items 
really have a tight coupling which is not the case for CalDAV 
resources).

Remember that placing locks is highly inefficient, both from the 
(server) work required to implement them and from the reduction in 
scalability (think of why row-level locking was a major new feature in 
RDBMS ;-).
I think keeping them optional is a good choice.

regards,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

Date: Fri, 07 Apr 2006 16:40:39 -0400
From: "Kervin L. Pierre" <[email-masked]>
To: Helge Hess <[email-masked]>, CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] Caldav sync approach comments

Hello,

I'm sure if it's a big deal to others, but the
case were a offline client modifies multiple
resources and tries to sync those with an online,
multi-user calendar when it finally gets online.

The resources themselves are uploaded alright,
but the client can not garantee that the calendar
is in the same state the client intended at the
beginning of the sync because other clients could
have modified the resources during that sync.

The resulting calendar would 'consistant' from a
CalDAV data point-of-view, but may not be from the
user's or client's point-of-view.

In other words there is no way to apply a set of
offline changes to the calendar atomically.

Checking the etags would confirm that there is a
conflict, but it does not give a method to
prevent or resolve the issue.

Ie.  If two changeset walk over each other, how
does one back out?

Best regards,
Kervin

Helge Hess wrote:
> On Apr 7, 2006, at 16:58, Kervin L. Pierre wrote:
> 
>> PS. A current related issue is that a client
>>     with an offline cache can not verify a
>>     complete sync with a multi-user calendar
>>     without WebDAV locks.  But WebDAV locks
>>     are optional in CalDAV.
> 

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Caldav sync approach comments
Date: Fri, 7 Apr 2006 21:04:26 +0200
To: CalDAV DevList <[email-masked]>

On Apr 7, 2006, at 16:58, Kervin L. Pierre wrote:
> PS. A current related issue is that a client
>     with an offline cache can not verify a
>     complete sync with a multi-user calendar
>     without WebDAV locks.  But WebDAV locks
>     are optional in CalDAV.

Could you elaborate?

Thanks,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

Date: Fri, 07 Apr 2006 10:58:44 -0400
From: "Kervin L. Pierre" <[email-masked]>
To: Jay Batson <[email-masked]>
Subject: Re: [Ietf-caldav] Caldav sync approach comments
Cc: [email-masked]

Hello Jay,

Jay Batson wrote:
> So don't jump too far too fast by adding SyncML into the mix.  I wish  I 
> knew what to suggest we'd prefer to see.  It's a tough call.  I'm  happy 
> to see this august body discuss it, though.
> 

I do believe sync is an issue that needs to
be addressed with some options being...

(i) Adding a 'changset' report based on tags
     or timestamp, as Lisa mentioned.  This
     would enable faster sync that does not
     require exchanging information about every
     resource in the calendar collection.  Very
     important to resource light clients that
     sometimes go offline and have local r/w
     caches.  Eg. many PDA organizers.

(ii)Provide compatibility for external sync
     protocol such as SyncML over HTTP.  Not
     suggesting SyncML being even _mentioned_ in
     the draft.  But care can be taken that a
     CalDAV server implementor can also expose
     the collection via SyncML/HTTP without any
     protocol conflicts.  Or any other
     coexistance issues that might come up.

(iii)Leave the entire discussion for the
     'caldav-schedule' document.

PS. A current related issue is that a client
     with an offline cache can not verify a
     complete sync with a multi-user calendar
     without WebDAV locks.  But WebDAV locks
     are optional in CalDAV.

Best regards,
Kervin

Date: Fri, 07 Apr 2006 10:00:03 -0400
From: Cyrus Daboo <[email-masked]>
To: IGnatius T Foobar <[email-masked]>, [email-masked]
Subject: Re: [Ietf-caldav] comments on version 10 of the CalDAV draft

Hi IGnatius,

--On April 7, 2006 9:18:38 AM -0400 IGnatius T Foobar 
<[email-masked]> wrote:

>  Consider the following sequence of events:
>
>  1. Client "A" issues a PUT with a strong ETag

No - the client does not generate a strong ETag on PUT the server does. We 
are talking about the ETag returned by the server in response to a PUT.

>  2. Client "B" reads the entity and replaces it with a new one.  It will
> have a different ETag, and it might even have a different URI altogether.

How can the client 'replace' a resource with one URI with one of a 
different URI in a single PUT - or are you suggesting some other sequence 
of operations? In any case, an ETag is related to a resource URI, so if 
there is a different URI its a completely different resource anyway.

>  3. Client "A" (unaware that Client "B" did anything) then issues its
> "subsequent" GET and does not find its "equivalent by octet
>  " entity that it is expecting.

A well written client in step 3 will use an If-Match header with the ETag 
it got back in step 1 and will know that someone else changed the resource.

Just to clarify: the statement we put in CalDAV was meant to emphasize the 
nature of STRONG ETags (as opposed to weak) - i.e., if a server returns a 
strong ETag in a PUT response, then if on a subsequent GET or PROPFIND, the 
returned ETag or getetag property is the same as that which came back on 
the PUT, then the actual resource data is EXACTLY the same as that which 
was PUT.

>  This is the same problem that was created a few versions ago when the
> CalDAV draft suddenly mandated that the server isn't allowed to change
> the  URI specified by the client after a PUT command.

Neither HTTP nor WebDAV define such a behavior. Some people assume the 
server can return a Location: header but that is only defined for a POST. 
2616 does allow for a 301 response to effectively 're-direct' the client to 
a more appropriate URI. As far as a I can tell the current draft does not 
rule out such behavior - if you think it does please let me know what 
portion of the draft that is and we can take another look at it.

>  HTTP is "heavily multiuser" and one cannot depend on race conditions.

Right - and proper use of ETags, If-Match, If-None-Match etc is supposed to 
help deal with that, and what we were trying to do (maybe not as well as we 
should have) is emphasis that in CalDAV as we know users are likely to have 
multiple calendar clients accessing the same server/calendars/resources at 
the same time.

-- 
Cyrus Daboo

To: [email-masked]
Date: Fri, 07 Apr 2006 09:18:38 -0400
Subject: Re: [Ietf-caldav] comments on version 10 of the CalDAV draft
From: "IGnatius T Foobar" <[email-masked]>
Organization: Uncensored

 >Sorry, if this has been discussed already, but I got somewhat confused   
 >about this...   
 >   
 >   "As required by [RFC2616], a response to a PUT request with a strong  
 
 >   entity tag MUST mean that the server will return on a subsequent GET  
 
 >   request a calendar object resource that is equivalent by octet   
 >   equality.   
   
 Whether it is specified in RFC2616 or not, it implies a race condition.  
   
 Consider the following sequence of events:  
    
 1. Client "A" issues a PUT with a strong ETag  
   
 2. Client "B" reads the entity and replaces it with a new one.  It will 
have a different ETag, and it might even have a different URI altogether.  
   
 3. Client "A" (unaware that Client "B" did anything) then issues its 
"subsequent" GET and does not find its "equivalent by octet  
 " entity that it is expecting.  

 This is the same problem that was created a few versions ago when the 
CalDAV draft suddenly mandated that the server isn't allowed to change the 
URI specified by the client after a PUT command.  
   
 HTTP is "heavily multiuser" and one cannot depend on race conditions.  

   Art Cancro <[email-masked]>  

From: Jay Batson <[email-masked]>
Subject: Re: [Ietf-caldav] Caldav sync approach comments
Date: Fri, 7 Apr 2006 07:57:18 -0400
To: [email-masked]

Nice discussion here.

I'm not sure layering SyncML in is essential.  Maybe worth an  
analysis, but I wouldn't jump too quickly.  It's a complex thing in  
its own right, and I would move slowly towards adding something of  
this weight.

The real issue isn't whether ETags is sufficient; it provides  
sufficient help for the "versioning" needed to make sync happen.

My concern was that the client has to do the conflict detection and  
merge.  While saddled with the issues I raise, the client-centric  
approach does have some scalability advantages.

So don't jump too far too fast by adding SyncML into the mix.  I wish  
I knew what to suggest we'd prefer to see.  It's a tough call.  I'm  
happy to see this august body discuss it, though.

Thanks
-jb

On Apr 6, 2006, at 8:14 PM, Kervin L. Pierre wrote:

> Hello,
>
> Lisa Dusseault wrote:
>> OTOH maybe it looks completely different.  Maybe there's a clever   
>> binding of SyncML to HTTP resource namespaces?
>
> SyncML HTTP binding on the calendar collection
> would work well here I think.
>
> Maybe it can be an informal recommendation
> outside CalDAV?  With CalDAV only ensuring
> compatibility between the two access methods.
>
> Best regards,
> Kervin

-------------
Jay Batson
[email-masked]
+1-978-824-0111 (w)
+1-978-758-1599 (m)

Date: Fri, 07 Apr 2006 13:34:45 +0200
From: Julian Reschke <[email-masked]>
To: Jari Urpalainen <[email-masked]>
Subject: Re: [Ietf-caldav] comments on version 10 of the CalDAV draft
Cc: CalDAV DevList <[email-masked]>

Jari Urpalainen wrote:
> On Wed, 2006-04-05 at 13:34 -0400, ext Cyrus Daboo wrote:
>> Hi Jeff,
>> Thanks for your comments:
> 
>>> 5.3.4 (last paragraph: A response to a PUT request MUST NOT contain  an
>>> ETag response header ....)
>>>
>>> Why shouldn't the server respond with the ETag it used to store the
>>> calendar object? Wouldn't that be more efficient than making the  client
>>> query the server to determine what it used?
>> There is a lot of debate about the meaning of an ETag header on a PUT and I 
>> believe there will be some work to tighten this up in the future. What we 
>> put in CalDAV was what we felt was best under the current conditions.
>>
> Sorry, if this has been discussed already, but I got somewhat confused
> about this...
> 
>    "As required by [RFC2616], a response to a PUT request with a strong
>    entity tag MUST mean that the server will return on a subsequent GET
>    request a calendar object resource that is equivalent by octet
>    equality.
> 
> I could not find a straight reference to this from rfc2616. We had some
> similar discussions with XCAP as well, where an explicit get(put(x))=x
> is defined, but I think this kind interpretation of rfc2616 is rather
> implicit, imo. So I'd prefer to just to remove the part "As required by
> [RFC2616]," because it is ok to have this sort of CalDAV requirement. Or
> alternatively "As required by this specification,".

First of all, RFC2616 doesn't mandate that. So claiming it does is 
definitively a bad thing to do. Furthermore, I also think that CalDAV 
making it's own requirements is a bad idea; it should just rely on what 
RFC2518bis will say.

 > ...

Best regards, Julian

Subject: Re: [Ietf-caldav] comments on version 10 of the CalDAV draft
From: Jari Urpalainen <[email-masked]>
To: ext Cyrus Daboo <[email-masked]>
Date: Fri, 07 Apr 2006 13:43:20 +0300
Cc: CalDAV DevList <[email-masked]>

On Wed, 2006-04-05 at 13:34 -0400, ext Cyrus Daboo wrote:
> Hi Jeff,
> Thanks for your comments:

> > 5.3.4 (last paragraph: A response to a PUT request MUST NOT contain  an
> > ETag response header ....)
> >
> > Why shouldn't the server respond with the ETag it used to store the
> > calendar object? Wouldn't that be more efficient than making the  client
> > query the server to determine what it used?
> 
> There is a lot of debate about the meaning of an ETag header on a PUT and I 
> believe there will be some work to tighten this up in the future. What we 
> put in CalDAV was what we felt was best under the current conditions.
> 
Sorry, if this has been discussed already, but I got somewhat confused
about this...

   "As required by [RFC2616], a response to a PUT request with a strong
   entity tag MUST mean that the server will return on a subsequent GET
   request a calendar object resource that is equivalent by octet
   equality.

I could not find a straight reference to this from rfc2616. We had some
similar discussions with XCAP as well, where an explicit get(put(x))=x
is defined, but I think this kind interpretation of rfc2616 is rather
implicit, imo. So I'd prefer to just to remove the part "As required by
[RFC2616]," because it is ok to have this sort of CalDAV requirement. Or
alternatively "As required by this specification,".

   "A response to a PUT request MUST NOT contain an ETag response header
   field if the server will return on a subsequent GET request a
   calendar object resource that is not equivalent by octet equality to
   the submitted calendar object resource.  In this case, the client
   SHOULD retrieve the new entity (and ETag) as a basis for further
   changes, rather than use the entity it had sent with the PUT
request."

If I have understood it correctly, you want to signal whether the server
does some mangling to the body or not, right ? Probably, I had this hard
time of understanding the section, because I was thinking does this
apply to If-Match and If-None-Match headers also (which it apparently
doesn't). So probably you could add something like this to the end: "In
other words, the missing ETag response header is just used to signal to
the client when the server has done some mangling to the calendar object
resource after successful PUT."

br,
Jari

Date: Thu, 06 Apr 2006 20:14:51 -0400
From: "Kervin L. Pierre" <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Caldav sync approach comments
Cc: [email-masked]

Hello,

Lisa Dusseault wrote:
> OTOH maybe it looks completely different.  Maybe there's a clever  
> binding of SyncML to HTTP resource namespaces?
> 

SyncML HTTP binding on the calendar collection
would work well here I think.

Maybe it can be an informal recommendation
outside CalDAV?  With CalDAV only ensuring
compatibility between the two access methods.

Best regards,
Kervin

Date: Thu, 06 Apr 2006 19:33:27 -0400
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>, "Kervin L. Pierre" <[email-masked]>
Subject: Re: [Ietf-caldav] Caldav sync approach comments
Cc: [email-masked]

Hi Lisa,

--On April 6, 2006 2:50:43 PM -0700 Lisa Dusseault <[email-masked]> 
wrote:

> I had a bit of offline discussion with Jay -- we'd both like to see a
> synch protocol that works well with HTTP resources, although I argued
> that's out of scope for just doing calendaring.  Maybe a synch  solution
> would be along the lines of defining state tags for  collections or other
> container resources, and/or a REPORT that says  what has changed within a
> namespace.

FYI I did write a sync report into CardDAV as a 'proof of concept' type 
thing to see if we could do it there and then extend CalDAV to do the same 
at some later point.

Whether we use that, SyncML or something else I do think we will need a 
better approach than using ETags...

-- 
Cyrus Daboo

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Caldav sync approach comments
Date: Thu, 6 Apr 2006 14:50:43 -0700
To: "Kervin L. Pierre" <[email-masked]>
Cc: [email-masked]

I had a bit of offline discussion with Jay -- we'd both like to see a  
synch protocol that works well with HTTP resources, although I argued  
that's out of scope for just doing calendaring.  Maybe a synch  
solution would be along the lines of defining state tags for  
collections or other container resources, and/or a REPORT that says  
what has changed within a namespace.

OTOH maybe it looks completely different.  Maybe there's a clever  
binding of SyncML to HTTP resource namespaces?

Lisa

On Apr 6, 2006, at 2:29 PM, Kervin L. Pierre wrote:

> Hello Jay,
>
> Jay Batson wrote:
>  > In CalDAV, the client performs the "sync" work by using ETags  
> to  -  the
>> detect and resolve information changes.
>> Compare this to SyncML, where the server does the that detection /
> [...]
>
> I don't think CalDAV can be directly compared
> to SyncML.  CalDAV is only the access protocol,
> it is suppose to be followed by the schedule
> protocol at some point.  Expired version of the
> draft can be found at...
> http://www.greenbytes.de/tech/webdav/draft-desruisseaux-caldav- 
> sched-00.html
>
> Best regards,
> Kervin
>
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Thu, 06 Apr 2006 17:29:36 -0400
From: "Kervin L. Pierre" <[email-masked]>
To: Jay Batson <[email-masked]>
Subject: Re: [Ietf-caldav] Caldav sync approach comments
Cc: [email-masked]

Hello Jay,

Jay Batson wrote:
  > In CalDAV, the client performs the "sync" work by using ETags to  - 
  the
> detect and resolve information changes.
> 
> Compare this to SyncML, where the server does the that detection /  
[...]

I don't think CalDAV can be directly compared
to SyncML.  CalDAV is only the access protocol,
it is suppose to be followed by the schedule
protocol at some point.  Expired version of the
draft can be found at...
http://www.greenbytes.de/tech/webdav/draft-desruisseaux-caldav-sched-00.html

Best regards,
Kervin

To: [email-masked]
From: Jay Batson <[email-masked]>
Date: Thu, 6 Apr 2006 14:03:08 -0400
Subject: [Ietf-caldav] Caldav sync approach comments

Hi -

I know I'm a bit late to the game, and late for comments of the type  
I'm making, which poses an architectural problem that is probably too  
late / hard to work on.

Caldav supports the notion of offline work, and synchronization of  
changes, in 8.2.1.3 et.seq.  This is important stuff.  AJAX trends  
notwithstanding, a pretty healthy amount of people want software they  
can use while offline.

In CalDAV, the client performs the "sync" work by using ETags to  -  
the detect and resolve information changes.

Compare this to SyncML, where the server does the that detection /  
resolution (e.g. the "sync").  The client sends relevant data, the  
server resolves conflicts, and tells the client how to resolve the  
sync process, returning information as needed.

The advantage of the SyncML approach is centralized control over a  
notoriously hard task.  In our experience, we've had our share of  
pain fixing bugs in this area.  Fortunately, our server is currently  
based on SyncML, and if there's a bug with the sync / merge logic, we  
can fix the bug and deploy a new server, and fix our entire installed  
base in one whack.

Whereas with Caldav, we'll have to produce a new client release and  
trigger an (auto-)update our entire installed base of client desktops  
in order to solve sync logic problems.

Unfortunately, anybody - vendors, open source projects, etc. - who  
deals with client software must manage the software release cycle,  
and release timing is affected by lots of factors.  In contrast,  
server-side releases are much easier to handle, whether the server is  
being provided by a service, or in an enterprise (premises-resident)  
configuration.  So the SyncML server-side sync approach does provide  
an advantage.

Of course, I understand the benefits of client-side work -  
principally in scalability (by using client CPU cycles instead of  
servers), consistency with SMTP/IMAP, and other IETF-style  
approaches, etc.  While these benefits are real, the client-centric  
approach does pose the practical difficulties I mention.

As I said, this is probably not the right time to bring this kind of  
problem up.  But there it is anyway.
Anybody wish to comment on this?
-jb

-------------
Jay Batson
[email-masked]
+1-978-824-0111 (w)
+1-978-758-1599 (m)

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] comments on version 10 of the CalDAV draft
Date: Thu, 6 Apr 2006 01:41:21 +0200
To: CalDAV DevList <[email-masked]>

On 5. Apr 2006, at 21:11 Uhr, Jeff McCullough wrote:
>> Depth can be 0, 1 or infinity so I'm not quite sure what you are  
>> getting at here. Can you explain some more?
> If I query at say depth 2, do I get a response only from depth 2 or  
> also from depth 1?

"Depth can be 0, 1 or infinity"

If you query a depth 2, I suppose you will get an HTTP status 400  
(Invalid Request).

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

From: Jeff McCullough <[email-masked]>
Subject: Re: [Ietf-caldav] comments on version 10 of the CalDAV draft
Date: Wed, 5 Apr 2006 12:11:43 -0700
To: Cyrus Daboo <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

Cyrus,

On Apr 5, 2006, at 10:34 AM, Cyrus Daboo wrote:
>
>> 7.9 (Support for the CALDAV:free-busy-query REPORT is REQUIRED)
>>
>> If the Depth header is included, does the response contain all
>> intermediate depths or only the specified depth?
>
> Depth can be 0, 1 or infinity so I'm not quite sure what you are  
> getting at here. Can you explain some more?

If I query at say depth 2, do I get a response only from depth 2 or  
also from depth 1?

>
>>
>> (Paragraph: If the current user is not granted the CALDAV:read-free-
>> busy.... This restriction will prevent users from discovering URLs of
>> resources for which they are only granted the CALDAV:read-free-busy
>> privilege.)
>>
>> How does this prevent users from discovering URLS for resources for
>> which they are granted privileges? Doesn't it prevent them from them
>> discovering URLs for which they have no privileges?
>
> This simply means that if I only give you CALDAV:read-free-busy  
> privilege on a resource you will not be able to discover the  
> existence of that resource if you don't already have the uri.
>

I think the wording needs to be changed. Instead of

>> This restriction will prevent users from discovering URLs of
>> resources for which they are only granted the CALDAV:read-free-busy
>> privilege.

change to

This restriction will prevent users from discovering URLs of
resources for which they are not granted at least the CALDAV:read- 
free-busy
privilege.

Cheers,
Jeff

Date: Wed, 05 Apr 2006 13:34:09 -0400
From: Cyrus Daboo <[email-masked]>
To: Jeff McCullough <[email-masked]>, CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] comments on version 10 of the CalDAV draft

Hi Jeff,
Thanks for your comments:

--On April 5, 2006 1:44:06 AM -0700 Jeff McCullough <[email-masked]> 
wrote:

> 4.2 (last paragraph starting: Calendar collections MUST only contain
> calendar object resources .....)
>
> This section mostly discusses what should not be. Can you also  include
> some text about what should be true.

Ok - reworded and reformatted into a list with some additional explanation 
of the restrictions themselves.

> 5.1.1 (second example:  In this example, the OPTIONS method returns  the
> value "calendar-access" in the DAV ....may support properties ....)
>
> Why is this "may" support, since the earlier text in 5.1 states a  MUST?
> Maybe the "may" can just be removed?

Done.

> 5.2.1 - 5.2.4
>
> While there is a section marked conformance, there is conformance
> information in the description section. Probably all conformance
> information should be in the conformance section for consistency sake.

Done.

> 5.2.5
>
> There may be value in clarifying the first sentence to say that the
> CalDAV specification requires an additional precondition rather than
> creates a precondition.

Done.

> 5.3.2
>
> Probably a silly nit, but why does the example add an entry for a  2001
> Bastille Day Party in 2005?

OK - we'll have the party in 2006 then!

> 5.3.4 (last paragraph: A response to a PUT request MUST NOT contain  an
> ETag response header ....)
>
> Why shouldn't the server respond with the ETag it used to store the
> calendar object? Wouldn't that be more efficient than making the  client
> query the server to determine what it used?

There is a lot of debate about the meaning of an ETag header on a PUT and I 
believe there will be some work to tighten this up in the future. What we 
put in CalDAV was what we felt was best under the current conditions.

> 6.2.1 (description section)
>
> This property specify the URL of collections that either are  calendar ...
>
> should be:
> This property specifies the URL of collections that are either calendar

Done.

> 7.2
>
> You may want to reorder the sentences in this paragraph to have the  MUST
> part before the MAY part. Also the "subject also to the value of  the
> Depth request header" should be a separate sentence.

Actually the MUST should be after the MAY. However, I have reworded this to 
make it a little clearer.

> 7.5
>
> In this section you refer to information that is listed later in the
> document. It isn't clear from the text how the client specifies one  of
> the three options. Yes, that is covered in later sections, but it  would
> be worth bringing it forward here as well.

This section has been completely rewritten for the next draft and no longer 
suffers from this problem.

> 7.7 (paragraph starting: CALDAV:supported-filter....)
>
> The last sentence is a bit hard to understand the way it is worded. I
> don't think it is completely obvious why it is worded as such. From  our
> conversation, I understand this format is similar to the way it  is in
> WebDAV. There may be some value in clarifying that.

OK, I added a sentence to clarify this.

> 7.7.x example reports
>
> The response date is Nov 2005 while some of the data elements have  last
> modified dates in 2006.

Fixed.

> 7.7.1
>
> It would be helpful if you were to explain more about the dates that  are
> stored on the server. That way the example returns will be  clearer. I
> finally found your full reports at the end of the  document, though it
> would take much to clarify it in text here.

I've added 'see Section ...' references to all of the examples in the 
REPORT section to point to the data being used in the examples.

> In the first example, you specify the properties that you want  returned.
> In the response, you have DTSTAMP which is not included in  the request
> property list.

Fixed.

>
> 7.9 (Support for the CALDAV:free-busy-query REPORT is REQUIRED)
>
> If the Depth header is included, does the response contain all
> intermediate depths or only the specified depth?

Depth can be 0, 1 or infinity so I'm not quite sure what you are getting at 
here. Can you explain some more?

>
> (Paragraph: If the current user is not granted the CALDAV:read-free-
> busy.... This restriction will prevent users from discovering URLs of
> resources for which they are only granted the CALDAV:read-free-busy
> privilege.)
>
> How does this prevent users from discovering URLS for resources for
> which they are granted privileges? Doesn't it prevent them from them
> discovering URLs for which they have no privileges?

This simply means that if I only give you CALDAV:read-free-busy privilege 
on a resource you will not be able to discover the existence of that 
resource if you don't already have the uri.

> 9.2 (Purpose: Specifies a request that lists the ....)
> Change "lists" to "includes".

Done.

> 9.5 (Description: 3rd paragraph: 2nd sentence: Given that XML parsers
> normalizes the two-character....)
>
> change normalizes to  normalize

Done.

> Appendix B.
>
> In the example the  >> Response << label is placed in the middle of  the
> request. The response label should follow </C:calendar-query>.
>
> Also the HTTP/1.1 200 OK
> Date: .....
> Content-Type: text/calendar
> Content-Length: xxxx
>
> should be included before the <?xml version..... ?> tag.

Done - plus I also added proper HTTP headers for the response.

-- 
Cyrus Daboo

To: CalDAV DevList <[email-masked]>
From: Jeff McCullough <[email-masked]>
Date: Wed, 5 Apr 2006 01:44:06 -0700
Subject: [Ietf-caldav] comments on version 10 of the CalDAV draft

Bernard,

Here are the comments I have on the version 10 CalDAV draft. Many of  
these we already discussed.

4.2 (last paragraph starting: Calendar collections MUST only contain  
calendar object resources .....)

This section mostly discusses what should not be. Can you also  
include some text about what should be true.

5.1.1 (second example:  In this example, the OPTIONS method returns  
the value "calendar-access" in the DAV ....may support properties ....)

Why is this "may" support, since the earlier text in 5.1 states a  
MUST?  Maybe the "may" can just be removed?

5.2.1 - 5.2.4

While there is a section marked conformance, there is conformance  
information in the description section. Probably all conformance  
information should be in the conformance section for consistency sake.

5.2.5

There may be value in clarifying the first sentence to say that the  
CalDAV specification requires an additional precondition rather than  
creates a precondition.

5.3.2

Probably a silly nit, but why does the example add an entry for a  
2001 Bastille Day Party in 2005?

5.3.4 (last paragraph: A response to a PUT request MUST NOT contain  
an ETag response header ....)

Why shouldn't the server respond with the ETag it used to store the  
calendar object? Wouldn't that be more efficient than making the  
client query the server to determine what it used?

6.2.1 (description section)

This property specify the URL of collections that either are  
calendar ...

should be:
This property specifies the URL of collections that are either calendar

7.2

You may want to reorder the sentences in this paragraph to have the  
MUST part before the MAY part. Also the "subject also to the value of  
the Depth request header" should be a separate sentence.

7.5

In this section you refer to information that is listed later in the  
document. It isn't clear from the text how the client specifies one  
of the three options. Yes, that is covered in later sections, but it  
would be worth bringing it forward here as well.

7.7 (paragraph starting: CALDAV:supported-filter....)

The last sentence is a bit hard to understand the way it is worded. I  
don't think it is completely obvious why it is worded as such. From  
our conversation, I understand this format is similar to the way it  
is in WebDAV. There may be some value in clarifying that.

7.7.x example reports

The response date is Nov 2005 while some of the data elements have  
last modified dates in 2006.

7.7.1

It would be helpful if you were to explain more about the dates that  
are stored on the server. That way the example returns will be  
clearer. I finally found your full reports at the end of the  
document, though it would take much to clarify it in text here.

In the first example, you specify the properties that you want  
returned. In the response, you have DTSTAMP which is not included in  
the request property list.

7.9 (Support for the CALDAV:free-busy-query REPORT is REQUIRED)

If the Depth header is included, does the response contain all  
intermediate depths or only the specified depth?

(Paragraph: If the current user is not granted the CALDAV:read-free- 
busy.... This restriction will prevent users from discovering URLs of  
resources for which they are only granted the CALDAV:read-free-busy  
privilege.)

How does this prevent users from discovering URLS for resources for  
which they are granted privileges? Doesn't it prevent them from them  
discovering URLs for which they have no privileges?

9.2 (Purpose: Specifies a request that lists the ....)
Change "lists" to "includes".

9.5 (Description: 3rd paragraph: 2nd sentence: Given that XML parsers  
normalizes the two-character....)

change normalizes to  normalize

Appendix B.

In the example the  >> Response << label is placed in the middle of  
the request. The response label should follow </C:calendar-query>.

Also the HTTP/1.1 200 OK
Date: .....
Content-Type: text/calendar
Content-Length: xxxx

should be included before the <?xml version..... ?> tag.

Cheers,
Jeff

Jeff McCullough
[email-masked]

Date: Tue, 04 Apr 2006 10:54:49 -0400
From: Bernard Desruisseaux <[email-masked]>
To: "Kervin L. Pierre" <[email-masked]>
Subject: Re: [Ietf-caldav] Fwd: Comments on CalDav-10 draft
Cc: Alexey Melnikov <[email-masked]>, CalDAV DevList <[email-masked]>

Kervin,

The following properties will be added to calendar collections
in the next draft:

CALDAV:max-resource-size
CALDAV:min-date-time
CALDAV:max-date-time
CALDAV:max-instances
CALDAV:max-attendees-per-instance

The draft will also define preconditions with the same names.

Cheers,
Bernard

Kervin L. Pierre wrote:
> Lisa Dusseault wrote:
> 
>>> 5). Postconditions in Section 7.7
>>>
>>> Is there a way to find out what is the value of the server specific 
>>> limit? Also, is it possible for the client to ask "fail request if 
>>> you find more than N responses".
>>> Similar feature is occasionally useful in LDAP searches.
>>
>>
>>
>> No, although a server could put human-readable text inside the 
>> postcondition.  Generally WebDAV doesn't have this kind of feature and 
>> we'd be loathe to invent it for CalDAV.
>>
> 
> This issue came up recently in our testing.  It
> seems that some important limits like
> minimum/maximum valid dates have to be
> pre-configured in each client.  How can a client
> find this out programmatically?  Some computational
> and memory related limits caused by expansions,
> etc.
> 
> The client will have a hard time figuring out why
> an option failed and thus will only be able to
> inform the user.  Users and admins will have to
> figure out the errors and troubleshoot.  If
> CalDAV returned the errors in a machine parsable
> form, then client developers would be able to
> react to those error notices.
> 
> I don't think not addressing is a bad thing, by
> the way.  Suspect that de facto limits will
> probably emerge, as there aren't going to be many
> server implementations anyway, and admins who
> tweak the limits would have to understand that
> they'll be bringing more work on themselves as
> users will start bringing them error messages :)
> 
> Best regards,
> Kervin
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Tue, 04 Apr 2006 10:50:53 -0400
From: Cyrus Daboo <[email-masked]>
To: "Kervin L. Pierre" <[email-masked]>, Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Fwd: Comments on CalDav-10 draft
Cc: Alexey Melnikov <[email-masked]>, CalDAV DevList <[email-masked]>

Hi Kervin,

--On April 4, 2006 10:42:06 AM -0400 "Kervin L. Pierre" 
<[email-masked]> wrote:

>> No, although a server could put human-readable text inside the
>> postcondition.  Generally WebDAV doesn't have this kind of feature and
>> we'd be loathe to invent it for CalDAV.
>>
>
> This issue came up recently in our testing.  It
> seems that some important limits like
> minimum/maximum valid dates have to be
> pre-configured in each client.  How can a client
> find this out programmatically?  Some computational
> and memory related limits caused by expansions,
> etc.
>
> The client will have a hard time figuring out why
> an option failed and thus will only be able to
> inform the user.  Users and admins will have to
> figure out the errors and troubleshoot.  If
> CalDAV returned the errors in a machine parsable
> form, then client developers would be able to
> react to those error notices.
>
> I don't think not addressing is a bad thing, by
> the way.  Suspect that de facto limits will
> probably emerge, as there aren't going to be many
> server implementations anyway, and admins who
> tweak the limits would have to understand that
> they'll be bringing more work on themselves as
> users will start bringing them error messages :)

The next version of the draft now defines an additional set of properties 
on calendar collections that allow the server to advertise its limits. The 
set of properties are:

       5.2.5.  CALDAV:max-resource-size Property . . . . . . . . . .  15
       5.2.6.  CALDAV:min-date-time Property . . . . . . . . . . . .  15
       5.2.7.  CALDAV:max-date-time Property . . . . . . . . . . . .  16
       5.2.8.  CALDAV:max-instances Property . . . . . . . . . . . .  17
       5.2.9.  CALDAV:max-attendees-per-instance Property  . . . . .  18

There are preconditions associated with each of these. So if a client gets 
one of those preconditions as an error it can check the property on the 
resource to see what the actual limit is. Or it can check those properties 
up front and prevent the user from creating events, tasks etc that exceed 
the limits.

-- 
Cyrus Daboo

Date: Tue, 04 Apr 2006 10:42:06 -0400
From: "Kervin L. Pierre" <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Fwd: Comments on CalDav-10 draft
Cc: Alexey Melnikov <[email-masked]>, CalDAV DevList <[email-masked]>

Lisa Dusseault wrote:
>> 5). Postconditions in Section 7.7
>>
>> Is there a way to find out what is the value of the server specific 
>> limit? Also, is it possible for the client to ask "fail request if you 
>> find more than N responses".
>> Similar feature is occasionally useful in LDAP searches.
> 
> 
> No, although a server could put human-readable text inside the 
> postcondition.  Generally WebDAV doesn't have this kind of feature and 
> we'd be loathe to invent it for CalDAV.
> 

This issue came up recently in our testing.  It
seems that some important limits like
minimum/maximum valid dates have to be
pre-configured in each client.  How can a client
find this out programmatically?  Some computational
and memory related limits caused by expansions,
etc.

The client will have a hard time figuring out why
an option failed and thus will only be able to
inform the user.  Users and admins will have to
figure out the errors and troubleshoot.  If
CalDAV returned the errors in a machine parsable
form, then client developers would be able to
react to those error notices.

I don't think not addressing is a bad thing, by
the way.  Suspect that de facto limits will
probably emerge, as there aren't going to be many
server implementations anyway, and admins who
tweak the limits would have to understand that
they'll be bringing more work on themselves as
users will start bringing them error messages :)

Best regards,
Kervin

From: Lisa Dusseault <[email-masked]>
Date: Mon, 3 Apr 2006 13:10:24 -0700
To: Alexey Melnikov <[email-masked]>
Cc: CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] Fwd: Comments on CalDav-10 draft

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

Thanks for these comments Alexey.  Some responses inline:

Begin forwarded message:

> From: Alexey Melnikov <[email-masked]>
> Date: April 3, 2006 12:18:51 PM PDT
> To: Lisa Dusseault <[email-masked]>, Cyrus Daboo  
> <[email-masked]>, Bernard Desruisseaux  
> <[email-masked]>
> Subject: Comments on CalDav-10 draft
>
> Overall I find the document to be well written and full of  
> implementation details. Some comments (and question), mostly  
> nitpicking, below.
> (Please excuse my ignorance, I didn't have time to absorb all  
> WebDav and Calendar related drafts/RFCs. Kindly point me to the  
> right documents.)
>
> 1). In Section 5.2.3 (CALDAV:supported-calendar-component-set)
>
> >Description: The CALDAV:supported-calendar-component-set property MAY
> >     be defined on any calendar collection to specify restrictions on
> >     the calendar component types that calendar object resources may
> >     contain in a calendar collection.
>
> Is this (or rather the example listing both VEVENT and VTODO) in  
> contradiction with the first sentence in section 4.1?:

No, but we were probably a little misleading there.  We will try to  
clarify in 4.1 that a collection can contain more than one kind of  
component, but only one component per resource.

>
> >Calendar object resources contained in calendar collections MUST NOT
> >contain more than one type of calendar components (e.g., VEVENT,
> >VTODO, VJOURNAL, VFREEBUSY, etc.) with the exception of VTIMEZONE
> >components which MUST be specified for each unique TZID parameter
> >value specified in the iCalendar object.
>
> 2). In Section 5.3.3
>
> >Server MUST support the use of non-standard components, properties
> >and parameters in calendar object resources stored via the PUT
> >method.
> >Servers MAY reject any non-standandard components, properties and
> >parameters that have specific values in calendar object resources
> >stored via the PUT method.
>
> It sounds like the MAY gives license to ignore the MUST, if the  
> server decides that any value is not allowed.

You're right. we'll rework this.

>
> 3). In Section 7.5:
>
> Item # 2:
>
> >Return the "master component" and only the "overridden
> >components" that currently or originally overlap the specified
> >time range.
>
> Maybe it is just me, but what is "currently overlap" and  
> "originally overlap"?

It's a particularly confusing part of iCalendar. We'll try to define  
those phrases in context.

>
> 4). Preconditions in Section 7.7 (CALDAV:calendar-query report):
>
> (CALDAV:valid-filter) - for ease of implementations it would be  
> nice to have a pointer to the section(s) describing all valid or  
> invalid filters.

I'm sure you're right and we'll try to do a bit more of this kind of  
reference.

>
> 5). Postconditions in Section 7.7
>
> Is there a way to find out what is the value of the server specific  
> limit? Also, is it possible for the client to ask "fail request if  
> you find more than N responses".
> Similar feature is occasionally useful in LDAP searches.

No, although a server could put human-readable text inside the  
postcondition.  Generally WebDAV doesn't have this kind of feature  
and we'd be loathe to invent it for CalDAV.

>
> 6). In Section 7.7.1
>
> In the second to the last line of the first paragraph: duplicated  
> word "only".
>
> 7). In Section 9.5.6
>
> >Description: The CALDAV:limit-recurrence-set XML element specifies
> >that for a give calendaring REPORT request the server MUST only
> >return the "master component" as well as the "overridden
> >components" that specify one of more recurrence instances whose
> ...
> Should the be "zero or more"?
> Or does presence of the CALDAV:limit-recurrence-set in a request  
> means that the server is not to return the "master component" if no  
> "overridden component" falls between the specified dates?

The limit-recurrence-set element does not affect whether or not the  
master component gets returned.  That master component is always  
returned if the resource matches the filter.   We'll try to spell  
this out in a little more detail.

>
> 8). In Section 9.6.1:
>
> I think the last word of the Description should be "match", not  
> "matches" (as "elements" is plural).

thx

>
> 9). In Section 9.6.4
>
> CALDAV:text-match XML element seems like a good place for using  
> comparators!
> A boolean "caseless" parameter doesn't seem to be sufficient.
>
> Also, why the requirement to follow [UNICODE4] is only a SHOULD and  
> not a MUST?
> I think MUST is needed to get consistent behavior.
> (Maybe you want to say that support for ascii-only case mapping is  
> mandatory and for the rest of Unicode optional?)

In the long run I agree with you about comparators, but they're not  
in common use in WebDAV yet.  We do need to clarify the Unicode  
requirements.

>
> Alexey
>
thanks,

Lisa

--Apple-Mail-23-431584174
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">Thanks for these comments =
Alexey.=A0 Some responses inline:<BR><DIV><BR><DIV>Begin forwarded =
message:</DIV><BR class=3D"Apple-interchange-newline"><BLOCKQUOTE =
type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><FONT face=3D"Helvetica" =
size=3D"3" color=3D"#000000" style=3D"font: 12.0px Helvetica; color: =
#000000"><B>From: </B></FONT><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">Alexey Melnikov &lt;<A =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt=
;</FONT></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><FONT face=3D"Helvetica" =
size=3D"3" color=3D"#000000" style=3D"font: 12.0px Helvetica; color: =
#000000"><B>Date: </B></FONT><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">April 3, 2006 12:18:51 PM =
PDT</FONT></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><FONT face=3D"Helvetica" =
size=3D"3" color=3D"#000000" style=3D"font: 12.0px Helvetica; color: =
#000000"><B>To: </B></FONT><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">Lisa Dusseault &lt;<A =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;, =
Cyrus Daboo &lt;<A =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;, Bernard =
Desruisseaux &lt;<A =
href=3D"mailto:[email-masked]">bernard.desruisseaux@oracl=
e.com</A>&gt;</FONT></DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; "><FONT face=3D"Helvetica" =
size=3D"3" color=3D"#000000" style=3D"font: 12.0px Helvetica; color: =
#000000"><B>Subject: </B></FONT><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica"><B>Comments on CalDav-10 =
draft</B></FONT></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV> =
<DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Overall I find the document to be well written and =
full of implementation details. Some comments (and question), mostly =
nitpicking, below.</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">(Please excuse my =
ignorance, I didn't have time to absorb all WebDav and Calendar related =
drafts/RFCs. Kindly point me to the right documents.)</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">1). In =
Section 5.2.3 (CALDAV:supported-calendar-component-set)</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">&gt;Description: The CALDAV:supported-calendar-component-set property =
MAY</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">&gt; <SPAN =
class=3D"Apple-converted-space">=A0 =A0 </SPAN>be defined on any =
calendar collection to specify restrictions on</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">&gt; <SPAN class=3D"Apple-converted-space">=A0 =A0 =
</SPAN>the calendar component types that calendar object resources =
may</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">&gt; <SPAN =
class=3D"Apple-converted-space">=A0 =A0 </SPAN>contain in a calendar =
collection.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Is this (or rather the example listing both VEVENT =
and VTODO) in contradiction with the first sentence in section =
4.1?:</DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>No, but we were probably a =
little misleading there.=A0 We will try to clarify in 4.1 that a =
collection can contain more than one kind of component, but only one =
component per resource.</DIV><BR><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">&gt;Calendar object resources contained in calendar collections MUST =
NOT</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">&gt;contain more than one type =
of calendar components (e.g., VEVENT,</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">&gt;VTODO, VJOURNAL, VFREEBUSY, etc.) with the exception of =
VTIMEZONE</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">&gt;components which MUST be =
specified for each unique TZID parameter</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">&gt;value specified in the iCalendar object.</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">2). In =
Section 5.3.3</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">&gt;Server MUST support the use of non-standard =
components, properties</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">&gt;and parameters in =
calendar object resources stored via the PUT</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">&gt;method.</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">&gt;Servers =
MAY reject any non-standandard components, properties and</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">&gt;parameters that have specific values in calendar =
object resources</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">&gt;stored via the PUT =
method.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">It sounds like the MAY gives license to ignore the =
MUST, if the server decides that any value is not =
allowed.</DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV>You're right. we'll rework =
this.</DIV><DIV><BR><BLOCKQUOTE type=3D"cite"><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">3). In =
Section 7.5:</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Item # 2:</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">&gt;Return the "master =
component" and only the "overridden</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">&gt;components" that currently or originally overlap the =
specified</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">&gt;time range.</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Maybe it =
is just me, but what is "currently overlap" and "originally =
overlap"?</DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>It's a particularly =
confusing part of iCalendar. We'll try to define those phrases in =
context.</DIV><BR><BLOCKQUOTE type=3D"cite"><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">4). =
Preconditions in Section 7.7 (CALDAV:calendar-query report):</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">(CALDAV:valid-filter) - for ease of implementations it would be nice =
to have a pointer to the section(s) describing all valid or invalid =
filters.</DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>I'm sure you're right and =
we'll try to do a bit more of this kind of =
reference.=A0=A0</DIV><BR><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">5). =
Postconditions in Section 7.7</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Is there a way to find out what =
is the value of the server specific limit? Also, is it possible for the =
client to ask "fail request if you find more than N =
responses".</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Similar feature is occasionally =
useful in LDAP searches.</DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>No, although a server could =
put human-readable text inside the postcondition.=A0 Generally WebDAV =
doesn't have this kind of feature and we'd be loathe to invent it for =
CalDAV.</DIV><BR><BLOCKQUOTE type=3D"cite"><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">6). In =
Section 7.7.1</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">In the second to the last line of the first =
paragraph: duplicated word "only".</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">7). In Section 9.5.6</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">&gt;Description: The CALDAV:limit-recurrence-set XML element =
specifies</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">&gt;that for a give calendaring =
REPORT request the server MUST only</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">&gt;return =
the "master component" as well as the "overridden</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">&gt;components" that specify one of more recurrence =
instances whose</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">...</DIV><DIV style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Should =
the be "zero or more"?</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">Or does presence of the =
CALDAV:limit-recurrence-set in a request means that the server is not to =
return the "master component" if no "overridden component" falls between =
the specified dates?</DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>The limit-recurrence-set =
element does not affect whether or not the master component gets =
returned.=A0 That master component is always returned if the resource =
matches the filter.=A0 =A0We'll try to spell this out in a little more =
detail.</DIV><BR><BLOCKQUOTE type=3D"cite"><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">8). In =
Section 9.6.1:</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">I think the last word of the Description should be =
"match", not "matches" (as "elements" is =
plural).</DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV>thx</DIV><DIV><BR><BLOCKQUOTE =
type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">9). In Section 9.6.4</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">CALDAV:text-match XML element seems like a good place for using =
comparators!</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">A boolean "caseless" parameter =
doesn't seem to be sufficient.</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Also, why the requirement to =
follow [UNICODE4] is only a SHOULD and not a MUST?</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">I think MUST is needed to get consistent =
behavior.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">(Maybe you want to say that =
support for ascii-only case mapping is mandatory and for the rest of =
Unicode optional?)</DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>In the long run I agree =
with you about comparators, but they're not in common use in WebDAV =
yet.=A0 We do need to clarify the Unicode =
requirements.</DIV><BR><BLOCKQUOTE type=3D"cite"><DIV style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">Alexey</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><BR></DIV></BLOCKQUOTE>thanks,</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Lisa</DIV><BR =
class=3D"khtml-block-placeholder"><DIV><BR =
class=3D"khtml-block-placeholder"></DIV></BODY></HTML>=

--Apple-Mail-23-431584174--