Mail exchange with Vint Cerf in 2009
The context of the discussion was : is the network DNS ruling the people's use or the people using the whole DNS capabilities (them being currently commonly used or not).
On Jul 1, 2009, at 6:00 AM, JFC Morfin wrote:
Please do not confuse user domain names and DNS domain names. It take one minute to contradict you in using Host.txt.
At 00:47 02/07/2009, Andrew Sullivan wrote:
Clearly, if you enter stray data into the system, you can get a different result. That's nowise a premise in favour of your view.
On Jul 2, 2009, at 6:00 AM, JFC Morfin wrote:
The point is what what do you mean by "stray" and by "system".
I feel you do not make a difference between what the user enter in the application and what the DNS receives as a querry. Pete has very well documented this point in his Draft. We are considering two systems.
- one is the Internet and its ASCII DNS. The charter says they should stay unchanged. IMHO this is an architectural MUST.
- the other is the Internationalized Internet which is made of the Internet plus IDNA. The purpose is to permit to use Chinese, French, Arabic, English domain names (IDNs) in the Internationalized Internet, however they are stray data in the DNS.
To map anything at:
- protocol level, i.e. at the same layer as the DNS, is to build a new DNS.
- IDNA level, i.e. above the DNS Internet application layer, is transparent to the DNS and does not build a new DNS. This is the whole IDNA idea.
There are therefore two layer violations under discussion:
- 1. to map at protocol layer. We roughly agree, however my architectural motives seem to be stricter than your DNS requirements.
- 2. to only consider the ASCII Unicode sub-part as a special part:
this is the linguistic English "bias" of English internationalization. We consider that _every_ Unicode sub-part (down to code point level) is potentially a special part, while Vint only want to cristalize a few of them in the technology itself.
This means that our conceptual premises are equivalent, so please let drop disputes on that matter. We only differ in terms of mapping flexibility (who decides, for how long) and extension (which code points and contexts); also we commonly explore mapping location (prior, after or within the punycode algorithm) and should consider architectural coherence and stability (how to document the whole thing in order to influence a better stability).
I understand there are two main positions:
- to protect the internet from linguistic originated technical overload through very limited changes, even if this does not fulfill the users expectations. The people supporting this position consider linguistic and Unicode details. They also want to use constraints as protection of technical status quo.
- to protect the internet from any technical change, because users expectations are much more extended than linguistic needs and are common to every digital technology: they must therefore be treated between the user and the Internet - what is named IDNA in here, and we more generally name Interplus. The people supporting this position are only interested in presentation layer issues, whatever the presentation details. They want no constraints on the Internet considering that the overload will more likely result from the constraint mechanism and and of its impact on the global network equilbrium.
IMHO, whatever the good reasons the first coalition may propose, they will most probably be disregarded by users as unnecessary constraints happening to support commercial and political status- quo. My concern, if there is no general IETF and ICANN consensus, at least for Class IN, a wild IDN usage will deploy.
On 12:32 02/07/2009, Vint Cerf said:
thanks for taking the trouble to prepare this note. It does lay out the issues clearly. I think I can report agreement with you in several areas.
First, while the IDNA working group members may not yet have reach consensus, there is at least among them, some who would treat the mapping on look up as a "should" (for compatibility reasons) but not a MUST and distinguish between the basic IDN protocol that preserves the A-label/U-label definitions and 1:1 conversion feature as part of protocol, and the pre-processing of strings that may be destined for lookup in the DNS. Some of the potential preprocessing is not specified in any of the documents except to say that by the time a look up occurs, it must be in A-label form (including the "xn--") or must be a "traditional" ASCII form ("LDH"). One form of preprocessing, about which we continue to debate, is to map some of the characters of the eventual "lookup" string so as to reduce variance from expectations that arise from the IDNA2003 behaviors.
The DNS itself continues to have the purely ASCII behavior it has always had to avoid requiring changes on the domain name server side.
Second, I think there is considerable room for innovation and standardization at a conceptual "presentation" layer - such a layer was not defined in the Internet while some effort to define on was in the OSI system . As applications have become increasingly internationalized, it is arguable that codifying presentation concepts may prove useful. Some might go so far as to suggest re-inventing the system of binding strings to internet addresses (what the DNS does). While that path was not chosen in the present DNS-IDNA2003-IDNA2008 sequence, it might be considered in the future and in my opinion, it is in these areas (presentation and re-definition) that much of your work, jefsey, has relevance .
I am interpreting your message here as arguing not to change the existing basic DNS, to confer stability at the server level, and here we agree.
- emphasis is ours
- emphasis is ours