Subject: [urn] Consensus & terminology check: assigned-name (URN)

From: Sean Leonard <[email-masked]>
Date: Wed, 25 Nov 2015 07:18:12 -0800

This is a consensus check on our understanding of the NID : NSS production.

A urn: URI is parseable into the following components:
"urn:"
assigned-name
"?"
r-component
q-component
"#"
f-component

(Forget about the specific order for the time being. The list above is 
unordered.)

Have we been using the following terms with a clear consensus of their 
meanings?

URN
assigned-name
urn: URI

When I think of "URN equivalence" (draft Section 4), it is only the 
assigned-name production that is getting compared. q-component, 
f-component, and r-component are not considered.

I want to be sure in these discussions that, just as we are cleanly 
separating q- and r-components from each other, we also cleanly separate 
the NID : NSS portion from other parts.

It seems to me that <NID : NSS> is the Uniform Resource *Name*, which we 
can (and ought) to call one of: assigned-name, Name, or URN. 
q-component, r-component, and f-component are not *Name* parts. (I 
believe that at one point, it was called the p-component during WG 
discussion. Not sure if we want to call it that anymore.)

Furthermore, the complete urn: URI syntax, including NID NSS r-component 
q-component and f-component, is what can be called "urn: URI". (But it 
can be called something else.)

The main thing I am trying to get at here, is that our use of the term 
"URN" has not been precise enough, as our debates have pushed it around 
to mean different parts of different things. If we expand the acronym, 
Uniform Resource Name ought to refer to the "Name", which is the part 
that occurs before the first "?" and "#". A complete urn: URI is no 
longer "just a name" because q-component, r-component, and f-component 
are more like appended instructions to "do things with the named thing 
in a defined way (i.e., resolve them and process the resulting resources)".

Sean

PS In -14-seantek, I redefined the assigned-name production so that it 
excludes the "urn:" prefix. Look at the ABNF for details.

---

From: John C Klensin <[email-masked]>
Date: Wed, 25 Nov 2015 10:45:35 -0500

--On Wednesday, November 25, 2015 07:18 -0800 Sean Leonard
<[email-masked]> wrote:

> (Forget about the specific order for the time being. The list
> above is unordered.)

Without making any assertions about consensus, that is the model
I, and I believe Peter, have been following in editing 2141bis.
 
> Have we been using the following terms with a clear consensus
> of their meanings?
> 
> URN
> assigned-name
> urn: URI

