From nobody Mon Jun 4 14:23:22 2018 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D05130DC0 for ; Mon, 4 Jun 2018 13:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 VsHcDjJusNDE for ; Mon, 4 Jun 2018 13:46:41 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14E46130DE2 for ; Mon, 4 Jun 2018 13:46:41 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id v131-v6so871355wma.1 for ; Mon, 04 Jun 2018 13:46:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc:message-id :references:to; bh=A9S3dPdPYY7iePONzhmAe/W/2qi26Jtlv4L9c6KkOj8=; b=QhtICdv6axYjI0CS1RwiKxo3y3/O/btDE9Ep0vASihD8uHmA9H4lyYmI80LXez2Llg mMbht2J2qb7xMKOQBg5pIgLyd22yxUwM0wTte7qYpiO827JCAUtqKa/VRYPmlsFc/xjX 1P17TZSHBWM6RB4bRF6grG+SQR0H5q6DGK3SC+M0hUP2SotwN4u9HnQ8DkLxDSiBDTeW vmys4RnShxBFNky5x2ra6WcwYzL9mRXu3nG8FPc2Pq1/lt+g+B+AvR0X+oif8jGd2IGD Aw9abi44RxHk73oNlBSS0iV+VT81By3q+afaLGJIFszbVbb8HoJr/mqwi0M7RYOdWLNg +4Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; bh=A9S3dPdPYY7iePONzhmAe/W/2qi26Jtlv4L9c6KkOj8=; b=bn7PERqBSVkHkUuTW8L8YLRehIeH7/+aJMM4n011KLgUtllpdPCtVxqCxhG5C3Gpw9 AzxfseplQpBMiF1wAjcJWVgBNwBodI05G8GOIqbRgE8yTUSm7LEhyHTzShiA93jePdcN CFnoynwJguCZSqzXh8HHgcE8wDgJu//1whJYlmtYMCX38wsOOTbyY4QDzgaiHk1oJRL3 MoEHeAuDnBLDMdegyFfRWi9V1P3q2jj1kS/mJDM1kgq1GR8VI0wEFjClRdJZ3GebIT9i SAxA/4HTJeigEjzsdgZlddann3f0MKd7sgDnPe9I20WsMWmSN6ggtIzTrYDVNOdLai7S zCgw== X-Gm-Message-State: ALKqPwdriLNdgIVq97dzKT1TZhLdNM4VpXrxDqPcuOOSagdPL2XOveC/ mlHwJv6pOhNDm/OSs9DexOw= X-Google-Smtp-Source: ADUXVKLHAzL3+vLjs1Zv5WDLgzHnw2zfRyV3kOTvSdlVRRqFzE4SIti+y4nQNeWvT8f2Q8o6i2Y2uw== X-Received: by 2002:a50:9176:: with SMTP id f51-v6mr25834797eda.29.1528145199412; Mon, 04 Jun 2018 13:46:39 -0700 (PDT) Received: from air-di-enrico.fritz.box (dsl-85-10-108-171.internet.lu. [85.10.108.171]) by smtp.gmail.com with ESMTPSA id q22-v6sm424694edd.69.2018.06.04.13.46.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 04 Jun 2018 13:46:38 -0700 (PDT) Sender: Enrico Francesconi Content-Type: multipart/alternative; boundary="Apple-Mail=_D54EB501-EDF6-4FEB-AB16-ED37D3A57F0C" Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Enrico Francesconi In-Reply-To: <87a7tk6wgz.fsf@hobgoblin.ariadne.com> Date: Mon, 4 Jun 2018 22:46:35 +0200 Cc: Pierluigi Spinosa , LUPO Caterina , urn@ietf.org, Alexey Melnikov , Barry Leiba , Peter Saint-Andre , john-ietf@jck.com, L.Svensson@dnb.de, "Hakala, Juha E" Message-Id: <921B7656-86DB-471A-9085-91381725D2BC@ittig.cnr.it> References: <87a7tk6wgz.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3094) Archived-At: X-Mailman-Approved-At: Mon, 04 Jun 2018 14:23:21 -0700 Subject: Re: [urn] Moving ahead with draft-spinosa-urn-lex X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 20:46:45 -0000 --Apple-Mail=_D54EB501-EDF6-4FEB-AB16-ED37D3A57F0C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Dale, thanks for your message and to the colleagues who approved your = proposal to move ahead with urn-lex registration.=20 As for the issue you raised about the maintenance of the registry of = jurisdiction codes, we agree at this stage to be ITTIG-CNR the Registrar. In this respect we propose the following changes: Section 3.1 "However, a special register for the , maintained by IANA, is required, the rules of which are defined in section 11.2." =E2=80=94> "However, a special register for the is required, the rules of which are defined in section 11.2." [...] Section 11.2 "IANA is requested to create a new registry for , with the following format:" =E2=80=94> "It is requested to create a new registry for , with the following format:" [...] "un.org "; "United Nations"; "DPI, United Nations, =
, "; [reference] =E2=80=94>=20 "un.org "; "United Nations"; "DPI, United Nations, =
, "; [reference] In the current experimental LEX registration phase, ITTIG-CNR will take = care to create and maintain the registry for . As the criteria of the LEX names assignment will be consolidated, after = the experimental phase such registry will be maintained by IANA. The adopted registration policy is compliant with the "Expert Review" as = specified in [RFC8126]. Designated Expert(s) will assign jurisdiction codes based on the = following principles: " If you think that such changes are sufficient, we are going to produce the draft v. 13 and upload it in the ietf versioning service. Thanks! Best regards Pierluigi and Enrico --------------------------------------------------------- Enrico Francesconi ITTIG - CNR Institute of Legal Information Theory and Techniques Italian National Research Council Via de' Barucci 20 50127 Florence Italy Tel: +39-055-4399-665 Fax: +39-055-4399-605 email: francesconi@ittig.cnr.it --------------------------------------------------------- > On 01 mag 2018, at 02:38, Dale R. Worley wrote: >=20 > My apologies for not working on this earlier. >=20 > The current draft of "urn-lex" is draft-spinosa-urn-lex-12. People = have > criticized its proposed URN system in many ways, but it seems to me = that > most of the criticisms are "bibliographic", they concern good ways to > create identifiers for written works. As such, the IETF is not a good > forum for correcting most of those problems. >=20 > My proposal is that we implement "rough consensus and running code" -- > obtain a usable registration of the "lex" URN namespace so that the > authors and ITTIG can put the "lex" URNs into practice. The process = of > using the URNs will educate the authors regarding the correct = resolution > of the various problems, and will likely cause them to later submit a > revised registration. >=20 > That is, the registration we create at this time will be understood to > be experimental in nature. >=20 > In order to be suitable as an "experimental" registration, there are a > few problems that must be resolved: >=20 > 1. The URN syntax must conform to the generic URN syntax. >=20 > 2. The requirements of uniqueness and persistence must be met. (That > is, any URN designates at most one resource, and the resource that it > designates must not change over time. However, it is permissible to > have multiple URNs designate the same resource.) >=20 > 3. The process or authority that assigns each URN must be = well-defined. >=20 > Item 1 is taken care of, in that the syntax in -12 conforms (as far as = I > can tell) to the URN syntax in RFC 8141. >=20 > Item 2 is the responsibility of the Jurisdictional Registrars, in the > same way that the naming authorities of many other URN namespaces are > responsible for uniqueness and persistence. >=20 > Item 3 requires that a registry of jurisdiction codes and = Jurisdictional > Registrars be maintained. Section 11.2 of the -12 draft proposes that > IANA maintain the registry. Given the experimental nature of the URN > registration, it seems to me to be premature to involve IANA, = especially > since the principles that the Designated Export must implement are > likely to change over time. Instead, it seems to me that the best > choice for registrar is ITTIG-CNR, the proposer and developer of the = URN > namespace. >=20 > When the namespace definition is transitioned to a non-experimental > status (including fixing a good set of policies to assign jurisdiction > codes), the registry can be transferred to IANA to implement the = proven > policies. >=20 > Following this path requires only small changes for -13, viz., = updating > section 11.2. >=20 > Dale > ---------------------------------------------------------------------- > Archived discussions: >=20 > https://www.ietf.org/mail-archive/web/urn/current/msg03828.html > 16 Nov 2017 > "urn:lex draft v. 12" >=20 > https://www.ietf.org/mail-archive/web/urn/current/msg03811.html > starting 20 Sep 2017 > "Request for new URN namespace review: LEX" > Message-Id: = <1505909590.1544977.1112321704.5FEB92F9@webmail.messagingengine.com> >=20 > https://www.ietf.org/mail-archive/web/urn-nid/current/msg01270.html > starting 29 Apr 2014 > "Publication request for draft-spinosa-urn-lex" > Message-Id: = >=20 > https://www.ietf.org/mail-archive/web/urn-nid/current/msg01204.html > starting 27 Mar 2013 > "Application for a formal URN NID" > Message-Id: <23A64284-6B03-4B24-B680-54A61E96BECA at ittig.cnr.it> >=20 > https://www.ietf.org/mail-archive/web/urn-nid/current/msg01059.html > 15 Oct 2009 > "URN LEX Namespace submission" --Apple-Mail=_D54EB501-EDF6-4FEB-AB16-ED37D3A57F0C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear Dale,
   thanks = for your message and to the colleagues who approved your proposal to = move ahead with urn-lex registration. 

As for the issue you raised about the maintenance of the = registry of jurisdiction codes, we agree at this stage to be = ITTIG-CNR the
Registrar. In this respect we propose = the following changes:

Section 3.1

"However, a special register for the = <jurisdiction-code>, maintained
by IANA, is = required, the rules of which are defined in section 11.2."
=E2=80=94>
"However, a special register for = the <jurisdiction-code> is required,
the rules of = which are defined in section 11.2."

[...]

Section 11.2

"IANA = is requested to create a new registry for <jurisdiction-code>,
with the following format:"
=E2=80=94>
"It is requested to create a new registry for = <jurisdiction-code>,
with the following format:"

[...]

"un.org"; "United Nations"; "DPI, = United Nations, <address>, <contact>"; [reference]
=E2=80=94> 
"un.org"; "United Nations"; "DPI, United Nations, = <address>, <contact>"; [reference]
In the = current experimental LEX registration phase, ITTIG-CNR will take = care to create and maintain the registry for = <jurisdiction-code>.
As the criteria of the LEX = names assignment will be consolidated, after the experimental phase = such registry will be maintained by
IANA.
The adopted registration policy is compliant with the "Expert Review" as specified = in [RFC8126].
Designated Expert(s) will assign = jurisdiction codes based on the following principles: "




If = you think that such changes are sufficient, we are going to produce
the draft v. 13 and upload it in the ietf versioning = service.

Thanks!
Best = regards
   Pierluigi and Enrico


---------------------------------------------------------
Enrico Francesconi
ITTIG - CNR
Institute of Legal Information Theory and Techniques
Italian National Research Council

Via de' Barucci 20
50127 Florence
Italy

Tel: +39-055-4399-665
Fax: +39-055-4399-605
email: francesconi@ittig.cnr.it
---------------------------------------------------------
=

On 01 mag 2018, at 02:38, Dale R. Worley <worley@ariadne.com> = wrote:

My apologies for not working on this earlier.
The current draft of "urn-lex" is draft-spinosa-urn-lex-12. =  People have
criticized its proposed URN system in = many ways, but it seems to me that
most of the criticisms = are "bibliographic", they concern good ways to
create = identifiers for written works.  As such, the IETF is not a good
forum for correcting most of those problems.

My proposal is that we implement "rough consensus and running = code" --
obtain a usable registration of the "lex" URN = namespace so that the
authors and ITTIG can put the "lex" = URNs into practice.  The process of
using the URNs = will educate the authors regarding the correct resolution
of= the various problems, and will likely cause them to later submit a
revised registration.

That is, = the registration we create at this time will be understood to
be experimental in nature.

In = order to be suitable as an "experimental" registration, there are a
few problems that must be resolved:

1. The URN syntax must conform to the generic URN syntax.

2. The requirements of uniqueness and = persistence must be met.  (That
is, any URN = designates at most one resource, and the resource that it
designates must not change over time.  However, it is = permissible to
have multiple URNs designate the same = resource.)

3. The process or authority that = assigns each URN must be well-defined.

Item = 1 is taken care of, in that the syntax in -12 conforms (as far as I
can tell) to the URN syntax in RFC 8141.

Item 2 is the responsibility of the Jurisdictional = Registrars, in the
same way that the naming authorities of = many other URN namespaces are
responsible for uniqueness = and persistence.

Item 3 requires that a = registry of jurisdiction codes and Jurisdictional
Registrars= be maintained.  Section 11.2 of the -12 draft proposes that
IANA maintain the registry.  Given the experimental = nature of the URN
registration, it seems to me to be = premature to involve IANA, especially
since the principles = that the Designated Export must implement are
likely to = change over time.  Instead, it seems to me that the best
choice for registrar is ITTIG-CNR, the proposer and developer = of the URN
namespace.

When = the namespace definition is transitioned to a non-experimental
status (including fixing a good set of policies to assign = jurisdiction
codes), the registry can be transferred to = IANA to implement the proven
policies.

Following this path requires only small changes for -13, = viz., updating
section 11.2.

Dale
---------------------------------------------------------------= -------
Archived discussions:

https://www.ietf.org/mail-archive/web/urn/current/msg03828.html=
16 Nov 2017
"urn:lex draft v. 12"

https://www.ietf.org/mail-archive/web/urn/current/msg03811.html=
starting 20 Sep 2017
"Request for new URN = namespace review: LEX"
Message-Id: = <1505909590.1544977.1112321704.5FEB92F9@webmail.messagingengine.com>=

https://www.ietf.org/mail-archive/web/urn-nid/current/msg01270.= html
starting 29 Apr 2014
"Publication = request for draft-spinosa-urn-lex"
Message-Id: = <CALaySJJk5YiCQZqt6WoWkqfAzi2A04HEAH=3DvG0pVAy8e45N5aQ@mail.gmail.com&g= t;

https://www.ietf.org/mail-archive/web/urn-nid/current/msg01204.= html
starting 27 Mar 2013
"Application for a = formal URN NID"
Message-Id: = <23A64284-6B03-4B24-B680-54A61E96BECA at ittig.cnr.it>

https://www.ietf.org/mail-archive/web/urn-nid/current/msg01059.= html
15 Oct 2009
"URN LEX Namespace = submission"

