Subject: Re: URI scheme uniqueness

From: Elias Sinderson <[email-masked]>
Date: Mon, 04 Aug 2003 10:47:27 -0700

>
>
>>[...]
>><Elias Sinderson> Perhaps something along the lines of the following would be acceptable?
>>
>>"...are free to use any URI scheme so long as it meets the stated uniqueness
>>requirements. One way to accomplish this is to use IETF-registered URI schemes."
>>    
>>
><Julian Reschke> That's plain and simply wrong. The only way is to use an URI scheme that
>*both* is IETF-registered and meets the uniqueness criterium.
>
<Elias Sinderson> Goodness, you are correct, mea culpa - I see your 
point now.

>><Elias Sinderson> This language seems specific enough to be unambiguous while flexible enough to allow for other mechanisms to ensure uniqueness. The drawback of not [...]
>>    
>>
><Julian Reschke> See, this kind of proves that the spec needs to be enhanced. You and others seem to read it as a license to come up with "private" URI schemes, which is plainly wrong and breaks the uniqueness requirements. Therefore the text
>should be clarified.
>
<Elias Sinderson> Yes, I agree, the current text allows for a looser 
interpretation than is desired - consider me in favor of modifying the 
current wording.

Cheers,
Elias

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 4 Aug 2003 22:54:50 +0200

Summarizing...

I think I've collected enough evidence (people that indeed thought that they
can achieve global uniqueness without using an IETF-registered scheme) that
this should at least be added to the RFC2518 issues list :-)

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On
Behalf Of Elias Sinderson
  Sent: Monday, August 04, 2003 7:47 PM
  To: [email-masked]
  Subject: Re: URI scheme uniqueness

[...]
<Elias Sinderson> Perhaps something along the lines of the following would
be acceptable?

"...are free to use any URI scheme so long as it meets the stated uniqueness
requirements. One way to accomplish this is to use IETF-registered URI
schemes."
    <Julian Reschke> That's plain and simply wrong. The only way is to use
an URI scheme that
*both* is IETF-registered and meets the uniqueness criterium.<Elias
Sinderson> Goodness, you are correct, mea culpa - I see your point now.

<Elias Sinderson> This language seems specific enough to be unambiguous
while flexible enough to allow for other mechanisms to ensure uniqueness.
The drawback of not [...]
    <Julian Reschke> See, this kind of proves that the spec needs to be
enhanced. You and others seem to read it as a license to come up with
"private" URI schemes, which is plainly wrong and breaks the uniqueness
requirements. Therefore the text
should be clarified.<Elias Sinderson> Yes, I agree, the current text allows
for a looser interpretation than is desired - consider me in favor of
modifying the current wording.

  Cheers,
  Elias

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 4 Aug 2003 14:04:19 -0700

I don't object to this being an issue, and I'm happy to see suggestions for
new wording.  However, I think we're missing something here.  You've already
pointed out that using an IETF-registered schema doesn't guarantee
uniqueness which is true, but the wording below suggests that you can't have
uniqueness without having IETF registration. Rather, IETF registration and
uniqueness are completely independent qualities.
 
As a counter-example, consider if you invented the schema "greenbytes:", in
which you might find a URI like
"greenbytes:www.greenbytes.com:1234-5678-9012:3365008, where the first part
is the schema name, the second part is a domain name, the third part is a
network card ID, and the fourth part is a non-reusable sequence number.
This schema has the quality of allowing globally unique URIs to be selected
without being IETF registered.
 
Lisa

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julian Reschke
Sent: Monday, August 04, 2003 1:55 PM
To: [email-masked]
Subject: RE: URI scheme uniqueness 

Summarizing...

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de <http://www.greenbytes.de/>
-- tel:+492512807760 

-----Original Message-----

[...]

<Julian Reschke> That's plain and simply wrong. The only way is to use an
URI scheme that

<Elias Sinderson> Goodness, you are correct, mea culpa - I see your point
now.

should be clarified.

Cheers,
Elias

---

From: [email-masked]
Date: Mon, 4 Aug 2003 14:22:41 -0700

At 2:04 PM -0700 8/4/03, Lisa Dusseault wrote:
>I don't object to this being an issue, and I'm happy to see 
>suggestions for new wording.  However, I think we're missing 
>something here.  You've already pointed out that using an 
>IETF-registered schema doesn't guarantee uniqueness which is true, 
>but the wording below suggests that you can't have uniqueness 
>without having IETF registration. Rather, IETF registration and 

