W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2009

Re: [VCARDDAV] REPORT related comments, was: vcarddav WGLC on draft-ietf-vcarddav-{carddav, mkcol}

From: Cyrus Daboo <cyrus@daboo.name>
Date: Sun, 15 Mar 2009 22:22:51 -0400
To: Julian Reschke <julian.reschke@gmx.de>, WebDAV <w3c-dist-auth@w3.org>, vcarddav@ietf.org
Message-ID: <C0FC5B418D3606949B2713CE@socrates.local>
Hi Julian,

--On March 13, 2009 3:49:56 PM +0100 Julian Reschke <julian.reschke@gmx.de> 

> 1) Editorial: when referring to specific reports (not the REPORT method),
> the spec sometimes uses "report", and sometimes "REPORT". Please be
> consistent (with a preference on the lowercase variant, to distinguish
> from the actual method name).


> 2) WebDAV reports should be consistent in how various depths are handled
> (see RFC 3253, Section 3.6). The best way to achieve this is by exactly
> defining what the scope is for Depth == 0. If the request URI is a WebDAV
> collection, the behavior for Depth == 1 or Depth == infinity will follow
> from that. Otherwise it should be specified or ruled out (see ACL
> reports).
> 3) Related to that:
> "As a result the "Depth" header MUST be ignored by the server and SHOULD
> NOT be sent by the client." --
> <http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-06#section-8.7>
> Nope. Really :-). This is incompatible with generic report handling.
> Instead, specify the desired behavior for Depth == 0, require clients to
> set Depth == 0 or leave it out, and require servers to return status 400
> for other values (like in RFC 3744).

Ok, so then we go with "the Depth header MUST be present and set to the 
value 0 (zero)" in all of these reports. Is that sufficient?

> 4) Editorial:
> "The request body MUST be a CARDDAV:addressbook-multiget XML element (see
> Section 10.7, which MUST contain at least one DAV: href XML element, and
> one optional CARDDAV:address-data element as defined in Section 10.4."
> -- <http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-06#section-8.7>
> Missing ")" after "Section 10.7".


> 5) It goes on saying:
> "If the Request-URI is a collection resource, then the DAV:href elements
> MUST refer to resources within that collection, and they MAY refer to
> resources at any depth within the collection. As a result the "Depth"
> header MUST be ignored by the server and SHOULD NOT be sent by the
> client. If the Request-URI refers to a non-collection resource, then
> there MUST be a single DAV:href element that is equivalent to the
> Request-URI."
> I think it would be simpler to define it this way:
> "If DAV:href elements are present, the scope of the request is the set of
> resources identified by these elements, which all need to be members (not
> necessarily internal members) of the resource identified by the
> Request-URI. Otherwise, the scope is the resource identified by the
> Request-URI itself."
> This avoids the special-casing, and gets rid of the repeated URI in the
> DAV:href element for non-collections.

I have made this change. Whilst this is technically significant in that it 
changes the way things work when the multiget is targeted at a single URI, 
I don't believe I have seen anyone actually using it that way in CalDAV so 
it won't hurt to do the change here.

Cyrus Daboo
Received on Monday, 16 March 2009 02:23:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:43 UTC