RE: Boeing XRI Use Cases

> > From: "Paul Prescod" <>
> > Let me make a concrete proposal.
> > Could the W3C (the TAG? Or someone else?) issue a recommendation to the
> > effect that URIs of the following form are special:
> >*jbradley/+home/+phone
> .....
> > Once the W3C had issued such a recommendation, the chances of someone
> > minting these URIs by accident would drop
> Ray Denenberg wrote:
> But the problem isn't the risk of someone minting these URIs *after the
> fact* (accidentally or otherwise).  The problem with this approach,
> registering a reserved string for the first URI path component, is the
> possibility that that string is already used.  It's not simply a matter of
> telling everyone in the world "don't ever use this string as the first
> path
> component of any URI you ever mint in the future".   Rather, you're
> telling
> everyone they'll have to change every such existing URI. I'm sure nobody
> is
> contemplating that, so what it means is finding some unique string that
> nobody in the world has ever used (in that part of a URI).  How do you go
> about that? (And not just one - SOMETHING will only be the first, someone
> will subsequently want SOMETHINGELSE, then ANOTHERTHING, and so on.)

Ray, just to clarify, what I think Paul is suggesting is not a single string
but a pattern. Choosing a sufficiently unique pattern can reduce the chance
of false positives (existing URIs that match the pattern but are not in fact
instances of that "subscheme") to nearly zero. That's what the XRI TC was
after in our definition of HXRIs in section 11.2 of XRI Resolution 2.0 [1].

That's why I made the suggestion I did in my email last night [2] to add
another character to the pattern Paul suggested - my unsubstantiated guess
is that the resulting pattern would all but eliminate false positives.

That said, if there is a better approach to identifying HTTP "subschemes",
I'm very open to it. 



Received on Thursday, 17 July 2008 14:37:06 UTC