WebDAV sync informal last call

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

Re: WebDAV sync informal last call

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:

Re: WebDAV sync informal last call

Re: WebDAV sync informal last call

Hi Werner,

--On April 15, 2011 10:32:57 PM +0200 Werner Donné 
<werner.donne <at> pincette.biz> 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

Re: WebDAV sync informal last call

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é <werner.donne <at> pincette.biz> 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.

Re: WebDAV sync informal last call

Hi Werner,

--On April 19, 2011 10:14:13 AM +0200 Werner Donné 
<werner.donne <at> pincette.biz> 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

Re: WebDAV sync informal last call

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.

PROPFIND vs. Accept: vs. variants

I've encountered some behavior that surprised me from Apache's mod_dav and I'm trying to figure out what
the correct behavior is. Specifically, what is the interpretation of the Accept: header sent with a
PROPFIND (or other DAV request other than GET)?

I have a server with mod_dav and MultiViews enabled, and files foo.txt and foo.png. As a result of this,
Apache presents a resource at 'foo', whose content and content-type vary depending on the Accept: header
sent in the GET request. This is as expected and as desired.

If I do a PROPFIND on that resource, I get information about either the txt or the png variant, depending on
the Accept header sent in the PROPFIND request. If I supply 'Accept: application/xml', then the PROPFIND
fails entirely with HTTP status 406. So clearly Apache is using the Accept: header to select the variant on
which to run the PROPFIND. This is unexpected (to me), but makes a certain amount of sense. (The <href> in
the PROPFIND result always returns the url with the appropriate extension --- the canonical URL for the
file that supplied that variant.)

I had thought, however, that PROPFIND requests should include 'Accept: application/xml', because that
is the content-type of the result body I want from the PROPFIND. RFC2616 describes Accept (and
Accept-Charset etc) as being "used to specify certain media types which are acceptable for the
response". 

So, my question is: what is the meaning of Accept: in a PROPFIND request? RFC2616 implies that a PROPFIND's
Accept: header, if present, should be application/xml, and in Apache's case, this works for non-varying
resources, even ones that aren't XML.  On the other hand, Apache is using it to select the variant to which to
apply the operation, regardless of the media type which will appear in the response. Apache's behavior
seems more *useful*, since it allows me to discover canonical URLs for a varying resource.

A related question, in the context of rfc4918 section 5, is how variant resources are modeled in terms of
segment-to-resource mapping. My initial understanding was that the 'foo' path segment mapped to a
single resource, whose content and properties varied based on content negotiation. The fact that the
resource didn't correspond to a particular disk file was an implementation detail and unimportant.

The other interpretation is that the 'foo' segment maps to different resources depending on content
negotiation. This seems to be the approach that Apache is taking, since in each case the PROPFIND response
indicates the more-canonical URL for the resource whose properties are returned. rfc4918 states "it is
illegal to have the same path segment mapped to more than one resource", but it is only mapped to one
resource during any given request, so perhaps that is OK.

Re: PROPFIND vs. Accept: vs. variants

Hi Wim,

My understanding is that Accept is the same for a GET or a PROPFIND. It is just an indication of the client
about the acceptable forms for the representation of a resource. The format for the response body of a
PROPFIND is application/xml. It the client requests this in another format then either the server
responds with a 406 or it transforms the data to the desired format if it supports it. I think this is allowed
because RFC4918 says:

"All servers MUST support returning a response of content type text/xml or application/xml that contains
a multistatus XML element that describes the results of the attempts to retrieve the various properties."

This doesn't preclude other representations of the data. A server could, for example, support also a JSON
representation or an OPDS representation, etc.

Using Accept for the selection of a variant is possible for a GET, but then I think foo.txt and foo.png are the
representations of two entities of the resource foo. As a consequence, the properties are always the
same, which means Accept can't be used to select a variant for a PROPFIND. Properties are related to
resources and are not affected by the Accept header.

Regarding the related question, I think that if "foo" corresponds to different resources depending on
content negotiation, then this always implies a redirect to one of those resources.

Best regards,

Werner.

On 20 Apr 2011, at 23:07, Wim Lewis wrote:

> I've encountered some behavior that surprised me from Apache's mod_dav and I'm trying to figure out what
the correct behavior is. Specifically, what is the interpretation of the Accept: header sent with a
PROPFIND (or other DAV request other than GET)?
> 
> I have a server with mod_dav and MultiViews enabled, and files foo.txt and foo.png. As a result of this,
Apache presents a resource at 'foo', whose content and content-type vary depending on the Accept: header
sent in the GET request. This is as expected and as desired.
> 
> If I do a PROPFIND on that resource, I get information about either the txt or the png variant, depending on
the Accept header sent in the PROPFIND request. If I supply 'Accept: application/xml', then the PROPFIND
fails entirely with HTTP status 406. So clearly Apache is using the Accept: header to select the variant on
which to run the PROPFIND. This is unexpected (to me), but makes a certain amount of sense. (The <href> in
the PROPFIND result always returns the url with the appropriate extension --- the canonical URL for the
file that supplied that variant.)
> 
> I had thought, however, that PROPFIND requests should include 'Accept: application/xml', because that
is the content-type of the result body I want from the PROPFIND. RFC2616 describes Accept (and
Accept-Charset etc) as being "used to specify certain media types which are acceptable for the
response". 
> 
> So, my question is: what is the meaning of Accept: in a PROPFIND request? RFC2616 implies that a PROPFIND's
Accept: header, if present, should be application/xml, and in Apache's case, this works for non-varying
resources, even ones that aren't XML.  On the other hand, Apache is using it to select the variant to which to
apply the operation, regardless of the media type which will appear in the response. Apache's behavior
seems more *useful*, since it allows me to discover canonical URLs for a varying resource.
> 
> 
> 
> A related question, in the context of rfc4918 section 5, is how variant resources are modeled in terms of
segment-to-resource mapping. My initial understanding was that the 'foo' path segment mapped to a
single resource, whose content and properties varied based on content negotiation. The fact that the
resource didn't correspond to a particular disk file was an implementation detail and unimportant.
> 
> The other interpretation is that the 'foo' segment maps to different resources depending on content
negotiation. This seems to be the approach that Apache is taking, since in each case the PROPFIND response
indicates the more-canonical URL for the resource whose properties are returned. rfc4918 states "it is
illegal to have the same path segment mapped to more than one resource", but it is only mapped to one
resource during any given request, so perhaps that is OK.
> 
> 
> 
> 
> 

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

Re: PROPFIND vs. Accept: vs. variants

On 20.04.2011 23:07, Wim Lewis wrote:
> I've encountered some behavior that surprised me from Apache's mod_dav and I'm trying to figure out what
the correct behavior is. Specifically, what is the interpretation of the Accept: header sent with a
PROPFIND (or other DAV request other than GET)?
>
> I have a server with mod_dav and MultiViews enabled, and files foo.txt and foo.png. As a result of this,
Apache presents a resource at 'foo', whose content and content-type vary depending on the Accept: header
sent in the GET request. This is as expected and as desired.
>
> If I do a PROPFIND on that resource, I get information about either the txt or the png variant, depending on
the Accept header sent in the PROPFIND request. If I supply 'Accept: application/xml', then the PROPFIND
fails entirely with HTTP status 406. So clearly Apache is using the Accept: header to select the variant on
which to run the PROPFIND. This is unexpected (to me), but makes a certain amount of sense. (The<href>  in
the PROPFIND result always returns the url with the appropriate extension --- the canonical URL for the
file that supplied that variant.)
>
> I had thought, however, that PROPFIND requests should include 'Accept: application/xml', because that
is the content-type of the result body I want from the PROPFIND. RFC2616 describes Accept (and
Accept-Charset etc) as being "used to specify certain media types which are acceptable for the response".

I agree this is what *should* happen.

Probably what you see is an interaction between modules that nobody has 
considered before.

> So, my question is: what is the meaning of Accept: in a PROPFIND request? RFC2616 implies that a PROPFIND's
Accept: header, if present, should be application/xml, and in Apache's case, this works for non-varying
resources, even ones that aren't XML.  On the other hand, Apache is using it to select the variant to which to
apply the operation, regardless of the media type which will appear in the response. Apache's behavior
seems more *useful*, since it allows me to discover canonical URLs for a varying resource.

Accept means the same thing for all methods; it's the preference for the 
media type of the returned content. This is an aspect of HTTP, not WebDAV.

> A related question, in the context of rfc4918 section 5, is how variant resources are modeled in terms of
segment-to-resource mapping. My initial understanding was that the 'foo' path segment mapped to a
single resource, whose content and properties varied based on content negotiation. The fact that the
resource didn't correspond to a particular disk file was an implementation detail and unimportant.
>
> The other interpretation is that the 'foo' segment maps to different resources depending on content
negotiation. This seems to be the approach that Apache is taking, since in each case the PROPFIND response
indicates the more-canonical URL for the resource whose properties are returned. rfc4918 states "it is
illegal to have the same path segment mapped to more than one resource", but it is only mapped to one
resource during any given request, so perhaps that is OK.

The WebDAV WG never got around to look into the interaction of content 
negotiation and authoring; I think the safest thing to do is not to try 

Best regards, Julian