Re: [domainrep] JSON namespace administration

[Dave CROCKER <[e-mail]>]

(it occurs to me that I make clear that I'm wearing my participant hat for this 
thread, not chair...)



On 11/14/2011 8:20 AM, Peter Saint-Andre wrote:
> On 11/14/11 7:41 AM, Dave CROCKER wrote:
>> On 11/14/2011 7:38 AM, DIEGO LOPEZ GARCIA wrote:
>>> The usual practice for Java class naming prefixes: "com.sun.javax"
>>
>> 1. Java has nothing to do with the activities in this working group.
>
> True, but there is a convention behind Java class naming, called "reverse domain
> name" (wherein the class "foo" developed by the folks at example.com is
> disambiguated as "com.example.foo"). We mention this in
> draft-ietf-appsawg-xdash, and draft-saintandre-json-namespaces will talk about
> this in the next version.

This is, of course, the same set of naming issues as the DNS.  The #2 point, 
below, applies to this as well as the DNS.

Yes, having different branches helps, but you still need an authority for each 
node, to ensure no name collisions for that sub-tree.


>> 2. The essence of name disambiguation is a function that operates during
>> name assignment to ensure no collisions.
>>
>> Your reference does not ensure that #2 is satisfied.
>
> Dave, could you explain that a bit further?

The issue has been confusing to many folk active in ICANN-related DNS debates, too.

To be clear, the core rule is:

      For any (sub-) namespace, the mechanism of assigning names
      MUST have a means of ensuring that name collisions do not occur.

The premise behind the original statement was that merely having the hierarchy 
fixes the problem.  It doesn't.

Having a hierarchy creates many, smaller namespaces, each of which needs a means 
of protecting against collisions.

That is, for any node in the tree, there can be sub-nodes.  Sub-nodes under the 
same node can have colliding names.  Some mechanism -- whether a naming rule or 
a registry function -- is needed for that node to ensure that sub-node names are 
not multiply assigned.

Usually, the implicit thinking behind the assumption that sub-names "fixes" the 
problem is actually that the sub-name assignment activity is extremely local and 
therefore a single person or tiny group is doing the assignment and won't step 
on each other's naming choices.  That's fine, but the key point is


-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net