Re: Last Call: draft-daboo-webdav-sync-06.txt (Collection Synchronization for WebDAV) to Proposed Standard
Cyrus Daboo wrote: I am not convinced the use of Depth in sync report is violating the definition in 3253. In some ways it is a matter of how you look at the sync. Your viewpoint is that the report asks the collection for its changes - in that case, yes, Depth:0 would apply. The other view is that the report asks each of the child resources to list their change status, in which case Depth:1 and Depth:infinity also makes sense. Which viewpoint is taken probably depends on actual implementation rather than any perceived protocol restrictions. My $.02: I look the sync report as a filtered query for properties (e.g. CALDAV:calendar-query), with the filter being only give me a DAV:response if the resource has been changed/removed since the specified sync-token. A Depth of 1 or infinity gives us exactly what is specified in the draft. A Depth of 0 refers to the collection itself, and assuming it exists, the DAV:multistatus response may or may not include a single DAV:response element, depending on whether the server maintains an entity tag on the collection which changes with its membership. In either case, the sync-token is returned per the extended grammar in 6.3. So, a sync-collection report with a depth of 0 might simply return the following: D:multistatus D:sync-tokenhttp://example.com/ns/sync/1234/D:sync-token /D:multistatus Does this make sense, or is my logic completely convoluted? -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-webdav-sync-06.txt (Collection Synchronization for WebDAV) to Proposed Standard
Julian Reschke wrote: On 2011-12-14 18:01, Ken Murchison wrote: Cyrus Daboo wrote: I am not convinced the use of Depth in sync report is violating the definition in 3253. In some ways it is a matter of how you look at the sync. Your viewpoint is that the report asks the collection for its changes - in that case, yes, Depth:0 would apply. The other view is that the report asks each of the child resources to list their change status, in which case Depth:1 and Depth:infinity also makes sense. Which viewpoint is taken probably depends on actual implementation rather than any perceived protocol restrictions. My $.02: I look the sync report as a filtered query for properties (e.g. CALDAV:calendar-query), with the filter being only give me a DAV:response if the resource has been changed/removed since the specified sync-token. A Depth of 1 or infinity gives us exactly what is specified in the draft. A Depth of 0 refers to the collection itself, and assuming it exists, the DAV:multistatus response may or may not include a single DAV:response element, depending on whether the server maintains an entity tag on the collection which changes with its membership. In either case, the sync-token is returned per the extended grammar in 6.3. So, a sync-collection report with a depth of 0 might simply return the following: D:multistatus D:sync-tokenhttp://example.com/ns/sync/1234/D:sync-token /D:multistatus Does this make sense, or is my logic completely convoluted? If this was designed from scratch, it wouldn't be using multistatus, but would include the properties of the collection (if changed). D:sync-result ... other collection props the report asked for ... D:sync-tokenhttp://example.com/ns/sync/1234/D:sync-token /D:sync-result I don't necessarily see a problem with sync report using multistatus, but perhaps the sync-token should be returned in a prop response element for the collection rather than as an added element of multistatus. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-webdav-sync-06.txt (Collection Synchronization for WebDAV) to Proposed Standard
On 14/12/2011 18:27, Cyrus Daboo wrote: A member URI MUST be reported as changed if its mapped resource's entity tag value (defined in Section 3.11 of [RFC2616]) has changed since the request sync-token was generated. It should be mentioned that this only works well with resources that are not content-negotiated. Unless the content negotiation was done as part of the original full sync request? How would that work? For instance, the common case for Conneg is using Accept:, but Accept: on REPORT specifies the expected media type for the REPORT response. Yes, that's a problem with WebDAV in general. OK, so we should probably punt on per-resource content-negotiation within the report itself (though I could see us wanting to support that in the future, in which case it would probably be done through extensions elements in the request body). So what do we need to do to address this? State that the etags returned in the report are always for the non-content-negotiated representation of each child resource? I think that is already implied by the definition of DAV:getetag, so perhaps we should state that we are referring to that value, which is the non-content negotiated entity tag. In the text above, we are only talking about a change of value, not about a specific value. Are there really a lot of cases where the non-content negotiated etag would not change while a content negotiated one would ? Unless that is a common scenario, I would not clobber the text with this additional statement. The opposite case (non content-negotiated changes while content negotiated does not) is even less problematic as it would just result in a false positive for clients using content negotiation. Arnaud ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-webdav-sync-06.txt (Collection Synchronization for WebDAV) to Proposed Standard
Hi Julian, --On December 14, 2011 12:10:27 AM +0100 Julian Reschke julian.resc...@gmx.de wrote: On 2011-12-02 00:41, The IESG wrote: ... Abstract This specification defines an extension to WebDAV that allows efficient synchronization of the contents of a WebDAV collection. - Expand acronyms on first use. Really, doesn't everyone know what WebDAV is by now :-) In any case fixed in my working copy. Typically, the first time a client connects to the server it will need to be informed of the entire state of the collection (i.e., a full list of all member URIs that are currently in the collection). That is done by the client sending an empty token value to the server. This indicates to the server that a full listing is required. I think it would be more consistent with other specs not to send an empty token, but to send *no* token. Existing implementations expect an empty sync-token element. I don't really see much difference either way on this, so would prefer to leave it as-is. As an alternative, the client might choose to do its first synchronization using some other mechanism on the collection (e.g. some other form of batch resource information retrieval such as PROPFIND, SEARCH [RFC5323] , or specialized REPORTs such as those defined in CalDAV [RFC4791] and CardDAV [I-D.ietf-vcarddav-carddav]) The CardDAV reference will need to be updated... Already fixed that one in my working copy. To implement the behavior for this report a server needs to keep track of changes to any member URIs and their mapped resources in a collection (as defined in Section 3 of [RFC4918]). This includes Actually, RFC 4918 defines member URL; maybe worth adjusting or pointing out it's the same. Will make that change in my working copy. BTW member URI does appear in 4918 in two places... Marshalling: The request URI MUST identify a collection. The request body MUST be a DAV:sync-collection XML element (see Section 6.1), which MUST contain one DAV:sync-token XML element, and one DAV:prop XML element, and MAY contain a DAV:limit XML element. The request MUST include a Depth header with a value of 1 or infinity. This report definition is in conflict with the definition of the REPORT method in RFC 3253 (http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.3.6). Essentially, a report is applied to just the request URI (depth: 0 or no depth header field), the request URI and it's internal members (1) or all descendants (infinity). A report definition should define the response for the case of Depth: 0. The format for the other cases follows directly from RFC 3253: If a Depth request header is included, the response MUST be a 207 Multi-Status. The request MUST be applied separately to the collection itself and to all members of the collection that satisfy the Depth value. The DAV:prop element of a DAV:response for a given resource MUST contain the requested report for that resource. (Note that I have complained about this a long time ago, http://lists.w3.org/Archives/Public/w3c-dist-auth/2007JulSep/0041.html). To fix this, the report would need to define Depth: 0 processing on a collection to mean the changes just on that collection (which means membership changes, but not changes to member resources), and the other modes would then follow based on RFC 3253. It doesn't seem to be possible to make this change in a way that doesn't break existing implementations, as RFC 3253 requires the report response format to be well-formed XML (thus only one root element), and that format then to be used *inside* DAV:multistatus/DAV:reponse/../DAV:prop. Optimally, this should be fixed. If this can't be fixed I'd argue that the spec should be published as Informational, and that it should include an explanation of the incompatibilty (essentially requiring servers to special-case this report in case they already use a generic WebDAV REPORT framework). I am not convinced the use of Depth in sync report is violating the definition in 3253. In some ways it is a matter of how you look at the sync. Your viewpoint is that the report asks the collection for its changes - in that case, yes, Depth:0 would apply. The other view is that the report asks each of the child resources to list their change status, in which case Depth:1 and Depth:infinity also makes sense. Which viewpoint is taken probably depends on actual implementation rather than any perceived protocol restrictions. Given that I feel the sync report is vital for WebDAV operations, for in particular CalDAV and CardDAV, I want to ensure this draft proceeds as a standard, not informational. If you feel strongly about this use of Depth, in spite of my comments above, then I would be willing to make some changes, provided we also include a statement on backwards compatibility (i.e., in an appendix state that clients/servers MAY
Re: Last Call: draft-daboo-webdav-sync-06.txt (Collection Synchronization for WebDAV) to Proposed Standard
On 2011-12-14 17:06, Cyrus Daboo wrote: Hi Julian, --On December 14, 2011 12:10:27 AM +0100 Julian Reschke julian.resc...@gmx.de wrote: On 2011-12-02 00:41, The IESG wrote: ... Abstract This specification defines an extension to WebDAV that allows efficient synchronization of the contents of a WebDAV collection. - Expand acronyms on first use. Really, doesn't everyone know what WebDAV is by now :-) In any case fixed in my working copy. Just being pro-active :-). The less happens ion AUTH48, the better. Typically, the first time a client connects to the server it will need to be informed of the entire state of the collection (i.e., a full list of all member URIs that are currently in the collection). That is done by the client sending an empty token value to the server. This indicates to the server that a full listing is required. I think it would be more consistent with other specs not to send an empty token, but to send *no* token. Existing implementations expect an empty sync-token element. I don't really see much difference either way on this, so would prefer to leave it as-is. Would be interesting to know how they treat missing sync tokens. ... Actually, RFC 4918 defines member URL; maybe worth adjusting or pointing out it's the same. Will make that change in my working copy. BTW member URI does appear in 4918 in two places... Errata, errata! Marshalling: The request URI MUST identify a collection. The request body MUST be a DAV:sync-collection XML element (see Section 6.1), which MUST contain one DAV:sync-token XML element, and one DAV:prop XML element, and MAY contain a DAV:limit XML element. The request MUST include a Depth header with a value of 1 or infinity. This report definition is in conflict with the definition of the REPORT method in RFC 3253 (http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.3.6). Essentially, a report is applied to just the request URI (depth: 0 or no depth header field), the request URI and it's internal members (1) or all descendants (infinity). A report definition should define the response for the case of Depth: 0. The format for the other cases follows directly from RFC 3253: If a Depth request header is included, the response MUST be a 207 Multi-Status. The request MUST be applied separately to the collection itself and to all members of the collection that satisfy the Depth value. The DAV:prop element of a DAV:response for a given resource MUST contain the requested report for that resource. (Note that I have complained about this a long time ago, http://lists.w3.org/Archives/Public/w3c-dist-auth/2007JulSep/0041.html). To fix this, the report would need to define Depth: 0 processing on a collection to mean the changes just on that collection (which means membership changes, but not changes to member resources), and the other modes would then follow based on RFC 3253. It doesn't seem to be possible to make this change in a way that doesn't break existing implementations, as RFC 3253 requires the report response format to be well-formed XML (thus only one root element), and that format then to be used *inside* DAV:multistatus/DAV:reponse/../DAV:prop. Optimally, this should be fixed. If this can't be fixed I'd argue that the spec should be published as Informational, and that it should include an explanation of the incompatibilty (essentially requiring servers to special-case this report in case they already use a generic WebDAV REPORT framework). I am not convinced the use of Depth in sync report is violating the definition in 3253. In some ways it is a matter of how you look at the It does. RFC 3253 defines the response format for Depth 0, and then states how the format for Depth 0 is derived from that; essentially by packaging into multistatus. This means that reports that do not support Depth 0 can not be defined. It also means that a report that uses multistatus for Depth 0, and which supports depths 0, will have to packages multistatus inside multistatus. sync. Your viewpoint is that the report asks the collection for its changes - in that case, yes, Depth:0 would apply. The other view is that the report asks each of the child resources to list their change status, in which case Depth:1 and Depth:infinity also makes sense. Which viewpoint is taken probably depends on actual implementation rather than any perceived protocol restrictions. What Depth 0 means is just a matter of definition. If you want to make Depth 0 mean request-URI and all of it's direct members, that's fine. It just will give funny results when you use it with other Depths *and* follow the RFC 3253 definition in these cases. Given that I feel the sync report is vital for WebDAV operations, for in particular CalDAV and CardDAV, I want to ensure this draft proceeds as a standard, not informational. If you feel strongly about this use of Depth, in spite of my comments above, then I would be willing to make some changes,
Re: Last Call: draft-daboo-webdav-sync-06.txt (Collection Synchronization for WebDAV) to Proposed Standard
On 2011-12-14 18:01, Ken Murchison wrote: Cyrus Daboo wrote: I am not convinced the use of Depth in sync report is violating the definition in 3253. In some ways it is a matter of how you look at the sync. Your viewpoint is that the report asks the collection for its changes - in that case, yes, Depth:0 would apply. The other view is that the report asks each of the child resources to list their change status, in which case Depth:1 and Depth:infinity also makes sense. Which viewpoint is taken probably depends on actual implementation rather than any perceived protocol restrictions. My $.02: I look the sync report as a filtered query for properties (e.g. CALDAV:calendar-query), with the filter being only give me a DAV:response if the resource has been changed/removed since the specified sync-token. A Depth of 1 or infinity gives us exactly what is specified in the draft. A Depth of 0 refers to the collection itself, and assuming it exists, the DAV:multistatus response may or may not include a single DAV:response element, depending on whether the server maintains an entity tag on the collection which changes with its membership. In either case, the sync-token is returned per the extended grammar in 6.3. So, a sync-collection report with a depth of 0 might simply return the following: D:multistatus D:sync-tokenhttp://example.com/ns/sync/1234/D:sync-token /D:multistatus Does this make sense, or is my logic completely convoluted? If this was designed from scratch, it wouldn't be using multistatus, but would include the properties of the collection (if changed). D:sync-result ... other collection props the report asked for ... D:sync-tokenhttp://example.com/ns/sync/1234/D:sync-token /D:sync-result ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-webdav-sync-06.txt (Collection Synchronization for WebDAV) to Proposed Standard
Hi Julian, --On December 14, 2011 5:29:16 PM +0100 Julian Reschke julian.resc...@gmx.de wrote: I am not convinced the use of Depth in sync report is violating the definition in 3253. In some ways it is a matter of how you look at the It does. RFC 3253 defines the response format for Depth 0, and then states how the format for Depth 0 is derived from that; essentially by packaging into multistatus. This means that reports that do not support Depth 0 can not be defined. It also means that a report that uses multistatus for Depth 0, and which supports depths 0, will have to packages multistatus inside multistatus. Well I don't consider the text there very clear at all. In fact I think it is very much tailored to the 3253 use cases and not flexible enough for other general purpose use of REPORT. It states this: The DAV:prop element of a DAV:response for a given resource MUST contain the requested report for that resource. Which implies packaging of multistatus within the DAV:prop element, which seems completely wrong to me. sync. Your viewpoint is that the report asks the collection for its changes - in that case, yes, Depth:0 would apply. The other view is that the report asks each of the child resources to list their change status, in which case Depth:1 and Depth:infinity also makes sense. Which viewpoint is taken probably depends on actual implementation rather than any perceived protocol restrictions. What Depth 0 means is just a matter of definition. If you want to make Depth 0 mean request-URI and all of it's direct members, that's fine. It just will give funny results when you use it with other Depths *and* follow the RFC 3253 definition in these cases. So would it hurt to allow this spec to override the 3253 nested multistatus requirement in the interests of generating a compact response specific to this type of report? Given that I feel the sync report is vital for WebDAV operations, for in particular CalDAV and CardDAV, I want to ensure this draft proceeds as a standard, not informational. If you feel strongly about this use of Depth, in spite of my comments above, then I would be willing to make some changes, provided we also include a statement on backwards compatibility (i.e., in an appendix state that clients/servers MAY use/accept the old Depth approach). If we do that we would need to proceed as follows: state that sync report can only be used with Depth:0, add a new request header to define the scope of the sync (e.g. Sync-Depth with values 1 and infinite). If we require Sync-Depth to be present, then we have a means for servers to detect old clients and handle Depth in a backwards compatible manner. Not happy having to add a new header field just for that. A simpler approach might be to just assign a different report name, and then allow all depths. I think if you insist on requiring Depth = nested multistatus, then we either add a new header or perhaps a depth element inside the request body (and that would also be reasonable in terms of being able to support backwards compatibility). At this point I would prefer the later as being least disruptive to existing implementations. In the case where a mapping between a member URI and the target collection was removed, then a new mapping with the same URI created, the member URI MUST be reported as changed and MUST NOT be reported as removed. The client could tell that this happened if the DAV:resourceid property was included. A member URI MUST be reported as changed if its mapped resource's entity tag value (defined in Section 3.11 of [RFC2616]) has changed since the request sync-token was generated. It should be mentioned that this only works well with resources that are not content-negotiated. Unless the content negotiation was done as part of the original full sync request? How would that work? For instance, the common case for Conneg is using Accept:, but Accept: on REPORT specifies the expected media type for the REPORT response. Yes, that's a problem with WebDAV in general. OK, so we should probably punt on per-resource content-negotiation within the report itself (though I could see us wanting to support that in the future, in which case it would probably be done through extensions elements in the request body). So what do we need to do to address this? State that the etags returned in the report are always for the non-content-negotiated representation of each child resource? I think that is already implied by the definition of DAV:getetag, so perhaps we should state that we are referring to that value, which is the non-content negotiated entity tag. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-webdav-sync-06.txt (Collection Synchronization for WebDAV) to Proposed Standard
Hi Ken, --On December 14, 2011 12:29:18 PM -0500 Ken Murchison mu...@andrew.cmu.edu wrote: D:sync-result ... other collection props the report asked for ... D:sync-tokenhttp://example.com/ns/sync/1234/D:sync-token /D:sync-result I don't necessarily see a problem with sync report using multistatus, but perhaps the sync-token should be returned in a prop response element for the collection rather than as an added element of multistatus. That won't work when the limiting/truncation option is used as the multistatus response for the collection indicates an overall status error, rather than using propstat. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-webdav-sync-06.txt (Collection Synchronization for WebDAV) to Proposed Standard
On 2011-12-14 18:27, Cyrus Daboo wrote: Hi Julian, --On December 14, 2011 5:29:16 PM +0100 Julian Reschke julian.resc...@gmx.de wrote: I am not convinced the use of Depth in sync report is violating the definition in 3253. In some ways it is a matter of how you look at the It does. RFC 3253 defines the response format for Depth 0, and then states how the format for Depth 0 is derived from that; essentially by packaging into multistatus. This means that reports that do not support Depth 0 can not be defined. It also means that a report that uses multistatus for Depth 0, and which supports depths 0, will have to packages multistatus inside multistatus. Well I don't consider the text there very clear at all. In fact I think it is very much tailored to the 3253 use cases and not flexible enough for other general purpose use of REPORT. It states this: The DAV:prop element of a DAV:response for a given resource MUST contain the requested report for that resource. It states what it states :-) Which implies packaging of multistatus within the DAV:prop element, which seems completely wrong to me. No, you only need to package multistatus inside prop in case the response to the Depth: 0 request uses multistatus. sync. Your viewpoint is that the report asks the collection for its changes - in that case, yes, Depth:0 would apply. The other view is that the report asks each of the child resources to list their change status, in which case Depth:1 and Depth:infinity also makes sense. Which viewpoint is taken probably depends on actual implementation rather than any perceived protocol restrictions. What Depth 0 means is just a matter of definition. If you want to make Depth 0 mean request-URI and all of it's direct members, that's fine. It just will give funny results when you use it with other Depths *and* follow the RFC 3253 definition in these cases. So would it hurt to allow this spec to override the 3253 nested multistatus requirement in the interests of generating a compact response specific to this type of report? I think so, because it defeats WebDAV stacks from executing reports consistently. (And, I assure you, I have written a framework in the past that did exactly that, otherwise I probably wouldn't have noticed the problem). Given that I feel the sync report is vital for WebDAV operations, for in particular CalDAV and CardDAV, I want to ensure this draft proceeds as a standard, not informational. If you feel strongly about this use of Depth, in spite of my comments above, then I would be willing to make some changes, provided we also include a statement on backwards compatibility (i.e., in an appendix state that clients/servers MAY use/accept the old Depth approach). If we do that we would need to proceed as follows: state that sync report can only be used with Depth:0, add a new request header to define the scope of the sync (e.g. Sync-Depth with values 1 and infinite). If we require Sync-Depth to be present, then we have a means for servers to detect old clients and handle Depth in a backwards compatible manner. Not happy having to add a new header field just for that. A simpler approach might be to just assign a different report name, and then allow all depths. I think if you insist on requiring Depth = nested multistatus, then we either add a new header or perhaps a depth element inside the request body (and that would also be reasonable in terms of being able to support backwards compatibility). At this point I would prefer the later as being least disruptive to existing implementations. Yes, a new child element of the request body (depth) works for me. In the case where a mapping between a member URI and the target collection was removed, then a new mapping with the same URI created, the member URI MUST be reported as changed and MUST NOT be reported as removed. The client could tell that this happened if the DAV:resourceid property was included. A member URI MUST be reported as changed if its mapped resource's entity tag value (defined in Section 3.11 of [RFC2616]) has changed since the request sync-token was generated. It should be mentioned that this only works well with resources that are not content-negotiated. Unless the content negotiation was done as part of the original full sync request? How would that work? For instance, the common case for Conneg is using Accept:, but Accept: on REPORT specifies the expected media type for the REPORT response. Yes, that's a problem with WebDAV in general. OK, so we should probably punt on per-resource content-negotiation within the report itself (though I could see us wanting to support that in the future, in which case it would probably be done through extensions elements in the request body). So what do we need to do to address this? State that the etags returned in the report are always for the non-content-negotiated representation of each child resource? I think that is already implied by the
Re: Last Call: draft-daboo-webdav-sync-06.txt (Collection Synchronization for WebDAV) to Proposed Standard
On 2011-12-14 18:34, Cyrus Daboo wrote: Hi Ken, --On December 14, 2011 12:29:18 PM -0500 Ken Murchison mu...@andrew.cmu.edu wrote: D:sync-result ... other collection props the report asked for ... D:sync-tokenhttp://example.com/ns/sync/1234/D:sync-token /D:sync-result I don't necessarily see a problem with sync report using multistatus, but perhaps the sync-token should be returned in a prop response element for the collection rather than as an added element of multistatus. That won't work when the limiting/truncation option is used as the multistatus response for the collection indicates an overall status error, rather than using propstat. OK, so it would need to be part of the sync-result (and the other props be included with a DAV:prop container). Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-daboo-webdav-sync-06.txt (Collection Synchronization for WebDAV) to Proposed Standard
On 2010-06-08 09:14, Julian Reschke wrote: On 07.06.2010 17:11, Werner Donné wrote: Hi, I don't see why Depth:infinity should be ruled out from the start. You can let the server decide if the performance penalty is too high or not. A server with a relational system underneath it, for example, can do this with one query. I don't agree with the bubble up principle. A collection changes when its member set changes. Changing a resource that is referred to by one of the members doesn't affect the collection, whether that resource is a collection or not. I think the bubble up principal is not consistent with the getlastmodified property. It is also not needed if Depth:infinity is supported. Best regards, Werner. Agreed. In particular: defining a report works by defining it for Depth: 0. The semantics for Depth: 1 and Depth: infinity follow by the definition in RFC 3253. It's probably *really* time to pull the definition of REPORT out of RFC 3253 and place it into a separate spec, including more rationale, recommendations for defining new reports, and examples. Best regards, Julian It seems to me that this issue was never addressed. As defined right now, the way REPORT is used doesn't seem to be compatible with the definition of REPORT in RFC 3253, and the definition of the Depth: header field in RFC 4918. Unless I'm missing something, this will be a problem for any implementation that tries to implement the sync report based on a generic WebDAV reporting framework. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-webdav-sync-06.txt (Collection Synchronization for WebDAV) to Proposed Standard
On 2011-12-02 00:41, The IESG wrote: ... Abstract This specification defines an extension to WebDAV that allows efficient synchronization of the contents of a WebDAV collection. - Expand acronyms on first use. Typically, the first time a client connects to the server it will need to be informed of the entire state of the collection (i.e., a full list of all member URIs that are currently in the collection). That is done by the client sending an empty token value to the server. This indicates to the server that a full listing is required. I think it would be more consistent with other specs not to send an empty token, but to send *no* token. As an alternative, the client might choose to do its first synchronization using some other mechanism on the collection (e.g. some other form of batch resource information retrieval such as PROPFIND, SEARCH [RFC5323] , or specialized REPORTs such as those defined in CalDAV [RFC4791] and CardDAV [I-D.ietf-vcarddav-carddav]) The CardDAV reference will need to be updated... To implement the behavior for this report a server needs to keep track of changes to any member URIs and their mapped resources in a collection (as defined in Section 3 of [RFC4918]). This includes Actually, RFC 4918 defines member URL; maybe worth adjusting or pointing out it's the same. Marshalling: The request URI MUST identify a collection. The request body MUST be a DAV:sync-collection XML element (see Section 6.1), which MUST contain one DAV:sync-token XML element, and one DAV:prop XML element, and MAY contain a DAV:limit XML element. The request MUST include a Depth header with a value of 1 or infinity. This report definition is in conflict with the definition of the REPORT method in RFC 3253 (http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.3.6). Essentially, a report is applied to just the request URI (depth: 0 or no depth header field), the request URI and it's internal members (1) or all descendants (infinity). A report definition should define the response for the case of Depth: 0. The format for the other cases follows directly from RFC 3253: If a Depth request header is included, the response MUST be a 207 Multi-Status. The request MUST be applied separately to the collection itself and to all members of the collection that satisfy the Depth value. The DAV:prop element of a DAV:response for a given resource MUST contain the requested report for that resource. (Note that I have complained about this a long time ago, http://lists.w3.org/Archives/Public/w3c-dist-auth/2007JulSep/0041.html). To fix this, the report would need to define Depth: 0 processing on a collection to mean the changes just on that collection (which means membership changes, but not changes to member resources), and the other modes would then follow based on RFC 3253. It doesn't seem to be possible to make this change in a way that doesn't break existing implementations, as RFC 3253 requires the report response format to be well-formed XML (thus only one root element), and that format then to be used *inside* DAV:multistatus/DAV:reponse/../DAV:prop. Optimally, this should be fixed. If this can't be fixed I'd argue that the spec should be published as Informational, and that it should include an explanation of the incompatibilty (essentially requiring servers to special-case this report in case they already use a generic WebDAV REPORT framework). The response body for a successful request MUST be a DAV: multistatus XML element, which MUST contain one DAV:sync-token Maybe s/one/a single/ ... Preconditions: (DAV:valid-sync-token): The DAV:sync-token element value MUST be a valid token previously returned by the server. A token can become invalid as the result of being out of date (out of the range of change history maintained by the server), or for other reasons (e.g. collection deleted, then recreated, access control changes, etc...). Does the sync-token need to originate from the same collection? 3.3. Depth behavior Servers MUST support both Depth:1 and Depth:infinity behavior with the DAV:sync-collection report. Clients MUST include either a Depth:1 or Depth:infinity request header with the DAV:sync-collection report. See above; this contradicts the base definition of REPORT. In the case where a mapping between a member URI and the target collection was removed, then a new mapping with the same URI created, the member URI MUST be reported as changed and MUST NOT be reported as removed. The client could tell that this happened if the DAV:resourceid property was included. A member URI MUST be reported as changed if its mapped resource's entity tag value (defined in Section 3.11 of [RFC2616]) has changed since the request sync-token was generated. It should be
Last Call: draft-daboo-webdav-sync-06.txt (Collection Synchronization for WebDAV) to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'Collection Synchronization for WebDAV' draft-daboo-webdav-sync-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-12-29. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification defines an extension to WebDAV that allows efficient synchronization of the contents of a WebDAV collection. Editorial Note (To be removed by RFC Editor before publication) Please send comments to the Distributed Authoring and Versioning (WebDAV) working group at mailto:w3c-dist-a...@w3.org, which may be joined by sending a message with subject subscribe to mailto:w3c-dist-auth-requ...@w3.org. Discussions of the WEBDAV working group are archived at http://lists.w3.org/Archives/Public/w3c-dist-auth/. The file can be obtained via http://datatracker.ietf.org/doc/draft-daboo-webdav-sync/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-daboo-webdav-sync/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
