<html>
<body>
<font size=2>Dear Vint and all,<br>
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.<br><br>
</font>At 01:04 18/05/2008, Vint Cerf wrote:<br>
<blockquote type=cite class=cite cite="">Let me try to be very
clear.<br><br>
I do not think that we should conflate the IDNA work as chartered
with<br>
the broader question of ML-DNS as it is becoming apparent that
ML-DNS<br>
(what ever might be meant by that) does not seem to fit into the
present<br>
charter.</blockquote><br>
<font size=2>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.<br><br>
</font><blockquote type=cite class=cite cite="">IDNA-bis is intended to
refine the basic IDNA mechanisms based on<br>
experience to date with the earlier IDNA2003 formulation. IDNA-bis<br>
is not chartered, e.g., to invent new classes of domain
names.</blockquote><br>
<font size=2>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</font>.<br><br>
<blockquote type=cite class=cite cite="">It seems to me that we are on a
productive vector to finalize the four<br>
documents with which the working group began. </blockquote><br>
<font size=2>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.<br><br>
</font><blockquote type=cite class=cite cite="">I have not heard any<br>
argument (that I was able to understand) that rejected the essential<br>
framework of IDNAbis. I AM hearing that some participants would like<br>
to consider alternatives to what we seem to be calling IDNA2008<br>
or IDNA200X now. I am not hearing any kind of consensus that we<br>
should abandon IDNA2008; rather, I am hearing a desire to finalize<br>
these documents. Much of the discussion surrounds the means by<br>
which sets of Unicoded characters are either accepted as PVALID<br>
or rejected as unacceptable for use in domain names.</blockquote><br>
<font size=2>Full agreement.<br><br>
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. <br><br>
I think that this mail of yours fully clarifies this for everyone.
<br><br>
1. IDNAbis must be a sucess.<br>
2. 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.<br>
3. 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.<br><br>
</font><blockquote type=cite class=cite cite="">I would urge the
participants in the IDNAbis Working Group to<br>
focus on refining and finalizing the four documents that have been<br>
submitted as the basis for the Working Group effort.</blockquote><br>
<font size=2>We obiously fully concur.<br>
1. We will continue to document the
<a href="http://wikidna.org/" eudora="autourl">http://wikidna.org</a>
with information on/for the IDNA development, deployment and support.
_Everyone_ is welcome to come and give a hand. <br>
2. The strategy of this site should be to support complete compatibility
at the linguistic IDN level between IDNA and ML-DNS.<br><br>
</font>At 01:27 18/05/2008, James Seng wrote:<br>
<blockquote type=cite class=cite cite="">Oh I understand the questions
fine. And the subtle implication of the <br>
lack of usefulness of this WG. </blockquote><br>
<font size=2>This may be your opinion. However, it is not ours.<br><br>
</font><blockquote type=cite class=cite cite="">But I dont see a need to
have the <br>
discussion since ML-DNS and questions are clearly out of scope. As
<br>
Vint indicated, you or anyone is feel to pursue another working
group <br>
or mailing list for it.</blockquote><br>
<font size=2>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).
<br><br>
This is precisely what we will do, as per the Internet standard process.
Exploring through temptative Drafts, and aiming at a BOF.<br><br>
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.<br><br>
</font><blockquote type=cite class=cite cite="">I also didnt miss the
suggestions that some groups may break off from <br>
IDNA without ML-DNS (whatever that is) and with reference to
Olympic <br>
suggesting that jersey is somehow speaking on the behalf of the
<br>
Chinese, however cleverly crafted that it imply he might also not
be.</blockquote><br>
<font size=2>??? <br>
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". <br><br>
</font><blockquote type=cite class=cite cite="">I have spend plenty of
time recently in China as well as catching up <br>
with old friends from CNNIC. But there are CNNIC folks on this list
<br>
and I am pretty sure they can speak for themselves if they have any
<br>
objections without someone claiming to represent "@large" or
myself <br>
even to speak for them.</blockquote><br>
<font size=2>I thank you for clearly spelling out your belief that I am
pretending to speak on behalf of CNNIC.<br><br>
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.<br><br>
</font>I also fail to see what objection we could have. We ask a
question?<br><br>
At 04:17 18/05/2008, Vint Cerf wrote:<br>
<blockquote type=cite class=cite cite="">Jefsey,<br>
you forget perhaps that the internet is based on voluntary adoption
<br>
of standards. IETF does not and cannot enforce; and ICANN has
limited <br>
means to do so through SOME contracts with SOME parties but not at
<br>
all levels of DNS nor resellers nor some other operators.<br><br>
so we just have to write the best technical specifications we can
and <br>
make them available.</blockquote><br>
<font size=2>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. <br><br>
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.<br><br>
I hope this definitely clarifies the issue.<br><br>
<br>
</font>Now, this debate helped us to better analyse our _IDNA_
priorities. We can state that it would be great if:<br><br>
1. everything was made for the browsers to protect users in the same way:
so the same IDNs resolve the same with every browser.<br>
2. applications can be updated online with supported charset tables. This
is for Unicode updates and private/local use code-points.<br>
3. it is spelled out that the IDNA usage is limited to ISO 10646
characters <br>
4. that non-punycode IDN can be used and will display as A labels.<br>
5. that users must have the possibility to filter in/out any code point
that they want/do not want to accept. <br>
6. there are documented strategies that can be supported depending on the
size of the used ROM.<br>
7. there is an IETF, a Unicode, TLD Registry Managers, and an ISO common
review IANA mailing list with IETF, ISO, and IGF co-chairs.<br>
8. when needed, due to its nature, IDNA should be discussed in the
context of the digital convergence and semantic emergence.<br>
9. IANA provides a reference A/U-Label converter, and possible other IDN
related services.<br>
10. IETF would only be concerned by scripts, not by languages (except
when languages may culturally modify the use of the scripts). <br><br>
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.<br><br>
jfc<br><br>
</body>
</html>