RE: [URN] focus the question

"Larry Masinter" <masinter@parc.xerox.com> Wed, 14 October 1998 19:04 UTC

Received: from services.bunyip.com (services.Bunyip.Com [192.77.55.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA21408 for <urn-archive@ietf.org>; Wed, 14 Oct 1998 15:04:20 -0400 (EDT)
Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id OAA26411 for urn-ietf-out; Wed, 14 Oct 1998 14:28:17 -0400 (EDT)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id OAA26406 for <urn-ietf@services.bunyip.com>; Wed, 14 Oct 1998 14:28:14 -0400 (EDT)
Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id OAA15638 for urn-ietf@services; Wed, 14 Oct 1998 14:28:16 -0400 (EDT)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by mocha.bunyip.com (8.8.5/8.8.5) with SMTP id OAA15634; Wed, 14 Oct 1998 14:28:12 -0400 (EDT)
Received: from casablanca.parc.xerox.com ([13.2.16.111]) by alpha.xerox.com with SMTP id <61605(4)>; Wed, 14 Oct 1998 11:26:39 PDT
Received: from copper.parc.xerox.com ([13.0.208.21]) by casablanca.parc.xerox.com with SMTP id <71835>; Wed, 14 Oct 1998 11:26:34 PDT
From: Larry Masinter <masinter@parc.xerox.com>
To: Leslie Daigle <leslie@Bunyip.Com>, "Martin J. Duerst" <duerst@w3.org>
Cc: urn-ietf@Bunyip.Com
Subject: RE: [URN] focus the question
Date: Wed, 14 Oct 1998 11:26:33 -0700
Message-ID: <000d01bdf7a0$2bab0c20$15d0000d@copper.parc.xerox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-to: <Pine.SUN.3.95.981014100922.14250F-100000@mocha.bunyip.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-urn-ietf@Bunyip.Com
Precedence: bulk
Reply-To: Larry Masinter <masinter@parc.xerox.com>
Errors-To: owner-urn-ietf@Bunyip.Com

> [Leslie's comments as WG co-chair:]
> I have a real feeling that people are trying to get in some "last licks"
> at asserting what the "proper" way to build a "good" URN namespace
> will be.  That's the area we have always had most trouble with -- there
> is no general agreement on it.  The only way we ever even got a draft
> of this document together is by focusing on the non-judgemental, strictly
> technical points necessary to make a _functioning_ URN system.    That
> remains the primary criterion upon which it should be discussed.

"draft-ietf-urn-nid-req-06.txt", dated October 8, 1998, introduced
a change. I am discussing the change. The change was to reserve
all two-letter URN namespaces.  This change was made without
any apparent discussion within the working group (on the mailing
list or in the minutes) and then a working group last call was
issued.

A separate document, draft-popp-realname-hfn-00.txt, dated
September 23, 1998,  contains a proposal for a two-letter
URN namespace (specifically, "rn"). Since the newly released
working group document now reserves a registration which was previously
not reserved, it is appropriate and timely to question the basis
of that reservation. If anything, "draft-ietf-urn-nid-req-06.txt"
contains a "last lick" in "namespace reservation", by now reserving
something, without an analysis of whether or not that reservation
is a good idea. 

Upon further examination, it seems that the entire concept of
"country code URN namespaces" is questionable.  It is true that
this questionableness might have been raised at some earlier date,
but, as is the case with most IETF activities, the fact that a
problem wasn't noticed before is a weak reason to not address it,
*especially* at the time of a "last call".

If you don't think that the "URN Namespace Definition Mechanisms"
document should address the issues of what constitutes a good
namespace and what does not, then you should remove the paragraph:

	ALL two-letter combinations are reserved for use
	as country code NIDs for eventual national registrations of
 	URN namespaces. 
 
from draft-ietf-urn-nid-req-06.txt, and let the subsequent
process for namespace management (described in the rest
section 4.0,III. Formal) discuss the appropriateness of
a two-letter code as a top level namespace.

Larry