[Ballot discuss]
The internationalization considerations section seems entirelyn
inadequate.  It seems clear that reportes provided in this
specification allow searching on text strings such as location and
names. 

Section 9.6 contains a facility for doing substring matching on
internationalized strings but contains no discussion of normalization,
limited discussion of case folding, and no discussion of other
matching issues that have been problematic for LDAP, IMAP and other
IETF technologies.  This seems quite inadequate.  If the
internationalization community within the IETF is quite sure that this
is OK, I'll remove the discuss.  I just don't see why text matching in
caldav should be so much easier than IDN or LDAP.

IANA Last Call Comment:

Upon approval of this document, the IANA will make the following assignments in the XML Namespaces registry located at
http://www.iana.org/assignments/xml-registry/ns.html

id URI Registration template Reference
caldev urn:ietf:params:xml:ns:caldav None specified RFCtobe-
dusseault-caldav

We understand the above to be the only IANA Actions for this document.
Note: The document defines a large collection of elements for the
namespace but does not request a registry for these elements.

IANA Last Call Comment:

Upon approval of this document, the IANA will make the following assignments in the XML Namespaces registry located at
http://www.iana.org/assignments/xml-registry/ns.html

id URI Registration template Reference
caldev urn:ietf:params:xml:ns:caldav None specified RFCtobe-
dusseault-caldav

We understand the above to be the only IANA Actions for this document.
Note: The document defines a large collection of elements for the
namespace but does not request a registry for these elements.

[Ballot comment]
Note:  reference to 2518bis is a potential blocker, since it's still in the WG; is 2518 good enough or will the bis be done soon enough?

[Ballot discuss]
The internationalization considerations section seems entirelyn
inadequate.  It seems clear that reportes provided in this
specification allow searching on text strings such as location and
names.  Can these strings be internationalized?  If not, what's the
plan to deal with that.  If so, how are normalization and other
internationalization issues handled?  Are there internationalization
concerns regarding sorting of entries?

[Ballot comment]
Note: reference to 2818 is a normative downref.  reference to 2518bis is a potential blocker, since it's still in the WG; is 2518 good enough or will the bis be done soon enough?

[Ballot comment]
I would have preferred to see the ETag issue driven to general consensus across HTTP, DAV, and this. I hope people still try to drive that to consensus.

[Ballot comment]
The second paragraph in the Introduction section says:

'Discussion of this Internet-Draft is taking place on the mailing list
  <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>.'

Is this sentence supposed to be taken out, or maybe refer to 'this memo' instead of 'this Internet-Draft'?

[Ballot discuss]
Based on the SecDir review by Angelos Keromytis and the discussion
  that followed, I expected to see two paragraphs added to the
  Security Considerations section:

    "When rolling up free-busy information, more information about a 
    user's events is exposed if busy periods overlap or abut (this
    tells the client requesting the free-busy information that the
    calendar owner has at least two events, rather than knowing only
    that the calendar owner has one or more events during the busy
    period).  Thus, a conservative approach to calendar data privacy
    would have servers always coalesce busy periods of the same type."

    "Procedure alarms are a known security risk for either clients or 
    servers to handle, particularly when the alarm was created by
    another agent.  Clients and servers are NOT REQUIRED to execute
    such procedure alarms."

[Ballot comment]
At the end of section 5.3.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.

This sentence is hard to interpret - what is the meaning of "the behavior
of the ETag response header is undefined" in addition to a strong enity tag
being forbidden?

(From Gen-ART review by Joel Halpern)

Author's response to Last Call comments on ETags

1) Best common practice in WebDAV

Currently very few, if any at all, WebDAV servers change the content of resource data during a PUT request. Most WebDAV servers do return an ETag on PUT. Thus clients have come to rely on the presence of the ETag to effectively mean that the resource data was stored unchanged and that the ETag can be used in subsequent GET requests etc. This justifies our statement that servers SHOULD return an ETag in a response when the data has not changed.

Now we have CalDAV servers where the resource data MAY be changed. Therefore to be compatible with existing client behavior a server MUST NOT send the ETag in a PUT response when the data changes, otherwise clients will misinterpret it. This justifies our 'MUST NOT' statement.

2) Restricted behavior

The ETag behavior we are talking about is restricted solely to calendar object resources being stored in calendar collections - i.e. it is very specific to CalDAV. This is not 'redefining' HTTP behavior by rather extending it for this one specific application need.

3) Future conflicts

One of Julian's arguments is that our requirement will "risk making CalDAV incompatible with other specs extending HTTP (or HTTP itself, for that matter)". Since we have been careful to require only behavior that already exists in deployed WebDAV servers, CalDAV adds no further incompatibility. If future work to better define the meaning of ETag on PUT ever happens, it will need to take into account the deployed base, and the subset of CalDAV servers will simply happen to be a consistently behaving subset. We believe that our requirements improve the interoperability of CalDAV, without making the future/potential incompatibility problem any worse than it already is.

4) Need/usefulness

In addition to the authors' evaluation of the usefulness of this feature for keeping an offline calendar correct, there have been other requests for predictable behavior w.r.t. PUT and ETags and calendar resources. This was one of the first feature requests from client implementors, including Dan Mosedale and Grant Baillie.

ANA Last Call Comments:

Upon approval of this document the IANA will register the
urn:ietf:params:xml:ns:caldav XML Namespace in the following registry:
http://www.iana.org/assignments/xml-registry/ns.html

We understand this to be the only IANA Action.