Re: Review and URN assignment for draft-seantek-xmlns-urn-00

Sean Leonard <dev+ietf@seantek.com> Tue, 11 November 2014 20:19 UTC

Return-Path: <dev+ietf@seantek.com>
X-Original-To: urn-nid@ietfa.amsl.com
Delivered-To: urn-nid@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359A51A8AFE for <urn-nid@ietfa.amsl.com>; Tue, 11 Nov 2014 12:19:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, 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 qNqH24HnZo37 for <urn-nid@ietfa.amsl.com>; Tue, 11 Nov 2014 12:19:31 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CECB31A90AF for <urn-nid@ietf.org>; Tue, 11 Nov 2014 12:19:11 -0800 (PST)
Received: from dhcp-b3ac.meeting.ietf.org (unknown [31.133.179.172]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8415122E257; Tue, 11 Nov 2014 15:19:07 -0500 (EST)
Content-Type: multipart/signed; boundary="Apple-Mail=_CA369406-DFCF-437A-8458-AFA83B15B7BE"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: Review and URN assignment for draft-seantek-xmlns-urn-00
From: Sean Leonard <dev+ietf@seantek.com>
In-Reply-To: <201411111609.sABG9uE8008942@hobgoblin.ariadne.com>
Date: Tue, 11 Nov 2014 10:18:03 -1000
Message-Id: <476745DD-A96F-41C6-9FAD-368FB8C33DE9@seantek.com>
References: <6A6694AE-BC9B-4058-8DE5-6B2FA8AE5B84@seantek.com> <201411111609.sABG9uE8008942@hobgoblin.ariadne.com>
To: "Dale R. Worley" <worley@ariadne.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/urn-nid/5RUm9SDJ6GFE3zBMAjVUbyuhFhk
Cc: urn-nid@ietf.org
X-BeenThere: urn-nid@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <urn-nid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn-nid/>
List-Post: <mailto:urn-nid@ietf.org>
List-Help: <mailto:urn-nid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Nov 2014 20:19:39 -0000

Thank you for the feedback.

On Nov 11, 2014, at 6:09 AM, Dale R. Worley <worley@ariadne.com> wrote:

> I'd like to see more discussion of why this NID is needed.

Ok.

>  The draft
> says:
> 
>   Experience suggests that several URN namespace registrations have
>   been proposed over the years, where the primary (yet only
>   occasionally stated) purpose is to create short URIs for the
>   registrant's XML namespaces.
> 
> That's true, but one can create URIs to name one's XML namespaces in
> many ways already.  One can use "oid" URNs, or "tag" URIs, or build
> HTTP URLs based on one's domain registration.

That is correct. However, urn:oid (and for that matter, oid: ) and tag: URIs are not really used in practice. OIDs are compact but not particularly mnemonic. tag: URIs are mnemonic, but like http(s) URIs, they depend on the DNS infrastructure. tag: URIs only depend on the DNS infrastructure at a particular point in time…but that particular point in time is forever inscribed into the URI. For XML namespace purposes, that is a lot of unnecessary redundancy. Additionally, tag: URIs do not have any semantics or associations with XML namespace resources, so they can only be used to generate arbitrary strings. (From taguri.org, tag URIs satisfy School 1 but not School 2.)

Compare for “Foo Description Language Version 2":
http://www.acmecorp.com/xml/foodlv2
tag:acmecorp.com,2014:foodlv2
urn:xmlns:acme:foodlv2

The http URI has 35 characters. You can put resources there, if you want, but you have to keep paying for the domain name and web server into eternity.
The tag URI has 29 characters. You cannot put or associate resources there.
The xmlns URN has 22 characters. You can associate resources there, and it’s free as long as IANA is free (heh).

> 
> The draft continues:
> 
>   registrant's XML namespaces.  An XML namespace designer now has the
>   option of choosing a short, memorable identifier ...
> 
> I assume that means "This draft provides an XML namespace designer
> with the option...", even though the "now" in that sentence is
> ambiguous -- does it refer to the time before adoption of the draft or
> after?

Yes. After adoption of the draft.

> 
> It seems that mnemonicity is a goal.  But in practice, the nicely
> mnemonic values will be taken fairly quickly and future registrants
> will be restricted to non-mnemonic values -- unless some sort of
> de-facto grouping convention comes to be used.

Meh, I am seriously not worried about that: that concern is overstated. People aren’t going to register things in urn:xmlns unless they are XML namespace URIs. It’s not really the right forum for vanity registrations. If folks are concerned about segregating a “private” sub-part of the namespace, there is a provision for that by using IANA Private Enterprise Numbers. The numbers are still low enough that they retain some mnemonic properties.

To the overall question of why this namespace is needed:
Since when is “why is this needed” a gating factor for URN assignments? For URI schemes, one is supposed to demonstrate some sort of broad utility for the Internet infrastructure. (But that can be easily overcome with a provisional registration.) For URNs, however, RFC 3406 states:

  ...the underlying
   namespace will provide benefit to *some subset of users* on the
   Internet.  That is, a formal NID proposal, if accepted, must be
   functional on and with the global Internet, not limited to users in
   communities or networks not connected to the Internet.  For example,
   a NID that is meant for naming of physics research is requested.  If
   that NID request required that the user use a proprietary network or
   service that was not at all open to the general Internet user, then
   it would make a poor request for a formal NID.  The intent is that,
   while the community of those who may actively use the names assigned
   within that NID may be small (but no less important), the potential
   use of names within that NID is open to any user on the Internet.


So to answer the question specifically: the namespace is beneficial to XML namespace designers who want to have short, mnemonic, unique, long-lived URIs, and to XML namespace users (that would be “everyone on the Internet”) who rely upon them. You can still use other URIs for XML namespaces, but this URN namespace is tailor-made to satisfy the needs of that subset of users.

Cheers,

Sean