Subject: [URN] focus the question

From: Leslie Daigle <[email-masked]>
Date: Tue, 13 Oct 1998 17:04:35 -0400 (EDT)

While what Larry is saying is quite true -- good namespace management
dictates that there be delegation to the level that there is autonomy
of change control (e.g., down to the state level, or national organization
level), I haven't yet heard anything that suggests this CANNOT be done
in the existing proposal, or that we should attempt to promote good
national namespace design by NID assignment procedures.

That is, 

	1. urn:us:ca:   and
	2. urn:us-ca:

differ in that

	1. requires an extra RDS lookup (_maybe_ -- I argue it can
	   be done with one, if there is a standard convention
	   for second-level servers, but I haven't actually done the
	   math myself)  

	   requires the "us" namespace designers have the forethought
	   to divide the namespace up appropriately

	   requires the "ca" subspace to "play within the rules of
	   the "us" namespace [is this a bad thing?  -- LLD]

	   can be built to allow California to have its own authority
	   for that part of the us namespace

	2. can be done in one  NAPTR lookup

	   doesn't require the national namespace builder to develop
	   a good namespace structure for all possible cases

	   still requires us- namespace developers to make reasonable
	   guesses about where to assign namespaces

	   easily supports complete disparity between us-* namespaces

I don't see what providing the "-" structure adds _technically_ to the
structure -- most of the above issues come down to proper namespace 
development, which is equally difficult in either case.

I will also point out that we threw out explicit NID hierarchy in the 
general case after the Dec 1997 IETF -- the argument was that we needed 
to get the basics working before we postulated what might be useful 
structuring of the NID.  I have some concerns that <countrycode>"-" is
dangerously close to the same territory, and perhaps should similarly
be punted to future work.

Leslie.

----------------------------------------------------------------------------

    If cats had bumper stickers:                  Leslie Daigle
                                             
      "I wake for food."                          Bunyip Information Systems
                -- ThinkingCat                    (514) 875-8611
                                                  [email-masked]
----------------------------------------------------------------------------

---

From: "Larry Masinter" <[email-masked]>
Date: Tue, 13 Oct 1998 15:20:37 PDT

> national namespace design by NID assignment procedures.

I think my question has been extended beyond the scope I intended for
it to apply. While it is an interesting question about whether there's
a substantial or different performance impact on delegated resolution for
"urn:us:ca" vs "urn:us-ca", my question applies exactly to, and only to,
the topic contained in the documented entitled "URN Namespace Definition
Mechanisms" for which there was recently a working group last call.

This document asks the registrar of a namespace a lengthy and detailed set
of
questions, which include questions about the syntax, semantics, matching
rules,
uniqueness considerations, etc etc.

If the namespace owner actually intends to set up a bunch of delegated
namespaces
that each individually have their own different answers to each of those
questions,
and so answers each of the questions "it depends on the sub-namespace I'll
delegate",
then what is the purpose and use of having the form at all?

And if it *isn't* intended that a namespace owner be able to create
sub-namespaces
where each of the sub-namespaces has its own unique answers to each of those
questions, then I would assert that there is no place for having two-letter
country codes as URN namespaces.

---

From: Michael Mealling <[email-masked]>
Date: Tue, 13 Oct 1998 18:54:49 -0400 (EDT)

Larry Masinter said this:
> of questions, which include questions about the syntax, semantics, matching
> rules, uniqueness considerations, etc etc.
> 
> namespaces that each individually have their own different answers to each 
> of those questions, and so answers each of the questions "it depends on the 
> sub-namespace I'll delegate", then what is the purpose and use of 
> having the form at all?

Because others won't and knowing the difference is important. While, 
"it depends" isn't chock full of information it is a very good referral
for finding the answer where it has the most value.

> sub-namespaces where each of the sub-namespaces has its own unique 
> answers to each of those questions, then I would assert that there 
> is no place for having two-letter country codes as URN namespaces.