I agree that they are independent, but we shouldn't lose sight of the idea that
registration tells you whether a scheme will or will not give you 
uniqueness.  The
double issues for non-registered schemes is that you can get overlap (the same
human-friendly scheme names occur to lots of people) and those using
the scheme may have different ideas about the syntax as things evolve.
Both can really damage interoperability.  I encourage folks to 
register schemes,
and we are now working again on the procedures for non-IETF trees, which
would allow people to do a lightweight registration.

				regards,
					Ted Hardie

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 4 Aug 2003 23:37:45 +0200

MessageLisa,

this really isn't a counter-example. Just as *I* could define a "private"
URI scheme called "greenbytes", everybody else could. Unless you are *the*
naming authority for the URI schema (for which you'll need the IETF
registration), you simply can't *rely* on nobody else using the same scheme
name and scheme-dependant part.

Yes, it's unlikely. But writing protocols is about making things 100%
robust, not 99.99%.

Besides, I really don't see the point in *not* using IETF-registered URI
schemes. There are lots that are *guaranteed* to give you the required
uniqueness, one of which is the "opaquelocktoken" scheme RFC2518 defines
*for this very purpose*.

Can you give a single reason why it would be preferrable for a server
implementor *not* to use one of the available schemes?

Julian

(P.S.: I already suggested a new wording)

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On
Behalf Of Lisa Dusseault
  Sent: Monday, August 04, 2003 11:04 PM
  To: 'Julian Reschke'; [email-masked]
  Subject: RE: URI scheme uniqueness

  I don't object to this being an issue, and I'm happy to see suggestions
for new wording.  However, I think we're missing something here.  You've
already pointed out that using an IETF-registered schema doesn't guarantee
uniqueness which is true, but the wording below suggests that you can't have
uniqueness without having IETF registration. Rather, IETF registration and
uniqueness are completely independent qualities.

  As a counter-example, consider if you invented the schema "greenbytes:",
in which you might find a URI like
"greenbytes:www.greenbytes.com:1234-5678-9012:3365008, where the first part
is the schema name, the second part is a domain name, the third part is a
network card ID, and the fourth part is a non-reusable sequence number.
This schema has the quality of allowing globally unique URIs to be selected
without being IETF registered.

  Lisa
    -----Original Message-----
    From: [email-masked] [mailto:[email-masked]]
On Behalf Of Julian Reschke
    Sent: Monday, August 04, 2003 1:55 PM
    To: [email-masked]
    Subject: RE: URI scheme uniqueness

    Summarizing...

    I think I've collected enough evidence (people that indeed thought that
they can achieve global uniqueness without using an IETF-registered scheme)
that this should at least be added to the RFC2518 issues list :-)

    Julian

      -----Original Message-----
      From: [email-masked]
[mailto:[email-masked]]On Behalf Of Elias Sinderson
      Sent: Monday, August 04, 2003 7:47 PM
      To: [email-masked]
      Subject: Re: URI scheme uniqueness

[...]

      Cheers,
      Elias

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 4 Aug 2003 15:56:55 -0700

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, August 04, 2003 2:23 PM
> To: Lisa Dusseault; 'Julian Reschke'; [email-masked]
> I agree that they are independent, but we shouldn't lose 
> sight of the idea that registration tells you whether a 
> scheme will or will not give you 
> uniqueness.  The
> double issues for non-registered schemes is that you can get 
> overlap (the same human-friendly scheme names occur to lots 
> of people) and those using the scheme may have different 
> ideas about the syntax as things evolve. Both can really 
> damage interoperability.  I encourage folks to 
> register schemes,
> and we are now working again on the procedures for non-IETF 
> trees, which would allow people to do a lightweight registration.

In this case interoperability shouldn't be affected. I haven't seen a case
where problems have been caused in real life, and I haven't heard a scenario
for problems caused (although a poorly chosen schema could compound poor
implementation practice).  

The section under discussion describes how lock tokens are generated.
Servers generate lock tokens as URIs for formatting reasons -- so that we
know what characters can appear and how they can be marshalled in XML.  We
could just as easily have required lock tokens to be opaque strings
containing only alphanumeric characters, because clients get no semantics
out of these tokens.  But, because these are URIs there must be a URI
scheme.  That scheme may or may not be IETF-registered.  It may be the http:
scheme, the DAV: scheme, the opaquelocktoken: scheme, or something else
entirely. 

