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

Pierre-Anthony Lemieux <> Fri, 21 February 2014 01:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A96D61A0396 for <>; Thu, 20 Feb 2014 17:10:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.732
X-Spam-Status: No, score=0.732 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T_2oXZnIjQHO for <>; Thu, 20 Feb 2014 17:09:55 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7D2A51A038B for <>; Thu, 20 Feb 2014 17:09:55 -0800 (PST)
Received: by with SMTP id c9so4290595qcz.26 for <>; Thu, 20 Feb 2014 17:09:51 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=A6UjZGs/v1+xFVDuTRr2WNeTsF5qOjnezJukwWClqg4=; b=lF5gvyXb56s8vd/TBGNZ0mj+PuCLBiFdzVRLz8PdJuh6e0goZYwSDlk0gvbPpMskkZ VMD4MSNXmvUPXsprM/h+Vb4Uk6gNtMRNXZBFJhV/m76loMkEQxe2iO1ZPThjw8/sB1wE 0X+9zepGyTWUeH00mk8BjoVT57AoTOdLdH/hiFBvJaNa+kbi4COZjoK4IjIVjfT7+d/F Zo0zptkYeKMbfapr+bFxqLWH0vfn8ds1BpG51jY4TL4iXUDq60tjBbwXLRvqF8H5/XWk J3ob4AKBvOUIbQL26X71lDwSmtuloC0Ox2MYPCbbOu8QzxpFPBnfXFgzlrX5/XUyMOS3 ZUeQ==
X-Gm-Message-State: ALoCoQlrEytPbU+Pry1yNBukfz3uLvQT3wmfwkeIcWak8yFenMNqgdOcLHVQyHsM98aSvggwKmR7
X-Received: by with SMTP id q5mr5961076qai.39.1392944991514; Thu, 20 Feb 2014 17:09:51 -0800 (PST)
Received: from ( []) by with ESMTPSA id k107sm10169913qgk.5.2014. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Feb 2014 17:09:47 -0800 (PST)
Received: by with SMTP id i17so4718305qcy.39 for <>; Thu, 20 Feb 2014 17:09:47 -0800 (PST)
X-Received: by with SMTP id j20mr6088087qar.82.1392944987202; Thu, 20 Feb 2014 17:09:47 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 20 Feb 2014 17:09:26 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: Pierre-Anthony Lemieux <>
Date: Thu, 20 Feb 2014 17:09:26 -0800
Message-ID: <>
Subject: Re: Application for a formal URN NID ("EIDR")
To: "" <>
Content-Type: multipart/mixed; boundary=089e0149c18627b9ea04f2e0473e
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Feb 2014 01:10:00 -0000

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.


-- Pierre

On Thu, Feb 6, 2014 at 6:07 PM, Pierre-Anthony Lemieux <> wrote:
> 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
> On Thu, Feb 6, 2014 at 11:16 AM, Dale R. Worley <> wrote:
>> 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 <>
>>> 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:,
>>> 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?
>> 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:
>>>                "" 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