Subject: BIND spec: Potential URI comparison issue

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Sep 2004 14:33:22 +0200

Hi,

a recent discussion on the Atom mailing list reminded me to check how 
the BIND spec currently defines "sameness" of resources [1]:

"If the values of DAV:resource-id returned by PROPFIND requests through 
two bindings are identical, the client can be assured that the two 
bindings are to the same resource."

The (potential) issue here is although the spec says "indentical", 
people may believe that assumptions about specific URI equivalence rules 
are allowed. For instance, or the following URIs identical?

"opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8"
"Opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8"
"opaquelocktoken:f81d4fae%2d7dec-11d0%2da765%2d00a0c91e6bf8"
"opaquelocktoken:f81d4fae%2D7dec-11d0%2da765%2D00a0c91e6bf8"

This is already non-trivial when only considering a single URI scheme, 
but it get's very hairy with multiple schemes.

Proposal: clarify that "identical" means "identical character-by-character".

Best regards, Julian

[1] 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#determining.whether.two.bindings.are.to.the.same.resource> 
	
-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 17 Sep 2004 09:55:27 -0400

I agree that "identical" in this case should 
mean "identical character-by-character".

Cheers,
Geoff

> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.
> html#determining.whether.two.bindings.are.to.the.same.resource> 
> 
> --

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Sep 2004 18:17:01 +0200

> mean "identical character-by-character".

Ok,

issue recorded and fix made in 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.2.6_identical>.

Best regards, Julian

---

From: Ted Hardie <[email-masked]>
Date: Mon, 20 Sep 2004 15:11:42 -0700

At 2:33 PM +0200 9/17/04, Julian Reschke wrote:
>Hi,
>
>a recent discussion on the Atom mailing list reminded me to check 
>how the BIND spec currently defines "sameness" of resources [1]:
>
>"If the values of DAV:resource-id returned by PROPFIND requests 
>through two bindings are identical, the client can be assured that 
>the two bindings are to the same resource."
>
>people may believe that assumptions about specific URI equivalence 
>rules are allowed. For instance, or the following URIs identical?
>
>This is already non-trivial when only considering a single URI 
>scheme, but it get's very hairy with multiple schemes.
>

opaquelocktoken is defined in 2518, at least if I am reading the URI scheme
registrations at IANA correctly.   Are you planning to update 2518?  If so,
do you plan to change the generation reference from the UUID reference
(ISO 11578) to something else?  As it stands now, I would expect
implementations to treat to tokens as equivalent if the UUID would
be equivalent.

Note as well that equivalence of the scheme name (Opaquelocktoken vs.
opaquelocktoken) is different to the equivalence of the token.  2396bis
defines the scheme as case-insensitive, even though the canonical
form is lower case.
		regards,
			Ted Hardie

---

From: Julian Reschke <[email-masked]>
Date: Tue, 21 Sep 2004 01:38:01 +0200

Ted Hardie wrote:
> ...

No.

> implementations to treat to tokens as equivalent if the UUID would

Well, the BIND spec allows *any* URI scheme. We can't expect recipients 
of DAV:resource-id properties to be aware of special comparison rules 
for specific URI schemes. So the simplest way to achieve 
interoperability is to specify one specific comparison that can be 
implemented by everybody without any knowledge of the various levels of 
URI equivalence (see RFC2396bis).

Note that this is the same problem as in XML Namespaces and in Atom, 
thus the same solution.

> defines the scheme as case-insensitive, even though the canonical

Yes. That's why we want to keep this simple (if the simplest solution 
works, why choose a different one?).

Julian

---

From: Ted Hardie <[email-masked]>
Date: Mon, 20 Sep 2004 17:14:25 -0700

At 1:38 AM +0200 9/21/04, Julian Reschke wrote:
>Well, the BIND spec allows *any* URI scheme. We can't expect 
>recipients of DAV:resource-id properties to be aware of special 
>comparison rules for specific URI schemes. So the simplest way to 
>achieve interoperability is to specify one specific comparison that 
>can be implemented by everybody without any knowledge of the various 
>levels of URI equivalence (see RFC2396bis).

>Note that this is the same problem as in XML Namespaces and in Atom, 

I'm not sure I see why this a feature.  Having a single, 
well-specified mechanism
that allows you to create identifiers that have a high probability of 
being unique
across space and time seems like goodness for this use.  Why would 
you want to allow
*any* URI scheme here?  mailto: [email-masked]? 
gopher://gopher.umd.edu/my_lock?

For both the xml namespace 1.0 and 1.1 recommendations, going down that
path has meant dealing with the difference between two references being
identical and "resolving to the same thing".  The spin-cycle on that argument
could wring out the garments of every parliament ever sat.

Again, what's the feature here?
			regards,
					Ted Hardie

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 20 Sep 2004 23:11:53 -0400

The reason to allow any URI scheme is to allow a reasonable implementation
on existing repositories that already have a UUID scheme built-in
to that repository (and are not amenable to extension with a different
UUID scheme just to satisfy the WebDAV BIND specification).

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Tue, 21 Sep 2004 09:24:36 +0200

Ted Hardie wrote:
> I'm not sure I see why this a feature.  Having a single, well-specified 
> mechanism
> across space and time seems like goodness for this use.  Why would you 
> want to allow

I personally don't think it's a problem. It has worked well for XMLNS 
(in practice!) and for WebDAV lock tokens.

In this specfic case, there's also the fact that many document 
management systems *already* assign unique identifiers, and allowing any 
kind of URI in many cases enables systems to just re-use the IDs they 
already have.

Requiring a single schema would also mean that this working group needs 
to define which. I really don't want to open *that* can of worms.

To summarize: this is an interesting discussion. In many previous cases, 
the result was to allow any URI and to use string comparision. Right 
now, Atom (lots of visibility) is using the same approach. I don't think 
it would be a good idea to start the same thread all over again here.

Julian