RE: UK NID?

[Jurijs Korņijenko <[e-mail]>]

Hello Andy,

some time ago we registered namespace for Latvian government integration project URN:IVIS - RFC4617. The purpose and usage of namespace is similar - XML schemas, e-services and other artifacts identification with URN number. Now we are planning to develop an IVIS URN resolve infrastructure. 

One suggestion: take a NID which is really politically and practically acceptable by anyone, how far it is possible. Because in our case we always have to answer to question - "Hey, IVIS, what is this and what for?". UKGOV from my point of view looks good.

Thank you,

Juri.

-------------------------------------
Dr.sc.ing. Jurijs Kornijenko
SIA "ABC software"
Mob. tālr. [phone]
Ofisa tālr. + 371 7082635

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Leslie Daigle
Sent: Tuesday, June 03, 2008 2:40 PM
To: Andy Greener
Cc: [e-mail]; Lisa Dusseault
Subject: Re: UK NID?


Hi Andy,

Ted is correct in that, given sufficient time and energy, just about
anything is possible.

I'd like to underscore, however, that the missing piece is not about
your proposed URN namespace:  to "get 'UK'", you would need to solve the
whole problem, generally, for country code URNs.

What I wrote, almost 3 years ago, when the discussion of NZ came up:

[I wrote:]
> There is no process defined to vet who represents which country for 
> the purposes of URN NID registration, and until there is, there will
> be no two letter country code NID registrations.
> 
> To counter that argument, solve ICANN's problems in ccTLD zone 
> administration authority, and then come back :-)
> 
> Less obliquely, there is the very real probability that, for eg, a
> national library could claim to be responsible for setting up
> permanent identifiers for resources, while the national passport
> office turned around and defined something entirely different.  How
> is the IETF/IANA to determine what authority within the country is
> going to arbitrate between them?


I hope you understand it is not a trivial problem to solve, and very
little of it has to do with engineering.

I can appreciate that "GBR" would not work for you; but I hope you can 
find an alternate that will get you to a working URN namespace soon.

Leslie.

Ted Hardie wrote:
> 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. regards, Ted Hardie
> 
> 
> 
> At 10:59 AM -0700 5/20/08, Andy Greener wrote:
>> Hello,
>> 
>> I recently joined this list so forgive me if this has been
>> discussed before (I did check the archive at www.nabble.com 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 (www.govtalk.gov.uk). 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
>> 
>> [e-mail] / [e-mail] [phone]
>> 
>> 
>> 
>> 
>> Attachment converted: Macintosh HD:smime 1479.p7s (    /    )
>> (007B1E4D)
> 

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[e-mail]
-------------------------------------------------------------------