From owner-idn@ops.ietf.org Fri Nov 1 04:46:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02235 for ; Fri, 1 Nov 2002 04:46:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187YHU-0007m2-00 for idn-data@psg.com; Fri, 01 Nov 2002 01:39:56 -0800 Received: from smtp.mailbox.net.uk ([195.82.125.32]) by psg.com with esmtp (Exim 3.36 #2) id 187YHS-0007lp-00 for idn@ops.ietf.org; Fri, 01 Nov 2002 01:39:54 -0800 Received: from [195.82.108.10] (helo=Steve.uk.com) by smtp.mailbox.net.uk with esmtp (Exim 3.36 #1) id 187YHQ-0007Ra-00 for idn@ops.ietf.org; Fri, 01 Nov 2002 09:39:52 +0000 Message-Id: <5.1.0.14.2.20021101093429.01b401a0@pop3.mailbox.co.uk> X-Sender: steve@pop3.mailbox.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 01 Nov 2002 09:40:52 +0000 To: idn@ops.ietf.org From: Steve Dyer Subject: Re: [idn] Re: idn-uri document In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-Spam-Status: No, hits=-6.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA02235 At 23:40 31/10/2002 +0100, Erik Nordmark wrote: > > >The defined syntax rules for declare certain ASCII domain names illegal > > >(such as *.example.org). Where is the check for illedgal names assumed to > > >be performed? For IDNA it probably makes sense to only apply this types > > >of checks (setting the UseSTD3ASCIIRules flag) when verifying domain name > > >registrations and not do such checks in the clients. > > > > This is an IDNA question, not a idn-uri question. As far as I remember, > > the idea was to have the checks done on the clients, too (with some > > leeway for unassigned characters to stay forward-compatible with > > new character assignements). The reason for this was to create > > pressure on registries to follow the rules. Hi, I am surprised that you indicate that certain ASCII domains will be illegal. I can see why unix people may be unhappy about "*.example.org". I trust that most high ASCII will be allowed - "é" (e-acute) for example since software such as BIND9 handles them. I am also concerned that a group discussing a protocol is suggesting that the protocol is designed to "create pressure on registries". A protocol is a stand-alone technical facility, not an instrument of policy. Regards Steve Dyer CentralNic Ltd From owner-idn@ops.ietf.org Fri Nov 1 14:00:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29001 for ; Fri, 1 Nov 2002 14:00:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187gpN-000JK3-00 for idn-data@psg.com; Fri, 01 Nov 2002 10:47:29 -0800 Received: from nat.alvestrand.no ([217.13.28.204] helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 3.36 #2) id 187gpL-000JJp-00 for idn@ops.ietf.org; Fri, 01 Nov 2002 10:47:28 -0800 Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 69F13622AC; Fri, 1 Nov 2002 19:47:15 +0100 (CET) Date: Fri, 01 Nov 2002 20:03:17 +0800 From: Harald Tveit Alvestrand To: John C Klensin , "Hollenbeck, Scott" , idn@ops.ietf.org Subject: RE: UTF-8 in Internet Drafts (was Re: [idn] I-D ACTION:draft-jsen g-idn-admin-01.txt) Message-ID: <301897355.1036180997@localhost> In-Reply-To: <22338404.1036080412@localhost> References: <3CD14E451751BD42BA48AAA50B07BAD603370141@vsvapostal3.prod.netsol .com> <22338404.1036080412@localhost> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.0 required=5.0 tests=DATE_IN_PAST_06_12,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 31. oktober 2002 16:06 -0500 John C Klensin wrote: >> I-Ds can be submitted in PostScript format if that helps, >> though a text version (that can be different due to issues >> with figures and non-ASCII characters) is still required to >> have both published. > > Assuming, obviously incorrectly, that the same "simultaneous > posting in text and PS or PDF" principle applied to I-Ds as > well as RFCs, this one was sent to the I-D administrator in > text and pdf formats. The latter was discarded. If we would > like a PDF alternative, I think that is a small matter of the > IESG expanding the rules. There are currently quite a few PDF files in the internet-drafts direcories, and I don't think they got there by accident. I'm checking with the secretariat to figure out whether they think it was lost through clerical error on their side or on the sender's side. Harald From owner-idn@ops.ietf.org Fri Nov 1 14:01:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29060 for ; Fri, 1 Nov 2002 14:01:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187gpd-000JKp-00 for idn-data@psg.com; Fri, 01 Nov 2002 10:47:45 -0800 Received: from nat.alvestrand.no ([217.13.28.204] helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 3.36 #2) id 187gpa-000JK6-00 for idn@ops.ietf.org; Fri, 01 Nov 2002 10:47:43 -0800 Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 620E862207; Fri, 1 Nov 2002 19:47:28 +0100 (CET) Date: Fri, 01 Nov 2002 20:08:16 +0800 From: Harald Tveit Alvestrand To: John C Klensin , "Hollenbeck, Scott" , idn@ops.ietf.org Subject: [idn] Representing codepoints (RE: UTF-8 in Internet Drafts) Message-ID: <302196385.1036181296@localhost> In-Reply-To: <22338404.1036080412@localhost> References: <3CD14E451751BD42BA48AAA50B07BAD603370141@vsvapostal3.prod.netsol .com> <22338404.1036080412@localhost> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.0 required=5.0 tests=DATE_IN_PAST_06_12,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 31. oktober 2002 16:06 -0500 John C Klensin wrote: > James and > the rest of the JET team have been discussing (at my request) > ways to present the characters in ASCII text that would make > the document more comprehensible than the code points alone > for those reading the document in ASCII text. advertising someone else's code, and only tangentially relevant to this list..... there's a Perl package out on CPAN called "unidecode", maintained by Sean Burke. It can be used to generate ASCII strings from any sequence of Unicode codepoints; in some cases, these ASCII strings can remind people what the characters were supposed to mean. For Chinese, for instance, it spits out something resembling Pinyin (probably *is* Pinyin, but I don't know enough to guarantee that). Health warning: I've only played with it.... Harald From owner-idn@ops.ietf.org Sun Nov 3 08:35:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05436 for ; Sun, 3 Nov 2002 08:35:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188Klc-0009Bs-00 for idn-data@psg.com; Sun, 03 Nov 2002 05:26:16 -0800 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201] ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 188KlY-0009AJ-00 for idn@ops.ietf.org; Sun, 03 Nov 2002 05:26:12 -0800 Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 73190B7E; Sun, 3 Nov 2002 22:26:07 +0900 (JST) Message-Id: <4.2.0.58.J.20021103114321.0445b090@localhost> X-Sender: duerst@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Sun, 03 Nov 2002 11:47:31 +0900 To: Steve Dyer , idn@ops.ietf.org From: Martin Duerst Subject: Re: [idn] Re: idn-uri document In-Reply-To: <5.1.0.14.2.20021101093429.01b401a0@pop3.mailbox.co.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-8.0 required=5.0 tests=DATE_IN_PAST_06_12,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_02_03 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Steve, In an URI, *.example.org (e.g. http://*.example.org) is very clearly illegal. Also, I don't think it's a bad idea that a group that decides on the syntax of a new protocol element give some thoughts about where the rules should be checked, and where not, in order to assure consistent deployment. The restrictions on domain names given by IDNA/nameprep/ stringprep are not in any sense policy issues, they are very clearly technical issues. Regards, Martin. At 09:40 02/11/01 +0000, Steve Dyer wrote: >At 23:40 31/10/2002 +0100, Erik Nordmark wrote: >> > >The defined syntax rules for declare certain ASCII domain names illegal >> > >(such as *.example.org). Where is the check for illedgal names assumed to >> > >be performed? For IDNA it probably makes sense to only apply this types >> > >of checks (setting the UseSTD3ASCIIRules flag) when verifying domain name >> > >registrations and not do such checks in the clients. >> > >> > This is an IDNA question, not a idn-uri question. As far as I remember, >> > the idea was to have the checks done on the clients, too (with some >> > leeway for unassigned characters to stay forward-compatible with >> > new character assignements). The reason for this was to create >> > pressure on registries to follow the rules. > >Hi, >I am surprised that you indicate that certain ASCII domains will be >illegal. I can see why unix people may be unhappy about "*.example.org". >I trust that most high ASCII will be allowed - "$Bq(B (e-acute) for example >since software such as BIND9 handles them. > >I am also concerned that a group discussing a protocol is suggesting that >the protocol is designed to "create pressure on registries". A protocol is >a stand-alone technical facility, not an instrument of policy. > >Regards > >Steve Dyer >CentralNic Ltd > > From owner-idn@ops.ietf.org Sun Nov 3 08:35:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05460 for ; Sun, 3 Nov 2002 08:35:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188Kle-0009C4-00 for idn-data@psg.com; Sun, 03 Nov 2002 05:26:18 -0800 Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201] ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 188Klb-0009BX-00 for idn@ops.ietf.org; Sun, 03 Nov 2002 05:26:16 -0800 Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id B521039A; Sun, 3 Nov 2002 22:26:11 +0900 (JST) Message-Id: <4.2.0.58.J.20021103151623.0281adc8@localhost> X-Sender: duerst@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Sun, 03 Nov 2002 15:49:18 +0900 To: Erik Nordmark From: Martin Duerst Subject: Re: [idn] Re: idn-uri document Cc: idn@ops.ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.5 required=5.0 tests=DATE_IN_PAST_06_12,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk At 23:40 02/10/31 +0100, Erik Nordmark wrote: > > Ah, I see, of course the resolvers pass things through and then > > pass the negative result back, so they don't actually reject it. > > So now the sentence reads: > > > > However, such syntax should never be used, and will never be > > resolved because no such domains will be registered. > >ok > > > > >The defined syntax rules for declare certain ASCII domain names illegal > > >(such as *.example.org). Where is the check for illedgal names assumed to > > >be performed? For IDNA it probably makes sense to only apply this types > > >of checks (setting the UseSTD3ASCIIRules flag) when verifying domain name > > >registrations and not do such checks in the clients. > > > > This is an IDNA question, not a idn-uri question. As far as I remember, > > the idea was to have the checks done on the clients, too (with some > > leeway for unassigned characters to stay forward-compatible with > > new character assignements). The reason for this was to create > > pressure on registries to follow the rules. > >My point is that the idn-uri document is more restrictive in its >syntax than the IDNA document. I don't know if this is a good idea >or a bad idea, and we need to understand which type of idea it is. URIs [RFC 2396] uses the same restrictions as STD3. I think it therefore makes sense to also use these restrictions in this upgrade. On the other hand, while URI syntax contains these checks, URI implementations are supposed to not check (because they would need scheme-specific knowledge to do so, which would restrict deployment of new schemes (even more than it's currently restricted)). > > >The above statement says that for all domain names (note that the term > > >"IDN" is defined to include the existing ASCII domain names) > > >one should apply nameprep. This might be fine but it makes sense > > >stating this explicitly. The ToASCII in IDNA does not apply nameprep > > >to all-ASCII labels. > > > > The idea was simply to say: We RECOMMEND that you apply the IDNA rules > > already when you create an URI. What these rules are is up to IDNA. > > If IDNA says that their preparation of ascii-only labels is the > > identity operation, then we recommend that you apply that (i.e. do > > nothing), and not something else. If you see a way to make this clearer, > > please tell me. > >It is the identity operation for ASCII-only labels (plus some checks >that will reject certain labels). > >If you want to do that part, but not apply the Punycode step >then I think you need to explicitly state that one should >apply ToASCII without the punycode step (and other steps that don't >make sense if there are any). Yes, thanks, fixed. > > >Which are the "any steps required as part of domain name resolution" > > >above? I can't figure out to what it might refer. > > > > That's the nameprep and related checking that the client has to > > do when it resolves a domain name. In IDNA terms, 'client' would > > be easy to understand. But using the word 'client' in an URI context > > doesn't work, so I tried to word around it. Any improved wording > > appreciated. > >In that case I think refering to ToASCII would be best. I have changed the parts in question to read: >>>> For domain names containing non-ASCII characters, the legal domain names are those for which the ToASCII operation ([IDNA], [Nameprep]; using the unescaped UTF-8 values as input), with the flags "UseSTD3ASCIIRules" and "AllowUnassigned" set, is successful. The URI resolver MUST apply any steps required as part of domain name resolution by [IDNA], in particular the ToASCII operation, with the above-mentioned flags set. URIs where the ToASCII operation results in an error should be treated as unresolvable. For domain names containing non-ASCII characters, the Nameprep specification ([Nameprep]) defines some mappings, which mainly include normalization to NFKC and folding to lower case. When encoding an internationalized domain name in an URI, these mappings SHOULD NOT be applied. It should be assumed that the domain name is already normalized as far as appropriate. >>>> I have explicitly changed it so that encoding does not require any Nameprep steps, have clearly and repeatedly mentioned ToASCII, and have added the necessary flags. > > >Finally, is the intent that nameprep always be applied before characters > > >are encoded in UTF-8? Then it makes sense stating that in the first real > > >paragraph on page 4. > > > > No. In the context e.g. of IRIs, the conversion from an IRI to an URI > > would not do nameprep. > >OK. Then it makes sense stating that explicitly somewhere. Done above. I'm submitting a new draft, it should show up in the directory in a few days (due to backlog). Regards, Martin. From owner-idn@ops.ietf.org Sun Nov 3 18:56:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17286 for ; Sun, 3 Nov 2002 18:56:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188UTl-0007Rc-00 for idn-data@psg.com; Sun, 03 Nov 2002 15:48:29 -0800 Received: from bean.ar.com ([66.123.187.68]) by psg.com with esmtp (Exim 3.36 #2) id 188UTj-0007RQ-00 for idn@ops.ietf.org; Sun, 03 Nov 2002 15:48:27 -0800 Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.2/8.12.0) with ESMTP id gA3NmRFP023499 for ; Sun, 3 Nov 2002 15:48:27 -0800 (PST) Date: Sun, 3 Nov 2002 15:48:26 -0800 (PST) From: Rick Wesson To: Subject: [idn] punnycode in java Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.2 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk anyone know of a punycode implementation in java source? thanks, -rick From owner-idn@ops.ietf.org Mon Nov 4 03:57:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06978 for ; Mon, 4 Nov 2002 03:57:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188ctN-000OaP-00 for idn-data@psg.com; Mon, 04 Nov 2002 00:47:29 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #2) id 188ctL-000Oa9-00 for idn@ops.ietf.org; Mon, 04 Nov 2002 00:47:27 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA21303; Mon, 4 Nov 2002 01:47:25 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gA48lOL20211; Mon, 4 Nov 2002 09:47:24 +0100 (MET) Date: Sun, 3 Nov 2002 20:07:10 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] Re: idn-uri document To: Martin Duerst Cc: Erik Nordmark , idn@ops.ietf.org In-Reply-To: "Your message with ID" <4.2.0.58.J.20021103151623.0281adc8@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-3.5 required=5.0 tests=DATE_IN_PAST_12_24,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk > URIs [RFC 2396] uses the same restrictions as STD3. I think it > therefore makes sense to also use these restrictions in this > upgrade. > > On the other hand, while URI syntax contains these checks, URI > implementations are supposed to not check (because they would need > scheme-specific knowledge to do so, which would restrict > deployment of new schemes (even more than it's currently restricted)). Hmm, is this captured in some specification? Clearly(?) URI parsers will have to enforce some syntax checks e.g. in order to tell which part of a URI is a domain name. Erik From owner-idn@ops.ietf.org Tue Nov 5 05:38:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09454 for ; Tue, 5 Nov 2002 05:38:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1890y3-000081-00 for idn-data@psg.com; Tue, 05 Nov 2002 02:29:55 -0800 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #2) id 1890y0-00007p-00 for idn@ops.ietf.org; Tue, 05 Nov 2002 02:29:52 -0800 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.6/8.12.6) with ESMTP id gA5ATjFu005475 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 5 Nov 2002 11:29:45 +0100 To: idn@ops.ietf.org Subject: [idn] Sample test vectors? X-Hashcash: 0:021105:idn@ops.ietf.org:f462e7fb31d2e998 From: Simon Josefsson Date: Tue, 05 Nov 2002 11:29:45 +0100 Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2.92 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.5 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Has anyone developed test vectors for stringprep and/or IDNA? I think such a document would be useful, to test implementations. A'la enumerating results like the following, together with details on the profile used: STRINGPREP("foo\xC2\xADbar") => "foobar" STRINGPREP("\xC2\xB5") => "\xCE\xBC" STRINGPREP("\xC2\xAA") => "\x61" From owner-idn@ops.ietf.org Tue Nov 5 13:34:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04039 for ; Tue, 5 Nov 2002 13:34:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1898Qm-0003hK-00 for idn-data@psg.com; Tue, 05 Nov 2002 10:28:04 -0800 Received: from [209.187.148.217] (helo=P2) by psg.com with esmtp (Exim 3.36 #2) id 1898Qj-0003h0-00; Tue, 05 Nov 2002 10:28:02 -0800 Date: Tue, 05 Nov 2002 13:23:53 -0500 From: John C Klensin To: Erik Nordmark , Martin Duerst cc: idn@ops.ietf.org Subject: Re: [idn] Re: idn-uri document Message-ID: <64525620.1036502633@localhost> In-Reply-To: References: X-Mailer: Mulberry/3.0.0b8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-6.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Thursday, 31 October, 2002 23:40 +0100 Erik Nordmark wrote: >> If IDNA says that their preparation of ascii-only labels is >> the identity operation, then we recommend that you apply that >> (i.e. do nothing), and not something else. If you see a way >> to make this clearer, please tell me. > > It is the identity operation for ASCII-only labels (plus some > checks that will reject certain labels). > > If you want to do that part, but not apply the Punycode step > then I think you need to explicitly state that one should > apply ToASCII without the punycode step (and other steps that > don't make sense if there are any). Erik, I tried to raise this argument in some of my remarks about IDNA, but, as with many other things, it was apparently ignored by the IESG. Let me repeat it, in a different way, in this context. One of the things that many of us feel is key to the success of the Internet protocol suite is a minimum of profiling and options for variations within a protocol. That is obviously a principle, not a hard rule: the stringprep-nameprep separation arose as the better choice relative to having different protocols make up their own mapping variations. But, even in that case, we haven't permitted profile variations _within_ IDNA: a user, site, or registry cannot select a different stringprep profile, and that is a Good, probably necessary, thing. But much the same argument applies to the type of use Martin contemplates. IDNA, as written, is _one_ protocol. It is not a toolkit for building other protocols, nor is it a a set of profiles that other protocols can adopt. Those two may be much the same thing in practice. As soon as we say "you should use that operation from IDNA, but without some particular step" we head down a slippery slope. That is especially true because IDNA contains (or appears to contain) a good deal of normative text outside the particular of, e.g., ToASCII. It is not clear whether "...explicitly state that one should apply ToASCII without the punycode step (and other steps..." includes some, all, or none of those textual specifications. And, whatever choice is made, "do just what is done over there, except..." is a poor way to do protocol specification and introduces some of the worst properties of profiling without any of the benefits of being explicit about what can, and cannot, be profiled. john From owner-idn@ops.ietf.org Tue Nov 5 19:02:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26220 for ; Tue, 5 Nov 2002 19:02:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189DZ7-0005Od-00 for idn-data@psg.com; Tue, 05 Nov 2002 15:57:01 -0800 Received: from [209.124.80.2] (helo=hosting.altserver.com) by psg.com with esmtp (Exim 3.36 #2) id 189DYb-0005OD-00 for idn@ops.ietf.org; Tue, 05 Nov 2002 15:56:29 -0800 Received: from lns03m-1-155.w.club-internet.fr ([212.194.48.155] helo=mine.jefsey.com) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 189DYY-0004PU-00 for idn@ops.ietf.org; Tue, 05 Nov 2002 15:56:27 -0800 Message-Id: <5.1.0.14.0.20021106003005.036f9030@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 06 Nov 2002 00:44:54 +0100 To: idn@ops.ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [idn] Re: idn-uri document In-Reply-To: <64525620.1036502633@localhost> References: Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-68DD11CE; boundary="=======21CF2481=======" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk --=======21CF2481======= Content-Type: text/plain; x-avg-checked=avg-ok-68DD11CE; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit I came in here just to say two things as a "user" - the punycode thing seems OK but the DNS aspects are inadequate" - the text you produced is not easily understandable. I was said to be a troll for the second point. May be could we also look at the second one? At 19:23 05/11/02, John C Klensin wrote: >--On Thursday, 31 October, 2002 23:40 +0100 Erik Nordmark >But, even in that case, we haven't permitted profile variations _within_ >IDNA: a user, site, or registry cannot select a different stringprep >profile, and that is a Good, probably necessary, thing. "probably" necessary ??? At this date, this rises a lot of question. All I found was a very early commitment to that in the process. I did not read everythng yet. Any reason why it is "certainly" necessary? (a part from obvious non technical reasons) But much the same argument applies to the type of use Martin >contemplates. IDNA, as written, is _one_ protocol. It is not >a toolkit for building other protocols, nor is it a a set of >profiles that other protocols can adopt. Those two may be much >the same thing in practice. As soon as we say "you should use >that operation from IDNA, but without some particular step" we >head down a slippery slope. That is especially true because >IDNA contains (or appears to contain) a good deal of normative >text outside the particular of, e.g., ToASCII. It is not clear >whether "...explicitly state that one should apply ToASCII >without the punycode step (and other steps..." includes some, >all, or none of those textual specifications. And, whatever >choice is made, "do just what is done over there, except..." is >a poor way to do protocol specification and introduces some of >the worst properties of profiling without any of the benefits of >being explicit about what can, and cannot, be profiled. You point is accepted. But to say that applying ToASCII to a valid ASCII name is equivalent to do nothing does not removes the need to use ToASCII, but helps understanding that this is what actually happens. The way it is written leaves many questions open. jfc --=======21CF2481=======-- From owner-idn@ops.ietf.org Tue Nov 5 21:44:09 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05810 for ; Tue, 5 Nov 2002 21:44:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189G3m-000K64-00 for idn-data@psg.com; Tue, 05 Nov 2002 18:36:50 -0800 Received: from [209.124.80.2] (helo=hosting.altserver.com) by psg.com with esmtp (Exim 3.36 #2) id 189G3k-000K5s-00 for idn@ops.ietf.org; Tue, 05 Nov 2002 18:36:48 -0800 Received: from lns03m-1-155.w.club-internet.fr ([212.194.48.155] helo=mine.jefsey.com) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 189G3i-00080X-00 for idn@ops.ietf.org; Tue, 05 Nov 2002 18:36:47 -0800 Message-Id: <5.1.0.14.0.20021106032934.023e2030@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 06 Nov 2002 03:30:26 +0100 To: idn@ops.ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [idn] Re: idn-uri document Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-68DD11CE; boundary="=======2B59997=======" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk --=======2B59997======= Content-Type: text/plain; x-avg-checked=avg-ok-68DD11CE; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit Hoops sorry: please read at the first one below : --- I came in here just to say two things as a "user" - the punycode thing seems OK but the DNS aspects are inadequate - the text you produced is not easily understandable. I was said to be a troll for the second point. May be could we also look at the (second) first one? At 19:23 05/11/02, John C Klensin wrote: >--On Thursday, 31 October, 2002 23:40 +0100 Erik Nordmark >But, even in that case, we haven't permitted profile variations _within_ >IDNA: a user, site, or registry cannot select a different stringprep >profile, and that is a Good, probably necessary, thing. "probably" necessary ??? At this date, this rises a lot of question. All I found was a very early commitment to that in the process. I did not read everythng yet. Any reason why it is "certainly" necessary? (a part from obvious non technical reasons) But much the same argument applies to the type of use Martin >contemplates. IDNA, as written, is _one_ protocol. It is not >a toolkit for building other protocols, nor is it a a set of >profiles that other protocols can adopt. Those two may be much >the same thing in practice. As soon as we say "you should use >that operation from IDNA, but without some particular step" we >head down a slippery slope. That is especially true because >IDNA contains (or appears to contain) a good deal of normative >text outside the particular of, e.g., ToASCII. It is not clear >whether "...explicitly state that one should apply ToASCII >without the punycode step (and other steps..." includes some, >all, or none of those textual specifications. And, whatever >choice is made, "do just what is done over there, except..." is >a poor way to do protocol specification and introduces some of >the worst properties of profiling without any of the benefits of >being explicit about what can, and cannot, be profiled. You point is accepted. But to say that applying ToASCII to a valid ASCII name is equivalent to do nothing does not removes the need to use ToASCII, but helps understanding that this is what actually happens. The way it is written leaves many questions open. jfc --=======2B59997=======-- From owner-idn@ops.ietf.org Tue Nov 5 22:01:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07110 for ; Tue, 5 Nov 2002 22:01:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189GNy-000Lx3-00 for idn-data@psg.com; Tue, 05 Nov 2002 18:57:42 -0800 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #2) id 189GNS-000Luw-00 for idn@ops.ietf.org; Tue, 05 Nov 2002 18:57:10 -0800 Received: (qmail 81732 invoked from network); 6 Nov 2002 02:56:49 -0000 Received: from bb-203-125-80-58.singnet.com.sg (HELO JSENGTOSHIBA) (203.125.80.58) by sentosa.post1.com with SMTP; 6 Nov 2002 02:56:49 -0000 Message-ID: <0ca901c28540$1fb51f00$b000a8c0@JSENGTOSHIBA> From: "James Seng" To: , "JFC \(Jefsey\) Morfin" References: <5.1.0.14.0.20021106032934.023e2030@mail.jefsey.com> Subject: Re: [idn] Re: idn-uri document Date: Wed, 6 Nov 2002 10:56:36 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-1.7 required=5.0 tests=INVALID_MSGID,REFERENCES,SPAM_PHRASE_03_05,USER_AGENT_OE version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I came in here just to say two things as a "user" > - the punycode thing seems OK but the DNS aspects are > inadequate > - the text you produced is not easily understandable. > I was said to be a troll for the second point. May be > could we also look at the (second) first one? The document is written for an engineer, not an "user". End-user without appropriate technical background will not likely to be able to understand this (or any other Standard RFC for that matter). I have asked you to read the books from Unicode Consortium and other documents. You have replied that you are not interested to do so. So let me repeat my request again. Please read up those books to get a basic understand of the discussion going on here. Thanks. > "probably" necessary ??? > At this date, this rises a lot of question. [snip] > The way it is written leaves many questions open. What is "lot of question" and what are the "questions open"? Your mail did not ask anything except some handwaving about "obvious" and 'certainly". Sorry, but this is not GA. We dont weasel here so please be more specific. -James Seng From owner-idn@ops.ietf.org Wed Nov 6 02:34:44 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07793 for ; Wed, 6 Nov 2002 02:34:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189KWj-000JX4-00 for idn-data@psg.com; Tue, 05 Nov 2002 23:23:01 -0800 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #2) id 189KWD-000JTG-00 for idn@ops.ietf.org; Tue, 05 Nov 2002 23:22:29 -0800 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.6/8.12.6) with ESMTP id gA67MOFu028387 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 6 Nov 2002 08:22:25 +0100 To: idn@ops.ietf.org Subject: [idn] [ANNOUNCE] Stringprep implementation X-Hashcash: 0:021106:idn@ops.ietf.org:81a3377428cab54c From: Simon Josefsson Date: Wed, 06 Nov 2002 08:22:24 +0100 Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2.92 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-1.8 required=5.0 tests=SPAM_PHRASE_02_03,USER_AGENT version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Libstringprep is an implementation of the Stringprep specification used by the Internationalized Domain Names IETF working group to implement internationalized domain names. It is licensed under the GNU Lesser General Public License. The library implements Unicode 3.2 NFKC normalization, mapping characters in strings according to Stringprep, and the Bidirectional Character handling steps of Stringprep. The simple API consists of two main functions, one for converting data from the system's native representation into UTF-8, and one function to perform the Stringprep processing. The library contains the Nameprep and Kerberos 5 stringprep profiles, but adding a new Stringprep profile is straightforward. The library is currently used by forthcoming SASL and Kerberos libraries to process user names and passwords before they are input to cryptographic operations. No domain name related application use it. The library has been tested on several different Unix systems (including Linux, Solaris, IRIX, AIX, and Tru64). It was designed to be ported easily to Windows as well. The project page of the library is available at: http://www.josefsson.org/libstringprep/ For more information see: http://www.ietf.org/html.charters/idn-charter.html http://www.ietf.org/internet-drafts/draft-hoffman-stringprep-07.txt http://www.i-d-n.net/ From owner-idn@ops.ietf.org Wed Nov 6 09:38:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22519 for ; Wed, 6 Nov 2002 09:38:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189R7m-000Ljm-00 for idn-data@psg.com; Wed, 06 Nov 2002 06:25:42 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #2) id 189R7f-000LjI-00 for idn@ops.ietf.org; Wed, 06 Nov 2002 06:25:35 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03890; Wed, 6 Nov 2002 07:25:29 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gA6EPLL00233; Wed, 6 Nov 2002 15:25:23 +0100 (MET) Date: Wed, 6 Nov 2002 15:22:19 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] Re: idn-uri document To: John C Klensin Cc: Erik Nordmark , Martin Duerst , idn@ops.ietf.org In-Reply-To: "Your message with ID" <64525620.1036502633@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk > But much the same argument applies to the type of use Martin > contemplates. IDNA, as written, is _one_ protocol. It is not > a toolkit for building other protocols, nor is it a a set of > profiles that other protocols can adopt. Those two may be much > the same thing in practice. As soon as we say "you should use > that operation from IDNA, but without some particular step" we > head down a slippery slope. That is especially true because > IDNA contains (or appears to contain) a good deal of normative > text outside the particular of, e.g., ToASCII. It is not clear > whether "...explicitly state that one should apply ToASCII > without the punycode step (and other steps..." includes some, > all, or none of those textual specifications. And, whatever > choice is made, "do just what is done over there, except..." is > a poor way to do protocol specification and introduces some of > the worst properties of profiling without any of the benefits of > being explicit about what can, and cannot, be profiled. Which is why I welcome folks that try to use IDN(A) is new protocols to share their experience. That way we can collectively learn about the actual issues that folks run into and use that to improve on the way IDNA is specified. In addition to the URI side there is also the registry side where I think there is active development today. And I hope that somebody will try to explore new protocols that will not use an ACE for the IDNs so that we can collectively understand the issues in that space as well. Erik From owner-idn@ops.ietf.org Wed Nov 6 11:18:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29929 for ; Wed, 6 Nov 2002 11:18:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189Sg1-0003pX-00 for idn-data@psg.com; Wed, 06 Nov 2002 08:05:09 -0800 Received: from [209.124.80.2] (helo=hosting.altserver.com) by psg.com with esmtp (Exim 3.36 #2) id 189Sfy-0003pJ-00 for idn@ops.ietf.org; Wed, 06 Nov 2002 08:05:07 -0800 Received: from lns03m-5-78.w.club-internet.fr ([212.194.52.78] helo=mine.jefsey.com) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 189Scj-0004EC-00; Wed, 06 Nov 2002 08:01:46 -0800 Message-Id: <5.1.0.14.0.20021106165947.02acdec0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 06 Nov 2002 17:04:25 +0100 To: Erik Nordmark , John C Klensin From: "JFC (Jefsey) Morfin" Subject: Re: [idn] Re: idn-uri document Cc: Erik Nordmark , Martin Duerst , idn@ops.ietf.org In-Reply-To: References: <"Your message with ID" <64525620.1036502633@localhost> Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-4E20650A; boundary="=======7D2D2D4D=======" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Status: No, hits=-6.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk --=======7D2D2D4D======= Content-Type: text/plain; x-avg-checked=avg-ok-4E20650A; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit At 15:22 06/11/02, Erik Nordmark wrote: > > But much the same argument applies to the type of use Martin > > contemplates. IDNA, as written, is _one_ protocol. It is not > > a toolkit for building other protocols, nor is it a a set of > > profiles that other protocols can adopt. Those two may be much > > the same thing in practice. As soon as we say "you should use > > that operation from IDNA, but without some particular step" we > > head down a slippery slope. That is especially true because > > IDNA contains (or appears to contain) a good deal of normative > > text outside the particular of, e.g., ToASCII. It is not clear > > whether "...explicitly state that one should apply ToASCII > > without the punycode step (and other steps..." includes some, > > all, or none of those textual specifications. And, whatever > > choice is made, "do just what is done over there, except..." is > > a poor way to do protocol specification and introduces some of > > the worst properties of profiling without any of the benefits of > > being explicit about what can, and cannot, be profiled. > >Which is why I welcome folks that try to use IDN(A) is new protocols >to share their experience. That way we can collectively learn about the >actual issues that folks run into and use that to improve on the way >IDNA is specified. > >In addition to the URI side there is also the registry side where I >think there is active development today. And I hope that somebody will >try to explore new protocols that will not use an ACE for the IDNs >so that we can collectively understand the issues in that space as well. Would there be a test nameprep C code to help with test registry tools? I suppose there are some traps to avoid. jfc --=======7D2D2D4D=======-- From owner-idn@ops.ietf.org Thu Nov 7 06:43:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12350 for ; Thu, 7 Nov 2002 06:43:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189kom-000ITd-00 for idn-data@psg.com; Thu, 07 Nov 2002 03:27:24 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 189kok-000ITR-00 for idn@ops.ietf.org; Thu, 07 Nov 2002 03:27:22 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10748; Thu, 7 Nov 2002 06:24:51 -0500 (EST) Message-Id: <200211071124.GAA10748@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [idn] I-D ACTION:draft-ietf-idn-uri-03.txt Date: Thu, 07 Nov 2002 06:24:51 -0500 X-Spam-Status: No, hits=1.8 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.41 X-Spam-Level: * Sender: owner-idn@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : Internationalized Domain Names in URIs Author(s) : M. Duerst Filename : draft-ietf-idn-uri-03.txt Pages : 8 Date : 2002-11-6 This document proposes to upgrade the definition of URIs (RFC 2396) [RFC2396] to work consistently with internationalized domain names. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-uri-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idn-uri-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-uri-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-6174755.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-uri-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-uri-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-6174755.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idn@ops.ietf.org Thu Nov 7 08:48:54 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24030 for ; Thu, 7 Nov 2002 08:48:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189mrm-0004QZ-00 for idn-data@psg.com; Thu, 07 Nov 2002 05:38:38 -0800 To: idn@ops.ietf.org Subject: [idn] Re: Privacy Policy References: <200211071321.VAA04362@msr.hinet.net> In-Reply-To: <200211071321.VAA04362@msr.hinet.net> X-URL: http://www.ietf.org/ Reply-to: nsyracus@ietf.org Subject: [idn] Autoreply from Internet Draft Submission Manager From: ietfauto@ietf.org (Internet Draft Submission Manager) Sender: owner-idn@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 07 Nov 2002 05:38:38 -0800 Greetings, We are sorry, but the cut-off for Internet-Draft submissions was Monday November 4 at 9AM ET. Your submission will not be retained (i.e. you need to resubmit) after November 17, 2002. If you receive this announcement, your submission will NOT be processed. Any submissions received prior to November 18, 2002 will not be retained; they must be resubmitted. Internet-Draft submissions received on or after November 18 will be processed. However, Internet-Draft announcements will not be sent until after the IETF Meeting in Atlanta. AS you may surmise, this is an extremly busy week. Be advised that it may take a number of days to process and announce your document. Our goal is to process and announce all valid Internet-Draft submissions by November 12 at the latest. Thank you for your understanding. IETF Secretariat From owner-idn@ops.ietf.org Thu Nov 7 15:25:00 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10033 for ; Thu, 7 Nov 2002 15:24:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189t3E-000Hib-00 for idn-data@psg.com; Thu, 07 Nov 2002 12:14:52 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 189t36-000HhP-00; Thu, 07 Nov 2002 12:14:44 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08965 for <1timer>; Thu, 7 Nov 2002 15:11:40 -0500 (EST) Message-Id: <200211072011.PAA08965@ietf.org> From: The IESG To: All IETF Working Groups: ; Subject: [idn] Note Well Statement x-msg: NoteWell Date: Thu, 07 Nov 2002 15:11:40 -0500 X-Spam-Status: No, hits=0.9 required=5.0 tests=SPAM_PHRASE_01_02,TO_HAS_SPACES,TO_MALFORMED version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk From time to time, especially just before a meeting, this statement is to be sent to each and every IETF working group mailing list. =========================================================================== NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. From owner-idn@ops.ietf.org Thu Nov 7 17:24:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15849 for ; Thu, 7 Nov 2002 17:24:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189uzx-0004eN-00 for idn-data@psg.com; Thu, 07 Nov 2002 14:19:37 -0800 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by psg.com with esmtp (Exim 3.36 #2) id 189uzv-0004eA-00 for idn@ops.ietf.org; Thu, 07 Nov 2002 14:19:35 -0800 Received: from [165.227.249.18] (165-227-249-18.client.dsl.net [165.227.249.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA7MJTv02965; Thu, 7 Nov 2002 14:19:30 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <5.1.0.14.0.20021106165947.02acdec0@mail.jefsey.com> References: <"Your message with ID" <64525620.1036502633@localhost> <5.1.0.14.0.20021106165947.02acdec0@mail.jefsey.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, 7 Nov 2002 14:19:09 -0800 To: idn@ops.ietf.org From: Paul Hoffman / IMC Subject: Re: [idn] Re: idn-uri document Cc: Martin Duerst Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-6.0 required=5.0 tests=HABEAS_SWE,IN_REP_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk In draft -03, it says: For domain names containing non-ASCII characters, the Nameprep specification ([Nameprep]) defines some mappings, which mainly include normalization to NFKC and folding to lower case. When encoding an internationalized domain name in an URI, these mappings SHOULD NOT be applied. It should be assumed that the domain name is already normalized as far as appropriate. Why the "SHOULD NOT"? What's wrong with a system that creates URIs doing that? An alternate wording for the last two sentences would be: When encoding an internationalized domain name in an URI, these mappings do not need to be applied if the domain name is already normalized as far as appropriate. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Fri Nov 8 01:39:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28427 for ; Fri, 8 Nov 2002 01:39:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18A2Zu-000OgG-00 for idn-data@psg.com; Thu, 07 Nov 2002 22:25:14 -0800 Received: from arwen.cs.berkeley.edu ([128.32.132.165] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #2) id 18A2Zp-000Og1-00 for idn@ops.ietf.org; Thu, 07 Nov 2002 22:25:09 -0800 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 18A2Zp-0005H0-00 for ; Thu, 07 Nov 2002 22:25:09 -0800 Date: Fri, 8 Nov 2002 06:25:09 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] Re: idn-uri document Message-ID: <20021108062508.GA19437@nicemice.net> Reply-To: IETF idn working group References: <64525620.1036502633@localhost> <5.1.0.14.0.20021106165947.02acdec0@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-14.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Paul Hoffman / IMC wrote: > In draft -03, it says: > > For domain names containing non-ASCII characters, the Nameprep > specification ([Nameprep]) defines some mappings, which mainly > include normalization to NFKC and folding to lower case. When > encoding an internationalized domain name in an URI, these > mappings SHOULD NOT be applied. It should be assumed that the > domain name is already normalized as far as appropriate. > > Why the "SHOULD NOT"? Indeed, I also see no need for that recommendation. > An alternate wording for the last two sentences would be: > > When encoding an internationalized domain name in an URI, these > mappings do not need to be applied if the domain name is already > normalized as far as appropriate. Am I supposed to perform some test to determine whether the domain name is already normalized as far as appropriate? No. I find that clause confusing and unnecessary. I think the only point of this paragraph is that domain names in URIs are not necessarily Nameprepped. That's all it needs to say. Draft -03 says: > For domain names containing non-ASCII characters, the legal > domain names are those for which the ToASCII operation ([IDNA], > [Nameprep]; using the unescaped UTF-8 values as input), with the flags > "UseSTD3ASCIIRules" and "AllowUnassigned" set, is successful. The > URI resolver MUST apply any steps required as part of domain name > resolution by [IDNA], in particular the ToASCII operation, with the > above-mentioned flags set. URI resolvers should indeed set AllowUnassigned, but URI resolvers aren't the only things that use URIs. Consider a program that creates HTML documents. The domain names in those URIs are stored strings, and Stringprep requires that unassigned code points be prohibited in stored strings, so AllowUnassigned would have to be unset in that situation. Finally, I'd like to point out an important caveat: Even if the URI generic syntax is updated to allow non-ASCII characters (escaped) in the host field, that doesn't mean you can actually put non-ASCII domain names into any URI you please. The IDNA rules still apply. If you know that a URI is occupying an IDN-aware slot (for example, if it appears in a new version of HTML that refers to the IDNA spec, or if it appears in an old-HTML document but new HTTP features are used to negotiate IDN-awareness), then you're free to put non-ASCII domain names (escaped) into the URI. But otherwise IDNA section 3.1 requirement 2 applies, and the domain name must contain only ASCII characters. The rationale is to prevent non-ASCII domain names from falling into the unwitting hands of old software that will choke on them. It might be prudent for the idn-uri document to remind the reader of this. AMC From owner-idn@ops.ietf.org Fri Nov 8 09:07:00 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19241 for ; Fri, 8 Nov 2002 09:06:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18A9bt-00083X-00 for idn-data@psg.com; Fri, 08 Nov 2002 05:55:45 -0800 Received: from maya20.nic.fr ([192.134.4.152]) by psg.com with esmtp (Exim 3.36 #2) id 18A9bq-000836-00 for idn@ops.ietf.org; Fri, 08 Nov 2002 05:55:43 -0800 Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id gA8DsH7I1357273; Fri, 8 Nov 2002 14:54:23 +0100 (CET) Received: by vespucci.nic.fr (Postfix, from userid 1000) id A9B3B10D2B; Fri, 8 Nov 2002 14:54:17 +0100 (CET) Date: Fri, 8 Nov 2002 14:54:17 +0100 From: Stephane Bortzmeyer To: "JFC (Jefsey) Morfin" Cc: Erik Nordmark , John C Klensin , Martin Duerst , idn@ops.ietf.org Subject: Re: [idn] Re: idn-uri document Message-ID: <20021108135417.GA24275@nic.fr> References: <64525620.1036502633@localhost> <5.1.0.14.0.20021106165947.02acdec0@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.0.20021106165947.02acdec0@mail.jefsey.com> User-Agent: Mutt/1.3.28i X-Operating-System: Debian GNU/Linux 3.0 X-Kernel: Linux 2.4.18-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ X-Spam-Status: No, hits=-12.7 required=5.0 tests=IN_REP_TO,NOSPAM_INC,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk On Wed, Nov 06, 2002 at 05:04:25PM +0100, JFC (Jefsey) Morfin wrote a message of 42 lines which said: > Would there be a test nameprep C code to help with test > registry tools? I suppose there are some traps to avoid. There are some tools From owner-idn@ops.ietf.org Fri Nov 8 21:40:53 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28047 for ; Fri, 8 Nov 2002 21:40:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ALEF-0004y3-00 for idn-data@psg.com; Fri, 08 Nov 2002 18:20:07 -0800 Received: from arwen.cs.berkeley.edu ([128.32.132.165] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #2) id 18ALED-0004xq-00 for idn@ops.ietf.org; Fri, 08 Nov 2002 18:20:05 -0800 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 18ALE9-0007pk-00 for ; Fri, 08 Nov 2002 18:20:01 -0800 Date: Sat, 9 Nov 2002 02:20:01 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] Re: idn-uri document Message-ID: <20021109022000.GA29012@nicemice.net> Reply-To: IETF idn working group References: <64525620.1036502633@localhost> <5.1.0.14.0.20021106165947.02acdec0@mail.jefsey.com> <20021108062508.GA19437@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021108062508.GA19437@nicemice.net> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-13.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk I wrote: > If you know that a URI is occupying an IDN-aware slot, then you're > free to put non-ASCII domain names (escaped) into the URI. But > otherwise IDNA section 3.1 requirement 2 applies, and the domain name > must contain only ASCII characters. I was assuming that the URI occupies a slot of some sort. If it is not in a slot at all (for example, it appears in a plain text message body), then requirement 2 does not apply, and you are free to put non-ASCII domain names in it. I have a question about the rationale behind allowing non-ASCII domain names in URIs. A URI containing a non-ASCII domain name seems to be useful only for software that is IDN-aware but IRI-unaware. If the software is IDN-unaware, it will choke on the URI. If the software is both IDN-aware and IRI-aware, then you might as well use an IRI rather than a URI, to avoid the ugly %-escaped UTF-8. My question is, do we really expect to see much, if any, software that is IDN-aware and IRI-unaware? IDNs and IRIs are being introduced at roughly the same time, and both deal with internationalization. Isn't it reasonable to assume that almost all web-related software will either support both, or support neither? Why complicate things by introducing a new IDN-supporting URI type if it's not useful? URIs with ACE are ugly, but work with old software. IRIs with non-ASCII domain names are pretty, but require new software. URIs with %-escaped non-ASCII domain names are both ugly and require new software, so what's the point? Here's another model to consider: All generic URIs (URIs beginning with scheme://) continue to be IDN-unaware, and therefore the host field must contain only ASCII characters. Generic IRI syntax (any IRI beginning with scheme://) is IDN-aware, and therefore non-ASCII names are allowed in the host field (escaped). I don't think there will be any problem converting generic IRIs to generic URIs, even if domain names happen to appear in other places (the path or query-string). In the generic syntax, the host field is the only place a domain name can appear that has client-side semantics. If domain names happen to appear anywhere else in the URI, they must be interpreted by the server, right? If non-ASCII domain names appear in a generic IRI outside the host field, that must mean the server is IDN-aware, and therefore those domain names don't need to be converted to ACE if the IRI is converted to a URI. The server will still be IDN-aware regardless of whether it is accessed via a URI or an IRI. The host field is the only domain name that needs to be ToASCII'd when converting a generic IRI to a URI. For converting non-generic IRIs to URIs, if you know the scheme, you can extract the domain names and apply ToASCII to them. If you don't know the scheme, then you have no way of knowing if the URI you produce might contain non-ASCII domain names that old software will choke on. Whether we call the URI valid or invalid doesn't change the fact of whether it breaks old software. Calling the URI valid is like blaming the old software for conforming to yesterday's standard. Calling the URI invalid is like blaming the convertor for performing a conversion without enough knowledge to do it safely. The latter makes more sense to me. How many non-generic URI schemes containing domain names are there? Suppose we require that after the introduction of IRIs all new non-generic schemes containing domain names must either be IDN-aware for both URIs and IRIs, or IDN-unaware for both URIs and IRIs. Then IRI-to-URI convertors won't need to do anything special for those schemes. The number of schemes that convertors need to know about will never increase. AMC From owner-idn@ops.ietf.org Fri Nov 8 21:41:40 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28073 for ; Fri, 8 Nov 2002 21:41:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ALJx-0005Db-00 for idn-data@psg.com; Fri, 08 Nov 2002 18:26:01 -0800 Received: from arwen.cs.berkeley.edu ([128.32.132.165] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #2) id 18ALJv-0005DO-00 for idn@ops.ietf.org; Fri, 08 Nov 2002 18:25:59 -0800 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 18ALJu-0007rF-00 for ; Fri, 08 Nov 2002 18:25:58 -0800 Date: Sat, 9 Nov 2002 02:25:58 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: [idn] internationalized email addresses Message-ID: <20021109022558.GB29012@nicemice.net> Reply-To: IETF idn working group Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.6 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Work on IRIs appears to be well underway, but what about internationalized email addresses? Is it time to start that effort? If so, where should that discussion take place? AMC From owner-idn@ops.ietf.org Fri Nov 8 22:00:14 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28517 for ; Fri, 8 Nov 2002 22:00:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ALiK-0006U4-00 for idn-data@psg.com; Fri, 08 Nov 2002 18:51:12 -0800 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #2) id 18ALiH-0006Pr-00 for idn@ops.ietf.org; Fri, 08 Nov 2002 18:51:09 -0800 Received: (qmail 32252 invoked from network); 9 Nov 2002 02:50:34 -0000 Received: from bb-203-125-126-155.singnet.com.sg (HELO JSENGTOSHIBA) (203.125.126.155) by sentosa.post1.com with SMTP; 9 Nov 2002 02:50:34 -0000 Message-ID: <144101c2879a$c0972740$8f00a8c0@JSENGTOSHIBA> From: "James Seng" To: "IETF idn working group" References: <20021109022558.GB29012@nicemice.net> Subject: Re: [idn] internationalized email addresses Date: Sat, 9 Nov 2002 10:50:23 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-4.0 required=5.0 tests=INVALID_MSGID,MAILTO_TO_REMOVE,QUOTED_EMAIL_TEXT, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT_OE version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit See draft-faerber-i18n-email-netnews-names-00.txt -James Seng ----- Original Message ----- From: "Adam M. Costello" To: "IETF idn working group" Sent: Saturday, November 09, 2002 10:25 AM Subject: [idn] internationalized email addresses > Work on IRIs appears to be well underway, but what about > internationalized email addresses? Is it time to start that effort? If > so, where should that discussion take place? > > AMC > From owner-idn@ops.ietf.org Fri Nov 8 22:24:18 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28835 for ; Fri, 8 Nov 2002 22:24:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18AM9i-0007rr-00 for idn-data@psg.com; Fri, 08 Nov 2002 19:19:30 -0800 Received: from arwen.cs.berkeley.edu ([128.32.132.165] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #2) id 18AM9g-0007rf-00 for idn@ops.ietf.org; Fri, 08 Nov 2002 19:19:28 -0800 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 18AM9f-00084p-00 for ; Fri, 08 Nov 2002 19:19:27 -0800 Date: Sat, 9 Nov 2002 03:19:27 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] internationalized email addresses Message-ID: <20021109031927.GE28644@nicemice.net> Reply-To: IETF idn working group References: <20021109022558.GB29012@nicemice.net> <144101c2879a$c0972740$8f00a8c0@JSENGTOSHIBA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <144101c2879a$c0972740$8f00a8c0@JSENGTOSHIBA> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-11.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT,USER_AGENT_MUTT version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk James Seng wrote: > See draft-faerber-i18n-email-netnews-names-00.txt Are you suggesting that the discussion of internationalized email addresses take place on the usefor mailing list (at least for now)? AMC From owner-idn@ops.ietf.org Fri Nov 8 22:52:19 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29798 for ; Fri, 8 Nov 2002 22:52:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18AMWL-00090M-00 for idn-data@psg.com; Fri, 08 Nov 2002 19:42:53 -0800 Received: from sentosa.post1.com ([202.27.17.100]) by psg.com with smtp (Exim 3.36 #2) id 18AMWJ-0008yy-00 for idn@ops.ietf.org; Fri, 08 Nov 2002 19:42:51 -0800 Received: (qmail 32722 invoked from network); 9 Nov 2002 03:42:12 -0000 Received: from bb-203-125-126-155.singnet.com.sg (HELO JSENGTOSHIBA) (203.125.126.155) by sentosa.post1.com with SMTP; 9 Nov 2002 03:42:12 -0000 Message-ID: <148601c287a1$f78702a0$8f00a8c0@JSENGTOSHIBA> From: "James Seng" To: "IETF idn working group" References: <20021109022558.GB29012@nicemice.net> <144101c2879a$c0972740$8f00a8c0@JSENGTOSHIBA> <20021109031927.GE28644@nicemice.net> Subject: Re: [idn] internationalized email addresses Date: Sat, 9 Nov 2002 11:42:02 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-4.7 required=5.0 tests=INVALID_MSGID,MAILTO_TO_REMOVE,QUOTED_EMAIL_TEXT, REFERENCES,SPAM_PHRASE_01_02,USER_AGENT_OE version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit No, I dont know where the discussion of i18n email should be carried. No working group have been formed yet. But INTLOC seem to be the most logical place to hold that discussion, IMHO. -James Seng ----- Original Message ----- From: "Adam M. Costello" To: "IETF idn working group" Sent: Saturday, November 09, 2002 11:19 AM Subject: Re: [idn] internationalized email addresses > James Seng wrote: > > > See draft-faerber-i18n-email-netnews-names-00.txt > > Are you suggesting that the discussion of internationalized email > addresses take place on the usefor mailing list (at least for now)? > > AMC > From owner-idn@ops.ietf.org Fri Nov 8 23:13:56 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00804 for ; Fri, 8 Nov 2002 23:13:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18AMuj-000AIt-00 for idn-data@psg.com; Fri, 08 Nov 2002 20:08:05 -0800 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 18AMub-000AHs-00 for idn@ops.ietf.org; Fri, 08 Nov 2002 20:08:03 -0800 Received: (from root@localhost) by postel3.postel.co.kr (8.11.0/8.11.0) id gA947ji17509; Sat, 9 Nov 2002 13:07:45 +0900 Date: Sat, 9 Nov 2002 13:07:45 +0900 From: Soobok Lee To: IETF idn working group Subject: Re: [idn] internationalized email addresses Message-ID: <20021109040745.GA14972@postel.co.kr> References: <20021109022558.GB29012@nicemice.net> <144101c2879a$c0972740$8f00a8c0@JSENGTOSHIBA> <20021109031927.GE28644@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021109031927.GE28644@nicemice.net> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-7.6 required=5.0 tests=IN_REP_TO,RCVD_IN_RFCI,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.41 Sender: owner-idn@ops.ietf.org Precedence: bulk On Sat, Nov 09, 2002 at 03:19:27AM +0000, Adam M. Costello wrote: > James Seng wrote: > > > See draft-faerber-i18n-email-netnews-names-00.txt > I found this example in the draft: I think mbox name should have different prefix and different stringprep profiles than IDN label because mbox name has differnt security considerations and administration/operational characteristics than IDN has. Example: C: EHLO zq--frber-gra.muc.de C: MAIL FROM: From owner-idn@ops.ietf.org Tue Nov 12 11:36:31 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05654 for ; Tue, 12 Nov 2002 11:36:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Bdmr-00060u-00 for idn-data@psg.com; Tue, 12 Nov 2002 08:21:13 -0800 To: idn@ops.ietf.org Subject: [idn] Re: Privacy Policy References: <200211071321.VAA04362@msr.hinet.net> In-Reply-To: <200211071321.VAA04362@msr.hinet.net> X-URL: http://www.ietf.org/ Reply-to: nsyracus@ietf.org Subject: [idn] Autoreply from Internet Draft Submission Manager From: ietfauto@ietf.org (Internet Draft Submission Manager) Sender: owner-idn@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 12 Nov 2002 08:21:13 -0800 Greetings, We are sorry, but the cut-off for Internet-Draft submissions was Monday November 4 at 9AM ET. Your submission will not be retained (i.e. you need to resubmit) after November 17, 2002. If you receive this announcement, your submission will NOT be processed. Any submissions received prior to November 18, 2002 will not be retained; they must be resubmitted. Internet-Draft submissions received on or after November 18 will be processed. However, Internet-Draft announcements will not be sent until after the IETF Meeting in Atlanta. AS you may surmise, this is an extremly busy week. Be advised that it may take a number of days to process and announce your document. Our goal is to process and announce all valid Internet-Draft submissions by November 12 at the latest. Thank you for your understanding. IETF Secretariat From owner-idn@ops.ietf.org Sun Nov 17 22:51:10 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01517 for ; Sun, 17 Nov 2002 22:51:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Dckn-000HKO-00 for idn-data@psg.com; Sun, 17 Nov 2002 19:39:17 -0800 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.36 #2) id 18Dckl-000HJZ-00 for idn@ops.ietf.org; Sun, 17 Nov 2002 19:39:16 -0800 Received: from localhost (retro.viagenie.qc.ca [3ffe:b00:c18:3::22]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id gAI3dIa45245; Sun, 17 Nov 2002 22:39:18 -0500 (EST) Date: Sun, 17 Nov 2002 22:39:12 -0500 From: Marc Blanchet To: idn@ops.ietf.org cc: jseng@pobox.org.sg Subject: [idn] process message from the chairs Message-ID: <774000000.1037590752@classic.viagenie.qc.ca> X-Mailer: Mulberry/3.0.0a5 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The chairs with the agreement of the AD believe that it is time to close the working group. This will happen when the current drafts (stringprep, nameprep, idna, punycode) in the RFC queue are published. However, we are requesting to the secretariat to move any remaining wg drafts to individual submission status. The authors should follow the documented IETF process steps (RFC2026) for advancing these documents. These documents are: draft-ietf-idn-dnsii-trace-01.txt and draft-ietf-idn-uri-03.txt. Marc and James. From owner-idn@ops.ietf.org Tue Nov 19 23:12:13 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16669 for ; Tue, 19 Nov 2002 23:12:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EM3p-000AkF-00 for idn-data@psg.com; Tue, 19 Nov 2002 20:01:57 -0800 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.36 #2) id 18EM3k-000Aia-00 for idn@ops.ietf.org; Tue, 19 Nov 2002 20:01:52 -0800 Received: from localhost (retro.viagenie.qc.ca [3ffe:b00:c18:3::22]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id gAK41qa76288 for ; Tue, 19 Nov 2002 23:01:52 -0500 (EST) Date: Tue, 19 Nov 2002 23:01:44 -0500 From: Marc Blanchet To: idn@ops.ietf.org Subject: Re: [idn] process message from the chairs Message-ID: <128500000.1037764904@classic.viagenie.qc.ca> In-Reply-To: <774000000.1037590752@classic.viagenie.qc.ca> References: <774000000.1037590752@classic.viagenie.qc.ca> X-Mailer: Mulberry/3.0.0a5 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA16669 clarifications based on 2 questions I got in the corridors in Atlanta: - the mailing list will remain opened "forever" (not quite, but you get it), for the community to continue discuss related idn work. Marc. -- dimanche, novembre 17, 2002 22:39:12 -0500 Marc Blanchet wrote/a écrit: > > The chairs with the agreement of the AD believe that it is time to close > the working group. This will happen when the current drafts (stringprep, > nameprep, idna, punycode) in the RFC queue are published. However, we are > requesting to the secretariat to move any remaining wg drafts to > individual submission status. The authors should follow the documented > IETF process steps (RFC2026) for advancing these documents. These > documents are: draft-ietf-idn-dnsii-trace-01.txt and > draft-ietf-idn-uri-03.txt. > > Marc and James. > From owner-idn@ops.ietf.org Mon Nov 25 07:24:01 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25196 for ; Mon, 25 Nov 2002 07:24:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GI4d-0000x9-00 for idn-data@psg.com; Mon, 25 Nov 2002 04:10:47 -0800 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #2) id 18GI4a-0000wx-00 for idn@ops.ietf.org; Mon, 25 Nov 2002 04:10:45 -0800 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.6/8.12.6) with ESMTP id gAPCAe5h020171 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 25 Nov 2002 13:10:41 +0100 To: idn@ops.ietf.org Subject: [idn] Re: Fwd: Unicode letter ballot References: <0A56805A-FF88-11D6-A024-0003934B2128@cisco.com> X-Hashcash: 0:021125:idn@ops.ietf.org:f35aab8cc3e67182 From: Simon Josefsson Date: Mon, 25 Nov 2002 13:10:39 +0100 In-Reply-To: <0A56805A-FF88-11D6-A024-0003934B2128@cisco.com> (Patrik =?iso-8859-1?q?F=E4ltstr=F6m's?= message of "Sun, 24 Nov 2002 09:38:00 +0100") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.3.50 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-5.0 required=5.0 tests=EMAIL_ATTRIBUTION,FWD_MSG,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_GNUS_UA version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit This message seems important for IDN. Note that if option A win the vote, it seems that stringprep/nameprep will have to fork the Unicode standard to remain backwards compatible when stringprep/nameprep updates its Unicode reference. I have added the characters below to the stringprep test vectors document. Patrik Fältström writes: > As liason with the Unicode Consortium, I report the following. > > Regards, Patrik > > Begin forwarded message: > >> From: Rick McGowan >> Date: lör nov 23, 2002 21:12:10 Europe/Stockholm >> To: liaisons@unicode.org >> Subject: Unicode letter ballot >> >> To members of liaisons organizations: >> >> Clerical errors were found in canonical mappings for 5 Han >> compatibility chars in plane 2... There is a letter ballot being >> issued to >> Unicode members, attached below. >> >> For further information on possible actions resulting from this ballot, >> please see the following two pages: >> http://www.unicode.org/unicode/uni2errata/UnicodeErrata.html >> http://www.unicode.org/Public/UNIDATA/NormalizationCorrections.txt >> >> Regards, >> Rick McGowan >> Unicode, Inc. >> >> --------------------------------------- >>> >>> BALLOT to decide the correction for five canonical mapping errors >>> in the >>> Unicode Character Database. >>> >>> APPROVE Option A: __ >>> >>> OR >>> >>> APPROVE Option B: __ >>> >>> ___________________________________________ >>> >>> SUMMARY >>> >>> There are five clear errors have been discovered in the canonical >>> mappings >>> for Plane 2 CJK compatibility characters, verified independently by >>> multiple experts. Those errors are for U+2F868, U+2F874, U+2F91F, >>> U+2F95F, >>> and U+2F9BF. >>> >>> An additional five characters have been determined to have certain >>> visual >>> or clerical errors, but these will be handled through annotations >>> to the >>> names list. >>> >>> At UTC 93, the committee approved that a letter ballot be issued to >>> choose >>> the appropriate corrective action, either Option A or Option B: >>> >>> A) Fix the canonical mappings and issue another normalization >>> corrigendum >>> with corrected mappings in the Unicode 4.0 time frame, as follows: >>> >>> Make the following corrections in UnicodeData.txt for 4.0: >>> Correct canonical mapping for 2F868 from 2136A to 36FC. >>> Correct canonical mapping for 2F874 from 5F33 to 5F53. >>> Correct canonical mapping for 2F91F from 43AB to 243AB. >>> Correct canonical mapping for 2F95F from 7AAE to 7AEE. >>> Correct canonical mapping for 2F9BF from 4D57 to 45D7. >>> Add the following entries to NormalizationCorrections.txt: >>> 2F868;2136A;36FC;4.0.0 # Corrigendum 4 >>> 2F874;5F33;5F53;4.0.0 # Corrigendum 4 >>> 2F91F;43AB;243AB;4.0.0 # Corrigendum 4 >>> 2F95F;7AAE;7AEE;4.0.0 # Corrigendum 4 >>> 2F9BF;4D57;45D7;4.0.0 # Corrigendum 4 >>> >>> B) Add five new characters with the correct canonical mappings and >>> deprecate the existing characters with the incorrect mappings, as >>> follows: >>> >>> Deprecate 2F868, 2F874, 2F91F, 2F95F, 2F9BF. >>> Encode 5 new CJK compatibility characters as follows: >>> 2FA1E CJK COMPATIBILITY CHARACTER-2FA1E --> 36FC >>> 2FA1F CJK COMPATIBILITY CHARACTER-2FA1F --> 5F53 >>> 2FA20 CJK COMPATIBILITY CHARACTER-2FA20 --> 243AB >>> 2FA21 CJK COMPATIBILITY CHARACTER-2FA21 --> 7AEE >>> 2FA22 CJK COMPATIBILITY CHARACTER-2FA22 --> 45D7 >>> ___________________________________________ >>> >>> IMPLICATIONS OF THE TWO OPTIONS: >>> >>> Implications of Option A. >>> a. Can be accomplished in Unicode 4.0 timeframe. >>> b. Requires issuing technical corrigendum 4 for >>> Unicode and a technical corrigendum for 10646. >>> c. Impacts normalization stability. >>> d. Follows precedent of technical corrigendum 3. >>> >>> Implications of Option B. >>> a. Deprecates 5 characters and creates 5 duplicates >>> of them to map correctly. >>> b. May be problematical to complete in Unicode 4.0 >>> if not levered into current FPDAM for 10646. >>> c. Preserves normalization stability. >>> d. Sets new precedent for correction of CJK >>> compatibility mapping errors. >>> ___________________________________________ >> From owner-idn@ops.ietf.org Tue Nov 26 12:09:54 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11249 for ; Tue, 26 Nov 2002 12:09:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Gj4a-0009nD-00 for idn-data@psg.com; Tue, 26 Nov 2002 09:00:32 -0800 Received: from tux.w3.org ([18.29.0.27] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 18Gj4W-0009lZ-00 for idn@ops.ietf.org; Tue, 26 Nov 2002 09:00:28 -0800 Received: from enoshima (IDENT:root@tux.w3.org [18.29.0.27]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA23904 for ; Tue, 26 Nov 2002 12:00:25 -0500 Message-Id: <4.2.0.58.J.20021127015327.040089e0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 27 Nov 2002 02:00:01 +0900 To: idn@ops.ietf.org From: Martin Duerst Subject: [idn] IDNA: meaning of 'verify' In-Reply-To: References: <200211071321.VAA04362@msr.hinet.net> <200211071321.VAA04362@msr.hinet.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk The IDNA draft (http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-14.txt) contains the word 'verify' in several critical locations, for example: >>>> (a) Verify the absence of non-LDH ASCII code points; that is, the absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F. >>>> I haven't found any kind of 'definition' of 'verify'. My imagination says that 'verify' means: Check, and throw an error if the check isn't successful. Can anybody confirm? Is it possible to make this clear in the draft? Also, there is a typo in that the term 'UseSTD13ASCIIRules flag' is used once, where otherwise, it is 'UseSTD3ASCIIRules flag'. Regards, Martin. From owner-idn@ops.ietf.org Tue Nov 26 14:17:10 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16663 for ; Tue, 26 Nov 2002 14:17:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Gl29-000HPs-00 for idn-data@psg.com; Tue, 26 Nov 2002 11:06:09 -0800 Received: from tux.w3.org ([18.29.0.27] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 18Gl26-000HPa-00 for idn@ops.ietf.org; Tue, 26 Nov 2002 11:06:06 -0800 Received: from enoshima (IDENT:root@tux.w3.org [18.29.0.27]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA01354 for ; Tue, 26 Nov 2002 14:06:05 -0500 Message-Id: <4.2.0.58.J.20021127035248.03c13bf8@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 27 Nov 2002 03:56:26 +0900 To: idn@ops.ietf.org From: Martin Duerst Subject: [idn] Punicode: Upper-case in example In-Reply-To: <4.2.0.58.J.20021127015327.040089e0@localhost> References: <200211071321.VAA04362@msr.hinet.net> <200211071321.VAA04362@msr.hinet.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk In http://www.ietf.org/internet-drafts/draft-ietf-idn-punycode-03.txt, example (I) says: (I) Russian (Cyrillic): U+043F u+043E u+0447 u+0435 u+043C u+0443 u+0436 u+0435 u+043E u+043D u+0438 u+043D u+0435 u+0433 u+043E u+0432 u+043E u+0440 u+044F u+0442 u+043F u+043E u+0440 u+0443 u+0441 u+0441 u+043A u+0438 Punycode: b1abfaaepdrnnbgefbaDotcwatmq2g4l The presence of the upper-case 'D' (not to say the string 'Dot' :-) is confusing, because it seems completely arbitrary. There is no upper-case letter in the Cyrillic string. Is the result string actually correct? Has it been generated mechanically? How did the upper-case D get in there? Regards, Martin. From owner-idn@ops.ietf.org Tue Nov 26 17:24:51 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23613 for ; Tue, 26 Nov 2002 17:24:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Gnyl-0000bd-00 for idn-data@psg.com; Tue, 26 Nov 2002 14:14:51 -0800 Received: from arwen.cs.berkeley.edu ([128.32.132.165] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #2) id 18Gnyf-0000bQ-00 for idn@ops.ietf.org; Tue, 26 Nov 2002 14:14:45 -0800 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 18Gnye-0002GK-00 for ; Tue, 26 Nov 2002 14:14:44 -0800 Date: Tue, 26 Nov 2002 22:14:43 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] IDNA: meaning of 'verify' Message-ID: <20021126221443.GA8215@nicemice.net> Reply-To: IETF idn working group References: <200211071321.VAA04362@msr.hinet.net> <200211071321.VAA04362@msr.hinet.net> <4.2.0.58.J.20021127015327.040089e0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.2.0.58.J.20021127015327.040089e0@localhost> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Martin Duerst wrote: > there is a typo in that the term 'UseSTD13ASCIIRules flag' is used > once, where otherwise, it is 'UseSTD3ASCIIRules flag'. Good catch. I guess we'll fix this during the 48-hour author review (if the RFC editor hasn't already caught it and fixed it by then). > >>>> > (a) Verify the absence of non-LDH ASCII code points; that is, > the absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F. > >>>> > > I haven't found any kind of 'definition' of 'verify'. My imagination > says that 'verify' means: Check, and throw an error if the check > isn't successful. > > Can anybody confirm? It's not a technical term, it's just the plain English word "verify". "Verify the absence of foo" means look and make sure that there is no foo. If you look and see foo, then your attempt to verify the absence of foo has failed. > Is it possible to make this clear in the draft? I thought it was clear from this: It is important to note that the ToASCII operation can fail. ToASCII fails if any step of it fails. ToUnicode never fails. If any step fails, then the original input sequence is returned immediately in that step. Do you think this needs clarification? AMC From owner-idn@ops.ietf.org Tue Nov 26 17:56:54 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24701 for ; Tue, 26 Nov 2002 17:56:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GoX3-00028r-00 for idn-data@psg.com; Tue, 26 Nov 2002 14:50:17 -0800 Received: from arwen.cs.berkeley.edu ([128.32.132.165] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #2) id 18GoX0-00028U-00 for idn@ops.ietf.org; Tue, 26 Nov 2002 14:50:14 -0800 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 18GoWz-0002Le-00 for ; Tue, 26 Nov 2002 14:50:13 -0800 Date: Tue, 26 Nov 2002 22:50:13 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] Punicode: Upper-case in example Message-ID: <20021126225013.GB8215@nicemice.net> Reply-To: IETF idn working group References: <200211071321.VAA04362@msr.hinet.net> <200211071321.VAA04362@msr.hinet.net> <4.2.0.58.J.20021127035248.03c13bf8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.2.0.58.J.20021127035248.03c13bf8@localhost> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Martin Duerst wrote: > In http://www.ietf.org/internet-drafts/draft-ietf-idn-punycode-03.txt, > example (I) says: > > (I) Russian (Cyrillic): > U+043F u+043E u+0447 u+0435 u+043C u+0443 u+0436 u+0435 u+043E > u+043D u+0438 u+043D u+0435 u+0433 u+043E u+0432 u+043E u+0440 > u+044F u+0442 u+043F u+043E u+0440 u+0443 u+0441 u+0441 u+043A > u+0438 > Punycode: b1abfaaepdrnnbgefbaDotcwatmq2g4l > > The presence of the upper-case 'D' (not to say the string 'Dot' :-) > is confusing, because it seems completely arbitrary. There is no > upper-case letter in the Cyrillic string. > > Is the result string actually correct? Yes. Uppercase and lowercase letters are equivalent in Punycode. Section 5 says: 41..5A (A-Z) = 0 to 25, respectively 61..7A (a-z) = 0 to 25, respectively A decoder MUST recognize the letters in both uppercase and lowercase forms (including mixtures of both forms). > Has it been generated mechanically? Yes. The sample encoder (that appears in the Punycode spec) was fed the Russian text in u+ form (exactly as it appears in example I) and it produced the Punycode encoding (exactly as it appears in example I). If the Punycode string (exactly as it appears in example I) is fed to the sample decoder, it will produce the Russian text in u+ form (exactly as it appears in example I, except for line breaks). If you have an ANSI C compiler, you can reproduce these results yourself. If you have another Punycode implementation, it won't necessarily agree with the sample implementation on the case of the letters in the encoded string, but that's not significant. Any correct encoder will produce the same ASCII string (ignoring case), and any correct decoder will produce the same numeric code points. > How did the upper-case D get in there? It corresponds to the uppercase U in one of the code points in the u+ notation. The sample Punycode implementation uses the case of the u as a 1-bit annotation. The sample encoder uses these annotations to determine the case of the letters in the Punycode string, and the sample decoder recovers the annotations, using them to determine the case of the u's in the u+ notation. Section 5 says: An encoder SHOULD output only uppercase forms or only lowercase forms, unless it uses mixed-case annotation (see appendix B). Appendix B says: ...mixed-case annotation is not used by the ToASCII and ToUnicode operations specified in [IDNA], and therefore implementors of IDNA can disregard this appendix. These annotations do not alter the code points returned by decoders; the annotations are returned separately, for the caller to use or ignore. Encoders can accept annotations in addition to code points, but the annotations do not alter the output, except to influence the uppercase/lowercase form of ASCII letters. Punycode encoders and decoders need not support these annotations, and higher layers need not use them. AMC From owner-idn@ops.ietf.org Tue Nov 26 18:09:26 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25651 for ; Tue, 26 Nov 2002 18:09:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Gok7-0002eu-00 for idn-data@psg.com; Tue, 26 Nov 2002 15:03:47 -0800 Received: from tux.w3.org ([18.29.0.27] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 18Gok4-0002ei-00 for idn@ops.ietf.org; Tue, 26 Nov 2002 15:03:45 -0800 Received: from enoshima (IDENT:root@tux.w3.org [18.29.0.27]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA09307; Tue, 26 Nov 2002 18:03:43 -0500 Message-Id: <4.2.0.58.J.20021127072540.03d64640@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 27 Nov 2002 08:00:11 +0900 To: IETF idn working group , idn@ops.ietf.org From: Martin Duerst Subject: Re: [idn] IDNA: meaning of 'verify' In-Reply-To: <20021126221443.GA8215@nicemice.net> References: <4.2.0.58.J.20021127015327.040089e0@localhost> <200211071321.VAA04362@msr.hinet.net> <200211071321.VAA04362@msr.hinet.net> <4.2.0.58.J.20021127015327.040089e0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk At 22:14 02/11/26 +0000, Adam M. Costello wrote: >Martin Duerst wrote: > > I haven't found any kind of 'definition' of 'verify'. My imagination > > says that 'verify' means: Check, and throw an error if the check > > isn't successful. > > > > Can anybody confirm? > >It's not a technical term, it's just the plain English word "verify". >"Verify the absence of foo" means look and make sure that there is no >foo. If you look and see foo, then your attempt to verify the absence >of foo has failed. > > > Is it possible to make this clear in the draft? > >I thought it was clear from this: > > It is important to note that the ToASCII operation can fail. > ToASCII fails if any step of it fails. > > ToUnicode never fails. If any step fails, then the original input > sequence is returned immediately in that step. > >Do you think this needs clarification? Well, it would be very good if the words 'fail' and 'verify' could be linked, for example something along the lines of 'If a condition cannot be verified, then ToASCII fails.' Regards, Martin. From owner-idn@ops.ietf.org Wed Nov 27 09:00:52 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09762 for ; Wed, 27 Nov 2002 09:00:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18H2aG-0006jR-00 for idn-data@psg.com; Wed, 27 Nov 2002 05:50:32 -0800 Received: from nat.alvestrand.no ([217.13.28.204] helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 3.36 #2) id 18H2aE-0006jC-00 for idn@ops.ietf.org; Wed, 27 Nov 2002 05:50:30 -0800 Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2B568621FA; Wed, 27 Nov 2002 14:50:29 +0100 (CET) Date: Wed, 27 Nov 2002 14:50:29 +0100 From: Harald Tveit Alvestrand To: Simon Josefsson , idn@ops.ietf.org Subject: Re: [idn] Re: Fwd: Unicode letter ballot Message-ID: <54030000.1038405029@askvoll.hjemme.alvestrand.no> In-Reply-To: References: <0A56805A-FF88-11D6-A024-0003934B2128@cisco.com> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-2.2 required=5.0 tests=FWD_MSG,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02 version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On mandag, november 25, 2002 13:10:39 +0100 Simon Josefsson wrote: > This message seems important for IDN. > > Note that if option A win the vote, it seems that stringprep/nameprep > will have to fork the Unicode standard to remain backwards compatible > when stringprep/nameprep updates its Unicode reference. > sigh.... all 5 are beyond-BMP characters added recently. if we could go back in time, we could have implemented a policy of not accepting characters as stable before 2 unicode versions had gone by.... proofreading takes time. Harald From owner-idn@ops.ietf.org Wed Nov 27 15:58:55 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27693 for ; Wed, 27 Nov 2002 15:58:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18H93r-000LZu-00 for idn-data@psg.com; Wed, 27 Nov 2002 12:45:31 -0800 Received: from tux.w3.org ([18.29.0.27] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 18H93o-000LZa-00 for idn@ops.ietf.org; Wed, 27 Nov 2002 12:45:28 -0800 Received: from enoshima (IDENT:root@tux.w3.org [18.29.0.27]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA22002 for ; Wed, 27 Nov 2002 15:45:27 -0500 Message-Id: <4.2.0.58.J.20021127081348.03d59ca0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 28 Nov 2002 05:41:28 +0900 To: IETF idn working group From: Martin Duerst Subject: Re: [idn] Punicode: Upper-case in example In-Reply-To: <20021126225013.GB8215@nicemice.net> References: <4.2.0.58.J.20021127035248.03c13bf8@localhost> <200211071321.VAA04362@msr.hinet.net> <200211071321.VAA04362@msr.hinet.net> <4.2.0.58.J.20021127035248.03c13bf8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03 version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Hello Adam, Many thanks for your quick response. At 22:50 02/11/26 +0000, Adam M. Costello wrote: >Martin Duerst wrote: > > > In http://www.ietf.org/internet-drafts/draft-ietf-idn-punycode-03.txt, > > example (I) says: > > > > (I) Russian (Cyrillic): > > U+043F u+043E u+0447 u+0435 u+043C u+0443 u+0436 u+0435 u+043E > > u+043D u+0438 u+043D u+0435 u+0433 u+043E u+0432 u+043E u+0440 > > u+044F u+0442 u+043F u+043E u+0440 u+0443 u+0441 u+0441 u+043A > > u+0438 > > Punycode: b1abfaaepdrnnbgefbaDotcwatmq2g4l > > > > The presence of the upper-case 'D' (not to say the string 'Dot' :-) > > is confusing, because it seems completely arbitrary. There is no > > upper-case letter in the Cyrillic string. > > How did the upper-case D get in there? > >It corresponds to the uppercase U in one of the code points in the u+ >notation. The sample Punycode implementation uses the case of the u >as a 1-bit annotation. I see. I don't think this is a very good idea to use the U+ for distinction, for the following reasons: 1) The u+ -> lower case, U+ -> upper case is not documented anywhere in the punycode draft (or at least I didn't find it). If used at all, it should be documented straight at the start of the examples. 2) The above convention is very easy to overlook, in particular because u+ and U+ look so very similar. It is close to a widely established convention, but differs slightly. 3) Punycode can be used in different ways, on mixed strings, on lc strings that still contain the original casing info, and on pure lc strings. Maybe there should be separate examples for all these three uses. Regards, Martin. From owner-idn@ops.ietf.org Wed Nov 27 17:51:52 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01228 for ; Wed, 27 Nov 2002 17:51:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HAzK-0000An-00 for idn-data@psg.com; Wed, 27 Nov 2002 14:48:58 -0800 Received: from mailout06.sul.t-online.com ([194.25.134.19]) by psg.com with esmtp (Exim 3.36 #2) id 18HAzH-0000AW-00 for idn@ops.ietf.org; Wed, 27 Nov 2002 14:48:56 -0800 Received: from fwd07.sul.t-online.de by mailout06.sul.t-online.com with smtp id 18HAzF-0005J7-03; Wed, 27 Nov 2002 23:48:53 +0100 Received: from mira.informatik.hu-berlin.de (03047300346-0001@[217.232.53.43]) by fmrl07.sul.t-online.com with esmtp id 18HAzE-1VPP2OC; Wed, 27 Nov 2002 23:48:52 +0100 Received: from mira.informatik.hu-berlin.de (localhost [127.0.0.1]) by mira.informatik.hu-berlin.de (8.12.6/8.11.6/SuSE Linux 0.5) with ESMTP id gARMmr7J003605 for ; Wed, 27 Nov 2002 23:48:53 +0100 Received: (from martin@localhost) by mira.informatik.hu-berlin.de (8.12.6/8.12.6/Submit) id gARMmqt4003602; Wed, 27 Nov 2002 23:48:52 +0100 X-Authentication-Warning: mira.informatik.hu-berlin.de: martin set sender to martin@v.loewis.de using -f To: IETF idn working group Subject: Re: [idn] Punicode: Upper-case in example References: <4.2.0.58.J.20021127035248.03c13bf8@localhost> <200211071321.VAA04362@msr.hinet.net> <200211071321.VAA04362@msr.hinet.net> <4.2.0.58.J.20021127035248.03c13bf8@localhost> <4.2.0.58.J.20021127081348.03d59ca0@localhost> From: martin@v.loewis.de (Martin v. Loewis) Date: 27 Nov 2002 23:48:51 +0100 In-Reply-To: <4.2.0.58.J.20021127081348.03d59ca0@localhost> Message-ID: Lines: 33 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 03047300346-0001@t-dialin.net X-Spam-Status: No, hits=-4.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_GNUS_UA, X_AUTH_WARNING version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Martin Duerst writes: > I see. I don't think this is a very good idea to use the U+ for > distinction, for the following reasons: > > 1) The u+ -> lower case, U+ -> upper case is not documented anywhere > in the punycode draft (or at least I didn't find it). If used at > all, it should be documented straight at the start of the examples. This is no issue, since the case is not normative. To produce test vectors, I find it reasonable to include mixed case, so that implementors may find problems in their implementations when confronted with mixed case. > 2) The above convention is very easy to overlook, in particular > because u+ and U+ look so very similar. It is close to a widely > established convention, but differs slightly. So what? Again, we are talking about test vectors here. The casing of the output is not normative - let alone the syntax of the input; usually, input won't be ASCII in the u+ notation anyway. > 3) Punycode can be used in different ways, on mixed strings, on > lc strings that still contain the original casing info, and > on pure lc strings. Maybe there should be separate examples > for all these three uses. While this may be true for Punycode, that is not true for IDNA. In IDNA, nameprep will lower-case the input before applying Punycode. Regards, Martin From owner-idn@ops.ietf.org Wed Nov 27 18:27:44 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02342 for ; Wed, 27 Nov 2002 18:27:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HBWL-0001Re-00 for idn-data@psg.com; Wed, 27 Nov 2002 15:23:05 -0800 Received: from arwen.cs.berkeley.edu ([128.32.132.165] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #2) id 18HBWI-0001RS-00 for idn@ops.ietf.org; Wed, 27 Nov 2002 15:23:02 -0800 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 18HBWH-0005Pl-00 for ; Wed, 27 Nov 2002 15:23:01 -0800 Date: Wed, 27 Nov 2002 23:23:01 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] Punicode: Upper-case in example Message-ID: <20021127232300.GC19768@nicemice.net> Reply-To: IETF idn working group References: <4.2.0.58.J.20021127035248.03c13bf8@localhost> <200211071321.VAA04362@msr.hinet.net> <200211071321.VAA04362@msr.hinet.net> <4.2.0.58.J.20021127035248.03c13bf8@localhost> <4.2.0.58.J.20021127081348.03d59ca0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.2.0.58.J.20021127081348.03d59ca0@localhost> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Martin Duerst wrote: > > The sample Punycode implementation uses the case of the u as a 1-bit > > annotation. > > I see. I don't think this is a very good idea to use the U+ for > distinction, for the following reasons: > > 1) The u+ -> lower case, U+ -> upper case is not documented anywhere > in the punycode draft (or at least I didn't find it). If used at > all, it should be documented straight at the start of the examples. It is not documented in the spec because it is not a feature of Punycode. The Punycode algorithm inputs and outputs code points, which are numbers. It does not input or output "u+". The sample implementation inputs and outputs "u+". Therefore the use of the u as a 1-bit annotation is mentioned in the documentation of the sample implementation, which is embedded in the source code (you can either read the source code of the usage() function, or run the program with no arguments). I tried to downplay mixed-case annotation as much as possible in the draft, because Paul and Patrik have never liked it. I'll ask them if they think the Examples section should call attention to the mixed-case annotations. > 2) The above convention is very easy to overlook, in particular > because u+ and U+ look so very similar. It is close to a widely > established convention, but differs slightly. I'm curious--can you explain or point me to that convention? > 3) Punycode can be used in different ways, on mixed strings, on lc > strings that still contain the original casing info, and on pure > lc strings. Maybe there should be separate examples for all these > three uses. Long ago some of my drafts included explanations of various scenarios, some of which are not applicable to domain names. Since then, we agreed that the Punycode draft should present itself as a piece of IDNA which, by the way, could perhaps be useful outside IDNA; not as as a general encoding that happens to be used in IDNA. The goal was to avoid confusing implementors of IDNA. So I cut out all but the essentials of mixed-case annotation, and confined its description to a single appendix (and the sample implementation). Maybe, if/when there is real interest in using mixed-case annotations and/or using Punycode for things other than domain names, we could update the spec, or augment it with a separate document. AMC From owner-idn@ops.ietf.org Wed Nov 27 19:36:07 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03905 for ; Wed, 27 Nov 2002 19:36:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HCQ3-0003gH-00 for idn-data@psg.com; Wed, 27 Nov 2002 16:20:39 -0800 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #2) id 18HCQ1-0003g5-00 for idn@ops.ietf.org; Wed, 27 Nov 2002 16:20:37 -0800 Received: from latte (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.6/8.12.6) with ESMTP id gAS0KX5h032733 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 28 Nov 2002 01:20:34 +0100 To: Harald Tveit Alvestrand Cc: idn@ops.ietf.org Subject: [idn] Re: Fwd: Unicode letter ballot References: <0A56805A-FF88-11D6-A024-0003934B2128@cisco.com> <54030000.1038405029@askvoll.hjemme.alvestrand.no> X-Hashcash: 0:021128:harald@alvestrand.no:2deab6e7fe11572e X-Hashcash: 0:021128:idn@ops.ietf.org:5565be573ab0a893 From: Simon Josefsson Date: Thu, 28 Nov 2002 01:20:33 +0100 In-Reply-To: <54030000.1038405029@askvoll.hjemme.alvestrand.no> (Harald Tveit Alvestrand's message of "Wed, 27 Nov 2002 14:50:29 +0100") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-5.3 required=5.0 tests=EMAIL_ATTRIBUTION,FWD_MSG,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_GNUS_UA version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Harald Tveit Alvestrand writes: > --On mandag, november 25, 2002 13:10:39 +0100 Simon Josefsson > wrote: > >> This message seems important for IDN. >> >> Note that if option A win the vote, it seems that stringprep/nameprep >> will have to fork the Unicode standard to remain backwards compatible >> when stringprep/nameprep updates its Unicode reference. >> > > sigh.... all 5 are beyond-BMP characters added recently. > if we could go back in time, we could have implemented a policy of not > accepting characters as stable before 2 unicode versions had gone > by.... > > proofreading takes time. Even two Unicode releases doesn't guarantee that the tables are correct. The only proper solution I can see is to stop modifying published decomposition tables. When mistakes are discovered, new character codes with proper decompositions should be added and the old character codes declared obsolete -- which is option B in the vote, but unfortunately neither IDN nor IETF has any voting powers (which suggest a methodological problem). From owner-idn@ops.ietf.org Wed Nov 27 20:17:18 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04548 for ; Wed, 27 Nov 2002 20:17:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HD73-0005bu-00 for idn-data@psg.com; Wed, 27 Nov 2002 17:05:05 -0800 Received: from inergen.sybase.com ([192.138.151.43]) by psg.com with esmtp (Exim 3.36 #2) id 18HD6y-0005XZ-00 for idn@ops.ietf.org; Wed, 27 Nov 2002 17:05:00 -0800 Received: from smtp1.sybase.com (sybgate [10.22.97.84]) by inergen.sybase.com with ESMTP id RAA25136 for ; Wed, 27 Nov 2002 17:04:30 -0800 (PST) Received: from smtp1.sybase.com (localhost [127.0.0.1]) by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000/11/20) with ESMTP id RAA05704 for ; Wed, 27 Nov 2002 17:04:29 -0800 (PST) Received: from olympus-dublin.sybase.com (olympus-dublin.sybase.com [10.22.97.100]) by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000-11-20) with ESMTP id RAA05696; Wed, 27 Nov 2002 17:04:28 -0800 (PST) Received: from birdie.sybase.com (birdie.sybase.com [10.22.85.43]) by olympus-dublin.sybase.com (8.11.6+Sun/8.10.2) with ESMTP id gAS14Se19286; Wed, 27 Nov 2002 17:04:28 -0800 (PST) Received: from birdie (birdie [10.22.85.43]) by birdie.sybase.com (8.8.8+Sun/8.8.8) with SMTP id RAA03897; Wed, 27 Nov 2002 17:04:27 -0800 (PST) Message-Id: <200211280104.RAA03897@birdie.sybase.com> Date: Wed, 27 Nov 2002 17:04:27 -0800 (PST) From: Kenneth Whistler Reply-To: Kenneth Whistler Subject: [idn] Re: Fwd: Unicode letter ballot To: jas@extundo.com Cc: idn@ops.ietf.org, kenw@sybase.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Qxsnuhnk1UGnp9HMCEK2DA== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc X-Spam-Status: No, hits=-0.9 required=5.0 tests=FWD_MSG,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Simon Josefsson said: > > sigh.... all 5 are beyond-BMP characters added recently. > > if we could go back in time, we could have implemented a policy of not > > accepting characters as stable before 2 unicode versions had gone > > by.... > > > > proofreading takes time. > > Even two Unicode releases doesn't guarantee that the tables are > correct. Of course. But in this case, because of the sensitivity of this problem, 5 independent audits of the Plane 2 CJK compatibility characters by CJK experts have converged on the same answer. There are 5 mistakes (4 clerical and one visual) in the current mappings for that set of recently added 542 supplementary characters on Plane 2. [There are also other known issues in the mappings, whereby one Han variant or another might be a "better" mapping, but there is also consensus among the experts that none of those issues rise to the level of blatant *mistakes* that must be corrected in the current tables -- which is why none of those is being ballotted or will be in the future.] The U.S. national body and the UTC are both also pushing back hard on the proposed addition of another 122 CJK compatibility characters because the CJK mapping experts have discovered errors in *that* table as well. In this case, having learned our lesson, the UTC is trying to be proactive and ensure that all errors are removed from the table *before* such an addition is standardized. > The only proper solution I can see is to stop modifying > published decomposition tables. When mistakes are discovered, new > character codes with proper decompositions should be added and the old > character codes declared obsolete -- which is option B in the vote, This will lead to other interoperability problems. The 542 supplementary characters in question (and all of the ones involving the errors) are CNS compatibility characters. They are there to provide round-trip mappings to the CNS 11643 standard. If you "obsolete" 5 code points and then add 5 new ones, then it is inevitable that CNS mapping tables will get updated to use the new code points instead of the old ones (and there will be some inconsistency in the mappings, because of the duplications, during this transition) -- because the old code points get normalized away to nonsense characters. This will undoubtedly lead to further problems, including for IDNA string matching, as one of the duplicated pair normalizes one way, and the other -- apparently identical -- normalizes another way. And you can't escape the problem by just adding the 5 obsolete code points to the stringprep prohibited list, because that, *too*, would have destabilized your specification: a string that was valid before you did that would be invalid after you did so. > but unfortunately neither IDN nor IETF has any voting powers (which > suggest a methodological problem). Why would IDN have voting powers here? You don't expect the UTC or SC2/WG2 to have voting powers in an IDN working group, do you? As for the IETF, the UTC and the IETF have a *liaison* relationship. The UTC immediately informed the IETF liaison about this ballot, because it knew this was an important issue that IETF participants are concerned about. That is why this discussion has migrated over to interested parties on the IDN list who have worked on IDNA and stringprep. But the buck has to stop somewhere. Ultimately the UTC and WG2 are responsible for the CJK compatibility character mapping tables. So those committees have to take the relevant votes, and if they end up standardizing errors, also have to take the relevant knocks when they go to fix the errors. To influence the actual *voting* on this (or other issues), one works through the UTC voting member representatives in the UTC case, or one works through the national bodies participating in SC2 in the SC2/WG2 case. --Ken From owner-idn@ops.ietf.org Wed Nov 27 20:34:37 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04817 for ; Wed, 27 Nov 2002 20:34:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HDSl-0006Vc-00 for idn-data@psg.com; Wed, 27 Nov 2002 17:27:31 -0800 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 18HDSj-0006VN-00 for idn@ops.ietf.org; Wed, 27 Nov 2002 17:27:29 -0800 Received: (from root@localhost) by postel3.postel.co.kr (8.11.0/8.11.0) id gAS1QnZ30614; Thu, 28 Nov 2002 10:26:49 +0900 Date: Thu, 28 Nov 2002 10:26:49 +0900 From: Soobok Lee To: Simon Josefsson Cc: Harald Tveit Alvestrand , idn@ops.ietf.org Subject: Re: [idn] Re: Fwd: Unicode letter ballot Message-ID: <20021128012649.GD20877@postel.co.kr> References: <0A56805A-FF88-11D6-A024-0003934B2128@cisco.com> <54030000.1038405029@askvoll.hjemme.alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-1.6 required=5.0 tests=FWD_MSG,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, REFERENCES,SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk On Thu, Nov 28, 2002 at 01:20:33AM +0100, Simon Josefsson wrote: > Harald Tveit Alvestrand writes: > > > --On mandag, november 25, 2002 13:10:39 +0100 Simon Josefsson > > wrote: > > > >> This message seems important for IDN. > >> > >> Note that if option A win the vote, it seems that stringprep/nameprep > >> will have to fork the Unicode standard to remain backwards compatible > >> when stringprep/nameprep updates its Unicode reference. > >> > > > > sigh.... all 5 are beyond-BMP characters added recently. > > if we could go back in time, we could have implemented a policy of not > > accepting characters as stable before 2 unicode versions had gone > > by.... > > > > proofreading takes time. > > Even two Unicode releases doesn't guarantee that the tables are > correct. The only proper solution I can see is to stop modifying > published decomposition tables. When mistakes are discovered, new > character codes with proper decompositions should be added and the old > character codes declared obsolete -- which is option B in the vote, > but unfortunately neither IDN nor IETF has any voting powers (which > suggest a methodological problem). > If option B wins, a few issues may be raised easily: 1) added characters does not preserve the original/ideal lexicographic radical-based order of those CJK glyphs. 2) How does any obsoletion of characters work ? compatiblity CJK characters are NFC-ed into other CJK characters in stringprep and so required obsoletion(mapping to newly added ones) should be done _before_ the stringprep operation is taken. If option A wins, I see a chaos: 1) NFKC_3.2_nameprep(NFKC_4.0_calling_application(IDN)) != NFKC_3.2_nameprep(IDN) What if future HTML/canonical XML standards adopt NFKC_4.0 ? Soobok Lee From owner-idn@ops.ietf.org Wed Nov 27 20:57:51 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05460 for ; Wed, 27 Nov 2002 20:57:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HDre-0007c8-00 for idn-data@psg.com; Wed, 27 Nov 2002 17:53:14 -0800 Received: from inergen.sybase.com ([192.138.151.43]) by psg.com with esmtp (Exim 3.36 #2) id 18HDrc-0007ZZ-00 for idn@ops.ietf.org; Wed, 27 Nov 2002 17:53:12 -0800 Received: from smtp1.sybase.com (sybgate [10.22.97.84]) by inergen.sybase.com with ESMTP id RAA01979 for ; Wed, 27 Nov 2002 17:52:42 -0800 (PST) Received: from smtp1.sybase.com (localhost [127.0.0.1]) by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000/11/20) with ESMTP id RAA14260 for ; Wed, 27 Nov 2002 17:52:41 -0800 (PST) Received: from olympus-dublin.sybase.com (olympus-dublin.sybase.com [10.22.97.100]) by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000-11-20) with ESMTP id RAA14252; Wed, 27 Nov 2002 17:52:40 -0800 (PST) Received: from birdie.sybase.com (birdie.sybase.com [10.22.85.43]) by olympus-dublin.sybase.com (8.11.6+Sun/8.10.2) with ESMTP id gAS1qde22463; Wed, 27 Nov 2002 17:52:39 -0800 (PST) Received: from birdie (birdie [10.22.85.43]) by birdie.sybase.com (8.8.8+Sun/8.8.8) with SMTP id RAA03951; Wed, 27 Nov 2002 17:52:38 -0800 (PST) Message-Id: <200211280152.RAA03951@birdie.sybase.com> Date: Wed, 27 Nov 2002 17:52:38 -0800 (PST) From: Kenneth Whistler Reply-To: Kenneth Whistler Subject: Re: [idn] Re: Fwd: Unicode letter ballot To: lsb@postel.co.kr Cc: idn@ops.ietf.org, kenw@sybase.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: aDx1NjNCCD23oQDZzb99+A== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc X-Spam-Status: No, hits=-0.6 required=5.0 tests=FWD_MSG,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Soobok Lee said: > If option A wins, I see a chaos: > 1) NFKC_3.2_nameprep(NFKC_4.0_calling_application(IDN)) > != NFKC_3.2_nameprep(IDN) It isn't as if you don't already have this problem in spades: NFKC_3.2_nameprep(AnyRandomNormalization_calling_application(IDN)) != NFKC_3.2_nameprep(IDN) You can't force the entire rest of the world to normalize their data the same way you do for some set of protocols, simply because other applications have other requirements for normalization of Unicode data. One way to control the *particular* problem of the CJK compatibility character mappings pose in normalization is for China's and Taiwan's domain registries to simply disallow use of these characters in domain names. (Either just for the problematical few where there are mapping errors, or for all of them -- which would be my preference.) After all, these compatibility characters -- particularly the CNS, GB and KSX ones, are duplicates for round-trip mapping purposes, but aren't really required for the level of distinctions useful for defining domain names (or host names, or any similar named entities that IETF is concerned about). > What if future HTML/canonical XML standards adopt NFKC_4.0 ? It won't be NFKC in any case. It will be NFC, which is different, anyway. (But which still has the problem of the erroneous mappings for CJK compatibility characters.) --Ken From owner-idn@ops.ietf.org Wed Nov 27 21:17:52 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05726 for ; Wed, 27 Nov 2002 21:17:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HECW-0008bB-00 for idn-data@psg.com; Wed, 27 Nov 2002 18:14:48 -0800 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 18HECS-0008aX-00 for idn@ops.ietf.org; Wed, 27 Nov 2002 18:14:45 -0800 Received: (from root@localhost) by postel3.postel.co.kr (8.11.0/8.11.0) id gAS2EaC31369; Thu, 28 Nov 2002 11:14:36 +0900 Date: Thu, 28 Nov 2002 11:14:36 +0900 From: Soobok Lee To: Kenneth Whistler Cc: idn@ops.ietf.org Subject: Re: [idn] Re: Fwd: Unicode letter ballot Message-ID: <20021128021436.GE20877@postel.co.kr> References: <200211280152.RAA03951@birdie.sybase.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211280152.RAA03951@birdie.sybase.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-1.3 required=5.0 tests=FWD_MSG,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk On Wed, Nov 27, 2002 at 05:52:38PM -0800, Kenneth Whistler wrote: > Soobok Lee said: > > > If option A wins, I see a chaos: > > 1) NFKC_3.2_nameprep(NFKC_4.0_calling_application(IDN)) > > != NFKC_3.2_nameprep(IDN) > > It isn't as if you don't already have this problem in spades: > > NFKC_3.2_nameprep(AnyRandomNormalization_calling_application(IDN)) > != NFKC_3.2_nameprep(IDN) > > You can't force the entire rest of the world to normalize their > data the same way you do for some set of protocols, simply because > other applications have other requirements for normalization > of Unicode data. Yes. Those conflicts of different normaliations were already discussed here and they will remains as inherent and unsolvable problems in i18n identifiers works. So, the above problem is nothing new in this WG. > > One way to control the *particular* problem of the CJK compatibility > character mappings pose in normalization is for China's and > Taiwan's domain registries to simply disallow use of these > characters in domain names. (Either just for the problematical > few where there are mapping errors, or for all of them -- which > would be my preference.) After all, these compatibility characters -- > particularly the CNS, GB and KSX ones, are duplicates for round-trip > mapping purposes, but aren't really required for the level > of distinctions useful for defining domain names (or host names, > or any similar named entities that IETF is concerned about). Right. That means any CJK IDN admin guideline efforts should deal with un-nameprepped CJK inputs in addition to nameprepped ones, in order to fine tune their CJK equivalence tables based on regional languages. that is , they should embrace those 5 wrong canonical CJK equivalences and all their transitional ones as if they were legitimate ones. But, even in those cases, local CJK identifier comparisons without DNS queries will fail to match regardless of those CJK domains are owned by a single registrant. of course, this issue is also nothing new in this WG. And, Chinese or Korean IME(input method editor) injects those compatibility characters into protocols and end users often does not know whther their input characters are compatibility CJKs or not. They look exactly identical to their canonical equivalent CJKs. > > > What if future HTML/canonical XML standards adopt NFKC_4.0 ? > > It won't be NFKC in any case. It will be NFC, which is different, Right. It is NFC which is adopted , not NFKC. Thanks. > anyway. (But which still has the problem of the erroneous > mappings for CJK compatibility characters.) > > --Ken From owner-idn@ops.ietf.org Wed Nov 27 21:47:18 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06561 for ; Wed, 27 Nov 2002 21:47:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HEe2-0009lH-00 for idn-data@psg.com; Wed, 27 Nov 2002 18:43:14 -0800 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #2) id 18HEdz-0009l4-00 for idn@ops.ietf.org; Wed, 27 Nov 2002 18:43:11 -0800 Received: from latte (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.6/8.12.6) with ESMTP id gAS2h75h001706 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 28 Nov 2002 03:43:08 +0100 To: Kenneth Whistler Cc: idn@ops.ietf.org Subject: [idn] Re: Fwd: Unicode letter ballot References: <200211280104.RAA03897@birdie.sybase.com> X-Hashcash: 0:021128:kenw@sybase.com:46a94d10e91dff01 X-Hashcash: 0:021128:idn@ops.ietf.org:089553c38dd1d630 From: Simon Josefsson Date: Thu, 28 Nov 2002 03:43:07 +0100 In-Reply-To: <200211280104.RAA03897@birdie.sybase.com> (Kenneth Whistler's message of "Wed, 27 Nov 2002 17:04:27 -0800 (PST)") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-5.0 required=5.0 tests=EMAIL_ATTRIBUTION,FWD_MSG,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_GNUS_UA version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Kenneth Whistler writes: >> The only proper solution I can see is to stop modifying >> published decomposition tables. When mistakes are discovered, new >> character codes with proper decompositions should be added and the old >> character codes declared obsolete -- which is option B in the vote, > > This will lead to other interoperability problems. The 542 > supplementary characters in question (and all of the ones involving > the errors) are CNS compatibility characters. They are there to > provide round-trip mappings to the CNS 11643 standard. If you > "obsolete" 5 code points and then add 5 new ones, then it is > inevitable that CNS mapping tables will get updated to use the > new code points instead of the old ones (and there will be some > inconsistency in the mappings, because of the duplications, during > this transition) -- because the old code points get normalized > away to nonsense characters. Assuming CNS 11643 discusses decomposition, you will have this problem with either option A or B anyway. Naïvely the conclusion then is that the entire 542 character block was in error, and should be replaced by a new 542 character block that provide the correct round-trip mapping with CNS 11643. > This will undoubtedly lead to further problems, including for IDNA > string matching, as one of the duplicated pair normalizes one way, > and the other -- apparently identical -- normalizes another way. And > you can't escape the problem by just adding the 5 obsolete code > points to the stringprep prohibited list, because that, *too*, would > have destabilized your specification: a string that was valid before > you did that would be invalid after you did so. It is not the stability I'm worried about here, but security issues. I'm not convinced the approach you propose here have the same security problems as having one Unicode string translate into different bit strings dependening on which Unicode version stringprep uses. In fact, I believe your proposed solution guarantees security at the expense of breaking backwards compatibility, which sounds like good engineering to me. >> but unfortunately neither IDN nor IETF has any voting powers (which >> suggest a methodological problem). > > Why would IDN have voting powers here? You don't expect the > UTC or SC2/WG2 to have voting powers in an IDN working group, do you? > > As for the IETF, the UTC and the IETF have a *liaison* relationship. > The UTC immediately informed the IETF liaison about this ballot, because it > knew this was an important issue that IETF participants are > concerned about. That is why this discussion has migrated over > to interested parties on the IDN list who have worked on IDNA > and stringprep. > > But the buck has to stop somewhere. Ultimately the UTC and WG2 > are responsible for the CJK compatibility character mapping > tables. So those committees have to take the relevant votes, > and if they end up standardizing errors, also have to take > the relevant knocks when they go to fix the errors. > > To influence the actual *voting* on this (or other issues), > one works through the UTC voting member representatives in > the UTC case, or one works through the national bodies > participating in SC2 in the SC2/WG2 case. My point was that if IDN wanted to influence the character set, and decomposition tables in particular, it should not have referenced UTC standards; it was a remark targetted against IDN, not UTC. But that is an entirely different discussion. UTC and SC2/WG2 do have the same voting powers as all other IDN WG participants have, btw. From owner-idn@ops.ietf.org Wed Nov 27 22:18:00 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07102 for ; Wed, 27 Nov 2002 22:18:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HF61-000AvY-00 for idn-data@psg.com; Wed, 27 Nov 2002 19:12:09 -0800 Received: from arwen.cs.berkeley.edu ([128.32.132.165] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #2) id 18HF5x-000AvC-00 for idn@ops.ietf.org; Wed, 27 Nov 2002 19:12:05 -0800 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 18HF5w-0005xt-00 for ; Wed, 27 Nov 2002 19:12:04 -0800 Date: Thu, 28 Nov 2002 03:12:04 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] Re: Fwd: Unicode letter ballot Message-ID: <20021128031204.GA21675@nicemice.net> Reply-To: IETF idn working group References: <200211280104.RAA03897@birdie.sybase.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211280104.RAA03897@birdie.sybase.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-5.2 required=5.0 tests=EMAIL_ATTRIBUTION,FWD_MSG,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Kenneth Whistler wrote: > And you can't escape the problem by just adding the 5 obsolete code > points to the stringprep prohibited list, True, but... > because that, *too*, would have destabilized your specification: a > string that was valid before you did that would be invalid after you > did so. Actually, adding compatibility characters to the Stringprep prohibited list would have absolutely no effect, because Stringprep performs normalization before prohibition. Let's consider the possible scenarios: 1. The decomposition mappings are changed. 1a. Stringprep/Nameprep track the update, breaking their promise of backward compatibility. If someone registers a name using a CNS 11643 string in combination with the old Nameprep, and later someone tries to look up the name using the very same CNS 11643 string in combination with the new Nameprep, it won't match (if it contains any of the five characters in question). As more clients upgrade to the new Nameprep, the name will become less and less accessible. But the old-Nameprepped form of the name (the one that actually got stored in the database) will look visibly wrong, won't it? If the registrant had been shown the Nameprepped form and asked for confirmation, the registration would probably have been aborted. So maybe this lookup failure would turn out to never happen in practice. On the other hand, if someone registers a name using a CNS 11643 string in combination with the new Nameprep, and later someone tries to look up the name using the very same CNS 11643 string in combination with the old Nameprep, it won't match. But this time the Nameprepped form shown to the registrant will look correct, so names causing this failure might be more likely to be registered than names causing the previous failure. For this failure, as more clients get upgraded, the name will become more and more accessible. 1b. Stringprep/Nameprep do not track Unicode updates; they remain frozen at a version containing the old mappings. If someone registers a name using a CNS 11643 string, and later someone tries to look up the name using the very same CNS 11643 string, it will match. But if a modern normalization operation gets inserted somewhere (for the heck of it, or because some other protocol that carries the domain name requires text to be normalized), it won't match. Names using the broken compatibility characters might not be registered in practice, because the Nameprepped form will look wrong. Since Nameprep never changes again, there is no transition as software gets upgraded. Names involving the five characters in question remain just as broken and undesirable in the far future as in the near future. It is likely that these five characters would never be used in domain names in practice, forever. 1c. Stringprep/Nameprep track Unicode updates, but require the use of NormalizationCorrections.txt to undo any changes to decompositions since Unicode 3.2. This is exactly like case 1b except that IDNA can take advantage of other updates to Unicode, like new characters. As software gets upgraded, the mappings of the five characters in question remain the same (broken), so it is likely that these five characters would never be used in domain names in practice, forever, same as case 1b. 2. The decomposition mappings are not changed; the characters are deprecated, and new characters added with the correct decompositions. 2a. Stringprep/Nameprep eventually allow the use of a version of Unicode that that includes the added characters. If someone registers a name using a CNS 11643 string in combination with the old CNS-to-Unicode tables, and later someone tries to look up the name using the very same CNS 11643 string in combination with the new CNS-to-Unicode tables, it won't match. As more clients upgrade to the new CNS-to-Unicode tables, the name will become less and less accessible. If the registrant is shown the Nameprepped form of the name, it will look visibly wrong, so the name will probably not end up getting registered, so this lookup failure might never happen in practice. If someone registers a name using a CNS 11643 string in combination with the new CNS-to-Unicode tables, and later someone tries to look up the name using the very same CNS 11643 string in combination with the old CNS-to-Unicode tables, it won't match, but this time the Nameprepped form shown to the registrant will look correct, so names causing this failure might be more likely to be registered than names causing the previous failure. For this failure, as more clients get upgraded, the name will become more and more accessible. 2b. Stringprep/Nameprep freeze on a version of Unicode that does not include the added characters, never to be updated again. If someone registers a name using a CNS 11643 string in combination with the old CNS-to-Unicode tables, and later someone tries to look up the name using the very same CNS 11643 string in combination with the new CNS-to-Unicode tables, it won't match. As more clients upgrade to the new CNS-to-Unicode tables, the name will become less and less accessible. If the registrant is shown the Nameprepped form of the name, it will look visibly wrong, so the name will probably not end up getting registered, so this lookup failure might never happen in practice. If someone tries to register a name using a CNS 11643 string in combination with the new CNS-to-Unicode tables, it will fail, because the new CNS-to-Unicode tables will use the new characters, which are unassigned in the version of Unicode used by Nameprep, and therefore disallowed in stored strings. It is likely that these five characters would never be used in domain names in practice, forever. It's interesting that cases 1a and 2a are basically identical, and cases 1b and 2b are extremely similar, although they correspond to opposite outcomes of the vote. The biggest difference I can see between case 1 and case 2 is that if the deprecate/add approach is taken (case 2), IDNA's only choices are to track Unicode updates (2a) or not track them (2b), all or nothing. But if the fix-decompositions approach is taken (case 1), IDNA has a third option (1c) of tracking all Unicode updates except changes to decompositions, via the NormalizationCorrections.txt file. I find this result to be counter-intuitive. My initial gut feeling was that the deprecate/add approach was more conservative, and safer. But apparently not. AMC From owner-idn@ops.ietf.org Wed Nov 27 23:13:00 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08379 for ; Wed, 27 Nov 2002 23:13:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HFsE-000D4j-00 for idn-data@psg.com; Wed, 27 Nov 2002 20:01:58 -0800 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 18HFsB-000D4X-00 for idn@ops.ietf.org; Wed, 27 Nov 2002 20:01:56 -0800 Received: (from root@localhost) by postel3.postel.co.kr (8.11.0/8.11.0) id gAS41mH00787; Thu, 28 Nov 2002 13:01:48 +0900 Date: Thu, 28 Nov 2002 13:01:48 +0900 From: Soobok Lee To: IETF idn working group Subject: Re: [idn] Re: Fwd: Unicode letter ballot Message-ID: <20021128040148.GG20877@postel.co.kr> References: <200211280104.RAA03897@birdie.sybase.com> <20021128031204.GA21675@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021128031204.GA21675@nicemice.net> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-1.3 required=5.0 tests=FWD_MSG,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk On Thu, Nov 28, 2002 at 03:12:04AM +0000, Adam M. Costello wrote: > 1. The decomposition mappings are changed. > > 1b. Stringprep/Nameprep do not track Unicode updates; they remain > frozen at a version containing the old mappings. > > If someone registers a name using a CNS 11643 string, and later > someone tries to look up the name using the very same CNS 11643 > string, it will match. But if a modern normalization operation > gets inserted somewhere (for the heck of it, or because some > other protocol that carries the domain name requires text to be > normalized), it won't match. > > Names using the broken compatibility characters might not be > registered in practice, because the Nameprepped form will look > wrong. Maybe. But, i think this is still over-simplified. I will add more sub-cases: The compatiblity form has three equivalent forms. 0) the compatiblity form itself 1) the (falsely) nameprepped form from Unicode 3.2 false-NFC 2) the desired-and-correct-but-abandoned equivalent form from correct-NFC Now, 0) can't be registered as itself in any case, because it is always mapped to something other. 1) may be abandoned as you described above because it renders differently than expected when registration time. 1) may be, however, registered as un-nameprepped form itself by other applicants who may occasionally have this 1) name as their biz name. 2) may be registered as un-nameprepped form itself by other applicants who may occasionally have this 2) name as their biz name. Adam, Could you continue to take your thorough analysis on these sub-cases? Soobok Lee > > Since Nameprep never changes again, there is no transition as > software gets upgraded. Names involving the five characters in > question remain just as broken and undesirable in the far future > as in the near future. It is likely that these five characters > would never be used in domain names in practice, forever. From owner-idn@ops.ietf.org Thu Nov 28 00:00:24 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09121 for ; Thu, 28 Nov 2002 00:00:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HGfs-000Euw-00 for idn-data@psg.com; Wed, 27 Nov 2002 20:53:16 -0800 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #2) id 18HGfo-000Euj-00 for idn@ops.ietf.org; Wed, 27 Nov 2002 20:53:13 -0800 Received: from latte (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.6/8.12.6) with ESMTP id gAS4r85h003285 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 28 Nov 2002 05:53:09 +0100 To: IETF idn working group Subject: [idn] Re: Fwd: Unicode letter ballot References: <200211280104.RAA03897@birdie.sybase.com> <20021128031204.GA21675@nicemice.net> X-Hashcash: 0:021128:idn@ops.ietf.org:958d1c621d140aea From: Simon Josefsson Date: Thu, 28 Nov 2002 05:53:08 +0100 In-Reply-To: <20021128031204.GA21675@nicemice.net> ("Adam M. Costello"'s message of "Thu, 28 Nov 2002 03:12:04 +0000") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-4.8 required=5.0 tests=EMAIL_ATTRIBUTION,FWD_MSG,IN_REP_TO,MAILTO_TO_REMOVE, QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_GNUS_UA version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk "Adam M. Costello" writes: > Let's consider the possible scenarios: This was a useful summary. > 1. The decomposition mappings are changed. > > 1a. Stringprep/Nameprep track the update, breaking their promise of > backward compatibility. > > If someone registers a name using a CNS 11643 string in > combination with the old Nameprep, and later someone tries to look > up the name using the very same CNS 11643 string in combination > with the new Nameprep, it won't match (if it contains any of the > five characters in question). As more clients upgrade to the new > Nameprep, the name will become less and less accessible. During the time frame when clients upgrade to the new stringprep (which will be a year or more big) you will also be able to fool security software that matches stringprep processed strings for equality, because the security software may use different decomposition tables than user applications. > The biggest difference I can see between case 1 and case 2 is that if > the deprecate/add approach is taken (case 2), IDNA's only choices are > to track Unicode updates (2a) or not track them (2b), all or nothing. > But if the fix-decompositions approach is taken (case 1), IDNA has a > third option (1c) of tracking all Unicode updates except changes to > decompositions, via the NormalizationCorrections.txt file. 1c is a compelling option, but it essentially means forking the Unicode NFKC tables. Forking non-IETF standards in IETF has not been a good idea historically. But since NormalizationCorrections.txt will be short and documented, and the rationale clear, I kind of like it. > I find this result to be counter-intuitive. My initial gut feeling was > that the deprecate/add approach was more conservative, and safer. But > apparently not. I seem to disagree. To me, case 1a seems to be a disaster as far as security is concerned. All other cases are better. I prefer 2a, followed closely by 1c. (Note that I intentionally talk about stringprep and not nameprep, as the same issues apply to non-IDN applications using stringprep too. There are several security protocols considering using stringprep.) From owner-idn@ops.ietf.org Thu Nov 28 00:51:53 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10334 for ; Thu, 28 Nov 2002 00:51:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HHR7-000Ged-00 for idn-data@psg.com; Wed, 27 Nov 2002 21:42:05 -0800 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 18HHR5-000GeR-00 for idn@ops.ietf.org; Wed, 27 Nov 2002 21:42:03 -0800 Received: (from root@localhost) by postel3.postel.co.kr (8.11.0/8.11.0) id gAS5fqP02438; Thu, 28 Nov 2002 14:41:52 +0900 Date: Thu, 28 Nov 2002 14:41:52 +0900 From: Soobok Lee To: IETF idn working group Subject: Re: [idn] Re: Fwd: Unicode letter ballot Message-ID: <20021128054151.GJ20877@postel.co.kr> References: <200211280104.RAA03897@birdie.sybase.com> <20021128031204.GA21675@nicemice.net> <20021128040148.GG20877@postel.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021128040148.GG20877@postel.co.kr> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-1.3 required=5.0 tests=FWD_MSG,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk On Thu, Nov 28, 2002 at 01:01:48PM +0900, Soobok Lee wrote: > On Thu, Nov 28, 2002 at 03:12:04AM +0000, Adam M. Costello wrote: > > 1. The decomposition mappings are changed. > > > > 1b. Stringprep/Nameprep do not track Unicode updates; they remain > > frozen at a version containing the old mappings. > > > > If someone registers a name using a CNS 11643 string, and later > > someone tries to look up the name using the very same CNS 11643 > > string, it will match. But if a modern normalization operation > > gets inserted somewhere (for the heck of it, or because some > > other protocol that carries the domain name requires text to be > > normalized), it won't match. > > > > Names using the broken compatibility characters might not be > > registered in practice, because the Nameprepped form will look > > wrong. > > Maybe. But, i think this is still over-simplified. I will add more sub-cases: > > The compatiblity form has three equivalent forms. > 0) the compatiblity form itself > 1) the (falsely) nameprepped form from Unicode 3.2 false-NFC > 2) the desired-and-correct-but-abandoned equivalent form from correct-NFC > > Now, > 0) can't be registered as itself in any case, > because it is always mapped to something other. > 1) may be abandoned as you described above because it renders differently > than expected when registration time. > 1) may be, however, registered as un-nameprepped form itself > by other applicants who may occasionally > have this 1) name as their biz name. > 2) may be registered as un-nameprepped form itself > by other applicants who may occasionally > have this 2) name as their biz name. I forgot to add this: 0) and 2) strings share the same character glyphs (by correct NFC!), but 1) string does not. Then, when 2) is registerd and end users enter 0) for 2), this will lead to a failure or a wrong site '1)' since 1) != 2). Soobok Lee > > Adam, Could you continue to take your thorough analysis on these sub-cases? > > Soobok Lee > > > > > Since Nameprep never changes again, there is no transition as > > software gets upgraded. Names involving the five characters in > > question remain just as broken and undesirable in the far future > > as in the near future. It is likely that these five characters > > would never be used in domain names in practice, forever. From owner-idn@ops.ietf.org Thu Nov 28 01:12:46 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10755 for ; Thu, 28 Nov 2002 01:12:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HHnt-000HXn-00 for idn-data@psg.com; Wed, 27 Nov 2002 22:05:37 -0800 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 18HHnq-000HXT-00 for idn@ops.ietf.org; Wed, 27 Nov 2002 22:05:34 -0800 Received: (from root@localhost) by postel3.postel.co.kr (8.11.0/8.11.0) id gAS65Jq02828; Thu, 28 Nov 2002 15:05:19 +0900 Date: Thu, 28 Nov 2002 15:05:14 +0900 From: Soobok Lee To: Kenneth Whistler Cc: idn@ops.ietf.org, jet-member@nic.ad.jp Subject: Re: [idn] Re: Fwd: Unicode letter ballot Message-ID: <20021128060514.GK20877@postel.co.kr> References: <200211280152.RAA03951@birdie.sybase.com> <20021128021436.GE20877@postel.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021128021436.GE20877@postel.co.kr> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-0.5 required=5.0 tests=FWD_MSG,IN_REP_TO,RCVD_IN_RFCI,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk From owner-idn@ops.ietf.org Thu Nov 28 01:22:14 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10811 for ; Thu, 28 Nov 2002 01:22:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HHwj-000HtP-00 for idn-data@psg.com; Wed, 27 Nov 2002 22:14:45 -0800 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 18HHwf-000Ht1-00 for idn@ops.ietf.org; Wed, 27 Nov 2002 22:14:42 -0800 Received: (from root@localhost) by postel3.postel.co.kr (8.11.0/8.11.0) id gAS6EPs03027; Thu, 28 Nov 2002 15:14:25 +0900 Date: Thu, 28 Nov 2002 15:14:25 +0900 From: Soobok Lee To: Kenneth Whistler Cc: idn@ops.ietf.org, jet-member@nic.ad.jp Subject: Re: [idn] Re: Fwd: Unicode letter ballot Message-ID: <20021128061425.GL20877@postel.co.kr> References: <200211280152.RAA03951@birdie.sybase.com> <20021128021436.GE20877@postel.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021128021436.GE20877@postel.co.kr> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-1.3 required=5.0 tests=FWD_MSG,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk On Thu, Nov 28, 2002 at 11:14:36AM +0900, Soobok Lee wrote: > > particularly the CNS, GB and KSX ones, are duplicates for round-trip > > mapping purposes, but aren't really required for the level > > of distinctions useful for defining domain names (or host names, > > or any similar named entities that IETF is concerned about). > > Right. That means any CJK IDN admin guideline efforts should deal with > un-nameprepped CJK inputs in addition to nameprepped ones, in order to > fine tune their CJK equivalence tables based on regional languages. > that is , they should embrace those 5 wrong canonical CJK equivalences > and all their transitional ones as if they were legitimate ones. I correct: s/transitional/transitive/; I now CC this posting to JET lists for considerations in CJK Guidelines. Soobok Lee (Sorry for my previous empty article, My beloved MUTT went wrong... ) > But, even in those cases, local CJK identifier comparisons without DNS > queries will fail to match regardless of those CJK domains are owned by > a single registrant. of course, this issue is also nothing new in this WG. > > And, Chinese or Korean IME(input method editor) injects those > compatibility characters into protocols and end users often does not > know whther their input characters are compatibility CJKs or not. > They look exactly identical to their canonical equivalent CJKs. > From owner-idn@ops.ietf.org Thu Nov 28 04:44:28 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24000 for ; Thu, 28 Nov 2002 04:44:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HL9a-000O4j-00 for idn-data@psg.com; Thu, 28 Nov 2002 01:40:14 -0800 Received: from mailout05.sul.t-online.com ([194.25.134.82]) by psg.com with esmtp (Exim 3.36 #2) id 18HL9Y-000O4Q-00 for idn@ops.ietf.org; Thu, 28 Nov 2002 01:40:12 -0800 Received: from fwd02.sul.t-online.de by mailout05.sul.t-online.com with smtp id 18HL9R-00045w-02; Thu, 28 Nov 2002 10:40:05 +0100 Received: from mira.informatik.hu-berlin.de (03047300346-0001@[217.232.39.197]) by fmrl02.sul.t-online.com with esmtp id 18HL9K-055xC4C; Thu, 28 Nov 2002 10:39:58 +0100 Received: from mira.informatik.hu-berlin.de (localhost [127.0.0.1]) by mira.informatik.hu-berlin.de (8.12.6/8.11.6/SuSE Linux 0.5) with ESMTP id gAS9e0fa001853; Thu, 28 Nov 2002 10:40:00 +0100 Received: (from martin@localhost) by mira.informatik.hu-berlin.de (8.12.6/8.12.6/Submit) id gAS9dwCg001850; Thu, 28 Nov 2002 10:39:58 +0100 X-Authentication-Warning: mira.informatik.hu-berlin.de: martin set sender to martin@v.loewis.de using -f To: Soobok Lee Cc: Simon Josefsson , Harald Tveit Alvestrand , idn@ops.ietf.org Subject: Re: [idn] Re: Fwd: Unicode letter ballot References: <0A56805A-FF88-11D6-A024-0003934B2128@cisco.com> <54030000.1038405029@askvoll.hjemme.alvestrand.no> <20021128012649.GD20877@postel.co.kr> From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 28 Nov 2002 10:39:57 +0100 In-Reply-To: <20021128012649.GD20877@postel.co.kr> Message-ID: Lines: 16 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 03047300346-0001@t-dialin.net X-Spam-Status: No, hits=-4.4 required=5.0 tests=EMAIL_ATTRIBUTION,FWD_MSG,IN_REP_TO,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_GNUS_UA, X_AUTH_WARNING version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Soobok Lee writes: > If option A wins, I see a chaos: I don't see chaos. Since these are compatibility characters, they won't be part of any registered domain. Users of domains that contain the compatibility equivalents of these characters should simply use those equivalents in their HTML pages. Notice that this "problem" already exists for Unicode 3.2.0, and U+F951: http://www.unicode.org/Public/UNIDATA/NormalizationCorrections.txt Regards, Martin From owner-idn@ops.ietf.org Thu Nov 28 04:50:42 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24073 for ; Thu, 28 Nov 2002 04:50:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HLEv-000OD9-00 for idn-data@psg.com; Thu, 28 Nov 2002 01:45:45 -0800 Received: from mailout05.sul.t-online.com ([194.25.134.82]) by psg.com with esmtp (Exim 3.36 #2) id 18HLEu-000OCv-00 for idn@ops.ietf.org; Thu, 28 Nov 2002 01:45:44 -0800 Received: from fwd11.sul.t-online.de by mailout05.sul.t-online.com with smtp id 18HLEp-00037J-08; Thu, 28 Nov 2002 10:45:39 +0100 Received: from mira.informatik.hu-berlin.de (03047300346-0001@[217.232.39.197]) by fmrl11.sul.t-online.com with esmtp id 18HLEk-1kgiWWC; Thu, 28 Nov 2002 10:45:34 +0100 Received: from mira.informatik.hu-berlin.de (localhost [127.0.0.1]) by mira.informatik.hu-berlin.de (8.12.6/8.11.6/SuSE Linux 0.5) with ESMTP id gAS9jafa001879; Thu, 28 Nov 2002 10:45:36 +0100 Received: (from martin@localhost) by mira.informatik.hu-berlin.de (8.12.6/8.12.6/Submit) id gAS9jZJs001876; Thu, 28 Nov 2002 10:45:35 +0100 X-Authentication-Warning: mira.informatik.hu-berlin.de: martin set sender to martin@v.loewis.de using -f To: Simon Josefsson Cc: Kenneth Whistler , idn@ops.ietf.org Subject: Re: [idn] Re: Fwd: Unicode letter ballot References: <200211280104.RAA03897@birdie.sybase.com> From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 28 Nov 2002 10:45:35 +0100 In-Reply-To: Message-ID: Lines: 11 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 03047300346-0001@t-dialin.net X-Spam-Status: No, hits=-5.2 required=5.0 tests=EMAIL_ATTRIBUTION,FWD_MSG,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_GNUS_UA, X_AUTH_WARNING version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Simon Josefsson writes: > It is not the stability I'm worried about here, but security issues. Can you please elaborate on the security issues? I believe they are irrelevant in presence of compatibility characters, since compatibility characters are never part of a IDN label (i.e. the ToUnicode operation never produces them). Regards, Martin From owner-idn@ops.ietf.org Thu Nov 28 06:55:35 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25937 for ; Thu, 28 Nov 2002 06:55:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HN76-0000lC-00 for idn-data@psg.com; Thu, 28 Nov 2002 03:45:48 -0800 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 18HN73-0000kw-00 for idn@ops.ietf.org; Thu, 28 Nov 2002 03:45:45 -0800 Received: (from root@localhost) by postel3.postel.co.kr (8.11.0/8.11.0) id gASBhNj08469; Thu, 28 Nov 2002 20:43:23 +0900 Date: Thu, 28 Nov 2002 20:43:23 +0900 From: Soobok Lee To: "Martin v. L?wis" Cc: Simon Josefsson , Harald Tveit Alvestrand , idn@ops.ietf.org Subject: Re: [idn] Re: Fwd: Unicode letter ballot Message-ID: <20021128114323.GM20877@postel.co.kr> References: <0A56805A-FF88-11D6-A024-0003934B2128@cisco.com> <54030000.1038405029@askvoll.hjemme.alvestrand.no> <20021128012649.GD20877@postel.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-1.3 required=5.0 tests=FWD_MSG,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk On Thu, Nov 28, 2002 at 10:39:57AM +0100, Martin v. L?wis wrote: > Soobok Lee writes: > > > If option A wins, I see a chaos: > > I don't see chaos. Since these are compatibility characters, they > won't be part of any registered domain. Users of domains that contain > the compatibility equivalents of these characters should simply use > those equivalents in their HTML pages. Right, if the html page use NFCed UTF8 as basic encoding. But, Most homepages in east asia use local charset /encoding. And that requires localcharset<->unicode conversion that produces compatibility CJKs which will be further fed into nameprep. Korean IME produces compatiblity-CJK-equivalent KSX characters in interactive input session on the url bar in browsers. Soobok Lee > > Notice that this "problem" already exists for Unicode 3.2.0, and > U+F951: Yes. This issue is not new problem. We had already discussed . And concluded it is not a big problem. but, this instance of 5 chars seems to need serious decision that we had not expected, iMO. the pure possiblity become the reality. Soobok lee > > http://www.unicode.org/Public/UNIDATA/NormalizationCorrections.txt > > Regards, > Martin From owner-idn@ops.ietf.org Thu Nov 28 07:32:44 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26519 for ; Thu, 28 Nov 2002 07:32:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HNkq-0001rj-00 for idn-data@psg.com; Thu, 28 Nov 2002 04:26:52 -0800 Received: from mailout05.sul.t-online.com ([194.25.134.82]) by psg.com with esmtp (Exim 3.36 #2) id 18HNkn-0001rI-00 for idn@ops.ietf.org; Thu, 28 Nov 2002 04:26:50 -0800 Received: from fwd00.sul.t-online.de by mailout05.sul.t-online.com with smtp id 18HNkh-0005mQ-03; Thu, 28 Nov 2002 13:26:43 +0100 Received: from mira.informatik.hu-berlin.de (03047300346-0001@[217.232.63.46]) by fmrl00.sul.t-online.com with esmtp id 18HNkQ-28KNCSC; Thu, 28 Nov 2002 13:26:26 +0100 Received: from mira.informatik.hu-berlin.de (localhost [127.0.0.1]) by mira.informatik.hu-berlin.de (8.12.6/8.11.6/SuSE Linux 0.5) with ESMTP id gASCQRr5029081; Thu, 28 Nov 2002 13:26:28 +0100 Received: (from martin@localhost) by mira.informatik.hu-berlin.de (8.12.6/8.12.6/Submit) id gASCQIVL027460; Thu, 28 Nov 2002 13:26:18 +0100 X-Authentication-Warning: mira.informatik.hu-berlin.de: martin set sender to martin@v.loewis.de using -f To: Soobok Lee Cc: Simon Josefsson , Harald Tveit Alvestrand , idn@ops.ietf.org Subject: Re: [idn] Re: Fwd: Unicode letter ballot References: <0A56805A-FF88-11D6-A024-0003934B2128@cisco.com> <54030000.1038405029@askvoll.hjemme.alvestrand.no> <20021128012649.GD20877@postel.co.kr> <20021128114323.GM20877@postel.co.kr> From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 28 Nov 2002 13:26:16 +0100 In-Reply-To: <20021128114323.GM20877@postel.co.kr> Message-ID: Lines: 32 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 03047300346-0001@t-dialin.net X-Spam-Status: No, hits=-5.5 required=5.0 tests=EMAIL_ATTRIBUTION,FWD_MSG,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_GNUS_UA, X_AUTH_WARNING version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Soobok Lee writes: > > > If option A wins, I see a chaos: [...] > But, Most homepages in east asia use local charset /encoding. And > that requires localcharset<->unicode conversion that produces > compatibility CJKs which will be further fed into nameprep. > Korean IME produces compatiblity-CJK-equivalent KSX characters in > interactive input session on the url bar in browsers. Whether this would cause chaos is still questionable. First, I understand that these are Chinese compatibility characters, so your experience with Korean IME might not be relevant. The question is rather whether users that use IMEs which produce CNS 11643 could enter these characters, and whether they could also enter the compatibility-normalized character instead. [It appears that it will be hard to find an IME which supports the full CNS 11643 repertoire in the first place]. In any case, the idea that incorrectly-normalized characters could cause chaos seems unlikely. > Yes. This issue is not new problem. We had already discussed . And > concluded it is not a big problem. but, this instance of 5 chars > seems to need serious decision that we had not expected, iMO. > the pure possiblity become the reality. What is the change here? Why is U+2F868 more real than U+F951? Regards, Martin From owner-idn@ops.ietf.org Thu Nov 28 08:49:18 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27891 for ; Thu, 28 Nov 2002 08:49:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HOoX-0003fu-00 for idn-data@psg.com; Thu, 28 Nov 2002 05:34:45 -0800 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 18HOoU-0003fe-00 for idn@ops.ietf.org; Thu, 28 Nov 2002 05:34:42 -0800 Received: (from root@localhost) by postel3.postel.co.kr (8.11.0/8.11.0) id gASDXnw10104; Thu, 28 Nov 2002 22:33:49 +0900 Date: Thu, 28 Nov 2002 22:33:44 +0900 From: Soobok Lee To: "Martin v. L?wis" Cc: Simon Josefsson , Harald Tveit Alvestrand , idn@ops.ietf.org Subject: Re: [idn] Re: Fwd: Unicode letter ballot Message-ID: <20021128133343.GN20877@postel.co.kr> References: <0A56805A-FF88-11D6-A024-0003934B2128@cisco.com> <54030000.1038405029@askvoll.hjemme.alvestrand.no> <20021128012649.GD20877@postel.co.kr> <20021128114323.GM20877@postel.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-1.6 required=5.0 tests=FWD_MSG,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, REFERENCES,SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk On Thu, Nov 28, 2002 at 01:26:16PM +0100, Martin v. L?wis wrote: > Soobok Lee writes: > > > > > If option A wins, I see a chaos: > [...] > > But, Most homepages in east asia use local charset /encoding. And > > that requires localcharset<->unicode conversion that produces > > compatibility CJKs which will be further fed into nameprep. > > Korean IME produces compatiblity-CJK-equivalent KSX characters in > > interactive input session on the url bar in browsers. > > Whether this would cause chaos is still questionable. First, I > understand that these are Chinese compatibility characters, so your > experience with Korean IME might not be relevant. I agree. Korean compatbility CJKs are in every day CJK use, but CNS11643 compatibility CJK may or may not! I guess they will be rarely used. > The question is > rather whether users that use IMEs which produce CNS 11643 could enter > these characters, and whether they could also enter the > compatibility-normalized character instead. > > [It appears that it will be hard to find an IME which supports the > full CNS 11643 repertoire in the first place]. Whether or not full CNS11643 support is rare does nothing to do with the current issue. In any cases, _if_ someone enters those characters, he will get errornous results surely! That is the concern. > > In any case, the idea that incorrectly-normalized characters could > cause chaos seems unlikely. "Chaos" does not mean stringprep/nameprep is a total failure. For example, stringprep/nameprep is useful and satisfactory for everyday hangul syllable use! My concern is that even such partial failures would make chaos _in some cases_. We can't ignore this. We should do "something", but i am not sure what to do yet. > > > Yes. This issue is not new problem. We had already discussed . And > > concluded it is not a big problem. but, this instance of 5 chars > > seems to need serious decision that we had not expected, iMO. > > the pure possiblity become the reality. > > What is the change here? Why is U+2F868 more real than U+F951? As i stated above, whether they are rare/real is not the issue. Do you agree? Soobok Lee > > Regards, > Martin From owner-idn@ops.ietf.org Thu Nov 28 09:25:49 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28366 for ; Thu, 28 Nov 2002 09:25:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HPPc-0004oo-00 for idn-data@psg.com; Thu, 28 Nov 2002 06:13:04 -0800 Received: from pheidippides.md.chalmers.se ([129.16.237.91]) by psg.com with esmtp (Exim 3.36 #2) id 18HPPZ-0004ob-00 for idn@ops.ietf.org; Thu, 28 Nov 2002 06:13:01 -0800 Received: from chalmers95a69n (elek-4-213.chl.chalmers.se [129.16.214.213]) by pheidippides.md.chalmers.se (8.10.1/8.10.1) with SMTP id gASECwD28531 for ; Thu, 28 Nov 2002 15:12:58 +0100 (MET) From: "Kent Karlsson" To: "'IETF idn working group'" Subject: RE: [idn] Punicode: Upper-case in example Date: Thu, 28 Nov 2002 15:13:16 +0100 Message-ID: <000801c296e8$4ce3ece0$d5d61081@chalmers95a69n> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20021127232300.GC19768@nicemice.net> x-mimeole: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_OUTLOOK version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ... > It is not documented in the spec because it is not a feature of > Punycode. The Punycode algorithm inputs and outputs code > points, which are numbers. It does not input or output "u+". > > The sample implementation inputs and outputs "u+". Therefore the use > of the u as a 1-bit annotation is mentioned in the > documentation of the > sample implementation, which is embedded in the source code (you can > either read the source code of the usage() function, or run > the program > with no arguments). I find this confusing. And I think two things have gone wrong here. In general, an example implementation (of any software specification) should be as pure as possible, no extra bells and whistles. Same goes for example strings (if any). So the "1-bit annotations" appear to not belong. If they belong, they surely should not manifest themselves as "U+"/"u+", which in addition is not explained. Furthermore, in this case, there are example argument (to encode) and result (from decoding) strings that are not readily presentable in an ASCII document (as IETF documents apparently still have to be). So there is an additional step of presenting characters that are not ASCII printable ones. Using "U+" notation for such code points in the example string presentation is fine, though. This additional step does NOT belong in a sample implementation, but should be kept strictly outside of it. It would still be nice to have the example strings also in UTF-8 in the document, if possible, even if the example implementation does not work directly on UTF-8 strings. As for the "test wrapper" part of the sample implementation, if at all presented, it should read/write test strings in at least one of the "major" Unicode encodings (easiest would be to use UTF-32; the conversion to/from UTF-32 and some other Unicode encoding does not even belong in the *example test* wrapper, nor does encode/decode of "U+"-notation). Examples (strings, code) should be there to illustrate required behaviour. Not confuse the readers with irrelevant (and even misleading and hard to see) extras. /kent k From owner-idn@ops.ietf.org Thu Nov 28 10:47:01 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29312 for ; Thu, 28 Nov 2002 10:47:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HQpX-0007QA-00 for idn-data@psg.com; Thu, 28 Nov 2002 07:43:55 -0800 Received: from postel3.postel.co.kr ([211.218.145.194] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 18HQpU-0007Pn-00 for idn@ops.ietf.org; Thu, 28 Nov 2002 07:43:52 -0800 Received: (from root@localhost) by postel3.postel.co.kr (8.11.0/8.11.0) id gASFh3a12355; Fri, 29 Nov 2002 00:43:03 +0900 Date: Fri, 29 Nov 2002 00:43:03 +0900 From: Soobok Lee To: "Martin v. L?wis" Cc: Simon Josefsson , Harald Tveit Alvestrand , idn@ops.ietf.org Subject: Re: [idn] Re: Fwd: Unicode letter ballot Message-ID: <20021128154303.GP20877@postel.co.kr> References: <0A56805A-FF88-11D6-A024-0003934B2128@cisco.com> <54030000.1038405029@askvoll.hjemme.alvestrand.no> <20021128012649.GD20877@postel.co.kr> <20021128114323.GM20877@postel.co.kr> <20021128133343.GN20877@postel.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021128133343.GN20877@postel.co.kr> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-1.6 required=5.0 tests=FWD_MSG,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, REFERENCES,SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk On Thu, Nov 28, 2002 at 10:33:44PM +0900, Soobok Lee wrote: > > "Chaos" does not mean stringprep/nameprep is a total failure. For example, > stringprep/nameprep is useful and satisfactory for everyday hangul syllable use! I will add this: Precomposed hangul syllables (in every day use) remain unchanged through NFC. But other ancient-syllable-forming jamo sequences may not be treated as it should be due to NFC's errors which is dated to the early stage of ISO10646/NFC deveopments. If option A wins in the coming ballot, then I will push forward "correct NFC's hangul jamo handling errors!" in Unicode 4.0, because NFC backward compatibility promises would be regarded as being broken already in those cases of 5 CJK characters. I think "backward compatiblity promise of NFC" is useful and neccesary but proved to be premature at least in current version 3.2. It is proved that proofreading takes much time. If option B wins, careful zone admin guidelines can help to alleviate the problems into less painful levels, as though they could not elliminate the problem completely. Of course, option A causes some transitional (3.2->4.0) problems , which will however disappear sometime. > My concern is that even such partial failures would make chaos _in some > cases_. We can't ignore this. We should do "something", but i am not > sure what to do yet. > From owner-idn@ops.ietf.org Thu Nov 28 15:49:32 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04225 for ; Thu, 28 Nov 2002 15:49:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HVSb-000JL1-00 for idn-data@psg.com; Thu, 28 Nov 2002 12:40:33 -0800 Received: from mail024.syd.optusnet.com.au ([210.49.20.148]) by psg.com with esmtp (Exim 3.36 #2) id 18HVSY-000JKo-00 for idn@ops.ietf.org; Thu, 28 Nov 2002 12:40:30 -0800 Received: from BCK1 (c19609.eburwd1.vic.optusnet.com.au [210.49.59.192]) by mail024.syd.optusnet.com.au (8.11.1/8.11.1) with SMTP id gASKeTs11874 for ; Fri, 29 Nov 2002 07:40:29 +1100 From: "Jarrod Hollingworth" To: "IDN List" Subject: [idn] When will IDN's go live? Date: Fri, 29 Nov 2002 07:40:26 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT_OUTLOOK version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Does anyone know when the proposals will be accepted (encoding method approved and domain name prefix decided) so that international domain names can start to be registered? Thanks, Jarrod Hollingworth From owner-idn@ops.ietf.org Thu Nov 28 18:33:42 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06602 for ; Thu, 28 Nov 2002 18:33:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HY44-00011q-00 for idn-data@psg.com; Thu, 28 Nov 2002 15:27:24 -0800 Received: from arwen.cs.berkeley.edu ([128.32.132.165] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #2) id 18HY40-00011U-00 for idn@ops.ietf.org; Thu, 28 Nov 2002 15:27:20 -0800 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 18HY3z-0008NO-00 for ; Thu, 28 Nov 2002 15:27:19 -0800 Date: Thu, 28 Nov 2002 23:27:19 +0000 From: "Adam M. Costello" To: "'IETF idn working group'" Subject: Re: [idn] Punicode: Upper-case in example Message-ID: <20021128232719.GA31675@nicemice.net> Reply-To: IETF idn working group References: <20021127232300.GC19768@nicemice.net> <000801c296e8$4ce3ece0$d5d61081@chalmers95a69n> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000801c296e8$4ce3ece0$d5d61081@chalmers95a69n> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Kent Karlsson wrote: > In general, an example implementation (of any software specification) > should be as pure as possible, no extra bells and whistles. The sample implementation is divided into two parts, the implementation itself (let's call it the core), and the test wrapper. The core is pure. It implements the Punycode algorithm and the mixed-case annotations described in appendix B, and provides a simple abstract programming interface that makes it trivial to not use the annotation support if you don't want it (you simply pass a null pointer instead of a pointer to an array of flags). > So the "1-bit annotations" appear to not belong. I think it's good to have examples of the annotations, if for no other reason than to serve as examples of mixed-case encoded strings, which all implementations are required to handle, even if they don't interpret them as annotations. > If they belong, they surely should not manifest themselves as > "U+"/"u+", I don't see what's wrong with that representation. The nice thing about it is that it's very easy to ignore if you don't care about the annotations. > which in addition is not explained. I can see how it might be considered unfortunate that the examples section does not call attention to the annotations. It might be too late to change that, and I don't know if there would be consensus that it should be changed. > Furthermore, in this case, there are example argument (to encode) and > result (from decoding) strings that are not readily presentable in an > ASCII document (as IETF documents apparently still have to be). So > there is an additional step of presenting characters that are not > ASCII printable ones. Using "U+" notation for such code points in > the example string presentation is fine, though. This additional > step does NOT belong in a sample implementation, but should be kept > strictly outside of it. I agree that it does not belong in the core, and it's not. I don't see why it shouldn't be in the test wrapper. The only purpose of the test wrapper is to provide a convenient command-line interface on top of the programming interface, to make it easy to write scripts to run tests. I put the conversion to/from U+ notation into the test wrapper because it was getting to be a pain to generate and test the examples without it. I figured that other readers of the document would find it convenient (like I did) to be able to use the sample implementation directly on the example strings. If someone wants a different test wrapper that inputs and outputs UTF-32, they can modify the test wrapper pretty easily. > It would still be nice to have the example strings also in UTF-8 in > the document, if possible, even if the example implementation does not > work directly on UTF-8 strings. It would, but I think RFCs are required to be ASCII. AMC From owner-idn@ops.ietf.org Fri Nov 29 10:34:25 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01690 for ; Fri, 29 Nov 2002 10:34:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Hmqd-000HPq-00 for idn-data@psg.com; Fri, 29 Nov 2002 07:14:31 -0800 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #2) id 18Hmqb-000HOv-00 for idn@ops.ietf.org; Fri, 29 Nov 2002 07:14:29 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA22013; Fri, 29 Nov 2002 07:13:57 -0800 (PST) Received: from localhost (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gATFDuH19299; Fri, 29 Nov 2002 16:13:56 +0100 (MET) Date: Fri, 29 Nov 2002 16:10:42 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [idn] When will IDN's go live? To: Jarrod Hollingworth Cc: IDN List In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk > Does anyone know when the proposals will be accepted (encoding method > approved and domain name prefix decided) so that international domain names > can start to be registered? The documents have been approved by the IESG and are in the rfc-editor queue. The thing that remain to be done for the standards themselves is: 11. IANA considerations IANA will assign the ACE prefix in consultation with the IESG. It's on my TODO list to start having the conversations with the IANA on this topic. Erik From owner-idn@ops.ietf.org Sat Nov 30 04:10:50 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00641 for ; Sat, 30 Nov 2002 04:10:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18I3WE-000Ftt-00 for idn-data@psg.com; Sat, 30 Nov 2002 01:02:34 -0800 Received: from arwen.cs.berkeley.edu ([128.32.132.165] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #2) id 18I3W9-000FtX-00 for idn@ops.ietf.org; Sat, 30 Nov 2002 01:02:29 -0800 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 18I3W8-0003vK-00 for ; Sat, 30 Nov 2002 01:02:28 -0800 Date: Sat, 30 Nov 2002 09:02:27 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] Re: Fwd: Unicode letter ballot Message-ID: <20021130090227.GB14628@nicemice.net> Reply-To: IETF idn working group References: <200211280104.RAA03897@birdie.sybase.com> <20021128031204.GA21675@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-5.2 required=5.0 tests=EMAIL_ATTRIBUTION,FWD_MSG,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Simon Josefsson wrote: > To me, case 1a seems to be a disaster as far as security is concerned. > All other cases are better. I prefer 2a, followed closely by 1c. This is very curious. You say 2a is your favorite, and 1a is a disaster, but to me they appear to have the very same characteristics. Could you give a scenario that illustrates why 1a is so much worse than 2a? It seems to me that for any security hole in 1a involving the comparison of Unicode strings, the same security hole exists in 2a involving the comparison of CNS 11643 strings. (Reminder: 1a means the decomposition mappings are changed and Stringprep tracks the update. 2a means characters are deprecated and added, and Stringprep tracks the update.) AMC From owner-idn@ops.ietf.org Sat Nov 30 09:42:00 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05684 for ; Sat, 30 Nov 2002 09:42:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18I8jE-000M0b-00 for idn-data@psg.com; Sat, 30 Nov 2002 06:36:20 -0800 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #2) id 18I8jA-000M0K-00 for idn@ops.ietf.org; Sat, 30 Nov 2002 06:36:16 -0800 Received: from localhost (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.6/8.12.6) with ESMTP id gAUEa5GB005320 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 30 Nov 2002 15:36:13 +0100 To: IETF idn working group Subject: [idn] Re: Fwd: Unicode letter ballot References: <200211280104.RAA03897@birdie.sybase.com> <20021128031204.GA21675@nicemice.net> <20021130090227.GB14628@nicemice.net> X-Hashcash: 0:021130:idn@ops.ietf.org:7e7533f212c30530 From: Simon Josefsson Date: Sat, 30 Nov 2002 15:36:05 +0100 In-Reply-To: <20021130090227.GB14628@nicemice.net> ("Adam M. Costello"'s message of "Sat, 30 Nov 2002 09:02:27 +0000") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-4.8 required=5.0 tests=EMAIL_ATTRIBUTION,FWD_MSG,IN_REP_TO,MAILTO_TO_REMOVE, QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_GNUS_UA version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk "Adam M. Costello" writes: > Simon Josefsson wrote: > >> To me, case 1a seems to be a disaster as far as security is concerned. >> All other cases are better. I prefer 2a, followed closely by 1c. > > This is very curious. You say 2a is your favorite, and 1a is a > disaster, but to me they appear to have the very same characteristics. > Could you give a scenario that illustrates why 1a is so much worse than > 2a? One class of scenarios are software checking ACLs, such as an application authentication proxy (application level firewall, if you wish). To take the example of SASL (which doesn't have a stringprep profile, but might get one), connecting in with administrator credentials to an employee account on an IMAP server with SASL. Detailed example: Authentication identity "admin", authorization identity U+4711, password X. For the argument, let's say U+4711 decomposes into U+1234 in Unicode 3.2 but is later changed to U+4321. The SASL library, acting as a proxy in front of the application software, implements the current libstringprep correctly. It checks that admin's password is X and that he is authorized to log in as U+1234 (which is the result after stringprep of U+4711, which was sent because the client hadn't been updated to use stringprep, which should cause no problem) and says OK to the application. Now, in 1a the application is using updated tables from a more recent stringprep that incorporates the fixed decomposition mapping, causing it to admit the user to an account U+4321. This is bad. In 2a, the application sees that the characters are deprecated due to its decomposition mapping changed, and rejects the user. This is good. This example might seem contrived, but this kind of proxying and username forwarding handles alot in practice if you think about it, it does not have to be as explicit as an admin-logon. > (Reminder: 1a means the decomposition mappings are changed and > Stringprep tracks the update. 2a means characters are deprecated and > added, and Stringprep tracks the update.) [I used the word "disaster" carelessly, btw. This problem only concerns a small number of characters. It is a problem, but it does not have disastrous proportions.] From owner-idn@ops.ietf.org Sat Nov 30 09:44:52 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05714 for ; Sat, 30 Nov 2002 09:44:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18I8nl-000M83-00 for idn-data@psg.com; Sat, 30 Nov 2002 06:41:01 -0800 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #2) id 18I8ni-000M7p-00 for idn@ops.ietf.org; Sat, 30 Nov 2002 06:40:58 -0800 Received: from localhost (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.6/8.12.6) with ESMTP id gAUEeqGB005385 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 30 Nov 2002 15:40:55 +0100 To: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Cc: idn@ops.ietf.org Subject: [idn] Re: Fwd: Unicode letter ballot References: <200211280104.RAA03897@birdie.sybase.com> X-Hashcash: 0:021130:martin@v.loewis.de:5ad08729a24bac16 X-Hashcash: 0:021130:idn@ops.ietf.org:be29f055eb45b240 From: Simon Josefsson Date: Sat, 30 Nov 2002 15:40:47 +0100 In-Reply-To: (martin@v.loewis.de's message of "28 Nov 2002 10:45:35 +0100") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-5.0 required=5.0 tests=EMAIL_ATTRIBUTION,FWD_MSG,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_GNUS_UA version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit martin@v.loewis.de (Martin v. Löwis) writes: > Simon Josefsson writes: > >> It is not the stability I'm worried about here, but security issues. > > Can you please elaborate on the security issues? See my message to Adam M. Costello. > I believe they are irrelevant in presence of compatibility > characters, since compatibility characters are never part of a IDN > label (i.e. the ToUnicode operation never produces them). Yes, you are right. I was thinking of when changes like the one proposed here applies to any character, that doesn't happen to be a compatibility character. Hm. Perhaps I was unclear about that, if so I'm sorry for my confusion. From owner-idn@ops.ietf.org Sat Nov 30 10:49:31 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07005 for ; Sat, 30 Nov 2002 10:49:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18I9mf-000Nj9-00 for idn-data@psg.com; Sat, 30 Nov 2002 07:43:57 -0800 Received: from tux.w3.org ([18.29.0.27] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 18I9md-000Niv-00 for idn@ops.ietf.org; Sat, 30 Nov 2002 07:43:55 -0800 Received: from enoshima (IDENT:root@tux.w3.org [18.29.0.27]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA25956; Sat, 30 Nov 2002 10:43:54 -0500 Message-Id: <4.2.0.58.J.20021129063845.04d00940@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Fri, 29 Nov 2002 06:48:21 +0900 To: IETF idn working group , IETF idn working group From: Martin Duerst Subject: Re: [idn] Punicode: Upper-case in example In-Reply-To: <20021127232300.GC19768@nicemice.net> References: <4.2.0.58.J.20021127081348.03d59ca0@localhost> <4.2.0.58.J.20021127035248.03c13bf8@localhost> <200211071321.VAA04362@msr.hinet.net> <200211071321.VAA04362@msr.hinet.net> <4.2.0.58.J.20021127035248.03c13bf8@localhost> <4.2.0.58.J.20021127081348.03d59ca0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.9 required=5.0 tests=DATE_IN_PAST_24_48,EMAIL_ATTRIBUTION,IN_REP_TO, QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Hello Adam, I understand that the documents have been approved by the IESG, so at this stage, changes are not appropriate. But maybe some of the changes can be done in the next stage (draft standard,...). At 23:23 02/11/27 +0000, Adam M. Costello wrote: >Martin Duerst wrote: > > I don't think this is a very good idea to use the U+ for > > distinction, for the following reasons: > > > > 1) The u+ -> lower case, U+ -> upper case is not documented anywhere > > in the punycode draft (or at least I didn't find it). If used at > > all, it should be documented straight at the start of the examples. > >It is not documented in the spec because it is not a feature of >Punycode. The Punycode algorithm inputs and outputs code points, which >are numbers. It does not input or output "u+". I agree that documenting it in the normative part of the spec would be a bad idea. But what I was proposing was that it be mentioned in the examples section. >The sample implementation inputs and outputs "u+". Therefore the use >of the u as a 1-bit annotation is mentioned in the documentation of the >sample implementation, which is embedded in the source code (you can >either read the source code of the usage() function, or run the program >with no arguments). I agree with what Kent Karlson said on this. >I tried to downplay mixed-case annotation as much as possible in the >draft, because Paul and Patrik have never liked it. I'll ask them if >they think the Examples section should call attention to the mixed-case >annotations. I agree with downplaying. But then the best thing would be to not use it in the examples section. The alternative is to mention them in the examples section. > > 2) The above convention is very easy to overlook, in particular > > because u+ and U+ look so very similar. It is close to a widely > > established convention, but differs slightly. > >I'm curious--can you explain or point me to that convention? The convention is the very widely established convention of writing Unicode/UTC codepoints with an U+ followed by 4 to 6 digits. In that convention, the U is always upper case. For many people used to this convention, this convention is so well established that it's very easy to overlook the lower-case u+. That happened to two of us on Tuesday, and it took quite some time for us to figure out what was actually going on. > > 3) Punycode can be used in different ways, on mixed strings, on lc > > strings that still contain the original casing info, and on pure > > lc strings. Maybe there should be separate examples for all these > > three uses. > >Long ago some of my drafts included explanations of various scenarios, >some of which are not applicable to domain names. Since then, we >agreed that the Punycode draft should present itself as a piece of IDNA >which, by the way, could perhaps be useful outside IDNA; not as as a >general encoding that happens to be used in IDNA. The goal was to avoid >confusing implementors of IDNA. So I cut out all but the essentials of >mixed-case annotation, and confined its description to a single appendix >(and the sample implementation). I think that basically, that was the right thing to do. >Maybe, if/when there is real interest in using mixed-case annotations >and/or using Punycode for things other than domain names, we could >update the spec, or augment it with a separate document. There is definitely no interest from my side for using Punycode for things other than domain names, and therefore no interest for mixed-case annotations. Regards, Martin. From owner-idn@ops.ietf.org Sat Nov 30 19:26:57 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15051 for ; Sat, 30 Nov 2002 19:26:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IHkB-000A2c-00 for idn-data@psg.com; Sat, 30 Nov 2002 16:13:55 -0800 Received: from arwen.cs.berkeley.edu ([128.32.132.165] helo=nicemice.net) by psg.com with esmtp (Exim 3.36 #2) id 18IHk8-000A2N-00 for idn@ops.ietf.org; Sat, 30 Nov 2002 16:13:52 -0800 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 18IHk7-0005au-00 for ; Sat, 30 Nov 2002 16:13:51 -0800 Date: Sun, 1 Dec 2002 00:13:50 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] Re: Fwd: Unicode letter ballot Message-ID: <20021201001350.GA20965@nicemice.net> Reply-To: IETF idn working group References: <200211280104.RAA03897@birdie.sybase.com> <20021128031204.GA21675@nicemice.net> <20021130090227.GB14628@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-5.2 required=5.0 tests=EMAIL_ATTRIBUTION,FWD_MSG,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-idn@ops.ietf.org Precedence: bulk Simon Josefsson wrote: > Authentication identity "admin", authorization identity U+4711, > password X. For the argument, let's say U+4711 decomposes into U+1234 > in Unicode 3.2 but is later changed to U+4321. > > The SASL library, acting as a proxy in front of the application > software, implements the current libstringprep correctly. It checks > that admin's password is X and that he is authorized to log in as > U+1234 (which is the result after stringprep of U+4711, which was sent > because the client hadn't been updated to use stringprep, which should > cause no problem) and says OK to the application. > > Now, in 1a the application is using updated tables from a more recent > stringprep that incorporates the fixed decomposition mapping, causing > it to admit the user to an account U+4321. This is bad. > > In 2a, the application sees that the characters are deprecated due > to its decomposition mapping changed, and rejects the user. This is > good. It looks like the security hole in 1a stems from the existence of two Unicode strings X and Y such that now Stringprep(X) != Stringprep(Y) (so that two distinct accounts for X and Y can be created), but later (after the update of the decomposition mappings) Stringprep(X) == Stringprep(Y), so the two accounts will get confused. But I think the same phenomenon can happen with 2a. There are CNS 11643 strings A and B such that now Stringprep(CNS11643toUnicode(A)) != Stringprep(CNS11643toUnicode(B)) (so that two distinct accounts for A and B can be created), but later (after the deprecation and addition of Unicode characters, and the subsequent update of CNS11643toUnicode to use the new Unicode characters instead of the deprecated ones) Stringprep(CNS11643toUnicode(A)) == Stringprep(CNS11643toUnicode(B)), so again the two accounts get confused. No deprecated characters are going to be seen and rejected, because no CNS 11643 characters are deprecated, and the deprecated Unicode characters do not appear in the new CNS11643toUnicode table. An approach that would really avoid this pitfall would be to deprecate these characters not only in Unicode, but also in CNS 11643 and any other character sets that contain them, and create new characters in all these character sets, and leave all the mappings of the old deprecated characters unchanged in both the Unicode database and the WhateverToUnicode tables. AMC