Re: [urn] Request for urn mrn

John C Klensin <john-ietf@jck.com> Tue, 07 November 2017 22:22 UTC

Return-Path: <john-ietf@jck.com>
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 <urn@ietfa.amsl.com>; 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 <urn@ietfa.amsl.com>; 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 <urn@ietf.org>; 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 <john-ietf@jck.com>) 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 <john-ietf@jck.com>
To: Peter Saint-Andre <stpeter@stpeter.im>, Kasper Nielsen <kasperni@gmail.com>
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> <CAPs6152OFgGaMmccyH8ZUrZaBYB9sTJMGELN74nA7_o=-bDmmQ@mail.gmail.c om> <CAPs6152KjkA6DW9hyDwmY3r_LHWvMsWF1sN-Nmojkgj2MfvGbQ@mail.gmail.com> <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: <https://mailarchive.ietf.org/arch/msg/urn/C28qDWQKLmq-1ziQ1IRONMXf-H8>
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 22:22:01 -0000

Concur.
   john


--On Tuesday, November 7, 2017 10:27 -0700 Peter Saint-Andre
<stpeter@stpeter.im> 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.
> 
>> 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
>