= --Apple-Mail=_D54EB501-EDF6-4FEB-AB16-ED37D3A57F0C-- From nobody Wed Jun 6 08:12:31 2018 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB457130E2E for ; Tue, 5 Jun 2018 19:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no 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 0lnqvR2GV_-x for ; Tue, 5 Jun 2018 19:28:34 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C00A0130E2D for ; Tue, 5 Jun 2018 19:28:34 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-09v.sys.comcast.net with ESMTP id QLTJf6ZPLqmKNQOBdfvhTF; Wed, 06 Jun 2018 02:28:34 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-18v.sys.comcast.net with ESMTPA id QOBYfJtyfEY3qQOBZffZkE; Wed, 06 Jun 2018 02:28:31 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id w562SRUN029017; Tue, 5 Jun 2018 22:28:27 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w562SOEh029008; Tue, 5 Jun 2018 22:28:24 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Enrico Francesconi Cc: pierluigi.spinosa@gmail.com, caterina.lupo@gmail.com, urn@ietf.org, aamelnikov@fastmail.fm, barryleiba@computer.org, stpeter@stpeter.im, john-ietf@jck.com, L.Svensson@dnb.de, juha.hakala@helsinki.fi In-Reply-To: <921B7656-86DB-471A-9085-91381725D2BC@ittig.cnr.it> (francesconi@ittig.cnr.it) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 05 Jun 2018 22:28:24 -0400 Message-ID: <87602wk5rr.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfGYW7BmjIQC5xfgdgqz3RPL/ffpMcd7bZKevPQSRL1/XvHuOyI3HdpnP4sJn1BzdDje3blKFr07s1IrfZRddvZR4WTvlUICBUTgHv0pwalhV6L3GGqlF 8I/rBWRqdAyae4AwoKziPHrp5OOT8FIDy2VUnIhZi5F3xTj7DX5qCf6WEDUmeJ0Wrx/KRlUiHYsC8nXmEIN3GyZZwMwhojIhyCuQu9w2ZlD9UeQnqRAIvYGM hIAvQ6K7kb2XB6VkI1m8mvjQcXcMTqKrvmM/QLbFXS6wu/LkOMM2eIAmPCCtyGngUdbtke8im430AF2kFmezFEXshcXIJ3g5GrfvhEK7YecO5vagh8TwXAO1 Fh2XbMQUJ2ibUGmopw+BDbBMQwYnlNBp9vkJs90gKa0Ra4A5VDeL5MgVJ1c+T+uWjrHWdG4NcIL3CLDi4H0if0rrpwKc8UTctDHWmn8FhscDk8bRN9Oaj5Ar o6atgcJ+Byy4m9EWEaD1ZpJXXavq/Gg7XmxS5viUf+5wS7QyHoeff9k4MphV5UxSczESehilEE6LyO5I Archived-At: X-Mailman-Approved-At: Wed, 06 Jun 2018 08:12:30 -0700 Subject: Re: [urn] Moving ahead with draft-spinosa-urn-lex X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 02:28:36 -0000 Enrico Francesconi writes: > As for the issue you raised about the maintenance of the registry of > jurisdiction codes, we agree at this stage to be ITTIG-CNR the > Registrar. In this respect we propose the following changes: The changes you propose seem satisfactory to me. Dale From nobody Wed Jun 6 09:38:46 2018 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54B1130F72 for ; Wed, 6 Jun 2018 09:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 Ru76nrHy3axt for ; Wed, 6 Jun 2018 09:05:29 -0700 (PDT) Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com [209.85.215.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 122CB130F6F for ; Wed, 6 Jun 2018 09:05:29 -0700 (PDT) Received: by mail-lf0-f44.google.com with SMTP id u4-v6so9969405lff.3 for ; Wed, 06 Jun 2018 09:05:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bKvUoHuaWx7DvVKeTCZLpnzJ/Q+q4WXf6Xs0HII46Vs=; b=KP3vTJX3WDm7t2D1qO+eGCSBONZajNIMQBcIBJ0CJYZTmfjcbx9sJwXT8BJjcZXFm9 DJHAqI58AJrlKEwaLOLhTiaFr3nz0mIaP86PfamiaCKftiU2GrY83g/5ak8090yhPdyx +ipVIa+vG3s0xWJiOQx6R5ItsG3BpURWz74I3pcKR61VtSdB6LEJsTmMTmHkUjGLQlvt Q3AZU7O5MdjHJ4LDAXKUMuQcxQsxLFBYuRJ9PeLFLV4IgAk/oNfIJqiKEwxgz71naI7W Tasjecq13Hsvg5a16iaYUd7I/qBUzq6hOisYW+SwDS6ReMRnMuOpRZ8DSlgrOla1oyAp 2/rg== X-Gm-Message-State: APt69E1TvD2MehpryAfyqex7qJpKvjk8+dUDL8Fe7ieczUQhrefk3RzF yOiIIBN7vp44BwOw4RqdL+dvLIrhg3X/H7cMa78= X-Google-Smtp-Source: ADUXVKINw288z4/nQXAenTznsmRrGo4srHQT0cy0Tks75z6YTO0YIhKxWwBvdceQJuH590wJjxy5h7Tw3d5eoZhHCXI= X-Received: by 2002:a19:a68a:: with SMTP id p132-v6mr2194836lfe.89.1528301127102; Wed, 06 Jun 2018 09:05:27 -0700 (PDT) MIME-Version: 1.0 References: <921B7656-86DB-471A-9085-91381725D2BC@ittig.cnr.it> <87602wk5rr.fsf@hobgoblin.ariadne.com> In-Reply-To: <87602wk5rr.fsf@hobgoblin.ariadne.com> From: Enrico Francesconi Date: Wed, 6 Jun 2018 18:05:14 +0200 Message-ID: To: "Dale R. Worley" Cc: Pierluigi Spinosa , LUPO Caterina , urn@ietf.org, aamelnikov@fastmail.fm, barryleiba@computer.org, stpeter@stpeter.im, john-ietf@jck.com, L.Svensson@dnb.de, juha.hakala@helsinki.fi Content-Type: multipart/alternative; boundary="000000000000ca76ce056dfb554f" Archived-At: X-Mailman-Approved-At: Wed, 06 Jun 2018 09:38:41 -0700 Subject: Re: [urn] Moving ahead with draft-spinosa-urn-lex X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 16:05:31 -0000 --000000000000ca76ce056dfb554f Content-Type: text/plain; charset="UTF-8" Dear Dale, this is just to inform you and the other colleagues that we have uploaded a new version (v. 13) of the urn:lex specifications. Thanks to all of you for the fruitful collaboration. Best regards Pierluigi and Enrico Il mer 6 giu 2018, 04:31 Dale R. Worley ha scritto: > Enrico Francesconi writes: > > As for the issue you raised about the maintenance of the registry of > > jurisdiction codes, we agree at this stage to be ITTIG-CNR the > > Registrar. In this respect we propose the following changes: > > The changes you propose seem satisfactory to me. > > Dale > --000000000000ca76ce056dfb554f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Dale,
=C2=A0 =C2=A0this is jus= t to inform you and the other colleagues that we have uploaded a new versio= n (v. 13) of the urn:lex specifications.
Thanks to a= ll of you for the fruitful collaboration.

=
Best regards
=C2=A0 Pierluigi and = Enrico


Il mer 6 gi= u 2018, 04:31 Dale R. Worley <worl= ey@ariadne.com> ha scritto:
= Enrico Francesconi <francesconi@ittig.cnr.it> writes:
> As for the issue you raised about the maintenance of the registry of > jurisdiction codes, we agree at this stage to be ITTIG-CNR the
> Registrar. In this respect we propose the following changes:

The changes you propose seem satisfactory to me.

Dale
--000000000000ca76ce056dfb554f-- From nobody Thu Jun 7 09:59:07 2018 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89FA9130F73 for ; Thu, 7 Jun 2018 09:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com 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 FEqc5HyxuuuY for ; Thu, 7 Jun 2018 09:59:00 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 714B0130F5E for ; Thu, 7 Jun 2018 09:59:00 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id g22-v6so12628587iob.7 for ; Thu, 07 Jun 2018 09:59:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=to:cc:from:subject:openpgp:autocrypt:message-id:date:user-agent :mime-version; bh=M/Ivowcn4BGZszSPmmAhvr1GkpkHXi+0sUu8JBZww+I=; b=fOz8jSWR4V6qy+YKJaozxZhyWQoF3FK/MbjOdsCVY6Vv7Z50dqIlC6SkGrhq9fAMSl TTlc+ozqH8NT3/bL5NBZRC/CD0bb63USFBEDLUVdtVRuipQL2wGgxKRNyMZrJv1Z52Wn RKu3kvsxejXsGIAwf1SokUcK/kPMXP+BRAIJ8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:openpgp:autocrypt:message-id :date:user-agent:mime-version; bh=M/Ivowcn4BGZszSPmmAhvr1GkpkHXi+0sUu8JBZww+I=; b=dQbqUH0eqxEiibbee6sM8WwgbyuoTzGTiFtf2q9jf1Mxibo6t+8VqyfvBi8gaqwbbG O0V/kMCCSUvN6f8WYNZJoHzQR00O1G0k4Eq3o0PDJIiGGR+Na2wYTVh+Lrjy/qohgorM eb9XBpuALx9JUybICk8jMUU5TugrS/LJ2U5iASnn6JhNsZ9Q4655oGdjdbv6NVCKbFQd hllzc2LHYQeiDVDS65G8UB2WyhBPVRJfgY1Kkj7NmGhuRYkmdHOo2Do3ylrglEZk/Kch a5dZs5MeySkeuCG34a1lZX057KnxRuFr5B+fAOb+XKt2k6BTIUOzkSW14xi4YGU23FUV wXLQ== X-Gm-Message-State: APt69E2T6lQdnnO0hQhvk/wTnfqIhyBr9sgS/WJsgBce22zRDQQMsCtl O3nRPL9snBc3JsH14qgb+uXcAkgtNpE= X-Google-Smtp-Source: ADUXVKJ6OSlCjhZx6xVAtffCjAgb89PoD3X+38o5eUrdz7MgRTywhUf5RprTuKa2YwG2LOps17qCLA== X-Received: by 2002:a6b:cf19:: with SMTP id o25-v6mr2187232ioa.281.1528390739889; Thu, 07 Jun 2018 09:58:59 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id x16-v6sm899652ith.6.2018.06.07.09.58.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jun 2018 09:58:59 -0700 (PDT) To: "urn@ietf.org" Cc: ibagdona@gmail.com, draft-mahesh-etsi-urn@ietf.org From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: <6aa1f7c2-8073-a2fd-1862-6f26266be823@mozilla.com> Date: Thu, 7 Jun 2018 10:58:58 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GlFxDZ2cTUgwhWQna7VexolbaQ6BB3lWh" Archived-At: Subject: [urn] URN expert review of 'etsi' NID X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 16:59:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GlFxDZ2cTUgwhWQna7VexolbaQ6BB3lWh Content-Type: multipart/mixed; boundary="CR24xdO8k8d5GhnixMWfZapxnL493C1kT"; protected-headers="v1" From: Peter Saint-Andre To: "urn@ietf.org" Cc: ibagdona@gmail.com, draft-mahesh-etsi-urn@ietf.org Message-ID: <6aa1f7c2-8073-a2fd-1862-6f26266be823@mozilla.com> Subject: URN expert review of 'etsi' NID --CR24xdO8k8d5GhnixMWfZapxnL493C1kT Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hello Expert Reviewers & others, I just noticed that draft-mahesh-etsi-urn requests a URN NID for 'etsi' to identify resources published by European Telecommunications Standards Institute: https://datatracker.ietf.org/doc/draft-mahesh-etsi-urn/ Although it's not clear which IESG telechat this is on (the responsible AD, Ignas Bagdonas, can tell us), let's make sure to review it in a timely fashion. Thanks! Peter --CR24xdO8k8d5GhnixMWfZapxnL493C1kT-- --GlFxDZ2cTUgwhWQna7VexolbaQ6BB3lWh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlsZZFIACgkQZWGMGH9o FKmcJQ/8C/Zp6lqnBpj3u79I6x42QOqE2N0iTe+7ugOa4QWJ3cGQW8rWweY4i76q xN2ngui6QtxjAD6Bc/zNNkndFjY1m+LIpb1V7cZZ0bbs0DSPlKWIhy2r3Oc5sk7K kWMsf556gpSBOZBav9vojJKt64j7Kf7d2XpYhMzR4HTGR3gX2Oc4JYw9H/pyFXtn Ja+rlJWJUhH8fyCOhePif5wybjj2DRlIfh+MDERCbHtijVsYKSwmYw9nuBzRYhvL wIyTeyyVoGZ4nyRQmzTSUeetW4xJKslY/Arx9Evq4gKti0prQbLn9TJRvLg//yzQ CEprolMzwM2xa59MLiDJsbCQpGrGJZ5IJvgiIBsBQJFNIuGtbf1UmrNZhRGvg1Je rsgiPbCpuYnNAsYStowhgJlIV4nm5frz4Er3T7+OV6qWkTWqaGS0PFa8FK4o5kvn sR/YsvnWqrr1nobIZoJKkSDHbv3yWGbKLatzFjg8qHBhp2ih3P1EB4WICM2ALDrB P84GEy8s255nmhuW6yqaR0O7rlPof5CrkbHbEmM2GUsqyk0bTfkUxS82ENkBdC5H 7v3GuIuskfRQPpt3We5b91bJa601imczsVKpuf3Vr9csKkuYtn028QY/X9o5CJ8n 0jcGTCkexO5pAR/fCcN8Y5/Bt0pmMj/ftzyOdI6mV7Cc9Kn3dWU= =+lPP -----END PGP SIGNATURE----- --GlFxDZ2cTUgwhWQna7VexolbaQ6BB3lWh-- From nobody Thu Jun 7 13:02:37 2018 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477D412F295 for ; Thu, 7 Jun 2018 13:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com 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 jAazEbZn_vpe for ; Thu, 7 Jun 2018 13:02:26 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37FBB12F1A5 for ; Thu, 7 Jun 2018 13:02:26 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id d22-v6so13241626iof.13 for ; Thu, 07 Jun 2018 13:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=WcHvLm5mPoE9Jxi0BoapFWY1A3qgFBVd4DBnUd776h8=; b=J2nvznbfZPZfUfAbEifO0TFq8Pt/47qinU8Lw+3B2cVK+8vXoqeAXD4cvR0AdlkfIi trnePilgsCLwx216BkAJtZewgbLgi4Zsjt+vMW0JD2aXKaU/NwCQyGnTLzUdLKDYAyoM tdRzLkB9h9ctamqI0LMdQ8uH4CtGWg58LWmBk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=WcHvLm5mPoE9Jxi0BoapFWY1A3qgFBVd4DBnUd776h8=; b=ZwHyq7n8B5178QFiW394G1EwN5oVCoJQCOuXWlx6/SGG2DiDgAVAxOVQfYrDm/YYvb QRbvtt7wpuz7JLWn4hc7NK5h9zKLpjx/GqEbQC0IFiqTDEPEZDBwmdvMTJQtt/EOaDB1 aDq9d8sSxj5oYpeAM1Jon2vrIi6OLuRZo7U/F3x9VfNn0qbne6qMm34wWftDLDndavx1 HhJuNQKBoj2fxRupZxcfrMvnOeEptLwZoVuchohSuoQFsbauUuupHAFxP7sxm5obnciZ UOE8xGdpkZ86INn8i39bgtQ2w+wMPtJ4XH1X68xP+Driko96Sa0VoodFn6eiIbXWKxBZ CI2A== X-Gm-Message-State: APt69E2cfMLitpdMsKXJHis4sq0tW7iQ0vxjb0A/M3Na9XYdycMDdhG/ 3dj6BU8ed4XpPWG1EcYKzikvXg== X-Google-Smtp-Source: ADUXVKInJmrZScAFcPfonHH8EMzhFRm8Yuzrz0MeUswmFP8vixSYqRlMDQPPOYuFqxMiFqumeZlg9Q== X-Received: by 2002:a6b:4a19:: with SMTP id w25-v6mr2831418iob.25.1528401745425; Thu, 07 Jun 2018 13:02:25 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id k19-v6sm1402460itb.35.2018.06.07.13.02.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jun 2018 13:02:24 -0700 (PDT) To: Benjamin Kaduk , The IESG Cc: draft-hakala-urn-nbn-rfc3188bis@ietf.org, "urn@ietf.org" References: <152837409539.30768.4568779645299135020.idtracker@ietfa.amsl.com> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: <6a1a100c-3bc0-76d3-3ae4-047d37906bfc@mozilla.com> Date: Thu, 7 Jun 2018 14:02:23 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <152837409539.30768.4568779645299135020.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="prnAVb0UtUcfWLw8tHWYtPhc0f2bp1iJ1" Archived-At: Subject: Re: [urn] Benjamin Kaduk's Discuss on draft-hakala-urn-nbn-rfc3188bis-01: (with DISCUSS and COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 20:02:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --prnAVb0UtUcfWLw8tHWYtPhc0f2bp1iJ1 Content-Type: multipart/mixed; boundary="CnDHYb5YSgR7rJ1LREPIGxd3bX4YfhbiH"; protected-headers="v1" From: Peter Saint-Andre To: Benjamin Kaduk , The IESG Cc: draft-hakala-urn-nbn-rfc3188bis@ietf.org, "urn@ietf.org" Message-ID: <6a1a100c-3bc0-76d3-3ae4-047d37906bfc@mozilla.com> Subject: Re: Benjamin Kaduk's Discuss on draft-hakala-urn-nbn-rfc3188bis-01: (with DISCUSS and COMMENT) References: <152837409539.30768.4568779645299135020.idtracker@ietfa.amsl.com> In-Reply-To: <152837409539.30768.4568779645299135020.idtracker@ietfa.amsl.com> --CnDHYb5YSgR7rJ1LREPIGxd3bX4YfhbiH Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable [ + cc urn@ietf.org for broader discussion ] Document shepherd here. I expect the document author (and perhaps my co-author on RFC 8141) to provide further thoughts. On 6/7/18 6:21 AM, Benjamin Kaduk wrote: > Benjamin Kaduk has entered the following ballot position for > draft-hakala-urn-nbn-rfc3188bis-01: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this= > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-hakala-urn-nbn-rfc3188bis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I think this document may benefit from an Internationalization > Considerations sections, but am not entirely sure how needed it is. > So let's discuss it... >=20 > In particular, the URN:NBN lexical equivalence rules include several > case-insensitive comparisons, for the prefix and for the case of the > hex digits in any percent-encoded values, but do not specify any > operation on the decoded percent-encoded values/characters.=20 As a reminder, RFC 8141 does state: In particular, with regard to characters outside the ASCII range, URNs that appear in protocols or that are passed between systems MUST use only Unicode characters encoded in UTF-8 and further encoded as required by RFC 3986. To the extent feasible and consistent with the requirements of names defined and standardized elsewhere, as well as the principles discussed in Section 1.2, the characters used to represent names SHOULD be restricted to either ASCII letters and digits or to the characters and syntax of some widely used models such as those of Internationalizing Domain Names in Applications (IDNA) [RFC5890], Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS) [RFC7613], or the Unicode Identifier and Pattern Syntax specification [UAX31]. In order to make URNs as stable and persistent as possible when protocols evolve and the environment around them changes, URN namespaces SHOULD NOT allow characters outside the ASCII range [RFC20] unless the nature of the particular URN namespace makes such characters necessary. By my reading of draft-hakala-urn-nbn-rfc3188bis and RFC 8141, the allowable case-sensitivity for nbn_string constructs generated by a national library applies to the percent-encoded string because that is where any comparison or equivalence-matching would occur for these identifiers. Venturing into case matching of percent-decoded strings would (IMHO) unnecessarily open up an ugly can of worms. > In many > (perhaps even most?) cases, ignoring such encoded characters for > purposes of case-insensitive comparison is the wrong thing to do, > but if I understand correctly, it actually is the correct thing to > do in this case. Namely, a NBN (or URN:NBN), once assigned, is > essentially static data and consumers of it should not attempt to > perform modification, Unicode normalization, etc. on it -- that > would potentially change what is being identified (or render the > identifier invalid).=20 Well, Unicode normalization would be used as part of equivalence operations (as in IDNA or PRECIS), but in general you are right about modification. These are identifiers or even numbers, not malleable string= s. > On the other hand, a national library or > delegated institution that is assigning NBNs may wish to take into > account Unicode normalization rules and other similar considerations > while assigning NBNs (in particular, the nbn_string component), as > part of their allocation policy.=20 It could, but as far as I know none of the national libraries have yet gone down that path or seen the need to. Juha can tell us if I'm wrong. > Because these can be subtle, it > may be worth explicitly pointing out the potential issues for > registration authorities.=20 "There be dragons and don't go there" seems like fine advice. > That, plus the directive to consumers to > not normalize, seems like it would be appropriate content for an > Internationalization Considerations section. By "normalize" you mean perform equivalence matching of percent-decoded strings (of which Unicode normalization might be one step), right? Here again I think the answer is "don't do that" because it's equivalence matching is done on the percent-encoded strings. > Separately, in Section 4.2.1 where we cover 4-components, I noted > that RFC 8141 rather discourages actually using r-components until > their semantics are standardized. The text here seems to be giving > free reign for national libraries to assign their own semantics > without any coordination with a broader community.=20 Juha and perhaps John can clarify, but as I understand it the scope of a URN resolver for NBNs would likely be within a particular national library system, not even necessarily across all national libraries (this is how things are deployed now in the absence of URN resolution, in any case). > Do we really > want to advocate for this, as opposed to attempting to get broadly > unified semantics for r-components Internet-wide? (Perhaps we > already have and I just missed it; if so, a reference here would be > appropriate.) The semantics of r-components are yet to be defined. I would venture that the IETF is probably not the right place to do that work, given how little energy remained in the URN WG at the end (and we probably didn't have the right people in the room in the first place). > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I'm a little confused on some of the places in the text that talk > about URN:NBNs being "generated from" NBNs (and non-reuse > thereafter) or restrictions on URN:NBN assignment (e.g., > uniqueness). The procedure seems to be basically deterministic for > creating a URN:NBN once an NBN is assigned, and potentially > something that could be done by any party in possession of the NBN > (i.e., not necessarily the registration authority that created the > NBN). So I'm not sure why the act of generating the URN:NBN has any > significance, if anyone could do it -- the restrictions would need > to apply at NBN assignment time in order to be useful. (This kind > of gets into Ben's DISCUSS point, too, in the sense that we can only > say what prerequisites there are for national library NBN allocation > policies in order for them to be useful with URN:NBN, but they can > in principle do whatever they like and choose to not use URN:NBN.) Yes, the process of creating a URN from an NBN is trivial (modulo potentially interesting encoding of non-ASCII characters). I think the point of the text is that an NBN URN is not exactly the same as an NBN. Perhaps that could be worded more clearly. > Section 3.2 >=20 > From the library community point of view it is important that the > f-component is not a part of the NSS and therefore f-component > attachment does not mean that the relevant component part is > identified. Moreover, the resolution process still retrieves the > entire resource even if there is an f-component. The fragment > selection is applied by the resolution client (e.g., browser) to the= > media returned by the resolution process. In other words, in this > latter case the fragments are logical and physical components of the= > identified resource whereas in the former cases these "fragments" ar= e > actually complete, independently named entities. >=20 > I'm not sure I'm understanding this correctly -- is the "former > case" the thing that libraries should not do, namely, including the > f-component in the NSS? Now that you point it out, I'm not sure what the former case is. Formally speaking the f-component simply is not part of the NSS, see the ABNF in RFC 8141. > If an NBN identifies a work, descriptive metadata about the work > SHOULD be supplied. The metadata record MAY contain links to > Internet-accessible digital manifestations of the work. >=20 > This left me confused. Is it only intended to apply in the case > described in the previous paragraph, where the resource identified > by the NBN is not available in the Internet? Or does it always > apply, forcing the metadata to take precedence over delivering the > actual work? (Or maybe I'm just confused, and there's an easy way > to deliver both metadata and the actual work alongside each other > with no ambiguity.) Juha can clarify this. > Section 4.1 >=20 > National Bibliography Number (NBN) is a generic term referring to a > group of identifier systems administered by the national libraries > and institutions authorized by them. >=20 > "the national libraries" implies a specific set -- which ones? It > may be better to hedge with "some national libraries". Or remove "the" ... "by national libraries". > Section 4.2.2 >=20 > Do we need to say anything about a URN-to-URI step before talking > about URI-to-resource services? >=20 > I'm also wondering about any relationship between "component > resource" NBNs and f-components of the containing work. If there is > are NBNs assigned to both an image within a work and that containing > work, and an NBN with f-resource is used to refer to the image > within the containing work, is there any relationship between the > f-resource and the image-specific NBN? >=20 > Section 4.3 >=20 > Expressing NBNs as URNs is usually straightforward, as only ASCII > characters are allowed in NBN strings. If necessary, NBNs MUST be > translated into canonical form as specified in RFC 8141. >=20 > When is it necessary? It seems that in theory an NBN itself could contain non-ASCII characters, whereas an NBN URN and its nbn_string construct can contain only ASCII characters. At least that is my understanding. > Being part of the prefix, sub-namespace identifier strings are case-= > insensitive. They MUST NOT contain any hyphens. >=20 > This MUST seems to just duplicate a syntactic requirement from the > ABNF; is RFC 2119 language really necessary? /me shrugs > Section 8 >=20 > John Klensin provided significant editorial and advisory support for= > late versions of the draft. >=20 > Presumably that's "later versions"? Yes. Peter --CnDHYb5YSgR7rJ1LREPIGxd3bX4YfhbiH-- --prnAVb0UtUcfWLw8tHWYtPhc0f2bp1iJ1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlsZj08ACgkQZWGMGH9o FKm66Q/+KUMfScqzI/1ou0izNQfKEMtrLJB23IlLCM660enT/ZoqU7XPeHTZKqhw fprdpiJQgoZmLlzHPfcQCuXlxf7+OoASBLzxSrCJrIBItqqDdhwueZpOr1JcyYd4 c6Asq15uTFneymskecsDOCXUHhtDpnp2hF1wLHXHqHhSf7OMudRmYN3TQJaU5PDi XtGU4ziFTnB7VCIpD0ZJXDXOnBFCNL+1bvzgN2tSuljH6b+A7ysdSiNP06/a6Zk+ ZlbVt0DyCGNv5uhMx4+Rj1MNcB+bxBopgT/3dq9L8JPidbw+Bpu/npy5NjkaYNiB 1QrvioEGwypCNEiHT04xBol+fHpYUncvi18FxC9hkyqVWZDqZCaCdlkUFXFoqlTu 0h3jZ4bAYLG3D8hwptJ3x1ZrsIb6Nidr3zWX0nbPgONW5/O6i6BvcShmchFh8xUs RPjalEOMCod8yMWReuyg9dfviJacDHHkFOCLs5oLcVqFlNGW928nBBh9zVjqgT21 igW7xSnF+nuah0+H2pezPnRDorR4ov0gTgEXfSibAZcJmUC74Y0e3vmIpDukq0/+ NJtTOjhkfM1qapkmpwIqw3Z2ppBCccPp96DjspjAvrdLLFstgchEntwWNAoPxv0/ ts/OQppm3AWb3FtZSHPjqWvdceovpDpxaxZ+Wg3/3YTLOsisBss= =i2Gh -----END PGP SIGNATURE----- --prnAVb0UtUcfWLw8tHWYtPhc0f2bp1iJ1-- From nobody Thu Jun 7 13:22:19 2018 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B11D130D7A for ; Thu, 7 Jun 2018 13:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com 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 x3v041EX5Pen for ; Thu, 7 Jun 2018 13:22:07 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA3B130934 for ; Thu, 7 Jun 2018 13:22:07 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id y127-v6so3236588itd.1 for ; Thu, 07 Jun 2018 13:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:from:to:cc:references:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=IPqYKRS/InJzX3STQzGfhIqpJZKQ2oaE4K9pSEyr8lM=; b=HHKGcFxJF7JQNbLkTqYJnjc1zZV+fbc0Bfp5q4pkQon37BJCJgPzFtu0ZnhV/INNPQ /bZpmKNj4s1pifnGQqje00CXrj+l5HUd6nJc/5BVnDJmtUvrmHy5i79XIr5JidTgZ2vf /eu5qBbUfR1KwZLBxRuiYczfxqNUY0muz2GpM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=IPqYKRS/InJzX3STQzGfhIqpJZKQ2oaE4K9pSEyr8lM=; b=efalLkHz5ufHpXvGxZNWerPTRCzg0LkFt1MQqUJtfRIYVVSMgChEWzyMOnOsizlgU7 huJ/gmgzxwwtJNf/eotrN3JjX91Nu8ivnnNIppTB/xgD6jeKT5asRtk2PA/A/ImO6735 rTwJLRucpCxcPKT25ot646AqNrLg62AaDw6J124lXpMwuWGJ8Y6Rr61S+RHFbWnmBnwv 8y1lMIlOo7os7/7Je4dwXJ+VWxv7U2A348JnB6oUGP5cW3fEEWEhqw1ESqunbG0J+QoR +NLe9qlI8BH6YQmrpYOQypr74ArEuAAGMFlo1557MdEneqDMOktBZNOWNIyN6eWnM4xP qDpg== X-Gm-Message-State: APt69E0Ot2axg0rL07oD0x5EXoQ48YwfoqMIeSTW6snvDMdsP/rXNMGF llqkv/56pW5K/XsDVQ2JuqoUTg== X-Google-Smtp-Source: ADUXVKIPHS/gS+mRlu1e5TGLKlFZeg0+vdmzaeAFirpXyaFV6ZjRTYq3XRGsDmew8lLOTfSGaJSmyg== X-Received: by 2002:a24:5901:: with SMTP id p1-v6mr3204702itb.119.1528402927137; Thu, 07 Jun 2018 13:22:07 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id k16-v6sm4009352iog.45.2018.06.07.13.22.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jun 2018 13:22:06 -0700 (PDT) From: Peter Saint-Andre To: "urn@ietf.org" Cc: ibagdona@gmail.com, draft-mahesh-etsi-urn@ietf.org References: <6aa1f7c2-8073-a2fd-1862-6f26266be823@mozilla.com> Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: <83796945-3f77-f1a2-fba6-8aac62630bf5@mozilla.com> Date: Thu, 7 Jun 2018 14:22:05 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <6aa1f7c2-8073-a2fd-1862-6f26266be823@mozilla.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IxssG5K2JEKEnvW1wavaCayG3nXXXnuvS" Archived-At: Subject: Re: [urn] URN expert review of 'etsi' NID X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 20:22:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IxssG5K2JEKEnvW1wavaCayG3nXXXnuvS Content-Type: multipart/mixed; boundary="PTzfiQkhh0M0YbND3nd9j9kQl36xVZg1c"; protected-headers="v1" From: Peter Saint-Andre To: "urn@ietf.org" Cc: ibagdona@gmail.com, draft-mahesh-etsi-urn@ietf.org Message-ID: <83796945-3f77-f1a2-fba6-8aac62630bf5@mozilla.com> Subject: Re: URN expert review of 'etsi' NID References: <6aa1f7c2-8073-a2fd-1862-6f26266be823@mozilla.com> In-Reply-To: <6aa1f7c2-8073-a2fd-1862-6f26266be823@mozilla.com> --PTzfiQkhh0M0YbND3nd9j9kQl36xVZg1c Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Upon review, I noticed a few things: 1. The registration request uses the old template from RFC 3406, not the new template from RFC 8141. IANA requires new registrations to use the new template. 2. Can you provide a slightly more detailed description of the kinds of resources these URNs will identify? 3. Can you provide a slightly more detailed description of the syntax within the NSS? Other reviewers might notice additional issues... Peter On 6/7/18 10:58 AM, Peter Saint-Andre wrote: > Hello Expert Reviewers & others, >=20 > I just noticed that draft-mahesh-etsi-urn requests a URN NID for 'etsi'= > to identify resources published by European Telecommunications Standard= s > Institute: >=20 > https://datatracker.ietf.org/doc/draft-mahesh-etsi-urn/ >=20 > Although it's not clear which IESG telechat this is on (the responsible= > AD, Ignas Bagdonas, can tell us), let's make sure to review it in a > timely fashion. >=20 > Thanks! >=20 > Peter >=20 --PTzfiQkhh0M0YbND3nd9j9kQl36xVZg1c-- --IxssG5K2JEKEnvW1wavaCayG3nXXXnuvS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlsZk+0ACgkQZWGMGH9o FKnBEg/7BK3i2D2R9kYXTbsA2RnhyTLkw2kMGEhW2sRNlMHmsgWMkPMStylT34E3 fhl+OceUA2MnNpxqO6XmVGQ6djmRgaYebo8w2u8oaRCEawfyRT3m46FY1yhU2Hsv ZCz9GtzgTj01sItiysdNrgFSQBuRJFvYGFQbHp87Df6ur5lh0pqAUX0c+kp2XHq4 0DmzXZMexNKEUB22MzP3DhDKJFilM52H5KxweuxfBFliw2Yp/8PbMYKBIceV+D/l vt8zkOyLrNFW0dFmdsxU2maszKbWGKq6jpbB214gN2zbzPpn2+wJjoObeF0R2FKC 4lPGim/Cu7DldSn9MsO4VpFT2Oc28Xf6oqNpT0h+MQr0HlHLSS5bXH5oeh42YFs9 fuqm/Rhad/OPmqRDcM0UuEPQcTWNfVFJWZqBi9gJ8bCLwEccPBTDRd1vptX7onH9 MmAracj6IyvQ2YnVMg4BzSxTfFMIcXpagaHSl8I1eXK58MZwMDhJZ74CWSpFAQWh mQakDYLVXuFrTrhmcq6urZxAo1Fxx7CK8tcyvlco2ufWWB7rjWk4qrTf48dyYRk0 n4MqSS8QVVyd3cdKZQCt+35zxedNhNghOYjjgcwZvy/x7BmvJUiImI5p4tfy8Ztd Y6K2AW5KlzFzrdBzVNGmqhlG6+J9OSxxJA3GO/UFoZTJ4Fmg5TQ= =eU8+ -----END PGP SIGNATURE----- --IxssG5K2JEKEnvW1wavaCayG3nXXXnuvS-- From nobody Thu Jun 7 13:41:01 2018 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE7C130F58; Thu, 7 Jun 2018 13:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 8lzB-Ei-ViuZ; Thu, 7 Jun 2018 13:40:53 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8EFC130DC6; Thu, 7 Jun 2018 13:40:52 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w57Keobx068860 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 7 Jun 2018 15:40:51 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Peter Saint-Andre , Benjamin Kaduk , The IESG Cc: "urn@ietf.org" , draft-hakala-urn-nbn-rfc3188bis@ietf.org References: <152837409539.30768.4568779645299135020.idtracker@ietfa.amsl.com> <6a1a100c-3bc0-76d3-3ae4-047d37906bfc@mozilla.com> From: Adam Roach Message-ID: <7161340e-014b-3740-83ed-39f4db3a30c0@nostrum.com> Date: Thu, 7 Jun 2018 15:40:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <6a1a100c-3bc0-76d3-3ae4-047d37906bfc@mozilla.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [urn] Benjamin Kaduk's Discuss on draft-hakala-urn-nbn-rfc3188bis-01: (with DISCUSS and COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 20:40:56 -0000 On 6/7/18 3:02 PM, Peter Saint-Andre wrote: > By "normalize" you mean perform equivalence matching of percent-decoded > strings (of which Unicode normalization might be one step), right? Here > again I think the answer is "don't do that" because it's equivalence > matching is done on the percent-encoded strings. I think the concern here is the translation between percent-encoded URNs on the wire and the display form that users enter into lookup forms. For example, imagine some alt-history version of a country that decided that its NBNs would take the form -. Encoded as a URN, this might look like urn:nbn:dd:roach-157. The issue, of course, is that "urn:nbn:dd:m%c3%bcller-127" doesn't match "urn:nbn:dd:mu%cc%88ller-127". So the problem doesn't occur at the level you mention; it happens somewhere between the keyboard and the network card of a querying user. That's not really this document's problem per se, but it is definitely a dragon that needs flagging. I'm not sure whether "don't do that then" is the correct advice, unless we have reason to believe that national libraries are hyper-aware of URN considerations when designing their NBN schemes. What we probably need to say is "if your national library defines an NBN that can contain percent-encoded characters higher than U+007F, then that same body needs to carefully define the canonical transformation from NBNs into URNs, including normalization forms." /a From nobody Thu Jun 7 14:28:11 2018 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59A5130F96; Thu, 7 Jun 2018 14:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 c2bHA5VQRxQf; Thu, 7 Jun 2018 14:28:04 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3444130DD6; Thu, 7 Jun 2018 14:28:03 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id d24-v6so16862673lfa.8; Thu, 07 Jun 2018 14:28:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=h4pvpVatXu3WJePKLf0ZZfhLa3tevHpjmtQ9nxnZu3w=; b=F7PnWGotfEgpWTY8POfkFFoIaKtTo7fhWTwfHeSbP3ii+5aIh1U/mKlJnhPkXELXUb K0NkXmzttgxiZFl+q5hiy9TL2JDAsxTTq9xt/b+NRWz+hcKWOepT/m0VLzOJ8flEsbHn rUsPW3zXa4iPzkM3Z7bII+ETxVWv9/Lcl2hO91IH4kx42V+qGVe14tbC0jhVsvcN0TE6 1e74jSDmY1rmJqDmNLfKZipsJVP29qHJ8oLeeryfUuTP2ip3Wiz8efRCEtbiQLIDIFvS mTmzBysNh6dgKakqsdgGrPGU5TIxxIjWRsE1ptgllv1Bm5kuHsYHIpqeD38t3kix5NXQ AZvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=h4pvpVatXu3WJePKLf0ZZfhLa3tevHpjmtQ9nxnZu3w=; b=kIuk5aMWkdJeb88IIGzA/S8+0IAflir4VnQnbVOhg3kmLoKx+i4HTbq5kZ2dy4Y0U/ 5ZVD32aNObASKLRvgor94cGREdWDnx6pwOXgorxNyv+uZGivouImRqVY/q0Bxl0DeXRt gdf4juQwyxQVRenPPWWzSxD8XS1KkAAMo6OQZKD/Ozf3Rq2t7OaD3vfvHfxVFTmTRvQe LkgnybwjROD7YtGVGqyPjT7M6y5M+d0EDy0qJdvJ/akB2+WaCKNpLvZZi66E3p0HlXLW FZ0Pwq87QX0vLKWgKdHIAkhJtj5o6PfHmIZlK7Us/UtGo1e0ZJMpsuUMaTWk5QKXpD+L ZcmQ== X-Gm-Message-State: APt69E1uPl4PFfC+ADhQBh6Su6PMTa5YYR7F6a40OZsxHCS4KH0ppflU cBsuMTAI8kUW393zdnxZfG6KrS24 X-Google-Smtp-Source: ADUXVKKriTMrBS3uq02JiBxsRzFOTQrT0kK2SO5ICaoUp39JJlzryDNXXcFpu2GTV7TqFLwRq3iy+w== X-Received: by 2002:a19:db18:: with SMTP id s24-v6mr2391169lfg.109.1528406881715; Thu, 07 Jun 2018 14:28:01 -0700 (PDT) Received: from [192.168.96.111] ([62.148.1.58]) by smtp.gmail.com with ESMTPSA id c20-v6sm3035537lji.82.2018.06.07.14.28.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jun 2018 14:28:00 -0700 (PDT) To: Peter Saint-Andre , "urn@ietf.org" Cc: draft-mahesh-etsi-urn@ietf.org References: <6aa1f7c2-8073-a2fd-1862-6f26266be823@mozilla.com> From: Ignas Bagdonas Message-ID: <9791600f-d0c9-424e-1123-0933f7273cb3@gmail.com> Date: Thu, 7 Jun 2018 22:27:59 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <6aa1f7c2-8073-a2fd-1862-6f26266be823@mozilla.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [urn] URN expert review of 'etsi' NID X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 21:28:07 -0000 Hi there, The draft is expected to go on the telechat after a 4 week last call, which practically means it will be at some time after Montreal. Thank you for looking into this. Ignas On 07/06/2018 17:58, Peter Saint-Andre wrote: > Hello Expert Reviewers & others, > > I just noticed that draft-mahesh-etsi-urn requests a URN NID for 'etsi' > to identify resources published by European Telecommunications Standards > Institute: > > https://datatracker.ietf.org/doc/draft-mahesh-etsi-urn/ > > Although it's not clear which IESG telechat this is on (the responsible > AD, Ignas Bagdonas, can tell us), let's make sure to review it in a > timely fashion. > > Thanks! > > Peter > From nobody Thu Jun 7 15:29:53 2018 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCEA13117D for ; Thu, 7 Jun 2018 15:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com 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 Wx0r_lJr9y5n for ; Thu, 7 Jun 2018 15:29:40 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D3D3131170 for ; Thu, 7 Jun 2018 15:29:36 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id l25-v6so13669151ioh.12 for ; Thu, 07 Jun 2018 15:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=eIvAiCBXxFTqvQtDziATRg6mJzVZ5arRVe1cNu3lbps=; b=ZpohBZ5WR2SXkaDpS+RE0kwCIMJk/4gqUbtOTKmw67Q6P71A/pVz6/uv5pJKAv7ERO xrkRm3vnq2LCYVtCsMNUXO6H2aN9/5IAwmtEjbmcKe98N1v5DPI81fyI+cBGma/WnLnY YH631f87q1BcsauBSrW/I8LlWcTk62/Ai64vg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=eIvAiCBXxFTqvQtDziATRg6mJzVZ5arRVe1cNu3lbps=; b=WkjhstIBR2kf2G74xfneLbp2bXCpVaAeGHHCg/lkn0E5Q1q4iv+hTf3+wCgTiDk0zl ncKw5QvhVdu/bxqaWecRzpQlM9IFTkzingIa0AMXQCJvKFx5anRsLCu8n47LkpYZ1WZ6 PnKz6VlnutIqtOxqhn90cHs2Y0yqZcMhN94L+cTDPPctlTUVtDcE2njpYWFZg0Y96ujt 4Ace9k/Sc+Sc/nf/Qd51dGFxE9RL19pX8yeHVg1psLbtOe+6Dx7eej9SX1DbCSjSQXMY r9YD9IYrwXsVxAxrOJRStEFCAMh95F0Wk1+Px+d2EbpG1GfIxAno0ZcAPE8KQCJeIeh3 K+Ig== X-Gm-Message-State: APt69E3QjQXcUjoP94POOGvVKf/fgxppLZHgNFQy9hBgcvqoDi9BVwTz 9njWOdTY1uVbla3XE9xJ+lJuR+Z33cI= X-Google-Smtp-Source: ADUXVKI7PzYRh4A823VcEfJNp9ZTJsWp7lsbJwocX9KJ4ktSjCN3upd48yIdHK69F9Squ5decxpTfQ== X-Received: by 2002:a6b:9e88:: with SMTP id h130-v6mr3358404ioe.283.1528410575610; Thu, 07 Jun 2018 15:29:35 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id z85-v6sm1483604ita.1.2018.06.07.15.29.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jun 2018 15:29:34 -0700 (PDT) To: Adam Roach , Benjamin Kaduk , The IESG Cc: "urn@ietf.org" , draft-hakala-urn-nbn-rfc3188bis@ietf.org References: <152837409539.30768.4568779645299135020.idtracker@ietfa.amsl.com> <6a1a100c-3bc0-76d3-3ae4-047d37906bfc@mozilla.com> <7161340e-014b-3740-83ed-39f4db3a30c0@nostrum.com> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: <7aad7f1f-ca4c-51d3-a1f4-aefb919dae34@mozilla.com> Date: Thu, 7 Jun 2018 16:29:33 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <7161340e-014b-3740-83ed-39f4db3a30c0@nostrum.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="N5fcrHKPcBkZwfFmcmIToXXy5gkpyJ6KA" Archived-At: Subject: Re: [urn] Benjamin Kaduk's Discuss on draft-hakala-urn-nbn-rfc3188bis-01: (with DISCUSS and COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 22:29:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --N5fcrHKPcBkZwfFmcmIToXXy5gkpyJ6KA Content-Type: multipart/mixed; boundary="qnMjYe2Oa1AUqb5tV2ArneKc4IKA0NT0h"; protected-headers="v1" From: Peter Saint-Andre To: Adam Roach , Benjamin Kaduk , The IESG Cc: "urn@ietf.org" , draft-hakala-urn-nbn-rfc3188bis@ietf.org Message-ID: <7aad7f1f-ca4c-51d3-a1f4-aefb919dae34@mozilla.com> Subject: Re: Benjamin Kaduk's Discuss on draft-hakala-urn-nbn-rfc3188bis-01: (with DISCUSS and COMMENT) References: <152837409539.30768.4568779645299135020.idtracker@ietfa.amsl.com> <6a1a100c-3bc0-76d3-3ae4-047d37906bfc@mozilla.com> <7161340e-014b-3740-83ed-39f4db3a30c0@nostrum.com> In-Reply-To: <7161340e-014b-3740-83ed-39f4db3a30c0@nostrum.com> --qnMjYe2Oa1AUqb5tV2ArneKc4IKA0NT0h Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/7/18 2:40 PM, Adam Roach wrote: > On 6/7/18 3:02 PM, Peter Saint-Andre wrote: >> By "normalize" you mean perform equivalence matching of percent-decode= d >> strings (of which Unicode normalization might be one step), right? Her= e >> again I think the answer is "don't do that" because it's equivalence >> matching is done on the percent-encoded strings. >=20 >=20 > I think the concern here is the translation between percent-encoded URN= s > on the wire and the display form that users enter into lookup forms. Fo= r > example, imagine some alt-history version of a country that decided tha= t > its NBNs would take the form -. Encoded as a > URN, this might look like urn:nbn:dd:roach-157. >=20 > The issue, of course, is that "urn:nbn:dd:m%c3%bcller-127" doesn't matc= h > "urn:nbn:dd:mu%cc%88ller-127". >=20 > So the problem doesn't occur at the level you mention; it happens > somewhere between the keyboard and the network card of a querying user.= > That's not really this document's problem per se, but it is definitely = a > dragon that needs flagging. I'm not sure whether "don't do that then" i= s > the correct advice, unless we have reason to believe that national > libraries are hyper-aware of URN considerations when designing their NB= N > schemes. What we probably need to say is "if your national library > defines an NBN that can contain percent-encoded characters higher than > U+007F, then that same body needs to carefully define the canonical > transformation from NBNs into URNs, including normalization forms." Text along those lines seems appropriate. We might also discourage people from defining their own canonical transformation, but rather re-use one that's already defined (say, a PRECIS profile such as UsernameCaseMapped). Peter --qnMjYe2Oa1AUqb5tV2ArneKc4IKA0NT0h-- --N5fcrHKPcBkZwfFmcmIToXXy5gkpyJ6KA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlsZsc0ACgkQZWGMGH9o FKk6qhAA23d3YCevx+vzmJbc4Qqnc1HQBQfHIN7PnKqOXqYCFlF6A0ORnIuEIWhh 6C1Onz7+Drya/OyyYWy8nx56ExBUjWhdqEt7WSDhxxFMfaiFwmNd639eTlbNgCEi wC2/LwUsdH2EgZ8k/8fzJz44WRAgwnmZ2xMjSSZNU4/IdSBANKt+UpZo1p9kS7vj T/yrBIthG3wGRFuO6zEEUj41F3SNoIVmX/D3kPc7smaZb5cT7Uj5GUvXlDoLGtZh Y4ibUNRix6xxNemz94hKYy2R5uXgvQApN5CsiNJ7wywU/aXjdbJ0/dgOCkDpx6My vLaWIFBPCN+eELI91Ue4NmzyjruJwuU7LNadHFokh1gg3AEnkRHGo3vz478kluev urXd5zorIDp/aKbe0wmVcy1Kl0iffKowK6l8vcoOdEfMV9Y8EoEUGpISiMkenx98 wGWDHHSJzNFs37SJDiPZQ4OAxtSfzdXDSR0esJ4ccoKcQ8gZvG0szkEiRWEJqihr 0SPS5la4rfadAZ/Q4+otdgHlCFN38883a+g+gbf8+IqNtcFiNO7xPikbh7btHT3O +FcHKwbAFIQyUUVWO8xQ+iCNG7VbXhYAayZjtTv0zxRvGjHmX+bQKsB85ioaBIIO T1usz9w5N0xR2hXzLQMopMIBqeuTSPq1XGgVlPUev5CbSg3C00U= =eEF7 -----END PGP SIGNATURE----- --N5fcrHKPcBkZwfFmcmIToXXy5gkpyJ6KA-- From nobody Thu Jun 7 17:52:39 2018 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5FE8131004; Thu, 7 Jun 2018 17:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no 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 l2OPK61bWjLM; Thu, 7 Jun 2018 17:52:30 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD39C130E04; Thu, 7 Jun 2018 17:52:30 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1fR5di-000Gel-KS; Thu, 07 Jun 2018 20:52:26 -0400 Date: Thu, 07 Jun 2018 20:52:21 -0400 From: John C Klensin To: Peter Saint-Andre , Adam Roach , Benjamin Kaduk , The IESG cc: urn@ietf.org, draft-hakala-urn-nbn-rfc3188bis@ietf.org Message-ID: <889191E8A3294673F32181B3@PSB> In-Reply-To: <7aad7f1f-ca4c-51d3-a1f4-aefb919dae34@mozilla.com> References: <152837409539.30768.4568779645299135020.idtracker@ietfa.amsl.com> <6a1a100c-3bc0-76d3-3ae4-047d37906bfc@mozilla.com> <7161340e-014b-3740-83ed-39f4db3a30c0@nostrum.com> <7aad7f1f-ca4c-51d3-a1f4-aefb919dae34@mozilla.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] Benjamin Kaduk's Discuss on draft-hakala-urn-nbn-rfc3188bis-01: (with DISCUSS and COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 00:52:37 -0000 --On Thursday, June 7, 2018 16:29 -0600 Peter Saint-Andre wrote: > Text along those lines seems appropriate. We might also > discourage people from defining their own canonical > transformation, but rather re-use one that's already defined > (say, a PRECIS profile such as UsernameCaseMapped). I started to write a much longer note and explanation, but maybe a summary is better for all concerned (i.e., if more is needed, it is readily available). IMO, there are two separate issues involved with this discussion. One is whether an Internationalization Considerations section is needed. It seems to me that it is, but that it should mostly be part of much clearer explanations in RFC 3986 about what rules, especially about canonical forms and matching, apply to all URI types, what is delegated to schemes/methods, and what can reasonably be further delegated by particular schemes to, e.g., for the URN case, particular namespaces. The URNBIS WG discussed whether to try to incorporate that type of explanation into what became RFC 8141 but concluded that would be unwise, in part because it would risk contradictions between the way some of those in the URN community interpreted (or wanted to interpret) 3986 and the way some of those in the more traditional web community (a subset of whom are offended at the whole idea of URNs interpret 3986. Pushing those issues and that debate into the definition of a particular namespace seems unwise and inappropriate. While the other is about i18n, it is less about what I would think of as internationalization considerations for NBNs in general then it is about free advice to those who are defining national sub-namespaces for NBNs. Make statements like that if you like (and please pay attention to whatever Juha, who is ultimately responsible for the text, has to say on the subject), but remember that the managers of those national sub-namespaces are mostly repository libraries who, in general, know far more about their names, their languages, and how Unicode relates to those languages than we can hope to. Remembering that NBNs are already deployed by some of those libraries and that they have hundreds of years of experience with the types of identifier, and identifier comparison rules, that work for them, I personally think that the IETF should be a little careful about hubris in giving advice on those issues, but whatever works. best, john From nobody Thu Jun 7 18:54:07 2018 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D54F130E12 for ; Thu, 7 Jun 2018 18:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no 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 jROi7ZJaDG71 for ; Thu, 7 Jun 2018 18:54:03 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9674912F1A6 for ; Thu, 7 Jun 2018 18:54:03 -0700 (PDT) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-09v.sys.comcast.net with ESMTP id R6SCf9OTJqmKNR6bKf1ZuF; Fri, 08 Jun 2018 01:54:02 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-08v.sys.comcast.net with ESMTPA id R6bIfgCkLmOP9R6bJfzHqz; Fri, 08 Jun 2018 01:54:02 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id w581s0Ex029620; Thu, 7 Jun 2018 21:54:00 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w581rxgC029616; Thu, 7 Jun 2018 21:53:59 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Peter Saint-Andre Cc: urn@ietf.org, ibagdona@gmail.com, draft-mahesh-etsi-urn@ietf.org In-Reply-To: <6aa1f7c2-8073-a2fd-1862-6f26266be823@mozilla.com> (stpeter@mozilla.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 07 Jun 2018 21:53:59 -0400 Message-ID: <87fu1yhwlk.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfEDl4JNIT/ye76HXmrP5QELs9OmuzBlerufrL6xDTNSsilcKYKFtNmUFyMZzQIBNMxfhoddwjuXeK3SeC2nODwtd/nLeEgEcrYTIKUnsE5YYsnEyUMSU DPBqy9g4OUL9VS9Cg24EnzPwBdvr4zPgLY9RhoTDur7DfwkDsYZJ1yS8aG9fKywcGvNnpOckfgn1kJzrXNeUvWczq8H0/WicBEvTIzZPGn8emUGMFCGK3cn/ FA+/JsF30RrcwOOt3gj10o9GYn7Moi88qH6aXFvo6wA9Ptscct9gJe1XDqHNSZ3df2XQ3gctZhwz/tlCug1ED6EihDhX9iIG7DEUmL4zsz0= Archived-At: Subject: Re: [urn] URN expert review of 'etsi' NID X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 01:54:06 -0000 Comments on draft-mahesh-etsi-urn-02 1.1. Terminology | PNNS | Protocol Name and Numbering Service | It would be helpful to state that PNNS is an ETSI function: | PNNS | ETSI Protocol Name and Numbering Service | Declaration of syntactic structure: The syntax of namespace specific strings for the 'etsi' namespace is in Uniform Resource Names (URNs) [RFC8141]. This is completely legitimate, but it is not satisfying. If ETSI has plans for how it will organize the space of NSSs, it would be nice to describe them here. Relevant ancillary documentation: ETSI publishes information regarding the registered resources in the ETSI URN Namespace (EUN) registry (https://portal.etsi.org/PNNS/GenericAllocation/ ETSIURNNamespace.aspx). It's good that ETSI gives the URL of its URN registry; many other organizations do not. However, I notice that that URL is password-protected. It would be much better for the community if the registry was readable by the world, since there is no stated intention that etsi URNs are used only within a closed community. Identifier uniqueness considerations: [...] ETSI is expected to guarantee the uniqueness [...] Formally, this registration is being submitted by ETSI, so it reads oddly for ETSI to say "ETSI is expected...". Much better would be "ETSI will...". Similarly, "ETSI could..." is used where it is more natural to say "ETSI may...". Note that using experimental types may create collision as multiple users may use the same values for different resources and specific strings. It would be very helpful if the registration stated how the ETSI registry will make clear how to recognize experimental URIs within the etsi namespace. Dale From nobody Fri Jun 8 09:43:35 2018 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F58D130F29; Fri, 8 Jun 2018 09:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 iW1_MgVypKGJ; Fri, 8 Jun 2018 09:43:27 -0700 (PDT) Received: from mail-pl0-x22e.google.com (mail-pl0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE6EA130F23; Fri, 8 Jun 2018 09:43:27 -0700 (PDT) Received: by mail-pl0-x22e.google.com with SMTP id w17-v6so8618082pll.9; Fri, 08 Jun 2018 09:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=y4pXhqkiB5QnHWMMoQhIvhIT9okYzTNN1r/odiH/jbg=; b=G3/AVMynFildkxl3vbxtv9et9j34xK4OF6sofgFC/jFZvMI1AkDEsMEJC8sRKay+CI /4rJgCylEiXZL7Yw2RR2IJft5OQkWN93B5L2kXaTv7yu+RnawmCO8itRadRKZDpvY7Oh qCRMZXQh/AOX4z/iJ1Rg+Ahweu3IVEylmphaNd+xWBxFzcyrZcPubTPpBpqDxCtCGByq TN6COO6YpBTbP03fh9i7sCZyCN4ibuuJBx/kQsco3gD6GP852w/yDoPHUZLgEPDMZKzP fbngOKwie/XiveVKdJ/Pz5HgzN/plwImU6pZlhyZqyjnumaRK0XU2eNCxO9e7Zo0L0rH QYXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=y4pXhqkiB5QnHWMMoQhIvhIT9okYzTNN1r/odiH/jbg=; b=YyULc3tS2vz2rvIdv6zPONMXggkFOQCgTZW4T+Akr14zTKcIhiR5GyllYIu3rGcAHa uqaim2D8zyHiWl7Gk38T+SlGFDgnRz1sDvdnzRswLOIwL5HvPmQ6IZ+P1YMH6P2MyN6g CuXTLdQ/JY6gOzMgJzxtas8PKh5qRFLW+aBz16AjMF89AYTCfr1VIiHtC8rVU1ieJA4j 6MthgVLS6ZX0f9Jxx0VAGWUTLEZgSwuD3qQeDetkLZwXWz+DN/5cAtXQLozErAqUUenQ IDU0HurCBrBOP6WrtBbaLOmS2cPa1iV+QX4EE7r++LF1XrKB48+SIsw0l20ryHW2Vqtu PZzw== X-Gm-Message-State: APt69E0Sw9jYCyA3Hc9LY61kWtMNC1P8Ycu+iy2R0N8KQsTf3M/Oww0P xMZiQEX3Ybidlr7WH+xahH4= X-Google-Smtp-Source: ADUXVKJaMkhmgTi6OsJSOpO9QEp4pIsJtCYBvKIk8HrwwxRFCp1DIwE077P/QaD0spVcKjxdelVcLQ== X-Received: by 2002:a17:902:b949:: with SMTP id h9-v6mr7525945pls.321.1528476207380; Fri, 08 Jun 2018 09:43:27 -0700 (PDT) Received: from ?IPv6:2601:647:4700:1280:433:2e83:815e:b150? ([2601:647:4700:1280:433:2e83:815e:b150]) by smtp.gmail.com with ESMTPSA id w10-v6sm36640436pfa.135.2018.06.08.09.43.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Jun 2018 09:43:26 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <03646C22-3BA1-4D85-A398-81A550D4B92C@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8C379CE2-6DE2-4BE8-AB87-3426699613FB" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Fri, 8 Jun 2018 09:43:25 -0700 In-Reply-To: <83796945-3f77-f1a2-fba6-8aac62630bf5@mozilla.com> Cc: "urn@ietf.org" , Ignas Bagdonas , draft-mahesh-etsi-urn@ietf.org To: Peter Saint-Andre References: <6aa1f7c2-8073-a2fd-1862-6f26266be823@mozilla.com> <83796945-3f77-f1a2-fba6-8aac62630bf5@mozilla.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [urn] URN expert review of 'etsi' NID X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 16:43:31 -0000 --Apple-Mail=_8C379CE2-6DE2-4BE8-AB87-3426699613FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Peter, > On Jun 7, 2018, at 1:22 PM, Peter Saint-Andre = wrote: >=20 > Upon review, I noticed a few things: >=20 > 1. The registration request uses the old template from RFC 3406, not = the > new template from RFC 8141. IANA requires new registrations to use the > new template. I will update the draft with the template information that is new in RFC = 8141. >=20 > 2. Can you provide a slightly more detailed description of the kinds = of > resources these URNs will identify? I have added a Purpose section to the draft that reads as: Purpose: The URN requested in this document will be used by ETSI for allocation = of namespaces to be used by YANG modules, to begin with, that are = developed by the organization. These namespaces are globally unique. The = URN will be used in public networks by devices used to configure and = manage resources in the network. It is these devices that will enforce = the uniqueness of the namespaces by using the namespace and the XPath = associated with the managed node in the network, when accessing a = resource. Does this answer your question? >=20 > 3. Can you provide a slightly more detailed description of the syntax > within the NSS? Let me work with my co-author to provide you a more detailed description = of the syntax of NSS. It is currently under a password protected web = site, but the idea is to make it public once we have finalized the = syntax. Thanks. >=20 > Other reviewers might notice additional issues... >=20 > Peter >=20 > On 6/7/18 10:58 AM, Peter Saint-Andre wrote: >> Hello Expert Reviewers & others, >>=20 >> I just noticed that draft-mahesh-etsi-urn requests a URN NID for = 'etsi' >> to identify resources published by European Telecommunications = Standards >> Institute: >>=20 >> https://datatracker.ietf.org/doc/draft-mahesh-etsi-urn/ >>=20 >> Although it's not clear which IESG telechat this is on (the = responsible >> AD, Ignas Bagdonas, can tell us), let's make sure to review it in a >> timely fashion. >>=20 >> Thanks! >>=20 >> Peter >>=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_8C379CE2-6DE2-4BE8-AB87-3426699613FB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Peter,

On Jun 7, 2018, at 1:22 PM, Peter Saint-Andre = <stpeter@mozilla.com> wrote:

Upon = review, I noticed a few things:

1. The = registration request uses the old template from RFC 3406, not the
new template from RFC 8141. IANA requires new registrations = to use the
new template.

I will = update the draft with the template information that is new in RFC = 8141.


2. Can you provide a slightly = more detailed description of the kinds of
resources these = URNs will identify?

I have added a Purpose section to the draft that reads = as:

Purpose:
The URN requested in = this document will be used by ETSI for allocation of namespaces to be = used by YANG modules, to begin with, that are developed by the = organization. These namespaces are globally unique. The URN will be used = in public networks by devices used to configure and manage resources in = the network. It is these devices that will enforce the  uniqueness = of the namespaces by using the namespace and the XPath associated with = the managed node in the network, when accessing a = resource.

Does this answer = your question?


3. Can you = provide a slightly more detailed description of the syntax
within the NSS?
Let me work with my co-author to provide you a more = detailed description of the syntax of NSS. It is currently under a = password protected web site, but the idea is to make it public once we = have finalized the syntax.

Thanks.


Other reviewers might notice = additional issues...

Peter

On 6/7/18 10:58 AM, Peter Saint-Andre wrote:
Hello Expert Reviewers = & others,

I just noticed that = draft-mahesh-etsi-urn requests a URN NID for 'etsi'
to = identify resources published by European Telecommunications Standards
Institute:

https://datatracker.ietf.org/doc/draft-mahesh-etsi-urn/

Although it's not clear which IESG telechat = this is on (the responsible
AD, Ignas Bagdonas, can tell = us), let's make sure to review it in a
timely fashion.

