Re: request for NID review: "iana"

Peter Saint-Andre <stpeter@stpeter.im> Sun, 11 November 2012 02:43 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: urn-nid@ietfa.amsl.com
Delivered-To: urn-nid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF95F21F88C9 for <urn-nid@ietfa.amsl.com>; Sat, 10 Nov 2012 18:43:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.455
X-Spam-Level:
X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qY1x4s+Heozy for <urn-nid@ietfa.amsl.com>; Sat, 10 Nov 2012 18:43:11 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6912421F88C5 for <urn-nid@ietf.org>; Sat, 10 Nov 2012 18:43:08 -0800 (PST)
Received: from [192.168.1.4] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CB69E40062; Sat, 10 Nov 2012 19:47:06 -0700 (MST)
Message-ID: <509F10BE.3020100@stpeter.im>
Date: Sat, 10 Nov 2012 19:43:10 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
Subject: Re: request for NID review: "iana"
References: <509AFBD8.7060703@stpeter.im> <509E6E07.3040406@it.aoyama.ac.jp>
In-Reply-To: <509E6E07.3040406@it.aoyama.ac.jp>
X-Enigmail-Version: 1.4.5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Cc: urn-nid@ietf.org, Michelle Cotton <michelle.cotton@icann.org>
X-BeenThere: urn-nid@ietf.org
X-Mailman-Version: 2.1.12
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: Sun, 11 Nov 2012 02:43:12 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/10/12 8:08 AM, "Martin J. Dürst" wrote:
> Hello Peter,
> 
> I have a few questions/concerns.
> 
> First, is creation of URNs planned for all registries? I can't
> remember an example, but some registry entries already probably
> have URNs associated with them. Or is this only going to be used
> when requested in a IANA consideration section?

All this document really does is reserve the "iana" namespace
identifier. It is up to the IANA whether they use the namespace at
all. This is made clear in the IANA Considerations for this document:

   This document defines a URN NID registration of "iana" and thus opens
   the possibility that the IANA can use that namespace if desired.
   However, this document does not stipulate that the IANA is to create
   names for every entry in every registry that it maintains.  The
   IANA's use of the namespace is a matter for IANA policy, which is
   outside the scope of this document.

> Next, there is wording such as: The IANA is responsible for
> managing the assignment of both "RegistryName" and "EntryName"
> strings. What does this mean? That e.g. the Charset Registry will
> be under RegistryName "Character%20Sets" (because that's how it
> appears at http://www.iana.org/protocols, with the space escaped),
> or something else? If something else, then what?

Really that should be "RegistryString" instead of "RegistryName".

> Another main concern is this uniqueness/persistence: Identifier
> Uniqueness Considerations:
> 
> The IANA ensures the uniqueness of all IANA URNs by checking 
> RegistryNames and EntryNames against existing names for both 
> registries and entries.  The IANA directly ensures the uniqueness
> of the assigned strings and does not assign secondary
> responsibility for management of any sub-trees. In no case will the
> resulting URNs be re-assigned.
> 
> Identifier Persistence Considerations:
> 
> Through its existing registration procedures, the IANA ensures that
> registrants provide clear documentation of the entries in IANA
> registries.
> 
> The uniqueness of the identifier isn't a problem. But what about
> the uniqueness of the "protocol entity" (or whatever) that is
> identified? There may be identifier reallocation for registries
> where there's not that much space. Also, if definitions of entries
> change because they are being updated, is a new URN needed, or is
> the old one still good enough? Personally, I'm fine with either
> way, but I think it should be discussed more.

I think that's a matter for IANA policy documents, but those are good
questions.

> Also, it says: The Internet community will benefit from this
> namespace by having more permanent and reliable names for
> parameters used in the context of Internet protocols and
> applications.
> 
> How do e.g. port assignments get more permanent or more reliable
> by creating this kind of URN? Similar question for other
> registries. Just because I can write urn:iana:charsets:iso-8859-1,
> how does this make it more permanent? Or more reliable?

The parameters you have mentioned are stable, but the names for them
are not, as explained in the Introduction (indeed, currently we don't
really have names for parameters, only for the registries themselves).

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCfEL4ACgkQNL8k5A2w/vzAxwCg8H501d++bqAi3q45uZAZZriS
GlcAmwc47dc8eq13wP3ADt3O5FwxkAA7
=uKlN
-----END PGP SIGNATURE-----