From nobody Tue Nov 7 09:11:52 2017 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 DD74A133090 for ; Tue, 7 Nov 2017 09:11:50 -0800 (PST) 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 8o6SAA8rGh8N for ; Tue, 7 Nov 2017 09:11:48 -0800 (PST) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 0164F133038 for ; Tue, 7 Nov 2017 09:11:48 -0800 (PST) Received: by mail-ua0-x236.google.com with SMTP id v27so9349865uav.7 for ; Tue, 07 Nov 2017 09:11:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=MGaa6YwUapypjjPLXDnKd9Pbm6pYedQMVFt7HT11mnE=; b=aLUuI6CfDl8eQ+BI34fofQw9/FelsoJrryRYR52DIbmMGb7gl0VJmGHoWKObuR+Oio lnWTWy/8t72Sq0+XYogW6TW0lm5oZiBYQ1NWDImC8m8ij6fW61BxB2LFfmyMRUrEiMUy cqggrtuFQaGK6BrUpdjs5I9C5AIXBzIwP6GdHoUiYVl8H9nZzXLDGagA7aHlQKfTSNha TLGTe7wpRLuMXZYC2p/i5TP4hhadlXVVgGpaOVcXyn9vkTum13E2tDohGw0QbqIpbQu/ YxBa6glcw9DbsDWaJmFcQwI8rUczSWdnwCx5l7mWtGORbNbuA5xKwB+b/37Edmvf7ZtU tLbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=MGaa6YwUapypjjPLXDnKd9Pbm6pYedQMVFt7HT11mnE=; b=RAjEIovD/f8fLMZTlPA8TvWMtP6EilEHZdhK8gGHyq/thWEg2Se2oM1zlm6K+mNeCF FU0LEP+55gDlptrNmFVoNSkOw/4r91n976fkpBapI14d7zNimB2qjW+cUbdRCLfV7e1P 8pa0YnQiOVHg1gWPq1TmafrXiqwBl6w709oEcYG1cvGz7RpXMOTV/U4LepE0qdu5ZES4 zclVTFcrILLm4NR3BVJe+DpKyglAuBY1LclRxNnu3fxqEdp5vw/SQvJHCMgRreVw+ibs P+Ev0bJsuPNFKyH9oW61vqZZ1LBJTzOB76bhP9GO93qgZ74HBLjhM5g7aWDJnQqPJurW v4Bw== X-Gm-Message-State: AJaThX6ws7iBsYZPtviJ+Bzw3M0E1i+gE4YYIcRN3r+lggNmEewLMdxW bapA86H9tDv21q1WCoCoZomStQOT1xYKlh8D0G9SFw== X-Google-Smtp-Source: ABhQp+SDsOVRPrx2jtMIarbS/RsLl0EF8U7G7vUH2D6N/EF0eCT1xG53SAeNUl/ntgVM4ZXFZ/wYJ9axmyXYRQuuoR8= X-Received: by 10.159.57.227 with SMTP id p35mr15597667uag.198.1510074706776; Tue, 07 Nov 2017 09:11:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.27.82 with HTTP; Tue, 7 Nov 2017 09:11:46 -0800 (PST) In-Reply-To: References: <24637769D123E644A105A0AF0E1F92EF010D31E7A1@dnbf-ex1.AD.DDB.DE> From: Kasper Nielsen Date: Tue, 7 Nov 2017 18:11:46 +0100 Message-ID: To: urn@ietf.org Content-Type: multipart/alternative; boundary="94eb2c19f2107b58b3055d67aa25" Archived-At: Subject: Re: [urn] Request for urn mrn X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 17:11:51 -0000 --94eb2c19f2107b58b3055d67aa25 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I'm a little unsure about the further registration process. Do we need to do something on our side? BR Kasper On 16 October 2017 at 16:42, Kasper Nielsen wrote: > Hi Lars, > > Thank you for your comments. My comments are inline. > > I know there are some sections that might be a bit weak. Having this kind > of meta URN namespace is a bit of an experiment for us. And we hope to > gather some valuable feedback once people start to adopt the standard. > Expecting to strengthen the specification as well as provide better > guidelines over time. > > >> Eventually I also got around to review your request. It looks almost >> ready to me, but there are two areas you might want to look into: >> >> 1) I cannot find anything on how you want to ensure that the identifiers >> (e. g. the URNs) remain unique and that they are not by accident assigne= d >> twice. In the "Assignment" section you write that "Management of >> Organization-Specific Namespace IDs should be done in accordance to t= he >> guidelines provided at http://www.mrnregistry.org." If that enough to >> ensure uniqueness of the that's fine with me but it would be helpful to >> have that explicit in the registration document. >> > I've changed the section to this: > > ++++++++++++++++++++++++ > Assignment of Organization IDs is done by filling out and sending in > the > registration template, as detailed on http://www.mrnregistry.org. IALA > will > ensure the uniqueness of Organization IDs by ensuring that an ID can > only be > assigned once. Records of all successful registrations will be > maintained in > a public version control repository as detailed on the website. > > The assignment procedures for MRN strings under a particular > Organization-specific namespace ID is the responsibility of the > maintaining > organization. The considerations provided by http://www.mrnregistry.or= g > as > well as Section 6.4.3 of the URN specification [RFC8141] must be taken > into > account when defining the actual assignment procedure. > +++++++++++++++++++++++++ > > >> 2) There is no section on lexical equivalence (e. g. how you can decide >> if two character sequences are "the same" URN). The "Syntax" section say= s: >> "The namespace, =E2=80=9Cmrn=E2=80=9D, is case-insensitive in processing= but is >> conventionally written in lower case" but that's about all. Since much o= f >> the handling is done in sub-namespaces, I understand that it can be >> difficult to give exact rules here, but I think that the registration at >> least should say that for comparison, the strings "urn" and "mrn" must b= e >> converted to lower case. If you can have such a rule for the OID, too, i= t >> would be excellent. Beyond that, I guess that it depends on the how the >> organisation identified by the OID handles its OSS. >> > > I've added the following section: > > +++++++++++++++++++++++++++ > > Rules for Lexical Equivalence: > > In addition to the URN equivalance rules defined in Section 2.1 of the > URN > specification [RFC8141]. Case normalization must be applied to both th= e > OID > and OSNID part before determining lexical equivalence. > > Rules for equality comparisons of the OSNS part must be clearly > documented > by the governing organization. > ++++++++++++++++++++++++ > > /Kasper > > > --94eb2c19f2107b58b3055d67aa25 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I'm a little unsure about the f= urther registration process. Do we need to do something on our side?
<= div>
BR
=C2=A0 Kasper

On 16 October 2017 at 16:42, Kasper= Nielsen <kasperni@gmail.com> wrote:
Hi Lars,

Thank you for yo= ur comments. My comments are inline.
<= br>
I know there are some sections that mig= ht be a bit weak. Having this kind of meta URN namespace is a bit of an exp= eriment for us. And we hope to gather some valuable feedback once people st= art to adopt the standard. Expecting to strengthen=C2=A0the specification a= s well as provide better guidelines over time.


Eventually I also got around to review your request. It looks almost= ready to me, but there are two areas you might want to look into:

1) I cannot find anything on how you want to ensure that the identifiers (e= . g. the URNs) remain unique and that they are not by accident assigned twi= ce. In the "Assignment" section you write that "Management o= f Organization-Specific Namespace IDs should be done in=C2=A0 =C2=A0 accord= ance to the guidelines provided at http://www.mrnregistry.org." I= f that enough to ensure uniqueness of the that's fine with me but it wo= uld be helpful to have that explicit in the registration document.
I've changed the section to this:

++++++++++++++++++++++++
=C2=A0 =C2=A0Assignment of = Organization IDs is done by filling out and sending in the=C2=A0
= =C2=A0 =C2=A0registration template, as detailed on http://www.mrnregistry.org. IALA will<= /div>
=C2=A0 =C2=A0ensure the uniqueness of Organization IDs by ensurin= g that an ID can only be
=C2=A0 =C2=A0assigned once. Records of a= ll successful registrations will be maintained in=C2=A0
=C2=A0 = =C2=A0a public version control repository as detailed on the website.=C2=A0=
=C2=A0 =C2=A0
=C2=A0 =C2=A0The assignment procedures f= or MRN strings under a particular=C2=A0
=C2=A0 =C2=A0Organization= -specific namespace ID is the responsibility of the maintaining=C2=A0
=
=C2=A0 =C2=A0organization. The considerations provided by http://www.mrnregistry.org= as=C2=A0
=C2=A0 =C2=A0well as Section 6.4.3 of the URN specifica= tion [RFC8141] must be taken into=C2=A0
=C2=A0 =C2=A0account when= defining the actual assignment procedure.
++++++++++++++++= +++++++++


2) There is no section on lexical equivalence (e. g. how you can decide if = two character sequences are "the same" URN). The "Syntax&quo= t; section says: "The namespace, =E2=80=9Cmrn=E2=80=9D, is case-insens= itive in processing but is=C2=A0 conventionally written in lower case"= but that's about all. Since much of the handling is done in sub-namesp= aces, I understand that it can be difficult to give exact rules here, but I= think that the registration at least should say that for comparison, the s= trings "urn" and "mrn" must be converted to lower case.= If you can have such a rule for the OID, too, it would be excellent. Beyon= d that, I guess that it depends on the how the organisation identified by t= he OID handles its OSS.

I've= added the following section:

++++++++++++++++= +++++++++++

Rules for Lexical Equivalence:

=C2=A0 =C2=A0In addition to the URN equivalance rule= s defined in Section 2.1 of the URN
=C2=A0 =C2=A0specification [R= FC8141]. Case normalization must be applied to both the OID=C2=A0
=C2=A0 =C2=A0and OSNID part before determining lexical equivalence.
<= div>
=C2=A0 =C2=A0Rules for equality comparisons of the OSNS = part must be clearly documented=C2=A0
=C2=A0 =C2=A0by the governi= ng organization.
++++++++++++++++++++++++

/Kasper
<= br>


