Subject: Re: [idn] Moving the IDN RFCs from Proposed to Draft Standards

From: John C Klensin <[email-masked]>
Date: Thu, 06 Nov 2003 01:24:06 -0500

Paul,

I have delayed writing this note in the hope that someone else 
would take the lead -- I'm tired of being the bad guy with 
regard to IDNA, which I basically support.  But a number of 
conversations during the last week have convinced me that it is 
important that something be said, so, two issues:

(1) It was my understanding of the agreements when the IDN 
documents were approved that, when they went to Draft, the Draft 
versions would incorporate a better statement of applicability 
and scope than the original versions and, in particular, would 
incorporate the gist of the "IESG Statement" on IDN 
applicability and missing pieces.   That agreement does not 
appear to be reflected in the text of the new drafts.

(2) Efforts to deploy IDNs seem to be hitting some user problems 
as those users see more of punycode then makes them happy.  Of 
course, for many end users, seeing punycode at all, ever, is too 
much.  Since the purpose of IDNA is to deliver native-text 
characters to end user applications and the presentation to the 
user, there is a case to be made that the "interoperable 
implementations" condition needs to be demonstrated with actual, 
end-user-oriented, applications that deliver non-ASCII 
characters to users.  That is, interoperability between test 
environments that can demonstrate the ability to prepare, code, 
and decode strings is not sufficient to demonstrate that 
interoperable and conforming implementations are possible.  I 
can't tell from the IDNConnect "final report" whether that 
stronger condition was met by those programs but, if it was not, 
some serious community discussion on this issue is probably in 
order.

regards,
     john

--On Thursday, 09 October, 2003 13:21 -0700 "Paul Hoffman / IMC" 
<[email-masked]> wrote:

> Greetings again. Patrik, Adam, Marc and I have made editorial
> revisions to the RFCs in a new series of Internet drafts. The
> announcements for those drafts came out recently; the
> following four messages include a summary of the announcements
> plus the list from each Internet Draft about what changes it
> makes to the corresponding RFC. Note that none of the
> protocols were changed: all the document changes were for
> clarification based on comments we have received over the past
> six months, plus a few minor editorial changes. That is, an
> implementation of the old RFC should work the same under the
> new RFC.
>
> Comments on the individual drafts are appreciated.
>
> BTW, the second part of moving RFCs from Proposed to Draft
> Standard involves finding two or more independent
> interoperable implementations of the standard. We believe that
> we found many during the IDNConnect event (see
> <http://www.idnconnect.jdna.jp>) a few weeks ago, and we'll be
> making a full report on this soon.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
>

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 6 Nov 2003 10:26:21 -0800

At 1:24 AM -0500 11/6/03, John C Klensin wrote:
>It was my understanding of the agreements when the IDN documents 
>were approved that, when they went to Draft, the Draft versions 
>would incorporate a better statement of applicability and scope than 
>the original versions and, in particular, would incorporate the gist 
>of the "IESG Statement" on IDN applicability and missing pieces. 
>That agreement does not appear to be reflected in the text of the 
>new drafts.

Just before the problem statement in draft-hoffman-rfc3490bis-01.txt, 
it says "The IESG issued a statement on IDNA [IESG-STATEMENT]." I 
didn't want to put the statement in directly because the IDNA authors 
didn't write the IESG statement, and it could dilute the value of the 
statement by making it appear to be something we did. However, seeing 
your concern, I'll ask the IESG about what they would prefer on this. 
I'm happy either way.

>Since the purpose of IDNA is to deliver native-text characters to 
>end user applications and the presentation to the user, there is a 
>case to be made that the "interoperable implementations" condition 
>needs to be demonstrated with actual, end-user-oriented, 
>applications that deliver non-ASCII characters to users.

Fully agree.

>   That is, interoperability between test environments that can 
>demonstrate the ability to prepare, code, and decode strings is not 
>sufficient to demonstrate that interoperable and conforming 
>implementations are possible.

That is being debated in other parts of the IETF right now, but 
fortunately, it isn't an issue here.

>   I can't tell from the IDNConnect "final report" whether that 
>some serious community discussion on this issue is probably in order.

Right. We specifically didn't list the participants because doing so 
made it easier for more organizations to test. Having said that, I 
can certainly say that many of the participants were testing "actual 
end-user-oriented applications".

In my previous message, I said:

    Subsequent to the event, I have validated one (unnamed, pre-release)
    IDNA system passes all the tests that it should pass, and fails all
    the test that should fail, as specified in the test description.

That implementation is still unnamed and pre-release, but it is very 
definitely a "actual end-user-oriented application". There are many 
other such applications available, although some of them are useful 
only in particular regions.

--Paul Hoffman, Director

---

From: John C Klensin <[email-masked]>
Date: Fri, 07 Nov 2003 12:32:18 -0500

This is great news.  Thanks for the in-depth reply.
    john

--On Thursday, 06 November, 2003 10:26 -0800 "Paul Hoffman / 
IMC" <[email-masked]> wrote:

>> It was my understanding of the agreements when the IDN
>> documents  were approved that, when they went to Draft, the
>> Draft versions  would incorporate a better statement of
>> applicability and scope than  the original versions and, in
>> particular, would incorporate the gist  of the "IESG
>> Statement" on IDN applicability and missing pieces.  That
>> agreement does not appear to be reflected in the text of the
>> new drafts.
>
> Just before the problem statement in
> draft-hoffman-rfc3490bis-01.txt, it says "The IESG issued a
> statement on IDNA [IESG-STATEMENT]." I didn't want to put the
> statement in directly because the IDNA authors didn't write
> the IESG statement, and it could dilute the value of the
> statement by making it appear to be something we did. However,
> seeing your concern, I'll ask the IESG about what they would
> prefer on this. I'm happy either way.
>
>> Since the purpose of IDNA is to deliver native-text
>> characters to  end user applications and the presentation to
>> the user, there is a  case to be made that the "interoperable
>> implementations" condition  needs to be demonstrated with
>> actual, end-user-oriented,  applications that deliver
>> non-ASCII characters to users.
>
> Fully agree.
>
>>   That is, interoperability between test environments that
>>   can  demonstrate the ability to prepare, code, and decode
>> strings is not  sufficient to demonstrate that interoperable
>> and conforming  implementations are possible.
>
> That is being debated in other parts of the IETF right now,
> but fortunately, it isn't an issue here.
>
>>   I can't tell from the IDNConnect "final report" whether
>>   that  stronger condition was met by those programs but, if
>> it was not,  some serious community discussion on this issue
>> is probably in order.
>
> Right. We specifically didn't list the participants because
> doing so made it easier for more organizations to test. Having
> said that, I can certainly say that many of the participants
> were testing "actual end-user-oriented applications".
>
> That implementation is still unnamed and pre-release, but it
> is very definitely a "actual end-user-oriented application".
> There are many other such applications available, although
> some of them are useful only in particular regions.
>
> --Paul Hoffman, Director