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