WebDAV BIND LC issue: confusion about "alternate URI"

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

Received on Monday, 25 May 2009 13:35:35 UTC