Re: WebDAV sync informal last call

Hi Arnaud,

Op 15 Apr 2011 om 11:37 heeft Arnaud Quillaud <arnaud.quillaud@oracle.com> het volgende geschreven:

> On 04/13/2011 09:33 PM, Werner Donné wrote:
>> 
>> Hi Cyrus,
>> 
>> Here are my comments:
>> 
>> Section 3.2
>> 
>> A resource must appear only once. What happens when there is more than one binding 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 resource under a specific name)? The latter would have a significant impact on a server implemenation.
> You are right. Reporting only one binding would be very confusing.
> 
> What about
> 
> <<A given mapping URI MUST appear only once in the response.>>

That would be fine.

> 
> In 3.5.1, we may want to also cover this scenario by adding to 
> <<
> 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, it MUST be reported as changed once for each such URI.
> >>

Indeed.
> 
>> 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 for the resource,
> 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).
>>  while it is only this report type that isn't. Wouldn't the status code 403 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 allowed, for whatever reason. Using this code wouldn't "twist" anything.
> 
>> 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 same report is requested a second time?
> Nothing (assuming that the second report includes a valid sync-token).
> Would
> 
> <<
> The 405 response MUST be sent only during an initial synchronization (as defined in 3.4).
> >>
> 
> be more clear ?

Yes.
> 
>> Section 3.5.1
>> 
>> second paragraph:
>> 
>> This paragraph states that when a resource is deleted and a new one is created using the same URI only a changed resource should be reported. However, this would imply a relationship between the deleted and the newly created resource. This is in contradiction with the BIND-spec, because the resource-id property would be different. In other words, no such relationship exists.
> From 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.

If behind the client there is a versioning system, e.g. a DeltaV server, then 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) in that it would have 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 all this would become much simpler, because it is just more general. 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 version histories for certain resources. This is a rather advanced synchronization scenario that is possible without complicating the synchronization protocol.
> 
>>  I think a deletion and a creation should be reported in this case. If the same resource is rebound to the same URI nothing should be reported.
> 
>> Remark:
>> 
>> Resources for which the properties or the contents have been updated since the last synchronization and which hence have a changed getlastmodifed property are not reported as changed. This means the methods PUT and PROPPATCH have no impact on the result of the report.
> From 3.5.1:
> 
> <<
> 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.
> >>.
> 
> 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.
> 
> In other words, this report deals with synchronization based on content only. 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 cover 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 can be updated several times before being checked in again. Do these intermediate 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 would be interested in synchronizing the intermediate updates.

> Arnaud Quillaud

Best regards,

Werner Donné.
--
http://www.pincette.biz/
Handling your documents with care, wherever you are.