is IDNA the ML-DNS we wait for ?

Sun May 18 01:04:14 CEST 2008

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.

vint

On May 17, 2008, at 6:52 PM, 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.
> --
> LB
>
> 2008/5/17 Vint Cerf <vint at google.com>:
>> 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 alvestrand.no
>>> http://www.alvestrand.no/mailman/listinfo/idna-update
>>
>> _______________________________________________
>> Idna-update mailing list
>> Idna-update at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/idna-update
>>