Thanks!

Peter



Mahesh Jethanandani
mjethanandani@gmail.com

= --Apple-Mail=_8C379CE2-6DE2-4BE8-AB87-3426699613FB-- From nobody Fri Jun 8 09:56:08 2018 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00173130F23; Fri, 8 Jun 2018 09:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 sVLWYuuC4oQk; Fri, 8 Jun 2018 09:56:03 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1E0A130F19; Fri, 8 Jun 2018 09:56:03 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id j20-v6so6918070pff.10; Fri, 08 Jun 2018 09:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dzx+zcueeiNHIWf3AxwRN6gGyqC+u0rl4l72W1LmOV4=; b=ET/MWjbE+Syfyyvty2uuHr7h83/Dtn72lG2aPR622WOG+DUPUQKzaBKWCAobU+K4yT QRDnWZm9Ju5wpB6JrPZrpfSjWeH2Pr8VRQmLttUWDG9xJOKSXlECFC7V5mvn2DtFW9II VnyPyAJrhOs3Ie744NSFmcSXORw9oxUg6QP0so+79GNX7FVlqGByJB9ElhUJdbFyOnEh mfSrHAjz/XjkuzzDEo81UsnlhTZyETL+XXA9WPfBiYeFWc2b1wsiJ4VUhobojAqhZqNm nJrA0HLNzIUplX3LGjrAUczXMDbla0fruq4T8gZGNuMGIwCE4/jCv/JY0GMAOow/OJPm Vhpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dzx+zcueeiNHIWf3AxwRN6gGyqC+u0rl4l72W1LmOV4=; b=MtKif/gADLjocNpM8R5ummk8ieSgt9k3QhX5jUXTQGaaEq0nbp3lP5S6az4jMZeycW sDlFZYLalnxHeMxyt9Hszl8WAMoVYvh6jWlpCIFXgUdLNcHAo66yDFqku22WsaxLOcx8 UmFqebP0WV0Re6G8khmjYOBB7Fv+AbyT0R/+WhocFKeraLZ0pKmzpOPZKyWQqnZuPUI9 v6djYvB6qkXQb5k5nRtdtHr16zMH5PduHj6n3lMwhbMUFNHQM/9IRKOiuMzh2ZXp6XxI qFIehn/krB2nu2NrQinJUViRnU/KsG95bWr6qp57euxG/7tre/3Gyf9Pg4fmSKZptR4D EczQ== X-Gm-Message-State: APt69E0bytfs2LEEKSlYz0cfVjq4dwMEabGOt7z7V5vTsmtCcHZre2vc gLSAJwj5tZZRGiMLacpg5ko= X-Google-Smtp-Source: ADUXVKIp7chYZiwY73b4VVkXD7kd2/ScNcBHHXQULO4xh5+jpEtaKZicIwQK5/GSIN135NVH9pRaVw== X-Received: by 2002:a65:62ce:: with SMTP id m14-v6mr5934580pgv.407.1528476963300; Fri, 08 Jun 2018 09:56:03 -0700 (PDT) Received: from ?IPv6:2601:647:4700:1280:433:2e83:815e:b150? ([2601:647:4700:1280:433:2e83:815e:b150]) by smtp.gmail.com with ESMTPSA id 29-v6sm97878348pfj.14.2018.06.08.09.56.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Jun 2018 09:56:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Mahesh Jethanandani In-Reply-To: <87fu1yhwlk.fsf@hobgoblin.ariadne.com> Date: Fri, 8 Jun 2018 09:56:01 -0700 Cc: Peter Saint-Andre , urn@ietf.org, Ignas Bagdonas , draft-mahesh-etsi-urn@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <11EAC9EB-F3B8-45AF-88F1-E70F8CA9F0D5@gmail.com> References: <87fu1yhwlk.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [urn] URN expert review of 'etsi' NID X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 16:56:06 -0000 Hi Dale, > On Jun 7, 2018, at 6:53 PM, Dale R. Worley wrote: >=20 > Comments on draft-mahesh-etsi-urn-02 >=20 > 1.1. Terminology >=20 > | PNNS | Protocol Name and Numbering Service | >=20 > It would be helpful to state that PNNS is an ETSI function: >=20 > | PNNS | ETSI Protocol Name and Numbering Service | Ok. Will add ETSI in front of the definition for PNNS. >=20 > Declaration of syntactic structure: >=20 > The syntax of namespace specific strings for the 'etsi' namespace > is in Uniform Resource Names (URNs) [RFC8141]. >=20 > This is completely legitimate, but it is not satisfying. If ETSI has > plans for how it will organize the space of NSSs, it would be nice to > describe them here. >=20 > Relevant ancillary documentation: >=20 > ETSI publishes information regarding the registered resources in > the ETSI URN Namespace (EUN) registry > (https://portal.etsi.org/PNNS/GenericAllocation/ > ETSIURNNamespace.aspx). >=20 > It's good that ETSI gives the URL of its URN registry; many other > organizations do not. However, I notice that that URL is > password-protected. It would be much better for the community if the > registry was readable by the world, since there is no stated intention > that etsi URNs are used only within a closed community. In my response to Peter, I stated that the syntax of the NSS will be = specified as part of the ancillary document at the URL specified, and I = will work with my co-author to publish that URL such that it is readable = by the world. >=20 > Identifier uniqueness considerations: >=20 > [...] ETSI is expected to guarantee the uniqueness [...] >=20 > Formally, this registration is being submitted by ETSI, so it reads > oddly for ETSI to say "ETSI is expected...". Much better would be > "ETSI will=E2=80=A6". Updated the text to say: ETSI will guarantee the uniqueness of the strings =E2=80=A6 >=20 > Similarly, "ETSI could..." is used where it is more natural to say = "ETSI > may=E2=80=A6". Updated to say: ETSI may allow for use of experimental type values ... >=20 > Note that using experimental types may create > collision as multiple users may use the same values for different > resources and specific strings. >=20 > It would be very helpful if the registration stated how the ETSI > registry will make clear how to recognize experimental URIs within the > etsi namespace. That will be part of the NSS definition in the ancillary document. But = basically, the idea is use something like :xid:, or experimental id, as = part of the NSS to distinguish it from assigned values. Thanks. >=20 > Dale Mahesh Jethanandani mjethanandani@gmail.com From nobody Fri Jun 8 11:01:57 2018 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69665130F9C for ; Fri, 8 Jun 2018 11:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com 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 F9Adf2HdXpBd for ; Fri, 8 Jun 2018 11:01:54 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59D51130F7E for ; Fri, 8 Jun 2018 11:01:54 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id l6-v6so3508554iti.2 for ; Fri, 08 Jun 2018 11:01:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=AV9S85vZpiY4gk+NAQ7hlq8Siyym5ed2cix506OOl1k=; b=HUbbnR5gmjV61/EpJ83L5IeDUaWH1T2inZBC5n/LfGWhQpEYF2N/eB6DdN1ZyDgz6A 1AzOBgTGS/R0HfH/cF5rqLVD/N3cN0E9bnbNGro8K30nUN94YadNFsJj/IeWvR8cdcI9 7oePiizU2FCaMN/Gu8GNqbeMSlCmM6DmudvfI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=AV9S85vZpiY4gk+NAQ7hlq8Siyym5ed2cix506OOl1k=; b=e0af9uP7/BkVJWnfUsxCe7YxcUwyDBeWMWV9bkkAqoPYyJ8pTRhqMR9syOgGSsCXz/ 1d7TOYMS7iWHGEVL+TMT03x1SJVTLSfPYxFpDnpftzNigAQYAOk+CTP3g69kZrgpMgX7 bzcT5JTUI1yBCW0b09/bXza07jiSWQ2YxpNY+Mc2lbkrG+agSn89bTm/W0kI6BAXuH8U 4eJ8csvW1JUU4CxVAjrsEP3dY4PXPGMnbJiVtc5+vF0VmEOXyK/bv1Hh5KqSkhSuXDqM QFm623Gb7sUEeMLMsvEv/7GqW79HccqubmqCOPehw/276W+v9f3bC/9kZvck184OcopQ KADQ== X-Gm-Message-State: APt69E0ShR6AjfORb/YEiLd+TzvtzNG3025s9rwwwDRHGgSHVjYTF+5W If4HPnqKjczOPUtJkyD1oxHwgl2qW+g= X-Google-Smtp-Source: ADUXVKIrON1FrHgs8GF47q7qIPcYqu0+bwX7iEw9qiOb7R8spRHl6p3cdSyjjuClYkScsbfhNIGtiw== X-Received: by 2002:a24:d3d5:: with SMTP id n204-v6mr2482272itg.29.1528480913779; Fri, 08 Jun 2018 11:01:53 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id z2-v6sm1099506ita.37.2018.06.08.11.01.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Jun 2018 11:01:53 -0700 (PDT) To: John C Klensin , Adam Roach , Benjamin Kaduk , The IESG Cc: urn@ietf.org, draft-hakala-urn-nbn-rfc3188bis@ietf.org References: <152837409539.30768.4568779645299135020.idtracker@ietfa.amsl.com> <6a1a100c-3bc0-76d3-3ae4-047d37906bfc@mozilla.com> <7161340e-014b-3740-83ed-39f4db3a30c0@nostrum.com> <7aad7f1f-ca4c-51d3-a1f4-aefb919dae34@mozilla.com> <889191E8A3294673F32181B3@PSB> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: <36fed997-33b4-cf82-e2b7-7680a718d9d4@mozilla.com> Date: Fri, 8 Jun 2018 12:01:51 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <889191E8A3294673F32181B3@PSB> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="shoIJB7bdgIpYCeFZUx8G3EhXxRMiRfv9" Archived-At: Subject: Re: [urn] Benjamin Kaduk's Discuss on draft-hakala-urn-nbn-rfc3188bis-01: (with DISCUSS and COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 18:01:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --shoIJB7bdgIpYCeFZUx8G3EhXxRMiRfv9 Content-Type: multipart/mixed; boundary="LUQgdThxhML8rMxeHB82jN1kKCqa4jKwS"; protected-headers="v1" From: Peter Saint-Andre To: John C Klensin , Adam Roach , Benjamin Kaduk , The IESG Cc: urn@ietf.org, draft-hakala-urn-nbn-rfc3188bis@ietf.org Message-ID: <36fed997-33b4-cf82-e2b7-7680a718d9d4@mozilla.com> Subject: Re: [urn] Benjamin Kaduk's Discuss on draft-hakala-urn-nbn-rfc3188bis-01: (with DISCUSS and COMMENT) References: <152837409539.30768.4568779645299135020.idtracker@ietfa.amsl.com> <6a1a100c-3bc0-76d3-3ae4-047d37906bfc@mozilla.com> <7161340e-014b-3740-83ed-39f4db3a30c0@nostrum.com> <7aad7f1f-ca4c-51d3-a1f4-aefb919dae34@mozilla.com> <889191E8A3294673F32181B3@PSB> In-Reply-To: <889191E8A3294673F32181B3@PSB> --LUQgdThxhML8rMxeHB82jN1kKCqa4jKwS Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/7/18 6:52 PM, John C Klensin wrote: >=20 >=20 > --On Thursday, June 7, 2018 16:29 -0600 Peter Saint-Andre > wrote: >=20 >> Text along those lines seems appropriate. We might also >> discourage people from defining their own canonical >> transformation, but rather re-use one that's already defined >> (say, a PRECIS profile such as UsernameCaseMapped). >=20 > I started to write a much longer note and explanation, but maybe > a summary is better for all concerned (i.e., if more is needed, > it is readily available). Indeed. Similarly, I had started writing a longer note yesterday, pointing out that much of this is already covered in: 1. RFC 3986 (esp. Section 1.2.1, which doesn't say how "to use a wider range of characters" nor does it "specify the character encoding used to map those characters to octets prior to being percent-encoded for the URI= ") 2. RFC 8141 (esp. Section 2.2, which specifies a character encoding of UTF-8 but doesn't say how to process "those characters" before UTF-8 encoding). My reading of Adam's and Ben's messages is that they'd like a more detailed specification of the last-mentioned item, or at least bring the matter to the attention of anyone brave or foolhardy enough to use "those characters" in NBNs. +1 to the rest of what John said. Peter --LUQgdThxhML8rMxeHB82jN1kKCqa4jKwS-- --shoIJB7bdgIpYCeFZUx8G3EhXxRMiRfv9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlsaxI8ACgkQZWGMGH9o FKmyfRAAndKZYIEXABmw4EaSNJQSSvfP67FdW5U/MoVJIb3tIGZU2XVnBuMLVtPR meXEOPG2PnFfKveqsEMw4ZDDZhlTTYw+jpVGbYM92FqHTXj1A9kJhZoy+UIYvY57 NzGGKo8dP4y3U4LaW/Zt9PPDDGNBm2YEjwZgLFsES7J1cxkj8d2ArJnYVZpLH+4y jI/q2/MYOAhebVNSCabNdRxnu01F3R8zikxJqiG83XvriGRSt0qQF5SrTfIaEGEF hRt26ZLOnDnVR9p+u/zSrAnGFuwdudjLf3XR/JWsdlFuZzVAkjmSZLvoDduOtjk6 5I+7CXREgiNiZtmVbEYMkySFH6wI11EyFVnRl2HspuWug+cuSCl++dcxOfjZfNdJ dedj9tlaLQ4yddIUut7yxsc4wPVuYRxvy2bOfd1KYYhYg7flRrDx+9CoRM6xotU4 4D06aYJxV+QquK4Sk2Wnvh/M+cwQAWe+dFQhuuOW+bJqJiacD0IQWgnJiqI1QmQl n/OltNtQvw6C7ZlwLlKEtij9Rt746XtlKX2CGONzOEcHZwGeNmfX9+XU3x4zOx8X xlu08Mc0+fZ7QjUH3616Su3BlimYKN/rX4vuXZkyGc6lF67b13aJniUvM5L5quNP UE1eBErFeLUtzsMjtmAZFVPsA93Sz8VcC02+g87Cqe3ZjQbDt5U= =cUE0 -----END PGP SIGNATURE----- --shoIJB7bdgIpYCeFZUx8G3EhXxRMiRfv9-- From nobody Fri Jun 8 12:45:19 2018 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1900C130FD9; Fri, 8 Jun 2018 12:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 3S7y01Ihv-aE; Fri, 8 Jun 2018 12:45:10 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0D44130FA6; Fri, 8 Jun 2018 12:45:10 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w58Jj9c0099851 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 8 Jun 2018 14:45:09 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Peter Saint-Andre , John C Klensin , Benjamin Kaduk , The IESG Cc: urn@ietf.org, draft-hakala-urn-nbn-rfc3188bis@ietf.org References: <152837409539.30768.4568779645299135020.idtracker@ietfa.amsl.com> <6a1a100c-3bc0-76d3-3ae4-047d37906bfc@mozilla.com> <7161340e-014b-3740-83ed-39f4db3a30c0@nostrum.com> <7aad7f1f-ca4c-51d3-a1f4-aefb919dae34@mozilla.com> <889191E8A3294673F32181B3@PSB> <36fed997-33b4-cf82-e2b7-7680a718d9d4@mozilla.com> From: Adam Roach Message-ID: <41220e59-8223-70bc-1ac2-701d7607be04@nostrum.com> Date: Fri, 8 Jun 2018 14:45:03 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <36fed997-33b4-cf82-e2b7-7680a718d9d4@mozilla.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [urn] Benjamin Kaduk's Discuss on draft-hakala-urn-nbn-rfc3188bis-01: (with DISCUSS and COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 19:45:12 -0000 On 6/8/18 1:01 PM, Peter Saint-Andre wrote: > ... > Indeed. Similarly, I had started writing a longer note yesterday, > pointing out that much of this is already covered in: > > 1. RFC 3986 (esp. Section 1.2.1, which doesn't say how "to use a wider > range of characters" nor does it "specify the character encoding used to > map those characters to octets prior to being percent-encoded for the URI") > > 2. RFC 8141 (esp. Section 2.2, which specifies a character encoding of > UTF-8 but doesn't say how to process "those characters" before UTF-8 > encoding). > > My reading of Adam's and Ben's messages is that they'd like a more > detailed specification of the last-mentioned item, or at least bring the > matter to the attention of anyone brave or foolhardy enough to use > "those characters" in NBNs. What I have in mind is more the second thing than the first. As John pointed out, what libraries want to do may vary from country to country. I just want text that warns that there's a gun here and that they should take care to aim it away from their own foot. /a From nobody Fri Jun 8 13:26:15 2018 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B867131012; Fri, 8 Jun 2018 13:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Vvsxs3rWXwh8; Fri, 8 Jun 2018 13:26:10 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46DE5130FCB; Fri, 8 Jun 2018 13:26:10 -0700 (PDT) X-AuditID: 1209190f-0ffff7000000444f-da-5b1ae661360d Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 7C.A4.17487.166EA1B5; Fri, 8 Jun 2018 16:26:09 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w58KQ77g020226; Fri, 8 Jun 2018 16:26:08 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w58KPx1Y013727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 8 Jun 2018 16:26:04 -0400 Date: Fri, 8 Jun 2018 15:25:59 -0500 From: Benjamin Kaduk To: Adam Roach Cc: Peter Saint-Andre , John C Klensin , The IESG , urn@ietf.org, draft-hakala-urn-nbn-rfc3188bis@ietf.org Message-ID: <20180608202558.GC16349@kduck.kaduk.org> References: <152837409539.30768.4568779645299135020.idtracker@ietfa.amsl.com> <6a1a100c-3bc0-76d3-3ae4-047d37906bfc@mozilla.com> <7161340e-014b-3740-83ed-39f4db3a30c0@nostrum.com> <7aad7f1f-ca4c-51d3-a1f4-aefb919dae34@mozilla.com> <889191E8A3294673F32181B3@PSB> <36fed997-33b4-cf82-e2b7-7680a718d9d4@mozilla.com> <41220e59-8223-70bc-1ac2-701d7607be04@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41220e59-8223-70bc-1ac2-701d7607be04@nostrum.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupileLIzCtJLcpLzFFi42IRYrdT0U18JhVt8Gwpv8Wev4vYLf5c/8Vi MePPRGaL1kt/2CyerTzFaDG1+QOTA5vHkiU/mTwur3zN7NF3oIvVY9bOJywBLFFcNimpOZll qUX6dglcGV/2PGUqeMpVMXH5MfYGxi0cXYycHBICJhJbDu5m6WLk4hASWMwkcWn2WSYIZwOj xPPFZxkhnCtMEp0zPgI5HBwsAioSNxpzQLrZgMyG7svMILaIgKJE2+GbzCD1zAKbGSXOzl3C CpIQFsiXmLbkKhOIzQu0bmPHHqh135kknhw8xg6REJQ4OfMJC4jNLKAlcePfSyaQZcwC0hLL /4GdyilgL3FkxROwZaICyhJ7+w6xT2AUmIWkexaS7lkI3QsYmVcxyqbkVunmJmbmFKcm6xYn J+blpRbpmujlZpbopaaUbmIEBTmnJP8OxjkN3ocYBTgYlXh4b7RIRQuxJpYVV+YeYpTkYFIS 5T1xXjJaiC8pP6UyI7E4I76oNCe1+BCjBAezkgjvMyWgct6UxMqq1KJ8mJQ0B4uSOG/2IsZo IYH0xJLU7NTUgtQimKwMB4eSBK/lU6BGwaLU9NSKtMycEoQ0EwcnyHAeoOGJT0CGFxck5hZn pkPkTzEqSonz6oE0C4AkMkrz4HpBSUgie3/NK0ZxoFeEeYtBqniACQyu+xXQYCagwR7MkiCD SxIRUlINjDzq/29Zr3B7mv/LT/RT/9MpiwRqTxlOfvZzosjd+oAkDccDmiEPpzPfyt59nU2Y zdYn5uOvxZfvvtdrZDi94op4vezsF7Zdetm5dba3J2z4mtHYEDYnha9kekvNdb3vpx8uyv3n ZHst+JBx+Yc8jnWpAXrmCom+ksdnhYpe9t5/ds3CrVY/C5VYijMSDbWYi4oTAfWMT9gdAwAA Archived-At: Subject: Re: [urn] Benjamin Kaduk's Discuss on draft-hakala-urn-nbn-rfc3188bis-01: (with DISCUSS and COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 20:26:13 -0000 On Fri, Jun 08, 2018 at 02:45:03PM -0500, Adam Roach wrote: > On 6/8/18 1:01 PM, Peter Saint-Andre wrote: > > ... > > Indeed. Similarly, I had started writing a longer note yesterday, > > pointing out that much of this is already covered in: > > > > 1. RFC 3986 (esp. Section 1.2.1, which doesn't say how "to use a wider > > range of characters" nor does it "specify the character encoding used to > > map those characters to octets prior to being percent-encoded for the URI") > > > > 2. RFC 8141 (esp. Section 2.2, which specifies a character encoding of > > UTF-8 but doesn't say how to process "those characters" before UTF-8 > > encoding). > > > > My reading of Adam's and Ben's messages is that they'd like a more > > detailed specification of the last-mentioned item, or at least bring the > > matter to the attention of anyone brave or foolhardy enough to use > > "those characters" in NBNs. > > What I have in mind is more the second thing than the first. As John > pointed out, what libraries want to do may vary from country to country. > I just want text that warns that there's a gun here and that they should > take care to aim it away from their own foot. I think that's what I had in mind as well (to the extent that I had anything at all in mind when I balloted -- I don't want to claim to be an expert in this space). -Benjamin From nobody Fri Jun 8 13:32:49 2018 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F024131024; Fri, 8 Jun 2018 13:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 84eRsntPaGoZ; Fri, 8 Jun 2018 13:32:38 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D75D2129619; Fri, 8 Jun 2018 13:32:37 -0700 (PDT) X-AuditID: 12074425-301ff700000045ef-35-5b1ae7e4a6a3 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id DA.74.17903.4E7EA1B5; Fri, 8 Jun 2018 16:32:36 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w58KWZkH019707; Fri, 8 Jun 2018 16:32:35 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w58KWUR8015567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 8 Jun 2018 16:32:33 -0400 Date: Fri, 8 Jun 2018 15:32:30 -0500 From: Benjamin Kaduk To: Peter Saint-Andre Cc: The IESG , draft-hakala-urn-nbn-rfc3188bis@ietf.org, "urn@ietf.org" Message-ID: <20180608203227.GD16349@kduck.kaduk.org> References: <152837409539.30768.4568779645299135020.idtracker@ietfa.amsl.com> <6a1a100c-3bc0-76d3-3ae4-047d37906bfc@mozilla.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline In-Reply-To: <6a1a100c-3bc0-76d3-3ae4-047d37906bfc@mozilla.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAKsWRmVeSWpSXmKPExsUixCmqrfvkuVS0wfI2Q4s/13+xWMz4M5HZ 4tnKU4wWU5s/MDmweCxZ8pPJo+9AF2sAUxSXTUpqTmZZapG+XQJXxryzDYwFl9IrJtxaxd7A eDy4i5GTQ0LARGLRm/mMILaQwGImiU/Nsl2MXED2BkaJJR+WMEE4V5gkdl5oYAOpYhFQkehc sRXMZgOyG7ovM4PYIgLaEjcP7WUBsZkF8iSaW7eB2cICmRIXft9nB7F5gbZdevySGWJoE6PE yQ8/GCESghInZz6Bai6T2H97H1ADB5AtLbH8HwdImFPAXuLhlxtgc0QFlCX29h1in8AoMAtJ 9ywk3bMQuiHCWhI3/r1kwhDWlli28DUzhG0rsW7de5YFjOyrGGVTcqt0cxMzc4pTk3WLkxPz 8lKLdC30cjNL9FJTSjcxgiKD3UV1B+Ocv16HGAU4GJV4eBuapKKFWBPLiitzDzFKcjApifKe OC8ZLcSXlJ9SmZFYnBFfVJqTWnyIUQVo16MNqy8wSrHk5eelKonwPlMCauVNSaysSi3KhymT 5mBREufNWcQYLSSQnliSmp2aWpBaBJOV4eBQkuAVAiYGIcGi1PTUirTMnBKENBMH5yFGCQ4e oOH1z0CGFxck5hZnpkPkTzEqSonzTgJJCIAkMkrz4HpBCU0ie3/NK0ZxoLeEeW+CVPEAkyFc 9yugwUxAgz2YJUEGlyQipKQaGCc1XUpf6xFruqHm/vqJtQoX3D5947uf+8JwX3pgj2JAwBrL WJUzD9aH13/veCV43NP78q4/2g53kz+HfrqY8HrlK/nnfCkZExTyg/7812/wrv1T+lN12+PC zb9eic2ccfT8H0bGbe9X73x96ZVBXvyDm983/U/99XfGu1DtbRVR6xUeN3GdzD6oxFKckWio xVxUnAgA+hmvM0MDAAA= Archived-At: Subject: Re: [urn] Benjamin Kaduk's Discuss on draft-hakala-urn-nbn-rfc3188bis-01: (with DISCUSS and COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 20:32:42 -0000 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm happy to see the main point of discussion progressing with input =66rom people who know more about the subject than me ... that said, I can comment on some of the other points, inline. On Thu, Jun 07, 2018 at 02:02:23PM -0600, Peter Saint-Andre wrote: > [ + cc urn@ietf.org for broader discussion ] >=20 > Document shepherd here. I expect the document author (and perhaps my > co-author on RFC 8141) to provide further thoughts. >=20 > On 6/7/18 6:21 AM, Benjamin Kaduk wrote: > > Benjamin Kaduk has entered the following ballot position for > > draft-hakala-urn-nbn-rfc3188bis-01: Discuss > >=20 > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > >=20 > >=20 > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > > for more information about IESG DISCUSS and COMMENT positions. > >=20 > >=20 > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-hakala-urn-nbn-rfc3188bis/ > >=20 > >=20 > >=20 > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > >=20 > > I think this document may benefit from an Internationalization > > Considerations sections, but am not entirely sure how needed it is. > > So let's discuss it... > >=20 > > In particular, the URN:NBN lexical equivalence rules include several > > case-insensitive comparisons, for the prefix and for the case of the > > hex digits in any percent-encoded values, but do not specify any > > operation on the decoded percent-encoded values/characters.=20 >=20 > As a reminder, RFC 8141 does state: >=20 > In particular, with regard to characters outside the ASCII range, > URNs that appear in protocols or that are passed between systems MUST > use only Unicode characters encoded in UTF-8 and further encoded as > required by RFC 3986. To the extent feasible and consistent with the > requirements of names defined and standardized elsewhere, as well as > the principles discussed in Section 1.2, the characters used to > represent names SHOULD be restricted to either ASCII letters and > digits or to the characters and syntax of some widely used models > such as those of Internationalizing Domain Names in Applications > (IDNA) [RFC5890], Preparation, Enforcement, and Comparison of > Internationalized Strings (PRECIS) [RFC7613], or the Unicode > Identifier and Pattern Syntax specification [UAX31]. >=20 > In order to make URNs as stable and persistent as possible when > protocols evolve and the environment around them changes, URN > namespaces SHOULD NOT allow characters outside the ASCII range > [RFC20] unless the nature of the particular URN namespace makes such > characters necessary. >=20 > By my reading of draft-hakala-urn-nbn-rfc3188bis and RFC 8141, the > allowable case-sensitivity for nbn_string constructs generated by a > national library applies to the percent-encoded string because that is > where any comparison or equivalence-matching would occur for these > identifiers. Venturing into case matching of percent-decoded strings > would (IMHO) unnecessarily open up an ugly can of worms. >=20 > > In many > > (perhaps even most?) cases, ignoring such encoded characters for > > purposes of case-insensitive comparison is the wrong thing to do, > > but if I understand correctly, it actually is the correct thing to > > do in this case. Namely, a NBN (or URN:NBN), once assigned, is > > essentially static data and consumers of it should not attempt to > > perform modification, Unicode normalization, etc. on it -- that > > would potentially change what is being identified (or render the > > identifier invalid).=20 >=20 > Well, Unicode normalization would be used as part of equivalence > operations (as in IDNA or PRECIS), but in general you are right about > modification. These are identifiers or even numbers, not malleable string= s. >=20 > > On the other hand, a national library or > > delegated institution that is assigning NBNs may wish to take into > > account Unicode normalization rules and other similar considerations > > while assigning NBNs (in particular, the nbn_string component), as > > part of their allocation policy.=20 >=20 > It could, but as far as I know none of the national libraries have yet > gone down that path or seen the need to. Juha can tell us if I'm wrong. >=20 > > Because these can be subtle, it > > may be worth explicitly pointing out the potential issues for > > registration authorities.=20 >=20 > "There be dragons and don't go there" seems like fine advice. >=20 > > That, plus the directive to consumers to > > not normalize, seems like it would be appropriate content for an > > Internationalization Considerations section. >=20 > By "normalize" you mean perform equivalence matching of percent-decoded > strings (of which Unicode normalization might be one step), right? Here > again I think the answer is "don't do that" because it's equivalence > matching is done on the percent-encoded strings. I did not have a terribly concrete scenario in mind when I wrote this; I think the one Adam described is probably enough to get us thinking about the right things. > > Separately, in Section 4.2.1 where we cover 4-components, I noted > > that RFC 8141 rather discourages actually using r-components until > > their semantics are standardized. The text here seems to be giving > > free reign for national libraries to assign their own semantics > > without any coordination with a broader community.=20 >=20 > Juha and perhaps John can clarify, but as I understand it the scope of a > URN resolver for NBNs would likely be within a particular national > library system, not even necessarily across all national libraries (this > is how things are deployed now in the absence of URN resolution, in any > case). >=20 > > Do we really > > want to advocate for this, as opposed to attempting to get broadly > > unified semantics for r-components Internet-wide? (Perhaps we > > already have and I just missed it; if so, a reference here would be > > appropriate.) >=20 > The semantics of r-components are yet to be defined. I would venture > that the IETF is probably not the right place to do that work, given how > little energy remained in the URN WG at the end (and we probably didn't > have the right people in the room in the first place). I won't argue with that. Does it make sense to say something like "There are not currently any broadly accepted semantics for r-components at the time of this writing which may be grounds to be cautious with their use" in this document? > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > >=20 > > I'm a little confused on some of the places in the text that talk > > about URN:NBNs being "generated from" NBNs (and non-reuse > > thereafter) or restrictions on URN:NBN assignment (e.g., > > uniqueness). The procedure seems to be basically deterministic for > > creating a URN:NBN once an NBN is assigned, and potentially > > something that could be done by any party in possession of the NBN > > (i.e., not necessarily the registration authority that created the > > NBN). So I'm not sure why the act of generating the URN:NBN has any > > significance, if anyone could do it -- the restrictions would need > > to apply at NBN assignment time in order to be useful. (This kind > > of gets into Ben's DISCUSS point, too, in the sense that we can only > > say what prerequisites there are for national library NBN allocation > > policies in order for them to be useful with URN:NBN, but they can > > in principle do whatever they like and choose to not use URN:NBN.) >=20 > Yes, the process of creating a URN from an NBN is trivial (modulo > potentially interesting encoding of non-ASCII characters). I think the > point of the text is that an NBN URN is not exactly the same as an NBN. > Perhaps that could be worded more clearly. Okay. (I don't think I have any suggestions for different text.) > > Section 3.2 > >=20 > > From the library community point of view it is important that the > > f-component is not a part of the NSS and therefore f-component > > attachment does not mean that the relevant component part is > > identified. Moreover, the resolution process still retrieves the > > entire resource even if there is an f-component. The fragment > > selection is applied by the resolution client (e.g., browser) to the > > media returned by the resolution process. In other words, in this > > latter case the fragments are logical and physical components of the > > identified resource whereas in the former cases these "fragments" are > > actually complete, independently named entities. > >=20 > > I'm not sure I'm understanding this correctly -- is the "former > > case" the thing that libraries should not do, namely, including the > > f-component in the NSS? >=20 > Now that you point it out, I'm not sure what the former case is. > Formally speaking the f-component simply is not part of the NSS, see the > ABNF in RFC 8141. I guess we should wait for Juha to clarify. > > If an NBN identifies a work, descriptive metadata about the work > > SHOULD be supplied. The metadata record MAY contain links to > > Internet-accessible digital manifestations of the work. > >=20 > > This left me confused. Is it only intended to apply in the case > > described in the previous paragraph, where the resource identified > > by the NBN is not available in the Internet? Or does it always > > apply, forcing the metadata to take precedence over delivering the > > actual work? (Or maybe I'm just confused, and there's an easy way > > to deliver both metadata and the actual work alongside each other > > with no ambiguity.) >=20 > Juha can clarify this. >=20 > > Section 4.1 > >=20 > > National Bibliography Number (NBN) is a generic term referring to a > > group of identifier systems administered by the national libraries > > and institutions authorized by them. > >=20 > > "the national libraries" implies a specific set -- which ones? It > > may be better to hedge with "some national libraries". >=20 > Or remove "the" ... "by national libraries". That's probably better :) Thanks, Benjamin > > Section 4.2.2 > >=20 > > Do we need to say anything about a URN-to-URI step before talking > > about URI-to-resource services? > >=20 > > I'm also wondering about any relationship between "component > > resource" NBNs and f-components of the containing work. If there is > > are NBNs assigned to both an image within a work and that containing > > work, and an NBN with f-resource is used to refer to the image > > within the containing work, is there any relationship between the > > f-resource and the image-specific NBN? > >=20 > > Section 4.3 > >=20 > > Expressing NBNs as URNs is usually straightforward, as only ASCII > > characters are allowed in NBN strings. If necessary, NBNs MUST be > > translated into canonical form as specified in RFC 8141. > >=20 > > When is it necessary? >=20 > It seems that in theory an NBN itself could contain non-ASCII > characters, whereas an NBN URN and its nbn_string construct can contain > only ASCII characters. At least that is my understanding. >=20 > > Being part of the prefix, sub-namespace identifier strings are case- > > insensitive. They MUST NOT contain any hyphens. > >=20 > > This MUST seems to just duplicate a syntactic requirement from the > > ABNF; is RFC 2119 language really necessary? >=20 > /me shrugs >=20 > > Section 8 > >=20 > > John Klensin provided significant editorial and advisory support for > > late versions of the draft. > >=20 > > Presumably that's "later versions"? >=20 > Yes. >=20 > Peter >=20 >=20 --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAlsa59YACgkQKNmm82Tr dRIYwgwg5O5lZEFiDazj4Hb8vxxikuSanHjGfJ3qKZo9Bmff1p0NtJRVMBFYux5a OE5vy5qkMHdexGLR3C4cl1iwZEPkhpVWoDS6WJ10QzY341BlFuh3mMr4qtciIu8W 9JoxBjoD2oPT3hdL6Nh5+dQH1b8t+EMBY2vPI7uM7+bb1UvYucx0+/ISuSTa1GT7 ASu6Rfj5PF7jg+KCfN+5JHSP3Zu3vuwhQeoP3CRqe2aUC+tUf5Kie7y3bdQOQl6U u9E7NZUkPkSo/PUshFK3Pt46v2OwIy9KbQIJUJv+vmGkfy/G50cDWHgguMl4EKIF 4Xlzem54C4H8yNIgYE/y/6msXSSiiJXiFraWaJvrADq51n0r1yCx67l1Ob2XW/uF wJyJHq46BiL6h95xx0f3kxdo8aX1WLQEKKNffEgC0m/snhd+6vGmltN9PDGOVtBM lHbSjfevKPc6YjVzDe1V5nA8N7qTHjEHU4ONgiqHBA0ciqLmfL687tfaBjO6+vVN f5nE3e+ARB2iGQ== =q21Z -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q-- From nobody Fri Jun 8 17:18:18 2018 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E63130DE7; Fri, 8 Jun 2018 17:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 DifxEbhvdlTG; Fri, 8 Jun 2018 17:18:12 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFBAF130DE5; Fri, 8 Jun 2018 17:18:12 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id z1-v6so7085065pgv.12; Fri, 08 Jun 2018 17:18:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mvr9veE+hqIbO4zv+kTh7VI/f3FwzoElAjfwfALo7uA=; b=kJx/wPCFfHRRJrHuWK53MV6VzN034KwWCk5dgSquWNkL+0eLoCT8TICNLOt546ylrG 2BBF8SOcTOfZKwMfZy8iBs/RXDlrVJdqH8UVUJw7Cwws78L/kckecK1/G9X9YrbgxzAK gXCUN33J89OiqyEcrtelkvVGvJTD3UME26W6ZS+alTBqoK8fw4YG6YMJpjTZ1nwpwzj1 heQQwKCrtRrRENw+KaEEugoFygyR54/sNmP6/RrNsH0N0Fap3DW7BT0NKjoZM+e38set tHJDGbHd/hiBXCKxau1wMdQm6DJLA72u1M45ldd9CCAQEyZJ7dmzEcH1jPv1VEnMr+2n Iodw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mvr9veE+hqIbO4zv+kTh7VI/f3FwzoElAjfwfALo7uA=; b=Pa/y6GA0iNEdnFHVc5NIMtpO9LCmOEDTqRYWye94JvJd7/0n06lxXsLtPdl74Q3cZi 7vIBv+Kt0sQPiq4rzTpcMA5g37xo5Jw6/bNyJi7ELdRjVovtFh41DD0+3TVACzo6rCMV TqkXDbcfnQ4Je/DO240r0jE7HB2svsF8fsau73rcgxuKa5sdTuaIYKejHRff36HxdmNt iRHFZ0wAuSM2yGGi0MfdqPak6yzNOOPc4W6zmi68yip4A6rZsHqB45vtmnTCOdN8wm6O oB50q8q8FBWV1BCyew77rc5k2YpHI5t+LPBKKGNPcftyeVUjYfFt/d9rYqZ0Pk28tWkg rmnA== X-Gm-Message-State: APt69E3XlU2luHZKt1Gp73UKkwlabx6ljuMs3PwIqGmJGb6xzOTejASv oRvkZmrTJqD5sbybMW9YvC0Zds4v X-Google-Smtp-Source: ADUXVKKj1ljMxCWLZ5tbmbAT1YAlp/60sSTSxxcLEm4dxELXwrbl8bDSa3b+80pAXPdB2rx+JIU44w== X-Received: by 2002:a63:67c4:: with SMTP id b187-v6mr6848696pgc.86.1528503491940; Fri, 08 Jun 2018 17:18:11 -0700 (PDT) Received: from ?IPv6:2601:647:4700:1280:433:2e83:815e:b150? ([2601:647:4700:1280:433:2e83:815e:b150]) by smtp.gmail.com with ESMTPSA id b74-v6sm81702355pfl.138.2018.06.08.17.18.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Jun 2018 17:18:11 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <241B7429-246F-4D13-9402-393315B4727A@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_40394527-3DB5-40BF-99A8-1B09392739BA" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Fri, 8 Jun 2018 17:18:09 -0700 In-Reply-To: <87fu1yhwlk.fsf@hobgoblin.ariadne.com> Cc: Peter Saint-Andre , Ignas Bagdonas , draft-mahesh-etsi-urn@ietf.org, "Dale R. Worley" To: urn@ietf.org References: <87fu1yhwlk.fsf@hobgoblin.ariadne.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [urn] New Version Notification for draft-mahesh-etsi-urn-03.txt (Was Re: URN expert review of 'etsi' NID) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2018 00:18:15 -0000 --Apple-Mail=_40394527-3DB5-40BF-99A8-1B09392739BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The following update to the draft addresses the comments raised as part = of expert review. The remaining action items are for us to make = available a public version of the ancillary document, whose URL was = provided in the draft, that describes: - the NSS namespace and how it will be allocated by ETSI - how a separate =E2=80=9Croot=E2=80=9D namespace under the allocated = URN can be used for experimental namespaces. Thanks --------------------------------------------------- A new version of I-D, draft-mahesh-etsi-urn-03.txt has been successfully submitted by Mahesh Jethanandani and posted to the IETF repository. Name: draft-mahesh-etsi-urn Revision: 03 Title: URN Namespace for ETSI Documents Document date: 2018-06-08 Group: Individual Submission Pages: 6 URL: = https://www.ietf.org/internet-drafts/draft-mahesh-etsi-urn-03.txt = Status: https://datatracker.ietf.org/doc/draft-mahesh-etsi-urn/ = Htmlized: https://tools.ietf.org/html/draft-mahesh-etsi-urn-03 = Htmlized: = https://datatracker.ietf.org/doc/html/draft-mahesh-etsi-urn = Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-mahesh-etsi-urn-03 = Abstract: This document describes the Namespace Identifier (NID) 'etsi' for Uniform Resource Names (URNs) used to identify resources published by European Telecommunications Standards Institute (http://etsi.org = ). ETSI specifies and manages resources that utilize this URN identification model. Management activities for these and other resources types are handled by the manager of the ETSI Protocol Naming and Numbering Service (PNNS). Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org = . The IETF Secretariat > On Jun 7, 2018, at 6:53 PM, Dale R. Worley wrote: >=20 > Comments on draft-mahesh-etsi-urn-02 >=20 > 1.1. Terminology >=20 > | PNNS | Protocol Name and Numbering Service | >=20 > It would be helpful to state that PNNS is an ETSI function: >=20 > | PNNS | ETSI Protocol Name and Numbering Service | >=20 > Declaration of syntactic structure: >=20 > The syntax of namespace specific strings for the 'etsi' namespace > is in Uniform Resource Names (URNs) [RFC8141]. >=20 > This is completely legitimate, but it is not satisfying. If ETSI has > plans for how it will organize the space of NSSs, it would be nice to > describe them here. >=20 > Relevant ancillary documentation: >=20 > ETSI publishes information regarding the registered resources in > the ETSI URN Namespace (EUN) registry > (https://portal.etsi.org/PNNS/GenericAllocation/ > ETSIURNNamespace.aspx). >=20 > It's good that ETSI gives the URL of its URN registry; many other > organizations do not. However, I notice that that URL is > password-protected. It would be much better for the community if the > registry was readable by the world, since there is no stated intention > that etsi URNs are used only within a closed community. >=20 > Identifier uniqueness considerations: >=20 > [...] ETSI is expected to guarantee the uniqueness [...] >=20 > Formally, this registration is being submitted by ETSI, so it reads > oddly for ETSI to say "ETSI is expected...". Much better would be > "ETSI will...". >=20 > Similarly, "ETSI could..." is used where it is more natural to say = "ETSI > may...". >=20 > Note that using experimental types may create > collision as multiple users may use the same values for different > resources and specific strings. >=20 > It would be very helpful if the registration stated how the ETSI > registry will make clear how to recognize experimental URIs within the > etsi namespace. >=20 > Dale Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_40394527-3DB5-40BF-99A8-1B09392739BA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = following update to the draft addresses the comments raised as part of = expert review. The remaining action items are for us to make available a = public version of the ancillary document, whose URL was provided in the = draft, that describes:

- the NSS namespace and how it will be allocated by = ETSI
- how a separate =E2=80=9Croot=E2=80=9D = namespace under the allocated URN can be used for experimental = namespaces.

Thanks
---------------------------------------------------

A new = version of I-D, draft-mahesh-etsi-urn-03.txt
has been = successfully submitted by Mahesh Jethanandani and posted to the
IETF repository.

Name: = draft-mahesh-etsi-urn
Revision: 03
Title: URN Namespace for ETSI Documents
Document = date: = 2018-06-08
Group: Individual Submission
Pages: 6
URL: =            https://www.ietf.org/internet-drafts/draft-mahesh-etsi-urn-03.t= xt
Status: =         https://datatracker.ietf.org/doc/draft-mahesh-etsi-urn/
Htmlized:       https://tools.ietf.org/html/draft-mahesh-etsi-urn-03
Htmlized:       https://datatracker.ietf.org/doc/html/draft-mahesh-etsi-urn=
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-mahesh-etsi-urn-03

Abstract:
  This = document describes the Namespace Identifier (NID) 'etsi' for
  Uniform Resource Names (URNs) used to identify = resources published by
  European = Telecommunications Standards Institute (http://etsi.org).
  ETSI = specifies and manages resources that utilize this URN
  identification model.  Management activities = for these and other
  resources types are = handled by the manager of the ETSI Protocol
  Naming and Numbering Service (PNNS).




Please note that it may take a couple of minutes from the = time of submission
until the htmlized version and diff are = available at tools.ietf.org.

The IETF = Secretariat

On Jun 7, 2018, at 6:53 PM, Dale R. Worley = <worley@ariadne.com> wrote:

Comments on draft-mahesh-etsi-urn-02

  1.1.  Terminology

      | PNNS =    | Protocol Name and Numbering Service =             |<= br class=3D"">
It would be helpful to state that PNNS is = an ETSI function:

=       | PNNS    | ETSI = Protocol Name and Numbering Service =        |

=   Declaration of syntactic structure:

     The syntax of namespace = specific strings for the 'etsi' namespace
=      is <NSS> in Uniform Resource Names = (URNs) [RFC8141].

This is completely = legitimate, but it is not satisfying.  If ETSI has
plans for how it will organize the space of NSSs, it would be = nice to
describe them here.

=   Relevant ancillary documentation:

     ETSI publishes information = regarding the registered resources in
=      the ETSI URN Namespace (EUN) registry
     (https://portal.etsi.org/PNNS/GenericAllocation/
     ETSIURNNamespace.aspx).

It's good that ETSI gives the URL of its URN = registry; many other
organizations do not.  However, = I notice that that URL is
password-protected.  It = would be much better for the community if the
registry was = readable by the world, since there is no stated intention
that etsi URNs are used only within a closed community.

  Identifier uniqueness = considerations:

=      [...]  ETSI is expected to guarantee = the uniqueness [...]

Formally, this = registration is being submitted by ETSI, so it reads
oddly = for ETSI to say "ETSI is expected...".   Much better would = be
"ETSI will...".

Similarly, = "ETSI could..." is used where it is more natural to say "ETSI
may...".

=      Note that using experimental types may = create
     collision as = multiple users may use the same values for different
=      resources and specific strings.

It would be very helpful if the registration = stated how the ETSI
registry will make clear how to = recognize experimental URIs within the
etsi namespace.

Dale

Mahesh Jethanandani
mjethanandani@gmail.com

= --Apple-Mail=_40394527-3DB5-40BF-99A8-1B09392739BA-- From nobody Sat Jun 9 13:20:53 2018 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8A9130F76; Sat, 9 Jun 2018 13:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no 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 iHGi58RHkCud; Sat, 9 Jun 2018 13:20:49 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FD92130F74; Sat, 9 Jun 2018 13:20:49 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1fRkLu-000MSW-H6; Sat, 09 Jun 2018 16:20:46 -0400 Date: Sat, 09 Jun 2018 16:20:39 -0400 From: John C Klensin To: Benjamin Kaduk , Peter Saint-Andre cc: urn@ietf.org, The IESG , draft-hakala-urn-nbn-rfc3188bis@ietf.org Message-ID: In-Reply-To: <20180608203227.GD16349@kduck.kaduk.org> References: <152837409539.30768.4568779645299135020.idtracker@ietfa.amsl.com> <6a1a100c-3bc0-76d3-3ae4-047d37906bfc@mozilla.com> <20180608203227.GD16349@kduck.kaduk.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] Benjamin Kaduk's Discuss on draft-hakala-urn-nbn-rfc3188bis-01: (with DISCUSS and COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2018 20:20:52 -0000 --On Friday, June 8, 2018 15:32 -0500 Benjamin Kaduk wrote: >> The semantics of r-components are yet to be defined. I would >> venture that the IETF is probably not the right place to do >> that work, given how little energy remained in the URN WG at >> the end (and we probably didn't have the right people in the >> room in the first place). > > I won't argue with that. Does it make sense to say something > like "There are not currently any broadly accepted semantics > for r-components at the time of this writing which may be > grounds to be cautious with their use" in this document? Perhaps. But see below. >... >> > If an NBN identifies a work, descriptive metadata about >> > the work SHOULD be supplied. The metadata record MAY >> > contain links to Internet-accessible digital >> > manifestations of the work. >> > >> > This left me confused. Is it only intended to apply in the >> > case described in the previous paragraph, where the >> > resource identified by the NBN is not available in the >> > Internet? Or does it always apply, forcing the metadata to >> > take precedence over delivering the actual work? (Or maybe >> > I'm just confused, and there's an easy way to deliver both >> > metadata and the actual work alongside each other with no >> > ambiguity.) >> >> Juha can clarify this. In the interest of saving time, I can probably get this one. The answer is "yes", this is intended to be about works not accessible on the Internet (although a very similar issue applies in at least one case where the NBN describes a conceptual work whose components also have NBNs, but not all of the components are available on the Internet. The extra paragraph break my be my fault as periodically serving as copy editor on the I-D. >> > Section 4.1 >> > >> > National Bibliography Number (NBN) is a generic term >> > referring to a group of identifier systems administered >> > by the national libraries and institutions authorized by >> > them. >> > >> > "the national libraries" implies a specific set -- which >> > ones? It may be better to hedge with "some national >> > libraries". >> >> Or remove "the" ... "by national libraries". > That's probably better :) That would be my preference, but Juha should decide on this. >> > Section 4.2.2 >> > >> > Do we need to say anything about a URN-to-URI step before >> > talking about URI-to-resource services? Given what 3986 has to say, a URN-to_URI step would be an oxymoron. If you meant a URN-to-URL step, that is probably a matter for 8141 and it may be worth pointing out that members of the web community (a euphuism for a particular, mostly known, set of individuals who claim to speak for that community in case you haven't figured that out) have been violently opposed to such text, claiming that, if it is needed, then there is really no need for URNs. On the other hand, while the URNBIS WG could not reach consensus on any particular proposal and did reach consensus about not trying to proceed with definitions, that is much of what r-components are expected to be about. >> > I'm also wondering about any relationship between "component >> > resource" NBNs and f-components of the containing work. If >> > there is are NBNs assigned to both an image within a work >> > and that containing work, and an NBN with f-resource is >> > used to refer to the image within the containing work, is >> > there any relationship between the f-resource and the >> > image-specific NBN? On a per-sub-namespace basis, possibly. In the general case, maybe. This is not an NBN issue but an issue about how namespaces are managed, organized, and used, i.e., probably an 8141 issue. >> > Section 4.3 >> > >> > Expressing NBNs as URNs is usually straightforward, as >> > only ASCII characters are allowed in NBN strings. If >> > necessary, NBNs MUST be translated into canonical form >> > as specified in RFC 8141. >> > >> > When is it necessary? >> >> It seems that in theory an NBN itself could contain non-ASCII >> characters, whereas an NBN URN and its nbn_string construct >> can contain only ASCII characters. At least that is my >> understanding. That is correct. But, more or less per 3986, _any_ URI can contain non-ASCII characters in the tail by %-encoding them. There were some moves in the URNBIS WG to restrict that for URNs, but it met resistance from the usual suspects. The bottom line here, and I don't know how loudly to say it, is that using non-ASCII characters in nbn_strings would probably nothing short to stupid, especially given that both IETF and W3C have suggested that they be avoided in identifiers non-specialist end users are not expected to see. However, due to a problem that goes back well before the early decision that ISO 8859-1 was going to be an adequate encoding for HTMP content (but of which that decision is symptomatic), it would be unsurprising if one or more national libraries whose local language uses Latin script with a few lightly-decorated characters had not taken that advice or had decided to incorporate existing (perhaps for decades) identifier strings with a few Latin characters outside the ASCOO subset into their national NBNs. One could imagine rewording the text mentioned above for more clarity (a job I will happily leave to the experts who make up the RFC Editor function) but the bottom line is that all we do is to say "don't do that, but if you decide to do it anyway, this is what you must do to prevent even worse problems". >> > Being part of the prefix, sub-namespace identifier >> > strings are case- insensitive. They MUST NOT contain >> > any hyphens. >> > >> > This MUST seems to just duplicate a syntactic requirement >> > from the ABNF; is RFC 2119 language really necessary? >> /me shrugs Probably not, but, while Juha should confirm, I assume that part of the origin of this text is that several other International Standard identifiers, e.g., ISBNs, all hyphens and treat them as optional. It might be wise to reinforce the message that the URN:NBN solution to the problems that causes is to clearly say "no" and say that clearly enough that even those whose eyes glaze over at ABNF will get the message. Whether it is better done by something like the sentences above or by saying "Hyphens are prohibited by the ABFN, see Section XXXX" is, IMO, a matter of editorial style and preference. >> > Section 8 >> > >> > John Klensin provided significant editorial and advisory >> > support for late versions of the draft. >> > >> > Presumably that's "later versions"? >> >> Yes. I really don't care. If one thinks this is an editorial problem, leave it to the RFC Editor. If one thinks it is substantive, remember that, while this is a -00 draft, the I-D itself has been through many iterations under other names, so it depends on how you count because I had nothing to do with early version of the I-D and at most only a reviewer/participant role in RFC 3188. If this were a different sort of document and I cared, I could make a strong case that I've been involved enough and have written enough text to be listed as a Contributor, but I think the nature of this document is that it is better if Juha is sole author without contributors other than Alfred. FWIW, I can't see why attribution at this level should be an IESG problem unless you have reason to believe that IPR rules are being violated. Finally, to avoid writing a separate note even though it will make this a paragraph longer, I think several of the comments you )Benjamin) and Adam have made make a strong case for a clarifying update to RFC 8141. In principle, I agree with that. It is little surprise to me that new URN namespace proposals are exposing issues that, if we had more ability to predict them, would have been reflected in 8141 itself. The difficulty with such an update is that, at the time 8141 and 8254 were completed, the URNBIS WG had run out of energy and was developing a level of acrimony that made further progress unlikely. If we were to try to open 8141 to do a clarification, I can just about guarantee that some of those who were the sources of frustration that led to that acrimony would insist that no document move forward until their pet issues and easy solutions were addressed. That, in turn, would result in a situation like the i18n one, only with less downside if the issues are not addressed and more issues that soul require solving fundamental philosophical disagreements in IETF community. I can't recommend going there, but it doesn't seem to me that trying to clarify 9141 by text in a single namespace definition is the solution either. best, john From nobody Sun Jun 10 10:02:55 2018 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74BD130E91 for ; Sun, 10 Jun 2018 10:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 6eGBKvWlQJWp for ; Sun, 10 Jun 2018 10:02:50 -0700 (PDT) Received: from sonic306-26.consmr.mail.gq1.yahoo.com (sonic306-26.consmr.mail.gq1.yahoo.com [98.137.68.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97FE1130E90 for ; Sun, 10 Jun 2018 10:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1528650169; bh=2kZw320dW7OMgN8Cf8vtxwcQYSGVkTw7aB/DW7AqhKo=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=bAYEaSX21Z1Dpy++lSRiOtPEOdYVohWZyuy+ckVnWvn2U+rS34gKZQbXIV8A08hB/ggLtt2nTundnkn6aHEoFOu/N5YmisJfDiC9eshKdX0k2Ql+gS8RBXWRbz4zkul3O/nKdifAmUkSmiaDxM5HFVgeomFg9ZLV7N7iO/BjaksvaNJxFwsj3T+sv2XG7lIFxeH1i4SN826e12ozq3mrFl35ON48XOcRl95wC0sWeeIsCyt0/csPLDuXy6yXL79HS7T93oU8ceNEbs01LZHT8THVX5cd99WRsPWHE4rdUCs1yYY7JnsfrVOXMRB0n//Sz1PsbsS42qRvAwLb7nbeoA== X-YMail-OSG: eG.ZejUVM1mMjL2E5RAQimPCHEgZ72hApU0rKeXAhxzJZ704oS2WjghQLtNXepX 4cs4gCBVuqKNEVfmf9xJC4rOwQWjq1LJXdUvjyzDfRDwK7eUU4nPn8OgwvkkDUDWahl5Msyp1m3n LgpUnH32R4Q.yqb2ss2lhTcZhwB92z6A2PTbRAslsXRfhayOFPzV7MevAYZgZa.v2lfbeCvn0DIr _73DYukKRD6OTqp7uo5y9oiDsFAbXAM.Dg9rjyMJYmggEZoC2RAe7Cxc.HOx9hJG0zYy6foUHEgZ mWGqBQfiNDKxnLxzozUA.6mkQdv0yiWg9KiCEZY.wuUCN31EN2nml4SKvOjAKCrID8zjZQrUyoB2 aJIo.bfea1.nm35FpHo71FuFh.12qM4KSsVDdvT4cEtao3NN2OhbXqm2Sm_PQ7tGz35k8R1llaUz AJGHBsJPpCQI_bv7sGfZbSvAhX0uIOBkumrtpIDPwjb_.WS6yHjIU8QeqcLg8dYN.j29KoqPcSgG DCllNL3wW3oLi0slq6Mhsl901H86gDyDxyKZ79ZDFcONMxCT2daQP5OVLgoIl9qIPgG8rkuIIPPt 0mZD5yOaaIMJVh9Icd8COSnZIFM59IljMzmJdAdUXI6a3GXWw79aYqTXFS9h4OLzSNa_tgTxzFwW 6fkc3gh.wA6BuLOLUq3GSC.UBGljoSRAwy9XGVUxg7aQc7FKgZI_tLDRmnvtuSuBgLzEEJPlMaxS 1HtpUvZpFOyulqtiaKrmpPI2BB5KQujuMmQHgOpR1Fww5UXlL8l8W2z9Yqg1srAE9wwa585ENbs9 o4uO3rPn6YdebWbkhLi3XzSr7kWrTStVJy4MDKH_5LUjmwGBygizGYh3.WxdbK8MijqVOxUvHlw6 7kOIOnhCl8017Lc2U4uzJLzMBUHc7gH3MIzs64iTpXMIRfG8rImNnV8gZjPdVYdyKCsxc.a4RalA wKRzVZwYSOIB0nrtDFAI0JYV3wrBnW7ayMcjIv8PY6kTdRZLLSxed2v13_WCt3hY- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sun, 10 Jun 2018 17:02:49 +0000 Date: Sun, 10 Jun 2018 17:02:48 +0000 (UTC) From: R Atarius Reply-To: R Atarius To: "jbakker@blackberry.com" , "l.svensson@dnb.de" , "urn@ietf.org" , "r_atarius@yahoo.com" , Ben Campbell , "Dale R. Worley" , Georg Mayer , Peter Saint-Andre Message-ID: <1044825299.2658476.1528650168493@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2658475_1250308688.1528650168492" References: <1044825299.2658476.1528650168493.ref@mail.yahoo.com> X-Mailer: WebService/1.1.11950 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36 Archived-At: Subject: [urn] draft-atarius-dispatch-meid-urn-18 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 17:02:53 -0000 ------=_Part_2658475_1250308688.1528650168492 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello all, A new draft has now be submitted. ThanksRoozbeh=C2=A0 https://www.ietf.org/id/draft-atarius-dispatch-meid-urn-18.txt ------=_Part_2658475_1250308688.1528650168492 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all,

A new draft has now be su= bmitted.

Th= anks
Roo= zbeh 


------=_Part_2658475_1250308688.1528650168492-- From nobody Mon Jun 11 01:42:25 2018 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280BA130E17; Mon, 11 Jun 2018 01:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=helsinkifi.onmicrosoft.com 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 TIj-7GFjK6Ry; Mon, 11 Jun 2018 01:42:13 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0103.outbound.protection.outlook.com [104.47.0.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B364130E13; Mon, 11 Jun 2018 01:42:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=HelsinkiFI.onmicrosoft.com; s=selector1-helsinki-fi; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=f8NBb67Fp2QDe3D2jfcodGyQZKopSO3pttMaVClWNoA=; b=hpiDeHtp0FPbTPw1C0h5PrvxHtoi2s3NDumD24KwU4cdHXXNk71to26rZ4jgCZ7JarLwgLl3NZTNMXF7zsL7xEYWfnmtXYcUsc3uk+PZmb4cQgTwunRNLaS0Xp0VRXiTuZXT7BoNzUmXlpgbkr4iB95eZrWsnhNRuhxtfqFGghU= Received: from HE1PR07MB3097.eurprd07.prod.outlook.com (10.170.244.159) by HE1PR07MB1545.eurprd07.prod.outlook.com (10.169.122.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.11; Mon, 11 Jun 2018 08:42:07 +0000 Received: from HE1PR07MB3097.eurprd07.prod.outlook.com ([fe80::3469:f3e:fa6b:5f0e]) by HE1PR07MB3097.eurprd07.prod.outlook.com ([fe80::3469:f3e:fa6b:5f0e%3]) with mapi id 15.20.0841.019; Mon, 11 Jun 2018 08:42:07 +0000 From: "Hakala, Juha E" To: John C Klensin , Benjamin Kaduk , Peter Saint-Andre CC: "urn@ietf.org" , The IESG , "draft-hakala-urn-nbn-rfc3188bis@ietf.org" Thread-Topic: [urn] Benjamin Kaduk's Discuss on draft-hakala-urn-nbn-rfc3188bis-01: (with DISCUSS and COMMENT) Thread-Index: AQHT/lod/sLH3rHscE+TRo/6OiegFaRVODGAgAGavwCAAY8FgIACJmWw Date: Mon, 11 Jun 2018 08:42:07 +0000 Message-ID: References: <152837409539.30768.4568779645299135020.idtracker@ietfa.amsl.com> <6a1a100c-3bc0-76d3-3ae4-047d37906bfc@mozilla.com> <20180608203227.GD16349@kduck.kaduk.org> In-Reply-To: Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.214.147.95] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB1545; 7:wue7qdvEV/NZ2fVMfnorXcHh3t5jyNf3GxjEhw1StdGHtEccTiE1bDyWAP43t+3PjQK8ujKQ6gtjks21t5nMnWOdQ8Z2B9kgjc91uvHR5bxLMXvYYF3e2/hmnrjCYwwpqU7WNdC/iT0Nix/G2xz5SlHnq2FGLoPmU8PRNtHOOIj3iNWkgs8Lqx74OKbPy0PCZBB6blClnQ9LLl6A0PnJ+xLIolj3MRg2gadocSinGDJStc48CCwAhEja3LlJlIAZ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB1545; x-ms-traffictypediagnostic: HE1PR07MB1545: authentication-results: spf=none (sender IP is ) smtp.mailfrom=juha.hakala@helsinki.fi; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(100405760836317)(240460790083961); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231254)(11241501184)(806099)(944501410)(52105095)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:HE1PR07MB1545; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1545; x-forefront-prvs: 070092A9D3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(346002)(366004)(39860400002)(39380400002)(189003)(52314003)(199004)(13464003)(57704003)(6246003)(105586002)(305945005)(53936002)(68736007)(2171002)(53946003)(3660700001)(25786009)(106356001)(76176011)(26005)(97736004)(74482002)(99286004)(6506007)(7736002)(59450400001)(3280700002)(93886005)(74316002)(486006)(4326008)(55016002)(186003)(7696005)(8936002)(102836004)(86362001)(478600001)(14454004)(476003)(5660300001)(786003)(2900100001)(561944003)(316002)(5250100002)(33656002)(446003)(966005)(11346002)(54906003)(110136005)(229853002)(2906002)(8676002)(6436002)(66066001)(9686003)(6116002)(6306002)(3846002)(81156014)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1545; H:HE1PR07MB3097.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: helsinki.fi does not designate permitted sender hosts) x-microsoft-antispam-message-info: yA4zZnNMQBwPzdPYwgIERiV+AxI6ToHlJNul3BUB6uQkxmyJLjrrgBm6eKq4iZhaeBFBuaG/3g+vB9lMkCrZ7ny/skz8kuA/IZu8S2rXdL+tEjSfD98Z+9SEgvb0iQCNE5H7MsqZaz7d6sfV/Mcrem3JX0WO4DL/WWd7SxdEUuSO8+MpGS3DN1AbV4/0JlqPI7jwNihjUVbeuipwy7ayEQ9iDb/2zD+g0chf1P+Mupc/LNB3u3O0uVippkzhozyn spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 393b1ca2-83bd-4432-47e1-08d5cf773734 X-OriginatorOrg: helsinki.fi X-MS-Exchange-CrossTenant-Network-Message-Id: 393b1ca2-83bd-4432-47e1-08d5cf773734 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2018 08:42:07.5963 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1545 Archived-At: Subject: Re: [urn] Benjamin Kaduk's Discuss on draft-hakala-urn-nbn-rfc3188bis-01: (with DISCUSS and COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 08:42:19 -0000 Hello, comments inline.=20 -----Original Message----- From: urn On Behalf Of John C Klensin Sent: lauantai 9. kes=E4kuuta 2018 23.21 To: Benjamin Kaduk ; Peter Saint-Andre Cc: urn@ietf.org; The IESG ; draft-hakala-urn-nbn-rfc3188bis= @ietf.org Subject: Re: [urn] Benjamin Kaduk's Discuss on draft-hakala-urn-nbn-rfc3188= bis-01: (with DISCUSS and COMMENT) --On Friday, June 8, 2018 15:32 -0500 Benjamin Kaduk wrote: >> The semantics of r-components are yet to be defined. I would venture=20 >> that the IETF is probably not the right place to do that work, given=20 >> how little energy remained in the URN WG at the end (and we probably=20 >> didn't have the right people in the room in the first place). Juha: in order to avoid chaos, URN user community needs a centrally maintai= ned registry of resolution services and parameters related to them. As far = as I am concerned, r-component syntax and semantics should not be user- or = namespace-specific, it has to apply to all namespaces. So if somebody esta= blishes r-component syntax for requesting a Dublin Core metadata record abo= ut the identified resource, the components used should be registered. And b= efore creating the r-component, URN users should check from the registry if= the required components (service and parameters) exist already. =20 While writing the I-D, my assumption was that r-component usage will only s= tart once there is an agreement on r-component syntax, and there is a centr= al registry for services specified. Developing syntax should not be rocket = science; what we need is a way to specify services and parameters related t= o them in a machine readable way.=20 Assuming that each r-component is allowed to contain one and only one servi= ce and 0-n parameters related to it, syntax might look like this:=20 s=3D&=3D&=3D&...&=3D for instance:=20 s=3DURC&format=3DDC to request metadata about the identified resource in Dublin Core format. I= am sure that people who are more technically oriented than myself will com= e up with something better than my example, but the components (services an= d their parameters) should be the same.=20 Generic r-component syntax can be specified without any knowledge about the= resolution services to be supported, but service specific details may only= be provided by experts who know how current applications operate. I do hop= e that IETF experts can assist with syntax definition; once that (and the r= egistry) is in place, URN user communities can start providing service leve= l specifications.=20 Users of persistent identifiers (DOI, Handle, ARK, URN) are all currently u= nder pressure to enrich the functionality of resolvers. Unless a central (a= nd shared) registry of resolution services is established, there is a clear= danger that each identifier system will develop its own solutions, which w= ill seriously limit interoperability between persistent identifier systems.= =20 > I won't argue with that. Does it make sense to say something like=20 > "There are not currently any broadly accepted semantics for=20 > r-components at the time of this writing which may be grounds to be=20 > cautious with their use" in this document? Juha: such text can be added as a clarification. Since my assumption has be= en that the r-component will not be used at all before we have generally ap= proved syntax and semantics for it, I might use even stronger formulation t= han just "cautious". But as noted above, I did not say anything about this = because I thought that non-usage of r-component applies automatically to al= l URN namespaces as long as r-component syntax is still work in progress. I= t seems a bit redundant to repeat the same thing in all namespace registrat= ions.=20 Having said that, I do hope that the syntax will be formally specified soon= , so that the URN user communities can start adding service level specifica= tions into the central registry (which should also be there from the beginn= ing). =20 >> > If an NBN identifies a work, descriptive metadata about >> > the work SHOULD be supplied. The metadata record MAY >> > contain links to Internet-accessible digital >> > manifestations of the work. >> >=20 >> > This left me confused. Is it only intended to apply in the case=20 >> > described in the previous paragraph, where the resource identified=20 >> > by the NBN is not available in the Internet? Or does it always=20 >> > apply, forcing the metadata to take precedence over delivering the=20 >> > actual work? (Or maybe I'm just confused, and there's an easy way=20 >> > to deliver both metadata and the actual work alongside each other=20 >> > with no ambiguity.) >>=20 >> Juha can clarify this. Juha: I can understand why this confuses people. Sorry, this bit is library= specific and hard to understand unless the reader knows our practices.=20 Work itself is immaterial. There may be 0-n manifestations of it, some of t= hem hand-held, some digital.=20 Work is an umbrella concept with which it is possible to bring together all= existing manifestations. In practice this can be done by e.g adding to the= work metadata record links to the metadata records describing these manife= stations. A practical example of similar practice is a splash page describi= ng a research data set ("work level metadata"). Such pages often contains l= inks to all versions of the relevant data set, with manifestation level met= adata such as appropriate warnings if some versions of the data set are ver= y large.=20 A user who requires metadata about a work may not even know if there are di= gital manifestations of the work. But with the metadata record the user wil= l be able to find this out, and select the version which suits his/her need= s best. =20 >> > Section 4.1 >> >=20 >> > National Bibliography Number (NBN) is a generic term >> > referring to a group of identifier systems administered >> > by the national libraries and institutions authorized by >> > them. >> >=20 >> > "the national libraries" implies a specific set -- which ones? It=20 >> > may be better to hedge with "some national libraries". >>=20 >> Or remove "the" ... "by national libraries". > That's probably better :) That would be my preference, but Juha should decide on this. Juha: by national libraries is better.=20 >> > Section 4.2.2 >> >=20 >> > Do we need to say anything about a URN-to-URI step before talking=20 >> > about URI-to-resource services? Given what 3986 has to say, a URN-to_URI step would be an oxymoron. If you= meant a URN-to-URL step, that is probably a matter for 8141 and it may be = worth pointing out that members of the web community (a euphuism for a part= icular, mostly known, set of individuals who claim to speak for that commun= ity in case you haven't figured that out) have been violently opposed to su= ch text, claiming that, if it is needed, then there is really no need for U= RNs. On the other hand, while the URNBIS WG could not reach consensus on a= ny particular proposal and did reach consensus about not trying to proceed = with definitions, that is much of what r-components are expected to be abou= t. >> > I'm also wondering about any relationship between "component=20 >> > resource" NBNs and f-components of the containing work. If there=20 >> > is are NBNs assigned to both an image within a work and that=20 >> > containing work, and an NBN with f-resource is used to refer to the=20 >> > image within the containing work, is there any relationship between=20 >> > the f-resource and the image-specific NBN? On a per-sub-namespace basis, possibly. In the general case, maybe. This is not an NBN issue but an issue about how namespaces are mana= ged, organized, and used, i.e., probably an 8141 issue. Juha: with NBN, national libraries have free hands to specify their own nam= ing policies. They may give just one identifier for e.g. an entire EPUB 3.0= .1 e-book, or they may assign separate identifiers for all the component pa= rts of the e-book. The best policy depends on many things, including the le= vel of control & access required / possible.=20 NBN specification does not specify limits on what can / should be done. If = the library prefers to use f-component to identify for instance images in a= PDF document, that is fine. =20 >> > Section 4.3 >> >=20 >> > Expressing NBNs as URNs is usually straightforward, as >> > only ASCII characters are allowed in NBN strings. If >> > necessary, NBNs MUST be translated into canonical form >> > as specified in RFC 8141. >> >=20 >> > When is it necessary? >>=20 >> It seems that in theory an NBN itself could contain non-ASCII=20 >> characters, whereas an NBN URN and its nbn_string construct can=20 >> contain only ASCII characters. At least that is my understanding. That is correct. But, more or less per 3986, _any_ URI can contain non-ASC= II characters in the tail by %-encoding them. There were some moves in the URNBIS WG to restrict that for URNs, but it me= t resistance from the usual suspects. The bottom line here, and I don't kn= ow how loudly to say it, is that using non-ASCII characters in nbn_strings = would probably nothing short to stupid, especially given that both IETF and= W3C have suggested that they be avoided in identifiers non-specialist end users are not expected to see. However, due to a problem that goes back well before the early decision that ISO 8859-1 was going to be an= adequate encoding for HTMP content (but of which that decision is symptoma= tic), it would be unsurprising if one or more national libraries whose loca= l language uses Latin script with a few lightly-decorated characters had no= t taken that advice or had decided to incorporate existing (perhaps for decades) identifier strings with a few Latin characters outside the ASCOO subset into their national NBNs. One could imagine rewording the text mentioned above for more clarity (a job I will happily l= eave to the experts who make up the RFC Editor function) but the bottom line is that all we do is to say "don't do that, b= ut if you decide to do it anyway, this is what you must do to prevent even = worse problems". =20 Juha: all NBNs I have seen so far have contained just (printable) ASCII cha= racters. But outside Europe there may be national libraries which have been= more liberal. If so, non-ASCII characters in their NBNs must be %-encoded = when these NBNs become URN:NBNs.=20 Nobody knows if there are NBNs with non-ASCII characters, and if so, how co= mmon they are. Therefore I decided to drop the recommendation that such cha= racters should be avoided in NBN strings.=20 In order to clarify text, beginning of 4.3 could be edited into:=20 Expressing NBNs as URNs is straightforward if NBN strings contain only ASCI= I characters. Non-ASCII characters, if any, MUST be translated into canonic= al form as specified in RFC 8141.=20 >> > Being part of the prefix, sub-namespace identifier >> > strings are case- insensitive. They MUST NOT contain >> > any hyphens. >> >=20 >> > This MUST seems to just duplicate a syntactic requirement from the=20 >> > ABNF; is RFC 2119 language really necessary? =20 >> /me shrugs Probably not, but, while Juha should confirm, I assume that part of the ori= gin of this text is that several other International Standard identifiers, = e.g., ISBNs, all hyphens and treat them as optional. It might be wise to reinforce the message that the URN:NBN solution to the problems that causes is to clearly say "no" and say= that clearly enough that even those whose eyes glaze over at ABNF will get the message. Whether it is better done by something like the sentences above or by saying "Hyphens are prohib= ited by the ABFN, see Section XXXX" is, IMO, a matter of editorial style an= d preference. Juha: I believe this may be an error inherited from RFC 3188. The forbidden= character should be colon.=20 URN:NBNs with sub-namespaces look like this:=20 urn:nbn:se:uu:diva-284370 This is a Swedish URN:NBN assigned by the Uppsala university. Organization= s which have a sub-namespace may divide their sub-namespace further if nece= ssary, using colons (e.g. Uppsala could create a namespace ID urn:nbn:se:uu= :thesis:). Given the special role the colon has, sub-namespace identifiers = must not contain them, since theoretically allowing colons could cause dupl= icate assignments. So if there is nbn:fi subnamespaces nbn:fi:aa, every NID= in the form nbn:fi:aa: must be a sub-namespace of nbn:fi:aa. = =20 Changing the specification might cause problems with backwards compatibilit= y had some libraries assigned sub-namespaces with colons in them. I don't t= hink that this is the case. So the next version of the I-D could say "MUST = NOT contain any hyphens or colons".=20 =20 >> > Section 8 >> >=20 >> > John Klensin provided significant editorial and advisory >> > support for late versions of the draft. >> >=20 >> > Presumably that's "later versions"? >>=20 >> Yes. I really don't care. If one thinks this is an editorial problem, leave it = to the RFC Editor. If one thinks it is substantive, remember that, while t= his is a -00 draft, the I-D itself has been through many iterations under o= ther names, so it depends on how you count because I had nothing to do with= early version of the I-D and at most only a reviewer/participant role in R= FC 3188. If this were a different sort of document and I cared, I could ma= ke a strong case that I've been involved enough and have written enough tex= t to be listed as a Contributor, but I think the nature of this document is= that it is better if Juha is sole author without contributors other than A= lfred.=20 FWIW, I can't see why attribution at this level should be an IESG problem u= nless you have reason to believe that IPR rules are being violated. Juha: I think "later versions" is fine.=20 Finally, to avoid writing a separate note even though it will make this a p= aragraph longer, I think several of the comments you )Benjamin) and Adam ha= ve made make a strong case for a clarifying update to RFC 8141. In princip= le, I agree with that. It is little surprise to me that new URN namespace proposals are exposing i= ssues that, if we had more ability to predict them, would have been reflect= ed in 8141 itself. The difficulty with such an update is that, at the time= 8141 and 8254 were completed, the URNBIS WG had run out of energy and was = developing a level of acrimony that made further progress unlikely. If we = were to try to open 8141 to do a clarification, I can just about guarantee = that some of those who were the sources of frustration that led to that acr= imony would insist that no document move forward until their pet issues and= easy solutions were addressed. That, in turn, would result in a situation= like the i18n one, only with less downside if the issues are not addressed= and more issues that soul require solving fundamental philosophical disagr= eements in IETF community. I can't recommend going there, but it doesn't se= em to me that trying to clarify 9141 by text in a single namespace definiti= on is the solution either. Juha: library community has been using URN:NBNs succesfully since RFC 3188 = was published. Tens of millions of identifiers have been assigned. From lib= raries' point of view, the important thing is that the revised RFC validate= s some new URN:NBN assignment practices which we did not foresee when RFC 3= 188 was written. I do hope that the revision will not get stuck on technica= lities or philosophical disagreements which have only minor impact on pract= ical work.=20 In the long term I do hope that allowing the use of r-, q- and f-components= will help libraries and other URN users such as film industry to build sma= rter URN resolvers. There is definitely a need for that. =20 All the best,=20 Juha PS. I volunteer to produce the next version of the I-D, but should I use th= e txt or XML version? And if the latter, where do I get it (last time I edi= ted the txt version).=20 _______________________________________________ urn mailing list urn@ietf.org https://www.ietf.org/mailman/listinfo/urn From nobody Wed Jun 13 16:18:40 2018 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAEE130EB1; Wed, 13 Jun 2018 16:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 esYgPHU19bSH; Wed, 13 Jun 2018 16:18:34 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F79B130EAA; Wed, 13 Jun 2018 16:18:34 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id k86-v6so2583220qkh.13; Wed, 13 Jun 2018 16:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TgU3uOxFhm2lGGHUbf82bsZbyXggKOrz/6Ngp2RUe0Q=; b=kp6VULNOcqFebU3+qWeJySBUrEJEIb8ChB6sGeSeywa2CmRuoTU1bnEP8ce17zVLgv XubA3NOsirek3iqnTdV6YtKgnaZzpaMoPzBCBQlecb5i+5kb51aEdPPsFKzcVnsBDdfs jlFUNDy2ExUGR9I2CnMWvvAfG1CGoAYb5P2i4qF0Fe8JWY1UC+J7wRZ13RWb3sR6R6rB xY+oD5NUNVZ6ROwcgMaYLlqGnd7YexZde9MI4FO7aGrXR7Ov5nPzBmTxFhhoDSXGAgWs cr0QPK9ohDya7X3rOUSB4ZamPklfLNIz6yrKbhiMK+Y9NAzoicgj8UFq6lkCEHiuGPL5 MGdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TgU3uOxFhm2lGGHUbf82bsZbyXggKOrz/6Ngp2RUe0Q=; b=aU8sPG7vwDrWj29sZT8Pw//zz3gQ7ZRxQbL3PaQvF8qw0xX9F89Zj8RfuRem7oSQx5 uKebVRxDhkuhuykC/V3qWrYTtv1j9uNhzoGKkMTUWmWlKAJ6TK9/9s1G/x4UiJOZNIZn FQKb1VQ2DMDpJ2RnbwlJDPuK1tSUIfkaCf82/ClW21QR80tQUqxojMgTRd7DHgRJg6Oi cX6yJiaBdDMEJnuAsnT2ul1k4oQ0bf2WZdPgZMEa6AI1axTGCuyUdtp+stkiEW73oxxu mZOMuOd5NIlGSDGM22wc03DD6x9mEj8llEXayz23CTjinxdqNGKaTgUGrFqfPAr7Fwj4 qDzQ== X-Gm-Message-State: APt69E3HiyXIsczDaTVhw5RHm/c4a4UBWWwgwdKVp8zrJgoi9f6ouewg iBKi8hgg+3qwlQ62wUlvxfs= X-Google-Smtp-Source: ADUXVKJkr4mkt4hm4fGzZzSflR+H6L0fzVX81MKaoYNsvH8l4zvGqmCBND/2F5xLVfCe8Ma5nzYdUA== X-Received: by 2002:ae9:ef0a:: with SMTP id d10-v6mr135656qkg.253.1528931912838; Wed, 13 Jun 2018 16:18:32 -0700 (PDT) Received: from [172.20.7.156] ([12.226.128.4]) by smtp.gmail.com with ESMTPSA id d200-v6sm2802612qkg.18.2018.06.13.16.18.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jun 2018 16:18:31 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-29A66C87-811A-4E18-B4B0-204046322323 Mime-Version: 1.0 (1.0) From: Mahesh Jethanandani X-Mailer: iPhone Mail (14G60) In-Reply-To: <241B7429-246F-4D13-9402-393315B4727A@gmail.com> Date: Wed, 13 Jun 2018 19:18:31 -0400 Cc: Peter Saint-Andre , Ignas Bagdonas , draft-mahesh-etsi-urn@ietf.org, "Dale R. Worley" Content-Transfer-Encoding: 7bit Message-Id: <6D608C59-3032-494C-92F8-959FA5D4CA91@gmail.com> References: <87fu1yhwlk.fsf@hobgoblin.ariadne.com> <241B7429-246F-4D13-9402-393315B4727A@gmail.com> To: urn@ietf.org Archived-At: Subject: Re: [urn] New Version Notification for draft-mahesh-etsi-urn-03.txt (Was Re: URN expert review of 'etsi' NID) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 23:18:38 -0000 --Apple-Mail-29A66C87-811A-4E18-B4B0-204046322323 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ETSI has now published a web page that is publicly available and describes t= he two questions outlined below. Please let us know if there are any questio= ns.=20 https://portal.etsi.org/PNNS/GenericAllocation/ETSIURNNamespace.aspx Thanks.=20 > On Jun 8, 2018, at 8:18 PM, Mahesh Jethanandani w= rote: >=20 > The following update to the draft addresses the comments raised as part of= expert review. The remaining action items are for us to make available a pu= blic version of the ancillary document, whose URL was provided in the draft,= that describes: >=20 > - the NSS namespace and how it will be allocated by ETSI > - how a separate =E2=80=9Croot=E2=80=9D namespace under the allocated URN c= an be used for experimental namespaces. >=20 > Thanks > --------------------------------------------------- >=20 > A new version of I-D, draft-mahesh-etsi-urn-03.txt > has been successfully submitted by Mahesh Jethanandani and posted to the > IETF repository. >=20 > Name: draft-mahesh-etsi-urn > Revision: 03 > Title: URN Namespace for ETSI Documents > Document date: 2018-06-08 > Group: Individual Submission > Pages: 6 > URL: https://www.ietf.org/internet-drafts/draft-mahesh-etsi-urn= -03.txt > Status: https://datatracker.ietf.org/doc/draft-mahesh-etsi-urn/ > Htmlized: https://tools.ietf.org/html/draft-mahesh-etsi-urn-03 > Htmlized: https://datatracker.ietf.org/doc/html/draft-mahesh-etsi-ur= n > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mahesh-etsi-urn-= 03 >=20 > Abstract: > This document describes the Namespace Identifier (NID) 'etsi' for > Uniform Resource Names (URNs) used to identify resources published by > European Telecommunications Standards Institute (http://etsi.org). > ETSI specifies and manages resources that utilize this URN > identification model. Management activities for these and other > resources types are handled by the manager of the ETSI Protocol > Naming and Numbering Service (PNNS). >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >> On Jun 7, 2018, at 6:53 PM, Dale R. Worley wrote: >>=20 >> Comments on draft-mahesh-etsi-urn-02 >>=20 >> 1.1. Terminology >>=20 >> | PNNS | Protocol Name and Numbering Service | >>=20 >> It would be helpful to state that PNNS is an ETSI function: >>=20 >> | PNNS | ETSI Protocol Name and Numbering Service | >>=20 >> Declaration of syntactic structure: >>=20 >> The syntax of namespace specific strings for the 'etsi' namespace >> is in Uniform Resource Names (URNs) [RFC8141]. >>=20 >> This is completely legitimate, but it is not satisfying. If ETSI has >> plans for how it will organize the space of NSSs, it would be nice to >> describe them here. >>=20 >> Relevant ancillary documentation: >>=20 >> ETSI publishes information regarding the registered resources in >> the ETSI URN Namespace (EUN) registry >> (https://portal.etsi.org/PNNS/GenericAllocation/ >> ETSIURNNamespace.aspx). >>=20 >> It's good that ETSI gives the URL of its URN registry; many other >> organizations do not. However, I notice that that URL is >> password-protected. It would be much better for the community if the >> registry was readable by the world, since there is no stated intention >> that etsi URNs are used only within a closed community. >>=20 >> Identifier uniqueness considerations: >>=20 >> [...] ETSI is expected to guarantee the uniqueness [...] >>=20 >> Formally, this registration is being submitted by ETSI, so it reads >> oddly for ETSI to say "ETSI is expected...". Much better would be >> "ETSI will...". >>=20 >> Similarly, "ETSI could..." is used where it is more natural to say "ETSI >> may...". >>=20 >> Note that using experimental types may create >> collision as multiple users may use the same values for different >> resources and specific strings. >>=20 >> It would be very helpful if the registration stated how the ETSI >> registry will make clear how to recognize experimental URIs within the >> etsi namespace. >>=20 >> Dale >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 --Apple-Mail-29A66C87-811A-4E18-B4B0-204046322323 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
ETSI has now published a web page that= is publicly available and describes the two questions outlined below. Pleas= e let us know if there are any questions. 

https://portal.etsi.or= g/PNNS/GenericAllocation/ETSIURNNamespace.aspx

Thanks. 

On Jun 8, 2018, at 8:18 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

<= /div>
The following update to the draft addresses= the comments raised as part of expert review. The remaining action items ar= e for us to make available a public version of the ancillary document, whose= URL was provided in the draft, that describes:

- the NSS namespace and how it will be allocated by E= TSI
- how a separate =E2=80=9Croot=E2=80=9D namespace u= nder the allocated URN can be used for experimental namespaces.

Thanks
--= -------------------------------------------------

A new version of I-D, draft-mahesh-e= tsi-urn-03.txt
has been successfully submitted by Mahesh Jetha= nandani and posted to the
IETF repository.

Name:= draft-mahesh-etsi-urn
Revision: 03
Title: URN Namespace for ET= SI Documents
Document date: 2018-06-08
Group: Individual Submissio= n
Pages: = 6
URL:         = ;   https://www.ietf.org/internet-drafts/draft-m= ahesh-etsi-urn-03.txt
Status:     &nbs= p;   https://datatracker.ietf.org/doc/draft-mahesh-etsi-ur= n/
Htmlized:       https://to= ols.ietf.org/html/draft-mahesh-etsi-urn-03
Htmlized:  = ;     https://datatracker.ietf.org/doc/html/= draft-mahesh-etsi-urn
Diff:      =      https://www.ietf.org/rfcdiff?url2=3Ddra= ft-mahesh-etsi-urn-03

Abstract:
  This document describes the Namespace Identifier (NID) 'etsi'= for
  Uniform Resource Names (URNs) used to identif= y resources published by
  European Telecommunicatio= ns Standards Institute (http://etsi.o= rg).
  ETSI specifies and manages resources that= utilize this URN
  identification model.  Mana= gement activities for these and other
  resources ty= pes are handled by the manager of the ETSI Protocol
 &nbs= p;Naming and Numbering Service (PNNS).




Please note that it may take a couple o= f minutes from the time of submission
until the htmlized versi= on and diff are available at tools.ietf.org.

The IETF Secretariat

On Jun 7, 2018, at 6:53 PM, Dale R. Worley <worley@ariadne.com> wrote:

Comments on draf= t-mahesh-etsi-urn-02

  1.1.  Te= rminology

      = | PNNS    | Protocol Name and Numbering Service   &= nbsp;         |
<= br class=3D"">It would be helpful to state that PNNS is an ETSI function:
      | PNNS  = ;  | ETSI Protocol Name and Numbering Service    &n= bsp;   |

  Declaratio= n of syntactic structure:

   &n= bsp; The syntax of namespace specific strings for the 'etsi' namespace<= br class=3D"">      is <NSS> in Uniform Resou= rce Names (URNs) [RFC8141].

This is completely l= egitimate, but it is not satisfying.  If ETSI has
plans f= or how it will organize the space of NSSs, it would be nice to
describe them here.

  Relevant anci= llary documentation:

    &= nbsp;ETSI publishes information regarding the registered resources in
     the ETSI URN Namespace (EUN) registry=
     (https://portal.etsi.org/PNNS/Gener= icAllocation/
     ETSIURNNamesp= ace.aspx).

It's good that ETSI gives the URL of= its URN registry; many other
organizations do not.  Howe= ver, I notice that that URL is
password-protected.  It wo= uld be much better for the community if the
registry was reada= ble by the world, since there is no stated intention
that etsi= URNs are used only within a closed community.

=   Identifier uniqueness considerations:

     [...]  ETSI is expected to guarantee t= he uniqueness [...]

Formally, this registration= is being submitted by ETSI, so it reads
oddly for ETSI to say= "ETSI is expected...".   Much better would be
"ETSI= will...".

Similarly, "ETSI could..." is used w= here it is more natural to say "ETSI
may...".
     Note that using experimental typ= es may create
     collision as mult= iple users may use the same values for different
  =    resources and specific strings.

It would be very helpful if the registration stated how the ETSI
registry will make clear how to recognize experimental URIs within the=
etsi namespace.

Dale

Mahesh Jethanandani
mjethanandani@gmail.com

= --Apple-Mail-29A66C87-811A-4E18-B4B0-204046322323-- From nobody Wed Jun 13 17:57:01 2018 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D9D130ED0 for ; Wed, 13 Jun 2018 17:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com 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 N8lIUXVzZNqs for ; Wed, 13 Jun 2018 17:56:57 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A49C2128CF3 for ; Wed, 13 Jun 2018 17:56:57 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id c10-v6so2084872pgu.9 for ; Wed, 13 Jun 2018 17:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=O2oGD5MjE5iu9MhjjFlqYFi8CDwko5s4O0beBs7mP6g=; b=AstV3RXBZLtjnkDkXkB7Dqx2gpSQFwFJoOmoX36swW0GdJliD6HYy8xUvobNSR8J2P XgQUowRBS6/qWpjXCKKHGuhI4HWeJJMAoZAJTpFyD4Di+8+IqR3UPMTFwBEBbIAyL3Yb fsST3Xf9eIUdzmkuwIGGoqQ5dgzOCWlygIiFg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=O2oGD5MjE5iu9MhjjFlqYFi8CDwko5s4O0beBs7mP6g=; b=ezsi5psKLJdmHO52o8SLWx1RlTdYQUidEMDbBv0zCOsRkelWjodyHv75hmY5TKvEZj a5EpDgtU5GzCFSvprw5FTk2NPqHuJdnWkOlARSNDUPxozg0kcYnxTgFrgFlg5WDnieuU 6uqEW3Ncx3WuVCWUV0o3f+3xx2XZNsgfZGXKIrD5mZoRj6pXia9GZ/daolpm9N28qkLc xTf0Pf2e94EJUEStbc9T0APY7sKp68CtkvkONJlI7BXBBxPRuKme8FXQc8zbuRLxLkum uvc2YUGIiW0nenPrb5Rj8Ah/ZF2Ue7wgf9ymxBDlc4IaRNtCk5ddrShAautmThvh/3bJ bJUQ== X-Gm-Message-State: APt69E3s5EGrl9PeFURGv4i0LHeNGEtTbM1EL2Gg4WmeuMg9B1S/ER1V uQHqYne9ZNTmPVjaNvgebLzRt+Jcmzo= X-Google-Smtp-Source: ADUXVKJPs734vcpDWjm3j8TkLXlZNkeF4hzJXAlPOcwmIT97RGLveV//wUuWCC7m/WnaIFWf9oJb0w== X-Received: by 2002:a62:6710:: with SMTP id b16-v6mr7228367pfc.37.1528937817198; Wed, 13 Jun 2018 17:56:57 -0700 (PDT) Received: from dragon.local ([207.242.53.83]) by smtp.gmail.com with ESMTPSA id y18-v6sm5242950pfl.122.2018.06.13.17.56.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jun 2018 17:56:56 -0700 (PDT) To: urn@ietf.org References: <87fu1yhwlk.fsf@hobgoblin.ariadne.com> <241B7429-246F-4D13-9402-393315B4727A@gmail.com> <6D608C59-3032-494C-92F8-959FA5D4CA91@gmail.com> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: <48eaed30-d3a0-fa81-da88-8759d795978a@mozilla.com> Date: Wed, 13 Jun 2018 18:56:55 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <6D608C59-3032-494C-92F8-959FA5D4CA91@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rg7t04jDHh2AwVUyrp0zbDhS9WUQMs4GC" Archived-At: Subject: Re: [urn] New Version Notification for draft-mahesh-etsi-urn-03.txt (Was Re: URN expert review of 'etsi' NID) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 00:57:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rg7t04jDHh2AwVUyrp0zbDhS9WUQMs4GC Content-Type: multipart/mixed; boundary="LxGT0sgsxhIvNYqKUiStnsRGPFCFvQBVO"; protected-headers="v1" From: Peter Saint-Andre To: urn@ietf.org Message-ID: <48eaed30-d3a0-fa81-da88-8759d795978a@mozilla.com> Subject: Re: [urn] New Version Notification for draft-mahesh-etsi-urn-03.txt (Was Re: URN expert review of 'etsi' NID) References: <87fu1yhwlk.fsf@hobgoblin.ariadne.com> <241B7429-246F-4D13-9402-393315B4727A@gmail.com> <6D608C59-3032-494C-92F8-959FA5D4CA91@gmail.com> In-Reply-To: <6D608C59-3032-494C-92F8-959FA5D4CA91@gmail.com> --LxGT0sgsxhIvNYqKUiStnsRGPFCFvQBVO Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Thanks, Mahesh, that is helpful. I'm still not sure if we want to make a normative reference to RFC 1737 (an Informational RFC from 1994) in the Security Considerations section; do you feel that it discusses issues that we left out of RFC 8141? Other than that, the document looks ready to proceed. Peter On 6/13/18 5:18 PM, Mahesh Jethanandani wrote: > ETSI has now published a web page that is publicly available and > describes the two questions outlined below. Please let us know if there= > are any questions.=C2=A0 >=20 > https://portal.etsi.org/PNNS/GenericAllocation/ETSIURNNamespace.aspx >=20 > Thanks.=C2=A0 >=20 > On Jun 8, 2018, at 8:18 PM, Mahesh Jethanandani > wrote: >=20 >> The following update to the draft addresses the comments raised as >> part of expert review. The remaining action items are for us to make >> available a public version of the ancillary document, whose URL was >> provided in the draft, that describes: >> >> - the NSS namespace and how it will be allocated by ETSI >> - how a separate =E2=80=9Croot=E2=80=9D namespace under the allocated = URN can be used >> for experimental namespaces. >> >> Thanks >> --------------------------------------------------- >> >> A new version of I-D, draft-mahesh-etsi-urn-03.txt >> has been successfully submitted by Mahesh Jethanandani and posted to t= he >> IETF repository. >> >> Name:draft-mahesh-etsi-urn >> Revision:03 >> Title:URN Namespace for ETSI Documents >> Document date:2018-06-08 >> Group:Individual Submission >> Pages:6 >> URL: >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0http= s://www.ietf.org/internet-drafts/draft-mahesh-etsi-urn-03.txt >> Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatr= acker.ietf.org/doc/draft-mahesh-etsi-urn/ >> Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/h= tml/draft-mahesh-etsi-urn-03 >> Htmlized: >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/h= tml/draft-mahesh-etsi-urn >> Diff: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0http= s://www.ietf.org/rfcdiff?url2=3Ddraft-mahesh-etsi-urn-03 >> >> Abstract: >> =C2=A0=C2=A0This document describes the Namespace Identifier (NID) 'et= si' for >> =C2=A0=C2=A0Uniform Resource Names (URNs) used to identify resources p= ublished by >> =C2=A0=C2=A0European Telecommunications Standards Institute (http://et= si.org). >> =C2=A0=C2=A0ETSI specifies and manages resources that utilize this URN= >> =C2=A0=C2=A0identification model. =C2=A0Management activities for thes= e and other >> =C2=A0=C2=A0resources types are handled by the manager of the ETSI Pro= tocol >> =C2=A0=C2=A0Naming and Numbering Service (PNNS). >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at=C2=A0tools.ietf.o= rg >> . >> >> The IETF Secretariat >> >>> On Jun 7, 2018, at 6:53 PM, Dale R. Worley >> > wrote: >>> >>> Comments on draft-mahesh-etsi-urn-02 >>> >>> =C2=A0=C2=A01.1. =C2=A0Terminology >>> >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| PNNS =C2=A0=C2=A0=C2=A0| Protoc= ol Name and Numbering Service =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0| >>> >>> It would be helpful to state that PNNS is an ETSI function: >>> >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| PNNS =C2=A0=C2=A0=C2=A0| ETSI P= rotocol Name and Numbering Service =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0| >>> >>> =C2=A0=C2=A0Declaration of syntactic structure: >>> >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0The syntax of namespace specific string= s for the 'etsi' namespace >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0is in Uniform Resource Names (URN= s) [RFC8141]. >>> >>> This is completely legitimate, but it is not satisfying. =C2=A0If ETS= I has >>> plans for how it will organize the space of NSSs, it would be nice to= >>> describe them here. >>> >>> =C2=A0=C2=A0Relevant ancillary documentation: >>> >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ETSI publishes information regarding th= e registered resources in >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0the ETSI URN Namespace (EUN) registry >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(https://portal.etsi.org/PNNS/GenericAl= location/ >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ETSIURNNamespace.aspx). >>> >>> It's good that ETSI gives the URL of its URN registry; many other >>> organizations do not. =C2=A0However, I notice that that URL is >>> password-protected. =C2=A0It would be much better for the community i= f the >>> registry was readable by the world, since there is no stated intentio= n >>> that etsi URNs are used only within a closed community. >>> >>> =C2=A0=C2=A0Identifier uniqueness considerations: >>> >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[...] =C2=A0ETSI is expected to guarant= ee the uniqueness [...] >>> >>> Formally, this registration is being submitted by ETSI, so it reads >>> oddly for ETSI to say "ETSI is expected...". =C2=A0=C2=A0Much better = would be >>> "ETSI will...". >>> >>> Similarly, "ETSI could..." is used where it is more natural to say "E= TSI >>> may...". >>> >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Note that using experimental types may = create >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0collision as multiple users may use the= same values for different >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0resources and specific strings. >>> >>> It would be very helpful if the registration stated how the ETSI >>> registry will make clear how to recognize experimental URIs within th= e >>> etsi namespace. >>> >>> Dale >> >> Mahesh Jethanandani >> mjethanandani@gmail.com >> >=20 >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn >=20 --LxGT0sgsxhIvNYqKUiStnsRGPFCFvQBVO-- --rg7t04jDHh2AwVUyrp0zbDhS9WUQMs4GC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlshvVcACgkQZWGMGH9o FKml9A//ZHP8sDvdjYRL4Z+FjMpeYCU2GTmvDw744z1XCgnR/Vtfsaezw+iJlXrl 0S28dp/A9j6X0gx85zStRRZuX2d4M0ip3f+4pHPVlW43EvMRliiFMm9dA8jMU4/L VvR0OXqoME0teSpQCq/OcdwQg8LR6cBAAVXvrruAP/ee8Q39gsrJ5TjUXOTVn6BG YRasxng99YFqL6gsLGSVUN6K1eL2SYyiqkY0tzCVAMrvwyna566hvoIuZWogfCLr DWETIo6CvLv9yYFbj8KMtC8p0Cg13uvi/+HWRy+5jU+dVBY2pHax1qeDWI98t1Pn MH5HpkUSjKDsrwy+0LhdrFKtUELnDf90GPqPbA8KSwxvtynFopR9BAn9YCnYNIWh w4Vlo/XQ2vlmh+mbXiCuKNsrfyy1HUNTmUbOD49yimB9iBvSjPZzFWJJDvf0OYQt lJIqZM+CzfDaZreubFH9kmtU22jgsjCheHd8cVBzggdUOHIghQyKPn3kzxEew2M2 Ai0YwMeOXXNSmOHPxO1WxookEv+tRJp9UtT0SSNk5eBrzMdBDX3jwFq6g4EqHtJG 4SqeYMDt67jZs7Fqm77QL9dojJlsGF966/Zl/3oxIbus0TVp1FW1vs5dZTaw2TTB /Yn3mPdnWPKCACEAs2xK8eI38qs3U6DsOSDv2JvmC++h0E97sYw= =1mpI -----END PGP SIGNATURE----- --rg7t04jDHh2AwVUyrp0zbDhS9WUQMs4GC-- From nobody Thu Jun 14 08:23:07 2018 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C9E130E45 for ; Thu, 14 Jun 2018 08:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 c93EZ64j31eb for ; Thu, 14 Jun 2018 08:23:00 -0700 (PDT) Received: from mail.dnb.de (mail.dnb.de [193.175.100.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E1E2130E31 for ; Thu, 14 Jun 2018 08:22:59 -0700 (PDT) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by mail.dnb.de (Postfix) with ESMTP id AD9B7536C5B6; Thu, 14 Jun 2018 17:22:57 +0200 (CEST) X-AuditID: 0a453fe7-181ff700000025db-44-5b22885119e5 Received: from dnbf-ex.AD.DDB.DE (dnbf-ex.AD.DDB.DE [10.69.63.244]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id 3A.90.09691.158822B5; Thu, 14 Jun 2018 17:22:57 +0200 (CEST) Received: from dnbf-ex.AD.DDB.DE (10.69.63.244) by dnbf-ex.AD.DDB.DE (10.69.63.244) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.669.32; Thu, 14 Jun 2018 17:22:55 +0200 Received: from dnbf-ex.AD.DDB.DE ([fe80::3576:7565:4f15:49c7]) by dnbf-ex.AD.DDB.DE ([fe80::3576:7565:4f15:49c7%4]) with mapi id 15.01.0669.032; Thu, 14 Jun 2018 17:22:55 +0200 From: "Svensson, Lars" To: Peter Saint-Andre , "urn@ietf.org" Thread-Topic: [Marketing Mail] Re: [urn] New Version Notification for draft-mahesh-etsi-urn-03.txt (Was Re: URN expert review of 'etsi' NID) Thread-Index: AQHUA2zj44SLFFIp3k2YKFPS6VeE/qRezMyAgAETNSA= Date: Thu, 14 Jun 2018 15:22:55 +0000 Message-ID: <17e4d21c533440a48bd0e1459ab5f48a@dnb.de> References: <87fu1yhwlk.fsf@hobgoblin.ariadne.com> <241B7429-246F-4D13-9402-393315B4727A@gmail.com> <6D608C59-3032-494C-92F8-959FA5D4CA91@gmail.com> <48eaed30-d3a0-fa81-da88-8759d795978a@mozilla.com> In-Reply-To: <48eaed30-d3a0-fa81-da88-8759d795978a@mozilla.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.69.12.166] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA11Ta0hTYRju2zlrn2tffR1n+1pZ80RERXaPiEiJCo2uVBBNymPntA3nXDtb qQRJF5Nl06ILLugCC0uqlRlGdGPmj5UhFRJCQbFKzW52ocuP7HyezWZ/Du/7vN/zvM/7vhzI cL91ZuhweSWPS3DyQ/WsfmnWt2lrK3nrjOt9pvlvLzwA84/t/azJ1uSEQr80OYF7fu0azSb9 QlFyOnZInumL8vX27hOtWndldklVR0BbDhoX+QGEBM8hTftz/EAPORwBpKe6SacmMUDuttTF k0ZAoqfOMX6gg0PxFPLJ7gcp0IiXkyO91Vr6JBUfAuRNfRNDEyMOAPK1OcSorxaQvp4jLI1Z PJF8fhEGNEZ4Lnl1OaxRGzwCJPT9vI4WUnAW+dW8R0NjgNPJlStt/UIMNpGGtz+0NCYYk9At FSc4jXTH/sRxC/kSaGXoaAyeTMI3p6vUDHL04Cud2nckida+ZmtAWjBJNfiPEUxiBJMYZwBb D4bLRbaZmYKYKYoFmaLUANRjdN4AgSdLIgBDwBtQ3nbeymmFHXJpUQSshho+DVnaM6zc8IJi sdQuyPYtHp9TknkjWhlTYDQAF/ichfw4tKvRYuVMA6jsk92OrY5in7zF53EqV4KMQj3kVZog USgtkzzFqmAEjIEsb0Ldd4Zs5LBN8EqFkuSWPInqRgh5gioPKMSRHskmlWxzOL2JssI75lYq OLnSbygDdVrHWzlzcuF/TxqYEgEroEEx9ryCGpPdQpHssMW1U5G9TEENCbRfNx210EFHJcDB mg9AIXxfUVXFwNdPjyvf+lB1DcOxrmKXZDYhSIfAlGn3uQZmMI9C9/OVjY5IKtBWZgta9kfB Ryfhg7u9A7nK6VJRLTVvUH61f945tJt6HxYH+62PRVFqPS2O/a+1Qrm5EbW0WOgivII3eRHr KdGQQOOL2KAuIg4OljOXg2Dvya6n5eLt/Mw2U92tut0/zu5LNzmy2j9VdDFF78LOeaPDfT+f PO6KPrPNOqW35jTnlcX40yWFxksN4qqdeS/nPuzZ/Nt7NJvrbb/fcVjXmTVrn55hJ96pm/Tx +tSeN7O/xzpqD65rzX0//sPVtovfnkUntG+7GjxQs7jkdGDStdwFPCvbhZlTGI8s/AUfiZJX jQQAAA== Archived-At: Subject: Re: [urn] [Marketing Mail] Re: New Version Notification for draft-mahesh-etsi-urn-03.txt (Was Re: URN expert review of 'etsi' NID) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 15:23:05 -0000 QXBhcnQgZnJvbSB3aGF0IFBldGVyIGFscmVhZHkgc2FpZCwgSSBoYXZlIG5vIGZ1cnRoZXIgY29t bWVudHMgb24gdGhpcyBkcmFmdCwgYXMgZmFyIGFzIEknbSBjb25jZXJuZWQgd2UncmUgcmVhZHkg dG8gcHJvY2VlZC4NCg0KQmVzdCwNCg0KTGFycw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IHVybiBbbWFpbHRvOnVybi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgUGV0ZXIgU2FpbnQtQW5kcmUNCj4gU2VudDogVGh1cnNkYXksIEp1bmUgMTQsIDIwMTggMjo1 NyBBTQ0KPiBUbzogdXJuQGlldGYub3JnDQo+IFN1YmplY3Q6IFtNYXJrZXRpbmcgTWFpbF0gUmU6 IFt1cm5dIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWFoZXNoLWV0c2ktDQo+ IHVybi0wMy50eHQgKFdhcyBSZTogVVJOIGV4cGVydCByZXZpZXcgb2YgJ2V0c2knIE5JRCkNCj4g DQo+IFRoYW5rcywgTWFoZXNoLCB0aGF0IGlzIGhlbHBmdWwuDQo+IA0KPiBJJ20gc3RpbGwgbm90 IHN1cmUgaWYgd2Ugd2FudCB0byBtYWtlIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0byBSRkMgMTcz Nw0KPiAoYW4gSW5mb3JtYXRpb25hbCBSRkMgZnJvbSAxOTk0KSBpbiB0aGUgU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMgc2VjdGlvbjsNCj4gZG8geW91IGZlZWwgdGhhdCBpdCBkaXNjdXNzZXMgaXNz dWVzIHRoYXQgd2UgbGVmdCBvdXQgb2YgUkZDIDgxNDE/DQo+IA0KPiBPdGhlciB0aGFuIHRoYXQs IHRoZSBkb2N1bWVudCBsb29rcyByZWFkeSB0byBwcm9jZWVkLg0KPiANCj4gUGV0ZXINCj4gDQo+ IE9uIDYvMTMvMTggNToxOCBQTSwgTWFoZXNoIEpldGhhbmFuZGFuaSB3cm90ZToNCj4gPiBFVFNJ IGhhcyBub3cgcHVibGlzaGVkIGEgd2ViIHBhZ2UgdGhhdCBpcyBwdWJsaWNseSBhdmFpbGFibGUg YW5kDQo+ID4gZGVzY3JpYmVzIHRoZSB0d28gcXVlc3Rpb25zIG91dGxpbmVkIGJlbG93LiBQbGVh c2UgbGV0IHVzIGtub3cgaWYgdGhlcmUNCj4gPiBhcmUgYW55IHF1ZXN0aW9ucy4NCj4gPg0KPiA+ IGh0dHBzOi8vcG9ydGFsLmV0c2kub3JnL1BOTlMvR2VuZXJpY0FsbG9jYXRpb24vRVRTSVVSTk5h bWVzcGFjZS5hc3B4DQo+ID4NCj4gPiBUaGFua3MuDQo+ID4NCj4gPiBPbiBKdW4gOCwgMjAxOCwg YXQgODoxOCBQTSwgTWFoZXNoIEpldGhhbmFuZGFuaSA8bWpldGhhbmFuZGFuaUBnbWFpbC5jb20N Cj4gPiA8bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPj4gd3JvdGU6DQo+ID4NCj4gPj4g VGhlIGZvbGxvd2luZyB1cGRhdGUgdG8gdGhlIGRyYWZ0IGFkZHJlc3NlcyB0aGUgY29tbWVudHMg cmFpc2VkIGFzDQo+ID4+IHBhcnQgb2YgZXhwZXJ0IHJldmlldy4gVGhlIHJlbWFpbmluZyBhY3Rp b24gaXRlbXMgYXJlIGZvciB1cyB0byBtYWtlDQo+ID4+IGF2YWlsYWJsZSBhIHB1YmxpYyB2ZXJz aW9uIG9mIHRoZSBhbmNpbGxhcnkgZG9jdW1lbnQsIHdob3NlIFVSTCB3YXMNCj4gPj4gcHJvdmlk ZWQgaW4gdGhlIGRyYWZ0LCB0aGF0IGRlc2NyaWJlczoNCj4gPj4NCj4gPj4gLSB0aGUgTlNTIG5h bWVzcGFjZSBhbmQgaG93IGl0IHdpbGwgYmUgYWxsb2NhdGVkIGJ5IEVUU0kNCj4gPj4gLSBob3cg YSBzZXBhcmF0ZSDigJxyb2904oCdIG5hbWVzcGFjZSB1bmRlciB0aGUgYWxsb2NhdGVkIFVSTiBj YW4gYmUgdXNlZA0KPiA+PiBmb3IgZXhwZXJpbWVudGFsIG5hbWVzcGFjZXMuDQo+ID4+DQo+ID4+ IFRoYW5rcw0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gPj4NCj4gPj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW1haGVzaC1l dHNpLXVybi0wMy50eHQNCj4gPj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBN YWhlc2ggSmV0aGFuYW5kYW5pIGFuZCBwb3N0ZWQgdG8gdGhlDQo+ID4+IElFVEYgcmVwb3NpdG9y eS4NCj4gPj4NCj4gPj4gTmFtZTpkcmFmdC1tYWhlc2gtZXRzaS11cm4NCj4gPj4gUmV2aXNpb246 MDMNCj4gPj4gVGl0bGU6VVJOIE5hbWVzcGFjZSBmb3IgRVRTSSBEb2N1bWVudHMNCj4gPj4gRG9j dW1lbnQgZGF0ZToyMDE4LTA2LTA4DQo+ID4+IEdyb3VwOkluZGl2aWR1YWwgU3VibWlzc2lvbg0K PiA+PiBQYWdlczo2DQo+ID4+IFVSTDoNCj4gPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoGh0dHBz Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tYWhlc2gtZXRzaS11cm4tMDMu dHh0DQo+ID4+IFN0YXR1czogwqDCoMKgwqDCoMKgwqDCoGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LW1haGVzaC1ldHNpLXVybi8NCj4gPj4gSHRtbGl6ZWQ6IMKgwqDCoMKg wqDCoGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYWhlc2gtZXRzaS11cm4tMDMN Cj4gPj4gSHRtbGl6ZWQ6DQo+ID4+IMKgwqDCoMKgwqDCoGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbWFoZXNoLWV0c2ktdXJuDQo+ID4+IERpZmY6IMKgwqDCoMKg wqDCoMKgwqDCoMKgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW1haGVz aC1ldHNpLXVybi0wMw0KPiA+Pg0KPiA+PiBBYnN0cmFjdDoNCj4gPj4gwqDCoFRoaXMgZG9jdW1l bnQgZGVzY3JpYmVzIHRoZSBOYW1lc3BhY2UgSWRlbnRpZmllciAoTklEKSAnZXRzaScgZm9yDQo+ ID4+IMKgwqBVbmlmb3JtIFJlc291cmNlIE5hbWVzIChVUk5zKSB1c2VkIHRvIGlkZW50aWZ5IHJl c291cmNlcyBwdWJsaXNoZWQgYnkNCj4gPj4gwqDCoEV1cm9wZWFuIFRlbGVjb21tdW5pY2F0aW9u cyBTdGFuZGFyZHMgSW5zdGl0dXRlIChodHRwOi8vZXRzaS5vcmcpLg0KPiA+PiDCoMKgRVRTSSBz cGVjaWZpZXMgYW5kIG1hbmFnZXMgcmVzb3VyY2VzIHRoYXQgdXRpbGl6ZSB0aGlzIFVSTg0KPiA+ PiDCoMKgaWRlbnRpZmljYXRpb24gbW9kZWwuIMKgTWFuYWdlbWVudCBhY3Rpdml0aWVzIGZvciB0 aGVzZSBhbmQgb3RoZXINCj4gPj4gwqDCoHJlc291cmNlcyB0eXBlcyBhcmUgaGFuZGxlZCBieSB0 aGUgbWFuYWdlciBvZiB0aGUgRVRTSSBQcm90b2NvbA0KPiA+PiDCoMKgTmFtaW5nIGFuZCBOdW1i ZXJpbmcgU2VydmljZSAoUE5OUykuDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IFBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mDQo+ID4+IHN1Ym1pc3Npb24NCj4gPj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5k IGRpZmYgYXJlIGF2YWlsYWJsZSBhdMKgdG9vbHMuaWV0Zi5vcmcNCj4gPj4gPGh0dHA6Ly90b29s cy5pZXRmLm9yZz4uDQo+ID4+DQo+ID4+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+ID4+DQo+ID4+ PiBPbiBKdW4gNywgMjAxOCwgYXQgNjo1MyBQTSwgRGFsZSBSLiBXb3JsZXkgPHdvcmxleUBhcmlh ZG5lLmNvbQ0KPiA+Pj4gPG1haWx0bzp3b3JsZXlAYXJpYWRuZS5jb20+PiB3cm90ZToNCj4gPj4+ DQo+ID4+PiBDb21tZW50cyBvbiBkcmFmdC1tYWhlc2gtZXRzaS11cm4tMDINCj4gPj4+DQo+ID4+ PiDCoMKgMS4xLiDCoFRlcm1pbm9sb2d5DQo+ID4+Pg0KPiA+Pj4gwqDCoMKgwqDCoMKgfCBQTk5T IMKgwqDCoHwgUHJvdG9jb2wgTmFtZSBhbmQgTnVtYmVyaW5nIFNlcnZpY2UgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgfA0KPiA+Pj4NCj4gPj4+IEl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gc3RhdGUg dGhhdCBQTk5TIGlzIGFuIEVUU0kgZnVuY3Rpb246DQo+ID4+Pg0KPiA+Pj4gwqDCoMKgwqDCoMKg fCBQTk5TIMKgwqDCoHwgRVRTSSBQcm90b2NvbCBOYW1lIGFuZCBOdW1iZXJpbmcgU2VydmljZSDC oMKgwqDCoMKgwqDCoHwNCj4gPj4+DQo+ID4+PiDCoMKgRGVjbGFyYXRpb24gb2Ygc3ludGFjdGlj IHN0cnVjdHVyZToNCj4gPj4+DQo+ID4+PiDCoMKgwqDCoMKgVGhlIHN5bnRheCBvZiBuYW1lc3Bh Y2Ugc3BlY2lmaWMgc3RyaW5ncyBmb3IgdGhlICdldHNpJyBuYW1lc3BhY2UNCj4gPj4+IMKgwqDC oMKgwqBpcyA8TlNTPiBpbiBVbmlmb3JtIFJlc291cmNlIE5hbWVzIChVUk5zKSBbUkZDODE0MV0u DQo+ID4+Pg0KPiA+Pj4gVGhpcyBpcyBjb21wbGV0ZWx5IGxlZ2l0aW1hdGUsIGJ1dCBpdCBpcyBu b3Qgc2F0aXNmeWluZy4gwqBJZiBFVFNJIGhhcw0KPiA+Pj4gcGxhbnMgZm9yIGhvdyBpdCB3aWxs IG9yZ2FuaXplIHRoZSBzcGFjZSBvZiBOU1NzLCBpdCB3b3VsZCBiZSBuaWNlIHRvDQo+ID4+PiBk ZXNjcmliZSB0aGVtIGhlcmUuDQo+ID4+Pg0KPiA+Pj4gwqDCoFJlbGV2YW50IGFuY2lsbGFyeSBk b2N1bWVudGF0aW9uOg0KPiA+Pj4NCj4gPj4+IMKgwqDCoMKgwqBFVFNJIHB1Ymxpc2hlcyBpbmZv cm1hdGlvbiByZWdhcmRpbmcgdGhlIHJlZ2lzdGVyZWQgcmVzb3VyY2VzIGluDQo+ID4+PiDCoMKg wqDCoMKgdGhlIEVUU0kgVVJOIE5hbWVzcGFjZSAoRVVOKSByZWdpc3RyeQ0KPiA+Pj4gwqDCoMKg wqDCoChodHRwczovL3BvcnRhbC5ldHNpLm9yZy9QTk5TL0dlbmVyaWNBbGxvY2F0aW9uLw0KPiA+ Pj4gwqDCoMKgwqDCoEVUU0lVUk5OYW1lc3BhY2UuYXNweCkuDQo+ID4+Pg0KPiA+Pj4gSXQncyBn b29kIHRoYXQgRVRTSSBnaXZlcyB0aGUgVVJMIG9mIGl0cyBVUk4gcmVnaXN0cnk7IG1hbnkgb3Ro ZXINCj4gPj4+IG9yZ2FuaXphdGlvbnMgZG8gbm90LiDCoEhvd2V2ZXIsIEkgbm90aWNlIHRoYXQg dGhhdCBVUkwgaXMNCj4gPj4+IHBhc3N3b3JkLXByb3RlY3RlZC4gwqBJdCB3b3VsZCBiZSBtdWNo IGJldHRlciBmb3IgdGhlIGNvbW11bml0eSBpZiB0aGUNCj4gPj4+IHJlZ2lzdHJ5IHdhcyByZWFk YWJsZSBieSB0aGUgd29ybGQsIHNpbmNlIHRoZXJlIGlzIG5vIHN0YXRlZCBpbnRlbnRpb24NCj4g Pj4+IHRoYXQgZXRzaSBVUk5zIGFyZSB1c2VkIG9ubHkgd2l0aGluIGEgY2xvc2VkIGNvbW11bml0 eS4NCj4gPj4+DQo+ID4+PiDCoMKgSWRlbnRpZmllciB1bmlxdWVuZXNzIGNvbnNpZGVyYXRpb25z Og0KPiA+Pj4NCj4gPj4+IMKgwqDCoMKgwqBbLi4uXSDCoEVUU0kgaXMgZXhwZWN0ZWQgdG8gZ3Vh cmFudGVlIHRoZSB1bmlxdWVuZXNzIFsuLi5dDQo+ID4+Pg0KPiA+Pj4gRm9ybWFsbHksIHRoaXMg cmVnaXN0cmF0aW9uIGlzIGJlaW5nIHN1Ym1pdHRlZCBieSBFVFNJLCBzbyBpdCByZWFkcw0KPiA+ Pj4gb2RkbHkgZm9yIEVUU0kgdG8gc2F5ICJFVFNJIGlzIGV4cGVjdGVkLi4uIi4gwqDCoE11Y2gg YmV0dGVyIHdvdWxkIGJlDQo+ID4+PiAiRVRTSSB3aWxsLi4uIi4NCj4gPj4+DQo+ID4+PiBTaW1p bGFybHksICJFVFNJIGNvdWxkLi4uIiBpcyB1c2VkIHdoZXJlIGl0IGlzIG1vcmUgbmF0dXJhbCB0 byBzYXkgIkVUU0kNCj4gPj4+IG1heS4uLiIuDQo+ID4+Pg0KPiA+Pj4gwqDCoMKgwqDCoE5vdGUg dGhhdCB1c2luZyBleHBlcmltZW50YWwgdHlwZXMgbWF5IGNyZWF0ZQ0KPiA+Pj4gwqDCoMKgwqDC oGNvbGxpc2lvbiBhcyBtdWx0aXBsZSB1c2VycyBtYXkgdXNlIHRoZSBzYW1lIHZhbHVlcyBmb3Ig ZGlmZmVyZW50DQo+ID4+PiDCoMKgwqDCoMKgcmVzb3VyY2VzIGFuZCBzcGVjaWZpYyBzdHJpbmdz Lg0KPiA+Pj4NCj4gPj4+IEl0IHdvdWxkIGJlIHZlcnkgaGVscGZ1bCBpZiB0aGUgcmVnaXN0cmF0 aW9uIHN0YXRlZCBob3cgdGhlIEVUU0kNCj4gPj4+IHJlZ2lzdHJ5IHdpbGwgbWFrZSBjbGVhciBo b3cgdG8gcmVjb2duaXplIGV4cGVyaW1lbnRhbCBVUklzIHdpdGhpbiB0aGUNCj4gPj4+IGV0c2kg bmFtZXNwYWNlLg0KPiA+Pj4NCj4gPj4+IERhbGUNCj4gPj4NCj4gPj4gTWFoZXNoIEpldGhhbmFu ZGFuaQ0KPiA+PiBtamV0aGFuYW5kYW5pQGdtYWlsLmNvbSA8bWFpbHRvOm1qZXRoYW5hbmRhbmlA Z21haWwuY29tPg0KPiA+Pg0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHVybiBtYWlsaW5nIGxpc3QNCj4gPiB1cm5AaWV0 Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Vybg0KPiA+ DQoNCg== From nobody Fri Jun 15 08:48:22 2018 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6F6130F20 for ; Fri, 15 Jun 2018 08:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=MNJgnKxL; dkim=pass (1024-bit key) header.d=ericsson.com header.b=D02XUHjf 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 hji0ShkvBihX for ; Fri, 15 Jun 2018 08:48:04 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8324C130E4F for ; Fri, 15 Jun 2018 08:48:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1529077681; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4lXFysh81y6sN2CfQKSyt/uE3q/xnOqAfVS+QtZwckw=; b=MNJgnKxLLfueiPeFmd4PVqdWXV7RvdBVs2IbewDh6CrgcrxVzkL5c/uqVogjix2u t+i81/8do8tfKsfmdXXUTWm2AsiG/vSKBie0UFD9l7L0idA/A4ctw0XaswRMAzdK W7ncQty59BzQk28q3RGXDt0x0MGL7eq2Fko1TAwMps8=; X-AuditID: c1b4fb25-97bdd9c000007b3f-ca-5b23dfb135a5 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B1.E2.31551.1BFD32B5; Fri, 15 Jun 2018 17:48:01 +0200 (CEST) Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESSHC020.ericsson.se (153.88.183.78) with Microsoft SMTP Server (TLS) id 14.3.382.0; Fri, 15 Jun 2018 17:47:00 +0200 Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 15 Jun 2018 17:47:00 +0200 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 15 Jun 2018 17:47:00 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AiiEhhjZqNW61KemXwwSNKMzEohhJFDyl3iWrEfP/vM=; b=D02XUHjf0Xi2xpgxnLITtIZuo62TJ4+vzfIW2siDMI1i+1MYcmRnWfucMUMVU2JPkhY+wDNPnk335e5mZEvSusZ3FvZLiGEvUi2tkHEhdaDm9obIXlXGjyL1Bze6qRVY5iCXIjzo6k9K0D2e4nbfNZzYtbS5edFlWbwtF0WEzqg= Received: from CY1PR15MB0235.namprd15.prod.outlook.com (10.163.49.13) by CY1PR15MB0812.namprd15.prod.outlook.com (10.169.22.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.17; Fri, 15 Jun 2018 15:46:58 +0000 Received: from CY1PR15MB0235.namprd15.prod.outlook.com ([fe80::1575:f33a:9393:20]) by CY1PR15MB0235.namprd15.prod.outlook.com ([fe80::1575:f33a:9393:20%4]) with mapi id 15.20.0863.016; Fri, 15 Jun 2018 15:46:58 +0000 From: Scott Mansfield To: "urn@ietf.org" CC: "Davis, Nigel (ndavis@ciena.com)" , "kamlam@fiberhome.com" Thread-Topic: Updated URN request for ONF Thread-Index: AdQEvwg9zv/GKNEKQ2aX+YHfYA6rNA== Date: Fri, 15 Jun 2018 15:46:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=scott.mansfield@ericsson.com; x-originating-ip: [72.23.221.187] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR15MB0812; 7:J+afl2aBRg6HXU0MOn0hv4TbJlr/ywypEIpKB9rzTph35tNtPkyDTY+NUW6vejRPJnirMFvXy0lLmZoJJfJ6umvniZVH8cIt+dvgIGAbr1v65r45nR9cai3NpJmNvXJqQcz9nEiSiEIGPUmjVXZBmpkNj16DXo7n/fKn3NkbQMK+mXn/4gmGKa1zQeFInyFtzb0UC0WdsV5ap4NIM5mTOmzangM192/f7twRzk5x8Ru078QDHEz/zI/nt8cpoSKK x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 887a2306-b551-44f3-77aa-08d5d2d73ab8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:CY1PR15MB0812; x-ms-traffictypediagnostic: CY1PR15MB0812: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231254)(944501410)(52105095)(93006095)(93001095)(149027)(150027)(6041310)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:CY1PR15MB0812; BCL:0; PCL:0; RULEID:; SRVR:CY1PR15MB0812; x-forefront-prvs: 0704670F76 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(39860400002)(39380400002)(346002)(366004)(189003)(199004)(54164003)(2501003)(33656002)(6306002)(6436002)(106356001)(476003)(105586002)(44832011)(99286004)(66066001)(55016002)(5640700003)(316002)(5630700001)(68736007)(99936001)(478600001)(14454004)(54906003)(486006)(5250100002)(3660700001)(3846002)(19609705001)(790700001)(6116002)(5890100001)(15650500001)(2351001)(2420400007)(3280700002)(6916009)(6506007)(5660300001)(39060400002)(8676002)(2906002)(10710500007)(74316002)(25786009)(4326008)(2900100001)(186003)(26005)(7110500001)(53936002)(8936002)(86362001)(102836004)(7696005)(97736004)(59450400001)(54896002)(81156014)(1730700003)(9686003)(81166006)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR15MB0812; H:CY1PR15MB0235.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Fl7x2Xjc8VYbALcWS/jH56spg2treAt5DNwjyMKVFe1ZDwpTM2kY4uiP+1BgsOEDY7ctR1AQ1sUxNYCdYIWetoky/0UAA5B2yXV4BIUw4/4+Xa6lTLSXB/Y2Jmxe9Oz/2pjwNPPA8Ql49FUHaxeaA5JSaBWrYufkOCYEXttX9SiwrioLuaytaf5mlbNDf/ft spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_004_CY1PR15MB023544C5860B901E31C7BF8D8B7C0CY1PR15MB0235namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 887a2306-b551-44f3-77aa-08d5d2d73ab8 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2018 15:46:58.5980 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR15MB0812 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA2WSe0hTYRjG+845Ozuai9Py8mY3nBrlXRMa3SjxDzPKKKJSy1YeL6hTNrW0 BKmQ0JYWrXJkWyQaKrp0ppiZjojmJfNGpjabWpGKaUUZwsztmxD03+95n+d9v5eXjyGFZp4r kyhN52RSSbKItqeKTzQc8n0y6h4V8E0bKB6a0fLFn4bXi5VXZom9ZFjXezMVVqtoI8NKS/8Q h8lI+12xXHJiJifz33PGPkHRYabTagrRBeN0RC6qvobyEcMAGwz9xoB8ZM8I2ZcIHptaEBY6 BKqxbhqLXwgWC3soLEoJ0Cj0PIug2CISno4YbE4RAc1zQ7YeI4LeFxoiH9kx9NIr9U13kYUd WTdo+XyZb2GSTYTSN3O0hdewHjCQN8PHma2QVzRNYPaD8f4m0sIU6wmVDV+sLGCjwTBntDJi neF3exWBZ7rA0ITaysA6gqmng8bsBF/HzTycj4HikucI192g8ZWCxLwBetUF1gsAqyNA3XPT ZvjCrFJp44PQ0XSFxqHXCHQTahLf0gtaqzNwJglMZc18zOGw2Flo690IFQoThXsNJPSW3+cX IX/VP4urbIeZ7b1hZQG7GgzFExSup4K2pZzG7AOaZ99t7A1lD6fIZe5sHSf+rwfBR8N1W34z jFbU8FRLe5BsDYL5Oj0PG25wu8DE1yCHCuQk5+RnU+KDtvlxssRzcnmq1E/KpdeipZ/Yplvw bER90/v0iGWQyEEQP+geJeRJMuVZKXrksTRnTFv5FrlS0lQpJ3IUKNJFUUJBrCQrm5Olxsgy kjm5Hq1jKJGLwLS9LlLIxkvSuSSOS+Nkyy7B2LnmopDdXmNKH//ZLsmBVRG+IZqqseHJo8Hx 85lX75z3/UAVivntndw0Ec5zWCs6zmsoiL7k4q0ZVM1EDgxtCv5x8thEcitfm7uTfrDQXbti R71KnBUQ16e7xd6bynkn8t9vDo0KPTXyMyQ4OptyXjlJkyUxcdGPuItb1H49xGllzhERJU+Q BHqRMrnkL2fiogeRAwAA Archived-At: Subject: [urn] Updated URN request for ONF X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 15:48:20 -0000 --_004_CY1PR15MB023544C5860B901E31C7BF8D8B7C0CY1PR15MB0235namp_ Content-Type: multipart/alternative; boundary="_000_CY1PR15MB023544C5860B901E31C7BF8D8B7C0CY1PR15MB0235namp_" --_000_CY1PR15MB023544C5860B901E31C7BF8D8B7C0CY1PR15MB0235namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have addressed all comments from the community and verified the resolutio= ns with the commenters. Thanks to everyone that provided feedback. I am al= so working on a URN request for the ITU, so I am applying the same edits to= that request to (hopefully) reduce the edit cycle. I have attached the ONF Formal URN request document in ID form as described= in sections 6.2 and 6.3 of RFC 8141. Please see Section 2 of draft-onf-ur= n.txt which is formatted based on the template in Appendix A of RFC8141. Regards, -scott. Scott Mansfield Ericsson Inc. +1 724 931 9316 --_000_CY1PR15MB023544C5860B901E31C7BF8D8B7C0CY1PR15MB0235namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have addressed all comments from the community and= verified the resolutions with the commenters. Thanks to everyone that prov= ided feedback.  I am also working on a URN request for the ITU, so I a= m applying the same edits to that request to (hopefully) reduce the edit cycle.

 

I have attached the ONF Formal URN request document = in ID form as described in sections 6.2 and 6.3 of RFC 8141.  Please s= ee Section 2 of draft-onf-urn.txt which is formatted based on the template = in Appendix A of RFC8141.

 

Regards,

-scott.

 

Scott Mansfield

Ericsson Inc.

+1 724 931 9316

 

--_000_CY1PR15MB023544C5860B901E31C7BF8D8B7C0CY1PR15MB0235namp_-- --_004_CY1PR15MB023544C5860B901E31C7BF8D8B7C0CY1PR15MB0235namp_ Content-Type: text/plain; name="draft-onf-urn.txt" Content-Description: draft-onf-urn.txt Content-Disposition: attachment; filename="draft-onf-urn.txt"; size=10258; creation-date="Fri, 15 Jun 2018 15:45:42 GMT"; modification-date="Fri, 15 Jun 2018 15:37:53 GMT" Content-Transfer-Encoding: base64 CgoKCkludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgICAgICAgICAgICAgICAgICAgICAg ICAgICBULiBTbG9hbmUsIEVkLgpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgT3BlbiBOZXR3b3JraW5nIEZvdW5kYXRpb24KSW50ZW5kZWQgc3RhdHVzOiBJbmZv cm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1heSAxLCAyMDE4CkV4cGly ZXM6IE5vdmVtYmVyIDIsIDIwMTgKCgogICAgICAgICAgICAgICAgICAgICAgICAgVVJOIE5hbWVz cGFjZSBmb3IgT05GCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZHJhZnQtb25mLXVybgoK QWJzdHJhY3QKCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBOYW1lc3BhY2UgSWRlbnRp ZmllciAoTklEKSAnb25mJyBmb3IKICAgVW5pZm9ybSBSZXNvdXJjZSBOYW1lcyAoVVJOcykgdXNl ZCB0byBpZGVudGlmeSByZXNvdXJjZXMgcHVibGlzaGVkIGJ5CiAgIHRoZSBPcGVuIE5ldHdvcmtp bmcgRm91bmRhdGlvbi4KClN0YXR1cyBvZiBUaGlzIE1lbW8KCiAgIFRoaXMgSW50ZXJuZXQtRHJh ZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUKICAgcHJvdmlzaW9u cyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBk b2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9yY2UgKElFVEYp LiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlCiAgIHdvcmtpbmcg ZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJu ZXQtCiAgIERyYWZ0cyBpcyBhdCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9j dXJyZW50Ly4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZv ciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2Vk LCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMg aW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRl cmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgog ICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIE5vdmVtYmVyIDIsIDIwMTguCgpD b3B5cmlnaHQgTm90aWNlCgogICBDb3B5cmlnaHQgKGMpIDIwMTggSUVURiBUcnVzdCBhbmQgdGhl IHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUKICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdo dHMgcmVzZXJ2ZWQuCgogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0 aGUgSUVURiBUcnVzdCdzIExlZ2FsCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1 bWVudHMKICAgKGh0dHBzOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVj dCBvbiB0aGUgZGF0ZSBvZgogICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNl IHJldmlldyB0aGVzZSBkb2N1bWVudHMKICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlv dXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0CiAgIHRvIHRoaXMgZG9jdW1l bnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0CiAg IGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0 aW9uIDQuZSBvZgogICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVk IHdpdGhvdXQgd2FycmFudHkgYXMKICAgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJTRCBM aWNlbnNlLgoKCgoKClNsb2FuZSAgICAgICAgICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMiwg MjAxOCAgICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg VVJOIE5hbWVzcGFjZSBmb3IgT05GICAgICAgICAgICAgICAgICBNYXkgMjAxOAoKClRhYmxlIG9m IENvbnRlbnRzCgogICAxLiAgSW50cm9kdWN0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDIKICAgMi4gIFVSTiBTcGVjaWZpY2F0aW9uIGZvciBP TkYgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAyCiAgICAgMi4xLiAgTmFt ZXNwYWNlIElkZW50aWZpZXIgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAg MwogICAgIDIuMi4gIFZlcnNpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgIDMKICAgICAyLjMuICBEYXRlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzCiAgICAgMi40LiAgUmVnaXN0cmFudCAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMwogICAgIDIu NS4gIFB1cnBvc2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgIDMKICAgICAyLjYuICBTeW50YXggIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzCiAgICAgMi43LiAgQXNzaWdubWVudCAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNAogICAgIDIuOC4gIFNlY3Vy aXR5IGFuZCBQcml2YWN5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQK ICAgICAyLjkuICBJbnRlcm9wZXJhYmlsaXR5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gICA0CiAgICAgMi4xMC4gUmVzb2x1dGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNAogICAgIDIuMTEuIERvY3VtZW50YXRpb24g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUKICAgMy4gIEFk ZGl0aW9uYWwgSW5mb3JtYXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICA1CiAgIDQuICBSZXZpc2lvbiBJbmZvcm1hdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAgNQogICA1LiAgQWNrbm93bGVkZ2VtZW50cyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUKICAgNi4gIElBTkEgQ29uc2lk ZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA1CiAg IDcuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAgNQogICA4LiAgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUKICAgICA4LjEuICBOb3JtYXRpdmUgUmVmZXJl bmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2CiAgICAgOC4yLiAg SW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAgNgogICBBdXRob3IncyBBZGRyZXNzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgIDYKCjEuICBJbnRyb2R1Y3Rpb24KCiAgIFRoZSBPcGVuIE5ldHdv cmtpbmcgRm91bmRhdGlvbiAoT05GKSBpcyBhIG5vbi1wcm9maXQgb3BlcmF0b3ItbGVkCiAgIGNv bnNvcnRpdW0gZHJpdmluZyB0cmFuc2Zvcm1hdGlvbiBvZiBuZXR3b3JrIGluZnJhc3RydWN0dXJl IGFuZAogICBjYXJyaWVyIGJ1c2luZXNzIG1vZGVscy4gIEFzIHBhcnQgb2YgdGhlc2Ugc3BlY2lm aWNhdGlvbiBlZmZvcnRzLAogICB0aGVyZSBpcyBhIG5lZWQgdG8gbWFpbnRhaW4gaWRlbnRpZmll cnMgaW4gYSBtYW5hZ2VkIG5hbWVzcGFjZSB0aGF0CiAgIGlzIHVuaXF1ZSBhbmQgcGVyc2lzdGVu dC4gIFRvIGVuc3VyZSB0aGF0IHRoaXMgbmFtZXNwYWNlJ3MgdW5pcXVlbmVzcwogICBpcyBhYnNv bHV0ZSwgc3BlY2lmaWNhdGlvbiBvZiBhbiBVUk4gTmFtZXNwYWNlIElkZW50aWZpZXIgKE5JRCkg Zm9yCiAgIHVzZSBieSB0aGUgT05GIGlzIHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50LCBpbiBm dWxsIGNvbmZvcm1hbmNlCiAgIHdpdGggdGhlIFVSTiByZWdpc3RyYXRpb24gcHJvY2VzcyBzcGVj aWZpZWQgaW4gVW5pZm9ybSBSZXNvdXJjZSBOYW1lcwogICAoVVJOcykgUkZDIDgxNDEgWzFdLiAg VGhlIE9ORiBzcGVjaWZpZXMgYW5kIG1hbmFnZXMgcmVzb3VyY2VzIHRoYXQKICAgdXRpbGl6ZSB0 aGlzIFVSTiBpZGVudGlmaWNhdGlvbiBtb2RlbC4gIE1hbmFnZW1lbnQgYWN0aXZpdGllcyBmb3IK ICAgdGhlc2UgYW5kIG90aGVyIHJlc291cmNlcyB0eXBlcyBhcmUgaGFuZGxlZCBieSB0aGUgbWFu YWdlciBvZiB0aGUgT05GCiAgIFVSTiBkb2N1bWVudC4KCjIuICBVUk4gU3BlY2lmaWNhdGlvbiBm b3IgT05GCgogICBUaGlzIHNlY3Rpb24gY29udGFpbnMgdGhlIG1hdGVyaWFsIGlkZW50aWZpZWQg aW4gQXBwZW5kaXggQSBSRkMgODE0MQogICBbMV0uCgoKCgoKCgpTbG9hbmUgICAgICAgICAgICAg ICAgICBFeHBpcmVzIE5vdmVtYmVyIDIsIDIwMTggICAgICAgICAgICAgICAgW1BhZ2UgMl0KDApJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgIFVSTiBOYW1lc3BhY2UgZm9yIE9ORiAgICAgICAgICAg ICAgICAgTWF5IDIwMTgKCgoyLjEuICBOYW1lc3BhY2UgSWRlbnRpZmllcgoKICAgUmVxdWVzdCBp cyBtYWRlIGZvciBhIGZvcm1hbCBhc3NpZ25tZW50OgoKICAgb25mCgoyLjIuICBWZXJzaW9uCgog ICAxCgoyLjMuICBEYXRlCgogICAyMDE4LTA1LTMxCgoyLjQuICBSZWdpc3RyYW50CgogICBSZWdp c3RlcmluZyBvcmdhbml6YXRpb246CiAgICAgIE5hbWU6IE9wZW4gTmV0d29ya2luZyBGb3VuZGF0 aW9uIChPTkYpCiAgICAgIEFkZHJlc3M6CiAgICAgICAgIDEwMDAgRWwgQ2FtaW5vIFJlYWwsIFN1 aXRlIDEwMAogICAgICAgICBNZW5sbyBQYXJrLCBDYWxpZm9ybmlhCiAgICAgICAgIDk0MjA1CiAg ICAgICAgIFVuaXRlZCBTdGF0ZXMgb2YgQW1lcmljYQogICAgICBEZXNpZ25hdGVkIGNvbnRhY3Qg cGVyc29uOgogICAgICAgICBUaW1vbiBTbG9hbmUKICAgICAgICAgUm9sZTogVlAgTWFya2V0aW5n ICYgRWNvc3lzdGVtLCBPTkYKICAgICAgICAgRW1haWw6IHRpbW9uQG9wZW5uZXR3b3JraW5nLm9y ZwoKMi41LiAgUHVycG9zZQoKICAgTmFtZXNwYWNlIG5lZWRlZCBmb3IgaWRlbnRpZmllcnMgZGVm aW5lZCBieSBPTkYsIGluY2x1ZGluZyB0aG9zZSB1c2VkCiAgIGluIFlBTkcgbW9kdWxlcyBSRkMg NjAyMCBbMl0gUkZDIDc5NTAgWzNdLiAgSW4gWUFORywgaWRlbnRpZmllcnMKICAgaWRlbnRpZnkg ZGlmZmVyZW50IGtpbmRzIG9mIFlBTkcgY29uc3RydWN0cy4gIEFuIGlkZW50aWZpZXIgaXMgYQog ICB2YWxpZCBuYW1lc3BhY2Ugd2hpY2ggcHJvdmlkZXMgdGhlIHNjb3BlIGZvciBZQU5HIG1vZHVs ZXMgYW5kIHRoZQogICBsZWFmcywgbGlzdHMsIGV0Yy4KCjIuNi4gIFN5bnRheAoKICAgdXJuOm9u Zjp7UmVzb3VyY2VTcGVjaWZpY1N0cmluZ30KCiAgICJSZXNvdXJjZVNwZWNpZmljU3RyaW5nIiBp ZGVudGlmaWVzIHRoZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUKICAgcmVzb3VyY2UuCgogICBPTkYg d2lsbCBtYW5hZ2UgdGhlIGFzc2lnbm1lbnQgb2YgIlJlc291cmNlU3BlY2lmaWNTdHJpbmciIGFu ZCB0aGUKICAgc3BlY2lmaWMgcmVnaXN0cmF0aW9uIHZhbHVlcyBhc3NpZ25lZCBmb3IgZWFjaCBy ZXNvdXJjZS4gIFRoZSBzeW50YXgKICAgb2YgIlJlc291cmNlU3BlY2lmaWNTdHJpbmciIG11c3Qg Y29uZm9ybSB0byB0aGUgTmFtZXNwYWNlIFNwZWNpZmljCiAgIFN0cmluZyBkZWZpbml0aW9uIGlu IFJGQyA4MTQxIFsxXS4gIFdoZW4gbWF0Y2hpbmcgdHdvIE9ORiBVUk5zIGZvcgogICBlcXVpdmFs ZW5jZSwgbWF0Y2hpbmcgb2YgdGhlICJSZXNvdXJjZVNwZWNpZmljU3RyaW5nIiBpcyBjYXNlCgoK ClNsb2FuZSAgICAgICAgICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMiwgMjAxOCAgICAgICAg ICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgVVJOIE5hbWVzcGFj ZSBmb3IgT05GICAgICAgICAgICAgICAgICBNYXkgMjAxOAoKCiAgIGluc2Vuc2l0aXZlLiAgQXBh cnQgZnJvbSB0aGlzLCB0aGUgcnVsZXMgZm9yIGxleGljYWwgZXF1aXZhbGVuY2UKICAgY292ZXJl ZCBpbiBTZWN0aW9uIDMgb2YgUkZDIDgxNDEgWzFdIGFwcGx5LiAgVGhlIE9ORiBwcm9jZXNzIGlz IGZvdW5kCiAgIGluIHRoZSBPTkYgVVJOIE1hbmFnZW1lbnQgWzRdIGRvY3VtZW50LgoKICAgRm9y IGNsYXJpdHksIGV4YW1wbGVzIG9mIGhvdyB0aGUgT05GIHBsYW5zIHRvIG1hbmFnZSB0aGUgSUFO QQogICBwcm92aXNpb25lZCBOYW1lc3BhY2VJZCBhbmQgdGhlIFJlc291cmNlU3BlY2lmaWNTdHJp bmcgZm9sbG93czoKCnVybjp7T05GLU5hbWVzcGFjZUlkfTp7T05GLVByb2plY3R9OntPTkYtU3Vi UHJvamVjdH06e1Byb3RvY29sfTp7TW9kdWxlTmFtZX0KCiAgIG8gIE9ORi1OYW1lc3BhY2VJZDog Im9uZiIgKE9wZW4gTmV0d29ya2luZyBGb3VuZGF0aW9uKQoKICAgbyAgVGhlIE9ORi1Qcm9qZWN0 OiBFeGFtcGxlOiAib3RjYyIgKE9wZW4gVHJhbnNwb3J0IENvbmZpZ3VyYXRpb24gJgogICAgICBD b250cm9sCgogICBvICBPTkYtU3ViUHJvamVjdDogRXhhbXBsZTogInRhcGkiIChUcmFuc3BvcnQg QVBJKQoKICAgbyAgUHJvdG9jb2w6IEV4YW1wbGU6ICJ5YW5nIgoKICAgbyAgTW9kdWxlTmFtZTog RXhhbXBsZSAiY29ubmVjdGl2aXR5IgoKICAgU28gYSBjb21wbGV0ZSBleGFtcGxlIHRoYXQgcHJv dmlkZXMgdGhlIFVSSSBmb3IgdGhlIGNvbm5lY3Rpdml0eSB5YW5nCiAgIG1vZGVsIGZvciB0aGUg dGFwaSBzdWItcHJvamVjdCBvZiB0aGUgb3RjYyBwcm9qZWN0IGZvciB0aGUgT05GIHdvdWxkCiAg IGJlOgoKICAgdXJuOm9uZjpvdGNjOnRhcGk6eWFuZzpjb25uZWN0aXZpdHkKCjIuNy4gIEFzc2ln bm1lbnQKCiAgIE9ORiBtYW5hZ2VzIHRoaXMgVVJOIGlkZW50aWZpY2F0aW9uIG1vZGVsIGFuZCB0 aGUgYXNzaWdubWVudCBvZgogICBpZGVudGlmaWVycyB3aXRoaW4gaXQgdG8gcmVzb3VyY2VzLgoK Mi44LiAgU2VjdXJpdHkgYW5kIFByaXZhY3kKCiAgIFNlZSB0aGUgbWF0ZXJpYWwgaW4gdGhlIFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zIChTZWN0aW9uIDcpIHNlY3Rpb24uCgoyLjkuICBJbnRlcm9w ZXJhYmlsaXR5CgogICBUaGUgcHVycG9zZSBvZiB0aGUgT05GIG5hbWVzcGFjZSBhbmQgaXRzIHVz ZSBmb3IgWUFORyBpcyBtZWFudCB0byBhaWQKICAgaW50ZXJvcGVyYWJpbGl0eSBieSBhdm9pZGlu ZyBkdXBsaWNhdGUgb3IgY29uZmxpY3RpbmcgbmFtZXNwYWNlcy4KCjIuMTAuICBSZXNvbHV0aW9u CgogICBObyByZXNvbHV0aW9uIG1lY2hhbmlzbSBpcyBpbnRlbmRlZCBvciBhbnRpY2lwYXRlZC4K CgoKCgoKCgpTbG9hbmUgICAgICAgICAgICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIsIDIwMTgg ICAgICAgICAgICAgICAgW1BhZ2UgNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIFVSTiBO YW1lc3BhY2UgZm9yIE9ORiAgICAgICAgICAgICAgICAgTWF5IDIwMTgKCgoyLjExLiAgRG9jdW1l bnRhdGlvbgoKICAgVGhlIE9ORiBtYWludGFpbnMgYSBVbmlmb3JtIFJlc291cmNlIE5hbWVzIChV Uk4pIGRvY3VtZW50IHRoYXQKICAgcHJvdmlkZXMgdGhlIG1lY2hhbmlzbSB0byBlbnN1cmUgdGhl IHJlc291cmNlIGlkZW50aWZpZXJzIGFyZSB1bmlxdWUuCiAgIFRoZSBPTkYgVVJOIE1hbmFnZW1l bnQgWzRdIGRvY3VtZW50IGNvbnRhaW5zIHRoZSBmb3JtYXR0aW5nCiAgIGd1aWRlbGluZXMgZm9y IHRoZSBVUk4gaGllcmFyY2h5IHRoYXQgaXMgcm9vdGVkIGF0IHRoZSBiYXNlIFVSTiB0aGF0CiAg IHdhcyBhc3NpZ25lZCBieSBJQU5BLgoKMy4gIEFkZGl0aW9uYWwgSW5mb3JtYXRpb24KCiAgIE5v bmUuCgo0LiAgUmV2aXNpb24gSW5mb3JtYXRpb24KCiAgIG8gIHYxOiBJbml0aWFsIFZlcnNpb24s IGRlZmluaW5nICJvbmYiIGFzIHRoZSBOYW1lc3BhY2UgSWRlbnRpZmllcgoKNS4gIEFja25vd2xl ZGdlbWVudHMKCiAgICAgIEx5bmRvbiBPbmcKICAgICAgUm9sZTogQ2hhaXIgb2YgT3BlbiBUcmFu c3BvcnQgQ29uZmlndXJhdGlvbiBhbmQgQ29udHJvbCBQcm9qZWN0CiAgICAgIEVtYWlsOiBseW9u Z0BjaWVuYS5jb20KCiAgICAgIEthbSBMYW0KICAgICAgUm9sZTogQ28tQ2hhaXIgb2YgT3BlbiBJ bmZvcm1hdGlvbiBNb2RlbGluZyBhbmQgVG9vbGluZyBQcm9qZWN0CiAgICAgIEVtYWlsOiBrYW0u bGFtQGZpYmVyaG9tZS5jb20KCiAgICAgIE5pZ2VsIERhdmlzCiAgICAgIFJvbGU6IENvLUNoYWly IG9mIE9wZW4gSW5mb3JtYXRpb24gTW9kZWxpbmcgYW5kIFRvb2xpbmcgUHJvamVjdAogICAgICBF bWFpbDogbmRhdmlzQGNpZW5hLmNvbQoKNi4gIElBTkEgQ29uc2lkZXJhdGlvbnMKCiAgIFRoaXMg ZG9jdW1lbnQgYWRkcyAib25mIiB0byB0aGUgIkZvcm1hbCBVUk4gTmFtZXNwYWNlcyIgcmVnaXN0 cnkKICAgPGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvdXJuLW5hbWVzcGFjZXM+LiAg VGhpcyBpcyB0aGUKICAgZGVmaW5pbmcgZG9jdW1lbnQuCgo3LiAgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMKCiAgIFRoZXJlIGFyZSBubyBhZGRpdGlvbmFsIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25z IG90aGVyIHRoYW4gdGhvc2UKICAgbm9ybWFsbHkgYXNzb2NpYXRlZCB3aXRoIHRoZSB1c2UgYW5k IHJlc29sdXRpb24gb2YgVVJOcyBpbiBnZW5lcmFsLAogICB3aGljaCBpcyBkZXNjcmliZWQgaW4g VW5pZm9ybSBSZXNvdXJjZSBOYW1lcyAoVVJOcykgUkZDIDgxNDEgWzFdLgoKOC4gIFJlZmVyZW5j ZXMKCgoKCgoKCgpTbG9hbmUgICAgICAgICAgICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIsIDIw MTggICAgICAgICAgICAgICAgW1BhZ2UgNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIFVS TiBOYW1lc3BhY2UgZm9yIE9ORiAgICAgICAgICAgICAgICAgTWF5IDIwMTgKCgo4LjEuICBOb3Jt YXRpdmUgUmVmZXJlbmNlcwoKICAgWzFdICAgICAgICBTYWludC1BbmRyZSwgUC4gYW5kIEouIEts ZW5zaW4sICJVbmlmb3JtIFJlc291cmNlIE5hbWVzCiAgICAgICAgICAgICAgKFVSTnMpIiwgUkZD IDgxNDEsIERPSSAxMC4xNzQ4Ny9SRkM4MTQxLCBBcHJpbCAyMDE3LAogICAgICAgICAgICAgIDxo dHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzgxNDE+LgoKOC4yLiAgSW5mb3JtYXRp dmUgUmVmZXJlbmNlcwoKICAgWzJdICAgICAgICBCam9ya2x1bmQsIE0uLCBFZC4sICJZQU5HIC0g QSBEYXRhIE1vZGVsaW5nIExhbmd1YWdlIGZvcgogICAgICAgICAgICAgIHRoZSBOZXR3b3JrIENv bmZpZ3VyYXRpb24gUHJvdG9jb2wgKE5FVENPTkYpIiwgUkZDIDYwMjAsCiAgICAgICAgICAgICAg RE9JIDEwLjE3NDg3L1JGQzYwMjAsIE9jdG9iZXIgMjAxMCwKICAgICAgICAgICAgICA8aHR0cHM6 Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM2MDIwPi4KCiAgIFszXSAgICAgICAgQmpvcmts dW5kLCBNLiwgRWQuLCAiVGhlIFlBTkcgMS4xIERhdGEgTW9kZWxpbmcgTGFuZ3VhZ2UiLAogICAg ICAgICAgICAgIFJGQyA3OTUwLCBET0kgMTAuMTc0ODcvUkZDNzk1MCwgQXVndXN0IDIwMTYsCiAg ICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzk1MD4uCgog ICBbNF0gICAgICAgIE9ORiwgIk9ORiBVUk4gTWFuYWdlbWVudCIsIDIwMTgsIDxodHRwczovL2Jp dC5seS8yS3l5ZmRyPi4KCkF1dGhvcidzIEFkZHJlc3MKCiAgIFRpbW9uIFNsb2FuZSAoZWRpdG9y KQogICBPcGVuIE5ldHdvcmtpbmcgRm91bmRhdGlvbgogICAxMDAwIEVsIENhbWlubyBSZWFsIFN1 aXRlIDEwMAogICBNZW5sbyBQYXJrLCBDYWxpZm9ybmlhICA5NDAyNQogICBVbml0ZWQgU3RhdGVz IG9mIEFtZXJpY2EKCiAgIFBob25lOiArMSA2NTAgMjA4IDA4NTcKICAgRW1haWw6IHRpbW9uQG9w ZW5uZXR3b3JraW5nLm9yZwoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKU2xvYW5lICAgICAgICAgICAg ICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyLCAyMDE4ICAgICAgICAgICAgICAgIFtQYWdlIDZdCg== --_004_CY1PR15MB023544C5860B901E31C7BF8D8B7C0CY1PR15MB0235namp_-- From nobody Wed Jun 20 00:36:59 2018 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22432131052 for ; Wed, 20 Jun 2018 00:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no 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 ry5kpxAItjOX for ; Wed, 20 Jun 2018 00:36:54 -0700 (PDT) Received: from mail.dnb.de (mail.dnb.de [193.175.100.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1B3A130DC1 for ; Wed, 20 Jun 2018 00:36:54 -0700 (PDT) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by mail.dnb.de (Postfix) with ESMTP id 0C950434C350; Wed, 20 Jun 2018 09:36:52 +0200 (CEST) X-AuditID: 0a453fe7-199ff700000025db-0f-5b2a0413ea76 Received: from dnbf-ex.AD.DDB.DE (dnbf-ex.AD.DDB.DE [10.69.63.244]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id 5F.9B.09691.3140A2B5; Wed, 20 Jun 2018 09:36:51 +0200 (CEST) Received: from dnbf-ex.AD.DDB.DE (10.69.63.244) by dnbf-ex.AD.DDB.DE (10.69.63.244) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.669.32; Wed, 20 Jun 2018 09:36:51 +0200 Received: from dnbf-ex.AD.DDB.DE ([fe80::3576:7565:4f15:49c7]) by dnbf-ex.AD.DDB.DE ([fe80::3576:7565:4f15:49c7%4]) with mapi id 15.01.0669.032; Wed, 20 Jun 2018 09:36:50 +0200 From: "Svensson, Lars" To: Scott Mansfield , "urn@ietf.org" CC: "Davis, Nigel (ndavis@ciena.com)" , "kamlam@fiberhome.com" Thread-Topic: Updated URN request for ONF Thread-Index: AdQEvwg9zv/GKNEKQ2aX+YHfYA6rNADo8Y1A Date: Wed, 20 Jun 2018 07:36:50 +0000 Message-ID: <4a4e8530a53a407293e8460746085aea@dnb.de> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.69.12.162] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA11Te0hTURj37N7N49qp49XN07Kw9dAWqYXViuhFwQKhwH+qFXZtt204t7G7 Rfaghz3AHpRkj9lDc70pllRG9qBBZYE9pCAtIrJVpqVF0Yu0e3c3u/bfd3/f93uc7+NCiqmA euhw+Tivi3UaVGpaPXfG13EptNGSu2Vbtqn1UyjRFHmebipvuKMyVZZ1K2bS5qaWHtr869tT lblu5y3KHAz+VCygF6unWTmnYyXnzZm+TG0/fOQt5WmGq87WmjeALlU5SIIE55EDZd8Ty4Ea MjgMSNXGAC19tAHSVXE89nERkE0f71HlIBGqsJF02UVyKi4gtY2NUSEKO0jwwedonYKzyPaK dpU0M4Zs3d2pkOoJpKXzDxBrGo8iR+6cUoo1whNJZWBPdIbBS0jg9l1arJPwUrK/uiI6D/BQ Ego9pCSvNFL39rtSegAmwWsSTrCWtLf1xPAMEnnxTSHN55KuB0dj3LHkRE0HJfkmk3sH39C7 gS4gkw3IKAEZJSCjVAP6DBjIl9jGZ7PWbKu1KNvK1QHpVO+ugF3Nc8IAQ2DQoCdgjIVRsiv5 0pIwmA8VBi2KvBSggUVua6md5e2FXr+T4w2p6PxzAUZ9cJHfWWwYhl7vzbIwaX0o7+c9juUO t58v9HudwsEgJVAT7gtDyMqWrua8bkkwDIZA2pCG2m8kLGSwjfVxxRzn4bzx7kIIDQTlK4wW JtnL2bhVKxxOX7wt8JpvCGmwvBMNNBw1zcq0MHp54/9MCpgUBvlQIwRbLuoj3sOW8A5bTDsF HYoI2po4GtUdin6ID9XFwf6a9wEHO7fu2EHBnpabOymGdrldnD4NUZQgj0WO3e/qS6/Xobui 2CBZQzTRZyDrZ8F5sAzv7/MBzBOOloIuiLE1wi/4LzWDmoAADoiB0dDpKLlS8NHGsP+18oVr p6KLqzPFFfhYn3wFm0WiJo7GVrClMrqCGNhfTr8BnM5MH9696VrBI2XelJw1rztOhtS6SwWe qo62L9udI2ZdHh1Jatvfej2410S//91xZer14oSTjdX7jukOrh9hqR9bNPKQ9llNWfcPrrfq YcMipvXZZKZQMXvz4/reA1pb1qQ/xoKvr17kXX1pWupuVK5o+JUwYO25dTnjQvWHR+WGbvW+ N9C8nR1vpLw8+xfV0ej0pQQAAA== Archived-At: Subject: Re: [urn] Updated URN request for ONF X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 07:36:58 -0000 Thanks Scott, The registration looks good to me. I have no further comments. Best, Lars > -----Original Message----- > From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Scott Mansfield > Sent: Friday, June 15, 2018 5:47 PM > To: urn@ietf.org > Cc: Davis, Nigel (ndavis@ciena.com) ; kamlam@fiberhome.= com > Subject: [Marketing Mail] [Caution: Message contains Redirect URL content= ] [urn] > Updated URN request for ONF >=20 > I have addressed all comments from the community and verified the resolut= ions with > the commenters. Thanks to everyone that provided feedback.=A0 I am also w= orking on a > URN request for the ITU, so I am applying the same edits to that request = to (hopefully) > reduce the edit cycle. >=20 > I have attached the ONF Formal URN request document in ID form as describ= ed in > sections 6.2 and 6.3 of RFC 8141.=A0 Please see Section 2 of draft-onf-ur= n.txt which is > formatted based on the template in Appendix A of RFC8141. >=20 > Regards, > -scott. >=20 > Scott Mansfield > Ericsson Inc. > +1 724 931 9316 From nobody Thu Jun 21 11:10:46 2018 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE2F8130DF5 for ; Thu, 21 Jun 2018 11:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com 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 fmAB9SuHMNr6 for ; Thu, 21 Jun 2018 11:10:36 -0700 (PDT) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EC4513113C for ; Thu, 21 Jun 2018 11:10:36 -0700 (PDT) Received: by mail-ot0-x22e.google.com with SMTP id c15-v6so4628958otl.3 for ; Thu, 21 Jun 2018 11:10:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kxl5qOuT6Pa6vL8zkzWPhAFRRNYQZJxx7FsuPlMtNIw=; b=XRbaQAdVdxVE9oeQRfPgJOufWrBoRWXxTg9LKw59xARvG8fJ5ile1Rn/UDuJzCr9nt rvbllUY8hIeWrQSPxLdH9iPTBHeyn/yhrgjmrz0luT9bG+fhtFcWY+3P4hW/u2k++DLH YZx0LgQ+jIYD1Ed00+xerQnuescbdZTuPi6Iw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kxl5qOuT6Pa6vL8zkzWPhAFRRNYQZJxx7FsuPlMtNIw=; b=sYc+dSZt2jY6AD/euGXauKDMot1ZQI6Lajr3jA2pf9OS7IwQYuozAo37zduTTdmZLf 1MQTx4Df9rqPDSk8ppHSDh7m1KQAjYbRcCq5spUSeDRZui76pDlhZmaUMKqrPCwfOObt n779l4f20B4VXjFKCn+E/cKiYtdgnWnAuCf7Lx58FNc5u6+rI4jnBldjEeS2+Qu3aTQ8 A93yGqkksTsMefvIoS43lQ5iQpTjWGJejjKJwd/Sp/wJpoEm7HZMVa8SfKHpAMUv+CL6 2K77VkNkSva6kdkXvqU6cVRUXhbRb2Ocj3vEqOy740GgwjmPpaxAwPai8t+xFl3wk6Nk jWbg== X-Gm-Message-State: APt69E1+tWbjegsrc5yfzCKA6QH7Irc+aUSB6yLgZSzWHN3IWcim+csU o1879WV3VjrMp8wzMSD0NhDWkfoN1os= X-Google-Smtp-Source: ADUXVKLiXdTH7goMRHuZ36hPIB3NnQZxuguaYIJE1tU4qApJq5JCqQVmbOJc2lGBvtGHsFq8STKjDQ== X-Received: by 2002:a9d:440d:: with SMTP id u13-v6mr17634009ote.374.1529604635589; Thu, 21 Jun 2018 11:10:35 -0700 (PDT) Received: from [10.223.23.3] (mobile-166-173-185-120.mycingular.net. [166.173.185.120]) by smtp.gmail.com with ESMTPSA id b203-v6sm2640989oii.48.2018.06.21.11.10.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jun 2018 11:10:35 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Peter Saint-Andre X-Mailer: iPhone Mail (15F79) In-Reply-To: <4a4e8530a53a407293e8460746085aea@dnb.de> Date: Thu, 21 Jun 2018 12:10:33 -0600 Cc: Scott Mansfield , "urn@ietf.org" , "Davis, Nigel (ndavis@ciena.com)" , "kamlam@fiberhome.com" Content-Transfer-Encoding: quoted-printable Message-Id: <4971F316-B4C3-4647-B179-71077FC2AF0B@mozilla.com> References: <4a4e8530a53a407293e8460746085aea@dnb.de> To: "Svensson, Lars" Archived-At: Subject: Re: [urn] Updated URN request for ONF X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 18:10:43 -0000 Ship it! :) Sent from mobile, might be terse=20 > On Jun 20, 2018, at 1:36 AM, Svensson, Lars wrote: >=20 > Thanks Scott, >=20 > The registration looks good to me. I have no further comments. >=20 > Best, >=20 > Lars >=20 >> -----Original Message----- >> From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Scott Mansfield >> Sent: Friday, June 15, 2018 5:47 PM >> To: urn@ietf.org >> Cc: Davis, Nigel (ndavis@ciena.com) ; kamlam@fiberhome.= com >> Subject: [Marketing Mail] [Caution: Message contains Redirect URL content= ] [urn] >> Updated URN request for ONF >>=20 >> I have addressed all comments from the community and verified the resolut= ions with >> the commenters. Thanks to everyone that provided feedback. I am also wor= king on a >> URN request for the ITU, so I am applying the same edits to that request t= o (hopefully) >> reduce the edit cycle. >>=20 >> I have attached the ONF Formal URN request document in ID form as describ= ed in >> sections 6.2 and 6.3 of RFC 8141. Please see Section 2 of draft-onf-urn.= txt which is >> formatted based on the template in Appendix A of RFC8141. >>=20 >> Regards, >> -scott. >>=20 >> Scott Mansfield >> Ericsson Inc. >> +1 724 931 9316 >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Fri Jun 29 15:09:13 2018 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB24130E28; Fri, 29 Jun 2018 15:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ngydkDXVLRDq; Fri, 29 Jun 2018 15:09:08 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1FE130E1B; Fri, 29 Jun 2018 15:09:08 -0700 (PDT) X-AuditID: 12074423-693ff700000019ec-d7-5b36ae02cc4b Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 79.07.06636.30EA63B5; Fri, 29 Jun 2018 18:09:07 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w5TM94k1015560; Fri, 29 Jun 2018 18:09:05 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w5TM8xk7021814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 29 Jun 2018 18:09:02 -0400 Date: Fri, 29 Jun 2018 17:08:59 -0500 From: Benjamin Kaduk To: "Hakala, Juha E" Cc: John C Klensin , Peter Saint-Andre , "urn@ietf.org" , The IESG , "draft-hakala-urn-nbn-rfc3188bis@ietf.org" Message-ID: <20180629220859.GF40164@kduck.kaduk.org> References: <152837409539.30768.4568779645299135020.idtracker@ietfa.amsl.com> <6a1a100c-3bc0-76d3-3ae4-047d37906bfc@mozilla.com> <20180608203227.GD16349@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAKsWRmVeSWpSXmKPExsUixCmqrMu8ziza4O0STos/13+xWMz4M5HZ ovXSHzaLpk/t7BbPVp5itJja/IHJgc2jf+V+do8lS34yeVxe+ZrZo+9AF2sASxSXTUpqTmZZ apG+XQJXRuu9E8wFazsZK67Nu8/SwPg+t4uRk0NCwETi3o8ZbF2MXBxCAouZJHrnb2KGcDYy SvT/3cwC4Vxlkvj/dwErSAuLgKrEqS33wWw2ARWJhu7LzCC2iICexLLltxlBGpgFfjFKrLg2 mREkISyQLzFtyVUmEJsXaN+Eq8fZIaYuZJL4POMgI0RCUOLkzCcsIDazgI7Ezq13gI7iALKl JZb/44AIa0ssW/gabBmnQKzEk9X7wFpFBZQl9vYdYp/AKDgLyaRZSCbNQpg0C8mkBYwsqxhl U3KrdHMTM3OKU5N1i5MT8/JSi3TN9HIzS/RSU0o3MYIig91FeQfjyz7vQ4wCHIxKPLwXgsyi hVgTy4orcw8xSnIwKYnyHhYDCvEl5adUZiQWZ8QXleakFh9ilOBgVhLhDQQp501JrKxKLcqH SUlzsCiJ8+YsYowWEkhPLEnNTk0tSC2CycpwcChJ8J5cA9QoWJSanlqRlplTgpBm4uAEGc4D NPwlSA1vcUFibnFmOkT+FKMux5/3UycxC7Hk5eelSonzbgYpEgApyijNg5sDSmgS2ftrXjGK A70lzCu2FqiKB5gM4Sa9AlrCBLSk+rgpyJKSRISUVAPjLJ9sTV9Jg0cPlZieajD1ta61vLXW 8Xev4dxErY2Ob8Pq+n/dOzU16QKvRb9bwJmumVVOzK8YzqR8jP4fr9f+Quyn5BaV3s/30lcU T9m8nXVx9a2Pp5WCJBiSnqZ9S1NNC4u4PN0v/vMdxT8tbdFq1bd+OEbtW9eZOFmsVy0k7cp5 o4nL1QuUWIozEg21mIuKEwFau7+yQwMAAA== Archived-At: Subject: Re: [urn] Benjamin Kaduk's Discuss on draft-hakala-urn-nbn-rfc3188bis-01: (with DISCUSS and COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 22:09:11 -0000 My belated thanks to Juha and everyone for the additional explanations. I think the changes in the -01 help at least this reader. I cleared my discuss position; sorry that it took so long to do so. -Benjamin On Mon, Jun 11, 2018 at 08:42:07AM +0000, Hakala, Juha E wrote: > Hello, >=20 > comments inline.=20 >=20 > -----Original Message----- > From: urn On Behalf Of John C Klensin > Sent: lauantai 9. kes=E4kuuta 2018 23.21 > To: Benjamin Kaduk ; Peter Saint-Andre > Cc: urn@ietf.org; The IESG ; draft-hakala-urn-nbn-rfc3188b= is@ietf.org > Subject: Re: [urn] Benjamin Kaduk's Discuss on draft-hakala-urn-nbn-rfc31= 88bis-01: (with DISCUSS and COMMENT) >=20 >=20 >=20 > --On Friday, June 8, 2018 15:32 -0500 Benjamin Kaduk wrot= e: >=20 > >> The semantics of r-components are yet to be defined. I would venture= =20 > >> that the IETF is probably not the right place to do that work, given= =20 > >> how little energy remained in the URN WG at the end (and we probably= =20 > >> didn't have the right people in the room in the first place). >=20 > Juha: in order to avoid chaos, URN user community needs a centrally maint= ained registry of resolution services and parameters related to them. As fa= r as I am concerned, r-component syntax and semantics should not be user- o= r namespace-specific, it has to apply to all namespaces. So if somebody es= tablishes r-component syntax for requesting a Dublin Core metadata record a= bout the identified resource, the components used should be registered. And= before creating the r-component, URN users should check from the registry = if the required components (service and parameters) exist already. =20 >=20 > While writing the I-D, my assumption was that r-component usage will only= start once there is an agreement on r-component syntax, and there is a cen= tral registry for services specified. Developing syntax should not be rocke= t science; what we need is a way to specify services and parameters related= to them in a machine readable way.=20 >=20 > Assuming that each r-component is allowed to contain one and only one ser= vice and 0-n parameters related to it, syntax might look like this:=20 >=20 > s=3D&=3D&=3D&...&=3D >=20 > for instance:=20 >=20 > s=3DURC&format=3DDC >=20 > to request metadata about the identified resource in Dublin Core format. = I am sure that people who are more technically oriented than myself will c= ome up with something better than my example, but the components (services = and their parameters) should be the same.=20 >=20 > Generic r-component syntax can be specified without any knowledge about t= he resolution services to be supported, but service specific details may on= ly be provided by experts who know how current applications operate. I do h= ope that IETF experts can assist with syntax definition; once that (and the= registry) is in place, URN user communities can start providing service le= vel specifications.=20 >=20 > Users of persistent identifiers (DOI, Handle, ARK, URN) are all currently= under pressure to enrich the functionality of resolvers. Unless a central = (and shared) registry of resolution services is established, there is a cle= ar danger that each identifier system will develop its own solutions, which= will seriously limit interoperability between persistent identifier system= s.=20 >=20 > > I won't argue with that. Does it make sense to say something like=20 > > "There are not currently any broadly accepted semantics for=20 > > r-components at the time of this writing which may be grounds to be=20 > > cautious with their use" in this document? >=20 > Juha: such text can be added as a clarification. Since my assumption has = been that the r-component will not be used at all before we have generally = approved syntax and semantics for it, I might use even stronger formulation= than just "cautious". But as noted above, I did not say anything about thi= s because I thought that non-usage of r-component applies automatically to = all URN namespaces as long as r-component syntax is still work in progress.= It seems a bit redundant to repeat the same thing in all namespace registr= ations.=20 >=20 > Having said that, I do hope that the syntax will be formally specified so= on, so that the URN user communities can start adding service level specifi= cations into the central registry (which should also be there from the begi= nning). =20 >=20 > >> > If an NBN identifies a work, descriptive metadata about > >> > the work SHOULD be supplied. The metadata record MAY > >> > contain links to Internet-accessible digital > >> > manifestations of the work. > >> >=20 > >> > This left me confused. Is it only intended to apply in the case=20 > >> > described in the previous paragraph, where the resource identified= =20 > >> > by the NBN is not available in the Internet? Or does it always=20 > >> > apply, forcing the metadata to take precedence over delivering the= =20 > >> > actual work? (Or maybe I'm just confused, and there's an easy way= =20 > >> > to deliver both metadata and the actual work alongside each other=20 > >> > with no ambiguity.) > >>=20 > >> Juha can clarify this. >=20 > Juha: I can understand why this confuses people. Sorry, this bit is libra= ry specific and hard to understand unless the reader knows our practices.= =20 >=20 > Work itself is immaterial. There may be 0-n manifestations of it, some of= them hand-held, some digital.=20 >=20 > Work is an umbrella concept with which it is possible to bring together a= ll existing manifestations. In practice this can be done by e.g adding to t= he work metadata record links to the metadata records describing these mani= festations. A practical example of similar practice is a splash page descri= bing a research data set ("work level metadata"). Such pages often contains= links to all versions of the relevant data set, with manifestation level m= etadata such as appropriate warnings if some versions of the data set are v= ery large.=20 >=20 > A user who requires metadata about a work may not even know if there are = digital manifestations of the work. But with the metadata record the user w= ill be able to find this out, and select the version which suits his/her ne= eds best. =20 >=20 > >> > Section 4.1 > >> >=20 > >> > National Bibliography Number (NBN) is a generic term > >> > referring to a group of identifier systems administered > >> > by the national libraries and institutions authorized by > >> > them. > >> >=20 > >> > "the national libraries" implies a specific set -- which ones? It= =20 > >> > may be better to hedge with "some national libraries". > >>=20 > >> Or remove "the" ... "by national libraries". >=20 > > That's probably better :) >=20 > That would be my preference, but Juha should decide on this. >=20 > Juha: by national libraries is better.=20 >=20 >=20 > >> > Section 4.2.2 > >> >=20 > >> > Do we need to say anything about a URN-to-URI step before talking=20 > >> > about URI-to-resource services? >=20 > Given what 3986 has to say, a URN-to_URI step would be an oxymoron. If y= ou meant a URN-to-URL step, that is probably a matter for 8141 and it may b= e worth pointing out that members of the web community (a euphuism for a pa= rticular, mostly known, set of individuals who claim to speak for that comm= unity in case you haven't figured that out) have been violently opposed to = such text, claiming that, if it is needed, then there is really no need for= URNs. On the other hand, while the URNBIS WG could not reach consensus on= any particular proposal and did reach consensus about not trying to procee= d with definitions, that is much of what r-components are expected to be ab= out. >=20 > >> > I'm also wondering about any relationship between "component=20 > >> > resource" NBNs and f-components of the containing work. If there=20 > >> > is are NBNs assigned to both an image within a work and that=20 > >> > containing work, and an NBN with f-resource is used to refer to the= =20 > >> > image within the containing work, is there any relationship between= =20 > >> > the f-resource and the image-specific NBN? >=20 > On a per-sub-namespace basis, possibly. In the general case, > maybe. This is not an NBN issue but an issue about how namespaces are ma= naged, organized, and used, i.e., probably an > 8141 issue. >=20 > Juha: with NBN, national libraries have free hands to specify their own n= aming policies. They may give just one identifier for e.g. an entire EPUB 3= =2E0.1 e-book, or they may assign separate identifiers for all the componen= t parts of the e-book. The best policy depends on many things, including th= e level of control & access required / possible.=20 >=20 > NBN specification does not specify limits on what can / should be done. I= f the library prefers to use f-component to identify for instance images in= a PDF document, that is fine. =20 >=20 > >> > Section 4.3 > >> >=20 > >> > Expressing NBNs as URNs is usually straightforward, as > >> > only ASCII characters are allowed in NBN strings. If > >> > necessary, NBNs MUST be translated into canonical form > >> > as specified in RFC 8141. > >> >=20 > >> > When is it necessary? > >>=20 > >> It seems that in theory an NBN itself could contain non-ASCII=20 > >> characters, whereas an NBN URN and its nbn_string construct can=20 > >> contain only ASCII characters. At least that is my understanding. >=20 > That is correct. But, more or less per 3986, _any_ URI can contain non-A= SCII characters in the tail by %-encoding them. > There were some moves in the URNBIS WG to restrict that for URNs, but it = met resistance from the usual suspects. The bottom line here, and I don't = know how loudly to say it, is that using non-ASCII characters in nbn_string= s would probably nothing short to stupid, especially given that both IETF a= nd W3C have suggested that they be avoided in identifiers non-specialist end > users are not expected to see. However, due to a problem that > goes back well before the early decision that ISO 8859-1 was going to be = an adequate encoding for HTMP content (but of which that decision is sympto= matic), it would be unsurprising if one or more national libraries whose lo= cal language uses Latin script with a few lightly-decorated characters had = not taken that advice or had decided to incorporate existing (perhaps for > decades) identifier strings with a few Latin characters outside > the ASCOO subset into their national NBNs. One could imagine > rewording the text mentioned above for more clarity (a job I will happily= leave to the experts who make up the RFC Editor > function) but the bottom line is that all we do is to say "don't do that,= but if you decide to do it anyway, this is what you must do to prevent eve= n worse problems". =20 >=20 > Juha: all NBNs I have seen so far have contained just (printable) ASCII c= haracters. But outside Europe there may be national libraries which have be= en more liberal. If so, non-ASCII characters in their NBNs must be %-encode= d when these NBNs become URN:NBNs.=20 >=20 > Nobody knows if there are NBNs with non-ASCII characters, and if so, how = common they are. Therefore I decided to drop the recommendation that such c= haracters should be avoided in NBN strings.=20 >=20 > In order to clarify text, beginning of 4.3 could be edited into:=20 >=20 > Expressing NBNs as URNs is straightforward if NBN strings contain only AS= CII characters. Non-ASCII characters, if any, MUST be translated into canon= ical form as specified in RFC 8141.=20 >=20 > >> > Being part of the prefix, sub-namespace identifier > >> > strings are case- insensitive. They MUST NOT contain > >> > any hyphens. > >> >=20 > >> > This MUST seems to just duplicate a syntactic requirement from the= =20 > >> > ABNF; is RFC 2119 language really necessary? > =20 > >> /me shrugs >=20 > Probably not, but, while Juha should confirm, I assume that part of the o= rigin of this text is that several other International Standard identifiers= , e.g., ISBNs, all hyphens and treat them as > optional. It might be wise to reinforce the message that the > URN:NBN solution to the problems that causes is to clearly say "no" and s= ay that clearly enough that even those whose eyes > glaze over at ABNF will get the message. Whether it is better > done by something like the sentences above or by saying "Hyphens are proh= ibited by the ABFN, see Section XXXX" is, IMO, a matter of editorial style = and preference. >=20 > Juha: I believe this may be an error inherited from RFC 3188. The forbidd= en character should be colon.=20 >=20 > URN:NBNs with sub-namespaces look like this:=20 >=20 > urn:nbn:se:uu:diva-284370 >=20 > This is a Swedish URN:NBN assigned by the Uppsala university. Organizati= ons which have a sub-namespace may divide their sub-namespace further if ne= cessary, using colons (e.g. Uppsala could create a namespace ID urn:nbn:se:= uu:thesis:). Given the special role the colon has, sub-namespace identifier= s must not contain them, since theoretically allowing colons could cause du= plicate assignments. So if there is nbn:fi subnamespaces nbn:fi:aa, every N= ID in the form nbn:fi:aa: must be a sub-namespace of nbn:fi:aa. = =20 >=20 > Changing the specification might cause problems with backwards compatibil= ity had some libraries assigned sub-namespaces with colons in them. I don't= think that this is the case. So the next version of the I-D could say "MUS= T NOT contain any hyphens or colons".=20 > =20 >=20 > >> > Section 8 > >> >=20 > >> > John Klensin provided significant editorial and advisory > >> > support for late versions of the draft. > >> >=20 > >> > Presumably that's "later versions"? > >>=20 > >> Yes. >=20 > I really don't care. If one thinks this is an editorial problem, leave i= t to the RFC Editor. If one thinks it is substantive, remember that, while= this is a -00 draft, the I-D itself has been through many iterations under= other names, so it depends on how you count because I had nothing to do wi= th early version of the I-D and at most only a reviewer/participant role in= RFC 3188. If this were a different sort of document and I cared, I could = make a strong case that I've been involved enough and have written enough t= ext to be listed as a Contributor, but I think the nature of this document = is that it is better if Juha is sole author without contributors other than= Alfred.=20 >=20 > FWIW, I can't see why attribution at this level should be an IESG problem= unless you have reason to believe that IPR rules are being violated. >=20 > Juha: I think "later versions" is fine.=20 >=20 > Finally, to avoid writing a separate note even though it will make this a= paragraph longer, I think several of the comments you )Benjamin) and Adam = have made make a strong case for a clarifying update to RFC 8141. In princ= iple, I agree with that. > It is little surprise to me that new URN namespace proposals are exposing= issues that, if we had more ability to predict them, would have been refle= cted in 8141 itself. The difficulty with such an update is that, at the ti= me 8141 and 8254 were completed, the URNBIS WG had run out of energy and wa= s developing a level of acrimony that made further progress unlikely. If w= e were to try to open 8141 to do a clarification, I can just about guarante= e that some of those who were the sources of frustration that led to that a= crimony would insist that no document move forward until their pet issues a= nd easy solutions were addressed. That, in turn, would result in a situati= on like the i18n one, only with less downside if the issues are not address= ed and more issues that soul require solving fundamental philosophical disa= greements in IETF community. I can't recommend going there, but it doesn't = seem to me that trying to clarify 9141 by text in a single namespace defini= tion is the solution either. >=20 > Juha: library community has been using URN:NBNs succesfully since RFC 318= 8 was published. Tens of millions of identifiers have been assigned. From l= ibraries' point of view, the important thing is that the revised RFC valida= tes some new URN:NBN assignment practices which we did not foresee when RFC= 3188 was written. I do hope that the revision will not get stuck on techni= calities or philosophical disagreements which have only minor impact on pra= ctical work.=20 >=20 > In the long term I do hope that allowing the use of r-, q- and f-componen= ts will help libraries and other URN users such as film industry to build s= marter URN resolvers. There is definitely a need for that. =20 >=20 > All the best,=20 >=20 > Juha >=20 > PS. I volunteer to produce the next version of the I-D, but should I use = the txt or XML version? And if the latter, where do I get it (last time I e= dited the txt version).=20 >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn