Subject: [domainrep] JSON namespace administration

From: Dave CROCKER <[email-masked]>
Date: Fri, 11 Nov 2011 07:33:22 +0800

Folks,

Nihao.

I'm not finding the mail that raised this (perhaps on a different list) but I 
seem to recall seeing a concern raised about JSON's current ability to handle 
namespace administration.  (St.Andre's active draft on this does imply there is 
a real issue.)

Since the Repute work needs to support an extensible namespace for reputon 
attributes, this seems to be a highly relevant concern for the working group, if 
JSON is chosen as the representation format.

Can anyone clarify the issue(s), tradeoffs, existing experience, etc.?

Thanks.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Sun, 13 Nov 2011 16:03:00 +0100

> Can anyone clarify the issue(s), tradeoffs, existing experience, etc.?

I'm not that familiar with Peter's active draft, but as far as I can tell I cannot foresee any namespace collision that could not be sorted out with good-ole reverse domain disambiguation. And JSoN buys you compactness, efficiency for marshalling and unmarshalling and (last but not least) a much simpler way to do signing (cf. the works of the JOSE WG)

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:      +34 913 129 041
-----------------------------------------

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 14 Nov 2011 04:12:28 +0800

On 11/13/2011 11:03 PM, DIEGO LOPEZ GARCIA wrote:
>> attributes, this seems to be a highly relevant concern for the working
>> group, if JSON is chosen as the representation format.
>>
> I'm not that familiar with Peter's active draft,

Your ability to contribute to the working group discussion will be enhanced by 
becoming familiar with the material being referenced.

In fact, there is a cliche in the IETF, which goes:  "I haven't read the draft, 
but here are my comments on it..."

 > but as far as I can tell I
> cannot foresee any namespace collision that could not be sorted out with
> good-ole reverse domain disambiguation.

What is "reverse domain disambiguation" and how is it a satisfactory alternative 
to simple, direct name registration?

d/

-- 

   Dave Crocker

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Mon, 14 Nov 2011 00:38:17 +0100

> to simple, direct name registration?

The usual practice for Java class naming prefixes: "com.sun.javax"

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:      +34 913 129 041

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 14 Nov 2011 07:41:12 +0800

> The usual practice for Java class naming prefixes: "com.sun.javax"

1. Java has nothing to do with the activities in this working group.

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.

d/

-- 

   Dave Crocker

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 14 Nov 2011 08:20:35 +0800

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

> 2. The essence of name disambiguation is a function that operates during
> name assignment to ensure no collisions.
>

Dave, could you explain that a bit further?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 14 Nov 2011 08:44:24 +0800

(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:
> 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.

> 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

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 14 Nov 2011 08:53:27 +0800

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

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!

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 15 Nov 2011 07:09:33 +0800

On 11/14/11 8:53 AM, Dave CROCKER wrote:

> 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!

Yes, that's true, but the thinking seems to be that at least it 
localizes the problem, and that if the folks at example.com are 
disorganized they will likely bear the brunt of the costs. Whether 
that's borne out in experience is another question...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 14 Nov 2011 18:32:02 -0500

> that's borne out in experience is another question...

It seems to me that in the DNS (a hierarchical namespace that we have
deployed and so can use as an analogy), when one has differences in
the smaller namespaces that are not consistent across those
namespaces, someone comes up with a plan to make them consistent in
some way, and everybody gets to bear those costs.  So I'm not sure I
agree with this line of argument.

-- 
Andrew Sullivan
[email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 15 Nov 2011 07:41:52 +0800

> agree with this line of argument.

I must be missing something. Can't the folks who manage subdomains of 
(say) wordpress.com bungle things just as badly as the folks who manage 
the classpath under (say) com.sun.java?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 15 Nov 2011 08:23:41 +0800

On 11/15/2011 7:41 AM, Peter Saint-Andre wrote:
> I must be missing something. Can't the folks who manage subdomains of (say)
> wordpress.com bungle things just as badly as the folks who manage the classpath
> under (say) com.sun.java?

There's an extremely simple way to resolve this issue with respect to the DNS:

      When the DNS is queried, is it possible for the name to be ambiguous?

(Hint:  The answer is no.)

However it is done, some process ensures that each node in a domain name is 
unique within the namespace of that node.

d/

-- 

   Dave Crocker

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 14 Nov 2011 20:40:12 -0500

On Tue, Nov 15, 2011 at 07:41:52AM +0800, Peter Saint-Andre wrote:
> I must be missing something. Can't the folks who manage subdomains
> of (say) wordpress.com bungle things just as badly as the folks who
> manage the classpath under (say) com.sun.java?

Of course they can.  But think of what we've started asking from the
hierarchical namespace I'm using as an analogy.

We had, for instance, the http cookies specification, that relied upon
certain assumptions of what various namespaces were _for_ in order to
draw conclusions about processing things inside that namespace.  Then
people discovered that the namespace didn't work the way they wanted,
and developed for themselves a special side namespace registry
(publicsuffix.org) that identified properties of those namespaces.
This side registry is synchronized by hand with the public registry
rooting the namespace.

We had the TXT record, which was supposed to be for free-form text at
a name in the namespace, but which has been altered in some
interesting ways depending on special things in the namespace (like
underscore labels) such that names may make declarations about other
parts of the namespace.  These underscore labels appear in all sorts
of different ways, so people want those features of the namespace to
start to be used in slightly more regular ways (although at the
moment, there's no standard for this, and there's no practical way to
manage it anyway).  This greater regularity is supposed to help
developers know how to interpret things -- so much so that you now
hear people talking about "underscore labels" as though they're some
sort of special class of labels (I do this myself -- no criticism is
intended), even though formally the namespace doesn't work that way.

We have a lot of tension in internationalization inside the namespace
because of the different ways people might have done things -- and for
that matter a lot of tension inside the way you use the namespace at
all because of the way that namespace interacts with other,
technically distinct but somehow related namespaces.

I'm not suggesting that a hierarchical namespace can't bring the
isolation benefit you were arguing it brings.  I'm suggesting,
however, that distributed management may later cause requests that
people have to do their distributed management in consistent ways, so
that people (or more likely, naive coders) aren't too surprised, and
in such cases the isolation benefits aren't quite as great as one
might imagine, because they come with the cost that everyone has to do
their management in similar ways (which causes a co-ordination
problem).  I don't have a strong feeling about what to do, I'm just
pointing out a possible consequence.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 15 Nov 2011 09:44:06 +0800

> hierarchical namespace I'm using as an analogy.

<snip/>

This is all interesting, but I think it's out of scope for REPUTE. Shall 
we move this discussion to apps-discuss?

/psa

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 15 Nov 2011 09:58:21 +0800

> This is all interesting, but I think it's out of scope for REPUTE. Shall we move
> this discussion to apps-discuss?

Unless I've missed a core issue, I think the only question that was being 
pursued here was about ensuring name uniqueness.  The rest of what has surfaced 
is interesting and possibly worth pursuing but, yes, I suspect it is out of 
scope for this wg.

d/

-- 

   Dave Crocker

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 14 Nov 2011 21:10:00 -0500

On Tue, Nov 15, 2011 at 09:58:21AM +0800, Dave CROCKER wrote:
> Unless I've missed a core issue, I think the only question that was
> being pursued here was about ensuring name uniqueness.  The rest of
> what has surfaced is interesting and possibly worth pursuing but,
> yes, I suspect it is out of scope for this wg.

And the only point I wanted to make was that reaching for a
hierarchical namespace seemed to me to be inviting some other
long-term consequences that might have negative effects. 

A

-- 
Andrew Sullivan
[email-masked]