WebDAV sync informal last call

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

WebDAV sync informal last call

Cyrus Daboo-2
Hi folks,
It is our intent to submit draft-daboo-webdav-sync-05 to the IETF. As such
we would appreciate it if you could give this one final review and post
comments back to this list (including "ok to go" comments) so we can show
the ADs that review has been done by various WebDAV experts.

BTW there are already several client and server implementations of this
draft now and I believe most implementors are happy with what we have done.

--
Cyrus Daboo


Reply | Threaded
Open this post in threaded view
|

Re: WebDAV sync informal last call

Werner Donné-2
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.

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, while it is only this report type that isn't. Wouldn't the status code 403 be more appropriate in this case?

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?

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. 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.

Best regards,

Werner Donné.

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

Op 07 Apr 2011 om 16:00 heeft Cyrus Daboo <[hidden email]> het volgende geschreven:

> Hi folks,
> It is our intent to submit draft-daboo-webdav-sync-05 to the IETF. As such we would appreciate it if you could give this one final review and post comments back to this list (including "ok to go" comments) so we can show the ADs that review has been done by various WebDAV experts.
>
> BTW there are already several client and server implementations of this draft now and I believe most implementors are happy with what we have done.
>
> --
> Cyrus Daboo
>
>

Reply | Threaded
Open this post in threaded view
|

Re: WebDAV sync informal last call

Werner Donné-2
Hi Arnaud,

Op 15 Apr 2011 om 11:37 heeft Arnaud Quillaud <[hidden email]> 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é.
--
Handling your documents with care, wherever you are.
Reply | Threaded
Open this post in threaded view
|

Re: WebDAV sync informal last call

Cyrus Daboo-2
Hi Werner,

--On April 15, 2011 10:32:57 PM +0200 Werner Donné
<[hidden email]> 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.

> <<
>  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.


--
Cyrus Daboo


Reply | Threaded
Open this post in threaded view
|

Re: WebDAV sync informal last call

Werner Donné-2
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é <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|

Re: WebDAV sync informal last call

Cyrus Daboo-2
Hi Werner,

--On April 19, 2011 10:14:13 AM +0200 Werner Donné
<[hidden email]> wrote:

>> 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?

Same rationale that causes changes to a resource to only be reported once.
Basically a server only sends notification of a change in "state" of a
resource once to anyone particular client for the simple reason that sync
clients are expected to persist some state from the last sync operation.

Simply put a "405" resource is no different from any other, except as
follows:

- When the resource first appears in the sync set, it is reported with a
403+DAV:error code
- No change notifications are sent for the resource since it does not
report any changes
- If the resource is removed, a 404 is returned

With that behavior, the "405" is effectively sent only once.

--
Cyrus Daboo


Reply | Threaded
Open this post in threaded view
|

Re: WebDAV sync informal last call

Werner Donné-2
Hi Cyrus,

On 19 Apr 2011, at 16:08, Cyrus Daboo wrote:

>> What is the rationale behind sending it only once?
>
> Same rationale that causes changes to a resource to only be reported once. Basically a server only sends notification of a change in "state" of a resource once to anyone particular client for the simple reason that sync clients are expected to persist some state from the last sync operation.
>
> Simply put a "405" resource is no different from any other, except as follows:
>
> - When the resource first appears in the sync set, it is reported with a 403+DAV:error code
> - No change notifications are sent for the resource since it does not report any changes
> - If the resource is removed, a 404 is returned
>
> With that behavior, the "405" is effectively sent only once.
>
> --
> Cyrus Daboo


I see what you mean now. Thank you.

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