[urn] The URN:GLUE proposal

This is getting caught up with the last several days of the discussion.
It is separated into several sections which are not strongly related.

0. Frustration

Upon reviewing the e-mails and the message I am writing, I am
sympathetic that this must be quite frustrating to the authors.  OTOH,
as others have noted, this I-D was sent to the URN committee very late
in the process, and it would have been wise to do so earlier.  More
subtly, while item 2, "politics", might be a surprise, items 3 and 4 are
purely technical and ISTM could have been anticipated and cleaned up
earlier in the process.

1. The possibility of a URI scheme rather than a URN namespace.

Creating "glue" as a URI scheme has the advantage that URIs do not
implicitly carry the semantics of being a "name" and so if the user
wishes to treat them as names, they must verify that themselves within
their particular processing environment.  All that is guaranteed of URIs
is that they meet the syntax and that if two URIs are case-sensitively
textually identical, they have the same semantics, whatever that might
be.

This is worth checking with users of similar identifiers -- do they
want to have all presented identifiers known to be semantically nice, or
are they already expecting to have to classify and subcase identifiers
in order to process them properly?

2. The politics of using someone else's identifier

As Peter says
> This sidesteps the question of whether the originating authority wishes 
> its identifiers to be incorporated. It seems to me that as a matter of 
> professional courtesy and to avoid any misunderstandings the IETF should 
> not incorporate identifier systems defined by other standards 
> development organizations without consultation and prior agreement. 
> Anything less could be perceived as rather aggressive.

Someone noted that RFC 8141 anticipates that other identifier systems
will be incorporated into URN namespaces.  But I quote section 6.3

    6.3.  Registration Policy and Process: Fast Track for Standards
          Development Organizations, Scientific Societies, and Similar
          Bodies

   The IETF recognizes that situations will arise in which URN
   namespaces will be created to either embed existing and established
   standards, particularly identifier standards, or reflect knowledge,
   terminology, or methods of organizing information that lie well
   outside the IETF's scope or the likely subject matter knowledge of
   its Designated Experts.  In situations in which the registration
   request originates from, or is authorized by, a recognized standards
   development organization, scientific society, or their designees, a
   somewhat different procedure is available at the option of that body:

The salient point is that the text assumes (without really analyzing)
that for such a namespace, the registrant will be the organization that
defines the incorporated identifier.

So I take it that "the IETF" has not really examined this issue.

Thus my current position is that we, the URN NID committee, should
consider that registrations by third-party organizations are suspect
*unless* a WG has discussed the matter and reached consensus that such
non-coordinated incorporations are OK.

Pursuant to that, can the authors of the I-D provide a summary of any
such discussions in the SPICE working group?

3. Technical matters in registrations

Section 7.1.2 of the GLUE states the transformation from the external
authority's form of the identifier to the GLUE form.  E.g.,

   7.1.2.1.  gln

   Authority Identifier:  gln
   URN:  urn:glue:gln
   Organization:  GS1
   Transformation Rules:  N/A
   Change Controller:  IETF
   Specification Document(s):  Section 4 of this specification, [GLN]

However, the transformation rules aren't noted in Table 1 in section 4,
so the table is a lossy transcription of the registrations.

A deeper problem is that the registrations don't specify the formal
*name* of the specification.  In most cases, they forward into the body
of the I-D (which won't be immediately visible to someone looking at the
registry), and even there provide only a URL to a specification (which
by definition isn't guaranteed to be persistent).

More subtly, they don't specify the formal name of the *version* of the
specification.  And that is necessary to an implementor to know the
correlation between the rules stated in the registration and versions of
the external identifier.  It's quite possible for an external authority
to define a new version of an external identifier that causes the code
specified by the transformation rules to throw an exception when
processing identifiers of the new version.

4. Items in the I-D itself

   By default,
   a GLUE URN is not equivalent to any other URN, including a URN
   defined by the referenced authority's own namespace.  Equivalence
   between a GLUE URN and a non-GLUE URN exists only when explicitly
   specified for a given Authority Identifier.  Implementations and
   relying parties MUST NOT assume equivalence between GLUE URNs and
   non-GLUE URNs unless such equivalence is explicitly defined by the
   authority and the party understands that particular Authority
   Identifier and the specified equivalance.

My first complaint is the phrase "the authority".  I expect you mean "the
External Authority", but you don't say that; indeed "authority" alone is
not defined.  Similarly for several other places in the I-D.

My second complaint is that this would just be nit-picking, but we need
to be rigidly clear about the distinction between the External Authority
that assigned the External Identifier, the registrant of GLUE, and the
registrant of the other URN namespace.  And this feeds into the
unresolved matter of who defines "such equivalence".

In the one example we have already, LEI, I see that the LEI namespace is
registered by the GLEIF, but GLEIF isn't the one who is specifying the
equivalence of urn:glue:lei and urn:lei; that's done by section 4.1.1 of
the draft, i.e., the IETF.

So it seems to me that this paragraph needs to be thought through, and
it and reality aligned.

Also, I see that in Table 1 in section 4 and the entries in section
7.1.2, the term "organization" is used for "External Authority".  This
contradicts that everywhere else in the I-D "organization" is used for
*the things being identified by the URNs*.

Dale

_______________________________________________
urn mailing list -- [email protected]
To unsubscribe send an email to [email protected]