RE: [bt-spec] Issue 78: revised solution

[Peter Furniss <peter.furniss@choreology.com>]

Doug,

> What you've done improves things more than my simple change.  It makes me
> wonder, though, why are we talking about URI values at all?  Wouldn't the
> text be simpler throughout the specification if it discussed names rather
> than identifiers and URN's rather than URI's?  I haven't resorted
> to looking
> up the proper RFC documents.  I might be ignoring something major
> like http:
> or uuid: not being valid URN schemes.

If I'm reading rfc 2396 correctly (and contrary to my belief before I did),
the URN and URL are defined by their use, not by their internal syntax.  So
if I find in some xml,
   xmlns:xsch="http://www.w3.org/2001/XMLSchema"
the URI is a URN. But if I say "a human-consumable page about, and links to
various representation for the XML schema is at
http://www.w3.org/2001/XMLSchema" then it's a URL.

So http was designed as a URL scheme, but that doesn't preclude the use of a
value from it as a URN. As a scheme, I believe uuid: would be a URN scheme,
but a value could be used as a URL if the context it was used in was known
to have some lookup mechanism supporting it (that is definitely well into
the angels-on-pinheads area). I think rfc 2396 implies that there is no real
distinction between urn and url schemes, and they are all uri schemes.

I'm no longer sure myself what the general understanding of URI, URL and URN
is, and I'd welcome correction on the above - but it does seem to be a
strict interpretation of the definition in rfc 2396 (I've included the
paragraph in question at the bottom, though not the wider context).  The
model text, since it is essentially explanatory, needs to build on what
people understand, so URI or URN probably should build on that as well as
the pedantic details.

I think we probably want to stick with "identifier" as the parameter name,
since transaction identifier is a common concept in this area, even if it is
a name according to the definitions. I'm open on whether we describe it as a
URN or URI.

> If we go with the lesser change you've proposed, I have a couple of minor
> corrections:

Thanks - I've applied these to what is in the issues list as the current
proposed solution.  In that text I've flagged the two sentences involved as
being potentially affected by issues 100 and 101.

Peter



from http://www.ietf.org/rfc/rfc2396.txt

 URI can be further classified as a locator, a name, or both.  The
   term "Uniform Resource Locator" (URL) refers to the subset of URI
   that identify resources via a representation of their primary access
   mechanism (e.g., their network "location"), rather than identifying
   the resource by name or by some other attribute(s) of that resource.
   The term "Uniform Resource Name" (URN) refers to the subset of URI
   that are required to remain globally unique and persistent even when
   the resource ceases to exist or becomes unavailable.