--94eb2c19f2107b58b3055d67aa25-- From nobody Tue Nov 7 09:27:37 2017 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 40EC0133038 for ; Tue, 7 Nov 2017 09:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=fD5o5VRV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KD2e16fY 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 2pDh8YeSnuD2 for ; Tue, 7 Nov 2017 09:27:34 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C770132F2E for ; Tue, 7 Nov 2017 09:27:34 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 9C56320964; Tue, 7 Nov 2017 12:27:33 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 07 Nov 2017 12:27:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=7Uklac/nFmltQcEf6SELGj365swjogqe9Z6VNFpXL7A=; b=fD5o5VRV yPM7GHyvb3G2a+HidRQaCIKeh176ECRPyNTVYvC5ycoHF66JZM41iURKhGItjzbu MYD9i43zxLyA+OJy+TsVizHDp2rXHm3h6it4WFIxfirISphSCoPoCCqYdqf01ImV B4QweEoVCo3Ga366gyhNCPqfBGWX7jKNxFBp8UOMQIKXcBqldRAmnFioPQQsYcHu z2zym0TOxy/LJEthnuUo8ex4gfX4tD5d8dOxEl1tsp5b91XkSmh0ZYNQFiyauPPh 8bZhx7SY9HLKjpTAYd8ENiF45RrSuqJsHLyBpnui9xZ/1AzZM4oxGsosAdG3aivD eWIwOzV4K8k0Pw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=7Uklac/nFmltQcEf6SELGj365swjo gqe9Z6VNFpXL7A=; b=KD2e16fYCGTcudvfiQXoCqxVifPHEE/cYpActoL16Qx+N Va6W6dDWPcSiJHr4HSJdR/VIDEnEmH1hxg8Pkm+eHAr53zvPdkzK2it6vgofyz66 MmK7cftD2TMqN27G7bL4ueYUjlacf2sc/1uwi7iRLvAleWwCqFqGFOu8eiqGPd9F GrOoIWCmAJBdXI1h7WHYHt6cQ8DlPDub7984T6ODUQgBiZ/rN5fWtA7bgKbK/QMh QMfUjUt99+pDFTEkwAnRq5p2K/9QdK7znO0dm980RtKLbN/2OvoP19Pi5RSE6LcI Z4bwpclazC8dIhEOXKxdXQY8vEPa5qeIkI4iL6Ffg== X-ME-Sender: Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id 140EE7F96B; Tue, 7 Nov 2017 12:27:33 -0500 (EST) To: Kasper Nielsen , urn@ietf.org References: <24637769D123E644A105A0AF0E1F92EF010D31E7A1@dnbf-ex1.AD.DDB.DE> From: Peter Saint-Andre Message-ID: <208e8f14-a29a-1413-aa4f-a9b6c52dc134@stpeter.im> Date: Tue, 7 Nov 2017 10:27:30 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wOjqOGvLDeXbLtJqKQQqsKBQlq90sRgTk" Archived-At: Subject: Re: [urn] Request for urn mrn X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 17:27:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wOjqOGvLDeXbLtJqKQQqsKBQlq90sRgTk Content-Type: multipart/mixed; boundary="tClm6S8G9TdOo9bT41Krl6CKH5jWQGflo"; protected-headers="v1" From: Peter Saint-Andre To: Kasper Nielsen , urn@ietf.org Message-ID: <208e8f14-a29a-1413-aa4f-a9b6c52dc134@stpeter.im> Subject: Re: [urn] Request for urn mrn References: <24637769D123E644A105A0AF0E1F92EF010D31E7A1@dnbf-ex1.AD.DDB.DE> In-Reply-To: --tClm6S8G9TdOo9bT41Krl6CKH5jWQGflo Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/7/17 10:11 AM, Kasper Nielsen wrote: > Hi, >=20 > I'm a little unsure about the further registration process.=20 Sorry about that. We're all smoothing out wrinkles in the registration process, so thanks for your patience. > Do we need > to do something on our side? Your textual changes look good to me. I have only two small comments... > =C2=A0 =C2=A0The assignment procedures for MRN strings under a part= icular=C2=A0 > =C2=A0 =C2=A0Organization-specific namespace ID is the responsibili= ty of the That should be "are" (subject-object agreement is annoying!). > =C2=A0 =C2=A0Rules for equality comparisons of the OSNS part must b= e clearly > documented=C2=A0 > =C2=A0 =C2=A0by the governing organization. It might be slightly better to say this: Rules for equality comparisons of the OSNS part must be clearly documented by the governing organization, and be consistent with Sections 3.1 and 6.4.2 of RFC 8141. That might help guide the governing organizations with regard to any rules they might define; I am thinking especially of the following guidelines in Sections 3.1 and Section 6.4.2 respectively: Such rules MUST always have the effect of eliminating some of the false negatives obtained by the procedure above and MUST NOT result in treating two URNs as not "the same" if the procedure here says they are URN-equivalent. And: 3. Rules for determining URN-equivalence between two names in the URN namespace. Such rules ought to always have the effect of eliminating false negatives that might otherwise result from comparison. If it is appropriate and helpful, reference can be made to particular equivalence rules defined in the URI specification [RFC3986] or to Section 3 of this document. Examples of URN-equivalence rules include equivalence between uppercase and lowercase characters in the NSS, between hyphenated and non-hyphenated groupings in the name, or between single quotes and double quotes. There may also be namespace-specific special encoding considerations, especially for URNs that contain embedded forms of names from non-URN identifier systems. (Note that these are not normative statements for any kind of best practice related to handling of relationships between characters in general; such statements are limited to one particular URN namespace only.) With those minor adjustments, in my opinion your registration is ready to be completed. Peter --tClm6S8G9TdOo9bT41Krl6CKH5jWQGflo-- --wOjqOGvLDeXbLtJqKQQqsKBQlq90sRgTk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEO1gGYnPG8aeH+JR96gakkSvFrakFAloB7QMACgkQ6gakkSvF ram7cw/+PbvBsVW7qjusWzF5ZFQr1XWbt/vzovoorvehq3AH57Y60whoPaypPLMm YgD3FSAuCYjEAJHWpq/Dl4aNVSuLKmpUL/m3PehbvzBIoInGxTOuK9ZYFnZZzCZr QTSKw04lVB8YXqARM9VuVrXZ2vA3qBg36qqYFY7BH2PmFpXSD+7NbYbDXbf05E3e qyyrFVhGPNvXv9JaGbzWYwEHQqd3QSxL4nItpvKl3ksPSHpKufsPPFLwY+H3vfJV gZBdySy7XMoNh+7mrzZy5qjPeWnNKynpYNUrqCXZxY0hIELkZJktEAxoC1omEYX/ v1t+tke5oCI4xqtRbSOCefTV2EWcl4jxCWJ2wsy6v/Q3rQE6j9s6yUd9siJP42X1 1PezaqwroctpX+0r6gMSc1LR/NeezUDb9mu3UXKNsbCXj41b1eP/uZLiIbdyGhHt Vtv6cY7GJyUHzxWtVdORkUnp4vS79sSsixRfLH2Q07C04dJyWo2UbUvlvdKeWKk/ yyRvk98n+flsGYw7LZMORXKy7Fl6gX5TJ5qRHPb/aTqwvBJB8DRk+2NK+aF5cgVF 6OXjhfiAzCKFTBU3ythzjjIylu63zlVZo+9Hp8X6bCJqbNvwI0Y/ITwT8ohzlLNR un9e3wMGAfuH/iJTZ2aNnB6XT+MUvRyolroxHupUqKpk/XH/lmE= =w+n+ -----END PGP SIGNATURE----- --wOjqOGvLDeXbLtJqKQQqsKBQlq90sRgTk-- From nobody Tue Nov 7 14:22:02 2017 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 CFB091293DB for ; Tue, 7 Nov 2017 14:22:00 -0800 (PST) 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, 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 SMH1ezbbjIGW for ; Tue, 7 Nov 2017 14:21:59 -0800 (PST) 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 666B0127F0E for ; Tue, 7 Nov 2017 14:21:59 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1eCCFo-000Fwj-LJ; Tue, 07 Nov 2017 17:21:56 -0500 Date: Tue, 07 Nov 2017 17:21:49 -0500 From: John C Klensin To: Peter Saint-Andre , Kasper Nielsen cc: urn@ietf.org Message-ID: <2A14A804C2BD9E975ADAE1C8@PSB> In-Reply-To: <208e8f14-a29a-1413-aa4f-a9b6c52dc134@stpeter.im> References: <24637769D123E644A105A0AF0E1F92EF010D31E7A1@dnbf-ex1.AD.DDB.DE> <208e8f14-a29a-1413-aa4f-a9b6c52dc134@stpeter.im> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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] Request for urn mrn X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 22:22:01 -0000 Concur. john --On Tuesday, November 7, 2017 10:27 -0700 Peter Saint-Andre wrote: > On 11/7/17 10:11 AM, Kasper Nielsen wrote: >> Hi, >>=20 >> I'm a little unsure about the further registration process.=20 >=20 > Sorry about that. We're all smoothing out wrinkles in the > registration process, so thanks for your patience. >=20 >> Do we need >> to do something on our side? >=20 > Your textual changes look good to me. I have only two small > comments... >=20 >> =C2=A0 =C2=A0The assignment procedures for MRN strings = under a >> particular=C2=A0 =C2=A0 =C2=A0Organization-specific = namespace ID is >> the responsibility of the >=20 > That should be "are" (subject-object agreement is annoying!). >=20 >> =C2=A0 =C2=A0Rules for equality comparisons of the OSNS = part must >> be clearly documented=C2=A0 >> =C2=A0 =C2=A0by the governing organization. >=20 > It might be slightly better to say this: >=20 > Rules for equality comparisons of the OSNS part must be > clearly documented by the governing organization, and be > consistent with Sections 3.1 and 6.4.2 of RFC 8141. >=20 > That might help guide the governing organizations with regard > to any rules they might define; I am thinking especially of > the following guidelines in Sections 3.1 and Section 6.4.2 > respectively: >=20 > Such rules MUST always have the effect of eliminating some > of the false negatives obtained by the procedure above and > MUST NOT result in treating two URNs as not "the same" if > the procedure here says they are URN-equivalent. >=20 > And: >=20 > 3. Rules for determining URN-equivalence between two names > in the URN namespace. Such rules ought to always have > the effect of eliminating false negatives that might > otherwise result from comparison. If it is appropriate > and helpful, reference can be made to particular > equivalence rules defined in the URI specification > [RFC3986] or to Section 3 of this document. Examples of > URN-equivalence rules include equivalence between > uppercase and lowercase characters in the NSS, between > hyphenated and non-hyphenated groupings in the name, or > between single quotes and double quotes. There may > also be namespace-specific special encoding > considerations, especially for URNs that contain > embedded forms of names from non-URN identifier systems. = (Note > that these are not normative statements for any kind of > best practice related to handling of relationships > between characters in general; such statements are > limited to one particular URN namespace only.) >=20 > With those minor adjustments, in my opinion your registration > is ready to be completed. >=20 > Peter >=20 From nobody Tue Nov 7 14:51:03 2017 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 EF606129478; Tue, 7 Nov 2017 14:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=ZzgBZlXt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kSCqC3Dy 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 teGJmcdmg-Q2; Tue, 7 Nov 2017 14:51:00 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E3D412951F; Tue, 7 Nov 2017 14:51:00 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 9E9BC20D89; Tue, 7 Nov 2017 17:50:58 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 07 Nov 2017 17:50:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=ddgde1fZoZbcS4aHHjOlBDXCJmCfervIffTB2bbQvqk=; b=ZzgBZlXt ljHfd0jKDwQ+HxPofLXcUBjy4j49qtueTow3qK0GWFuxjT0H5/ALqjS+0taJbU2K ziM82co1Ng+RmqPMXT2ZdwkvVOC2+uczh7awKlJsAAdJKdZAMDxxNJl4eQtkAcjx wPzejO5LyTLMwlGUdAYRRMfe0VWxlguEEopdS0wNrXa+TGLHr0SADekzA6ZzuJQE 5E7uYeSfOdypwOADnGFxBAMEoGYOS8UuZqdZQC/2Xuma6p1vD6KHmfClf9IdjZVa mXcPEBlKEG/9QyslR+Am7+pExuKzQJhTXKnz0+wxjGVKt4EbG0P0DQ70qT14tK8y J/3U5+0JZKvUTg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=ddgde1fZoZbcS4aHHjOlBDXCJmCfe rvIffTB2bbQvqk=; b=kSCqC3DyPak3eyGg1ExLHofACyAvOgfhJOyKOdy0Hg+bx jdvU0Otj+7PrXqInRa61946nqo7l9C73Ubx6dGNP711G9vckUa0u6aT/h8Zt+PxR ptEgWTovnOdXDq9EfrF3Fglh6l+gj5HJO7UsuKqi9tGEamxc2l12qsrHYHKg4wqd j+t/p8fwX4QoVL1NWWeV/cEg4pgcG+DwrmDBH/WIJHTS2LKSbNOuUJi2duKUR7+B PQRIIzgHtemaXI2TPtzS4nJ/z9hVmvRv4+hDWUGr8dW4c3fMBD+ubzaUuutCT4aB lz4WJgtXkCcGD6URd36OsZGyoNI4yhf24wwnbAZvA== X-ME-Sender: Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id C4EE67FAC9; Tue, 7 Nov 2017 17:50:57 -0500 (EST) To: Enrico Francesconi , "Hakala, Juha E" Cc: Pierluigi Spinosa , "draft-spinosa-urn-lex.all@ietf.org" , "urn@ietf.org" , Alexey Melnikov References: <1505909590.1544977.1112321704.5FEB92F9@webmail.messagingengine.com> <59D492AC-FEC7-48D9-84B6-614BB0B0223D@ittig.cnr.it> <2AC1F018-9E90-4071-928C-2803AD1290E0@ittig.cnr.it> From: Peter Saint-Andre Message-ID: <8204cf1f-c7aa-4305-e1f0-03f6659bc4d4@stpeter.im> Date: Tue, 7 Nov 2017 15:50:56 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fxNf58kSFTFDvwB2flOpoH4ReaTKn3VXM" Archived-At: Subject: Re: [urn] Request for new URN namespace review: LEX X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 22:51:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fxNf58kSFTFDvwB2flOpoH4ReaTKn3VXM Content-Type: multipart/mixed; boundary="PsUrf0ox3N3e12KsUSOCXOf08WcJPphEn"; protected-headers="v1" From: Peter Saint-Andre To: Enrico Francesconi , "Hakala, Juha E" Cc: Pierluigi Spinosa , "draft-spinosa-urn-lex.all@ietf.org" , "urn@ietf.org" , Alexey Melnikov Message-ID: <8204cf1f-c7aa-4305-e1f0-03f6659bc4d4@stpeter.im> Subject: Re: [urn] Request for new URN namespace review: LEX References: <1505909590.1544977.1112321704.5FEB92F9@webmail.messagingengine.com> <59D492AC-FEC7-48D9-84B6-614BB0B0223D@ittig.cnr.it> <2AC1F018-9E90-4071-928C-2803AD1290E0@ittig.cnr.it> In-Reply-To: --PsUrf0ox3N3e12KsUSOCXOf08WcJPphEn Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable One comment on syntax... On 10/24/17 2:33 PM, Enrico Francesconi wrote: >> Req: As regards syntax, concerns about un-encoded use of @ to indicate= >> an expression of a work >> To Deepen: not clear the motivations >> Juha: the motivation was just to say that it is necessary to percent >> encode special characters which cannot be expressed in HTTP URIs in >> unencoded form, such as @. >=20 > For the users this problem will be transparent.=20 I think Juha's concern is that the namespace specification should define the encoding rules to ensure consistent translation between the URN form and the HTTP URI serialization described in "Attachment D". Peter --PsUrf0ox3N3e12KsUSOCXOf08WcJPphEn-- --fxNf58kSFTFDvwB2flOpoH4ReaTKn3VXM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEO1gGYnPG8aeH+JR96gakkSvFrakFAloCONAACgkQ6gakkSvF rakWNBAAhbOrNBwH53UMwi0hPG4OakgKsqTJz+jV9+imRLej35L/u7NSnSCPy1Zs 5DyqgQ6uVjMI7OspM7IK6qU7R89Zj79yiEN9eD/GyAo/b5rUk+4HL2SawN/38uvs SzFv/f+bzdwSZDaoRzAFEz1pFW23YbO4Bx1jhyso3pw9MdxBkLIAjjqUzjPf1cQW zm0nlvZH6KgpdfA0RskuUot49FXbxyUoBdTd2ekuKEvB+gN9noVLFyocHiKf3+lY SiW6PPh/qiiVYyYKArHi/KEfBEm8k0iZCfMDGENXA9cGaPE5L8j7tOjb++2KYpEg xSFacLBGms2tQQfK+CBopkgB0VvqfpVXWChO8yBZj3I6oV+t0+QuiArTNggOPpS6 ZgsAl8zLemHjIyUFKfDTHINiqBjyy+AUWzzuTaUj0J2SctZ3v4Ieb7l3xd10mEgD GWfmFzqMol2bMhFZ+CxpNcfGfs2OJhPKWbhY61CzlD+uAvc6Ckonor9wo2BuTxBM 3mTz4O3/ljh1OlK2BJ7y1rWwOeCCdbHQY3Yy7nyteime0TN/Mu4CmVSspHGRUo6z g18h4buvA8fhgiEWHfjOUXTBNv71Hs9dVvKhwPJ7PSws+SBCY5dQ+enFP9umSQE7 TZz5peDu2WOtel/Kas51G+/RSx3IYY+MVYA2TrDt33x7Ni1tdaA= =2how -----END PGP SIGNATURE----- --fxNf58kSFTFDvwB2flOpoH4ReaTKn3VXM-- From nobody Fri Nov 10 00:52:12 2017 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 58F4312EC0C for ; Fri, 10 Nov 2017 00:52:11 -0800 (PST) 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 zT8RSMnhTmf9 for ; Fri, 10 Nov 2017 00:52:08 -0800 (PST) Received: from mail.dnb.de (prodfix-out0.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 7EC7E12EC08 for ; Fri, 10 Nov 2017 00:52:08 -0800 (PST) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by mail.dnb.de (Postfix) with ESMTP id B3339438A117; Fri, 10 Nov 2017 09:52:05 +0100 (CET) X-AuditID: 0a453fe7-f9bff70000000eab-83-5a0568b52f4a 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 10.9D.03755.5B8650A5; Fri, 10 Nov 2017 09:52:05 +0100 (CET) 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; Fri, 10 Nov 2017 09:52:04 +0100 Received: from dnbf-ex.AD.DDB.DE ([fe80::3576:7565:4f15:49c7]) by dnbf-ex.AD.DDB.DE ([fe80::3576:7565:4f15:49c7%13]) with mapi id 15.01.0669.032; Fri, 10 Nov 2017 09:52:04 +0100 From: "Svensson, Lars" To: Kasper Nielsen CC: "urn@ietf.org" , John C Klensin , "Peter Saint-Andre" Thread-Topic: [Marketing Mail] Re: [urn] Request for urn mrn Thread-Index: AQHTV+uGRlFpGEp5P0uF/JjDL1clPKMJGsUAgABSPICAA+SdIA== Date: Fri, 10 Nov 2017 08:52:04 +0000 Message-ID: References: <24637769D123E644A105A0AF0E1F92EF010D31E7A1@dnbf-ex1.AD.DDB.DE> <208e8f14-a29a-1413-aa4f-a9b6c52dc134@stpeter.im> <2A14A804C2BD9E975ADAE1C8@PSB> In-Reply-To: <2A14A804C2BD9E975ADAE1C8@PSB> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.65] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA11Ta0wTWRT2zkzppfbiMLyuRVwZF40aYTVqatDV+NhgQsL6Q5d0NwsDM7bV 0paZloAmBpbgoyRifPywoqIh8RE21CZmlRBWmyyJYuILJUbFGBGsRNz4BIOPuZ0Wi//OfOd8 j3tOBtJcEzRBu9MjyU7BwScYGMP6VW8XXrDpLD9dHzWZG26PJ5g7x88mmLs7m2jz4fr/qdVM wSX/I31Ba+sYVXDn7DBdcKzzOf0rYzGsECWHvUqS834uNdj6/37NuNtyqm+dNNaCwI8+kAgx uwQP9nYwpObYKwDvbnL6gEGtnwLcHPRT2scFgB/UnQY+oIcJ7Hz8ykbmU9m5eOhuV4RLs5W4 te2xntQpbD4O7nlB+wBUZ1ZgXz/Uxtfgsb4WitQMm4NP9I3qSI3YpbjhWQ+jObVTuP7LGEW4 iewC/M+dtWQGsFk4ELhBa1YZODj4QafFZ3Frp4ZjNg2Hn36O4rPw/o+9DJGh2Xm4vSNPo2bj Q41P9JptMr56ZIDZD9L9car+bwx/HMMfx2gBzDmQpFRYF+UKYq4oluWKUhBodxq6CPbdXhcC LAS8EXmeMBZOJ1QpNRUhUAQpPg2ZlqtQUplLrLEJiq1E9jokhU9F3YLOwqEJuMzr2MbPRDdf 0xYuYwJVvIrbXm53eZUSr+wIAQxplZr3A6GKQs12SXZpgiGQCRk+A4W7phRzrFXwSNskyS3J sW4xhDxGLVaVmCxLVql6i93hibVVnpF02PhOJFA2On+KsnCm+Mb3mSiYGAKF0KgGGyUqSHEL FYrdGtVOQUPkpcYYGtHNQsveqA9Nj4GTNa8BCQ7cO/6JgoNHhmtpjnG6nJIpA22OhCQcm9c5 kd6Uju71qSGnxTWIiWkW6i9UTabH4ZN9XoAN6tFSkEx0jer/9y01hwJbVHBqFIyEnoFEEjot in2vVaheOxX9rmfICjyCJ34FfxCiMYZGV/CntoIoOFnOVAvqDoy/7Qi+m374StWmXVWZdSOO xhKx4XK5c2/+QXdRebVN+K3et7IZ79y498HAktV1v/w15wzzMDxjx/D95F2PXuX92zF3Y++h nJG05V01s4vbKr0rF5b2jOh33szMmv2en7pn63/ocvjozDly0v3m3ZX5i11YvzWx2BxubO8+ vvll4CHPKDZh0XxaVoSvMFqKtaIEAAA= Archived-At: Subject: Re: [urn] [Marketing Mail] Re: Request for urn mrn X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 08:52:11 -0000 SCBLYXNwZXIsDQoNClNvcnJ5IGZvciBub3QgY29taW5nIGJhY2sgdG8geW91ciByZXBseSByZSBt eSBjb21tZW50cyBzb29uZXIuLi4gVGhhbmtzIGZvciB0YWtpbmcgbXkgc3VnZ2VzdGlvbnMgaW50 byBhY2NvdW50LiBJIGFncmVlIHdpdGggUGV0ZXIgYW5kIEpvaG4gdGhhdCB5b3VyIHJlZ2lzdHJh dGlvbiBpcyByZWFkeSB0byBiZSBjb21wbGV0ZWQgaWYgeW91IGFkZCBQZXRlcidzIHN1Z2dlc3Rl ZCByZWZlcmVuY2VzIHRvIMKnwqcgMy4xIGFuZCA2LjQuMiBvZiBSRkMgODE0MS4NCg0KVGhhbmtz LA0KDQpMYXJzDQoNCk9uIFR1ZXNkYXksIE5vdmVtYmVyIDA3LCAyMDE3IDExOjIyIFBNLCB1cm4g W21haWx0bzp1cm4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvaG4gQyBLbGVuc2lu IHdyb3RlOg0KDQo+IENvbmN1ci4NCj4gICAgam9obg0KPiANCj4gDQo+IC0tT24gVHVlc2RheSwg Tm92ZW1iZXIgNywgMjAxNyAxMDoyNyAtMDcwMCBQZXRlciBTYWludC1BbmRyZQ0KPiA8c3RwZXRl ckBzdHBldGVyLmltPiB3cm90ZToNCj4gDQo+ID4gT24gMTEvNy8xNyAxMDoxMSBBTSwgS2FzcGVy IE5pZWxzZW4gd3JvdGU6DQo+ID4+IEhpLA0KPiA+Pg0KPiA+PiBJJ20gYSBsaXR0bGUgdW5zdXJl IGFib3V0IHRoZSBmdXJ0aGVyIHJlZ2lzdHJhdGlvbiBwcm9jZXNzLg0KPiA+DQo+ID4gU29ycnkg YWJvdXQgdGhhdC4gV2UncmUgYWxsIHNtb290aGluZyBvdXQgd3JpbmtsZXMgaW4gdGhlDQo+ID4g cmVnaXN0cmF0aW9uIHByb2Nlc3MsIHNvIHRoYW5rcyBmb3IgeW91ciBwYXRpZW5jZS4NCj4gPg0K PiA+PiBEbyB3ZSBuZWVkDQo+ID4+IHRvIGRvIHNvbWV0aGluZyBvbiBvdXIgc2lkZT8NCj4gPg0K PiA+IFlvdXIgdGV4dHVhbCBjaGFuZ2VzIGxvb2sgZ29vZCB0byBtZS4gSSBoYXZlIG9ubHkgdHdv IHNtYWxsDQo+ID4gY29tbWVudHMuLi4NCj4gPg0KPiA+PiAgICAgwqAgwqBUaGUgYXNzaWdubWVu dCBwcm9jZWR1cmVzIGZvciBNUk4gc3RyaW5ncyB1bmRlciBhDQo+ID4+ICAgICBwYXJ0aWN1bGFy wqAgwqAgwqBPcmdhbml6YXRpb24tc3BlY2lmaWMgbmFtZXNwYWNlIElEIGlzDQo+ID4+ICAgICB0 aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhlDQo+ID4NCj4gPiBUaGF0IHNob3VsZCBiZSAiYXJlIiAo c3ViamVjdC1vYmplY3QgYWdyZWVtZW50IGlzIGFubm95aW5nISkuDQo+ID4NCj4gPj4gICAgIMKg IMKgUnVsZXMgZm9yIGVxdWFsaXR5IGNvbXBhcmlzb25zIG9mIHRoZSBPU05TIHBhcnQgbXVzdA0K PiA+PiAgICAgYmUgY2xlYXJseSBkb2N1bWVudGVkDQo+ID4+ICAgICDCoCDCoGJ5IHRoZSBnb3Zl cm5pbmcgb3JnYW5pemF0aW9uLg0KPiA+DQo+ID4gSXQgbWlnaHQgYmUgc2xpZ2h0bHkgYmV0dGVy IHRvIHNheSB0aGlzOg0KPiA+DQo+ID4gICAgUnVsZXMgZm9yIGVxdWFsaXR5IGNvbXBhcmlzb25z IG9mIHRoZSBPU05TIHBhcnQgbXVzdCBiZQ0KPiA+IGNsZWFybHkgICAgZG9jdW1lbnRlZCBieSB0 aGUgZ292ZXJuaW5nIG9yZ2FuaXphdGlvbiwgYW5kIGJlDQo+ID4gY29uc2lzdGVudCB3aXRoICAg IFNlY3Rpb25zIDMuMSBhbmQgNi40LjIgb2YgUkZDIDgxNDEuDQo+ID4NCj4gPiBUaGF0IG1pZ2h0 IGhlbHAgZ3VpZGUgdGhlIGdvdmVybmluZyBvcmdhbml6YXRpb25zIHdpdGggcmVnYXJkDQo+ID4g dG8gYW55IHJ1bGVzIHRoZXkgbWlnaHQgZGVmaW5lOyBJIGFtIHRoaW5raW5nIGVzcGVjaWFsbHkg b2YNCj4gPiB0aGUgZm9sbG93aW5nIGd1aWRlbGluZXMgaW4gU2VjdGlvbnMgMy4xIGFuZCBTZWN0 aW9uIDYuNC4yDQo+ID4gcmVzcGVjdGl2ZWx5Og0KPiA+DQo+ID4gICAgU3VjaCBydWxlcyBNVVNU IGFsd2F5cyBoYXZlIHRoZSBlZmZlY3Qgb2YgZWxpbWluYXRpbmcgc29tZQ0KPiA+ICAgIG9mIHRo ZSBmYWxzZSBuZWdhdGl2ZXMgb2J0YWluZWQgYnkgdGhlIHByb2NlZHVyZSBhYm92ZSBhbmQNCj4g PiBNVVNUIE5PVCAgICByZXN1bHQgaW4gdHJlYXRpbmcgdHdvIFVSTnMgYXMgbm90ICJ0aGUgc2Ft ZSIgaWYNCj4gPiB0aGUgcHJvY2VkdXJlIGhlcmUgICAgc2F5cyB0aGV5IGFyZSBVUk4tZXF1aXZh bGVudC4NCj4gPg0KPiA+IEFuZDoNCj4gPg0KPiA+ICAgIDMuICBSdWxlcyBmb3IgZGV0ZXJtaW5p bmcgVVJOLWVxdWl2YWxlbmNlIGJldHdlZW4gdHdvIG5hbWVzDQo+ID4gaW4gdGhlICAgICAgICBV Uk4gbmFtZXNwYWNlLiAgU3VjaCBydWxlcyBvdWdodCB0byBhbHdheXMgaGF2ZQ0KPiA+IHRoZSBl ZmZlY3Qgb2YgICAgICAgIGVsaW1pbmF0aW5nIGZhbHNlIG5lZ2F0aXZlcyB0aGF0IG1pZ2h0DQo+ ID4gb3RoZXJ3aXNlIHJlc3VsdCBmcm9tICAgICAgICBjb21wYXJpc29uLiAgSWYgaXQgaXMgYXBw cm9wcmlhdGUNCj4gPiBhbmQgaGVscGZ1bCwgcmVmZXJlbmNlIGNhbiBiZSAgICAgICAgbWFkZSB0 byBwYXJ0aWN1bGFyDQo+ID4gZXF1aXZhbGVuY2UgcnVsZXMgZGVmaW5lZCBpbiB0aGUgVVJJICAg ICAgICBzcGVjaWZpY2F0aW9uDQo+ID4gW1JGQzM5ODZdIG9yIHRvIFNlY3Rpb24gMyBvZiB0aGlz IGRvY3VtZW50LiAgICAgICAgRXhhbXBsZXMgb2YNCj4gPiBVUk4tZXF1aXZhbGVuY2UgcnVsZXMg aW5jbHVkZSBlcXVpdmFsZW5jZSBiZXR3ZWVuDQo+ID4gdXBwZXJjYXNlIGFuZCBsb3dlcmNhc2Ug Y2hhcmFjdGVycyBpbiB0aGUgTlNTLCBiZXR3ZWVuDQo+ID4gaHlwaGVuYXRlZCAgICAgICAgYW5k IG5vbi1oeXBoZW5hdGVkIGdyb3VwaW5ncyBpbiB0aGUgbmFtZSwgb3INCj4gPiBiZXR3ZWVuIHNp bmdsZSAgICAgICAgcXVvdGVzIGFuZCBkb3VibGUgcXVvdGVzLiAgVGhlcmUgbWF5DQo+ID4gYWxz byBiZSBuYW1lc3BhY2Utc3BlY2lmaWMgICAgICAgIHNwZWNpYWwgZW5jb2RpbmcNCj4gPiBjb25z aWRlcmF0aW9ucywgZXNwZWNpYWxseSBmb3IgVVJOcyB0aGF0IGNvbnRhaW4NCj4gPiBlbWJlZGRl ZCBmb3JtcyBvZiBuYW1lcyBmcm9tIG5vbi1VUk4gaWRlbnRpZmllciBzeXN0ZW1zLiAgKE5vdGUN Cj4gPiAgICAgICAgdGhhdCB0aGVzZSBhcmUgbm90IG5vcm1hdGl2ZSBzdGF0ZW1lbnRzIGZvciBh bnkga2luZCBvZg0KPiA+IGJlc3QgICAgICAgIHByYWN0aWNlIHJlbGF0ZWQgdG8gaGFuZGxpbmcg b2YgcmVsYXRpb25zaGlwcw0KPiA+IGJldHdlZW4gY2hhcmFjdGVycyAgICAgICAgaW4gZ2VuZXJh bDsgc3VjaCBzdGF0ZW1lbnRzIGFyZQ0KPiA+IGxpbWl0ZWQgdG8gb25lIHBhcnRpY3VsYXIgVVJO ICAgICAgICBuYW1lc3BhY2Ugb25seS4pDQo+ID4NCj4gPiBXaXRoIHRob3NlIG1pbm9yIGFkanVz dG1lbnRzLCBpbiBteSBvcGluaW9uIHlvdXIgcmVnaXN0cmF0aW9uDQo+ID4gaXMgcmVhZHkgdG8g YmUgY29tcGxldGVkLg0KPiA+DQo+ID4gUGV0ZXINCj4gPg0KPiANCj4gDQo+IA0KPiANCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdXJuIG1haWxp bmcgbGlzdA0KPiB1cm5AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby91cm4NCg== From nobody Mon Nov 13 01:40:21 2017 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 068C7128BB6 for ; Mon, 13 Nov 2017 01:40:21 -0800 (PST) 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 Pll0p11LMwbM for ; Mon, 13 Nov 2017 01:40:19 -0800 (PST) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::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 F2BFA126CC4 for ; Mon, 13 Nov 2017 01:40:18 -0800 (PST) Received: by mail-ua0-x234.google.com with SMTP id l25so2697510uag.8 for ; Mon, 13 Nov 2017 01:40:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hzLX8jCpab41m7gvkMKZ5KEdI8yYjRJLG0lynpXNc5Y=; b=plgBrnVzVaK89GCWwM17+RIc+CZwp8PyZ/4z1pDgIPVpIbpt5nQ3bG+idQL0hO7jX+ wGfJbva8y4QsYPvl8HsQon7vhOYsNMB95l3bTzc8qIvHv80/GlcLlP6YrEAgcHIcjoqW +WDHoHUlxEJdCoQw9rPmcQkOSXGzx/UIScsZykSqdLdhpOsFfA7ynMAGTkdIB4hkz7aW mzLHE0QdNgCmOZMR0RsvYixJWyBXoXDCp9QPQK0irpLId+M5R9XGeJd1AZNHSsDy1kQv 0LhFPjhZMMMiop1yKbO4/6SKp3R09NwrCvB4NOhPkVphp4zRnKbEeXYdn+Pp/FXlw00e OaGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hzLX8jCpab41m7gvkMKZ5KEdI8yYjRJLG0lynpXNc5Y=; b=HhUQP2S8wYm2GyL8ijKPBVtf7G8QitkOykGOciPN48zzxIeB2BtrzjRWdy7qlUfGN4 ZMd73EZxDVLhi0EYMr6OZ0rJW+je2kBASkmK1PE6iG7GSANvh/0+80uNwTeUMqmqIohM 3kSYCI0LIBrx6Oi34VT0U9hBxdeHl+9BKXA9z5alqLB4rjeDLoUscdIKHMcQWnVBYljg RDUXvC5eaZPBfp1NSzD9wN+dwmmvCV4MXuBfToR6hDP1VQB8rgoXJLnq2bRiMPrJdnoY gx5TmCubeW9h7YZHdARWoJXKz7FAChQdEZR9g6+5AZbMsfFM3lJPAZ4XyAyBcAxNsbvw /kow== X-Gm-Message-State: AJaThX5+p0e3hGAvFNjoZSFUSXPgm9ia1YngHLo9Y//+9mW6WNSRmFpI W58ehKLq4zZi6rE157zKX9kXZW8g79l1ndxhILjom8E1 X-Google-Smtp-Source: AGs4zMaPwoHfrRqqgu119JJFUwCsvjb7N7WTobBVlEsBP6+ghICHxPNU3JBVVMM7XX+pd487RW8YNBPElLSHWIG7hrE= X-Received: by 10.176.74.196 with SMTP id t4mr3102345uae.83.1510566017954; Mon, 13 Nov 2017 01:40:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.55.19 with HTTP; Mon, 13 Nov 2017 01:40:17 -0800 (PST) In-Reply-To: <208e8f14-a29a-1413-aa4f-a9b6c52dc134@stpeter.im> References: <24637769D123E644A105A0AF0E1F92EF010D31E7A1@dnbf-ex1.AD.DDB.DE> <208e8f14-a29a-1413-aa4f-a9b6c52dc134@stpeter.im> From: Kasper Nielsen Date: Mon, 13 Nov 2017 10:40:17 +0100 Message-ID: To: Peter Saint-Andre Cc: urn@ietf.org Content-Type: multipart/alternative; boundary="f403045f8f78e8f838055dda0e30" Archived-At: Subject: Re: [urn] Request for urn mrn X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 09:40:21 -0000 --f403045f8f78e8f838055dda0e30 Content-Type: text/plain; charset="UTF-8" On 7 November 2017 at 18:27, Peter Saint-Andre wrote: > On 11/7/17 10:11 AM, Kasper Nielsen wrote: > > Hi, > > > > I'm a little unsure about the further registration process. > > Sorry about that. We're all smoothing out wrinkles in the registration > process, so thanks for your patience. > No worries, just appreciated all the hard work done by you guys. > > The assignment procedures for MRN strings under a particular > > Organization-specific namespace ID is the responsibility of the > > That should be "are" (subject-object agreement is annoying!). > > > Rules for equality comparisons of the OSNS part must be clearly > > documented > > by the governing organization. > > It might be slightly better to say this: > > Rules for equality comparisons of the OSNS part must be clearly > documented by the governing organization, and be consistent with > Sections 3.1 and 6.4.2 of RFC 8141. > > That might help guide the governing organizations with regard to any > rules they might define; I am thinking especially of the following > guidelines in Sections 3.1 and Section 6.4.2 respectively: > > Both of them added, thanks. The updated document is here https://raw.githubusercontent.com/dma-dk/www.mrnregistry.org/gh-pages/iana-registration BR Kasper --f403045f8f78e8f838055dda0e30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On 7 November 2017 at 18:27, Peter Saint-Andre <stp= eter@stpeter.im> wrote:
<= div class=3D"gmail_quote">
On 11/7/17 10:11 AM, Kasper Nielsen wrote:
> Hi,
>
> I'm a little unsure about the further registration process.

