From owner-idn@ops.ietf.org Thu Nov 6 02:01:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14907 for ; Thu, 6 Nov 2003 02:01:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHdZG-000MDo-73 for idn-data@psg.com; Thu, 06 Nov 2003 06:24:30 +0000 Received: from [209.187.148.211] (helo=bs.jck.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHdZ3-000MCy-7j for idn@ops.ietf.org; Thu, 06 Nov 2003 06:24:17 +0000 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.10) id 1AHdYs-00083C-00; Thu, 06 Nov 2003 01:24:06 -0500 Date: Thu, 06 Nov 2003 01:24:06 -0500 From: John C Klensin To: "Paul Hoffman / IMC" , idn@ops.ietf.org Subject: Re: [idn] Moving the IDN RFCs from Proposed to Draft Standards Message-ID: <287897394.1068081845@scan.jck.com> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b9 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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" 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 > ) a few weeks ago, and we'll be > making a full report on this soon. > > --Paul Hoffman, Director > --Internet Mail Consortium > From owner-idn@ops.ietf.org Thu Nov 6 13:35:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21968 for ; Thu, 6 Nov 2003 13:35:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHopg-0000FP-Pf for idn-data@psg.com; Thu, 06 Nov 2003 18:26:12 +0000 Received: from [208.184.76.39] (helo=above.proper.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHopc-0000Ed-KC for idn@ops.ietf.org; Thu, 06 Nov 2003 18:26:08 +0000 Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA6IQ3kU023119 for ; Thu, 6 Nov 2003 10:26:04 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <287897394.1068081845@scan.jck.com> References: <287897394.1068081845@scan.jck.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 6 Nov 2003 10:26:21 -0800 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] Moving the IDN RFCs from Proposed to Draft Standards Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-12.9 required=5.0 tests=BAYES_00,HABEAS_SWE autolearn=ham version=2.60 Sender: owner-idn@ops.ietf.org Precedence: bulk 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 >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". 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 --Internet Mail Consortium From owner-idn@ops.ietf.org Fri Nov 7 12:42:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26248 for ; Fri, 7 Nov 2003 12:42:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AIAT7-000Oyn-SK for idn-data@psg.com; Fri, 07 Nov 2003 17:32:21 +0000 Received: from [209.187.148.211] (helo=bs.jck.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AIAT5-000OyY-4H for idn@ops.ietf.org; Fri, 07 Nov 2003 17:32:19 +0000 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.10) id 1AIAT4-0000mY-00; Fri, 07 Nov 2003 12:32:18 -0500 Date: Fri, 07 Nov 2003 12:32:18 -0500 From: John C Klensin To: "Paul Hoffman / IMC" , idn@ops.ietf.org Subject: Re: [idn] Moving the IDN RFCs from Proposed to Draft Standards Message-ID: <414387507.1068208337@scan.jck.com> In-Reply-To: References: <287897394.1068081845@scan.jck.com> X-Mailer: Mulberry/3.1.0b9 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is great news. Thanks for the in-depth reply. john --On Thursday, 06 November, 2003 10:26 -0800 "Paul Hoffman / IMC" wrote: > 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 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". > > 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 > --Internet Mail Consortium > From owner-idn@ops.ietf.org Mon Nov 17 20:49:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18018 for ; Mon, 17 Nov 2003 20:49:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALuoV-000BAm-40 for idn-data@psg.com; Tue, 18 Nov 2003 01:37:55 +0000 Received: from [202.27.17.100] (helo=sentosa.post1.com) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ALuoI-000BA5-5M for idn@ops.ietf.org; Tue, 18 Nov 2003 01:37:42 +0000 Received: (qmail 49430 invoked from network); 18 Nov 2003 01:57:10 -0000 Received: from icsf.ida.gov.sg (HELO pobox.org.sg) (210.24.193.10) by sentosa.post1.com with SMTP; 18 Nov 2003 01:57:10 -0000 Message-ID: <3FB977D0.9070607@pobox.org.sg> Date: Tue, 18 Nov 2003 09:37:20 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: IETF/IDN WG , ietf-imaa@imc.org Subject: [idn] IDN Open Source Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_RFCI autolearn=no version=2.60 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Some of you may be aware that there is a initiative to start an IDN Open Source Software project. After some delay (mostly my fault), we finally got our website: http://idn.isc.org/ You can also find some information on our Wiki: http://idn.isc.org/wiki/wiki.cgi Comments or Suggestions are welcome! http://idn.isc.org/wiki/wiki.cgi?Suggestions I will be setting up a mailing list soon but in the meantime, if you wish to help out in the effort or like to be kept informed, drop me an email. -James Seng