Subject: Application for a formal URN NID ("EIDR")

From: Pierre-Anthony Lemieux <[email-masked]>
Date: Tue, 4 Feb 2014 22:32:36 -0800

Good morning/evening,

Per IETF RFC 3406, please find at the link below an application for a
formal URN NID ("EIDR").

http://www.ietf.org/id/draft-pal-eidr-urn-00.txt

Very much Looking forward to your comments and feedback. Let me know
if you need additional information.

Best,

-- Pierre [on behalf of MovieLabs (http://movielabs.com)]

---

From: Ted Hardie <[email-masked]>
Date: Wed, 5 Feb 2014 11:14:16 -0800

Thanks for sending your draft for review.  A few quick points:

The draft currently says:

EIDR-NSS = DOI-PREFIX ":" DOI-SUFFIX

This would seem to imply that any DOI prefix may be
encountered and that this NID could be used with any
registered DOI.  IF that were the intent, I would

suggest registering the namespace "DOI" instead.  I
understand that the DOI folks have consciously chosen not
to do that(cf: http://www.doi.org/factsheets/DOIIdentifierSpecs.html),

though, so I suspect your intent is to limit this to a subset
of DOIs.  Is that correct?  Is it essentially limited to 10.5240?
If not, how will the appropriate subset be identified?

This comes up again here:

When DOI-PREFIX is equal to "10.5240", the syntax of DOI-SUFFIX is
further constrained according to [SMPTERP2079] as follows:

           DOI-SUFFIX   = EIDR-SUFFIX
           EIDR-SUFFIX  = 5*5(4*4HEXDIG "-") CHECK
           DIGIT        = %x30-39
           HEXDIG       = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
           ALPHA        = %x41-5A / %x61-7A
           CHECK        = DIGIT / ALPHA

I don't think this says quite what you intend.  I think what you

intend is to say is that the overall syntax is roughly either:

urn:eidr:10.5240:EIDR-SUFFIX

or

urn:eidr:DOI-PREFIX-which-is-not-10.5240:DOI-SUFFIX

If the use of the URN is only for 10.5240, then you can just
drop the second syntax.  If it is for a set of DOI prefixes,
none of which but 10.5240 is intended to have this restriction,

then I believe you want to say, roughly:

EIDR-NSS = EIDR-PREFIX ":" EIDR-SUFFIX

where EIDR-SUFFIX has a choice pattern:

EIDR-SUFFIX: SMPTERP2079-SUFFIX | DOI-SUFFIX

And the list of DOI prefixes suitable for EIDR-PREFIX is
set you register as such. The syntax of the prefix can still

match the general DOI prefix.

Later, the document says:

Rules for Lexical Equivalence:

      Two EIDR-NSS are equivalent if and only if they are equal.  EIDR-
      NSS are case-insensitive.

"equal" here doesn't have a precise meaning.  I'd suggest that

you say something like "are lexically equivalent based on
a case insensitive string match"

regards,

Ted Hardie

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 6 Feb 2014 14:16:00 -0500 (EST)

If there's a difference between EIDR and DOI, you ought to make that
clear.  The two terms are used throughout the document and I vaguely
assumed that they are the same.  Actually, the underlying problem is
that you write the document assuming that the reader is thoroughly
familiar with EIDR's, DOI's, and the like.  Start with enough tutorial
so that someone who has never heard of either before (me) will have a
clear understanding of what is going on.

> From: Ted Hardie <[email-masked]>
> 

If the NID is to provide an encoding for all DOI names, then it should
be named "doi".  But if the DOI people have decided that it is not a
good thing to provide a NID for all DOI names, then:

- the NID should be "eidr"

- the syntax should not give a DOI-PREFIX, because that will *always*
  be "10.5240", and there's no point including a long invariant string
  in the syntax

Fundamentally, you need to determine if the DOI people are
fundamentally against mapping DOI names into URNs, or whether they
just don't want to put in the work (and you are actually doing the job
for them).

Also, if you are thinking of providing a NID that can encompass all
DOIs, you have to worry about character sets.  According to Wikipedia,
"Most legal Unicode characters are allowed in these strings", whereas
the %-encoding system can only represent ASCII characters.

>       where DOI-PREFIX and DOI-SUFFIX are DOI Name prefix and suffix,
>       respectively, translated into canonical NSS format according to
>       [RFC2141].  DOI Name syntax is specified in [ISO26234].

What you mean to say is something like:  A DOI name consists of a
prefix and a suffix, which are character strings [a fact the reader
didn't know before].  They are translated into the DOI-PREFIX and
DOI-SUFFIX by replacing all characters which are not XXX with
corresponding %-escapes.  (See RFC 2141 section 2.2.)

Exactly what the set XXX is needs to be specified with some care.
Section 2.2 specifies that all characters that may not appear in URNs
*at all* must be escaped.  But of course, ":" may appear in URNs and
by that specification need not be escaped.  OTOH, if ":" appears in a
prefix or suffix, you very well want it escaped.  I'm pretty sure that
you want XXX to be <pchar> as defined in RFC 3986 (the infamous
"Uniform Resource Identifier (URI): Generic Syntax").

Also, you are depending on the fact that EIDR suffixes consist of
ASCII characters, which can be represented by %-escapes (whereas DOI
suffixes can contain Unicode characters, which can't).

NIDs are case-insensitive (RFC 2141 section 5), but usually are
presented in lower case.

>           EIDR-SUFFIX  = 5*5(4*4HEXDIG "-") CHECK

You can just say

           EIDR-SUFFIX  = 5(4HEXDIG "-") CHECK

>    Identifier persistence considerations:
> 
>       As a DOI Name, the persistence of EIDR-NSS is guaranteed by the
>       ISO 26324 Registration Authority.  A DOI Name remains valid
>       indefinitely.

It would be clearer if you said something like

       The ISO 26324 Registration Authority assigns DOI Names to
       works(?).  A DOI Name remains valid indefinitely.  As a
       consequence, the URN derived from a DOI Name remains valid
       indefinitely.

Similar editing of the other items in this section would be helpful.

I can't quite put my finger on what seems to be the problem with the
writing.  I *think* the problem is that the text is written from the
point of view of someone who is thoroughly familiar with DOIs/EIDRs,
to the point where it never really has to be said what they are *for*
or how they work, whereas the correct way to write these sections is
from the point of view of someone who is familiar with URNs but has
never heard of a DOI before.  "We are talking about URNs that look
like this: ...  These URNs are used to specify DOIs, which are used in
XXX industry to designate YYYs.  DOIs are assigned to YYYs by ZZZ."

In the above paragraph, the sentence starts with "As a DOI Name...",
which is actually trying to leverage that the reader *already
understands* how DOI Names work.

>       As a DOI Name, the resolution of EIDR-NSS is handled by the ISO
>       26324 Registration Authority.
> 
>       The ISO 26324 Registration Authority operates a web service that
>       allows an EIDR-NSS to be resolved by issuing an HTTP GET request
>       to the following URI:
> 
>                "http://doi.org/" DOI-PREFIX "/" DOI-SUFFIX

As written, this doesn't specify anything, because you can apply that
process to any alleged EIDR.  In order to make this meaningful, you
have to specify what the format of the HTTP *response* is and the
significance of the elements of the response.  (Presumably there is an
ISO standard you can reference here.)

Dale

---

From: Pierre-Anthony Lemieux <[email-masked]>
Date: Thu, 6 Feb 2014 18:07:54 -0800

Hi Ted and Dale,

Thanks for the detailed comments, which I am in the process of
addressing. In the meantime, some additional background and
clarification on the request.

The requested EIDR NID is not intended to accommodate any and all DOI
Names, but specifically DOI Names allocated by EIDR organization, i.e.
DOI Names with a prefix assigned to EIDR organization. This means that
(a) EIDR organization essentially controls the syntax of the EIDR
Identifiers, e.g. add check codes and constrain it to the ASCII set,
and (b) the NID is specifically intended for audiovisual works. The
fact that EIDR Identifiers are valid DOI Names ensures persistence,
uniqueness and an open resolution infrastructure.

Currently, EIDR Identifiers use the 10.5240 prefix for audiovisual
works. The idea is to leave the door open for additional prefixes (and
corresponding suffixes) to be defined in the future (with EIDR NID
specification being updated accordingly). In all cases, these prefixes
and suffixes would be defined and controlled by EIDR organization.

So, if an implementation receives an EIDR-NSS with an unknown prefix,
it can still accept it, treating it as an opaque (case insensitive)
identifier (with the option of resolving it as generic DOI Name.) If
the prefix is known, additional processing can occur, e.g. error
detection in the case of the 10.5240 prefix.

Does this makes sense? I assume it is acceptable to reply cc'ing the
reflector. If not, I am happy to chat offline.

Best,

-- Pierre

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 7 Feb 2014 11:44:38 -0500 (EST)

> From: Pierre-Anthony Lemieux <[email-masked]>

> DOI Names with a prefix assigned to EIDR organization. [...]

Interesting...  That is what the draft *says* now that I read it again
but it didn't come through the first time I read it.  I think it would
be easier to understand if you start with

           URN-EIDR = "URN:EIDR:" EIDR-NSS
           EIDR-NSS = DOI-PREFIX ":" DOI-SUFFIX

      NOTE: The canonical string representation of an EIDR Identifier
      uses "/" instead of ":" as the delimiter between DOI-PREFIX and
      DOI-SUFFIX. ":" is used here since "/" is a reserved character.

Then say that the prefix must be one that is allocated to EIDR
organization, and that currently only '10.5240' is allocated, though
others might be allocated in the future.  Then continue,

Othewise the transition into "When DOI-PREFIX is equal to
"10.5240"..." is mysterious -- What is special about that value?  Why
is there a special syntax constraint on suffixes for that single
prefix?

You still need to worry about the character encoding issues regarding
possible additional prefixes, as the ISO standard doesn't restrict
possible future EIDR prefixes from including Unicode characters that
can't be represented with %-escapes.

Dale

---

From: Ted Hardie <[email-masked]>
Date: Fri, 7 Feb 2014 10:31:35 -0800

On Thu, Feb 6, 2014 at 6:07 PM, Pierre-Anthony Lemieux <[email-masked]>wrote:

> I think you might update the draft to discuss that these are intended to
be
a subset of DOIs, then, just to remove any confusion.

Would you anticipate that later EIDR suffixes would retain the syntax
of the current 10.5240-based identifiers?  If so, this would be relatively
simple.  If not, it may be simpler to register one namespace now, basedon
10.5240 and its syntax, and then register later NIDs for other prefix/suffix
combinations in future.

regards,

Ted Hardie

---

From: Pierre-Anthony Lemieux <[email-masked]>
Date: Thu, 20 Feb 2014 17:09:26 -0800

Good morning/evening,

Please find attached a revised application for the formal "EIDR" URN
NID. The revised application is intended to address the comments
received on the list.

Some highlights:

- the introduction was expanded to provide more details on DOI Names,
EIDR Identifiers and their relationship.
- the EIDR-URN syntax was refactored to focus on EIDR Identifiers, and
not DOI Names in general.
- the EIDR Identifier prefix and suffix character sets are now
explicitly specified to remove potential ambiguities in mapping them
to the URN character set
- the HTTP response to a resolution request to the ISO 26324
Registration Authority is now specified

I plan to update the I-D when the submission window reopens.

Thanks again to the commenters.

Best,

-- Pierre