Subject: Re: [iucg] Katakana Middle Dot again (Was: tables-06b.txt: A.5, A.6, A.9)

From: Elisabeth Blanconil <[email-masked]>
Date: Sat, 8 Aug 2009 11:58:22 +0200

Dear Andrew,
I was refering to John's Draft I quoted further on. The difficulty
with the DNS terminology is that "DNS" is taken for many different
things: namespace, system, protocol, nameservers, business, etc. in
which IDNA does not initially belong. IDNA does not know dnames and
cnames, it only knows IDNs. This lack of a properly termed
architectural model is most probably the main difficulty we meet.

This is something Jefsey's Interplus Draft partly addresses. Only
partly, however, and we currently discuss how to clarify it. This is
because we did not realise that in the geek's mind the Internet was so
much network centric, while it is not, and the use we consider is
people centric. IDNA is a _client_ of the DNS which in turn depends on
the decisions of zone managers. We only are interested in IDNA, not in
DNS.

Now, I am not sure - but I am not a logician - that dname/cname
properties cannot be transitive; and what would be the UTF-8/punycode
implications (let assume that a TLD accepts UTF-8) and the
corresponding DNAME does not (I am not sure this case was discussed
yet?).

Elisabeth Blanconil

2009/8/8 Andrew Sullivan <[email-masked]>:
> I don't have time to reply properly right now, let alone from a decent MUA,
> so apologies in advance. John is quite right: there is _in principle_ no way
> to know what "domain" a given label is "in", because at least of cname and
> dname. Sorry, but the DNS just does not work as you seem to assume.
>
> Andrew Sullivan
> [email-masked]
>
> On 2009-08-07, at 17:38, Elisabeth Blanconil <[email-masked]> wrote:
>
>> Dear John,
>> I do not understand some of your remarks.
>>
>> 2009/8/7 John C Klensin <[email-masked]>:
>>>
>>>
>>> --On Friday, August 07, 2009 22:13 +0200 Elisabeth Blanconil
>>> Except that a "TLD table inheritance system" is impossible in a
>>> DNS in which it is not, in the general case, possible to tell
>>> which TLD a label is actually part of and in which a given node
>>> can be effectively a subtree of multiple trees.
>>
>> I am afraid "impossible" only means that some R&D is to be carried.
>> Hence my allusion to RFC 3869.
>>
>>>> Was it not at a time a proposition by John Klensin?
>>>
>>> Nope.
>>
>> I refered to
>> http://ietfreport.isoc.org/all-ids/draft-klensin-idn-tld-00.txt
>>
>> Sorry, if I did not understand the underlying idea. If there are
>> tables to translate TLDs, it means that TLDs are identified.
>>
>>>> Ooops! This would have been a problem for "internationalized"
>>>> money making gTLDs ICANN wants to sell.
>>>
>>> No, actually, some of the "Rich people" who want those domains
>>> would undoubtedly like the freedom to do whatever they like
>>> even to use character coding systems other than Unicode.  So you
>>> need a different conspiracy theory and/or source of innuendo.
>>
>> I am afraid you misuderstand the commercial point here. Coca-Cola does
>> not want to fool around with ".coke". They want something stable and
>> unique. TM protection is not in freedom, but in enforced rules. The
>> same for .com.
>>
>> Freedom is great for IDN TLDs, not for global TLDs.
>>
>>> 3869 doesn't discuss "development priority".  It discusses
>>> relatively long-term research priorities.
>>
>> It intends to suggest that a broad range  of ongoing research is
>> needed, and to propose some candidate topics. IDNA is not one however
>> new namespaces are considered.
>>
>>>  If you would like to
>>> put IDNs into that category and accept the five or ten year wait
>>> it would imply, I'm sure I can find people who would be
>>> sympathetic to that idea.  But I'm not one of them and I suspect
>>> that few participants in the WG are either.
>>
>> IDNs were introduced on the Internet in 1998.
>>
>>>> IMHO the
>>>> real issue is to make sure in the final wording that Class,
>>>> TLD, presentation, or Zone related character restrictions or
>>>> exceptions can be documented without contradicting the
>>>> proposed text - in order to avoid unnecessary conflicts.
>>>
>>> I wish I had a better idea what you are talking about and
>>> whether it was relevant to the WG.
>>
>> I only mean that zone managers will have to deal with the final texts.
>> And that we have to make sure no one can use these texts to insert
>> hidden MUSTs, for example in the way to implement them or to contract
>> their use.
>>
>> Best.
>>
>> Elisabeth Blanconil
>> _______________________________________________
>> Idna-update mailing list
>> [email-masked]
>> http://www.alvestrand.no/mailman/listinfo/idna-update
>

