WebDAV BIND LC issue: confusion about "alternate URI"

[Julian Reschke]

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

[Geoffrey M Clemm]

Removing the Note is fine with me.

Cheers,
Geoff

Julian Reschke <julian.reschke@...> 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
>
>
>
>
>