- From: Werner Donné <werner.donne@pincette.biz>
- Date: Tue, 19 Apr 2011 10:14:13 +0200
- To: Cyrus Daboo <cyrus@daboo.name>
- Cc: Arnaud Quillaud <arnaud.quillaud@oracle.com>, w3c-dist-auth@w3.org
Hi Cyrus, On 18 Apr 2011, at 16:16, Cyrus Daboo wrote: > Hi Werner, > > --On April 15, 2011 10:32:57 PM +0200 Werner Donné <werner.donne@pincette.biz> wrote: > >> No strong opinion on this. Might 403 be returned for other reasons ? >> >> >> >> It is a code that is used in general to indicate that something is not >> allowed, for whatever reason. Using this code wouldn't "twist" anything. >> > > I think we do need to distinguish the specific problem being dealt with here: namely that a depth:infinity sync cannot "traverse" into a specific collection. I would be willing to change the 405 to a 403, with the proviso that a DAV:error element MUST also be returned and that MUST contain a DAV:supports-parent-depth-infinity-sync element. That way clients can clear distinguish between this case and other types of 403. I agree. > >> << >> The 405 response MUST be sent only during an initial synchronization (as >> defined in 3.4). >> >> >> be more clear ? >> >> >> >> Yes. > > That statement about the "405" case is not entirely true. If such a collection is created after the initial sync on one of its parents, then it will need to be reported in the "405" state on the next sync of that parent. I think the current text accurately describes the situation: > > The 405 response MUST be sent once, when the collection is first > reported to the client. What is the rationale behind sending it only once? > > > -- > Cyrus Daboo > Best regards, Werner. -- http://www.pincette.biz/ Handling your documents with care, wherever you are.
Received on Tuesday, 19 April 2011 08:14:47 UTC