WG-IDNABIS : Is IDNA to be an ML-DNS
Un article de Wiki.
france@large et le groupe de travail WG-IDNABIS ont agréé que l'IETF ne vise pas avec IDNA à apporter une solution multilingue au DNS de l'Internet (mais à mieux définir sa solution internationalisée) et que le travail que les @larges ont l'entière liberté d'engager vers un ML-DNS, recherchant une solution multilingue où chaque langue peut-être desservie comme l'anglais par le DNS ASCII, n'est ni confusant ni contre-productif, pour autant que les deux efforts soient clairement séparés.
Sommaire |
Inroduction du problème
Dear friends, The concerns of the Working Group of the IETF on the revision of the IDNA, chaired by Vint Cerf; become increasingly confused. It decides again of the perception and support of languages on the Internet, and identification systems (IRI), classifying, reference, and addressing semantic that derive from it.
- Chers amis, Les préoccupations du groupe de Travail de l'IETF sur la révision de l'IDNA, présidé par Vint Cerf; deviennent de plus en plus confuses. Or il s'y joue à nouveau la perception et le support des langues sur l'Internet, et les systèmes d'identification (IRI), de classement, de référence, et d'adressage sémantiques qui en dérivent.
Given the importance of DNS, this will practically decide whether our online/virtual world: -- will be multipolar and specific to each one ( "people centric") according to the will of the WSIS and the ISO vote against the IETF position, -- or stay 'network centric" as per the IETF design, unilaterally conditioned around ICANN, IANA and the English language, by the Unicode Consortium (IBM, $ M, Google, Yahoo! Oracle), subject to two heavy technical impasses (1) no "end to end" for domain names language (2) simulation and non-implementation of the network "presentation" layer, which misses in the Internet architecture, necessary for IDNA.
- Vu l'importance du DNS, ceci décidera pratiquement si notre monde en-ligne/virtuel :
- * va devenir multilpolaire et propre à chacun ("people centric") selon la volonté du SMSI et le vote obtenu à l'ISO contre la position IETF,
- * ou rester 'network centric" comme le conçoit l'IETF, unilatéralement conditionné, autour de l'ICANN, du IANA et de la langue anglaise, par le consortium Unicode (IBM, M$, Google, Yahoo! Oracle), moyennant deux lourdes impasses techniques (1) pas de "end to end" pour les noms de domaine linguistiques (2) la simulation et non l'implantation de la couche réseau "présentation", qui manque à l'Internet, nécessaire aux IDN.
I thus want to ask clearly Vint Cerf its intentions after eight years of waht may be preceived as well organized strategic uncertainties. We have to be fixed finally publicly and can all go to see somewhere else before it is too late. Please see review my draft mail and if it is sufficiently clear and complete.
- Je veux donc demander clairement à Vint Cerf ses intentions après huit ans d'incertitudes que l'on peut croire stratégiquemernt bien organisées. Il faut que nous soyons enfin publiquement fixés et puissions tous aller voir ailleurs avant que cela ne soit trop tard. Merci de revoir mon projet de mail et de me dire si c'est suffisament clair et complet.
The alternative is simple, robust and conform to open standards. It is an implementation of the "presentation" layer for good. This requires an average development. It is transparent to who does not use it. It does not destabilise the Internet. It is extremely attractive in terms of applications - beyond what is related to language empowerment. However, the presentation layer allows to multiply at the infinity autonomous global Internet "presentations". Hundreds, thousands of logical Internet . This is in tune with the real world, which is distributed, not decentralized from USA. This means eventually an internet more homogeneous and intergoverned by the "ICANN"s of each "presentation". It is the ICANN vision in its ICP-3 document, which envisages the end of the unique authoritatve root. It wold also be a big change for the naming industry and control which will no longer be ICANN-centric but also become people centric.
- La solution alternative est simple, robuste et conforme aux standards ouverts. Elle consiste en une implémentation de la couche "présentation" pour de bon. Ceci demande un développement moyen. C'est transparent à qui ne l'utilise pas. Il ne destabilise pas l'Internet. Il est extrèmement porteur en terme d'applications - audelà de ce qui est liè à la capacitation linguistique. Toutefois, cette couche présentation permet de multiplier à l'infini les "présentations" globales autonomes de l'internet. Des centaines, milliers d'Internet logiques. Ceci est au diapason du monde réel qui est distribué, et non pas décentralisé à partir des Etats-Unis. Ceci signifie à terme un internet plus homogène et intergouverné par les "ICANN" de chaque "présentation". C'est la vision de l'ICANN dans son document ICP-3 ou elle envisage ainsi la fin du fichier racine unique. Ce serait aussi un grand changement pour l'industrie et le contrôle du nommage qui ne sera plus centré-ICANN, mais lui-aussi "people centric".
Question to Vint Cerf as Chair, WG-IDNABIS
- At 03:29 17/05/2008, jefsey wrote:
Dear Vint,
As I explained it, prior to sending this mail, I circulated its draft to many people round the world and took their remarks into consideration, specially @large members who like those of france@large and Multilinc translate "@large" as "an Internet co-owner", and MAAYA Members.
The IDNA issue is a key priority for the continuation of the IETF technology as the network technology of the world digital ecosystem (WDE). If the IETF cannot match the world's expectations in that area it must say so now, so others can consider alternative solutions before we see different uncoordinated local solutions developed and deployed.
- >At 22:37 09/05/2008, Kenneth Whistler wrote: What matters, I think, is what contemporary communities *are* using or might reasonably be inferred to want to use if available, for domain names.
Maybe, what really matters are:
- (1) the political world consensus for a multilingual Internet for a people centered multilingual society of information,
- (2) the universal resentment at being told what one is supposed to want. People accept being told by others as to what they can only do, if they understand exactly why.
The world expects a Multilingual DNS that works for every language and every script the way the DNS works for English and ASCII. Let us call this the ML-DNS specification. It is very simple, terse, and clear.
Question (A): does this IETF WG-IDNABIS seek to document an IDNA based ML-DNS in order to be ready for testing by Dec. 2008 (Y/N)?
Question (B): If A is "N", what are the clearly defined and committed detailed specifications of the Nov. 2008 IETF deliverable?
Among the points to be clarified in these specifications are:
- - will it be mainly focussed towards Mobiles, Browsers, Applications, or the three of them?
- - will it be phishing proof at every DN level?
- - which scripts or charset and languages will be supported? or will it be transparent to scripts choices?
- - will it be IDN2003 compatible?
- - will it strive to be future ML-DNS interoperable?
- - why was the IDNA option chosen as the best way to support ML-DNS vs. other possibilities?
- - will Microsoft, Google, and Firefox fully and identically support it? Will they also permit the support of any other ML-DNS proposition?
- - will it support easily additional symbols such as logos?
- - will it stay ISO 3166 conformant?
Thank you for your committed answer.
Answer from WG-IDNA and WG-IDNABIS Chairs and WG
- At 03:38 17/05/2008, James Seng wrote:
- James Seng was the co-Chair of the WG-IDNA.
I believe this working group is chartered very narrowly and specific related to the work done by the previous work in IDN-WG and later work by John on IDNA2003. So while I do not question the legitimacy of your question, this working group may not be the right forum for having those discussion as it is out of scope.
But quickly:
- (1) is out of scope even for IETF.
- (2) is something under discussion so no answer.
- (3) is out of scope (ask Unicode)
- (4) is answered in the chartered
- (5) cannot be answered since there is no "ML-DNS" RFC to base it against
- (6) is out of scope - refer to original IDN-WG
- (7) is out of scope for IETF
- (8) is out of scope (ask Unicode) and
- (9) is out of scope (ask ICANN)
- At 04:40 17/05/2008, Vint Cerf wrote:
Thanks james, you and [I hav]e a common understanding of the focus for this working group. V
- At 04:50 17/05/2008, Andrew Sullivan wrote:
- On Sat, May 17, 2008 at 03:29:31AM +0200, jefsey wrote: If the IETF cannot match the world's expectations in that area it must say so now, so others can consider alternative solutions before we see different uncoordinated local solutions developed and deployed.
I'm not entirely sure anyone knows what the world's expectations are -- I have, personally, a hard time predicting the mood of my current riding's electorate from month to month -- but supposing you had a good handle on what the world's expectations are, why would it be necessarily harmful if a multitude of possible answers emerged before one final one did? (I have my own list for why, note; I'm asking you for yours.)
- The world expects a Multilingual DNS that works for every language and every script the way the DNS works for English and ASCII. Let us call this the ML-DNS specification. It is very simple, terse, and clear.
Actually, I think we need some parsing marks to be clear: the desire is "internationalised LDH" (or "iLDH" if we need to invent bits of jargon). Therefore, the goal of the current work really is [DNS that works for every (Unicode-defined) script] the way [DNS works for ASCII today]. I want to leave language out of it, because even though humans happen to use labels as signifiers, they're only parts of language in the passing theory of the interlocutors (cf. Donald Davidson).
- Question (A): does this IETF WG-IDNABIS seek to document an IDNA based ML-DNS in order to be ready for testing by Dec. 2008 (Y/N)?
I think the goal is a short document cycle. Being as it's May, I think December may be a little optimistic.
- Question (B): If A is "N", what are the clearly defined and committed detailed specifications of the Nov. 2008 IETF deliverable?
This is question begging. We don't know until the protocol specification is done.
- 1- will it be mainly focussed towards Mobiles, Browsers, Applications, or the three of them?
None or all. It will be mainly focussed towards labels in the DNS, and their interpretations by IDNA-interpreting clients, whatever they are.
- 2- will it be phishing proof at every DN level?
No. Even ASCII isn't.
- 3- which scripts or charset and languages will be supported? or will it be transparent to scripts choices?
This is a loaded question; but I think we're still working out which scripts get included.
- 4- will it be IDN2003 compatible?
Maybe.
- 5- will it strive to be future ML-DNS interoperable?
I'm unwilling to speculate.
- 6- why was the IDNA option chosen as the best way to support ML-DNS vs. other possibilities?
I think this is part of what John's current draft is about. http://tools.ietf.org/html/draft-klensin-idna-alternatives-00
- 7- will Microsoft, Google, and Firefox fully and identically support it? Will they also permit the support of any other ML-DNS proposition?
You'll have to ask them.
- 8 - will it support easily additional symbols such as logos?
Not as currently outlined.
- 9 - will it stay ISO 3166 conformant?
I don't think I understand this question.
No hat, and best regards,
Required clarifications
- At 15:16 17/05/2008, JFC Morfin wrote:
- * At 04:40 17/05/2008, Vint Cerf wrote: Thanks james, you and e [sic] a common understanding of the focus for this working group. V
Dear Vint,
I read this as "you and I have a common understanding of the focus for this working group".
As I commented to James, the question is not about the focus of this WG which is IDNA. The question is about what do you expect from IDNA as compared to these users expectations.
The initial WG-IDNA charter called for a survey of the user demand. If I am correct it was then decided it was beyond what IETF could do and it was eventually decided that the best was to give the RFC a try and to review the IDNA proposition after a few years of pragmatic deployment.. This is exactly what is happening. Most of the members of this group have participated to the whole WG-IDNA process, contributed to the first implementations of IDNA, worked on its update, jointly decided of this WG-IDNABIS. This represents a considerable amount of experience, expertise and knowledge about internationalization on the market.
I chair an @large organisation. Our understanding of an @large is someone considering himself from his knowledge, involvement, investment, monthly bill, usage, innovative thinking and efforts, business involvement, political and societal responsibilities, etc. as an Internet co-owner. Most are more interested in applied semantic strata, consider the ASCII DNS as a good tool, and agree with WSIS multilingualism for which they expect the DNS to work transparently. They just want to know, if you consider that IDNA will eventually bring an answer to their needs as they express them, or if you do not and why. This is only because they want to know if they should just keep waiting for November, help the concertation meeting I proposed, or give a try to an Internet upgrade supporting the missing OSI layers in a different but interoperable manner.
- At 15:26 17/05/2008, James Seng wrote:
Let me forward to the group what I said to you in private:
"Sorry to say you wouldnt find the answers to your questions here.
If your members thinks IDNA is not suitable and they need ML-DNS, then they should start working. You do what you have to do.
The working group however is focus on one and only one thing, updating IDNA. This mailing list is called "idna-update" should be obvious enough of the priority."
ps: You probably dont understand the dry humor of my English shortcoming.
- At 16:41 17/05/2008, Vint Cerf wrote:
Jefsey, et al,
The IDNA-update mailing list is intended for discussions leading to the finalization of the draft submissions that have been posted on behalf of the working group on this mailing list.
If people want to have more speculative and wide-ranging discussions beyond the charter of the working group, I recommend that we set up a separate mailing list, unassociated with the working group. Please try to confine discussions on IDNA-UPDATE to the charter of the working group and the draft documents it is considering.
- At 00:52 18/05/2008, LB wrote:
Jefsey,
James Seng did not understand our question (so his humour is not
turning against him). But we have our answer.
The first question the answer is "no". The engineers of IDNA do not think it can be an ML-DNS. To the second question detailed response is either "too early to respond" either" IDNA is not an architectural strategy for the Internet".
The commentary is clear: if you want a ML-DNS, work on it, a prospective effort can not hurt.
They did not understand that our concern as lead users is to help them develop their IDNA for it to be effective and legally acceptable to operators and registrants, and work an ML-DNS we need (if that is possible) that is interoperable with IDNA, while we do not know what IDNA will finally be.
That's what you always said. But we were not sure that you had the right. Now we can all see that there was no opposition from Vint Cerf and that your approach is consistent with the spirit of the Internet and the IETF, and we can even create a list for IETF discuss if we have a real project.
Nothing more to say. Only work on IDNA and ML-DNS.
- At 01:04 18/05/2008, Vint Cerf wrote:
Let me try to be very clear.
I do not think that we should conflate the IDNA work as chartered with the broader question of ML-DNS as it is becoming apparent that ML-DNS (what ever might be meant by that) does not seem to fit into the present charter.
IDNA-bis is intended to refine the basic IDNA mechanisms based on experience to date with the earlier IDNA2003 formulation. IDNA-bis is not chartered, e.g., to invent new classes of domain names.
It seems to me that we are on a productive vector to finalize the four documents with which the working group began. I have not heard any argument (that I was able to understand) that rejected the essential framework of IDNAbis. I AM hearing that some participants would like to consider alternatives to what we seem to be calling IDNA2008 or IDNA200X now. I am not hearing any kind of consensus that we should abandon IDNA2008; rather, I am hearing a desire to finalize these documents. Much of the discussion surrounds the means by which sets of Unicoded characters are either accepted as PVALID or rejected as unacceptable for use in domain names.
I would urge the participants in the IDNAbis Working Group to focus on refining and finalizing the four documents that have been submitted as the basis for the Working Group effort.
- At 01:27 18/05/2008, James Seng wrote:
Oh I understand the questions fine. And the subtle implication of the lack of usefulness of this WG. But I dont see a need to have the discussion since ML-DNS and questions are clearly out of scope. As Vint indicated, you or anyone is feel to pursue another working group or mailing list for it.
I also didnt miss the suggestions that some groups may break off from IDNA without ML-DNS (whatever that is) and with reference to Olympic suggesting that jersey is somehow speaking on the behalf of the Chinese, however cleverly crafted that it imply he might also not be.
I have spend plenty of time recently in China as well as catching up with old friends from CNNIC. But there are CNNIC folks on this list and I am pretty sure they can speak for themselves if they have any objections without someone claiming to represent "@large" or myself even to speak for them.
- At 04:17 18/05/2008, Vint Cerf wrote:
Jefsey,
you forget perhaps that the internet is based on voluntary adoption of standards. IETF does not and cannot enforce; and ICANN has limited means to do so through SOME contracts with SOME parties but not at all levels of DNS nor resellers nor some other operators.
so we just have to write the best technical specifications we can and make them available.
vint
Conclusion
- At 01:47 19/05/2008, JFC Morfin wrote:
Dear Vint and all,
It seems that we are all 100% in agreement, except for perhaps James Seng who wants to read things that no one ever wrote. I apologise for coming back to this. I hope that it will finally be the last time.
- At 01:04 18/05/2008, Vint Cerf wrote: Let me try to be very clear.
- I do not think that we should conflate the IDNA work as chartered with the broader question of ML-DNS as it is becoming apparent that ML-DNS (what ever might be meant by that) does not seem to fit into the present charter.
This is exactly what we wanted to see clearly spelled out. Because, some of us - per my suggestion - thought from reading the Charter and John Klensin's documents that a succesful IDNA could be targeted as a good ML-DNS and that we did not want to disrupt its respective process.
- IDNA-bis is intended to refine the basic IDNA mechanisms based on experience to date with the earlier IDNA2003 formulation. IDNA-bis is not chartered, e.g., to invent new classes of domain names.
We are in full agreement. And no one ever suggested this. Our two year ICP-3 community test bed (dot-root) plus our three years of exploration on semantic national protection (AFRAC) and a parallel two years on a multilinguistics investigation have shown us that the ML-DNS does not need to use classes (as John Klensin suggested once). This could help, as would also a built-in presentation layer, but it is not necessary because classes are not unlimited.
- It seems to me that we are on a productive vector to finalize the four documents with which the working group began.
Absolutely. And we fully agree with this. James' misunderstanding is, however, very positive as it enables this to be made absolutely clear. We fully support the WG-IDNABIS for what it is and certainly we want to contribute to its success as a good, adequate, compact, clear document set. Either it is good enough to satisfy most of our needs, or it will be easier to encapsulate within any ML-DNS strategy (whatever it may turn out to be). We do not have any solution as of yet. We only have needs currently.
- I have not heard any argument (that I was able to understand) that rejected the essential
framework of IDNAbis. I AM hearing that some participants would like to consider alternatives to what we seem to be calling IDNA2008 or IDNA200X now. I am not hearing any kind of consensus that we should abandon IDNA2008; rather, I am hearing a desire to finalize these documents. Much of the discussion surrounds the means by which sets of Unicoded characters are either accepted as PVALID or rejected as unacceptable for use in domain names.
Full agreement.
After I explained to them the reasons for James' misunderstanding (he explains very well in his own mail) Louis, other French lurkers, and I believe that proposing to abandon/discuss IDNA2008 would be highly disruptive. Our worry, due to other past confusions and to the possible economic/architectural possible impact, was that our own possible investigation concerning an ML-DNS would not be confused as an alternative but as a more complete solution in a continuity that is totally out of the scope of the WG-IDNABIS.
I think that this mail of yours fully clarifies this for everyone.
- IDNAbis must be a sucess.
- It is not intended to be an ML-DNS, so working separately in parallel to the preparation of a possible ML-DNS BOF is encouraged.
- There is no reason as to why ML-DNS should be discussed any further here. Answering Vint's suggestion, I have created an ML-DNS exploratory mailing list to that end.
- I would urge the participants in the IDNAbis Working Group to focus on refining and finalizing the four documents that have been submitted as the basis for the Working Group effort.
We obiously fully concur.
- We will continue to document the http://wikidna.org with information on/for the IDNA development, deployment and support. _Everyone_ is welcome to come and give a hand.
- The strategy of this site should be to support complete compatibility at the linguistic IDN level between IDNA and ML-DNS.
- At 01:27 18/05/2008, James Seng wrote:Oh I understand the questions fine. And the subtle implication of the lack of usefulness of this WG.
This may be your opinion. However, it is not ours.
- But I dont see a need to have the discussion since ML-DNS and questions are clearly out of scope. As Vint indicated, you or anyone is feel to pursue another working group or mailing list for it.
There was not any reason to do it, if we did not need to. Now, you clarified that there was a technical need, and Vint said that we were not disruptive at having a try (we feared your misunderstanding).
This is precisely what we will do, as per the Internet standard process. Exploring through temptative Drafts, and aiming at a BOF.
We will also consider as to how to prepare an adequate legal IDNA acceptance by registrants and registry managers, because we are registrants and registry managers and we need to be fully interoperable with the best IDNA, which we want to help coproduce in this WG.
- I also didnt miss the suggestions that some groups may break off from IDNA without ML-DNS (whatever that is) and with reference to Olympic suggesting that Jefsey is somehow speaking on the behalf of the Chinese, however cleverly crafted that it imply he might also not be.
???
I made it clear that I am speaking on behalf of some French and francophone @large and @large international community informed members, defining them as "Internet lead users that consider themselves as Internet co-owners".
- I have spend plenty of time recently in China as well as catching up with old friends from CNNIC. But there are CNNIC folks on this list and I am pretty sure they can speak for themselves if they have any objections without someone claiming to represent "@large" or myself even to speak for them.
I thank you for clearly spelling out your belief that I am pretending to speak on behalf of CNNIC.
This clearly shows the exact origin of your misuderstanding: I am not speaking on behalf of CNNIC. Moreover, I am not pretending to speak on behalf of CNNIC, and I do not see what CNNIC has to do with this at all. I do not see why I could be interested in speaking on behalf of the CNNIC??? They already have an IDNA based solution that, therefore, is not an ML-DNS solution (according to you who is the expert).
I also fail to see what objection we could have. We ask a question?
- At 04:17 18/05/2008, Vint Cerf wrote:
- Jefsey,you forget p'erhaps that the internet is based on voluntary adoption of standards. IETF does not and cannot enforce; and ICANN has limited means to do so through SOME contracts with SOME parties but not at all levels of DNS nor resellers nor some other operators. so we just have to write the best technical specifications we can and
make them available.
I did not forget. I am just pragmatic and I have to convince people that are not familiar with the IETF that this the way it works. I thank you for spelling it out: they certainly felt relieved. James Seng's reaction has shown that only asking "if IDNA should or should not be considered as an ML-DNS solution" was a sensible conflicting issue for some. This is what had to be clarified first, both at this WG and among our own @larges.
No one wants confusion or conflict. As Louis explained it, @large people are not really happy about the response that IDNA cannot be considered as an ML-DNS and that they must have a try at it. Furthermore, they did not want to be confused with opponents who they consider as their back-up solution, in which they certainly want to contribute if they can.
I hope this definitely clarifies the issue.
IDNA priorities for ML-DNS
It is likely that the ML-DNS debate [1] will lead to the encapsulation of IDNA within the ML-DNS global framework, to support internationalisation when necessary.
Now, this debate helped us to better analyse our IDNApriorities. We can state that it would be great if:
- everything was made for the browsers to protect users in the same way: so the same IDNs resolve the same with every browser.
- applications can be updated online with supported charset tables. This is for Unicode updates and private/local use code-points.
- it is spelled out that the IDNA usage is limited to ISO 10646 characters
- that non-punycode IDN can be used and will display as A labels.
- that users must have the possibility to filter in/out any code point that they want/do not want to accept.
- there are documented strategies that can be supported depending on the size of the used ROM.
- there is an IETF, a Unicode, TLD Registry Managers, and an ISO common review IANA mailing list with IETF, ISO, and IGF co-chairs.
- when needed, due to its nature, IDNA should be discussed in the context of the digital convergence and semantic emergence.
- IANA provides a reference A/U-Label converter, and possible other IDN related services.
- IETF would only be concerned by scripts, not by languages (except when languages may culturally modify the use of the scripts).
To conclude: when we state that we want full support of the French character set, we mean whatever a francophone person can be confronted with in his/her usual daily life and national neigbhourhood, along with the ISO 3166-1 and -2 tables.
