Subject: [urn] Names and derived identifiers

From: [email-masked] (Dale R. Worley)
Date: Fri, 5 Sep 2014 23:07:01 -0400

Here I am attempting to summarize a conceptual distinction that seems
to be to be important for this discussion:  There are classes of
"identifiers" whose meanings are fixed by the meanings of "names" upon
which they are based.

(I think this aligns with the ideas Juha presented in his message
"Rules for identifier systems"
(http://www.ietf.org/mail-archive/web/urn/current/msg02449.html).)

Terminology:  I am going to use the terminology of RFC 3986:

name - A persistent, unique identifier whose definition and assignment
is managed by an explicit authority.  (In Juha's terminology, an
"identifier".)  (A URN, in RFC 3986 terminology.)

identifier - An identifier that indicates some resource(s) by some
means.  This identification may depend on an assumed "access" or
"resolution" process, and may depend on the circumstances within which
it is used.  (A URI, in RFC 3986 terminology.)

Let me go through a number of examples which share certain features:

Example 1: Adding a "fragment" part to a URN

Let us assume that <urn:oid:1.3.6.1.4.1.14490.21.137> is the name of an
HTML document.  (I have administrative authority over that part of the
OID tree, so I can make it so!)  And let us suppose that one of the
<a> tags in the document has a "name" attribute with value "section1".
Then (given how "fragment" is used in HTML URLs), it would be
reasonable to define that <urn:oid:1.3.6.1.4.1.14490.21.137#section1>
references that location within that (abstract) HTML document.

Example 2: Footnoting a page

Sitting in front of me is a copy of the book edition with ISBN
978-1-59403-698-9.  That book edition has the URN
<urn:isbn:978-1-59403-698-9>.

Suppose we define an extension to the syntax to allow reference to a
specific page of a book denoted by an ISBN:
<urn:isbn:978-1-59403-698-9^p=67>.  (Here, I deliberately use the
character "^" for the extension; "^" is not valid in URIs, and so I
cannot be thought to be advocating any particular syntax.)  This
construction would be useful for scholarly citations.

Example 3: Retrieving bibliographic information

Suppose there is a standard for providing the metadata (bibliographic
data) about a resource.  This has been called "URC" (Uniform Resource
Characteristics) in RFC 2169.  Then we could standardize that
<urn:oid:1.3.6.1.4.1.14490.21.312^metadata> is the identifier of the
metadata regarding <urn:oid:1.3.6.1.4.1.14490.21.312>.  (Of course,
this does not address how we obtain the metadata, it only defines a
standard identifier with which to refer to it.)

Example 4: Retrieving the instance of a resource from a particular server

Suppose we have defined a way to obtain an instance of the resource
named by <urn:oid:1.3.6.1.4.1.14490.21.6980> from a server.  Then we
could standardize the identifier
<urn:oid:1.3.6.1.4.1.14490.21.6980^resolver=foo.example.com> to be the
instance (if any) of <urn:oid:1.3.6.1.4.1.14490.21.6980> that can be
obtained from foo.example.com.

All of these examples have a two-part structure:

- a "base URN", which is a name in the strict sense -- its meaning is
  defined and fixed by an authority

- a "modifier" whose meaning/interpretation/effect is fixed by a
  standard

such that the combination of base URN and modifier is fixed by the
combination of the meaning of the base URN (set by the authority) and
the meaning of the modifier (set by the standard)

The degree to which the full URI is a name varies.  In regard to
Example 2 (footnoting a page), the modified URN is as well-defined,
unique, and permanent as the ISBN itself.  (Which is why scholarly
citations are done that way.)  It differs from full "names" by the
fact that its meaning is not *individually* set by an authority.

Similarly, Example 1 (Adding a fragment) generates a modified URN that
is a name in every way except that it is not individually allocated by
an authority.

Example 3 (metadata) would be a name if the contents of the metadata
was fixed by some standard or authority.  But it seems that in
practice, it is not so, so the modified URN is just a URI, as the
result of a particular reference to the resource depends on many
unknown factors.  (And it is not even a URL, as it does not describe
how to resolve itself.)

Example 4 (retrieving from a particular server) is a URL, since it
specifies how to obtain the described information.  But it is not a
name, as there is no assurance that particular resolver can produce an
instance of that base resource.

So although all of these modified URNs are constructed in the same
generic way, the nature of the resulting URI (URN, URL, neither, or
perhaps both) depends on the specification of the modifier.

If we want to allow these sorts of construction, I do not see that as
a problem, as long as we remain aware that the modified URN may not
have the same properties as the base URN.  I doubt anyone will be
confused in any particular application, but people must beware of
making generalizations without thinking through the various
possibilities.

Dale

---

From: John C Klensin <[email-masked]>
Date: Sat, 06 Sep 2014 03:03:09 -0400

Dale,

I think I understand what you are attempting to do and believe
it is constructive.  However, trying to do it in terms of
definitions and other semantics in 3986 that have already been
shown to be problematic is not particularly helpful, at least
for me.  Details inline below.

--On Friday, September 05, 2014 23:07 -0400 "Dale R. Worley"
<[email-masked]> wrote:

> Here I am attempting to summarize a conceptual distinction
> that seems to be to be important for this discussion:  There
> are classes of "identifiers" whose meanings are fixed by the
> meanings of "names" upon which they are based.
> 
> (I think this aligns with the ideas Juha presented in his
> message "Rules for identifier systems"

Unless you are going to argue against the general approach of
draft-ietf-urnbis-semantics-clarif (in which case, please do so
explicitly), please don't.  The particular vocabulary of 3986
has been, at least IMO, a significant part of the confusion and
delay in this WG and, at least through and including the Toronto
discussions, viewing 3986 purely as a syntax definition appears
useful (and possibly even necessary) to this WG's making
progress.

In particular, the class of URN that acts as an indicator or
flag, such as the XMPP case that Peter has mentioned several
times, does not conform to the "identifier" definition you cite
below.  If we intend to have a discussion about deprecating that
use, let's have it explicitly.  If we do not, let's move on.

> identifier - An identifier that indicates some resource(s) by
> some means.  This identification may depend on an assumed
> "access" or "resolution" process, and may depend on the
> circumstances within which it is used.  (A URI, in RFC 3986
> terminology.)
 
> Let me go through a number of examples which share certain

I'm going to take a couple of these examples as additional
examples of why trying to reintroduce fine interpretations of
3986 is not helpful here:

> Let us assume that <urn:oid:1.3.6.1.4.1.14490.21.137> is the
> name of an HTML document.  (I have administrative authority
> over that part of the OID tree, so I can make it so!)  And let
> us suppose that one of the <a> tags in the document has a
> "name" attribute with value "section1". Then (given how
> "fragment" is used in HTML URLs), it would be reasonable to
> define that <urn:oid:1.3.6.1.4.1.14490.21.137#section1>

But 3986 explicitly binds fragments to media type, so, unless
either every OID or your particular OID has a media type, that
discussion leads to a very odd place.  In addition, as
previously discussed on-list and reflected in Appendix B.3 of
the current draft, there is a case to be made that the fragment
to which you refer is really a property of the HTML document and
not the OID or URN.  As such, the syntax you are looking for
might be more like

<http://retrieval.mechanism.domain/?urn:oid:1.3.6.1.4.1.14490.21.137#section1>
I don't believe that, but the distinction is very fine indeed
and one that the WG may need to address.

> Suppose we define an extension to the syntax to allow
> reference to a specific page of a book denoted by an ISBN:
> <urn:isbn:978-1-59403-698-9^p=67>.  (Here, I deliberately use
> the character "^" for the extension; "^" is not valid in URIs,
> and so I cannot be thought to be advocating any particular
> syntax.)  This construction would be useful for scholarly
> citations.

Of course, your doing that as part of the URN requires that you
have an agreement with the particular publisher that all
instances of objects that they associate with the ISBN have the
same pagination properties.  I don't believe that is a
requirement of the ISBN standard.  Whether it is or not, I know
(as Juha has also pointed out), publisher assignments of ISBNs
are sometimes more flexible.

> Suppose there is a standard for providing the metadata
> (bibliographic data) about a resource.  This has been called
> "URC" (Uniform Resource Characteristics) in RFC 2169.  Then we
> could standardize that
> <urn:oid:1.3.6.1.4.1.14490.21.312^metadata> is the identifier
> of the metadata regarding <urn:oid:1.3.6.1.4.1.14490.21.312>.
> (Of course, this does not address how we obtain the metadata,
> it only defines a standard identifier with which to refer to
> it.)

I'll let you and Juha (and others who are interested) debate
whether that form is an identifier or a service request.  I hope
that, in the process, you will explain to the rest of us how the
distinction moves the work of the WG forward.

>...

  best,
     john

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 8 Sep 2014 16:54:06 -0400

> From: John C Klensin <[email-masked]>
> 

If you have an alternative set of "definitions and other semantics",
I'm probably willing to use it, but I don't recall having seen one
that has the categories I'm trying to use.

> useful (and possibly even necessary) to this WG's making

I've read draft-ietf-urnbis-semantics-clarif (more or less), and I
just peeked at it again, and I don't see where "the general approach"
of that document provides a revised vocabulary for naming the various
semantics for URIs.

> > circumstances within which it is used.  (A URI, in RFC 3986

OK, I wasn't clear enough.  In *that* definition, I take "resource" in
the broadest possible meaning, including resources that are concepts.
So a URI can be used as an indicator or designator for just about
anything.  (Of course, there is the treachery that Juha uses the term
"identifier" in a very different sense.)

> discussion leads to a very odd place.

Uh, that's true.  But as I said, "Let us assume that
<urn:oid:1.3.6.1.4.1.14490.21.137> is the name of an HTML document."
So "[my] particular OID has a media type".

> are sometimes more flexible.

OK; my understanding was that ISBN assignment is very rigid, and so
every potential book that is an instance of ISBN 978-1-59403-698-9
will have exactly the same contents on page 7.

Hmmm, I think where I got that idea is from the passage 

    It isn't true that ISBN numbers never change. They change rarely,
    perhaps. A primary use of ISBN was as bookstore stock and pricing
    unique key. So if a book is printed with multiple color covers,
    they might use the same ISBN number. New printing, perhaps a minor
    printing flaw fixed, ditto.

which I read in
http://www.ietf.org/mail-archive/web/urn/current/msg02342.html.
However, while that *message* was from Juha, the passage in question
is from Larry Masinter.

But... as this is an example of a concept, the question isn't whether
it's correct in our world, but to show that there are examles of a
pattern.  In this case, the pattern is "The assigning of a name may
cause the implicit creation of additional derived names.  And the
derived names may be as "good" as the original name, in terms of their
stability and uniqueness."

> whether that form is an identifier or a service request.

As I'm using the term "identifier" extremely broadly (broadly enough
to include SIP URIs as "identifiers"), there's no particular
distinction between "identifier" and "service request".

But I see Example 3 as creating an "identifier", not a "service
request", as it is *not* clear from the new URI how one goes about
retrieving the information that is implied.

Example 4 is more of a "service request", and it is actually a
"locator", as it gives you enough information to know what network
operation to execute to access it:

    <urn:oid:1.3.6.1.4.1.14490.21.6980^resolver=foo.example.com>

> I hope that, in the process, you will explain to the rest of us how
> the distinction moves the work of the WG forward.

The point that I'm trying to make is that when a name is assigned, it
makes sense in many cases for the assignment to bring into existence
additional "identifiers".  Depending on the definition of the
mechanism that defines the identifiers, their properties can vary:
Some of them are "names", in the sense of having a permanant, fixed
meaning.  Some of them are "locators", in the sense that there is
(assumed to be) a disk file or such concrete data object, and the
locator defines how one executes a network operation to get a copy of
the data object.  Some of them are "indicators", whose meaning is
broader.

In practice, if such a situation exists, it seems that the
practicalities aren't confusing.  But adjusting the terminology to
handle the general case is messier.

And I think we need to beware of that, because all the instances I've
seen where people suggest attaching "fragments", "queries", "service
requests", etc. are of this nature:  Taking a managed name and turning
in into an identifier which is useful, but may not be expected to be a
name at all.  It doesn't help to note that adding a "service request"
decoration to an item in the URN namespace does not generate a proper
name -- we already know that.  What we need is a terminology which
isn't inconvenienced by that.

But it's also a reason why the universe of URNs isn't disjoint from
the universe of other URIs -- we may well want systematic ways of
generating URIs from URNs.

Dale