Re: [urn] Request for urn mrn

Peter Saint-Andre <stpeter@stpeter.im> Tue, 07 November 2017 17:27 UTC

Return-Path: <stpeter@stpeter.im>
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 <urn@ietfa.amsl.com>; 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 <urn@ietfa.amsl.com>; 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 <urn@ietf.org>; 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: <xms:Be0BWqrKWGFXPUw6hFHndVrjAhzt6hhvDvQtxpqRn5s8J17DJJHUSw>
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 <kasperni@gmail.com>, urn@ietf.org
References: <24637769D123E644A105A0AF0E1F92EF010D31E7A1@dnbf-ex1.AD.DDB.DE> <CAPs6152OFgGaMmccyH8ZUrZaBYB9sTJMGELN74nA7_o=-bDmmQ@mail.gmail.com> <CAPs6152KjkA6DW9hyDwmY3r_LHWvMsWF1sN-Nmojkgj2MfvGbQ@mail.gmail.com>
From: Peter Saint-Andre <stpeter@stpeter.im>
Message-ID: <208e8f14-a29a-1413-aa4f-a9b6c52dc134@stpeter.im>
Date: Tue, 07 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: <CAPs6152KjkA6DW9hyDwmY3r_LHWvMsWF1sN-Nmojkgj2MfvGbQ@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="wOjqOGvLDeXbLtJqKQQqsKBQlq90sRgTk"
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/nCFX5iOfhSylDsWvhg2NaewznzU>
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 <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Nov 2017 17:27:36 -0000

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.

> Do we need
> to do something on our side?

Your textual changes look good to me. I have only two small comments...

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

   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