Sorry about that. We're all smoothing out wrinkles in the regist= ration
process, so thanks for your patience.
=C2=A0
No worries, just appreciated all the hard work done by you guys.=C2=A0
=C2=A0
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0The assignment pr= ocedures for MRN strings under a particular=C2=A0
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Organization-specific namespace ID is = the responsibility of the

That should be "are" (subject-object agreement is annoying= !).

>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Rules for equality comparisons of the = OSNS part must be clearly
>=C2=A0 =C2=A0 =C2=A0documented=C2=A0
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0by the governing organization.

It might be slightly better to say this:

=C2=A0 =C2=A0Rules for equality comparisons of the OSNS part must be clearl= y
=C2=A0 =C2=A0documented by the governing organization, and be consis= tent with
=C2=A0 =C2=A0Sections 3.1 and 6.4.2 of RFC 8141.

That might help guide the governing organizations with regard to any
rules they might define; I am thinking especially of the following
guidelines in Sections 3.1 and Section 6.4.2 respectively:

=C2=A0
Both of them added, thanks.
The updated docum= ent is here=C2=A0

--f403045f8f78e8f838055dda0e30-- From nobody Mon Nov 13 07:16:43 2017 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 77610129ADD for ; Mon, 13 Nov 2017 07:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=stpeter.im header.b=oC6nuJIn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EkmIIkn6 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 o1Lw_0uv0445 for ; Mon, 13 Nov 2017 07:16:37 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8443412944A for ; Mon, 13 Nov 2017 07:16:21 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 9DD3920F29; Mon, 13 Nov 2017 10:16:20 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 13 Nov 2017 10:16:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=+1P6qXWGaL1Ml24yZFXE6QJE2o0IqIywyN9mU49jy5A=; b=oC6nuJIn XH7VJ0PSjKmyr5+w5y2rb17qMtB2H9CaGi3Hi+V8rJRzsoO20so6oKho9o4TUeeU 79gTEQLd3iHiMql8YRt4pQr2WbGtWbX/J8JBmogK2qiXVUj4qdLyyPqlw/Ilcmi2 A+ML9S/Uv8/SxsNMTpaB7+pwWdaaJHGWMKHxcK9OZkhb7MY7S9XUsp7t8hCEEXYN 6/HHcWiz/ArSub/YJkFEFT/OfYwHUkuXKP8v2VQxyXHRpFgAxCvLk8zmZ/+5GF8P d1HHwq74M+tshbJ3ix8tH887Jgf2BqzcSUCPTgp8wKi2KRvM0Y/kOj56XEfija9v ZR6VfTG62iLxSw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=+1P6qXWGaL1Ml24yZFXE6QJE2o0Iq IywyN9mU49jy5A=; b=EkmIIkn6JVbWwuK2IzLfngumaQq/TWuv5QJ45EQiVHB4e fBAnz3A5RRcAcsa2z1ekI7Se1mUv/xKaAZOaXI4joUh+ZzqfnDUOHaXgdzFHc2fA FRvRBDOKUavOV7VY9y5N1AAgGx2mHbWKtpXWSHNv9f+n0km8p6/NwuPjIDF0YVfd f9pTMlxmLATqMxNbxXFyqnK4WTnhiF/72t5SfN02GOktdJOo7/W2aBTWtp/dWgvu aJZ/EFHCOI2qTgg7ahpFEIjS3fa8oK4moq/zy1iKqanFHfxFNQkz9a2ShdY3d5zH TgjkXQgDZLcviQBdPCYbdG5Hh9yR4bvDT8aK+W8CQ== X-ME-Sender: Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id 305377FAC8; Mon, 13 Nov 2017 10:16:20 -0500 (EST) To: Kasper Nielsen Cc: urn@ietf.org References: <24637769D123E644A105A0AF0E1F92EF010D31E7A1@dnbf-ex1.AD.DDB.DE> <208e8f14-a29a-1413-aa4f-a9b6c52dc134@stpeter.im> From: Peter Saint-Andre Message-ID: <2ccce200-1956-3ae9-ff2b-f0b595a90673@stpeter.im> Date: Mon, 13 Nov 2017 08:16:17 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vxhWMlIwItQjVj5wMNleC4voWWInCDspp" Archived-At: Subject: Re: [urn] Request for urn mrn X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 15:16:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vxhWMlIwItQjVj5wMNleC4voWWInCDspp Content-Type: multipart/mixed; boundary="8bF4HBCapv8WR3WrWim8iAJNPQ38IF4s4"; protected-headers="v1" From: Peter Saint-Andre To: Kasper Nielsen Cc: urn@ietf.org Message-ID: <2ccce200-1956-3ae9-ff2b-f0b595a90673@stpeter.im> Subject: Re: [urn] Request for urn mrn References: <24637769D123E644A105A0AF0E1F92EF010D31E7A1@dnbf-ex1.AD.DDB.DE> <208e8f14-a29a-1413-aa4f-a9b6c52dc134@stpeter.im> In-Reply-To: --8bF4HBCapv8WR3WrWim8iAJNPQ38IF4s4 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/13/17 2:40 AM, Kasper Nielsen wrote: > On 7 November 2017 at 18:27, Peter Saint-Andre > wrote: >=20 > On 11/7/17 10:11 AM, Kasper Nielsen wrote: > > Hi, > > > > I'm a little unsure about the further registration process. >=20 > Sorry about that. We're all smoothing out wrinkles in the registrat= ion > process, so thanks for your patience. >=20 > =C2=A0 > No worries, just appreciated all the hard work done by you guys.=C2=A0 > =C2=A0 >=20 > >=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0The assignment procedures for MRN= strings under a particular=C2=A0 > >=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Organization-specific namespace I= D is the responsibility of the >=20 > That should be "are" (subject-object agreement is annoying!). >=20 > >=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Rules for equality comparisons of= the OSNS part must be clearly > >=C2=A0 =C2=A0 =C2=A0documented=C2=A0 > >=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0by the governing organization. >=20 > It might be slightly better to say this: >=20 > =C2=A0 =C2=A0Rules for equality comparisons of the OSNS part must b= e clearly > =C2=A0 =C2=A0documented by the governing organization, and be consi= stent with > =C2=A0 =C2=A0Sections 3.1 and 6.4.2 of RFC 8141. >=20 > That might help guide the governing organizations with regard to an= y > rules they might define; I am thinking especially of the following > guidelines in Sections 3.1 and Section 6.4.2 respectively: >=20 > =C2=A0 > Both of them added, thanks. > The updated document is here=C2=A0 > https://raw.githubusercontent.com/dma-dk/www.mrnregistry.org/gh-pages/i= ana-registration Thanks, Kasper. I think it is ready to submit to IANA! Peter --8bF4HBCapv8WR3WrWim8iAJNPQ38IF4s4-- --vxhWMlIwItQjVj5wMNleC4voWWInCDspp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEO1gGYnPG8aeH+JR96gakkSvFrakFAloJt0EACgkQ6gakkSvF ram0KQ//dcUw3uYctsbqjjE3EoK6vSvo4De8sJxnqpbrh6rE1L6s08a4ljG0j7y3 zs/YhLIpcHy5pC0acsqd6e8ur22NqZm0r+mIRp38zAF3vNkrY0AnpvdgKO/AV2T9 AH/LQBKQ3wmONutE2r3Ioor7uGRjb9qUkXAy7HjR5M0Wc9y2jF6k/6b4uCU8gJwT npVkKZq08SGD5KTCtq4ZiR8mOy1tPPCWra7D+lAfzeu0qM7kEcqzLo3tNWEN2M0f kFdWD2DziNHMJXCVhapBgk+k2WFVzN5vl58sFi/RDAxdS5Hf+6Sk7vp0rCP5Jyia wO/dn9f6suW4ujGU65dwYiSCEg5nJZdvyhgxRIwvQo02GtZkMHViqVnh+uZAYiBt RdEAUf9vUshGXaVkm+8CU15V4DD3Tx+Drxoh5NxWX8Yxfha8jsVNXEXNtY793cGe L9bcGT/ePWwpINCbFQ1/SO3xX5E0FQ/w2/8cXL0COUQxW8gmL8ExdyrahZ0FdqGe UrVfuUjbxA6CNKQIPKIdBeDr5fB9R/gbQhM5nNqSfR8ryd1h0xfsvGAClITNt9ke HV2lEUZ5XIc272zedcLvCT3sqBiG4OKY9MONpml2aQlh4WtRL0T28f0Y6KwAaDUV E6Gdu7onvAgNqb3ePEi4wyGEFL5lig6gPL1iafRxyAW/CzoAvTk= =jEGX -----END PGP SIGNATURE----- --vxhWMlIwItQjVj5wMNleC4voWWInCDspp-- From nobody Thu Nov 16 13:04:08 2017 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 82082129483; Thu, 16 Nov 2017 13:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 wdkuFpn1A_jw; Thu, 16 Nov 2017 13:04:02 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 5C31412957B; Thu, 16 Nov 2017 13:04:02 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id r68so2782697wmr.1; Thu, 16 Nov 2017 13:04:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:references:cc:to; bh=6sGpXPwvUuFRNq3mqIWOsgNPYnWK5HuLZvUXx/R5QCI=; b=gQn8IIxijTSX4ZvE8OafYEg7J6KVTMylF1MXNRosESB/DZ0wk6ddacPKkTb3uySKXs WVU3ZJP23n8MzmUzi8/TjWoAlEGJ3PrwsXoMVuENvmiovJ1X+aHzhoulNHSDGlgQ3VI2 pCGAahf2cukQE3HUoNYJAA9MEgrAq5khfrA0592p6/AiicLEPL51ZPaiA6ZuSn11aSXI 99DfhPPsS6pzIb1+d1f7g3h01SoVCG2xoIDOnG0HU1liTPBuMyWUstzWJAtT+inrQrfy yBHGmS5xG0Y2dixLyLrWJm2KLXOcNRUlD7Imb3qxcvh3NWh45Z1Pf21GOPxOd3Gq/Jef 9hHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :references:cc:to; bh=6sGpXPwvUuFRNq3mqIWOsgNPYnWK5HuLZvUXx/R5QCI=; b=FTbsbf+4+GXXOwwGwutbSVTXi3VJicrLaZRtQlQkmJCho3XN2mV1xVW7d972bjyEO/ UlJ5+qezx9rapY4v+YV1odztb7lEGhdU22PVZEdFA6yg8bcfjIfHH/nhEdaN0CMYaBWu m4tX7H5cRxVSlap0Q+fjOkhGY/UjzOvPCoiz1tYPBi6ASmjJm8dC9qEcwfvk619l1LeB xgrbc2+dWHhm+5kNKYv/dr1gTdhgdGj0/3mmxAEV6nMTBvA+Z84EAyW5Fl93mm1o6+64 X1jSW1PZaIJ+Ic6BE0cmmBxrPTC0z1xO7IOpvtL8lIMY7HON8eCNVUxZlvhzy6Bn7lb7 3juQ== X-Gm-Message-State: AJaThX7DozOhK41wMOvHFKtZaBPliUE+iEveO74HDkj6RCs8FUZEsfbd sU8R1zpQF9HRjpz//vfT/AuLJkOU X-Google-Smtp-Source: AGs4zMZSLMWEx+Gw5IxNWbWrjbXNtYMEu8TnbGBJsDyRy6ABENW+88xxaLVKw9hgCVwKApmOdGyamg== X-Received: by 10.80.230.1 with SMTP id y1mr4469185edm.211.1510866239977; Thu, 16 Nov 2017 13:03:59 -0800 (PST) Received: from [192.168.0.3] ([94.103.212.185]) by smtp.gmail.com with ESMTPSA id m31sm1595460ede.27.2017.11.16.13.03.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 16 Nov 2017 13:03:58 -0800 (PST) Sender: Enrico Francesconi From: Enrico Francesconi Content-Type: multipart/alternative; boundary="Apple-Mail=_CE8D30C9-5C9F-45FC-B06E-B9929A89B135" Message-Id: <67234FFE-32AA-4CEB-8B9A-DF201D4DB8D2@ittig.cnr.it> Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) Date: Thu, 16 Nov 2017 22:03:57 +0100 References: Cc: Alexey Melnikov , Pierluigi Spinosa To: draft-spinosa-urn-lex.all@ietf.org, urn@ietf.org X-Mailer: Apple Mail (2.3094) Archived-At: Subject: [urn] urn:lex draft v. 12 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 21:04:08 -0000 --Apple-Mail=_CE8D30C9-5C9F-45FC-B06E-B9929A89B135 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear All, we have just finalized and uploaded in the IETF website a new version = (v.12) of the urn-lex draft. This new version follows your remarks and = our change proposals https://datatracker.ietf.org/doc/draft-spinosa-urn-lex/ = In particular we have organized your remarks in three groups according = how they have been addressed:=20 a) fixed according to the proposed solution b) fixed in a way similar to the proposed solution (details in the the = draft) c) not yet fixed, waiting for agreement on a solution Here below are the details of your remarks (as listed in our previous = emails) including our proposals and classified in one of the 3 groups. Waiting for your feedback Best regards Pierluigi and Enrico 1. Annex A: Use of alfanum, etc. Req: Simplifying syntax with non-terminal elements a) Ans: We will simplify the syntax in the direction required 2. Sez. 4.4: How are non-ASCII characters to be handled? Req: Different management of non-ASCII characters in different sections. = UTF-8% encoded or puny code incompatible a) Ans: strongly recommend the use of ASCII base. In this case we can = use a straightforward DNS query for routing. In case this solution is = unacceptable for a jurisdiction: use UTF-8% encoded in URNs and use = punycode conversion in DNS. In this case, the jurisdiction has to = implement a software conversion as an interface for DDDS 3. Sez. 3.2: Compatibility with RFC 2141 and use of "~" Req: character "~" not allowed in RFC 2141 a) Ans: declare that the syntax conforms to RFC 8141 b) To Deepen: For backward compatibility, the "/", previously prohibited = in URNs, is reserved for future use, then we can remove the "/" from = prohibited characters and include it in "future expansions" b) Ans: To keep backward compatibility with existing applications in = some jurisdictions, the "lex" NID syntax does not include the use of the=20= character "/" in this version. 4. Sez. 11.2: The pseudo-TLD ".lex" Req: it no longer works if .lex is assigned a) Ans: use pseudo-domain "lex.arpa" 5. Sez. 6.7: Dealing with publishers Req: Possible issues if an event is assigned by an editor independently a) Ans: By joining the federated system, a publisher accepts the urn-lex = rules. The Jurisdictional Registrar (Section 7.2) provides guidelines = and monitors their application Req: Domain Name Editor: persistence of the manifestation depends on the = publisher b) To Deepen: Common problem with all components where a domain name is = indicated. Think of a solution through aliases =20 b) Ans: Since publishers' domain names may vary over time, = manifestations already assigned by a publisher remain=20 unchanged even if the identified object is no longer accessible. In = this case, in order to make its materials accessible, the publisher=20 will have to create for each of them a new manifestation with the = new domain name; 6. Abstract Req: World Wide Web Consortium reference for resource identification a) Ans: Replace W3C with IETF 7. Sez. 1.1: The Purpose of Namespace "lex" Req: Useful when mapped on HTTP URLs and not URIs b) To Deepen: we often talk about http uri. Maybe we can emphasize its = function as identifier rather than as locator. The identifier is often = not an absolute URL a) changed URIs with URLs. We have retained the URI indication when it = comes to identifier and not locator 8. Sez. 1.4: General Characteristics of the System Req: SHOULD seems more appropriate than MUST a) Ans: replace "must" with "should" 9. Sez. 2: Syntax label Req: The syntax and semantics of components r- and q- are not defined in = the document a) Ans: after: "... introduced by [RFC8141]" insert: "The use of r- and = q- components with LEX URNs is not defined in this document. But they = provide new ... " 10. Sect. 2: Documentation Req: better replace "none" with a reference to the same document a) Ans: replace "none" with: "The details of the syntax, semantics and = use of LEX URNs are given in [this RFC]." 11. Sect. 3.1: Identifier structure Req: Capitalization of Section Title: non-consistent document a) To Deepen: Check rules for writing section titles a) Ans: we checked all the titles and capitalized the nouns Req: representation of non-ASCII characters in RFCs b) Ans: right: the guidelines suggest using the Unicode convention U + = XXXX b) Ans: the guidelines suggest using the Unicode convention U + XXXX, = then we brought 4 hexadecimal digits after U + 12. Examples Req: Are the examples shown real or hypothetical? a) Ans: Include the following: "All URN examples in the document are = hypothetical" 13. Sez. 5.3: Ordinal Numbers Req: To clarify whether it is Western or Eastern Arabic numbers a) Ans: add "Western" before "Arabic numbers" 14. Sez. 6.1: Basic Principles Req: substitution suggestion of "by parser" with "from parser=E2=80=9D a) Ans: replace "by parser" with "from parser" 15. Sez. 6.7: Structure of the Document Identifier at Manifestation = Level Req: syntax ambiguity: with only one element, it is not clear whether it = is component or feature a) Ans: Correct syntax according to Dale's suggestions in the presence = of features, component (if absent) is set to "all" (whole document) a) Ans: Correct syntax in a conforming manner (even if not equal) to = Dale's suggestions in the presence of features, component (if absent) is = set to "all" (whole document) =20 16. Sez. 6.8: Sources of Law References Req: Partition ID indicates an element and not a simple location b) To Deepen: It is true, but it depends on the level of granularity of = the identification systems (documents or also partitions?). b) Ans: It is true, but it depends from the type of text marking; we = have tried to explain better as it allows you to identify an element or = just a point 17. Sez. 8.1: The General Architecture of the System Req: Incomplete reference: RFC 3403 only defines NAPTR records a) Ans: Add reference to RFC 3405 explaining why the lex.urn.arpa domain = is created 18. Sez. 11.2: Jurisdiction-code Registration Req: missing the description of the registry structure a) Ans: Specify format and examples of the registry of jurisdiction = codes 19. Annex A: Summary of the syntax of the uniform names of the "lex" = namespace Req: Reported several errors or ambiguities: lowercase; = body/function/office, component/feature, =E2=80=A6 a) Ans: review the syntax, according to Dale's suggestions. We tested = the syntax with Bill's ABNF Parser 20. Annex A: Summary of the syntax of the uniform names of the "lex" = namespace Req: syntax error for % encoded b) To Deepen: Correct the % encoded syntax (see RFC 3261 par.25.1) b) Ans: Correct the % encoded syntax in a more simple way, as other RFCs 21. Annex A, Sec. B1.4 (Indication of the Body) and B1.5 (Indication of = the Function) Req: ambiguity between body / function / office a) Ans: Correct syntax to eliminate ambiguities 22. Annex D and D1: Http-based LEX identifier Req: HTTP and non-HTTP-based a) Ans: delete "based" Req: Same names used for http and urn elements: same semantics but = different syntax b) Ans: Use same names in http and urn elements (that have the same = syntax), maybe change delimiters =20 23. Sez. D1: Http-based URI Req: Wrong Link to Linked Data b) To Deepen: Correct reference to Linked Data b) Ans: the reference to Linked Data is to Berners Lee article=20 24. Scope of the document Req: Doc. describes not only URN but a fully federated system. Better = divide the two documents c) To Deepen: postpone the decision at the end of the discussion 25. Name or query? Req: Doc. also describes how to use URNs as a query, incompatibility = with URNs c) To Deepen: Document: URN Full and Unique; references: URN incomplete, = but useful (see e-mail sent to Dale on 9/20) 26. Sez. 11.2: Jurisdiction-code Registration Req: Re-assigning ccTLD: using the solution of international = institutions? b) Ans: The Registry of Jurisdiction Codes solves this problem. If the = ccTLD was reassigned, the old assignment remains in the log. If it was = already assigned, the applicant should choose a different one Req: .lex is no longer valid if .lex is assigned a) Ans: use pseudo-domain "lex.arpa" (see answer to Dale=E2=80=99s = remark n.4) 27. Full utility of this URN form Req: it seems that a browser plugin in needed c) To Deepen: The DDDS for URNs is fully described in various RFCs = (3401-05). However, to the best of our knowledge, the "urn:" schema is = not recognized by browsers, the most widely used tool for accessing = information. Therefore, to activate a resolution process from a native = reference as "... href =3D =E2=80=98urn: ...=E2=80=99 ", there are 2 = possibilities: 1. Develop a browser plug-in, that can recognize the urn schema. = Such a plug-in could route the urn to a service, active on one (or more) = servers, which is able to walk through the DNS chain and return the = address of the resolver (typically via http); 2. Transform a native urn reference to an http one (like: ... = href =3D "httReq: // ?urn: ..."), through a pre-processor or = style sheet, where the urn is a parameter of the call to the service = previously described. Req: Move the solution in a separate document c) To Deepen: Postpone the decision to the end of this review 28. Sez. 4.4: Use of Punycode Req: The syntax has to be revised for the non-ASCII. It includes = %-encoding but not punycode a) Ans: Use UTF-8 %encoded within a URN; convert punycode in the DNS = (see Dale point 2.) 29. Sez. 6.7: Ambiguity between components and features Req: syntax ambiguity: with one element it is not clear if it is a = [component] or a [feature] a) Ans: get rid of the syntax ambiguity in the manifestation (see Dale's = point 15.) 30. Annex D: Http-based LEX identifier Req: it seems unuseful, there are no references: remove or incorporate = in another doc=20 c) To Deepen: postpone the decision at the end of this revision phase 31. Name or query?=20 Req: it is difficult to separate naming rules from the resolution = aspects: split the document in two? Req: there are several elements which are difficult to identify by a = user and drive you to the construction of different URNs c) To Deepen: a document has always a complete and unequivocal URN; a = reference can have an incomplete URN, nevertheless useful for a = retrieval service. (See also the mail sent to Dale on 9/20) 32. Name or query?=20 Req: The user attempts to build a URN by some metadata he knows. The = input URN is not actually a URN to the document under analysis - it is a = query for some documents b) Ans: In the RFC we can better clarify the case of 1) a complete and = unequivocal URN as document identifier; 2) an incomplete URN but still = useful for retrieval and that can be used in references (See also the = e-mail sent to Dale on 9/20) 33. urn NID registry Req: Expert review should be completed before your document can be = approved for publication as an RFC c) Ans: waiting for the conclusion of the revision 34. Sect. 11.1 - NAPTR records Req: approval of the IAB to implement NAPTR records. Is the host = lex.ittig.cnr.it guaranteed for a long term? b) Ans: We contacted other institutions able to guarantee long-term = maintenance of a hostname, ex. =E2=80=9Cregistro.it=E2=80=9D, the CNR = (Italian National Research Council) service which provides registration = of the domain names .it and .eu Req: It might be better to document the approach in such a way that that = exact form of the NAPTR record is not in the I-D a) Ans: provide only a generic information, 35. Jurisdiction codes registry Req: Where should this new registry be located? Should it be added to an = existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols? c) To Deepen: see point 18, anyway at the beginning there are no records = in it 36. Final operations Req: only when the RFC will be approved=20 c) Ans: we=E2=80=99ll wait the final RFC approval 37. Mandate Req: Based on the I-D, it is not clear what mandate ITTIG-CNR has. Would = URN:LEX complement existing systems? Establishing a urn namespace to sources of law can be useful in the long = term. c) Ans: No specific mandate: this is a proposal for a global namespace = which every system can adhere to 38. Administration Req: ITTIG-CNR will be responsible of maintaining the uniqueness of the = =20 element. Req: In the level of country codes this will be easy. But there may be a = large number of sub- divisions within each country, and also organization-based = sub-divisions. If urn:lex becomes popular, it may be a substantial task = to maintain and to support organizations in making their = urn:lex identifiers actionable. Has ITTIG-CNR estimated the amount of work required in the short term / = long term?=20 b) Ans: The responsibility of maintaing jurisdiction codes will be = distributed at the level of each=20 jurisdiction, according to a federative de-centralized approach (see = sect. 7.2) 39. Semantic and syntax Req: The template does not provide sufficient information about the = semantics and syntax of NSS, but luckily draft-spinosa-urn-lex-11 is = very detailed in that respect. Most URN namespaces (and traditional = identifiers) have relatively simple semantics. Identifiers may be = totally "dumb" (it is impossible to see from the NSS what the URN = identifies) and even if the identifier has some semantic like ISBN, = things are kept simple (for those in the know, ISBN reveals the country = and the publisher) URNs from proposed urn:lex namespace may contain a = lot of information about the identified resource It may be difficult, = both for humans and applications, to make sense of this. b) Ans: The suggested metadata are necessary to guarantee, unequivocal = identifiers, nevertheless not all of them are mandatory. In the = references, only metadata at the level of Work are required (see email = on 9/20 in response to Dale=E2=80=99s remarks) Req: Having a lot of semantics in the NSS may overload the resolvers = with tasks which should be done by passing a request to an appropriate = target system. It is also more challenging to develop assignment rules = for a very semantic identifier system, and to be able to use such=20 system correctly b) Ans: the hierarchical structure paves the way to a structured = resolution (see e-mail to Dale on=20 9/20) Req: As regards syntax, concerns about un-encoded use of @ to indicate = an expression of a work c) To Deepen: not clear the motivations b) Ans: we added that unacceptable characters in URI are to be escaped 40. Resolution Req: ITTIG-CNR intends to maintain a centralized resolution service for = urn:lex. Better one for each jurisdiction b) Ans: Actually not. The idea is to de-centralize the system, starting = from the jurisdiction,=20 until the issuing authority. We will emphasize Sections 8.1 and 8.2 Req: It would of course be possible to harvest URN - URL mapping tables = from national lex=20 resolvers into the central resolver maintained by ITTIG-CNR.=20 b) Ans: Currently it is not foreseen --------------------------------------------------------- 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 --------------------------------------------------------- --Apple-Mail=_CE8D30C9-5C9F-45FC-B06E-B9929A89B135 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear All,
   we have just finalized = and uploaded in the IETF website a new version (v.12) of the urn-lex = draft. This new version follows your remarks and our change = proposals
https://datatracker.ietf.org/doc/draft-spinosa-urn-lex/

In particular we have organized your = remarks in three groups according how they have been addressed: 

a) fixed according to the proposed solution
b) fixed in a way similar to the proposed solution (details = in the the draft)
c) not yet fixed, waiting for agreement = on a solution

