Katakana Middle Dot again (Was: tables-06b.txt: A.5, A.6, A.9)

Elisabeth Blanconil eblanconil at gmail.com
Sat Aug 8 11:58:22 CEST 2009


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 <ajs at shinkuro.com>:
> 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
> ajs at shinkuro.com
>
> On 2009-08-07, at 17:38, Elisabeth Blanconil <eblanconil at gmail.com> wrote:
>
>> Dear John,
>> I do not understand some of your remarks.
>>
>> 2009/8/7 John C Klensin <klensin at jck.com>:
>>>
>>>
>>> --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
>> Idna-update at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/idna-update
>


More information about the Idna-update mailing list