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

Hi Julian,

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

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

Fixed.

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

Fixed.

> 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