[vip] The "Invisible Separator Characters" Issue

[JFC Morfin]

At 15:58 02/08/2011, Andrew Sullivan wrote:
>On Tue, Aug 02, 2011 at 03:41:04PM +0200, JFC Morfin wrote:
> > At 11:22 29/07/2011, Nicholas Ostler wrote:
> > >>The DNS only have three parameters in a query: {owner, type, class}.
> >
> > Incorrect. It also has the prefix and the TLD that can be used to
> > support presentation elements.

Dear Andrew,

I am afraid my proposition is not as tricky as you are afraid. But 
better I explain it so, you can criticize it if I was wrong. I am 
also interested in your draft.
It only relates to few things I propose and we tested for more than a 
decade as "quiest" and also my point that unicode is inadequate to neworking.
None has any impact with the DNS.

By TLD I mean TLD and by prefix I mean whatever label(s) someone may 
want to conventinally introduce prior to the domain name he/she uses. 
I quote them together because both can be used together.

1. "zonale" (and netlocale about the . This only means that a TLD 
manager should maintain a possibly empty information center at 
zonale.tld, as ut uses to operate a nic.tld or a www.tld. And that 
this ZIC provides presentation oriented information and IDN tables. 
This will be simpler, faster and more equal to everyone than the IANA 
where only  $ 187.000+ TLDs and ISO 3166 ccTLDs can be documented 
(please remember that my logic for 1/3 of century is ICANN/ICP-3-Part 5)

2. "prefix". I personally hate the WHOIS which violates every privacy 
law throughout the world and is of very low interest in terms of 
possibly included data. For years I advocate the quiest.domain.name 
optional formula for people to say what they want about themselves, 
or nothing. There is no difficulty in having a list of such 
registries, sub-hosts, or pages that can be used to give formated 
information on the host, its relational spaces, its policy, its zonale, etc

Obviously the prefix.tld or prefix.zic.tld or prefix.nic.tld or 
prefix.www.tld can be used to give TLD zone information.

>Zone cuts in the DNS are there for the administrative convenience _of
>the DNS_, and are not in themselves any kind of information about
>administrative boundaries for policy.

:-) this is something you should explain to ICANN@ 185.000 per zone.
Actually I would suggest that every TLD supports an icann.tld name 
where it would document its relations with ICANN, the amount it pays 
to ICANN, etc.
And obviously a variants.TLD if they are not documented in the zonale file.

>The misunderstanding of this
>distinction, for instance, is a primary reason that http cookies are
>subject to so many woeful security problems, and why we have ended up
>with preposterous mechanisms like publicsuffix.org.

However, a very interesting initiative in terms of relation to the 
DNS orgnanization and monetary value.

>The reason policy is important and unusual at or near the root is not
>because those zones are somehow special, but because they mostly do
>delegation out to other operators, so innovations at those points in
>the tree are places that can affect a large number of other zones.

Sure, but you know that I have an heterarchical vision of the top 
zone. So, it is technically slightly less important to me than to 
you. But it can certainly be highly confusing for many. This is why 
variants should be carefully treated in coordination with all the 
other use of names, in every technology.


>Therefore,
>
> > I think it is time to introduce the concept of "zonale" definition
> > file that document the parameters of a TLD relational space.
> > For example, the .FRA zonale will document the sensitivity of .FRA
> > domain names to majuscule.
>
>if what you are suggesting is that it needs to be possible to track
>down certain policy rules about a zone by looking up the location of
>such a policy in the DNS, along with rules about what to do if a zone
>doesn't come with a policy, then I might agree (and indeed, I
>committed during IETF week to put out a draft along these lines).

This is an interesting news. The question is about the DNS itself 
beeing used as a data repository, or a DDDS or a linked registry, or 
some SQLite engine. I am personally interested in investing some 
effort this summer time in ISO 11169 and see how to amalgamate the 
concepts involved in all this. I am considering building from scratch 
a multi-registry server as part of the ML-DNS support.

>  If
>you're suggesting instead that we use the mere fact of the fully
>qualified domain name's labels to entail different formatting
>conventions, then I predict widespread failure from such simple
>inferences.

I am not sure I understand what you mean, unless you are afraid that 
I try to infer some information from the simple, common way a FQDN 
looks like. This is not the case.
Best
jfc