is IDNA the ML-DNS we wait for ?

LB lbleriot at
Sun May 18 00:52:02 CEST 2008

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.

2008/5/17 Vint Cerf <vint at>:
> 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.
> Vint
> On May 17, 2008, at 9:39 AM, JFC Morfin wrote:
>> 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.)
>> Andrew,
>> I do not want to discuss the cons and pros of IDNA. This was discussed
>> before. This WG is committed to IDNA. And IDNA has and will keep deploying.
>> My concern is that if IDNA is not to deliver the functionnality the world
>> expect (robust transparency to languages) there will be several local
>> non-coordinated deployments most probably confirmed after the Olympic Games.
>>> > 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).
>> We agree. This results from ISO 3166 compliance (which is the world
>> referent in terms of sovereignty, scripts-and-languages).
>> I thank you for your answers. They will help. I will compile the answers
>> as I did about "funycode".
>> jfc
>>> > 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.
>>> > 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,
>>> A
>> _______________________________________________
>> Idna-update mailing list
>> Idna-update at
> _______________________________________________
> Idna-update mailing list
> Idna-update at

More information about the Idna-update mailing list