From nobody Mon Mar 3 00:59:55 2014 Return-Path: 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 7C1711A0643 for ; Mon, 3 Mar 2014 00:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 U-DMljM-Piz1 for ; Mon, 3 Mar 2014 00:59:50 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 78C4F1A0349 for ; Mon, 3 Mar 2014 00:59:42 -0800 (PST) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s238xbbq020601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 3 Mar 2014 10:59:38 +0200 Message-ID: <53144479.2080304@helsinki.fi> Date: Mon, 03 Mar 2014 10:59:37 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: urn@ietf.org References: <52FB9D0C.3070508@stpeter.im> <1B1D296F042C7A4C9A15F2E8@JcK-HP8200.jck.com> In-Reply-To: <1B1D296F042C7A4C9A15F2E8@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/vyKPr7A7vIPVS5q3y6t59dDgo8g Subject: Re: [urn] ISSNs, ISBNs, and automatic definition upgrading X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 08:59:54 -0000 Hello, A few comments below. On 28.2.2014 22:15, John C Klensin wrote: > The other note I promised... > > --On Wednesday, February 12, 2014 09:10 -0700 Peter Saint-Andre > wrote: > >> 5. This text might be slightly ambiguous: >> >> For both ISSN and ISBN URNs, it is intended that the >> registrations >> track the evolution of ISO standardization without >> requiring >> resubmission of the templates or other formal IETF or IANA >> registration update approval procedures. >> >> I assume that refers to the current registrations, not any >> future registrations. > As I said, this needs WG thought and input. > > As we have seen with the revisions that specified the longer > identifiers for ISBNs, these underlying ISO standards change. There are other ISO identifiers which are about to change. For instance, a thorough revision of ISRC, International Standard Recording Code, has just started. And another revision of ISBN is already under way. So we may expect that even if (ISO) identifiers themselves are persistent (they will last for centuries), the identifier standards themselves will be regularly tweaked for various reasons. > The good news is that, at least in my opinion, changes that > would make older identifiers invalid are just not going to > happen: they would be extremely disruptive and costly to a > community that is very dependent on stability over periods the > IETF has trouble thinking about. Usually, every identifier that has been assigned according to the old version of the standard remains valid. However, there are exceptions to this rule. ISBN-13 allows two different practices as regards the use of old ISBN-10s. They may be kept as is (library preference) or they may be converted to ISBN-13 format. In practice, I've seen books (reprints of books which were first published during ISBN-10 era) which have both ISBN-10 and ISBN-13, or more precisely, the same ISBN number in two formats. New ISRC standard, if approved, may make invalid some old ISRC identifiers. So far, ISRC assignment has been very decentralized, but there has been no global ISRC database. Therefore a single recording may have received multiple ISRCs. The idea is to validate existing ISRCs by harvesting them and related metadata into an international ISRC database. If a recording has two or more ISRCs, only one of them will be approved and others deprecated. But these deprecated ISRCs will never be reassigned and most likely they will still be included in the metadata of the recording, so from the users' point of view even these ISRCs are still actionable. However, even when the identifier community changes things (the identifier assignment process, the identifier syntax, etc.) everything will be done to make sure that even the deprecated identifiers will remain actionable. This principle also applies to errors; if a book has a typo in the ISBN number, it is possible to find the book with that ISBN, although the correct number has been assigned later. > My instinct is to trust that > and allow a registration that does not require revision or > updating to move from one version of an underlying ISO standard > for the identifier to another. The current reference version > of the underlying standard, syntax, assignment rules, etc., are > what ISO says they are with no IETF, Expert, or registrant > action being required (even though I'm sure we would welcome > explanatory updates). Some modifications to identifier standards may have no impact on existing URN namespace registrations. But only the identifier community itself will know if this is the case. However, most ISO identifier standard updates I've seen have been non-trivial from URN point of view. Even if the standard remains the same, there may be a need to update the registration. For instance, the designated contact person or his/her contact information may change, and namespace related documentation may be updated. It should be possible to make these editorial changes "any time". > > I don't know whether that generalizes beyond ISSNs and ISBNs > (and, maybe, if the IAB decides to go in that direction, the > ISO version of DOIs). We would certainly want to have a very > serious discussion if someone wanted to register a URN > namespace that was dependent on a possibly more volatile set of > references. Most URN namespace registrations will require less maintenance than ISBN and ISSN. For instance, there is no NBN standard except RFC 3188 so there is no "external pressure" to revise the namespace registration. The scope and syntax of NBN are intentionally relaxed, and there is no need to make the specification more precise. As an aside, as identifiers DOI (and Handle) are NBN-like broad umbrella systems. These identifiers can be applied to almost any resource out there. "Digital object identifier" actually means "digital identifier to all kinds of objects". > But, for this case, it makes sense to me and would > eliminate possible uncertainties between the time an ISO > standard is updated and published and when someone gets around > to updating the URN registration. Experience leds me to hate > those sorts of timing dependencies, especially when they can be > avoided. > > So, two questions (I'll try to interpret the answers, but the > decision about agreement, as I noted earlier, belongs to Andy): > > (1) Does the WG agree with my analysis and believe that having > the registration based on the "current version" of the ISO > standard, whatever that version is at a given time, is wise? Yes, for ISO and any other identifier standards. And I don't see a good alternative to this approach, based on my practical experiences on how the ISO identifiers have developed during the last 20 years. > > (2) If so, how should this be said? Note that it might (or > might now) require some tuning to 3507bis to get an explicit > statement in the registration template as to whether the > referenced external standard is the version as of some specific > date (and/or version number) or whether it always follows the > versions of the external standard as I'm suggesting here. RFC3406bis should make it more clear that that if the namespace is being registered for a de jure standard identifier, the name and version of the standard shall be specified in the Purpose section of the registration. This is important since many other things (such as the scope of the identifier, syntax of the identifier string, identifier assignment process, technical basis for resolution process) are based on the identifier system AND its version. It might be useful to provide in RFC3406bis examples of circumstances when the revision of the registration is recommended or even required. These include: 1. Changes in the registrant information (new contact person or change in the address info) 2. Substantial changes in the documentation (such as a new user guide) 3. Changes in the purpose, syntax, assignment or resolution of the identifier For instance, the planned new ISRC would require an update to the (currently non-existing) ISRC namespace registration due to the possibility of resolving URN:ISRCs in the global ISRC database required by the new version of the standard. IMO for cases 1 & 2 above, formal update of the registration via the review process should not be necessary since the changes are just editorial. Case 3 is different; for instance, if the purpose (scope) of the identifier changes, a review by designated experts is necessary, especially if the new extended scope overlaps with that of one of more existing namespaces. Another issue which requires consideration is a syntax change which makes it necessary to alter the resolution process. IETF and ISO TC 46 have established a liaison. This will enable IETF to keep an eye on the revision of those ISO identifiers which have URN namespaces, and - if the suggested new versions of these identifiers are problematic from the URN point of view - provide guidance on how the situation could be improved. Best regards, Juha > > thanks, > john > > > > > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Mon Mar 3 02:28:04 2014 Return-Path: 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 802461A0E6F; Mon, 3 Mar 2014 02:28:02 -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] 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 iOrueuVSCPEV; Mon, 3 Mar 2014 02:28:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F3D1A0E5B; Mon, 3 Mar 2014 02:28:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140303102800.5806.56513.idtracker@ietfa.amsl.com> Date: Mon, 03 Mar 2014 02:28:00 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/eKaNV83kc5JnvrUCbowrtoRel30 Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-ns-reg-transition-02.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 10:28:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names, Revised Working Group of the IETF. Title : Uniform Resource Name (URN) Namespace Registration Transition Authors : John C Klensin Juha Hakala Filename : draft-ietf-urnbis-ns-reg-transition-02.txt Pages : 7 Date : 2014-03-03 Abstract: The original registration procedure for formal Uniform Resource Name (URN) namespaces required IETF Consensus. That requirement discouraged some registrations and increased the risk for problems that could occur as a result. The requirements have now been changed in [[RFC 3406bis]] to adopt a different model. This document specifies IANA instructions to adapt selected existing registrations to the new model. It also obsoletes some previous RFCs to eliminate any ambiguity about the status of new templates and updated registrations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-urnbis-ns-reg-transition/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-urnbis-ns-reg-transition-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-ns-reg-transition-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 3 12:37:10 2014 Return-Path: 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 E92C01A00AB for ; Mon, 3 Mar 2014 12:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.254 X-Spam-Level: X-Spam-Status: No, score=-1.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=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 BYHnZKIn7gwh for ; Mon, 3 Mar 2014 12:37:06 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id A85041A0151 for ; Mon, 3 Mar 2014 12:37:06 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id s23Kan9v019972 for ; Mon, 3 Mar 2014 15:36:51 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id s23Kahu86146506 for ; Mon, 3 Mar 2014 15:36:43 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id s23Kahsi6151234; Mon, 3 Mar 2014 15:36:43 -0500 (EST) Date: Mon, 3 Mar 2014 15:36:43 -0500 (EST) Message-Id: <201403032036.s23Kahsi6151234@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: urn@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/urn/oU0Q5MLm0qMQjWb2Zh0IaOYoAOo Subject: [urn] URN NIDs for private enterprises X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 20:37:09 -0000 This is an idea that I floated in a previous message to urn-nid while we were discussing a NID request from a business. I want to extract it and present it as a stand-alone message so I can get more feedback on the idea. I've just joined the URN mailing list, so I'm not up on the discussions of the revisions of the URN RFCs. Perhaps this issue has been dealt with already. The question is, "What do we do if an enterprise (business or other private organization) wants to have a NID of its own?" ("Enterprise" is used as a generic term for organizations in RFC 2578 and the IANA registry of "private enterprise numbers" (https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers).) I feel that this raises several questions which I have not seen involved in other NID definitions: - Because the registrant is a single enterprise, it would be desirable if the delegation was done under a policy that was explicitly even-handed toward all enterprises that might want a delegation. - There are a *lot* of potential enterprise registrants, leading to the possibility of "NID pollution", filling the registry with names to the point that new names that are meaningful would be difficult to assign. - Enterprises will likely desire an NID based on the enterprise's name, making it harder to resolve conflicts regarding desired NIDs. It seems to me that a good way to address these issues is to create a single NID whose sub-NIDs are delegated to enterprises. I can see at least three ways to handle all enterprises in a systematic way: - urn:enterprise:: This technique uses the existing private enterprise numbers to identify the enterprise. - urn:enterprise:: This technique would create a new registry, from which enterprises would allocate identifiers on a first-come basis. The syntax of would probably be the same as in RFC 2141. - urn:enterprise:: This technique uses the enterprise's domain name. (There are a bunch of details that are needed to make domain names permanent. See draft-ietf-salud-alert-info-urns-11 for how to do it.) Using my consulting company (Ariadne Internet Services) as an example enterprise, these techniques would produce the following examples, assuming that the overall NID was "enterprise", using the different formats: - urn:enterprise:14490:nss - urn:enterprise:ariadne:nss - urn:enterprise:ariadne.com:nss, or urn:enterprise:ariadne.com(2012-01-01):nss If we wanted to be terse, we could assign the NID "e", giving these examples: - urn:e:14490:nss - urn:e:ariadne:nss - urn:e:ariadne.com:nss, or urn:e:ariadne.com(2012-01-01):nss Comments? Dale From nobody Tue Mar 4 01:11:13 2014 Return-Path: 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 ED07C1A0414 for ; Tue, 4 Mar 2014 01:11:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 70eGiA7Z65cS for ; Tue, 4 Mar 2014 01:11:10 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id CBA2E1A0413 for ; Tue, 4 Mar 2014 01:11:09 -0800 (PST) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1WKlNS-0008Co-GL; Tue, 04 Mar 2014 04:11:06 -0500 Date: Tue, 04 Mar 2014 04:11:05 -0500 From: John C Klensin To: "Dale R. Worley" , urn@ietf.org Message-ID: <2249FE78B14F524552546F8E@JcK-eee10.meeting.ietf.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 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/8VWx1CDRFX7vxsg6rX8uSsRHUbY Subject: Re: [urn] URN NIDs for private enterprises X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 09:11:12 -0000 --On Monday, 03 March, 2014 15:36 -0500 "Dale R. Worley" wrote: > This is an idea that I floated in a previous message to > urn-nid while we were discussing a NID request from a > business. I want to extract it and present it as a > stand-alone message so I can get more feedback on the idea. > I've just joined the URN mailing list, so I'm not up on the > discussions of the revisions of the URN RFCs. Perhaps this > issue has been dealt with already. > > The question is, "What do we do if an enterprise (business or > other private organization) wants to have a NID of its own?" > > ("Enterprise" is used as a generic term for organizations in > RFC 2578 and the IANA registry of "private enterprise numbers" > (https://www.iana.org/assignments/enterprise-numbers/enterpris > e-numbers).) > Dale, For reasons that should be clear if you review the archives (or that I'm happy to review f2f), I'm a little reluctant to institutionalize sub-NIDs, especially sub-NID trees that are managed by IANA rather than the registrant. To summarize the non-technical part, I think it would lead us down the same path that the DNS has gone since ICANN took over, e.g., demands to use "example." rather than "example.foo." and "example:" rather than " "enterprise:example:". I'm not sure what you intend from your examples but, if there is any hint of claiming equivalence between "enterprise:ariadne:" and "enterprise:14490:", that is a whole different can of worms. Use of the first would embroil IANA in the whole trademark mess about which ICANN has given us a lot of education. The day someone on that side of the gap decided that enterprise names could be profitably monetized or used in an extortion scheme.. well, we just don't want to go there. Counter-suggestion, which keeps the process lightweight: we break the "informal" (urn-NNNN:) URN space into blocks so that, for example, the range from 1 - 9999 (or 1-999999 if we are really nervous and want to be cautious) dedicated to sequentially-assigned "informal" spaces as specified in the current versions of 3407bis. Values above that may be obtained by: (i) Obtaining an enterprise number from that IANA registry. (ii) Requesting an informal namespace with NID urn: <10000 + enterprise-number>: or urn: <1000000 + enterprise-number>: from IANA. That is consistent with the general informal namespace model (and would require only a few extra sentences in 3406bis and no change to URN-handling applications). It just uses a second assignment model for a different range. IANA's URN workload for such namespaces doesn't take it into trademark or name-ownership territory (whatever the risks are in that area are in the existing enterprise number registry). An alternative with the same general theme would be to use the entire ISO-IANA-arc private enterprise number (see either RFC 2578 or the IANA registry at http://www.iana.org/assignments/enterprise-numbers/enterprise-numbers), giving you an NID of urn-1.3.6.1.4.1.14490 We'd have to sort out whether that syntax made sense and whether it would be disruptive elsewhere, but, with a few lines of additional specification, it would have the additional advantage of allowing anyone who was offended by needing to register in a tree associated with a US Government entity [1] could register in another tree of their choice and, at most, notify IANA that the URN form was going to be in use. That eliminates the need to split the informal space by ranges and eliminates the need for IANA to arbitrate uniqueness in anything but its own arc. Would that help? john [1] Incorporate the entire "Internet Governance" mess, and especially the "globalization of IANA" part (see Thursday "Internet Governance Update" session for some pieces) by reference. From nobody Tue Mar 4 01:26:43 2014 Return-Path: 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 AC09F1A0418 for ; Tue, 4 Mar 2014 01:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 kW9honfPpfEb for ; Tue, 4 Mar 2014 01:06:52 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 05C171A0414 for ; Tue, 4 Mar 2014 01:06:52 -0800 (PST) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1WKlJH-0008C5-Th; Tue, 04 Mar 2014 04:06:48 -0500 Date: Tue, 04 Mar 2014 04:06:47 -0500 From: John C Klensin To: "Dale R. Worley" , urn@ietf.org Message-ID: <91E799B74D3451FEEA8E9407@JcK-eee10.meeting.ietf.org> In-Reply-To: <201403032036.s23Kahsi6151234@shell01.TheWorld.com> References: <201403032036.s23Kahsi6151234@shell01.TheWorld.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 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/5aPWm--2rKPt_7C1KxaJpzA87Qc X-Mailman-Approved-At: Tue, 04 Mar 2014 01:26:41 -0800 Subject: Re: [urn] URN NIDs for private enterprises X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 09:06:56 -0000 --On Monday, 03 March, 2014 15:36 -0500 "Dale R. Worley" wrote: > This is an idea that I floated in a previous message to > urn-nid while we were discussing a NID request from a > business. I want to extract it and present it as a > stand-alone message so I can get more feedback on the idea. > I've just joined the URN mailing list, so I'm not up on the > discussions of the revisions of the URN RFCs. Perhaps this > issue has been dealt with already. > > The question is, "What do we do if an enterprise (business or > other private organization) wants to have a NID of its own?" > > ("Enterprise" is used as a generic term for organizations in > RFC 2578 and the IANA registry of "private enterprise numbers" > (https://www.iana.org/assignments/enterprise-numbers/enterpris > e-numbers).) > Dale, For reasons that should be clear if you review the archives (or that I'm happy to review f2f), I'm a little reluctant to institutionalize sub-NIDs, especially sub-NID trees that are managed by IANA rather than the registrant. To summarize the non-technical part, I think it would lead us down the same path that the DNS has gone since ICANN took over, e.g., demands to use "example." rather than "example.foo." and "example:" rather than " "enterprise:example:". I'm not sure what you intend from your examples but, if there is any hint of claiming equivalence between "enterprise:ariadne:" and "enterprise:14490:", that is a whole different can of worms. Use of the first would embroil IANA in the whole trademark mess about which ICANN has given us a lot of education. The day someone on that side of the gap decided that enterprise names could be profitably monetized or used in an extortion scheme.. well, we just don't want to go there. Counter-suggestion, which keeps the process lightweight: we break the "informal" (urn-NNNN:) URN space into blocks so that, for example, the range from 1 - 9999 (or 1-999999 if we are really nervous and want to be cautious) dedicated to sequentially-assigned "informal" spaces as specified in the current versions of 3407bis. Values above that may be obtained by: (i) Obtaining an enterprise number from that IANA registry. (ii) Requesting an informal namespace with NID urn: <10000 + enterprise-number>: or urn: <1000000 + enterprise-number>: from IANA. That is consistent with the general informal namespace model (and would require only a few extra sentences in 3406bis and no change to URN-handling applications). It just uses a second assignment model for a different range. IANA's URN workload for such namespaces doesn't take it into trademark or name-ownership territory (whatever the risks are in that area are in the existing enterprise number registry). An alternative with the same general theme would be to use the entire ISO-IANA-arc private enterprise number (see either RFC 2578 or the IANA registry at http://www.iana.org/assignments/enterprise-numbers/enterprise-numbers), giving you an NID of urn-1.3.6.1.4.1.14490 We'd have to sort out whether that syntax made sense and whether it would be disruptive elsewhere, but, with a few lines of additional specification, it would have the additional advantage of allowing anyone who was offended by needing to register in a tree associated with a US Government entity [1] could register in another tree of their choice and, at most, notify IANA that the URN form was going to be in use. That eliminates the need to split the informal space by ranges and eliminates the need for IANA to arbitrate uniqueness in anything but its own arc. Would that help? john [1] Incorporate the entire "Internet Governance" mess, and especially the "globalization of IANA" part (see Thursday "Internet Governance Update" session for some pieces) by reference. From nobody Wed Mar 5 07:30:50 2014 Return-Path: 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 8574B1A0119 for ; Wed, 5 Mar 2014 07:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 wYYHxskC4WMZ for ; Wed, 5 Mar 2014 07:30:42 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9960B1A04F6 for ; Wed, 5 Mar 2014 07:30:42 -0800 (PST) Received: from webmail-3.mappi.helsinki.fi (webmail-3.mappi.helsinki.fi [128.214.20.217]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s25FUYwA028029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Mar 2014 17:30:36 +0200 Received: from a88-114-107-213.elisa-laajakaista.fi (a88-114-107-213.elisa-laajakaista.fi [88.114.107.213]) by webmail.helsinki.fi (Horde Framework) with HTTP; Wed, 05 Mar 2014 17:30:34 +0200 Date: Wed, 05 Mar 2014 17:30:34 +0200 Message-ID: <20140305173034.Horde.Mbt3-roqZMua4xTHa3ABsw1@webmail.helsinki.fi> From: jehakala@mappi.helsinki.fi To: John C Klensin References: <52FB9D0C.3070508@stpeter.im> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H5 (6.1.6) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Archived-At: http://mailarchive.ietf.org/arch/msg/urn/chTvTepLsJHXdGJCVVecFhRln7Q Cc: urn@ietf.org Subject: Re: [urn] editorial comments on draft-ietf-urnbis-ns-reg-transition-01 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 15:30:46 -0000 Hello, Quoting John C Klensin : > Hi. > > > Observation from a participant in this WGs who thinks the work > is very important and who has some experience with how the IETF > works, but no official role in the WG other than being willing > to help with writing: When WG drafts are posted and met with > dead silence (or silence except from an extremely small number > of people, the usual IETF tendency is to assume that the WG is > dead, no one cares, and that, if it produces any work, that work > doesn't represent enough meaningful consensus to be moved > forward. In this case, these conclusions may be at least partially wrong. The organizations which currently use URNs or other persistent identifiers most actively do not normally participate actively in the IETF work. Therefore they may not follow what is going on, or they may just be lurking (I know several people who are doing exactly that. The eagerness to just lurk was strengthened when discussions on the list veered away from (what for instance we librarians) consider practical issues related to resource identification into more fundamental issues of what it means to use fragment and query in URNs and how that relates to the generic URI syntax. > Barry has been extremely patient, I think because he > shares my/our sense of importance, but I'm very concerned about > how we move forward this way. This is especially important > because a few of us have been thinking about a very radical move > to get the various issues of syntax, properties of the name or > named object versus things that can be done only after it is > retrieved, and so on unstuck. That move would be, IMO, > impossible without strong backing from the WG. Because just > raising it would probably stir up a lot of controversy, I (at > least) haven't even been willing to explain it on this mailing > list. It may be difficult not to bring these issues up eventually. The conclusions we have at least tentatively drawn are not exactly a perfect match with RFC 3986. Juha > > So, nay I ask (and recommend) that those of you who are reading > drafts, saying "seems ok" to yourselves, and moving on start > posting "I have read this and seems ok" (or "I have read it and > it is hopeless" if that is that better reflects your views) > notes to the list. And those of you who haven't been reading > drafts should start soon -- the silence will kill us, if not by > action from the IESG than by the authors giving up. > > Again, a few notes on Peter's comments below > > thanks, > john > > > --On Wednesday, February 12, 2014 09:10 -0700 Peter Saint-Andre > wrote: > >> Thanks to John and Juha for working on this document. Overall >> I think the substance is fine. Here are a few small editorial >> issues I noticed. >> >> 1. Expand URN on first use: >> ... >> 2. This is a bit awkward: >> ... >> 3. There's a stray word here: >> ... >> 4. A missing and: >> ... > >> 5. This text might be slightly ambiguous: >> >> For both ISSN and ISBN URNs, it is intended that the >> registrations >> track the evolution of ISO standardization without >> requiring >> resubmission of the templates or other formal IETF or IANA >> registration update approval procedures. >> >> I assume that refers to the current registrations, not any >> future registrations. > > Actually, I was trying to finesse a problem. This really needs > input from you and the read of the WG. Let me keep it separate > from the editorial issues by writing a separate note. > >> 6. This is a bit of a run-on sentence: >> ... >> 7. Typo here: >> ... >> 8. I sense some ambiguity here: >> >> IANA is requested to update the registry entries for URN >> ISSNs, >> ISBNs, and NRNs to reflect the new, RFC 3406bis-complaint >> templates >> as soon as they are available and to no longer reference >> the now- >> historic RFCs. Other registrations and templates >> conforming to the >> newer rules may be substituted for the older ones when >> they are >> available. However, neither this document nor RFC 3406bis >> invalidates existing registrations other than those listed >> above, so >> IANA needs to be prepared to maintain a registry whose >> contents >> reflect both old and new templates. >> >> I think "other registrations and templates" might be referring >> to registrations and templates for namespaces other than ISSN, >> ISBN, and NBN. > > Yes. And it needed to spelled out a bit more even where it > wasn't ambiguous. I've substituted your proposed sentence, > which is probably good enough. > > Suggestions for less tedious wording are welcome. > >> I think "supersedes" might be more appropriate than >> "invalidates". > > I really did mean "invalidate", partially because of aspects of > the ongoing "obsoletes" versus "historic" debate. In addition, > in theory this document or 3507bis could declare all existing > registrations invalid without any superceding documentation or > registration (in some sense, it does make tham obsolete because > the information required is different). We've decided (I > think) to not do that and I thought it was worth making > explicit. But I've changed the word to "supercedes". It can be > changed back if anyone feels strongly about it. > >> And I think "a registry whose contents reflect both old and >> new templates" does not imply that IANA would point to both an >> old and a new template for the same namespace, but for >> different namespaces. > > One would hope that, in the former case, a new NID would be > assigned. > >> Thus I suggest: >> >> IANA is requested to update the registry entries for URN >> ISSNs, >> ISBNs, and NBNs to reflect the new, RFC 3406bis-complaint >> templates >> as soon as they are available and to no longer reference >> the now- >> historic RFCs for those namespaces. With respect to >> namespaces >> other than those listed above, registrations and templates >> conforming to the newer rules may be substituted for the >> older ones >> when they are available. However, neither this document >> nor RFC >> 3406bis supersedes existing registrations other than those >> listed >> above. Therefore, IANA needs to be prepared to maintain a >> registry >> whose contents reflect old templates for some namespaces >> and new >> templates for other namespaces. > > Smoothed a bit but basically incorporated. > > Thanks for the careful reading, > john > > > > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Fri Mar 7 10:15:09 2014 Return-Path: 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 EC38C1A00A2 for ; Fri, 7 Mar 2014 10:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] 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 oz_S4Ml539vm for ; Fri, 7 Mar 2014 10:15:04 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id CCABC1A008B for ; Fri, 7 Mar 2014 10:15:03 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id s27IFeuF012704; Fri, 7 Mar 2014 13:15:43 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id s27IERFS6450496; Fri, 7 Mar 2014 13:14:27 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id s27IEMSg6438588; Fri, 7 Mar 2014 13:14:22 -0500 (EST) Date: Fri, 7 Mar 2014 13:14:22 -0500 (EST) Message-Id: <201403071814.s27IEMSg6438588@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: John C Klensin In-reply-to: <91E799B74D3451FEEA8E9407@JcK-eee10.meeting.ietf.org> (john@jck.com) References: <201403032036.s23Kahsi6151234@shell01.TheWorld.com> <91E799B74D3451FEEA8E9407@JcK-eee10.meeting.ietf.org> Archived-At: http://mailarchive.ietf.org/arch/msg/urn/oJQjPKnpISusO_CpYwbC46jbxtc Cc: urn@ietf.org Subject: Re: [urn] URN NIDs for private enterprises X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 18:15:07 -0000 I'll prepend this note that this discussion is not purely theoretical, it was triggered by the request by DTS, Inc. for a URN namespace with NID "dts" (naturally enough). Oddly, neither the specific proposal or my message summarizing the more general questions elicited any discussion (other than from myself and the registrant). I think that some feedback from the URN WG is in order, because otherwise the DTS URN proposal as it stands now is likely to pass by default. Dealing with a number of issues in no particular order: > From: John C Klensin > > For reasons that should be clear if you review the archives (or > that I'm happy to review f2f), The threads that I have found that are relevant are "[URN] WG last call: URN Namespace Definition Mechanisms" https://www.ietf.org/mail-archive/web/urn/current/msg01355.html "[URN] focus the question" https://www.ietf.org/mail-archive/web/urn/current/msg01334.html If you know of others, it might be worth pointing to them on this list. > I'm a little reluctant to > institutionalize sub-NIDs, especially sub-NID trees that are > managed by IANA rather than the registrant. I see that there has been considerable opposition to making URNs hierarchical. For example: | From: "Larry Masinter" | Date: Sat, 10 Oct 1998 22:21:31 PDT | | > The draft even clearly mentions the possibility of subdividing | > (partitioning) namespaces. | | draft-ietf-urn-nid-req-06.txt clearly mentions the possibility | of subdividing the name space in order to delegate the assignment | of uniqueness, as happens, for example, with ISBN numbers, where | each publisher is delegated the authority of keeping their part | of the name space unique. | | However, in the case of urn:us:ssn:001-101-4452 and | urn:us:ca:license:7URN123, this is not merely a delegation | for the purpose of uniqueness, but a separation of the namespace | into subspaces which will differ for every attribute in the | template given in draft-ietf-urn-nid-req-06.txt. | | If you go through the fields in the draft: | Registration Information | [...] | | It would seem that these can't be easily handled by having a | country-code URN namespace then having the country parcel it out | for country-unique spaces. I could imagine reserving the names | "xx-" for country xx, so that "us-ssn" would be recommended | over "ssn" to distinguish it from "dk-ssn", but I'd think that | each of these should be registered separately. On the other hand, | From: urn-list at faerber.muc.de (Claus AndrC) FC$rber) | Date: 10 Oct 1998 14:36:00 +0200 | | I don't think so. The propsed Mechanisms are so open that you could | certainly register a namespace that -- as a consistent set of features | -- is subdividable into several namespaces by the same rules. | | The draft even clearly mentions the possibility of subdividing | (partitioning) namespaces. And it's true that RFC 3406 "URN Namespace Definition Mechanisms" mentions partitioning: Possible answers include, but are not limited to: - exposition of the structure of the identifiers, and partitioning of the space of identifiers amongst assignment authorities which are individually responsible for respecting uniqueness rules > To summarize the > non-technical part, I think it would lead us down the same path > that the DNS has gone since ICANN took over, e.g., demands to > use "example." rather than "example.foo." and "example:" rather > than " > "enterprise:example:". > [1] Incorporate the entire "Internet Governance" mess, and > especially the "globalization of IANA" part (see Thursday > "Internet Governance Update" session for some pieces) by > reference. > Use of the first would embroil IANA in the whole trademark mess > about which ICANN has given us a lot of education. The day > someone on that side of the gap decided that enterprise names > could be profitably monetized or used in an extortion scheme.. > well, we just don't want to go there. > IANA's URN workload for > [informal] namespaces doesn't take it into trademark or name-ownership > territory (whatever the risks are in that area are in the > existing enterprise number registry). Yes, I can see the maze of problems that could arise if NIDs were assigned that were intended to match the names of ordinary commercial enterprises. > I'm not sure what you intend from your examples but, if there is > any hint of claiming equivalence between "enterprise:ariadne:" > and "enterprise:14490:", that is a whole different can of worms. In regard to equivalence per se, I have no intention to create "alternative spellings" when that can be avoided. It's true that there is no rule that one object/resource may not be named by multiple URNs, it's generally good to avoid that, excepting for "lexical equivalence" that can be specified by a closed algorithm (that is, one that does not need to reference a time-varying database, as the equivalence of "enterprise:ariadne" and "enterprise:14490" would). The various examples I gave were indended to be *exclusive* alternatives for how we might allocate URNs. > Counter-suggestion, which keeps the process lightweight: we > break the "informal" (urn-NNNN:) URN space into blocks so that, > for example, the range from 1 - 9999 (or 1-999999 if we are > really nervous and want to be cautious) dedicated to > sequentially-assigned "informal" spaces as specified in the > current versions of 3407bis. Values above that may be obtained > by: > > (i) Obtaining an enterprise number from that IANA registry. > (ii) Requesting an informal namespace with NID > urn: <10000 + enterprise-number>: > or > urn: <1000000 + enterprise-number>: > from IANA. > > That is consistent with the general informal namespace model > (and would require only a few extra sentences in 3406bis and no > change to URN-handling applications). It just uses a second > assignment model for a different range. Thanks for pointing me toward the informal NID group, as that largely has the semantics I'm looking for. I don't like the idea of "1000000 + enterprise-number", because people are likely to get it wrong, as well as using more characters than is necessary. Perhaps we could define a new group of informal NIDs, "ent-"? This would avoid the "add 10,000" problem without otherwise disturbing the semantics and registration procedures for informal NIDs. > An alternative with the same general theme would be to use the > entire ISO-IANA-arc private enterprise number (see either RFC > 2578 or the IANA registry at > http://www.iana.org/assignments/enterprise-numbers/enterprise-numbers), > giving you an NID of > urn-1.3.6.1.4.1.14490 > We'd have to sort out whether that syntax made sense and whether > it would be disruptive elsewhere, but, with a few lines of > additional specification, it would have the additional advantage > of allowing anyone who was offended by needing to register in a > tree associated with a US Government entity [1] could register > in another tree of their choice and, at most, notify IANA that > the URN form was going to be in use. That eliminates the need > to split the informal space by ranges and eliminates the need > for IANA to arbitrate uniqueness in anything but its own arc. If we're going to use OIDs, I would suggest we tell registrants that they should register an enterprise number and then they would be able to use OID-based URNs for their resources: urn:oid:1.3.6.1.4.1.14490.xxx.yyy.zzz That is already specified; essentially their enterprise number registration gets them an OID delegation, which allocates to them a URN sub-space. One question which I see is that there has generally been some opposition to registrations which say "I want to have a namespace, but I'm not going to tell you anything specific about its use." This tends to happen automatically if a NID is going to be partitioned into sub-NIDs, because the different sub-NIDs have different answers for the various registration questions: | From: "Larry Masinter" | Date: Tue, 13 Oct 1998 15:20:37 PDT | | [The NID registration] document asks the registrar of a namespace a | lengthy and detailed set of questions, which include questions about | the syntax, semantics, matching rules, uniqueness considerations, etc | etc. | | If the namespace owner actually intends to set up a bunch of delegated | namespaces that each individually have their own different answers to | each of those questions, and so answers each of the questions "it | depends on the sub-namespace I'll delegate", then what is the purpose | and use of having the form at all? But it turns out that a lot of NID registrations already have minimally-informative registrations. Of the first 10 registrations listed at http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml today, only one ("epc") provides any syntax (although a number only provide links to external documents, all of which 404). So in a sense, there's not much information that we genuinely require in a NID registration, and I think that it would be reasonable to have an automatic NID registration, derived from enterprise number assignment. Dale From nobody Sat Mar 8 11:02:02 2014 Return-Path: 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 117FB1A00BC for ; Sat, 8 Mar 2014 11:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 KT34stQqWpz2 for ; Sat, 8 Mar 2014 11:01:58 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BC30D1A026F for ; Sat, 8 Mar 2014 11:01:57 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CD1B2404AF; Sat, 8 Mar 2014 12:01:52 -0700 (MST) Message-ID: <531B691F.7090608@stpeter.im> Date: Sat, 08 Mar 2014 12:01:51 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Dale R. Worley" , John C Klensin References: <201403032036.s23Kahsi6151234@shell01.TheWorld.com> <91E799B74D3451FEEA8E9407@JcK-eee10.meeting.ietf.org> <201403071814.s27IEMSg6438588@shell01.TheWorld.com> In-Reply-To: <201403071814.s27IEMSg6438588@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/eUjwvZanaJ4DzxGLBWdWGVcc2RM Cc: urn@ietf.org Subject: Re: [urn] URN NIDs for private enterprises X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 19:02:01 -0000 On 3/7/14, 11:14 AM, Dale R. Worley wrote: > I'll prepend this note that this discussion is not purely theoretical, > it was triggered by the request by DTS, Inc. for a URN namespace with > NID "dts" (naturally enough). Oddly, neither the specific proposal or > my message summarizing the more general questions elicited any > discussion (other than from myself and the registrant). I think folks were busy with the IETF meeting and preparations for that. At least, I know I was! > I think that > some feedback from the URN WG is in order, because otherwise the DTS > URN proposal as it stands now is likely to pass by default. Side topic: I think it's confusing to have two lists for URN-related discussion. > If we're going to use OIDs, I would suggest we tell registrants that > they should register an enterprise number and then they would be able > to use OID-based URNs for their resources: > urn:oid:1.3.6.1.4.1.14490.xxx.yyy.zzz > That is already specified; essentially their enterprise number > registration gets them an OID delegation, which allocates to them a > URN sub-space. If we already have something that will work, I suggest we use it. > One question which I see is that there has generally been some > opposition to registrations which say "I want to have a namespace, but > I'm not going to tell you anything specific about its use." This > tends to happen automatically if a NID is going to be partitioned into > sub-NIDs, because the different sub-NIDs have different answers for > the various registration questions: > > | From: "Larry Masinter" > | Date: Tue, 13 Oct 1998 15:20:37 PDT > | > | [The NID registration] document asks the registrar of a namespace a > | lengthy and detailed set of questions, which include questions about > | the syntax, semantics, matching rules, uniqueness considerations, etc > | etc. > | > | If the namespace owner actually intends to set up a bunch of delegated > | namespaces that each individually have their own different answers to > | each of those questions, and so answers each of the questions "it > | depends on the sub-namespace I'll delegate", then what is the purpose > | and use of having the form at all? > > But it turns out that a lot of NID registrations already have > minimally-informative registrations. Of the first 10 registrations > listed at > http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml > today, only one ("epc") provides any syntax (although a number only > provide links to external documents, all of which 404). > > So in a sense, there's not much information that we genuinely require > in a NID registration, and I think that it would be reasonable to have > an automatic NID registration, derived from enterprise number > assignment. There are two topics here: (1) What we require for registration of a formal NID. Historically, registrants have needed to specify some public benefit, if you will, and to document their processes to some extent. That still seems beneficial to me. (2) What we require for (automatic?) registration of an enterprise NID. If these are truly private and not intended to be public in any way (although such things often leak out into the public space, see RFC 6648 for related considerations) then a less onerous registration process might be sensible. FWIW, then I worked at Cisco I had to actively stamp out usage of (private, internal) XML namespaces like urn:cisco:* - naive developers though they could create such things out of thin air. Discouraging such behavior would be a good thing. If "automatic" registration via the OID namespace identifier (RFC 3061) moves us in that direction, that might be helpful (but one reason people try to use URNs like "urn:cisco:*" even when the NID doesn't exist is that it seems so straightforward and developer-friendly). Peter From nobody Wed Mar 12 13:06:05 2014 Return-Path: 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 A81301A075E for ; Wed, 12 Mar 2014 13:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 YMwBbAqDLTgZ for ; Wed, 12 Mar 2014 13:06:01 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E88401A0756 for ; Wed, 12 Mar 2014 13:06:00 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 735F940455; Wed, 12 Mar 2014 14:05:54 -0600 (MDT) Message-ID: <5320BE21.8070406@stpeter.im> Date: Wed, 12 Mar 2014 14:05:53 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Dale R. Worley" References: <201403032036.s23Kahsi6151234@shell01.TheWorld.com> <91E799B74D3451FEEA8E9407@JcK-eee10.meeting.ietf.org> <201403071814.s27IEMSg6438588@shell01.TheWorld.com> <531B691F.7090608@stpeter.im> <201403121950.s2CJomP76660924@shell01.TheWorld.com> In-Reply-To: <201403121950.s2CJomP76660924@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/DPKjBgTrvt2sZ4A1NB04RDnrG9A Cc: john@jck.com, urn@ietf.org Subject: Re: [urn] URN NIDs for private enterprises X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 20:06:03 -0000 On 3/12/14, 1:50 PM, Dale R. Worley wrote: > In regard to providing a method for private enterprises to > automatically have a space of URNs: > >> From: Peter Saint-Andre >> Date: Sat, 08 Mar 2014 12:01:51 -0700 > >>> If we're going to use OIDs, I would suggest we tell registrants that >>> they should register an enterprise number and then they would be able >>> to use OID-based URNs for their resources: >>> [...] >> >> If we already have something that will work, I suggest we use it. > > That is sensible. It seems to me that you may have solved the problem > in another message: > >> Date: Tue, 11 Mar 2014 14:01:22 -0600 >> From: Peter Saint-Andre >> To: Joel Kalvesmaki >> Subject: Re: URN UUID question >> Archived-At: http://mailarchive.ietf.org/arch/msg/urn-nid/q9TdGA2GIMP-fCBuxc8-Me1IDYs >> Cc: urn-nid@ietf.org >> >> It sounds to me as if you might want to use the 'tag' URI scheme: >> >> https://tools.ietf.org/html/rfc4151 > > The "tag" scheme lets DTS, Inc. use URIs with the format (among others): > > tag:dts.com,2014:{pchar-string} > > which seems to me to solve all their practical problems. Formally, > they're URIs not URNs, but that seems (1) to have no practical > consequences, and (2) to avoid any philosophical problems regarding > uniqueness/persistence, public documentation, public syntax, public > benefit, etc. > > I've proposed this to the DTS people on urn-nid. Let's see what they > have to say. Thanks. The 'tag' scheme seems to fit the bill for a lot of folks, but folks don't know about it. Perhaps it needs a better marketing department. Peter From nobody Wed Mar 19 14:30:51 2014 Return-Path: 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 16E511A0538 for ; Wed, 19 Mar 2014 14:30:51 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 729p0VgJIRvh for ; Wed, 19 Mar 2014 14:30:49 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 315801A04BA for ; Wed, 19 Mar 2014 14:30:49 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta01.westchester.pa.mail.comcast.net with comcast id fU7Q1n0030vyq2s51ZWg0F; Wed, 19 Mar 2014 21:30:40 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta05.westchester.pa.mail.comcast.net with comcast id fZWf1n00Q1KKtkw3RZWfAC; Wed, 19 Mar 2014 21:30:40 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s2JLUcwq012142; Wed, 19 Mar 2014 17:30:38 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s2JLUcfH012141; Wed, 19 Mar 2014 17:30:38 -0400 Date: Wed, 19 Mar 2014 17:30:38 -0400 Message-Id: <201403192130.s2JLUcfH012141@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Peter Saint-Andre In-reply-to: <531B691F.7090608@stpeter.im> References: <201403032036.s23Kahsi6151234@shell01.TheWorld.com> <91E799B74D3451FEEA8E9407@JcK-eee10.meeting.ietf.org> <201403071814.s27IEMSg6438588@shell01.TheWorld.com> <531B691F.7090608@stpeter.im> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1395264640; bh=32kYLW6A/balVFdSTr/9WxQb9JKJOEwxYl0rwclTTyA=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=mNSETbQGC6TwGfmy3zWAiHxj0SNPl3J9TnJYgglzjhBnGIn+DBPeiHXZIf7961Uny VFK32bLobY2lFH90425DfjijGVFNwKEFy+NrCIRbE0N1MULqZACFtZYSL5QW2qrein oJvoUI4JVRBk8tBd7c3XFk7jlNM0hxqRYAnsvo2k7p6/aEB3xWjOCYMQz5eaqgqnJ7 V1XRlXNxgntPgp0uY5J4HScBmXGXQ/ie8N+UkISAyTwa01u+hOlPyiDzzovyqlGjK6 xh+INGOKREV2o03y+bYGBzK1rjiwHuOj3Rrf1bNHwFXbbIPKFEBb3m9K5/PFqkI8op Ko0rLe68kyUhQ== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/SkXXfCHsaCwnLtJBUEwqU3fMoGQ Cc: urn@ietf.org Subject: Re: [urn] URN NIDs for private enterprises X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 21:30:51 -0000 > From: Peter Saint-Andre > > If we're going to use OIDs, I would suggest we tell registrants that > > they should register an enterprise number and then they would be able > > to use OID-based URNs for their resources: > > urn:oid:1.3.6.1.4.1.14490.xxx.yyy.zzz > > That is already specified; essentially their enterprise number > > registration gets them an OID delegation, which allocates to them a > > URN sub-space. > > If we already have something that will work, I suggest we use it. I will suggest that as a possibility to the DTS people. > (1) What we require for registration of a formal NID. Historically, > registrants have needed to specify some public benefit, if you will, and > to document their processes to some extent. That still seems beneficial > to me. I agree with the sentiment. But looking at the registration for urn:3gpp (which I choose only because it is the first namespace listed in the registry), it contains essentially no information about any of those issues. And yet, I see no reason not to approve 3GPP's registration. > (2) What we require for (automatic?) registration of an enterprise NID. > If these are truly private and not intended to be public in any way > (although such things often leak out into the public space, see RFC 6648 > for related considerations) then a less onerous registration process > might be sensible. I think that there is a complication: while a set of URNs may be "proprietary", in that they're defined and used in a way specified by a private enterprise, the "ecosystem community" around the enterprise that uses those URNs may be quite large, possibly open-ended, and the URNs themselves may be flying around the greater Internet, and appear in contexts that are to some degree visible to parties/systems outside of the ecosystem. So the difference between "public usage" and "private usage" is not clear-cut. Referring to your paragraph I quote below, if Google wants to name an XML namespace and publish its DTD, it needs a piece of namespace that it can be sure doesn't overlap with anyone else's namespace. > FWIW, then I worked at Cisco I had to actively stamp out usage of > (private, internal) XML namespaces like urn:cisco:* - naive developers > though they could create such things out of thin air. Discouraging such > behavior would be a good thing. If "automatic" registration via the OID > namespace identifier (RFC 3061) moves us in that direction, that might > be helpful (but one reason people try to use URNs like "urn:cisco:*" > even when the NID doesn't exist is that it seems so straightforward and > developer-friendly). I was at a company that needed to name XML namespaces, and we used HTTP URLs, since we already had the registration for the "host" DNS name. In a sense, the public benefit of this proposal is that it easily allows enterprises to create URNs that won't collide with URNs created by any other enterprise. Dale From nobody Wed Mar 19 14:31:26 2014 Return-Path: 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 1DC781A0724 for ; Wed, 19 Mar 2014 14:31:25 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 cDr9cqLbEjFW for ; Wed, 19 Mar 2014 14:31:23 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 4501C1A0538 for ; Wed, 19 Mar 2014 14:31:23 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta04.westchester.pa.mail.comcast.net with comcast id fNrU1n0081wpRvQ54ZXEso; Wed, 19 Mar 2014 21:31:14 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta18.westchester.pa.mail.comcast.net with comcast id fZXE1n0021KKtkw3eZXEm3; Wed, 19 Mar 2014 21:31:14 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s2JLVCuc012186; Wed, 19 Mar 2014 17:31:13 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s2JLVBgX012184; Wed, 19 Mar 2014 17:31:11 -0400 Date: Wed, 19 Mar 2014 17:31:11 -0400 Message-Id: <201403192131.s2JLVBgX012184@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Peter Saint-Andre In-reply-to: <531B691F.7090608@stpeter.im> References: <201403032036.s23Kahsi6151234@shell01.TheWorld.com> <91E799B74D3451FEEA8E9407@JcK-eee10.meeting.ietf.org> <201403071814.s27IEMSg6438588@shell01.TheWorld.com> <531B691F.7090608@stpeter.im> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1395264674; bh=O2z99RqZjeGP0x/hsvldKej6pX1LJODoYdabevYyO/g=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=KFLmf4F6iNIai+UsUX89qo4SuQWr3uaiYH15VebZWqtaFrl4WN975L43fbMmEHek+ nCHKYUIPIehODxoyTNCsXipHVCdFf2Hf2GkM1N4lyBFOFl8xTNr8EEh9LHne8/7JN5 s7hKxTgce+2Z/YUaOT50bsst7fhsJjqP0aOyMgpPFL7HeX4HSQcq1IFcmMQEoOA8XW UyAw7ooDOz5KdpfRG5a0+3Rj+bDEmDURyxdEqWHWLbcBEh163O4P4sglhY9bIKUaZd T4lIXp6ytKpQIxCXMdxhlwB7+K8P3ZlrUnqIjSm9aq10UGYYLKSE4ou4eAoHoVXzTW /yJF5Ed9AjRxw== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/ig7IENVQZD16Q2Y30L7bX4Zn1V4 Cc: john@jck.com, urn@ietf.org Subject: Re: [urn] URN NIDs for private enterprises X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 21:31:25 -0000 In regard to providing a method for private enterprises to automatically have a space of URNs: > From: Peter Saint-Andre > Date: Sat, 08 Mar 2014 12:01:51 -0700 > > If we're going to use OIDs, I would suggest we tell registrants that > > they should register an enterprise number and then they would be able > > to use OID-based URNs for their resources: > > [...] > > If we already have something that will work, I suggest we use it. That is sensible. It seems to me that you may have solved the problem in another message: > Date: Tue, 11 Mar 2014 14:01:22 -0600 > From: Peter Saint-Andre > To: Joel Kalvesmaki > Subject: Re: URN UUID question > Archived-At: http://mailarchive.ietf.org/arch/msg/urn-nid/q9TdGA2GIMP-fCBuxc8-Me1IDYs > Cc: urn-nid@ietf.org > > It sounds to me as if you might want to use the 'tag' URI scheme: > > https://tools.ietf.org/html/rfc4151 The "tag" scheme lets DTS, Inc. use URIs with the format (among others): tag:dts.com,2014:{pchar-string} which seems to me to solve all their practical problems. Formally, they're URIs not URNs, but that seems (1) to have no practical consequences, and (2) to avoid any philosophical problems regarding uniqueness/persistence, public documentation, public syntax, public benefit, etc. I've proposed this to the DTS people on urn-nid. Let's see what they have to say. Dale