---

From: jefsey <[email-masked]>
Date: Sat, 08 Aug 2009 20:40:24 +0200

John,
Elisabeth is probably influenced by my often repeated regret that the 
WG-OPES wasted its time with SMTP instead of working on DNS as I 
proposed, after HTTP. SMTP was a far too complex a model, while DNS 
was a real need. Many of the problems we meet result from a 
misunderstanding of the nature of (the network) "time". Time can be a 
date or a succession indicator. Date is transitive. Succession is 
not. We consider the resolution time as a date, instead  of 
considering it as a succession process, so we get our own Heisinberg 
limitations. Such as not being able to identify the TLD.

Now, let consider runing a nameserver with an OPES acting as a ONES 
shim (open networked extended service/overlay network executive 
system). If that shim had not been implemented the TLD received by 
the nameserver is the one the user has entered or the one the 
nameserver has DNAMEd. If it has been implemented the TLD received by 
the nameserver is the "DNAMEd" TLD, with possible meta-data that the 
ONES may deliver (the first of them is the TLD actually requested by 
the user). That ONES can cover the entire network and act as a 
pre-DNS unique front-end converting HANS ".com" in ASCII ".com", i.e. 
supporting your proposition. BTW this is orthogonal to IDNA. This 
means that IDNA users may or may not use it.

IMHO this is a possible answer to the mess the Interplus is going to 
permit and the lack of possiblility to enforce IDNA. It means that 
nameservers operators may subscribe to such a ONES as part of their 
Interplus MDRS (Multilingual Distributed Reference System/Meta-Data 
Registry Structure) choice, and filter/pre-process/security-check the 
requests. There will be no change in their installation but they will 
be able to resolve Class x ibm.com requests as Class IN 
class-x.ibm.com. A way to protect famous TMs even in alt-roots.

What I regret is that we will have to consider this quickly as a 
patch while it is a long standing unused Internet technology feature. 
Just remember that the basic difference between the Internet and the 
Interplus amphitem (encapsulating system) is that the Internet 
supports passive content, and the Interplus adds "post-wire" support 
of the active content. The Interplus is a client network and the 
internet is a server network. So the (meta)data received by the 
Internet from the Interplus are not necessarily those of the 
"off-wire" User Client or Interface.

JFC