It doesn't really matter for interoperability whether the lock token is
really unique, or whether it uses an IETF-registered scheme.  Since the lock
token is never parsed by foreign software (software other than the software
which generated the token) it is not an interoperability issue, period.
(the only interoperability issue is what characters can appear, which seems
uncontroversial since we've defined it as a URI).

The uniqueness issue does matter to the server implementor to make their
implementation work.  But in practice it doesn't have to be universally
unique in order to work, it just has to be unique to that server.  So if my
server issues a locktoken 'DAV:1234', it doesn't matter to either successful
interoperability or to the successful functioning of my server if another
server issues the same lock token. My server should probably not reuse the
locktoken "DAV:1234" for another lock in the future although after
sufficient time passes it would be a harmless mistake.  That said, it does
little harm for the WebDAV spec to be more strict in its requirements, which
it is -- it says "Lock token URIs MUST be unique across all resources for
all time. ...across resources and servers...".  

The syntax issue (which you mention as a reason to register schemas) is
completely irrelevant as lock tokens are unparsable by any other agent -
they are opaque strings in the format of URIs.  The issuing server may even
treat them as unparsable lookup strings.

The issue under discussion is whether we should additionally require the
scheme in the lock token to be registered.  Currently the spec says
"resources are free to return any URI scheme so long as it meets the
uniqueness requirements".  An additional requirement for registration
doesn't help interoperability problems in this particular case as I could
register a schema that did not meet the uniqueness requirements (or I could
use an existing schema like http: in a way that does not meet the uniqueness
requirements).  If it is an IETF policy to require registration regardless
of the interoperability considerations then it's trivial to add that
requirement.

Lisa

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 4 Aug 2003 16:08:03 -0700

According to your logic, if I register the scheme "foo:", and I don't
register the scheme "bar:", and if both schemes are defined to use a
registered domain name and a unique network card ID plus a unique sequence
number, then 
 -->  foo:www.greenbytes.com:1234-5678-9012:3365008 is guaranteed to be
unique
 -->  bar:www.greenbytes.com:1234-5678-9012:3365008 is NOT guaranteed to be
unique

You think that because "foo:" is registered everybody will use it properly,
whereas because "bar:" is unregistered somebody else is likely to use it
improperly?  In the real world, registering a schema makes it *more* likely
that other people will use it.  Increasing the usage of the scheme will also
increase the likelihood that even if that scheme is designed to allow
uniqueness it will be misused and create a non-unique URI.  So in some sense
encouraging registration does more to make things less-than-100% robust.
Bugs and poor implementation choices are the likely causes of non-uniqueness
here, not the registration of the scheme. 

I did not say it would be preferable for a server implementor to use an
unregistered scheme.  I am merely arguing that some of the arguments used in
this discussion are bogus arguments.  Generally I don't like things to be
changed for poor reasons.  Even if I'm not opposed to the change we ought to
understand the reasons.

Lisa

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Monday, August 04, 2003 2:38 PM
To: Lisa Dusseault; [email-masked]
Subject: RE: URI scheme uniqueness 

Lisa,

Julian

-----Original Message-----

Lisa
-----Original Message-----

Summarizing...

Julian

-----Original Message-----

[...]

    

Cheers,
Elias

---

From: [email-masked]
Date: Mon, 4 Aug 2003 16:40:32 -0700

>  > trees, which would allow people to do a lightweight registration.
<snip of Lisa's response>

Obviously my transition here wasn't very good.

<point one>

As you say above, the two are independent; you can have IETF schemes which are
not unique and non-IETF schemes which are.

<transition>

If you are an implementor considering using a non-IETF registered URI 
scheme _for_any_purpose_,
don't lose sight of what using a registered URI scheme gives you. 
Non-registered
schemes risk overlap and risk misunderstandings of syntax developing over
time.  We're trying to reduce the overhead of registration by 
re-introducing the
idea of non-IETF trees and making the registration procedures for 
them lightweight.

<back story>

A presumption (possibly unwarranted) on my part was that anyone choosing an
unregistered URI scheme for lock tokens is doing so to reuse scheme they
are already using for some other purpose.  Hence the motivation to make
the general plug above to register schemes whenever they can.

>all time. ...across resources and servers...".

I suspect that this presumes something about the way clients should behave;
to wit, if they get a lock token DAV:1234 issued by server dav.example.com,
they will not get whacked out when they get a lock token DAV:1234 issued
by server dav.example.net (obviously, for some other resource).  I believe
that this would be good engineering, obviously, but I think maintaining
a stricter requirement is useful.

>treat them as unparsable lookup strings.

Again, I was making a more general point about the usefulness of registering
schemes.  That said, having external review of the minting algorithms
can be useful, as achieving uniqueness can be harder than many folks
believe.

>of the interoperability considerations then it's trivial to add that

I guess I'm looking at this from a different perspective.  If you have a URI
scheme that you find useful (if my backstory guess is correct, for something
more than opaque lock tokens), then registering seems like a good move,
so why not do that? (assuming, of course, we can get the registration process
finalized and lightweight).

Reading the quoted text "resources are free to return any URI scheme so long
as it meets the uniqueness requirements", I would have presumed "registered
URI scheme" was implied.  You could, however, rewrite it to "resources are
free to return any opaque lock token so long as it meets the uniqueness
requirements and conforms to URI syntax" (or something similar) and get
much the same effect without that same presumption.
				regards
					Ted Hardie

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 5 Aug 2003 09:09:37 +0200

> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Tuesday, August 05, 2003 12:57 AM
> To: [email-masked]; 'Julian Reschke'; [email-masked]
> ...

I absolutely disagree with this statement. URIs were chosen as this was
simply the best way to come up with a robust identifier syntax.

> containing only alphanumeric characters, because clients get no semantics

...in which case you would have reached the uniqueness criteria exactly
how...?

> which generated the token) it is not an interoperability issue, period.

