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

[[e-mail] (Dale R. Worley)]

> From: Pierre-Anthony Lemieux <[e-mail]>

> 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. [...]
> 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.

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

      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].

      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,

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

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