Re: draft-daboo-webdav-sync-01

Hi,

below are some comments on draft-daboo-webdav-sync-01.

High Level:

First of all, the complexity of this mainly depends on the type of 
server. For instance, for a Subversion-style store (with a global change 
counter) this could be almost trivial, while it may be very hard to 
implement for many others.

Also, there's some related work in this area, such as:

- using a feed format (Atom?)

- sending notifications over XMPP 
(<http://greenbytes.de/tech/webdav/draft-hildebrand-webdav-notify-00.html>)

- Microsoft's take on it: SUBSCRIBE/UNSUBSCRIBE/NOTIFY/POLL 
(<http://msdn.microsoft.com/en-us/library/aa143117(EXCHG.65).aspx>)

- Notifications, as defined in JCR (Java Content Repository), which at 
some point we'll want to transport over HTTP....

- RFC 3253 (DeltaV) and WebDAV BIND which clarify what the state of a 
collection is, and define a property (DAV:resource-id) which could be 
used to define "sameness" of a WebDAV resource under name changes.


Regarding Section 3, "Open Issues":

"1. Should we try and discriminate between changes to the body of a 
resource and changes to the properties?"

I think we need to.

"2. If we indicate a property change, should we return the list of 
properties that changed on each resource (propnames NOT values)?"

Why only the names?

"3. Should we provide a way to indicate that a 'new' resource is new in 
the collection as a result of a COPY or MOVE from another location, as 
opposed to being created?"

At least MOVE and COPY should be handled separately; DAV:resource-id 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-23.html#rfc.section.3.1>) 
could be used for that.

"4. Should we provide a way to indicate that a 'deleted' resource was 
removed from the collection as a result of a MOVE to another location, 
as opposed to being actually deleted?"

Not sure it makes a difference.

"5. How should ACLs be handled? e.g. a resource is visible to a user at 
one point in time, then its <read> privilege is removed. Should the 
resource be marked as having been deleted when next synchronized?"

Why deleted? I realize that some servers return 404 for resources the 
user doesn't have read access to, but that's not the general case.

"6. Do we want a special indicator for a resource that was deleted and 
then re-created, as opposed to just indicating that the resource was 
'changed'?"

I think the information is needed. It could be provided using 
DAV:resource-id.


Other substantial comments:

1. Introduction

"This can currently be done using a WebDAV PROPFIND request on a 
collection to list all members of a collection along with their HTTP 
ETag values, which allows the client to determine which resources were 
changed, added or deleted."

s/HTTP ETag values/DAV:getetag property values/

Also note this wouldn't necessarily detect property changes.

"Additionally, a new property is added to collection resources that is 
used to convey a "synchronization token" that is guaranteed to change 
when the contents of the collection have changed."

You need to define the term "contents" here. Obviously, it includes data 
that is not included in the collection's state, as defined in RFC 3253, 
for example.


4.1

"HTTP already defines a synchronization token in the form of an entity 
tag which is attached to a resource. However, the entity tag is not 
always required to be 'strong' and thus cannot be relied on absolutely 
as a valid synchronization indicator. In addition, there is no concept 
of an entity tag for a collection's contents."

Sic -- it's because that term is not defined (at least not in the way 
this spec wants to use it :-)

4.2

"To implement the behavior for this REPORT a server needs to keep track 
of changes to any resources in a collection."

Need to clarify what "in a collection" means; I guess "Internal Member", 
as defined by RFC 4918, Section 3?

"The request URI MUST be a collection."

Why?

"The "Depth" header MUST be ignored by the server and SHOULD NOT be sent 
by the client."

Nope, see earlier discussion.

"The response body for a successful request MUST be a DAV:multistatus 
XML element, which MUST contain one DAV:sync-token element in addition 
to any DAV:sync-response elements."

Not sure why this re-uses DAV:multistatus, and then puts something 
completely else as child elements.


Editorial Comments:

- state venue for discussion

- expand abbreviations on first use

- 4.1

"The is specification defines a new WebDAV REPORT that is used to enable 
client-server collection synchronization."

"The is"?

"That is done by the client sending an empty token value to the server."

I think "no token" would be better.


- "4.2 REPORT defined"

Title.

"If the report is not available, clients MUST NOT attempt to execute one."

Requirement unnecessary.



Best regards, Julian

Received on Monday, 23 March 2009 14:21:14 UTC