Re: [domainrep] JSON namespace administration

[Dave CROCKER <[e-mail]>]

(re-send.  not sure how the partial draft got posted.)


And it occurs to me that I should 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 in the earlier message 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.  This local 
scope assume that assignments won't step on each other's naming choices.

In practical terms, this often works well, but it does not contradict the core 
rule stated above.

To the extent that name hierarchy are used, to create local names spaces with a 
simpler basis for avoiding conflicts, there of course needs to be a means of 
creating the naming hierarchy (without name conflicts.)  It's fine to import an 
existing means of doing this, but that important needs to be part of the full 
specification for naming.


d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net