Here below are the details of = your remarks (as listed in our previous emails) including our proposals = and classified in one of the 3 groups.

Waiting for your feedback
Best regards
   Pierluigi and Enrico


1. Annex A: Use of alfanum, = etc.

Req: Simplifying = syntax with non-terminal elements
a) Ans: We will = simplify the syntax in the direction required

2. Sez. 4.4: How are non-ASCII characters to be = handled?

Req: = Different management of non-ASCII characters in different sections. = UTF-8% encoded or puny code incompatible
a) Ans: strongly recommend the use of ASCII base. In this = case we can use a straightforward DNS query for routing. In case this = solution is unacceptable for a jurisdiction: use UTF-8% = encoded in URNs and use punycode conversion in DNS. In this case, the = jurisdiction has to implement a software conversion as an = interface for DDDS

3. Sez. = 3.2: Compatibility with RFC 2141 and use of "~"

Req: character "~" not allowed in RFC = 2141
a) Ans: declare that the syntax conforms to RFC = 8141
b) To Deepen: For backward compatibility, the "/", = previously prohibited in URNs, is reserved for future use, then we can = remove the "/" from prohibited characters and include it in "future = expansions"
b) Ans: To keep backward compatibility with = existing applications in some jurisdictions, the "lex" NID syntax does = not include the use of the 
   character = "/" in this version.

