RE: URI scheme uniqueness

At 3:56 PM -0700 8/4/03, Lisa Dusseault wrote:
>  > -----Original Message-----
>>  From: hardie@qualcomm.com [mailto:hardie@qualcomm.com]
>>  Sent: Monday, August 04, 2003 2:23 PM
>>  To: Lisa Dusseault; 'Julian Reschke'; w3c-dist-auth@w3.org
>>  Subject: RE: URI scheme uniqueness
>>
>>
>>  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
>>  >uniqueness are completely independent qualities.
>>
>>  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.
<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.



>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...".

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.


>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.

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.

>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.

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

Received on Monday, 4 August 2003 19:40:44 UTC