Re: WebDAV sync informal last call
Werner Donné <[email protected]> Fri, 15 Apr 2011 22:32:57 +0200
| Newsgroups | gmane.ietf.webdav |
|---|---|
| Message-ID | <[email protected]> |
--Apple-Mail-2-322349351 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Arnaud, Op 15 Apr 2011 om 11:37 heeft Arnaud Quillaud <[email protected]> h= et volgende geschreven: > On 04/13/2011 09:33 PM, Werner Donn=C3=A9 wrote: >>=20 >> Hi Cyrus, >>=20 >> Here are my comments: >>=20 >> Section 3.2 >>=20 >> A resource must appear only once. What happens when there is more than on= e binding for a resource? Should only one of those bindings be reported? If s= o, should always the same binding be reported (perhaps the client knows he r= esource under a specific name)? The latter would have a significant impact o= n a server implemenation. > You are right. Reporting only one binding would be very confusing. >=20 > What about >=20 > <<A given mapping URI MUST appear only once in the response.>> That would be fine. >=20 > In 3.5.1, we may want to also cover this scenario by adding to=20 > << > A resource MUST be reported as changed if its entity tag value > (defined in Section 3.11 of [RFC2616]) has changed since the request > sync-token was generated. > >> > the following statement: > << > If the resource has multiple mapping URIs within the scope of the report, i= t MUST be reported as changed once for each such URI. > >> Indeed. >=20 >> Section 3.3 (last paragraph) >>=20 >> When some collection can't be synchronized the status code 405 is put in i= ts DAV:response. However, this would imply the REPORT method is not allowed f= or the resource, > Given that the status code is part of the DAV:response and its interpretat= ion clearly defined by the spec, I'm not sure there is much risk of people i= nterpreting it that way. I think WebDAV implementers are already used to HTT= P status codes being used in "twisted" ways (e.g. PROPPATCH responses). >> while it is only this report type that isn't. Wouldn't the status code 4= 03 be more appropriate in this case? > 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 allow= ed, for whatever reason. Using this code wouldn't "twist" anything. >=20 >> The paragraph ends by saying that such a fact should be reported only onc= e. What is to be reported then for this resource when the same report is req= uested a second time? > Nothing (assuming that the second report includes a valid sync-token). > Would >=20 > << > The 405 response MUST be sent only during an initial synchronization (as d= efined in 3.4). > >> >=20 > be more clear ? Yes. >=20 >> Section 3.5.1 >>=20 >> second paragraph: >>=20 >> This paragraph states that when a resource is deleted and a new one is cr= eated using the same URI only a changed resource should be reported. However= , this would imply a relationship between the deleted and the newly created r= esource. This is in contradiction with the BIND-spec, because the resource-i= d property would be different. In other words, no such relationship exists. > =46rom a synchronization perspective, there is definitely a relationship s= ince both resources are sharing the same URI. And clients can definitely inc= lude the resource-id property in the list of requested properties if they ca= re about the exact scenario that led to the change. If behind the client there is a versioning system, e.g. a DeltaV server, the= n only the inclusion of the resource-id property would enable the distiction= between a new version of an existing resource or a new resource altogether,= which could imply a new version of the containing collection. However, this= would put an unreasonable burden on the client (or whatever is behind it) i= n that it would have to maintain a possibly huge mapping between the resourc= e-ids and its own resource-ids. If the change report would be preceded by a d= eletion report all this would become much simpler, because it is just more g= eneral. Of course, servers don't necessarily have the information to produce= such a detailed report. They could fall back to the simple change report in= this case. A use-case for this is two DeltaV servers that could maintain congruent vers= ion histories for certain resources. This is a rather advanced synchronizati= on scenario that is possible without complicating the synchronization protoc= ol. >=20 >> I think a deletion and a creation should be reported in this case. If th= e same resource is rebound to the same URI nothing should be reported. >=20 >> Remark: >>=20 >> Resources for which the properties or the contents have been updated sinc= e the last synchronization and which hence have a changed getlastmodifed pro= perty are not reported as changed. This means the methods PUT and PROPPATCH h= ave no impact on the result of the report. > =46rom 3.5.1: >=20 > << > A resource MUST be reported as changed if its entity tag value > (defined in Section 3.11 of [RFC2616]) has changed since the request > sync-token was generated. > >>. >=20 > So while you are generally right for PROPPATCH, a PUT will have an impact.= That is, unless the ETag of the resource is not affected by the PUT of cour= se. >=20 > In other words, this report deals with synchronization based on content on= ly. But maybe I missed your point. No, you are right. That is what I mean. I suggest to use the getlastmodified= property as a complement, because etags are not mandatory and they don't co= ver properties. There is also the scenario of a DeltaV server that uses a different etag for= each version of a resource. However, when some resource is checked out it c= an be updated several times before being checked in again. Do these intermed= iate updates require a new etag each time? If not, the client may still have= the permission to read the contents of the checked out resource and hence w= ould be interested in synchronizing the intermediate updates. > Arnaud Quillaud Best regards, Werner Donn=C3=A9. -- http://www.pincette.biz/ Handling your documents with care, wherever you are.= --Apple-Mail-2-322349351 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><body bgcolor=3D"#FFFFFF"><div>Hi Arnaud,<br></div><div><br>Op 15 Apr 2= 011 om 11:37 heeft Arnaud Quillaud <<a href=3D"mailto:arnaud.quillaud@ora= cle.com">[email protected]</a>> het volgende geschreven:<br><br>= </div><div></div><blockquote type=3D"cite"><div> On 04/13/2011 09:33 PM, Werner Donn=C3=A9 wrote: <blockquote cite=3D"mid:[email protected]= z" type=3D"cite"> <pre wrap=3D"">Hi Cyrus, Here are my comments: Section 3.2 A resource must appear only once. What happens when there is more than one b= inding for a resource? Should only one of those bindings be reported? If so,= should always the same binding be reported (perhaps the client knows he res= ource under a specific name)? The latter would have a significant impact on a= server implemenation. </pre> </blockquote> You are right. Reporting only one binding would be very confusing.<br> <br> What about<br> <br> <<A given mapping URI MUST appear only once in the response.>><br></div></blockquote><div><br></div>That would be fin= e.<div><br><blockquote type=3D"cite"><div> <br> In 3.5.1, we may want to also cover this scenario by adding to <br> <<<br> <pre class=3D"newpage">A resource MUST be reported as changed if its ent= ity tag value (defined in <a href=3D"http://tools.ietf.org/html/rfc2616#section-3.11">S= ection 3.11 of [RFC2616]</a>) has changed since the request sync-token was generated.</pre> >><br> the following statement:<br> <<<br> If the resource has multiple mapping URIs within the scope of the report, it MUST be reported as changed once for each such URI.<br> >><br></div></blockquote><div><br></div>Indeed.</div><div><blockqu= ote type=3D"cite"><div> <blockquote cite=3D"mid:[email protected]= z" type=3D"cite"> <pre wrap=3D"">Section 3.3 (last paragraph) When some collection can't be synchronized the status code 405 is put in its= DAV:response. However, this would imply the REPORT method is not allowed fo= r the resource,</pre> </blockquote> Given that the status code is part of the DAV:response and its interpretation clearly defined by the spec, I'm not sure there is much risk of people interpreting it that way. I think WebDAV implementers are already used to HTTP status codes being used in "twisted" ways (e.g. PROPPATCH responses).<br> <blockquote cite=3D"mid:[email protected]= z" type=3D"cite"> <pre wrap=3D""> while it is only this report type that isn't. Wouldn't= the status code 403 be more appropriate in this case? </pre> </blockquote> No strong opinion on this. Might 403 be returned for other reasons ?<br>= </div></blockquote><div><br></div>It is a code that is used in general to in= dicate that something is not allowed, for whatever reason. Using this code w= ouldn't "twist" anything.<br><blockquote type=3D"cite"><div> <blockquote cite=3D"mid:[email protected]= z" type=3D"cite"> <pre wrap=3D"">The paragraph ends by saying that such a fact should be= reported only once. What is to be reported then for this resource when the s= ame report is requested a second time? </pre> </blockquote> Nothing (assuming that the second report includes a valid sync-token).<br> Would<br> <br> <<<br> The 405 response MUST be sent only during an initial synchronization (as defined in 3.4).<br> >><br> <br> be more clear ?<br></div></blockquote><div><br></div>Yes.<br><blockquote= type=3D"cite"><div> <blockquote cite=3D"mid:[email protected]= z" type=3D"cite"> <pre wrap=3D"">Section 3.5.1 second paragraph: This paragraph states that when a resource is deleted and a new one is creat= ed using the same URI only a changed resource should be reported. However, t= his would imply a relationship between the deleted and the newly created res= ource. This is in contradiction with the BIND-spec, because the resource-id p= roperty would be different. In other words, no such relationship exists.</pr= e> </blockquote> =46rom a synchronization perspective, there is definitely a relationship since both resources are sharing the same URI. And clients can definitely include the resource-id property in the list of requested properties if they care about the exact scenario that led to the change.<br></div></blockquote><div><br></div>If behind the cl= ient there is a versioning system, e.g. a DeltaV server, then only the inclu= sion of the resource-id property would enable the distiction between a new v= ersion of an existing resource or a new resource altogether, which could imp= ly a new version of the containing collection. However, this would put an un= reasonable burden on the client (or whatever is behind it) in that it would h= ave to maintain a possibly huge mapping between the resource-ids and its own= resource-ids. If the change report would be preceded by a deletion report a= ll this would become much simpler, because it is just more general. Of cours= e, servers don't necessarily have the information to produce such a detailed= report. They could fall back to the simple change report in this case.</div= ><div><br></div><div>A use-case for this is two DeltaV servers that could ma= intain congruent version histories for certain resources. This is a rather a= dvanced synchronization scenario that is possible without complicating the s= ynchronization protocol.</div><div><blockquote type=3D"cite"><div> <blockquote cite=3D"mid:[email protected]= z" type=3D"cite"> <pre wrap=3D""> I think a deletion and a creation should be reported i= n this case. If the same resource is rebound to the same URI nothing should b= e reported. </pre> </blockquote> <blockquote cite=3D"mid:[email protected]= z" type=3D"cite"> <pre wrap=3D"">Remark: Resources for which the properties or the contents have been updated since t= he last synchronization and which hence have a changed getlastmodifed proper= ty are not reported as changed. This means the methods PUT and PROPPATCH hav= e no impact on the result of the report. </pre> </blockquote> =46rom 3.5.1:<br> <br> <<<br> <pre class=3D"newpage">A resource MUST be reported as changed if its ent= ity tag value (defined in <a href=3D"http://tools.ietf.org/html/rfc2616#section-3.11">S= ection 3.11 of [RFC2616]</a>) has changed since the request sync-token was generated. </pre> >>.<br> <br> So while you are generally right for PROPPATCH, a PUT will have an impact. That is, unless the ETag of the resource is not affected by the PUT of course.<br> <br> In other words, this report deals with synchronization based on content only. But maybe I missed your point.<br></div></blockquote><div>= <br></div>No, you are right. That is what I mean. I suggest to use the getla= stmodified property as a complement, because etags are not mandatory and the= y don't cover properties.</div><div><br></div><div>There is also the scenari= o of a DeltaV server that uses a different etag for each version of a resour= ce. However, when some resource is checked out it can be updated several tim= es before being checked in again. Do these intermediate updates require a ne= w etag each time? If not, the client may still have the permission to read t= he contents of the checked out resource and hence would be interested in syn= chronizing the intermediate updates.</div><div><br><blockquote type=3D"cite"= ><div> =20 Arnaud Quillaud</div></blockquote><div><br></div>Best regards,</div><div= ><br></div><div>Werner Donn=C3=A9.</div><div>--<br><span class=3D"Apple-styl= e-span" style=3D"-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -w= ebkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composi= tion-frame-color: rgba(77, 128, 180, 0.230469); "><div><a href=3D"http://www= .pincette.biz/">http://www.pincette.biz/</a></div><div>Handling your documen= ts with care, wherever you are.</div></span></div></body></html>= --Apple-Mail-2-322349351--