4. Sez. = 11.2: The pseudo-TLD ".lex"

Req: it no longer works if .lex is assigned
a) Ans: use pseudo-domain "lex.arpa"

5. Sez. 6.7: Dealing with = publishers

Req: = Possible issues if an event is assigned by an editor independently
a) Ans: By joining the federated system, a publisher = accepts the urn-lex rules. The Jurisdictional Registrar (Section 7.2) = provides guidelines and monitors their application

Req: Domain Name Editor: persistence of = the manifestation depends on the publisher
b) To Deepen: = Common problem with all components where a domain name is indicated. = Think of a solution through aliases
 
b) = Ans: Since publishers' domain names may vary over time, manifestations = already assigned by a publisher remain 
    =  unchanged even if the identified object is no longer accessible. = In this case, in order to make its materials accessible, the = publisher 
     will have to create = for each of them a new manifestation with the new domain name;



6. Abstract

Req: World Wide Web Consortium = reference for resource identification
a) Ans: Replace W3C with IETF


7. = Sez. 1.1: The Purpose of Namespace "lex"

Req: Useful when mapped on HTTP URLs = and not URIs
b) To Deepen: we often = talk about http uri. Maybe we can emphasize its function as identifier = rather than as locator.  The identifier is often not = an absolute URL
a) changed URIs with = URLs. We have retained the URI indication when it comes to = identifier and not locator


