Re: Application for a formal URN NID ("EIDR")
Pierre-Anthony Lemieux <pal@sandflow.com> Fri, 21 February 2014 01:10 UTC
Return-Path: <pal@sandflow.com>
X-Original-To: urn-nid@ietfa.amsl.com
Delivered-To: urn-nid@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96D61A0396 for <urn-nid@ietfa.amsl.com>; Thu, 20 Feb 2014 17:10:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.732
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T_2oXZnIjQHO for <urn-nid@ietfa.amsl.com>; Thu, 20 Feb 2014 17:09:55 -0800 (PST)
Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2A51A038B for <urn-nid@apps.ietf.org>; Thu, 20 Feb 2014 17:09:55 -0800 (PST)
Received: by mail-qc0-f181.google.com with SMTP id c9so4290595qcz.26 for <urn-nid@apps.ietf.org>; Thu, 20 Feb 2014 17:09:51 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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 10.224.67.69 with SMTP id q5mr5961076qai.39.1392944991514; Thu, 20 Feb 2014 17:09:51 -0800 (PST)
Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by mx.google.com with ESMTPSA id k107sm10169913qgk.5.2014.02.20.17.09.47 for <urn-nid@apps.ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Feb 2014 17:09:47 -0800 (PST)
Received: by mail-qc0-f180.google.com with SMTP id i17so4718305qcy.39 for <urn-nid@apps.ietf.org>; Thu, 20 Feb 2014 17:09:47 -0800 (PST)
X-Received: by 10.224.122.20 with SMTP id j20mr6088087qar.82.1392944987202; Thu, 20 Feb 2014 17:09:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.41.133 with HTTP; Thu, 20 Feb 2014 17:09:26 -0800 (PST)
In-Reply-To: <CAF_7JxAsn7StRvXf8B+dPpu8a97XACH+DAf8ftZN6OVFkJmXkg@mail.gmail.com>
References: <CAF_7JxASOJEKwZ_XAohHwqVjaDz5zqqbG349dCNiQHRh+nnHxw@mail.gmail.com> <201402061916.s16JG0J64392388@shell01.TheWorld.com> <CAF_7JxAsn7StRvXf8B+dPpu8a97XACH+DAf8ftZN6OVFkJmXkg@mail.gmail.com>
From: Pierre-Anthony Lemieux <pal@sandflow.com>
Date: Thu, 20 Feb 2014 17:09:26 -0800
Message-ID: <CAF_7JxB046x5zZOsjV+VocasxXyVDjJqgdcN7h3mmXxizmu53A@mail.gmail.com>
Subject: Re: Application for a formal URN NID ("EIDR")
To: "urn-nid@apps.ietf.org" <urn-nid@apps.ietf.org>
Content-Type: multipart/mixed; boundary="089e0149c18627b9ea04f2e0473e"
Archived-At: http://mailarchive.ietf.org/arch/msg/urn-nid/0k6uzsXdp_pzqtfzoUThI5CK2Tc
X-BeenThere: urn-nid@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <urn-nid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn-nid/>
List-Post: <mailto:urn-nid@ietf.org>
List-Help: <mailto:urn-nid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=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. Best, -- Pierre On Thu, Feb 6, 2014 at 6:07 PM, Pierre-Anthony Lemieux <pal@sandflow.com> 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 <worley@ariadne.com> 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 <ted.ietf@gmail.com> >>> >>> 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? >> >> 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
- Application for a formal URN NID ("EIDR") Pierre-Anthony Lemieux
- Re: Application for a formal URN NID ("EIDR") Ted Hardie
- Re: Application for a formal URN NID ("EIDR") Dale R. Worley
- Re: Application for a formal URN NID ("EIDR") Pierre-Anthony Lemieux
- Re: Application for a formal URN NID ("EIDR") Dale R. Worley
- Re: Application for a formal URN NID ("EIDR") Ted Hardie
- Re: Application for a formal URN NID ("EIDR") Pierre-Anthony Lemieux
- Re: Application for a formal URN NID ("EIDR") Pierre-Anthony Lemieux