Ted Hardie <> Mon, 02 June 2008 16:48 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 96F4F28C240; Mon, 2 Jun 2008 09:48:46 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D08E28C12A for <>; Mon, 2 Jun 2008 09:29:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.475
X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_25=0.6, USER_IN_WHITELIST=-100, WHOIS_MYPRIVREG=1.499]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0e7KiFqQynux for <>; Mon, 2 Jun 2008 09:29:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E38C63A6B25 for <>; Mon, 2 Jun 2008 09:29:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=qcdkim; t=1212424160; x=1243960160; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20<p06240601c469c1cae339 @[]>|In-Reply-To:=20<352F4F60-571C-4782-95DB>|References:=20<352F4F60-571C-478>|Date:=20Mon,=202=20Jun=202 008=2009:29:11=20-0700|To:=20Andy=20Greener=20<andy@gid.c>,=20""=20<>|From:=20 Ted=20Hardie=20<>|Subject:=20Re:=20UK =20NID?|CC:=20Leslie=20Daigle=20<>, =0D=0A=20=20=20=20=20=20=20=20Lisa=20Dusseault=0D=0A=09<l>|Content-Type:=20text/plain=3B=20ch arset=3D"us-ascii"|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"520 0,2160,5307"=3B=20a=3D"3608053"; bh=S52PlXXjf/MaDRc3CkGkkDvNTO406axSw2/UGxABde0=; b=jeOBsF5NzHxtWzu36GnzHT30Xw7g6B+B8QmT/ltnO5lPcAiw8aLNxWtj EKbT5miv1P1ELYnO2oO46a345tC9J0UJSz18nO+df9EWV2K98KvB8OIYa 4Jdsv/oPPyQwplmByApVR9f5sVnbh7vQsZvcwB6r1hJMi3bHUIaBNqvxT 0=;
X-IronPort-AV: E=McAfee;i="5200,2160,5307"; a="3608053"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Jun 2008 09:29:20 -0700
Received: from ( []) by (8.14.2/8.14.2/1.0) with ESMTP id m52GTJCn027248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Jun 2008 09:29:20 -0700
Received: from ( []) by (8.14.2/8.14.2/1.0) with ESMTP id m52GTJxA008768 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Jun 2008 09:29:19 -0700 (PDT)
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id; Mon, 2 Jun 2008 09:29:17 -0700
MIME-Version: 1.0
Message-ID: <p06240601c469c1cae339@[]>
In-Reply-To: <>
References: <>
Date: Mon, 02 Jun 2008 09:29:11 -0700
To: Andy Greener <>, "" <>
From: Ted Hardie <>
Subject: Re: UK NID?
Content-Type: text/plain; charset="us-ascii"
X-Mailman-Approved-At: Mon, 02 Jun 2008 09:48:45 -0700
Cc: Leslie Daigle <>, Lisa Dusseault <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Hi Andy,
	I've cc'ed Leslie Daigle on this message, as she was quite
heavily involved in both setting up the registration procedures and
in working with New Zealand on arranging their NID.  I've also
cc'ed Lisa Dusseault, who is the Area Director who currently
processes most URI-related drafts).
	The first question, at least from my perspective, is what time
frame do you need this in?  The procedures for getting a namespace
identifier according to the current rules are relatively clear cut and
with sufficient coordination could probably be done in a couple of
months (get a draft written along the New Zealand model, have it
go through the required review by the urn-nid list, approved by
the IESG). The last step is the longest/least sure since the IESG approves
all IETF technical standards and many related documents as well, so their
calendar can get full.  If you need it relatively quickly, though, using the existing
procedures is probably the way to go.
	You're right that the 2-letter IDs were reserved in 3406, with
the following text:

NOTE: ALL two-letter combinations, and two-letter combinations
   followed by "-" and any sequence of valid NID characters are reserved
   for potential use as countrycode-based NIDs for eventual national
   registrations of URN namespaces.  The definition and scoping of rules
   for allocation of responsibility for such namespaces is beyond the
   scope of this document.
	To allocate a two-letter combination, the rules for the
allocation would have to be codified in an update to BCP33/RFC3406
and then a document written that conformed to the new rules.  That's
pretty much automatically going to be slower than getting a longer NID approved
(since it involves two passes through the IESG).  Theoretically, there could be
some parallel processing, but realistically it will be slower. 
	The big reason it will be slower is that it is not entirely clear
how to create a process that allows the IETF/IANA to be assured that a
NID request comes from *the part of an individual government* that should
be assigned the NID.  Since governments vary considerably in their structure,
we cannot simply say:  "A request from the government's CIO or equivalent
to assign will be honored".   In some cases,  there will be no such office; in others,
the request might most appropriately come from a governmental office charged
with library services (e.g. the U.S. Library of Congress).  There are also codes like
AQ (for Antarctica) which are assigned but for which identifying  a single governmental entity as responsible is difficult, and codes which ISO has re-assigned
after the passage of time (like SK).    We would also have to deal with situations like
yours in which there is an assigned code (GB) and an exceptionally reserved one (UK).
Writing that document and getting agreement on it is unlikely to be quick, and
none of this is, honestly, in the IETF's core area of concern or competence.  That
also makes things slow. 
	If you have no particular time constraints and have the energy to put
into proposals here, it may be possible to resolve this.  But I do believe it will
be relatively slow to complete.
				Ted Hardie

At 10:59 AM -0700 5/20/08, Andy Greener wrote:
>I recently joined this list so forgive me if this has been discussed before (I did check the archive at but couldn't see anything of direct relevance recently).
>As my sig indicates I'm a technical consultant working for HM Revenue & Customs in the UK, and I'm also a member of a sub-committee of the UK CTO Council's Architecture Review Board that is considering the future of the UK GovTalk policies and standards web site ( As part of this work we are considering establishing a URN scheme for namespace naming of persistent artefacts (XML Schemas, code lists, etc) across the UK Government space, and naturally the subject of a "UK" NID came up.
>I note that RFC3406 states that all two-letter combinations are reserved for potential use as countrycode-based NIDs for eventual national registrations of URN namespaces, but it hints at another set of definition & scoping rules for such namespaces. I also note that there are no existing two-letter NIDs on the IANA list, but that at least one country (New Zealand) has already tackled this issue and worked around it by using their ISO three-letter code instead (not an option for us as the three-letter code for the UK is "GBR", which we feel is inappropriate under the circumstances, as well as being somewhat "politically incorrect").
>Are we on a hiding to nothing if we wish to pursue the "UK" NID? The registration would be made on behalf of the UK Govt by the Govt's CTO, and it is unclear to me who else would have ultimate authority to formally request this particular NID if it's not the UK government. I expect I'm opening a can of worms here, but if you don't ask you don't get! I'd be grateful for any guidance or advice anyone can give me.
>The best qualifying alternative we can come up with is "UKGOV", but this is likely to be subsumed into any future "UK" NID anyway (not a desirable attribute for a supposedly persistent naming mechanism! - we'd like to do the "right" thing once, and for all).
>	Andy
>Andy Greener
>Enterprise Architect
>Architecture Solutions & Assurance
>IMS Strategy & Architecture, HMRC
> /
>+44 7836 331933
>Attachment converted: Macintosh HD:smime 1479.p7s (    /    ) (007B1E4D)