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: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 16 Mar 2009 10:52:11 +0100
Message-ID: <49BE214B.7040700@gmx.de>
To: Cyrus Daboo <cyrus@daboo.name>
CC: WebDAV <w3c-dist-auth@w3.org>, vcarddav@ietf.org
Cyrus Daboo wrote:
> ...
>> 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?

The default is 0 anyway (per RFC 3253). Making a requirement on the 
client doesn't make sense here; if Depth values != 0 are not supported, 
then the requirement is on the server to reject the request.

That being said: are you positively sure that the default depth handling 
defined in RFC 3253 does not apply here?

1) addressbook-query

In this case, the scope is the set of address objects contained in the 
address book collection (at the request URI), right? (*)

Thus depth != 0 would essentially mean the same thing, as recursion into 
child collections wouldn't (by definition) find any additional address 
objects. Thus, I don't see any reason to forbid it, just mention it's 
meaningless.

(*) Or is it allowed to address a specific address object?

2) multiget

Again, I think it would become clearer if you could precisely define 
what the scope for Depth 0 is. Does it include indirect child resources 
(they wouldn't be address objects, but could still report WebDAV 
properties, right?)?

> ...

BR, Julian
Received on Monday, 16 March 2009 09:52:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:16 GMT