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