[urn] Approval process for new URNs based on non-IETF standards
John C Klensin <john-ietf@jck.com> Sun, 13 September 2015 17:51 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BDD1B56CD for <urn@ietfa.amsl.com>; Sun, 13 Sep 2015 10:51:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.79
X-Spam-Level:
X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 lyU63oDBDAJO for <urn@ietfa.amsl.com>; Sun, 13 Sep 2015 10:51:05 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665811B56C8 for <urn@ietf.org>; Sun, 13 Sep 2015 10:51:05 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1ZbBQd-000NyX-QA for urn@ietf.org; Sun, 13 Sep 2015 13:51:03 -0400
Date: Sun, 13 Sep 2015 13:50:58 -0400
From: John C Klensin <john-ietf@jck.com>
To: urn@ietf.org
Message-ID: <65C29163B6F527DF836969A9@JcK-HP8200.jck.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/oR6NYgd0QK0qWD_44kbIYH5_2Yc>
Subject: [urn] Approval process for new URNs based on non-IETF standards
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 13 Sep 2015 17:51:07 -0000
Hi. A recent request to register a URN associated with an external standard involving a scientific community whose work lies well outside the normal scope and expertise of the IETF brought up an issue that I think we briefly discussed on-list but that never made it into 2141bis. The current particular issue involves draft-blanchet-ccsds-urn-00.txt (A Uniform Resource Name (URN) Namespace for the Consultative Committee for Space Data Systems (CCSDS)) about which Barry wrote the WG earlier today. In the most general scenario of interest, a URN registration request arrives from some specialized scientific or professional community. The IETF, and experts it designates, are generally not in a good position to evaluate the request on the basis of its subject matter. We might offer advice about formats or URN-specific issues but, ultimately, the right place to make the decisions about the substantive matters and any tradeoffs is in the relevant community, not the IETF. Unfortunately, lack of knowledge has never prevented the IETF community from having opinions and expressing them loudly. That can lead to frustration and impatience on the part of the submitting organization, reactions that, in turn, tend to discourage registrations. We encountered a similar issue in thinking about media types and developed the idea of delegating most of the responsibility in such situations to "recognized standards-related organization" (see Section 3.1 of RFC 6838 for the current version, but variations on the idea go back many years). Adapting that model to URNs seems wise to me. If there is agreement about that as a principle, I suggest we make approximately the following changes to Section 7 or draft-ietf-urnbis-rfc2141bis-urn-12 (or equivalent, if Peter gets -13 finished before agreement is reached on this): ----------- (1) At the end of Section 7.1, add: "While the registration templates are the same, slightly different procedures are used depending on the source of the registration." (2) Change the title of Section 7.2 to "Registration Policy and Process: Community Registrations". (3) Add a new Section 7.3, titled "Registration Policy and Process: Fast Track for Recognized Standards Development Organizations and Scientific Societies" that reads: The IETF recognizes that situations will arise in which URN namespaces will be created to either embed existing and established standards or to reflect scientific knowledge, terminology, or information organization that lie well outside the IETF's scope or the likely subject matter knowledge of its Designated Experts. In situations in which the registration request originates from, or is authorized by, a recognized standards-related organization or scientific society, a somewhat different procedure is available at the option of that body: 1. The namespace registration template is filled out and submitted as in steps 1 and 2 above. 2. A specification is required that reflects of points to the needed external standards or specifications. Publication in the RFC Series or through an IETF process (e.g., posting as an Internet Draft) is not expected and would be appropriate only under very unusual circumstances. 3. The reviews on the discussion list and by the designated experts are, however, strictly advisory, with the decisions about what advice to accept and the length of time to allocate to the process strictly under the control of the external body. 4. When that body concludes that the application is sufficiently mature, they will request that IANA will complete the registration for the NID and IANA will do so. A similar model is available for recognized standards-related organizations registering Media Types. The document describing that mechanism [RFC6838] provides somewhat more information about the general concept. (4) Renumber Section 7.3 and its subsections as appropriate. (5) Add the following sentence to Section A.4: If the registrant is a recognized standards development organization or scientific society requesting the fact track registration procedure (See Section 7.3), that information should be clearly indicated in this section of the template. ----------- If this model is adopted, draft-ietf-urnbis-ns-reg-transition will probably need some tuning but we can deal with that when appropriate. john
- [urn] Approval process for new URNs based on non-… John C Klensin
- Re: [urn] Approval process for new URNs based on … Peter Saint-Andre - &yet
- Re: [urn] Approval process for new URNs based on … Martin J. Dürst
- Re: [urn] Approval process for new URNs based on … John C Klensin
- Re: [urn] Approval process for new URNs based on … Peter Saint-Andre