RE: URI scheme uniqueness (was Re: rfc2518-bis-04 issues (part 2))

> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
> Behalf Of Elias Sinderson
> Sent: Thursday, July 31, 2003 6:53 AM
> To: w3c-dist-auth@w3.org
> Subject: URI scheme uniqueness (was Re: rfc2518-bis-04 issues (part 2))
>
>
> Julian Reschke wrote:
>
>
> <Julian Reschke> 02-C05 Section 6.3, p3
> Replace
> "However resources are free to return any URI scheme so long as it meets
the
> uniqueness requirements."
> by
> "However servers are free to use any IETF-registered URI scheme so long as
> it meets the uniqueness requirements."
> (If it's not IETF-registered, I don't see how it can possibly meet the
> uniqueness criterium).
>
> <Jason Crawford> I'd vote to leave the text as it is.
>
> <Julian Reschke> Again, please help me understand...:
>
> 1) Are you suggesting that to for a scheme to be IETF-registered is not a
> requirement? In which case I'll argue that by definition there
> can't be any
> uniquess guarantee otherwise.
> <Elias Sinderson> It's a given that any IETF-registered URI  scheme will
meet
> the stated uniqueness requirements. I don't believe that it is  the only
way

That's not a given. For instance, "file:///abc" or "dav:foobar" make very
poor lock tokens, although the URI schemes are IETF-registered.

> to do so, however. For example, private intranets may utilize their own,
> homegrown system to guarantee uniquenes. It's also entirely possible that,

Not true, unless your private intranet indeed isn't (and never will be)
connect to the public internet (in which case I really don't care :-). A
client may talk with two distinct "homegrown" systems at the same time.
RFC2518 requires that it will never ever see the same lock token twice. If
these systems do not use an IETF-registered URI scheme, there's simply no
way to guarantee this.

> in the distant future, there may be alternative means to
> accomplish this on
> the public internet. 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."

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.

> This language seems specific enough to be unambiguous while
> flexible enough
> to allow for other mechanisms to ensure uniqueness. The drawback of not

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.

> taking a firmer position on this is that it opens the possibility that
> someone will implement some half-baked idea and it won't meet the
> necessary
> requirements...

Absolutely.

Can you provide an example that wouldn't be "half-baked"? My point being,
unless you register the scheme, nobody is guaranteeing uniqueness, so it is
soft of "half-baked" automatically.

Another question: why are people fighting against this requirement? There
are tons of simply ways to produce lock tokens that meet all the criteria,
one of which is the opaquelocktoken scheme. I really don't see what's so
attractive about inventing new schemes to do the same thing.


Julian


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

Received on Thursday, 31 July 2003 02:52:02 UTC