At least in list discussions, I think "URN" has sometimes been
used more loosely, sometimes for the entire string that I've
referred to as a "urn-string" in some places (and for which
2141bis-14 uses "<namestring>" and that you describe as a "urn:
URI" above, and sometimes for the assigned-name only.   I hope
that bit of sloppiness does not appear in 2141bis; if people
find instances of it, I'd appreciate pointers so they can be
fixed.

FWIW, if anyone believes that clarity in 2141bis would be
improved by substituting "urn-string" for "namestring", as so.
It occurs to me after having read your note that "namestring"
might cause confusion with "Name" and hence the change might be
helpful, but I won't make the change it unless others think it
would help.

> When I think of "URN equivalence" (draft Section 4), it is
> only the assigned-name production that is getting compared.
> q-component, f-component, and r-component are not considered.

Again, I believe that is the intent of the text, although
r-components are a difficult area because some of the examples
various of us have given imply an opportunity for considerable
differences in the results of URN (sic) evaluation.   I think we
are ok with that and, coming back to an example I used in my
exchanges with Juha, it is another difference (other than "bad
idea") between (using the 2141bis-14 syntax)
   urn:isbn:xxxx??metadata     and
   urn:isbn-metadata:xxxx

My sense (could be wrong) is that we understand the difference
there and have a reasonable understanding the "urn:isbn:xxxx"
and "urn:isbn:xxxx??metadata" are the same name and reference
the same object even though the evaluation results are quiet
different.   Getting a clear, accurate, and succinct explanation
into the text has not proven easy.

> I want to be sure in these discussions that, just as we are
> cleanly separating q- and r-components from each other, we
> also cleanly separate the NID : NSS portion from other parts.

Yes.
 
> It seems to me that <NID : NSS> is the Uniform Resource
> *Name*, which we can (and ought) to call one of:
> assigned-name, Name, or URN. q-component, r-component, and
> f-component are not *Name* parts. (I believe that at one
> point, it was called the p-component during WG discussion. Not
> sure if we want to call it that anymore.)

The current intent of 2141bis has been to call it
"assigned-name" and, at least when the distinction is important,
to use that term consistently.  "Name" and "URN" are best
avoided because, independent of what the document says, they
carry connotations that may confuse people.  Again, while Peter
caught a lot, probably most, of them in -14, it would not
surprise me if there are places in 2141bis where things are not
as precise as they could be.  Again, specific pointers would be
appreciated if people find those.

> Furthermore, the complete urn: URI syntax, including NID NSS
> r-component q-component and f-component, is what can be called
> "urn: URI". (But it can be called something else.)

See above.
 
> The main thing I am trying to get at here, is that our use of
> the term "URN" has not been precise enough, as our debates
> have pushed it around to mean different parts of different
> things. If we expand the acronym, Uniform Resource Name ought
> to refer to the "Name", which is the part that occurs before
> the first "?" and "#". A complete urn: URI is no longer "just
> a name" because q-component, r-component, and f-component are
> more like appended instructions to "do things with the named
> thing in a defined way (i.e., resolve them and process the
> resulting resources)".

Yes.  But I fear that pinning down "URN" at this point,
especially given the added confusion of the language in 3986
that talks about URNs that are not part of the "urn:" scheme at
all, is fairly hopeless at this point.

> PS In -14-seantek, I redefined the assigned-name production so
> that it excludes the "urn:" prefix. Look at the ABNF for
> details.

Yes, I noticed that.  I no longer remember the details of the
discussion, but I think some combination of Peter and I decided
to include the prefix because it made discussions of equivalence
easier and avoided trying to be precise about what a "URN" was
(especially in the context of the other issues mentioned above).

    john

---

From: Keith Moore <[email-masked]>
Date: Mon, 30 Nov 2015 22:09:01 -0500

> Have we been using the following terms with a clear consensus of their 

preface: I'm resigned to "URN" referring to the entire string consisting 
of prefix, assigned-name, r-, q-, and/or f-components, for the simple 
reason that I strongly suspect that users will insist on calling 
anything that begins with "urn:" a URN.    This bothers me, because as 
you point out, the "name" is only the assigned portion, and a URN with 
r-, q-, and/or f-components attached isn't a pure name any more.   But I 
tried to craft more precise language, on multiple occasions I believe 
(e.g. "augmented URN" for a URN with one or more of those components 
attached), and I couldn't even get this group to buy into it.  If this 
group can't agree on something like that, getting the entire user 
community to use terms consistent with whatever we define is hopeless.

> f-component, and r-component are not considered.

When I read this, I find myself asking  "equivalence for what purpose?"

If you want to know if two URNs refer to the same resource, compare 
their assigned-names for equivalence.

If you want to know if two URNs are equivalent for other purposes, say 
for caching of results, you could compare the entirety of both URNs.   
This wouldn't ensure that you got the same result, as nothing constrains 
either the resolution service or the resource itself to produce 
consistent results from one access to the next, but it might still be 
useful for short-term caching.   (It's probably no worse than caching 
the results from GETs on HTTP URLs.)

> It seems to me that <NID : NSS> is the Uniform Resource *Name*, which 
> we can (and ought) to call one of: assigned-name, Name, or URN. 
> r-component q-component and f-component, is what can be called "urn: 
> URI". (But it can be called something else.)

I don't think it will fly, for the reasons listed above.   We should of 
course try to make the language in our documents precise and consistent 
within those documents.   But I think the meaning of URN is going to 
inevitably be "a URI that begins with urn:" no matter what we say.

> excludes the "urn:" prefix. Look at the ABNF for details.

If we want to be able to reference assigned-name in protocol 
specifications, e.g. in resolution protocols, it probably makes more 
sense to include the 'urn:' prefix than not.

Keith