Subject: Re: [iucg] [vip] The "Invisible Separator Characters" Issue

From: JFC Morfin <[email-masked]>
Date: Tue, 02 Aug 2011 18:37:19 +0200

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

---

From: JFC Morfin <[email-masked]>
Date: Mon, 22 Aug 2011 17:33:58 +0200

At 10:40 22/08/2011, Patrik Fältström wrote:

>On 2 aug 2011, at 18:37, JFC Morfin wrote:
>
> > 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.
>
>A domain name is whatever set of one or more labels you for example 
>can use in a DNS query that together with type and class form the 
>triple on which matching is based.
>What you seem to talk about is one label in a domain name, but not a 
>domain name.

Dear Patrick,

Please remember that when we started the WG/IDNA2008 work, I asked 
Vint if the intent was to address the needs of the users or the needs 
of the Internet, as per the charter. The response from James Seng 
confirmed by Vint was: the needs of the Internet. I then said I will 
develop the ML-DNS to suit the needs of the users based upon the 
IDNA2008 outcome if this was possible. At a given time the debate 
shown it would not be possible and we opposed for that reason. I was 
therefore fired with some "Jefsey's disciples", etc. At the end of 
the day we surprisingly were able to reach a consensus because it 
turned out that the Internet technology was able, in an "unusual" way 
(RFC 5895):

1. to support IDNA2008 on the network side - as per the WG. Hence the 
consensus with our mental restriction concerning othotypographic 
metadata.(e.g. French majuscules)
2. to support IDNA2008 on the user side through what I call "IUI" 
(Internet/Intelligent Use Interface) with the users' machine and its 
applications. Work to be carried somewhere.

I asked IESG/IAB where. They made clear was that the possible IUI 
definition, experimentation, etc. was of potential interest to the 
IETF but was no part of its scope. Hence the need to initiate a place 
to carry that work (IUTF, etc.) and a way to liaise with the IETF as 
an "IETF client". The IUCG which helped the IDNA2008 consensus on our 
side seems to be the proper place for that since it is a user's need.

Now, I have a personal difficulty.

1. The IUI is an architectural component which has to be neutrally 
defined on a general architectural basis.
2. Then I have my own architectural project (I name Internet PLUS) to 
develop and support an IUI. There may be others.

However, the IUI concept being a new one, my own experimental 
implementation will validate it. I am therefore to be careful at not 
confusing what is intrinsic to a subsidiary extension of the Internet 
architecture (I call the SDNS [subsidiary DNS] in the DNS case) and 
what belongs to my own SDNS implementation, I carry through ALFA.

In *my* implementation, the necessary dialog between the user and its 
network piece of intelligence located at the participating IUIs 
(local, host, cybship - i.e. all the other processes controlled by 
the user whatever the machine) can simply be carried by a "netix" 
command set also delivered by what I name "prefixes".

This being said. In my personal project, if we take the 
"xyz.icann.org" domain name, if I can differentiate "xyz", I can 
consider "icann.org" as the registered domain name of ICANN and "xyz" 
as a netix "prefix" which has been introduced prior to that domain 
name - however it looks as being a part of it so it goes through to 
the ML-DNS. The way this prefix is to be used is no part of the 
Internet and of the Internet DNS, but will be filtered and applied by 
the ML-DNS. For example, I can say that "9--2.icann.org" is to be 
understood by the ML-DNS as to stand for a class 2 "icann.org" FQDN, 
the ML-DNS will make the DNS resolve as such.

This means that "9--2.xn--jean-franois-sdb.jefsey.com" will be 
"jean-françois.jefsey.com" in CLASS 2. However, please remember that 
this is only because the ML-DNS acts as a smart middleware 
IDNApplication (cf. the scheme in 
http://iucg.org/wiki/IDNS_Common_Glossary). And with an ML-DNS, 
Internet PLUS experimental implementation.

Why is this important to the IETF? For consistency reasons. Post 
IDNA2008 solutions should be consistent (RFC 1958) to be stable. For 
the time being we have at least seven entities considering them:
- IAB
- UNICODE
- PRECIS at protocol level
- ICANN at DNS governance level
- emerging IUTF at IUI level
- IUCG at user satisfaction level
- and me at research and experimental level.
I am sure there are others.

Hence, my effort to get a common glossary and communication to help 
problems mutual understanding,
jfc

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 22 Aug 2011 10:40:47 +0200

On 2 aug 2011, at 18:37, JFC Morfin wrote:

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

A domain name is whatever set of one or more labels you for example can use in a DNS query that together with type and class form the triple on which matching is based.

What you seem to talk about is one label in a domain name, but not a domain name.

   Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 22 Aug 2011 20:06:59 +0200

On 22 aug 2011, at 17.33, JFC Morfin wrote:

> This being said. In my personal project, if we take the "xyz.icann.org" domain name, if I can differentiate "xyz", I can consider "icann.org" as the registered domain name of ICANN and "xyz" as a netix "prefix" which has been introduced prior to that domain name - however it looks as being a part of it so it goes through to the ML-DNS.

My only point, which I reiterate, is that xyz.icann.org is a domain name, as is icann.org and org. Three different domain names.

Please do not use the term "domain name" for anything else.

   Patrik

---

From: JFC Morfin <[email-masked]>
Date: Tue, 23 Aug 2011 02:06:22 +0200

At 20:06 22/08/2011, Patrik Fältström wrote:

> consider "icann.org" as the registered domain name of ICANN and 
> "xyz" as a netix "prefix" which has been introduced prior to that 
> domain name - however it looks as being a part of it so it goes 
> through to the ML-DNS.
>
>My only point, which I reiterate, is that xyz.icann.org is a domain 
>name, as is icann.org and org. Three different domain names.

Dear Patrik,
however happy I would be to deffer to your wishes, I am lost at 
understanding what they are?

1. xyz.icann.org is a domain name, as is icann.org and org. Three 
different domain names.
2. in these domain names "org" is their TLD or suffix or first level label.
3. xyz, icann, and org are respectively their upper level label. I 
claim the capacity to call them their prefixes.

If you have a problem with that I can also call them their ULL, and 
their TLD their FLL. However, this sounds less multilinguistic and 
unecessarily sophisticated?

Best.
jfc