Not true. The spec says that the lock token is a URI. A user agent is
absolutely allowed to run a lock token through a URI parser. In particular,
this URI parser may actually do scheme-dependant parsing. For instance, it
would be perfectly legal for a client to reject a lock token on the basis
that it doesn't comply to the syntactical rules for the scheme used, for
instance:

"opaquelocktoken:foobar" or "http:foobar"

> uncontroversial since we've defined it as a URI).

Well, uniqueness as well. As RFC2518 guarantess uniqueess...:

"Lock token URIs MUST be unique across all resources for all time. This
uniqueness constraint allows lock tokens to be submitted across resources
and servers without fear of confusion."

a client may store all lock tokens in a map, independantly of where they
came from. In particular, the spec allows it to *keep* these tokens and to
raise an error if a token is issued a second time (this may not be very
useful, but the issue is that the spec *allows* that behaviour).

> implementation work.  But in practice it doesn't have to be universally

...and to the client.

> server issues a locktoken 'DAV:1234', it doesn't matter to either
successful

No, no, no. The spec says that clients can rely on lock tokens to be unique.
If a client talks to two different servers and they both use the lock token
"DAV:1234", this can clearly be a problem. *Please* do not make assumptions
about what clients do or don't. From what you're saying right now it seems
that you're trying to reverse history by removing a required feature from
the protocol, and I really really would like to understand *why* you're
doing that.

> sufficient time passes it would be a harmless mistake.  That said, it does

Are you saying that breaking a MUST-level requirement of the protocol is
harmless?

> treat them as unparsable lookup strings.

Yes. But the spec clearly says that both servers and clients can rely on
them being URIs, therefore are allowed to run them through a URI parser and
reject them if they aren't valid URIs (for instance, rejecting string that
contain non-ASCII characters).

> uniqueness requirements".  An additional requirement for registration

...my point being that you can't have *guaranteed* uniqueness unless you
register the scheme.

