Re: [urn] Request for urn mrn

Kasper Nielsen <kasperni@gmail.com> Mon, 16 October 2017 14:42 UTC

Return-Path: <kasperni@gmail.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 D5A6913301E for <urn@ietfa.amsl.com>; Mon, 16 Oct 2017 07:42:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qp6VY9ztr6Ve for <urn@ietfa.amsl.com>; Mon, 16 Oct 2017 07:42:41 -0700 (PDT)
Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::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 8C0FB132320 for <urn@ietf.org>; Mon, 16 Oct 2017 07:42:41 -0700 (PDT)
Received: by mail-vk0-x22f.google.com with SMTP id k123so7820724vkb.3 for <urn@ietf.org>; Mon, 16 Oct 2017 07:42:41 -0700 (PDT)
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=1O1s6tEqXA9Ur+oZsyxIjwgf8hvBE7zsmzIxx7l8Lto=; b=F1nUvluoHik3zVVB+r3XpKGwDt2wym63IYhWhT6EagGB2FBW73XcCTQUH7GkzZ/goT lXlUEp8b+n5ajxQjv39I8mDPSWo/v/ZqpiP2jdvvaopkVSWzNes3cAVrorvJI+ULphTJ HXm1Uhd01QVvcxdtBYrsm99DALFmnaQre9Jb3iYn9ZWC62dXLfplUssOjFU4db3Jaw0l EvrH7+OqLKCVspSKeI4c3KucTBx8f52mswDu2UwP6gZJa/qxJcjSvAOZWvXQnsNaScIB Rnq1lD6zcmoGEIkW7hh6ptjDREVE2vT7lb6a5lUBoM1CzxN3loN6VDVFrJ+Z2v6gY4fX 1QKQ==
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=1O1s6tEqXA9Ur+oZsyxIjwgf8hvBE7zsmzIxx7l8Lto=; b=qgYPtAWkavp07b4XhydWpIFiN4eeD0wlnU6uytGqeweIeJhGPOKbfNyxyzsvTsxcFw cL825ygvBoqpxh9tXvYEDLnWHtEcjqvwyXwKn0rd/e1NHY/i90AJBS89beNMq6bjNbxu 9tU/4MDIZ0IzzErMPxkDqCoGeEYc6fO1ad11Wdbt42fkNV5fiYAtotbkjDlBSVPNNUPo akq81sF7aEy7oC18xLxx2o0zp+vyuJ7Drw+cOlzaitGXsdEXXA5tm65w63rFwju5zAKx HWPjURsEYOukdlzgL3qkvsrYDAZ6EAxRzQ8L8kdjKuDARnAOIF0Wc1RwhUFDjh91+t9L 5jmQ==
X-Gm-Message-State: AMCzsaXyYVA5p8sftWj57ey6zk62ThvS+sjXoTEUPaXb0bDU1hyifnO8 lw/wXxTm/lhj3TobGCZrx/JKVTZmvR4vEWGKE9s=
X-Google-Smtp-Source: ABhQp+QjornA8lEwGmXug7bxLHQA8lGXdYaLeq0+kLn7cyY9yEMvRa6quWD8/JhZsWSbAv65gUHyOxYpUVkLbWbehao=
X-Received: by 10.31.67.151 with SMTP id q145mr644458vka.84.1508164960400; Mon, 16 Oct 2017 07:42:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.27.82 with HTTP; Mon, 16 Oct 2017 07:42:39 -0700 (PDT)
In-Reply-To: <24637769D123E644A105A0AF0E1F92EF010D31E7A1@dnbf-ex1.AD.DDB.DE>
References: <24637769D123E644A105A0AF0E1F92EF010D31E7A1@dnbf-ex1.AD.DDB.DE>
From: Kasper Nielsen <kasperni@gmail.com>
Date: Mon, 16 Oct 2017 16:42:39 +0200
Message-ID: <CAPs6152OFgGaMmccyH8ZUrZaBYB9sTJMGELN74nA7_o=-bDmmQ@mail.gmail.com>
To: "Svensson, Lars" <L.Svensson@dnb.de>
Cc: "urn@ietf.org" <urn@ietf.org>
Content-Type: multipart/alternative; boundary="001a114dae42ba3c63055bab04aa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/zoRt5ObsHXePvVOV14Ui3FfeTAE>
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: Mon, 16 Oct 2017 14:42:44 -0000

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 assigned
> twice. In the "Assignment" section you write that "Management of
> Organization-Specific Namespace IDs should be done in    accordance to the
> 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.org
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 says:
> "The namespace, “mrn”, is case-insensitive in processing but is
> conventionally written in lower case" but that's about all. Since much of
> 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 be
> converted to lower case. If you can have such a rule for the OID, too, it
> 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 the
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