At 14:07 08/08/2009, John C Klensin wrote:
>Content-Transfer-Encoding: base64Content-Disposition: inline
>
>--On Friday, August 07, 2009 23:38 +0200 Elisabeth Blanconil
><[email-masked]> wrote:
>
> > Dear John,
>HÈnot understand some of your remarks.
> >
> >ƒâ£ãâÒÔöâg&F'ÂVwW0t 07, 2009 22:13 +0200 Elisabeth Blanconil
> >^Ù\] a "TLD table inheritance system" is impossible in
> >> a DNS in which it is not, in the general case, possible to
> > tell which TLD a label is actually part of and in which a
> >> given node can be effectively a subtree of multiple trees.
>‚'Òg&B&×÷76&ƒ"öæÇ'ÖVç2F†B6öÐe R&D is to be
> > carried. Hence my allusion to RFC 3869.
>
>No.  "Impossible" in this case means that, especially with
>DNAMEs, doing resolution or matching with different rules based
>on location in the tree is not possible without _very_
>significant changes to the DNS, changes so significant that the
>result would essentially be a new, replacement, DNS.   It is not
>about minor tuning to IDNs or the equivalent.
>
> >ˆØ\È]›Ý]H[YHH›ÜÜÚ][ÛˆžH›Àhn Klensin?
> >> Nope.
> >
> > I refered to
>Ah.  That proposal.  That proposal has nothing to do with this
>discussion and is related to TLDs only.  It would not work lower
>in the tree, even at the second level, and works for TLDs only
>if IDN TLDs for countries (or country-like economics or other
>entities) are prohibited entirely and, probably, that the number
>of new TLDs of any type is significantly limited.  ICANN has
>decided to go in the opposite direction.  I don't consider that
>set of ICANN decisions wise, but, to paraphrase and update an
>old American saying, my opinion and a few dollars will buy a cup
>of coffee-flavored milk.
>
>The summary of that proposal would be:
>
>         (i) No IDN ccTLDs at all and probably no IDN TLDs.
>
>         (ii) Each localized application (browser or otherwise)
>         has its own table of TLDs of interest and local names,
>         in the local language, and performs translations as
>         needed.  Those translations are a function of the
>         localized software and do not occur in (or anywhere
>         near) the DNS.
>
>         The net effect of the above is that, as far as the
>         localized user is concerned, all relevant TLDs exist in
>         the local language.  That user doesn't really care what
>         some other country is called in that country's language,
>         only about what it is called locally.  For example, for
>         one of your users, it would be much more useful to be
>         able to refer to the TLD for the country to your east as
>         "Allemagne" than to be concerned about what either its
>         residents call it or about what I (or someone else)
>         might call it.
>
>         (iii) People traveling outside their preferred localized
>         environment either need to know and use the global form
>         or to have a way to carry their localizations with them.
>
>The third comment above of course has very general
>applicability.  As soon as we start to do _any_ localizations,
>those localizations have to be portable or users who move
>outside the locality (geographically or from a
>software-selection standpoint) are going to also need to know
>the global forms (inconvenient and unnatural as they may be).
>Much of the argument about mapping has been this issue in
>disguise: if one forces everyone into a single global format and
>terminology, one gets better global interoperability; if one
>permits (or encourages) localization to make things easier for
>casual users, then one has to be careful --and tolerate extra
>measures-- in order to avoid losing global interoperability.
>
>This model has no consequences at all for domains below the top
>level.  At that level, if the domain administrator wants to make
>things easier for a speaker of a given language, she can create
>alternate entries, aliases, etc., for those speakers without
>either having to make the root huge or engaging in international
>politics.
>
>ÛÜœžKYˆHY›Ý[™\œÀtand the underlying idea. If there
>\™HX›\ÈÈ˜[œÛate TLDs, it means that TLDs are
> > identified.
>
>That model requires a list of TLDs of interest (possibly a
>different list for each localized application-instance).  That
>list is not part of IDNA or the DNS.    And, in particular, it
>doesn't have anything to do with how names further down in the
>tree are interpreted.
>
> >ˆÛÛÜÈH\ÈÛÝ[ave been a problem for "internationalized"
> >ˆ[Û™^HXZÚ@ng gTLDs ICANN wants to sell.
> >>
> >›ËXÝX[KÛÛYHÀf the "Rich people" who want those domains
> >ÛÝ[[™Ý@btedly like the freedom to do whatever they like
> >]™[ˆto use character coding systems other than Unicode.  So
> >> you need a different conspiracy theory and/or source of
>ˆ[›Y[™‹ˆˆH[HYœ˜ZY[ÝHZ\ÝY\œÝ[™HÛÛ[@ercial point here.
> > Coca-Cola does not want to fool around with ".coke". They want
> > something stable and unique. TM protection is not in freedom,
> > but in enforced rules. The same for .com.
>
>We may need to agree to disagree but, while I believe that what
>you are saying is quite sensible and that stability, uniqueness,
>and decent rules are the key to predictable and usable behavior
>(and, incidentally, the ability to localize), that is _not_ the
>direction in which the marketplace is headed.
>
>And the peculiarity of the "should control pass from ICANN
>and/or the US Govt to someone else" debate, whether carried out
>in the US Congress, in IGF, or elsewhere, is that it isn't about
>stability and uniqueness versus a domain names market that
>concentrates on a rather different set of issues, but about who
>should control, manage, and maybe profit from that market.
>
>The nature of the DNS is that any TLD is inherently global.  The
>focus of their registrations may differ as a matter of policy,
>but accessibility --and consistency of the rules with which they
>are accessed and names are interpreted-- are very much global
>whether we like it or not.   If we don't like it, the only
>options are to layer localizations on top of the DNS (and now on
>top of IDNA) without changing the DNS or IDNA --and that is
>exactly what the proposal to which you refer was about-- or to
>junk the DNS and start over.
>
> >...
>ˆ0¨Yˆ[ÝHÛÝ[ZÀe to
>ˆ]QœÈ[È]Ø]YÛÜžH[™XØÙ\Hš]™HÀr ten year
>ˆØZ]]ÛÝ[[\KIÛHÝ\™HHØ[ˆš[™@ople who would be
> >> sympathetic to that idea.  But I'm not one of them and I
> >Ý\ÜXÝ]™]È\XÚ\[È[€ the WG are either.
>‚"Dç2vW&RçG&öGV6VBöâF†RçFPrnet in 1998.
>
>Sigh.  Even earlier than that, actually.   But, if you think
>that is relevant, it is yet another reason why they are not a
>research topic.
>
> >...
>ˆHÚ\ÚI had a better idea what you are talking about and
>‚'öæÇ'ÖVâF†B¦öàe managers will have to deal with the
>š[˜[^Ëˆ[™that we have to make sure no one can use
>\ÙH^ÈÀ insert hidden MUSTs, for example in the way to
> > implement them or to contract their use.
>
>And so[ÝHÛÝ[Ú@nge what about what we are doingIÛB˜[ÛÈÛÛ˜Ù\›™YX›Àut 
>"make sure" because, ultimately, we have no
>enforcement mechanism other than the consequences of misbehavior
>causing loss of interoperability.
>
>regards,
>     john
>

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 8 Aug 2009 22:11:00 -0400

Yet again we are in deep confusion caused by sloppy terminology. The  
problem is not just a TLD that resolves to a dname.

AIUI, the idea here is that policies in the TLD recurse down the tree  
to subordinate zones. But this is what A cname or dname foils. For it  
is easy to make a cname from www.example.org to interstupendousplus.exemple.fr 
. Now whose policies apply?  Org's or fr's?  I can make a strong  
argument for either one, depending on which you pick. And none of this  
even begins to scratch the surface of what "applying" means here.

The DNS just isn't subject to central planning the way you seem to  
think it is. Once the namespace is delegated, the delegator loses  
control, period.

Andrew Sullivan
[email-masked]

On 2009-08-08, at 14:40, jefsey <[email-masked]> wrote:

> John,
> Elisabeth is probably influenced by my often repeated regret that  
> the WG-OPES wasted its time with SMTP instead of working on DNS as I  
> misunderstanding of the nature of (the network) "time". Time can be  
> a date or a succession indicator. Date is transitive. Succession is  
> nameserver has DNAMEd. If it has been implemented the TLD received  
> by the nameserver is the "DNAMEd" TLD, with possible meta-data that  
> the ONES may deliver (the first of them is the TLD actually  
> requested by the user). That ONES can cover the entire network and  
> act as a pre-DNS unique front-end converting HANS ".com" in ASCII  
> ".com", i.e. supporting your proposition. BTW this is orthogonal to  
> IDNA. This means that IDNA users may or may not use it.
>
> Registry Structure) choice, and filter/pre-process/security-check  
> the requests. There will be no change in their installation but they  
> will be able to resolve Class x ibm.com requests as Class IN class-x.ibm.com 
> . A way to protect famous TMs even in alt-roots.
>
> patch while it is a long standing unused Internet technology  
> feature. Just remember that the basic difference between the  
> Internet and the Interplus amphitem (encapsulating system) is that  
> the Internet supports passive content, and the Interplus adds "post- 
> wire" support of the active content. The Interplus is a client  
> network and the internet is a server network. So the (meta)data  
> received by the Internet from the Interplus are not necessarily  
> those of the "off-wire" User Client or Interface.
>
> JFC
>
>
>> H»not understand some of your remarks.
>> >
>> >É‚£„‚“‘ˆ‚g&≠F'¬VwW0t 07, 2009 22:13 +0200  
>> Elisabeth Blanconil
>> >^Ÿ\] a "TLD table inheritance system" is impossible in
>> Ç'“g&≠B&≠◊˜76≠&É"ˆÊ«'÷VÁ2FÜB6ˆ–e R&D is to be
>> >àÿ\»]õ›]H[YHHõ‹‹⁄][€àûHõ¿hn Klensin?
>> >> Nope.
>> >
>> > I refered to
>> €‹úûKYàHYõ›[ô\ú¿tand the underlying idea. If there
>> \ôHXõ\»»ò[ú€ate TLDs, it means that TLDs are
>> > identified.
>>
>> >à€€‹»H\»€›[ave been a problem for "internationalized"
>> >à[€ô^HXZ⁄@ng gTLDs ICANN wants to sell.
>> >>
>> >õÀX›X[K€€YH¿f the "Rich people" who want those domains
>> >€›[[ô›@btedly like the freedom to do whatever they like
>> >]ô[àto use character coding systems other than Unicode.  So
>> à[õùY[ôãèàèàH[HYúòZY[›HZ\›Y\ú›[ôH€€[@ercial  
>> point here.
>> à0®Yà[›H€›[Z¿e to
>> à]Qú»[ù»]ÿ]Y€‹ûH[ôXÿŸ\Hö]ôH¿r ten year
>> àÿZ]]€›[[\KI€H›\ôHHÿ[àö[ô@ople who would be
>> >›\‹X›]ô]»\ùX⁄\[ù»[Ä the WG are either.
>> Ç"DÁ2vW&R≠ÁG&ˆGV6VBˆ‚FÜR≠ÁFPrnet in 1998.
>>
>> àH⁄\⁄I had a better idea what you are talking about and
>> Ç'ˆÊ«'÷V‚FÜB¶ˆ‡e managers will have to deal with the
>> ö[ò[^Àà[ôthat we have to make sure no one can use
>> \ŸH^»¿ insert hidden MUSTs, for example in the way to
>> And so[›H€›[⁄@nge what about what we are doingI€Bò 
>> [€»€€òŸ\õôYXõ¿ut "make sure" because, ultimately, we  
>> have no

---

From: JFC Morfin <[email-masked]>
Date: Sun, 09 Aug 2009 20:33:44 +0200

At 04:11 09/08/2009, Andrew Sullivan wrote:

>is easy to make a cname from www.example.org to 
>interstupendousplus.exemple.fr . Now whose policies apply?  Org's or 
>fr's?  I can make a strong argument for either one, depending on 
>which you pick. And none of this even begins to scratch the surface 
>of what "applying" means here.
>

Correct for the "DNS" taken as the currently implemented software 
system. And we do not want to change that software system.

Correct for the "DNS" taken as the currently understood naming 
system. The resulting distributed responsibility is the key point in 
favor of DDDS in distributed technologies/environments. However in 
the "DNS.1" process that you describe there is an entropy loss that 
network services can overcome (they can even become a feature of the DNS.2 ?)

In the case you quote:
- either the DNS is used without any additional edge service and at 
each change the then current rules should transitively apply as it 
seems to result from general DDDS architecture?
- or the DNS is used with edge services that may deny, correct, 
document, or/and propagate the change and act upon that information.

In either cases, there is only a problem if the user is not informed 
of the functional rules being in use; if the naming topology cannot 
be properly configurated; or if that configuration is not analyzed 
enough. This certainly is an area to investigate.

The urgent problems we really face, as I see them, are:

1) that the architecture was initially a decentralized master/slave 
architecture, then a decentralized client/server, and now has to be a 
"people in multilingual distributed society driven server 
network/client network/user client" architecture. I do not think we 
can make it if we do not uncouple the issues and keep each element at 
the single task it does well. This is why there should be no change 
(what permits easier replacement, enhancements and transitions) in 
the existing building blocks, but implement additional building 
blocks that will organize new synergies and not to expect that 
miraculously or through IETF due disputation process more will 
"emerge" from the Internet system than there is in the sum of each of 
its parts.

2) the content that the Internet propagate is passive. There is now a 
need to support active content. This is the Interplus area. Active 
content, that integrate "post-wire" services, is a necessity for the 
Intersem strata "off-wire" intelligent relation facilitation mind to 
mind services (what is related to interintelligibility on top of 
interoperability). The practical difficulty is to introduce the 
Interplus in trying to protect usage from confusion. This confusion 
comes from the fact that the Interplus is only an open minded reading 
of the existing internet technology that everyone can make, and that 
the same technology has not built yet enough protection against its 
oneself. It is a bis of the security issues. It must therefore be 
introduced in a way which is both attractive (so people do not try 
something different) and which includes the protections the Internet 
misses, in addition to its own protections.

jfc