8. Sez. 1.4: General Characteristics of the System

Req: SHOULD seems = more appropriate than MUST
a) Ans: = replace "must" with "should"


9. = Sez. 2: Syntax label

Req: The syntax and semantics of components r- and q- are not = defined in the document
a) Ans: = after: "... introduced by [RFC8141]" insert: "The use of r- and q- = components with LEX URNs is not defined in this document. But they = provide new ... "


10. Sect. 2: = Documentation

Req: = better replace "none" with a reference to the same document
a) Ans: replace "none" with: "The = details of the syntax, semantics and use of LEX URNs are given in [this = RFC]."


11. Sect. 3.1: = Identifier structure

Req: Capitalization of Section Title: non-consistent = document
a) To Deepen: Check rules for writing section = titles
a) Ans: we checked all the titles and = capitalized the nouns

Req: representation = of non-ASCII characters in RFCs
b) Ans: right: the = guidelines suggest using the Unicode convention U + XXXX
b) = Ans: the guidelines suggest using the Unicode convention U + XXXX, = then we brought 4 hexadecimal digits after U +


12. Examples
Req: Are the examples shown real or = hypothetical?
a) Ans: Include the = following: "All URN examples in the document are hypothetical"


13. Sez. 5.3: Ordinal Numbers

Req: To clarify = whether it is Western or Eastern Arabic numbers
a) Ans: add "Western" before "Arabic numbers"

14. Sez. 6.1: Basic Principles

Req: substitution suggestion of "by = parser" with "from parser=E2=80=9D
a) = Ans: replace "by parser" with "from parser"


15. Sez. 6.7: Structure of the Document Identifier at = Manifestation Level

Req: syntax ambiguity: with only one element, it is not clear = whether it is component or feature
a) = Ans: Correct syntax according to Dale's suggestions in the presence of = features, component (if absent) is set to "all" (whole document)
a) Ans: Correct syntax in a conforming manner (even if = not equal) to Dale's suggestions in the presence of features, = component (if absent) is set to "all" (whole document)
 

16. Sez. 6.8: Sources = of Law References

Req: Partition ID indicates an element and not a simple = location

b) To = Deepen: It is true, but it depends on the level of granularity of the = identification systems (documents or also partitions?).
b) = Ans: It is true, but it depends from the type of text = marking; we have tried to explain better as it allows you to = identify an element or just a point


17. Sez. 8.1: The General Architecture of the = System

Req: = Incomplete reference: RFC 3403 only defines NAPTR records
a) Ans: Add reference to RFC 3405 = explaining why the lex.urn.arpa domain is created


18. Sez. 11.2: Jurisdiction-code Registration

Req: missing the = description of the registry structure
a) Ans: Specify format and examples of the registry of = jurisdiction codes


19. Annex A: Summary = of the syntax of the uniform names of the "lex" namespace

Req: Reported = several errors or ambiguities: lowercase; body/function/office, = component/feature, =E2=80=A6
a) Ans: = review the syntax, according to Dale's suggestions. We tested the = syntax with Bill's ABNF Parser


20. = Annex A: Summary of the syntax of the uniform names of the "lex" = namespace

Req: = syntax error for % encoded
b) To = Deepen: Correct the % encoded syntax (see RFC 3261 par.25.1)
b) Ans: Correct the % encoded syntax in a more simple = way, as other RFCs


21. Annex A, Sec. = B1.4 (Indication of the Body) and B1.5 (Indication of the Function)

Req: ambiguity = between body / function / office
a) = Ans: Correct syntax to eliminate ambiguities


22. Annex D and D1: Http-based LEX identifier

Req: HTTP and = non-HTTP-based
a) Ans: delete "based"

Req: Same names used for http and urn = elements: same semantics but different syntax
b) Ans: = Use same names in http and urn elements (that have the same = syntax), maybe change delimiters
 

23. Sez. D1: Http-based URI
Req: Wrong Link to Linked Data
b) To Deepen: Correct reference to Linked Data
b)= Ans: the reference to Linked Data is to Berners Lee article 


24. Scope of the = document

Req: = Doc. describes not only URN but a fully federated system. Better divide = the two documents
c) To Deepen: postpone the decision at = the end of the discussion


25. = Name or query?

Req:= Doc. also describes how to use URNs as a query, incompatibility with = URNs
c) To Deepen: Document: URN Full and Unique; = references: URN incomplete, but useful (see e-mail sent to Dale on = 9/20)


26. Sez. 11.2: = Jurisdiction-code Registration

Req: Re-assigning ccTLD: using the solution of international = institutions?
b) Ans: The Registry of Jurisdiction = Codes solves this problem. If the ccTLD was reassigned, the old = assignment remains in the log. If it was already assigned, the = applicant should choose a different one

Req: = <name> .lex is no longer valid if .lex is assigned
a) = Ans: use pseudo-domain "lex.arpa" (see answer to Dale=E2=80=99s remark = n.4)


27. Full utility of this URN form

Req: it seems that a browser plugin in = needed
c) To = Deepen: The DDDS for URNs is fully described in various RFCs = (3401-05). However, to the best of our knowledge, the "urn:" schema = is not recognized by browsers, the most widely used tool for = accessing information. Therefore, to activate a resolution process = from a native reference as "... href =3D =E2=80=98urn: ...=E2=80=99 = ", there are 2 possibilities:

1. = Develop a browser plug-in, that can recognize the urn schema. Such a = plug-in could route the urn to a service, active on one (or more) = servers, which is able to walk through the DNS chain and return the = address of the resolver (typically via http);

= 2. Transform a native urn reference to an http one (like: ... = href =3D "httReq: // <service>?urn: ..."), through a pre-processor = or style sheet, where the urn is a parameter of the call to the = service previously described.


Req: Move the solution in a separate document
c) To Deepen: Postpone the decision to the end of = this review


28. Sez. 4.4: Use of Punycode

Req: The syntax has to be revised for the non-ASCII. It = includes %-encoding but not punycode
a) = Ans: Use UTF-8 %encoded within a URN; convert punycode in the DNS = (see Dale point 2.)




29. Sez. = 6.7: Ambiguity between components and features

Req: syntax ambiguity: with one element it is not clear = if it is a [component] or a [feature]
a) Ans: get rid = of the syntax ambiguity in = the manifestation (see Dale's point 15.)


30. Annex D: = Http-based LEX identifier

Req: it seems = unuseful, there are no references: remove or incorporate in another = doc 
c) To Deepen: postpone the decision at the end = of this revision phase


31. = Name or query? 
Req: it is difficult = to separate naming rules from the resolution aspects: split = the document in two?
Req: there are several = elements which are difficult to identify by a user = and drive you to the construction of different URNs
c) To Deepen: a document has always a complete and = unequivocal URN; a reference can have an incomplete URN, = nevertheless useful for a retrieval service. (See also = the mail sent to Dale on 9/20)


32. Name or query? 
Req: The user attempts to build a URN by = some metadata he knows. The input URN is not actually a URN to = the document under analysis - it is a query for = some documents
b) Ans: In the RFC we can better = clarify the case of 1) a complete and unequivocal URN as = document identifier; 2) an incomplete URN but still useful for = retrieval and that can  be used in references = (See also the e-mail sent to Dale on 9/20)


33. urn = NID registry
Req: Expert review should be = completed before your document can be approved for publication as an = RFC
c) Ans: waiting for the conclusion of the revision


34. Sect. 11.1 - = NAPTR records
Req: approval of the IAB to implement = NAPTR records. Is the host lex.ittig.cnr.it guaranteed for a long term?
b) Ans: We contacted other institutions able to = guarantee long-term maintenance of a hostname, ex. =E2=80=9Cregistro.it=E2=80=9D, the CNR = (Italian National Research Council) service which provides = registration of the domain names .it and .eu

Req: It might be better to document the approach in such a = way that that exact form of the NAPTR record is not in the I-D
a) Ans: provide only a generic information, <urn-lex.zone.org>


35. Jurisdiction codes registry
Req: Where should this new registry be located? Should it = be added to an existing registry page? If not, does it belong in an = existing
category at http://www.iana.org/protocols?

c) To Deepen: see point 18, anyway at the beginning there are = no records in it

36. Final = operations
Req: only when the RFC will be = approved 
c) Ans: we=E2=80=99ll wait the final RFC = approval


37. Mandate
Req: Based on the I-D, it is not clear what mandate ITTIG-CNR = has. Would URN:LEX complement existing systems?
Establishing a urn namespace to sources of law can be useful = in the long term.
c) Ans: No specific mandate: this is a = proposal for a global namespace which every system can adhere to


38. = Administration
Req: ITTIG-CNR will be responsible of = maintaining the uniqueness of the <jurisdiction> 
element.
Req: In the level of country codes = this will be easy. But there may be a large number of sub-
divisions within each country, and also organization-based = sub-divisions. If urn:lex becomes popular, it may be a substantial task = to maintain <jurisdiction> and to support organizations =  in making their urn:lex identifiers actionable.
Has = ITTIG-CNR estimated the amount of work required in the short term / long = term? 

b) Ans: = The responsibility of maintaing jurisdiction codes will be distributed = at the level of each 
jurisdiction, according to a = federative de-centralized approach (see sect. 7.2)


39. Semantic and = syntax
Req: The template does not provide sufficient = information about the semantics and syntax of NSS, but luckily = draft-spinosa-urn-lex-11 is very detailed in that respect. Most URN = namespaces (and traditional identifiers) have relatively simple = semantics. Identifiers may be totally "dumb" (it is impossible to = see from the NSS what the URN identifies) and even if the identifier has = some semantic like ISBN, things are kept simple (for those in the = know, ISBN reveals the country and the publisher) URNs from proposed = urn:lex namespace may contain a lot of information about the = identified resource It may be difficult, both for humans and = applications, to make sense of this.
b) Ans: The suggested = metadata are necessary to guarantee, unequivocal identifiers, = nevertheless not all of them are mandatory. In the references, only = metadata at the level of Work are required (see email on 9/20 in = response to Dale=E2=80=99s remarks)

Req: = Having a lot of semantics in the NSS may overload the resolvers with = tasks which should be  done by passing a request to an = appropriate target system. It is also more challenging to develop = assignment rules for a very semantic identifier system, and to be able = to use such 
system correctly
b) Ans: = the hierarchical structure paves the way to a structured resolution (see = e-mail to Dale on 
9/20)

Req: As regards syntax, concerns about un-encoded use of @ to = indicate an expression of a work
c) To Deepen: not clear = the motivations
b) Ans: we added that unacceptable = characters in URI are to be escaped


40. Resolution
Req: ITTIG-CNR intends = to maintain a centralized resolution service for urn:lex. Better one for =  each jurisdiction
b) Ans: Actually not. The idea is = to de-centralize the system, starting from the jurisdiction, 
until the issuing authority. We will emphasize Sections 8.1 = and 8.2

Req: It would of course be possible = to harvest URN - URL mapping tables from national lex 
resolvers into the central resolver maintained by = ITTIG-CNR. 
b) Ans: Currently it is not foreseen




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




