Re: WebDAV BIND LC issue: confusion about "alternate URI"

Removing the Note is fine with me.

Cheers,
Geoff

Julian Reschke <julian.reschke@gmx.de> wrote on 05/25/2009 09:34:43 AM:

> [image removed] 
> 
> WebDAV BIND LC issue: confusion about "alternate URI"
> 
> Julian Reschke 
> 
> to:
> 
> WebDAV
> 
> 05/25/2009 09:34 AM
> 
> Cc:
> 
> Alexey Melnikov, Jason Crawford, Geoffrey M Clemm, Jim Whitehead
> 
> Hi,
> 
> this is another issue raised by the Apps Area Director (Alexey 
Melnikov).
> 
> In Section 3.1 
> (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-
> bind-23.html#rfc.section.3.1>) 
> we currently say:
> 
> "3.1. DAV:resource-id Property
> 
> The DAV:resource-id property is a REQUIRED property that enables clients 

> to determine whether two bindings are to the same resource. The value of 

> DAV:resource-id is a URI, and may use any registered URI scheme that 
> guarantees the uniqueness of the value across all resources for all time 

> (e.g. the urn:uuid: URN namespace defined in [RFC4122] or the 
> opaquelocktoken: URI scheme defined in [RFC4918]).
> 
> <!ELEMENT resource-id (href)>
> 
> Note: by definition, the URI specified in the DAV:resource-id property 
> always is an alternate URI for that resource."
> 
> The last sentence was added in autumn 2007, after Yaron Goland asked for 

> a way to use REBIND and BIND without the risk of race conditions. My 
> suggestion was that as the resource-ID *is* a URI for the resource, a 
> server could accept it in the BIND/REBIND request, even if it wasn't an 
> HTTP URL. See discussion in 
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2007OctDec/0029.html
>.
> 
> So, given a DAV:resource-id of 
> <urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8> (inside DAV:href...), it 

> would be legal to use BIND like this:
> 
>    BIND /CollY HTTP/1.1
>    Host: www.example.com
>    Content-Type: application/xml; charset="utf-8"
>    Content-Length: xxx
> 
>    <?xml version="1.0" encoding="utf-8" ?>
>    <D:bind xmlns:D="DAV:">
>       <D:segment>bar.html</D:segment>
>       <D:href>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8</D:href>
>    </D:bind>
> 
> But, back then, we didn't want to *require* a server to support this, as 

> it implies the ability to look up a resource by DAV:resource-id, which 
> the spec currently does not require in the first place.
> 
> Summarizing: I still think this is a neat idea, and it would be 
> interesting to implement this experimentally. But then, the statement 
> apparently causes confusion, instead of clarification.
> 
> Thus, my recommendation is to remove it.
> 
> Feedback appreciated,
> 
> Julian
> 
> 
> 
> 
>