Re: urn:oid:

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Fri, 14 March 2014 02:31 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
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 6A0A51A06C8 for <urn-nid@ietfa.amsl.com>; Thu, 13 Mar 2014 19:31:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.362
X-Spam-Level:
X-Spam-Status: No, score=0.362 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547] 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 MRrURWadwqGg for <urn-nid@ietfa.amsl.com>; Thu, 13 Mar 2014 19:31:45 -0700 (PDT)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 29E841A06C3 for <urn-nid@apps.ietf.org>; Thu, 13 Mar 2014 19:31:44 -0700 (PDT)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id s2E2VZsS021263; Fri, 14 Mar 2014 11:31:36 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 7126_8192_c3425bb6_ab20_11e3_83c9_001e6722eec2; Fri, 14 Mar 2014 11:31:34 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 020CBC042B; Fri, 14 Mar 2014 11:31:35 +0900 (JST)
Message-ID: <532269FE.6010807@it.aoyama.ac.jp>
Date: Fri, 14 Mar 2014 11:31:26 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Phillip Maness <Phillip.Maness@dts.com>, "Dale R. Worley" <worley@ariadne.com>
Subject: Re: urn:oid:
References: <520A56052CF01E42B1C128F990FBE681A4715F92@LAX-EXMB02.dts.local>
In-Reply-To: <520A56052CF01E42B1C128F990FBE681A4715F92@LAX-EXMB02.dts.local>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/urn-nid/JDGBfffKBYbp98Ek0NeFkOzw9Zg
Cc: "urn-nid@apps.ietf.org" <urn-nid@apps.ietf.org>, "Mark R. Johnson" <Mark.Johnson@dts.com>
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: Fri, 14 Mar 2014 02:31:47 -0000

On 2014/03/12 22:42, Phillip Maness wrote:
> Hi Dale,

> Your idea to map ':oid:1.3.6.1.4.1' to ':enterprise', (or 'e') would be a significant improvement from a human readability perspective, but I really like your second idea better, even to perhaps generalize it to:
>
> urn:dn:<domain name>:{string}
>
> For example
>
> urn:dn:dts.com:{string}
>
> In our case this scheme would have the added benefit to inform a developer encountering this urn an easy clue on where to go for more information.
>
> Have you any insight whether this could be an acceptable proposal? I would be willing to write the draft RFC.

Domain names are being changed and reused all the time. And 
people/organizations who reuse them usually don't know what URNs their 
predecessors have minted, nor would they care.

In Web Architecture discussions, there are people who regularly say that 
there's no need to use URNs, just use something like 
http://dts.com/{string}. The proponents of URNs always said that URNs 
are there to provide more stability than e.g. HTTP URLs. This proposal 
would essentially pollute the overall URN space with the instability 
from other URI/IRI schemes.

> In light of this new information, it's apparent there is no merit in pursuing my original namespace RFC. Can I withdraw it, or do I just let it expire?

Just let it expire.

Regards,   Martin.