= --Apple-Mail=_CE8D30C9-5C9F-45FC-B06E-B9929A89B135-- From nobody Tue Nov 28 06:57:54 2017 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 346DA124E15 for ; Tue, 28 Nov 2017 06:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 D_BuWykX2WGf for ; Tue, 28 Nov 2017 06:57:50 -0800 (PST) Received: from itu2out.svc.unicc.org (itu2out.svc.unicc.org [192.91.247.110]) (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 92F651200B9 for ; Tue, 28 Nov 2017 06:57:49 -0800 (PST) Received: from TUCM02.TUECSP.UNICC.ORG (unknown [10.81.6.71]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iccpfxor02.svc.unicc.org (Postfix) with ESMTPS id 4912160F84 for ; Tue, 28 Nov 2017 14:57:47 +0000 (UTC) Received: from TUCM03.TUECSP.UNICC.ORG (10.81.38.70) by TUCM02.TUECSP.UNICC.ORG (10.81.6.71) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 28 Nov 2017 14:57:47 +0000 Received: from TUCM03.TUECSP.UNICC.ORG ([10.81.38.70]) by TUCM03.TUECSP.UNICC.ORG ([10.81.38.70]) with mapi id 15.00.1293.002; Tue, 28 Nov 2017 14:57:46 +0000 From: "OTA, Hiroshi" To: "urn@ietf.org" CC: "TSB SG15 Secretariat, ITU" Thread-Topic: Request for the NID 'itu' for URN - draft-itu-urn Thread-Index: AdNoV/8WE67UFRnVRBmdA4tA0JzgMw== Date: Tue, 28 Nov 2017 14:57:46 +0000 Message-ID: <7485c1030d0f4a59b3099226440ab3c6@TUCM03.TUECSP.UNICC.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.81.64.102] Content-Type: multipart/mixed; boundary="_004_7485c1030d0f4a59b3099226440ab3c6TUCM03TUECSPUNICCORG_" MIME-Version: 1.0 Archived-At: Subject: [urn] Request for the NID 'itu' for URN - draft-itu-urn X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 14:57:53 -0000 --_004_7485c1030d0f4a59b3099226440ab3c6TUCM03TUECSPUNICCORG_ Content-Type: multipart/alternative; boundary="_000_7485c1030d0f4a59b3099226440ab3c6TUCM03TUECSPUNICCORG_" --_000_7485c1030d0f4a59b3099226440ab3c6TUCM03TUECSPUNICCORG_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, I would like to submit the attached Internet-Draft "URN Namespace for ITU" = (draft-itu-urn.txt) for requesting the Namespace Identifier (NID) 'itu' for= Uniform Resource Names (URNs) used to identify resources published by the = ITU (International Telecommunication Union). Thank you. Hiroshi --- Hiroshi OTA, Advisor, ITU-T SG15 International Telecommunication Union Place des Nations CH-1211 Geneva 20 Switzerland Tel: +41 22 730 6356 Fax: +41 22 730 5853 E-mail: hiroshi.ota@itu.int --_000_7485c1030d0f4a59b3099226440ab3c6TUCM03TUECSPUNICCORG_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all,

 

I would like to submit the attached Internet-Draft &= #8220;URN Namespace for ITU” (draft-itu-urn.txt) for requesting the N= amespace Identifier (NID) 'itu' for Uniform Resource Names (URNs) used to i= dentify resources published by the ITU (International Telecommunication Union).

 

Thank you.

Hiroshi

 

---

Hiroshi OTA,= Advisor, ITU-T SG15

Internationa= l Telecommunication Union

Place des Na= tions CH-1211 Geneva 20 Switzerland

Tel: +41= 22 730 6356

Fax: +41= 22 730 5853

E-mail: hiroshi.ota@itu.int

 

 

--_000_7485c1030d0f4a59b3099226440ab3c6TUCM03TUECSPUNICCORG_-- --_004_7485c1030d0f4a59b3099226440ab3c6TUCM03TUECSPUNICCORG_ Content-Type: text/plain; name="draft-itu-urn.txt" Content-Description: draft-itu-urn.txt Content-Disposition: attachment; filename="draft-itu-urn.txt"; size=9427; creation-date="Wed, 22 Nov 2017 15:03:09 GMT"; modification-date="Tue, 28 Nov 2017 13:40:55 GMT" Content-Transfer-Encoding: base64 CgoKCkludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBILiBPdGEsIEVkLgpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIElUVSBUU0IKSW50ZW5kZWQgc3RhdHVzOiBJbmZv cm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgIE5vdmVtYmVyIDI3LCAyMDE3CkV4cGly ZXM6IE1heSAzMSwgMjAxOAoKCiAgICAgICAgICAgICAgICAgICAgICAgICBVUk4gTmFtZXNwYWNl IGZvciBJVFUKICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkcmFmdC1pdHUtdXJuCgpBYnN0 cmFjdAoKICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIE5hbWVzcGFjZSBJZGVudGlmaWVy IChOSUQpICdpdHUnIGZvcgogICBVbmlmb3JtIFJlc291cmNlIE5hbWVzIChVUk5zKSB1c2VkIHRv IGlkZW50aWZ5IHJlc291cmNlcyBwdWJsaXNoZWQgYnkKICAgdGhlIElUVSAoSW50ZXJuYXRpb25h bCBUZWxlY29tbXVuaWNhdGlvbiBVbmlvbikuCgpTdGF0dXMgb2YgVGhpcyBNZW1vCgogICBUaGlz IEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhl CiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuCgogICBJbnRlcm5ldC1EcmFmdHMg YXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwogICBUYXNr IEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0 ZQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBj dXJyZW50IEludGVybmV0LQogICBEcmFmdHMgaXMgYXQgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kcmFmdHMvY3VycmVudC8uCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3Vt ZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMKICAgYW5kIG1heSBiZSB1cGRh dGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkKICAg dGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZl cmVuY2UKICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4g cHJvZ3Jlc3MuIgoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBNYXkgMzEs IDIwMTguCgpDb3B5cmlnaHQgTm90aWNlCgogICBDb3B5cmlnaHQgKGMpIDIwMTcgSUVURiBUcnVz dCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUKICAgZG9jdW1lbnQgYXV0aG9ycy4g IEFsbCByaWdodHMgcmVzZXJ2ZWQuCgogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQ IDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8g SUVURiBEb2N1bWVudHMKICAgKGh0dHBzOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8p IGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZgogICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50 LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMKICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRl c2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0CiAgIHRvIHRo aXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVu dCBtdXN0CiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJl ZCBpbiBTZWN0aW9uIDQuZSBvZgogICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJl IHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMKICAgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlm aWVkIEJTRCBMaWNlbnNlLgoKCgoKCk90YSAgICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBN YXkgMzEsIDIwMTggICAgICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgVVJOIE5hbWVzcGFjZSBmb3IgSVRVICAgICAgICAgICAgTm92ZW1iZXIgMjAxNwoK ClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgSW50cm9kdWN0aW9uICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDIKICAgMi4gIFVSTiBTcGVjaWZpY2F0 aW9uIGZvciBJVFUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAyCiAgICAg Mi4xLiAgTmFtZXNwYWNlIElkZW50aWZpZXIgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAgMgogICAgIDIuMi4gIFZlcnNpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDMKICAgICAyLjMuICBSZWdpc3RyYW50ICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzCiAgICAgMi40LiAgUHVy cG9zZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAg MwogICAgIDIuNS4gIFN5bnRheCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgIDMKICAgICAyLjYuICBBc3NpZ25tZW50ICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0CiAgICAgMi43LiAgU2VjdXJpdHkgYW5k IFByaXZhY3kgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNAogICAgIDIu OC4gIEludGVyb3BlcmFiaWxpdHkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgIDQKICAgICAyLjkuICBEb2N1bWVudGF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0CiAgIDMuICBBY2tub3dsZWRnZW1lbnRzICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNAogICA0LiAgSUFOQSBDb25z aWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQK ICAgNS4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gICA0CiAgIDYuICBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNQogICAgIDYuMS4gIE5vcm1hdGl2ZSBSZWZl cmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUKICAgICA2LjIu ICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICA1CiAgIEF1dGhvcidzIEFkZHJlc3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAgNQoKMS4gIEludHJvZHVjdGlvbgoKICAgSVRVIGlzIHRoZSBV bml0ZWQgTmF0aW9ucyBzcGVjaWFsaXplZCBhZ2VuY3kgZm9yIGluZm9ybWF0aW9uIGFuZAogICBj b21tdW5pY2F0aW9uIHRlY2hub2xvZ2llcyAoSUNUcykuICBBcyBwYXJ0IG9mIHRoZXNlIHNwZWNp ZmljYXRpb24KICAgZWZmb3J0cywgdGhlcmUgaXMgYSBuZWVkIHRvIG1haW50YWluIGlkZW50aWZp ZXJzIGluIGEgbWFuYWdlZAogICBuYW1lc3BhY2UgdGhhdCBpcyB1bmlxdWUgYW5kIHBlcnNpc3Rl bnQuICBUbyBlbnN1cmUgdGhhdCB0aGlzCiAgIG5hbWVzcGFjZSdzIHVuaXF1ZW5lc3MgaXMgYWJz b2x1dGUsIHNwZWNpZmljYXRpb24gb2YgYW4gVVJOIFN5bnRheAogICBSRkMgMjE0MSBbMl0gTmFt ZXNwYWNlIElkZW50aWZpZXIgKE5JRCkgZm9yIHVzZSBieSB0aGUgSVRVIGlzCiAgIHNwZWNpZmll ZCBpbiB0aGlzIGRvY3VtZW50LCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlIE5JRAogICBy ZWdpc3RyYXRpb24gcHJvY2VzcyBzcGVjaWZpZWQgaW4gVVJOIE5hbWVzcGFjZSBEZWZpbml0aW9u IE1lY2hhbmlzbXMKICAgUkZDIDM0MDYgWzNdLiAgRWFjaCBJVFUgc2VjdG9yIHNwZWNpZmllcyBh bmQgbWFuYWdlcyByZXNvdXJjZXMgdGhhdAogICB1dGlsaXplIHRoaXMgVVJOIGlkZW50aWZpY2F0 aW9uIG1vZGVsLiAgTWFuYWdlbWVudCBhY3Rpdml0aWVzIGZvcgogICB0aGVzZSBhbmQgb3RoZXIg cmVzb3VyY2VzIHR5cGVzIGFyZSBoYW5kbGVkIGJ5IHRoZSBtYW5hZ2VyIG9mIHRoZSBJVFUKICAg VVJOIGRvY3VtZW50LgoKMi4gIFVSTiBTcGVjaWZpY2F0aW9uIGZvciBJVFUKCiAgIFRoaXMgc2Vj dGlvbiBjb250YWlucyB0aGUgbWF0ZXJpYWwgaWRlbnRpZmllZCBpbiBBcHBlbmRpeCBBIFJGQyA4 MTQxCiAgIFs2XS4KCjIuMS4gIE5hbWVzcGFjZSBJZGVudGlmaWVyCgogICBpdHUKCgoKCgoKCk90 YSAgICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgMzEsIDIwMTggICAgICAgICAgICAg ICAgICBbUGFnZSAyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgVVJOIE5hbWVzcGFjZSBm b3IgSVRVICAgICAgICAgICAgTm92ZW1iZXIgMjAxNwoKCjIuMi4gIFZlcnNpb24KCiAgIG8gIFJl Z2lzdHJhdGlvbiB2ZXJzaW9uIG51bWJlcjogMQoKICAgbyAgUmVnaXN0cmF0aW9uIGRhdGU6IDIw MTctMTEtMDEKCjIuMy4gIFJlZ2lzdHJhbnQKCiAgIFJlZ2lzdGVyaW5nIG9yZ2FuaXphdGlvbjoK ICAgICAgTmFtZTogSW50ZXJuYXRpb25hbCBUZWxlY29tbXVuaWNhdGlvbiBVbmlvbiAoSVRVKQog ICAgICBBZGRyZXNzOgogICAgICAgICBJVFUvVFNCCiAgICAgICAgIFBsYWNlIGRlcyBOYXRpb25z CiAgICAgICAgIDEyMTEgR2VuZXZhIDIwCiAgICAgICAgIFN3aXR6ZXJsYW5kCiAgICAgIERlc2ln bmF0ZWQgY29udGFjdCBwZXJzb246CiAgICAgICAgIEhpcm9zaGkgT3RhCiAgICAgICAgIFJvbGU6 IElUVS1UIFN0dWR5IEdyb3VwIDE1IEFkdmlzb3IKICAgICAgICAgRW1haWw6IHRzYnNnMTVAaXR1 LmludAoKMi40LiAgUHVycG9zZQoKICAgTmFtZXNwYWNlIG5lZWRlZCBmb3IgWUFORyBSRkMgNjAy MCBbNF0gUkZDIDc5NTAgWzVdIG1vZHVsZXMuCgoyLjUuICBTeW50YXgKCiAgIHVybjppdHU6e0lU VS1TZWN0b3J9OntTZWN0b3JSZXNvdXJjZX06e1Jlc291cmNlU3BlY2lmaWNTdHJpbmd9CgogICAi SVRVLVNlY3RvciIgaXMgZWl0aGVyICdyJyBmb3IgUmFkaW9jb21tdW5pY2F0aW9uIFNlY3Rvciwg J3QnIGZvcgogICBUZWxlY29tbXVuaWNhdGlvbiBTdGFuZGFyZGl6YXRpb24gU2VjdG9yLCAnZCcg Zm9yIFRlbGVjb21tdW5pY2F0aW9uCiAgIERldmVsb3BtZW50IFNlY3Rvci4KCiAgICJTZWN0b3JS ZXNvdXJjZSIgaW5kaWNhdGVzIHRoZSB0eXBlIG9mIHJlc291cmNlLgoKICAgIlJlc291cmNlU3Bl Y2lmaWNTdHJpbmciIGlkZW50aWZpZXMgdGhlIGluZm9ybWF0aW9uIGFib3V0IHRoZQogICByZXNv dXJjZS4KCiAgIFRoZSAiU2VjdG9yUmVzb3VyY2UiIGlzIGFuIFVTLUFTQ0lJIHN0cmluZyB0aGF0 IGNvbmZvcm1zIHRvIHRoZSBVUk4KICAgc3ludGF4IHJlcXVpcmVtZW50cyBSRkMgMjE0MSBbMl0g YW5kIGRlZmluZXMgYSBzcGVjaWZpYyBjbGFzcyBvZgogICByZXNvdXJjZSB0eXBlLiAgRWFjaCBy ZXNvdXJjZSB0eXBlIGhhcyBhIHNwZWNpZmljIGxhYmVsaW5nIHNjaGVtZQogICB0aGF0IGlzIGNv dmVyZWQgYnkgIlJlc291cmNlU3BlY2lmaWNTdHJpbmciLCB3aGljaCBhbHNvIGNvbmZvcm1zIHRv CiAgIHRoZSBuYW1pbmcgcmVxdWlyZW1lbnRzLgoKICAgSVRVIHdpbGwgbWFuYWdlIHRoZSBhc3Np Z25tZW50IG9mICJTZWN0b3JSZXNvdXJjZSIgYW5kIHRoZSBzcGVjaWZpYwogICByZWdpc3RyYXRp b24gdmFsdWVzIGFzc2lnbmVkIGZvciBlYWNoIHJlc291cmNlLgoKCgoKCgpPdGEgICAgICAgICAg ICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDMxLCAyMDE4ICAgICAgICAgICAgICAgICAgW1BhZ2Ug M10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIFVSTiBOYW1lc3BhY2UgZm9yIElUVSAgICAg ICAgICAgIE5vdmVtYmVyIDIwMTcKCgoyLjYuICBBc3NpZ25tZW50CgogICBFYWNoIElUVSBzZWN0 b3Igc3BlY2lmaWVzIGFuZCBtYW5hZ2VzIHJlc291cmNlcyB0aGF0IHV0aWxpemUgdGhpcyBVUk4K ICAgaWRlbnRpZmljYXRpb24gbW9kZWwuICBFYWNoIElUVSdzIHNlY3RvciB3aWxsIGVuc3VyZSB0 aGUgdW5pcXVlbmVzcwogICBvZiB0aGUgc3RyaW5ncyB0aGVtc2VsdmVzIG9yIHdpbGwgcGVybWl0 IHNlY29uZGFyeSByZXNwb25zaWJpbGl0eSBmb3IKICAgbWFuYWdlbWVudCBvZiB3ZWxsLWRlZmlu ZWQgc3ViLXRyZWVzLgoKMi43LiAgU2VjdXJpdHkgYW5kIFByaXZhY3kKCiAgIFNlZSB0aGUgbWF0 ZXJpYWwgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIChTZWN0aW9uIDUpIHNlY3Rpb24u CgoyLjguICBJbnRlcm9wZXJhYmlsaXR5CgogICBUaGUgcHVycG9zZSBvZiB0aGUgSVRVIG5hbWVz cGFjZSBhbmQgaXRzIHVzZSBmb3IgWUFORyBpcyBtZWFudCB0byBhaWQKICAgaW50ZXJvcGVyYWJp bGl0eSBieSBhdm9pZGluZyBkdXBsaWNhdGUgb3IgY29uZmxpY3RpbmcgbmFtZXNwYWNlcy4KCjIu OS4gIERvY3VtZW50YXRpb24KCiAgIFRoZSBJVFUgbWFpbnRhaW5zIGEgVW5pZm9ybSBSZXNvdXJj ZSBOYW1lcyAoVVJOKSBkb2N1bWVudCB0aGF0CiAgIHByb3ZpZGVzIHRoZSBtZWNoYW5pc20gdG8g ZW5zdXJlIHRoZSByZXNvdXJjZSBpZGVudGlmaWVycyBhcmUgdW5pcXVlLgogICBUaGUgSVRVIFVS TiBNYW5hZ2VtZW50IFs3XSBkb2N1bWVudCBjb250YWlucyB0aGUgZm9ybWF0dGluZwogICBndWlk ZWxpbmVzIGZvciB0aGUgVVJOIGhpZXJhcmNoeSB0aGF0IGlzIHJvb3RlZCBhdCB0aGUgYmFzZSBV Uk4gdGhhdAogICB3YXMgYXNzaWduZWQgYnkgSUFOQS4KCjMuICBBY2tub3dsZWRnZW1lbnRzCgog ICBUZWNobmljYWwgY29udGFjdCBwZXJzb246CiAgICAgIFNjb3R0IE1hbnNmaWVsZAogICAgICBS b2xlOiBJVFUtVCBTdHVkeSBHcm91cCAxNSBRdWVzdGlvbiAxNCBBc3NvY2lhdGUgUmFwcG9ydGV1 cgogICAgICBFbWFpbDogc2NvdHQubWFuc2ZpZWxkQGVyaWNzc29uLmNvbQoKNC4gIElBTkEgQ29u c2lkZXJhdGlvbnMKCiAgIFRoaXMgZG9jdW1lbnQgYWRkcyAiaXR1IiB0byB0aGUgIkZvcm1hbCBV Uk4gTmFtZXNwYWNlcyIgcmVnaXN0cnkKICAgPGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVu dHMvdXJuLW5hbWVzcGFjZXM+LiAgVGhpcyBpcyB0aGUKICAgZGVmaW5pbmcgZG9jdW1lbnQuCgo1 LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIFRoZXJlIGFyZSBubyBhZGRpdGlvbmFsIHNl Y3VyaXR5IGNvbnNpZGVyYXRpb25zIG90aGVyIHRoYW4gdGhvc2UKICAgbm9ybWFsbHkgYXNzb2Np YXRlZCB3aXRoIHRoZSB1c2UgYW5kIHJlc29sdXRpb24gb2YgVVJOcyBpbiBnZW5lcmFsLAogICB3 aGljaCBhcmUgZGVzY3JpYmVkIGluIEZ1bmN0aW9uYWwgUmVxdWlyZW1lbnRzIGZvciBVUk5zIFJG QyAxNzM3IFsxXSwKICAgVVJOIFN5bnRheCBSRkMgMjE0MSBbMl0sIGFuZCBVUk4gTmFtZXNwYWNl IERlZmluaXRpb24gTWVjaGFuaXNtcyBSRkMKICAgMzQwNiBbM10uCgoKCgoKCgpPdGEgICAgICAg ICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDMxLCAyMDE4ICAgICAgICAgICAgICAgICAgW1Bh Z2UgNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIFVSTiBOYW1lc3BhY2UgZm9yIElUVSAg ICAgICAgICAgIE5vdmVtYmVyIDIwMTcKCgo2LiAgUmVmZXJlbmNlcwoKNi4xLiAgTm9ybWF0aXZl IFJlZmVyZW5jZXMKCiAgIFsxXSAgICAgICAgU29sbGlucywgSy4gYW5kIEwuIE1hc2ludGVyLCAi RnVuY3Rpb25hbCBSZXF1aXJlbWVudHMgZm9yCiAgICAgICAgICAgICAgVW5pZm9ybSBSZXNvdXJj ZSBOYW1lcyIsIFJGQyAxNzM3LCBET0kgMTAuMTc0ODcvUkZDMTczNywKICAgICAgICAgICAgICBE ZWNlbWJlciAxOTk0LCA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmMxNzM3Pi4K CiAgIFsyXSAgICAgICAgTW9hdHMsIFIuLCAiVVJOIFN5bnRheCIsIFJGQyAyMTQxLCBET0kgMTAu MTc0ODcvUkZDMjE0MSwKICAgICAgICAgICAgICBNYXkgMTk5NywgPGh0dHBzOi8vd3d3LnJmYy1l ZGl0b3Iub3JnL2luZm8vcmZjMjE0MT4uCgogICBbM10gICAgICAgIERhaWdsZSwgTC4sIHZhbiBH dWxpaywgRC4sIElhbm5lbGxhLCBSLiwgYW5kIFAuIEZhbHRzdHJvbSwKICAgICAgICAgICAgICAi VW5pZm9ybSBSZXNvdXJjZSBOYW1lcyAoVVJOKSBOYW1lc3BhY2UgRGVmaW5pdGlvbgogICAgICAg ICAgICAgIE1lY2hhbmlzbXMiLCBSRkMgMzQwNiwgRE9JIDEwLjE3NDg3L1JGQzM0MDYsIE9jdG9i ZXIgMjAwMiwKICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9y ZmMzNDA2Pi4KCjYuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFs0XSAgICAgICAgQmpv cmtsdW5kLCBNLiwgRWQuLCAiWUFORyAtIEEgRGF0YSBNb2RlbGluZyBMYW5ndWFnZSBmb3IKICAg ICAgICAgICAgICB0aGUgTmV0d29yayBDb25maWd1cmF0aW9uIFByb3RvY29sIChORVRDT05GKSIs IFJGQyA2MDIwLAogICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM2MDIwLCBPY3RvYmVyIDIw MTAsCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNjAy MD4uCgogICBbNV0gICAgICAgIEJqb3JrbHVuZCwgTS4sIEVkLiwgIlRoZSBZQU5HIDEuMSBEYXRh IE1vZGVsaW5nIExhbmd1YWdlIiwKICAgICAgICAgICAgICBSRkMgNzk1MCwgRE9JIDEwLjE3NDg3 L1JGQzc5NTAsIEF1Z3VzdCAyMDE2LAogICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRp dG9yLm9yZy9pbmZvL3JmYzc5NTA+LgoKICAgWzZdICAgICAgICBTYWludC1BbmRyZSwgUC4gYW5k IEouIEtsZW5zaW4sICJVbmlmb3JtIFJlc291cmNlIE5hbWVzCiAgICAgICAgICAgICAgKFVSTnMp IiwgUkZDIDgxNDEsIERPSSAxMC4xNzQ4Ny9SRkM4MTQxLCBBcHJpbCAyMDE3LAogICAgICAgICAg ICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzgxNDE+LgoKICAgWzddICAg ICAgICBJVFUsICJJVFUgVVJOIE1hbmFnZW1lbnQiLCAyMDE3LCA8aHR0cDovL3d3dy5pdHUuaW50 L2VuLwogICAgICAgICAgICAgIElUVS1UL0RvY3VtZW50cy9JVFUtVVJOLU1hbmFnZW1lbnQucGRm Pi4KCkF1dGhvcidzIEFkZHJlc3MKCiAgIEhpcm9zaGkgT3RhIChlZGl0b3IpCiAgIElUVSBUU0IK ICAgUGxhY2UgZGVzIE5hdGlvbnMKICAgR2VuZXZhLCAyMCAgMTIxMQogICBTd2l0emVybGFuZAoK ICAgUGhvbmU6ICs0MSAyMiA3MzAgNjM1NgogICBFbWFpbDogaGlyb3NoaS5vdGFAaXR1LmludAoK CgoKCgoKT3RhICAgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE1heSAzMSwgMjAxOCAgICAg ICAgICAgICAgICAgIFtQYWdlIDVdCg== --_004_7485c1030d0f4a59b3099226440ab3c6TUCM03TUECSPUNICCORG_-- From nobody Tue Nov 28 07:03:33 2017 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 C95FC12711E for ; Tue, 28 Nov 2017 07:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 9X-4qxtrkIEr for ; Tue, 28 Nov 2017 07:03:17 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 35701126E01 for ; Tue, 28 Nov 2017 07:03:17 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 0DB8B282914; Tue, 28 Nov 2017 16:03:15 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 077FE282BB4; Tue, 28 Nov 2017 16:03:15 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id 00E96282914; Tue, 28 Nov 2017 16:03:15 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id F2014642A7A1; Tue, 28 Nov 2017 16:03:14 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id EE7CC40068; Tue, 28 Nov 2017 16:03:14 +0100 (CET) Date: Tue, 28 Nov 2017 16:03:14 +0100 From: Stephane Bortzmeyer To: "OTA, Hiroshi" Cc: "urn@ietf.org" , "TSB SG15 Secretariat, ITU" Message-ID: <20171128150314.eawo5ilgp6jy3k6x@nic.fr> References: <7485c1030d0f4a59b3099226440ab3c6@TUCM03.TUECSP.UNICC.ORG> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7485c1030d0f4a59b3099226440ab3c6@TUCM03.TUECSP.UNICC.ORG> X-Operating-System: Debian GNU/Linux 9.2 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000015, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.11.28.145115 Archived-At: Subject: Re: [urn] Request for the NID 'itu' for URN - draft-itu-urn X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 15:03:20 -0000 On Tue, Nov 28, 2017 at 02:57:46PM +0000, OTA, Hiroshi wrote a message of 313 lines which said: > I would like to submit the attached Internet-Draft "URN Namespace > for ITU" (draft-itu-urn.txt) Unless you want a prior examination by this list (it is not mandatory, and your draft seems OK), the normal way to submit is through the datatracker From nobody Tue Nov 28 07:41:03 2017 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 AA7101242EA for ; Tue, 28 Nov 2017 07:41:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 lHF4V4W0_EQL for ; Tue, 28 Nov 2017 07:40:59 -0800 (PST) Received: from itu4out.svc.unicc.org (itu4out.svc.unicc.org [206.155.102.67]) (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 BBEEE1270B4 for ; Tue, 28 Nov 2017 07:40:59 -0800 (PST) Received: from TUCM02.TUECSP.UNICC.ORG (unknown [10.81.6.71]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iccpfxor04.svc.unicc.org (Postfix) with ESMTPS id 74334603C6; Tue, 28 Nov 2017 15:40:58 +0000 (UTC) Received: from TUCM03.TUECSP.UNICC.ORG (10.81.38.70) by TUCM02.TUECSP.UNICC.ORG (10.81.6.71) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 28 Nov 2017 15:40:57 +0000 Received: from TUCM03.TUECSP.UNICC.ORG ([10.81.38.70]) by TUCM03.TUECSP.UNICC.ORG ([10.81.38.70]) with mapi id 15.00.1293.002; Tue, 28 Nov 2017 15:40:57 +0000 From: "OTA, Hiroshi" To: Stephane Bortzmeyer CC: "urn@ietf.org" , "TSB SG15 Secretariat, ITU" Thread-Topic: Request for the NID 'itu' for URN - draft-itu-urn Thread-Index: AdNoV/8WE67UFRnVRBmdA4tA0JzgMwAAgR4AAAFEioA= Date: Tue, 28 Nov 2017 15:40:56 +0000 Message-ID: <1a24092a3d13485a93cf04e862486d26@TUCM03.TUECSP.UNICC.ORG> References: <7485c1030d0f4a59b3099226440ab3c6@TUCM03.TUECSP.UNICC.ORG> <20171128150314.eawo5ilgp6jy3k6x@nic.fr> In-Reply-To: <20171128150314.eawo5ilgp6jy3k6x@nic.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.81.64.103] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [urn] Request for the NID 'itu' for URN - draft-itu-urn X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 15:41:02 -0000 Thank you Stephane. I will submit my I-D through the datatracker. Regards, Hiroshi -----Original Message----- From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr]=20 Sent: Tuesday, November 28, 2017 16:03 To: OTA, Hiroshi Cc: urn@ietf.org; TSB SG15 Secretariat, ITU Subject: Re: Request for the NID 'itu' for URN - draft-itu-urn On Tue, Nov 28, 2017 at 02:57:46PM +0000, OTA, Hiroshi wrote a message of 313 lines which said: > I would like to submit the attached Internet-Draft "URN Namespace for=20 > ITU" (draft-itu-urn.txt) Unless you want a prior examination by this list (it is not mandatory, and = your draft seems OK), the normal way to submit is through the datatracker <= https://datatracker.ietf.org/submit/> From nobody Tue Nov 28 08:10:44 2017 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 923321286AB for ; Tue, 28 Nov 2017 08:10:11 -0800 (PST) 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, 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 r4_phMAF0Nmw for ; Tue, 28 Nov 2017 08:10:08 -0800 (PST) Received: from bsa2.jck.com (ns.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 681991286B1 for ; Tue, 28 Nov 2017 08:10:08 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1eJiSU-00089i-HF; Tue, 28 Nov 2017 11:10:06 -0500 Date: Tue, 28 Nov 2017 11:10:00 -0500 From: John C Klensin To: "OTA, Hiroshi" , urn@ietf.org cc: "TSB SG15 Secretariat, ITU" Message-ID: In-Reply-To: <7485c1030d0f4a59b3099226440ab3c6@TUCM03.TUECSP.UNICC.ORG> References: <7485c1030d0f4a59b3099226440ab3c6@TUCM03.TUECSP.UNICC.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@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] Request for the NID 'itu' for URN - draft-itu-urn X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 16:10:12 -0000 Hiroshi, Having skimmed very quickly through the draft (warning: I have not studied it carefully), a few observations/suggestions. First, we have updated and replaced the registration procedures described in the drafts you cite with those of RFC 8141. You should look at that document, which will actually make things easier for you, and update your draft accordingly. One of the procedural changes is that, as a recognized standards developer, the ITU need not post an I-D or publish an RFC in order to register a URN namespace and NID if you refer to publish and maintain the relevant documents yourselves. In general, ITU just decides what is best for its needs, documents it appropriately, and then requests the registration, with input from the IETF being largely advisory. Details are in RFC 8141. Should you want to move ahead with RFC publication, see Stephane's note for instructions on posting the Internet Draft. I do have one more substantive concern after having skimmed the draft. While I think what you have proposed appears to be reasonable, I think we would expect that anything that covers registrations from all three Sectors should be submitted from or endorsed by the office of the Secretary General rather than appearing to come from ITU-T or a single ITU-T SG alone. It seems to me that formal recognition from the Central Secretariat would protect ITU-T, as well as IETF and IANA, from any possible future misunderstandings. thanks and regards, john --On Tuesday, November 28, 2017 14:57 +0000 "OTA, Hiroshi" wrote: > Dear all, > > I would like to submit the attached Internet-Draft "URN > Namespace for ITU" (draft-itu-urn.txt) for requesting the > Namespace Identifier (NID) 'itu' for Uniform Resource Names > (URNs) used to identify resources published by the ITU > (International Telecommunication Union). > > Thank you. > Hiroshi > > --- > Hiroshi OTA, Advisor, ITU-T SG15 > International Telecommunication Union > Place des Nations CH-1211 Geneva 20 Switzerland > Tel: +41 22 730 6356 > Fax: +41 22 730 5853 > E-mail: hiroshi.ota@itu.int > >