[urn] Re: Request to register urn:glue

Comments on draft-ietf-spice-glue-id-07:

2.1.  Uniqueness and Namespacing

   Each GLUE URI MUST be globally unique.

   An organization can be identified by multiple GLUE URIs, but each
   GLUE URI can only refer to a single organization.

The first of these sentences doesn't make much sense, since of course
"any two GLUE URIs" means any two that are different.  All of the
meaning you want is captured in the second sentence.

   It is assumed that most registered organizational entity
   identification schemes already handle any necessary namespacing as
   part of the External Identifier.  However, if collisions are possible
   within the set of possible external identifiers for an Authority
   Identifier scheme, then further namespacing is necessary at the GLUE
   URI level.  Such namespacing MUST be done using the Authority
   Identifier.  The combination of the Authority Identifier and the
   External Identifier MUST result in a unique GLUE URI.

The difficulty with this paragraph is that the term "namespacing"
isn't well-defined.  Pretty much all of the meaning you want is
captured in "each GLUE URI can only refer to a single organization"
above.  It seems to me that it would be best to omit this paragraph.

3.  GLUE URIs

You probably want to title this section "GLUE URNs".

   GLUE URIs comply with [RFC3986].

Why doesn't this say "GLUE URNs comply with [RFC38141]."?

   They begin with urn:glue: and are ...

This would read better as

   They begin with "urn:glue:" and are ...

as is the style elsewhere in the document.

   There is a limit of 1000 characters for an External Identifier.

Given that this limit is much larger than we expect to need in
practice, it seems to me that you might instead want to limit the
URN's overall length to 1023 characters or less to avoid data
processing systems treating GLUE URNs as "potentially large" objects.

   Consequently,
   GLUE URIs do not support representation of External Identifiers whose
   canonical form includes non-ASCII characters.  This specification is
   therefore limited to identifier systems whose canonical
   representations are fully within the permitted character set.

I'm not sure you want to use "canonical" here; if you speak of
"canonical form" you imply that there are other forms as well, and in
that case, there might be a defined form that uses only the permitted
characters.  So I think you want to say something like:

   Consequently, GLUE URIs do not support representation of External
   Identifiers which include non-ASCII characters.  This specification
   is therefore limited to identifier systems with representations
   that are fully within the permitted character set.

--

   It is specific to the Authority Identifier whether the
   External Identifiers are case-insensitive or case-sensitive.  When
   they are case-insensitive, the canonical form is lowercase and
   documents that specify External Identifiers must do so with lowercase
   letters.

I suggest that you avoid having "for some authorities the external
identifier is case sensitive and for some it is case-insensitive"
because that becomes a nightmare to implement:  proper
equivalence-testing code needs to be continuously updated based on new
authority registrations.

Also, despite the statement "It is specific to the Authority
Identifier whether the External Identifiers are case-insensitive or
case-sensitive", the registrations in sec. 7.1.2 do not state for each
authority whether the external identifiers are case-sensitive.  This
suggests you haven't thought through all of the complexities involved.

To avoid trouble, I suggest that if the authority considers its
identifiers to be case-insensitive, it should only create GLUE URNs in
one case or the other.  The current document suggests that you want it
to be "MUST be lower-case".  But for some reason, sec. 4.1.1
contradicts that, providing a "urn:glue:lei" URN in upper case.  So
maybe you want to just require the authority to pick one case and
stick with it.

4.  GLUE Authority Identifiers

This section list 5 authorities, which are registered in section
7.1.2.  Have your verified that when you mention e.g. "GS1" that it is
completely unambiguous what character sequence is intended for the
external identifier without any further explanation.

My quick check turns up that DUNS numbers are sometimes expressed
using hyphens, which appear to be non-significant:  "A D-U-N-S number
is a unique nine-digit identifier assigned by Dun & Bradstreet (D&B)
to legally identify businesses, such as 12-345-6789 or 150483782. It
is used to verify company identity, creditworthiness, and to register
for government contracts or grants."

There are also suggestions that ISO/IEC 6523 identifiers may sometimes
be considered to contain colons, which are of course forbidden by the
external identifier syntax:  "ISO/IEC 6523 provides a standardized
format for uniquely identifying organizations in electronic business,
structured as ICD:OrganizationIdentifier. A common example is an
Australian Business Number (ABN), represented as 0151:55609885501,
where '0151' is the International Code Designator (ICD) for the
ABN. Other examples include DUNS (0060) and LEI codes (0199)."

And indeed, since for some future authorities this question will arise,
you need some place in the authority registration template to document
clearly what form of the identifier is to be used as the external
identifier.

4.1.  Equivalence to Similar URIs

   A GLUE URI is an identifier in a distinct URN namespace.  By default,
   a GLUE URI is not equivalent to any other URI, including a URI
   defined by the referenced authority's own namespace.  Equivalence
   between a GLUE URI and a non-GLUE URI exists only when explicitly
   specified for a given Authority Identifier.

As in the discussion for sec. 3, allowing each registration to specify
equivalence to other URNs that a generic equivalence-testing routine
has to understand is a recipe for confusion.  Better to allow that the
authority can define an equivalence that applications that understand
that particular authority identifier can apply but not require a
general equivalence-tester to understand.

5.  Security Considerations

   Security considerations for URNs can be found in [RFC2141].

Since RFC 2141 was obsoleted by RFC 8141, why doesn't this reference
8141?

Dale

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