> register a schema that did not meet the uniqueness requirements (or I
could

It does help interop issues if they are a result of

- people using the same non-registered URI scheme with conflicting tokens,
and/or
- clients rejecting lock tokens because they don't parse as valid URI.

> of the interoperability considerations then it's trivial to add that

Yes. Please. The discussion has shown that it doesn't seem to be obvious,
because making up ad-hoc URI schemes seems to be almost the norm, not the
exception.

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 5 Aug 2003 09:19:47 +0200

> Sent: Tuesday, August 05, 2003 1:08 AM

Yes.

> improperly?  In the real world, registering a schema makes it *more*
likely

Nope. Please define what you call "improper" use of a URI schema that is not
registered. The scheme name "bar" doesn't "belong* to anybody. Thus all uses
of it in public protocols is "improper".

Because it is not registered, you simply don't have any control over it. The
next day, an IETF RFC may define the "bar:" scheme for something else and
define a grammar for legal "bar:" URIs that's incompatible to your ad-hoc
usage. Clients would have every right to reject the URI because they may
have a URI parser that knows about the new scheme and rejects it.

> here, not the registration of the scheme.

Both.

Anyway, you seem to suggest a mechanism that I'll call
"uniqueness-by-obscurity".

> this discussion are bogus arguments.  Generally I don't like things to be

Such as...?

> changed for poor reasons.  Even if I'm not opposed to the change  we ought
to

Again: I understand this as clarification. You simply can't have guaranteed
uniqueness in a URI unless the URI scheme is registered. This is *by
definition* how URIs work.

Julian

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 5 Aug 2003 09:24:35 +0200

> [mailto:[email-masked]]On Behalf Of [email-masked]
> Sent: Tuesday, August 05, 2003 1:41 AM

Thanks, Ted. This is where I came from: most people to which I talked about
this assumed that as well. However, during testing I found servers that
simply use ad-hoc schemes. I think this is a very bad practice, and thus
RFC2518bis should be *clarified*.> free to return any opaque lock token so
long as it meets the uniqueness

> much the same effect without that same presumption.

So *how* do you produce a guaranteed-to-be-unique URI without using a
registered scheme? I think this is simply impossible.

Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 5 Aug 2003 11:17:33 -0400

Julian is correct here.  I support adding the clarification to 2518bis
that he suggests, i.e. the lock token schema MUST be an IETF-registered 
schema.

Cheers,
Geoff

[email-masked] wrote on 08/05/2003 03:09:37 AM:

> > scheme.  That scheme may or may not be IETF-registered.  It may  be 
the
> http:
> > really unique, or whether it uses an IETF-registered scheme.  Since 
the
> lock

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 11 Aug 2003 13:06:10 -0700

> As you say above, the two are independent; you can have IETF 
> schemes which are not unique and non-IETF schemes which are.
Great, I think we all agree on that...

> schemes risk overlap and risk misunderstandings of syntax 
> developing over time.  

I agree with this so the next version of RFC2518bis will recommend
using a registered scheme unless I start hearing more disagreement.

> A presumption (possibly unwarranted) on my part was that 
> anyone choosing an unregistered URI scheme for lock tokens is 
> doing so to reuse scheme they are already using for some 
> other purpose.  Hence the motivation to make the general plug 
> above to register schemes whenever they can.

I hadn't made that presumption but it's a fair consideration.  

> I suspect that this presumes something about the way clients 
> should behave; to wit, if they get a lock token DAV:1234 
> issued by server dav.example.com, they will not get whacked 
> out when they get a lock token DAV:1234 issued by server 
> dav.example.net (obviously, for some other resource).  I 
> believe that this would be good engineering, obviously, but I 
> think maintaining a stricter requirement is useful.

I think that although we have the uniqueness requirement already
(it can't be made stricter very easily) clients simply can't assume
that lock tokens really are globally unique.  

Should we add some client advice to RFC2518bis, saying that in 
practice clients cannot assume that lock tokens will be unique
across servers and should not be used as unique lookups in client
code? It provides little advantage to the client to assume 
uniqueness, and it could be an easy source of bugs.  This falls 
under the IETF principle of being generous in what you accept 
(non-unique tokens) but strict in what you generate (unique only).

 Lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 11 Aug 2003 22:14:07 +0200

> From: Lisa Dusseault [mailto:[email-masked]]
> Sent: Monday, August 11, 2003 10:06 PM

Sounds good so far.

> that lock tokens really are globally unique.

Wait a minute. The spec says that they MUST be globally unique. It even
defines a URI scheme that is supposed to guarantee that uniqueness. And now
you want to tell clients that they can't rely on that???

> (non-unique tokens) but strict in what you generate (unique only).

Absolutely no. Either clients can rely on uniquess, or they can't. RFC2518
guarantees this, and I don't see an interoperability problem caused by this.
Removing the guarantee potentially breaks existing clients with no visible
benefit.

Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 11 Aug 2003 16:50:09 -0400

I agree with Julian.  I have seen no reason to weaken the current 
requirement that lock tokens be globablly unique.

Cheers,
Geoff

---

From: [email-masked]
Date: Mon, 11 Aug 2003 16:01:21 -0700

>Lisa Dusseault writes:

It's always tricky to write that sort of text without weakening the
core requirement, but it is possible.  Usually it falls under the "fail
gracefully" rubric--in other words, saying that clients which receive
the same lock token a second time should neither accept it nor
crash, but do something else which allows them to fail gracefully.
Given the potential uses here, though, I'm not sure what the "graceful
failure" mode is.  What would you suggest the right behavior is in
that case?
			regards,
				Ted