I assert that it is intended that a namespace can delegate the answers
to those questions. Thus country codes are important in this respect.
But, that aside, I think that simply specifying that a NIDs that start
with "twolettercountrycode-" are reserved for those that have that 
authority does no rise to the level of hierarchy we're talking about.
At least for me, reserving "us-" for the US specific spaces is simply
a way of keeping others from inappropriately asserting that they
can assing US specific spaces. Take it from someone who works with it,
if you don't reserve it, people will take it and use it inappropriately.

You know, we could get really nuts with this by claiming that, since
both numbers and letters form a specific series, any sequence of bits
we stick in an NID is really hierarchical and thus subject to 
decomposition by the RDS process. But I don't think we really want to
go down that road, do we?

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  [email-masked]

---

From: "Martin J. Duerst" <[email-masked]>
Date: Wed, 14 Oct 1998 12:55:24 +0900

> 	   for second-level servers, but I haven't actually done the

You are assuming that because the sequence of labels and colons
looks like subsequent NIDs, they actually are subsequent NIDs.

This is a dangerous assumption, because it is wrong.

As far as the URN syntax document
(ftp://ftp.isi.edu/in-notes/rfc2141.txt) goes, for an URN of

   urn:us:ca:ssn:123456789

we get the following

   urn:us:ca:ssn:123456789
   ####***$$$$$$$$$$$$$$$$

where # denotes the "urn:" prefix, * the NID, and $ the NSS
(Namespace Specific String).

This may have various consequences for resolution, but it also
has for definitions. As only "us:" is the NID, the registration
only goes that far. "us:ca:" or "us:ca:ssn:" won't be registered
with IANA.

The consequence of this is that IANA will have to accept very
generic registrations. Basically everybody can come and say
"I want to register a namespace, I want to put all kinds of things
in there, so in all the fields, I just write 'various' or
'depends' or 'don't know yet'".

It looks to me as if this would be very much against the
general goals of the whole URN effort.

The solutions I see are:

- Change the syntax to change xxx:yyy:... prefix chains into
  sequences of NIDs.

- Explicitly allow deferring of detailled namespace definitions
  for registrations (i.e. the draft would allow you to register
  e.g. "us:", with very generic terms, but in that case would
  require that:
  - It is spelled out how subspaces are identified syntactically
  - It is spelled out how subspaces get managed (one option
    would be to say that subspaces get registered directly with
    IANA according to this document)

- Go with the "-" solution.

> 	   the "us" namespace [is this a bad thing?  -- LLD]

If the rules of the "us" namespace have to be made so general as to
be useless to be able to accomodate the wide variety of what goes
in there, it looks like this may be a bad thing.

> be punted to future work.

<countrycode>"-" is close, but I guess <countrycode>":" is closer.
And at least the reservation has to be done now, that cannot be
punted. There is some potential to punt the use only.

Regards,   Martin.

---

From: Toby Speight <[email-masked]>
Date: 14 Oct 1998 10:34:54 +0100

Leslie> Leslie Daigle <URL:mailto:[email-masked]>

0> In article
0> <[email-masked]>, Leslie
0> wrote:

Leslie> 	1. urn:us:ca:   and
Leslie> 	2. urn:us-ca:

PMFJI with a trivial syntax issue, but the usual convention is to use
"." as a hierarchy separator and "-" as a non-hierarchy word separator
(eg in DNS or Usenet).  I can't remember whether "." is allowed in
scheme names, but I think there ought to be some sort of distinction
between the two semantics (using "--", perhaps).

FWIW, I'm in favour of case 2, where namespaces are individually
registered, but have to show a convincing claim to the country code
(but what is considered convincing enough?).

---

From: Leslie Daigle <[email-masked]>
Date: Wed, 14 Oct 1998 10:29:05 -0400 (EDT)

[Leslie's comments as a document editor:]
> This is a dangerous assumption, because it is wrong.

Actually, I mislead you by doing a "short-hand".  No, the ":" in no
way is a standard sub-divider for URNs into sub-namespaces.  My point
was that the designer of a namespace COULD elect to use it as such,
or the character "-", or the character "A", if it comes down to it.
For the purposes of illustration, I made the assumption that the clever
namespace-builder had settled on that as a mechanism for delineating
a subspace.

> only goes that far. "us:ca:" or "us:ca:ssn:" won't be registered

Correct.  The entity registering the "us" namespace can elect to
make clear how it intends to handle sub-namespace delegation (or not),
and where to go to get more information on those sub-namespaces (or not).
The degree to which it does or does not make this information available
defines the degree to which the whole namespace is "publicly interpretable".

> 'depends' or 'don't know yet'".

In any case, the IANA can only handle registrations where the mechanical
process is very clear -- i.e., no value judgements involved.

As for "everybody can come and say...", that's getting a little over-general:
anyone can register a namespace and have a number assigned ("informal"), but
any request for a particlar NID ("formal") goes through the RFC/IESG
process.  I believe that is the appropriate part of the process in which
to insert non-mechanical value-judgements, in open discussion.  When
we have enough "Practice" to determine what is in fact "Best Current", the
IETF can publish an RFC of guidelines for building good URN namespaces
and/or being acceptable as a formal namespace.

> - Change the syntax to change xxx:yyy:... prefix chains into

This is just pushing the problem down a level.

>     IANA according to this document)

It is currently possible to do this, although it is not required.  By
not requiring it, entities have the possibility of  not revealing how
they elect to handle hierarchical delegation.  The cost is that
it is not possible for j-random-client to optimize interactions by
knowing where to go for the sub-delegated parts of the namespace.

> - Go with the "-" solution.

This is not a solution -- it's a can opener sitting right next to a mighty
fine looking can of worms.

> in there, it looks like this may be a bad thing.

See above comments re. generality -- it doesn't HAVE to be.

[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.

Leslie.

---

From: "Larry Masinter" <[email-masked]>
Date: Wed, 14 Oct 1998 11:26:33 PDT

> 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

---

From: Frederick Roeber <[email-masked]>
Date: Wed, 14 Oct 1998 13:51:47 -0700

On the question of reserving all two-letter pairs vs. only reserving
already assigned ISO two-letter country codes:

> all two-letter URN namespaces.

The only reason I suggested this change was that the previous documents
merely reserved the two-letter codes which were already country codes. 
Obviously, that can break the next time someone revolts.  DNS reserves
all two-letter codes -- assigned by ISO or not -- for the same reason.

The issue of whether or not someone can create a meaningful country code
namespace is orthogonal to our reserving "zz" for some future Republic
of Zzyzx.

On the question of reserving country codes at all:

> let the subsequent process for namespace management (described in 
> the rest section 4.0,III. Formal) discuss the appropriateness of

They'll have to go through the procedures anyway.  But reserving their
country codes just means than when Turkmenistan gets around to putting
its phone numbers or document IDs or whatever into URNs, just like the
US, FR, CH, DE, etc. have in the by-then-expected way, it won't discover
that the American trademark office has usurped "tm."

Reserving the two-letter (potential) NIDs for their countries doesn't
mean we endorse or encourage their indiscriminate use.  It just means
that should they prove useful, all countries are equally protected.

I'm not convinced that country codes are the best namespaces, though
there are a lot of national namespaces that could naturally be
grandfathered in in this way.  But at this late a date, unless we have
an overriding other need for two-letter NIDs (e.g., a global character
shortage), I say mark 'em reserved and move on.

-- 
Frederick Roeber

---

From: "Martin J. Duerst" <[email-masked]>
Date: Thu, 15 Oct 1998 15:33:50 +0900

I think Frederick has summarized things very well:

It doesn't make sense to reserve the currently assigned two-letter
country codes. It only makes sense to reserve all two-letter codes,
so that future collisions can be avoided.

---

From: "Martin J. Duerst" <[email-masked]>
Date: Thu, 15 Oct 1998 15:44:06 +0900

> remains the primary criterion upon which it should be discussed.

So if we don't know anything yet, and there are differing oppinions,
why don't we just reserve both us- and us:?

Regards,   Martin.