From discuss-bounces@apps.ietf.org Mon Oct 01 13:35:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcP9w-0004YN-2X; Mon, 01 Oct 2007 13:34:20 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IcP9v-0004YB-1B for discuss-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 13:34:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcP9u-0004Xw-NC for discuss@apps.ietf.org; Mon, 01 Oct 2007 13:34:18 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcP9o-0006yQ-FM for discuss@apps.ietf.org; Mon, 01 Oct 2007 13:34:18 -0400 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0A21B142203; Mon, 1 Oct 2007 10:34:02 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLpbnPkhxaEP; Mon, 1 Oct 2007 10:33:55 -0700 (PDT) Received: from [192.168.1.103] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id A9954142210; Mon, 1 Oct 2007 10:33:55 -0700 (PDT) In-Reply-To: <46FC83E2.7030309@dcrocker.net> References: <6FE6A5ED-4E1C-4F61-A957-C7E4E00845A2@osafoundation.org> <0EF132BF-F10B-4282-A94B-428E46FB38D2@osafoundation.org> <46FC83E2.7030309@dcrocker.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9F49B1D6-946B-4056-9FD0-266BEECCA4CC@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: Dates for architecture workshop Date: Mon, 1 Oct 2007 10:33:52 -0700 To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Sep 27, 2007, at 9:32 PM, Dave Crocker wrote: > > Lisa Dusseault wrote: >> - The topic is intended to be Apps area common architecture (some >> such pieces which already exist include SASL, LDAP, URLs, MIME >> types). Any topic should relate to more than one application. >> - We would like this to be a working meeting. We may break people >> out forcibly into twos or threes to actually write stuff (email, >> proposals, I-D text, etc) but we'll also have some discussion as >> a big group. > > > Lisa, > > I've re-read your note a few times and while I think I understand > the concept of "common architecture" I am not understanding what > you mean by "position papers". > > Can you clarify what sorts of architectural problems are motivating > the event, what sorts of issues you are looking to have addressed, > what sorts of follow-on actions you are seeking, etc.? I'm hoping for community input on what sort of issues need to be addressed, rather than drive the agenda myself and end up with nobody doing the actual work :) This may be obvious, but I think the reason for a special venue and the topic of *common* architecture is to get people talking who normally wouldn't talk because they focus on different applications. It would be a waste of that time for the email folks to go off and discuss 2821 continuation line syntax amongst themselves, if, as I hope, there are HTTP and LDAP and calendaring folks there too. The definition of "Position paper" can be pretty loose. The topic is something you think might be interesting for the group to discuss, so what information can best fit in four pages to prepare for the discussion? It could be a discussion of a problem, of a solution, or comparison of solutions or approaches. I can definitely say what sorts of follow-on actions I'm hoping for: new work in the form of actual new I-Ds or draft charters, progress on stalled cross-application work, or even proposals to cease duplicative or unimportant work if that's appropriate. Lisa From discuss-bounces@apps.ietf.org Mon Oct 01 15:40:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcR6u-0003Ve-82; Mon, 01 Oct 2007 15:39:20 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IcR6s-0003Tr-Ps for discuss-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 15:39:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcR6s-0003Tg-Fg for discuss@apps.ietf.org; Mon, 01 Oct 2007 15:39:18 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcR6r-0001pN-1B for discuss@apps.ietf.org; Mon, 01 Oct 2007 15:39:18 -0400 Received: from pc6 (1Cust142.tnt10.lnd4.gbr.da.uu.net [62.188.139.142]) by astro.systems.pipex.net (Postfix) with SMTP id 03B0EE001341; Mon, 1 Oct 2007 20:05:16 +0100 (BST) Message-ID: <001b01c80454$b0490ac0$0601a8c0@pc6> From: "tom.petch" To: "Lisa Dusseault" References: <6FE6A5ED-4E1C-4F61-A957-C7E4E00845A2@osafoundation.org> <0EF132BF-F10B-4282-A94B-428E46FB38D2@osafoundation.org> Subject: Re: Dates for architecture workshop Date: Mon, 1 Oct 2007 13:01:13 +0200 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-Score: -99.1 (---------------------------------------------------) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org ----- Original Message ----- From: "Lisa Dusseault" To: "John C Klensin" Cc: "Apps Discuss" Sent: Thursday, September 27, 2007 6:41 PM Subject: Re: Dates for architecture workshop > I think that conflict is livable, and since the dates work well for > CalConnect people and for me and Chris, I'd like to nail those dates > down. Please put Feb 11/12 on your calendar if you're interested in > participating. > > We haven't nailed down all the details yet, but here's the rough idea: > > - The topic is intended to be Apps area common architecture (some > such pieces which already exist include SASL, LDAP, URLs, MIME > types). Any topic should relate to more than one application. Like - XML as a protocol definition language - XML as a data definition (/information /model) language Tom Petch > - We would like this to be a working meeting. We may break people > out forcibly into twos or threes to actually write stuff (email, > proposals, I-D text, etc) but we'll also have some discussion as a > big group. > - We would like participation to be open to people who aren't > already Apps 'insiders' so we do not plan to issue formal invitations > to a closed list of people. However, in order to limit attendance a > little, we will ask for on-topic position papers, just a few pages, > in advance of the meeting, as a condition of participation. > - If you intend to participate, I'd appreciate an email any time to > get a rough headcount. > - The deadline for position papers is tentatively friday, Dec 14. > That gives the IETF week and one week after for people who want to > bounce ideas around for position papers. > - We'll circulate the position papers in January so that people can > read and comment in advance. More homework! > - It will be in the Bay area. > - We are going to look for a host, but if there are a few expenses > not covered, we may ask for a few 100$ attendance fee. If we need to > ask this we'll ask in advance of the actual meeting, but once we have > a better idea how many people and what meeting space we need to obtain. > > Thanks, > Lisa > From discuss-bounces@apps.ietf.org Thu Oct 04 17:12:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdXy6-00076R-Bm; Thu, 04 Oct 2007 17:10:50 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IdXy5-00072v-Pk for discuss-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 17:10:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdXy5-00072N-FF for discuss@apps.ietf.org; Thu, 04 Oct 2007 17:10:49 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdXy4-0000ot-6c for discuss@apps.ietf.org; Thu, 04 Oct 2007 17:10:49 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IdXxz-0004F7-O2; Thu, 04 Oct 2007 17:10:43 -0400 Date: Thu, 04 Oct 2007 17:10:43 -0400 From: John C Klensin To: discuss@apps.ietf.org Subject: draft-klensin-net-utf8 and draft-klensin-unicode-escapes Message-ID: <3A8797AD0BB8B1EF4FAA7DE8@p3.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: the.map@alum.mit.edu X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi. After a long delay, I'm in the process or updating both of these documents. Very high-level summary of changes: ------ draft-klensin-unicode-escapes -04 has been posted. It has been reorganized to make it easier to follow and to respond to comments from several people on and off the list. It now recommends either \u'NNNN..' or the XML form and recommends against the others (and explains why). I think (hope?) that is consistent with general consensus. The alternative is to make no recommendation at all, which rather misses the point, I think (and some others seem to think so as well). Chris Newman suggested one additional change, which was to move the syntax for the not-recommended options into an appendix so as to further discourage their use. I think that is reasonable, but it didn't make -04. -05 will be posted, presumably within the next 24 hours if the online tool works this time, but that is the only substantive change from -04. ------- draft-klensin-net-utf8 This document has been considerably reworked, with some requirements lowered to SHOULD and others promoted to MUST per online discussions. Most of the former introductory material and explanations of Net-ASCII have been moved to appendices and the text streamlined. Normative recommendations to avoid the printer-driven idiosyncrasies of Net-ASCII have been added and clarified and a prohibition against the C1 controls has been added as well. The document should be posted once my collaborator and co-author has had a chance to review it. My hope is that we can fine-tune these in the next week or two and then put the documents out for Last Call as Proposed Standards. I think they are valuable or I wouldn't be putting effort into them. However, they have reached the point that, at least for me, significant further investments would exceed that value. So, if the community wants them, let's focus on any remaining important issues and get them resolved. If not, well, I'm prepared to just let one or both drop at this point. john From discuss-bounces@apps.ietf.org Fri Oct 05 10:25:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ido6m-0006ri-W8; Fri, 05 Oct 2007 10:24:52 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ido6m-0006qd-1b for discuss-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 10:24:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ido6l-0006qR-Jv for discuss@apps.ietf.org; Fri, 05 Oct 2007 10:24:51 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ido6f-0007cN-E3 for discuss@apps.ietf.org; Fri, 05 Oct 2007 10:24:51 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 5F9351C0108 for ; Fri, 5 Oct 2007 16:24:34 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 5BAFD1C00F7 for ; Fri, 5 Oct 2007 16:24:34 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 4ADED58ECC6 for ; Fri, 5 Oct 2007 16:24:34 +0200 (CEST) Date: Fri, 5 Oct 2007 16:24:34 +0200 From: Stephane Bortzmeyer To: discuss@apps.ietf.org Subject: Encoding of small characters in draft-klensin-unicode-escapes-04 Message-ID: <20071005142434.GA26901@nic.fr> References: <3A8797AD0BB8B1EF4FAA7DE8@p3.JCK.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3A8797AD0BB8B1EF4FAA7DE8@p3.JCK.COM> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Thu, Oct 04, 2007 at 05:10:43PM -0400, John C Klensin wrote a message of 49 lines which said: > It now recommends either \u'NNNN..' [Small syntax detail, do not spend too much time on it.] Section 5.1 describes the content of the "Backslash-U with Delimiters" form as "4*6HEXDIG". Why not "2*6HEXDIG"? It would be more compact for the first characters and would be more consistent with the other forms such as the "XML and HTML" one. My personal taste is that \u'20' is better than \u'0020'. Section 6.2 contains a note which seems related (the risk that small numbers are thought to represent octets, in the current locale) but I do not think it is a serious risk since section 2 clearly states that we encode Unicode code points, not octets. From discuss-bounces@apps.ietf.org Fri Oct 05 11:09:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdomY-0002FF-Ld; Fri, 05 Oct 2007 11:08:02 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IdomX-0002Ck-A8 for discuss-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 11:08:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdomX-0002Cb-0W for discuss@apps.ietf.org; Fri, 05 Oct 2007 11:08:01 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdomV-0000R8-Nj for discuss@apps.ietf.org; Fri, 05 Oct 2007 11:08:00 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 58F8C1C0100 for ; Fri, 5 Oct 2007 17:07:59 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 540B61C00F7 for ; Fri, 5 Oct 2007 17:07:59 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 515CF58EBBF for ; Fri, 5 Oct 2007 17:07:59 +0200 (CEST) Date: Fri, 5 Oct 2007 17:07:59 +0200 From: Stephane Bortzmeyer To: discuss@apps.ietf.org Subject: Re: I-D Action:draft-klensin-net-utf8-04.txt Message-ID: <20071005150759.GA29903@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Fri, Oct 05, 2007 at 01:40:02AM -0400, Internet-Drafts@ietf.org wrote a message of 91 lines which said: > Title : Unicode Format for Network Interchange > Author(s) : J. Klensin, M. Padlipsky > Filename : draft-klensin-net-utf8-04.txt I have read and studied this I-D and I find it basically OK, suitable for approval and very useful for the Internet, where internationalization is an important issue. I have some reservations, which are mostly details: > Section 1.1 [...] preferred to the double-byte encoding of "extended > ASCII" [RFC0698] This reference to a very obsolete system does not bring useful information. Delete it or move it to the interesting "History and Context" appendix. > Section 2.1 [...] None of those uses is inappropriate for streams of > plain text. Isn't it a typo? It should be "appropriate". > Section 3 [...] Recognition of the fact that some applications > implementations may rely on operating system libraries over which > they have little control and adherence to the robustness principle > suggests that receivers of such strings should be prepared to > receive unnormalized ones This is also a security issue. An attacker could deliberately send unormalized text even if the specification says MUST. As such, it is worth a mention in the security considerations. > Section 5.2 [...] internationalized domain names (IDNA [RFC3490]) > [...] specific difficulties with IDNA in this regard are discussed > in [RFC4690] The two mentions of IDNA brings no value and really smell like a personal issue. Discussions of the UTF-8 RFC are understandable but other RFC talking about Unicode are not mentioned. Why specifically IDNA? > Section 6 [...] A mention about firewalls and unormalized UTF-8 streams could be useful. Something like "Firewalls and other systems interpreting UTF-8 streams should be developed with the clear knowledge that an attacker may deliberately send unnormalized text, for instance to avoid detection by naive text-matching systems." > Appendix A [...] whois [RFC0954] If it is the current version, it should be RFC3912. If it is the original one, which would make sense in an historical section, it should be RFC0812. From discuss-bounces@apps.ietf.org Fri Oct 05 11:12:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idoqu-00074y-7c; Fri, 05 Oct 2007 11:12:32 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Idoqt-00074t-IN for discuss-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 11:12:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idoqt-00074l-8o for discuss@apps.ietf.org; Fri, 05 Oct 2007 11:12:31 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Idoqq-0000XV-De for discuss@apps.ietf.org; Fri, 05 Oct 2007 11:12:31 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 12C4B1C0100; Fri, 5 Oct 2007 17:12:28 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 0E8141C00F7; Fri, 5 Oct 2007 17:12:28 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 00BA158EBBF; Fri, 5 Oct 2007 17:12:28 +0200 (CEST) Date: Fri, 5 Oct 2007 17:12:27 +0200 From: Stephane Bortzmeyer To: John C Klensin Subject: Form feed in Net-UTF8? (Was: FWD: Re: Comments on Unicode Format for Network Interchange Message-ID: <20071005151227.GA31232@nic.fr> References: <398A6C120C8B166FCBD3BDAF@p3.JCK.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <398A6C120C8B166FCBD3BDAF@p3.JCK.COM> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Doug Ewell said: > > I recommend that the control code FF (form feed, U+000C) be > > likewise permitted. The form feed function is well known and well > > defined in almost all printing functions, and all RFCs issued in > > modern times use FF to separate pages. It would ironic indeed for > > the Internet-Draft to retain the requirement that form feeds > > "SHOULD NOT be used unless required by exceptional circumstances" > > while advancing toward publication as an RFC, complete with form > > feeds! And I did not see anywhere a discussion of this specific point. I notice that draft-klensin-net-utf8-04 still disallows (actually, it is a SHOULD NOT in section 2.1) form feeds and I'm not sure of the rationale. Why end-of-lines and not end-of-pages? From discuss-bounces@apps.ietf.org Fri Oct 05 11:31:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idp8U-000515-5R; Fri, 05 Oct 2007 11:30:42 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Idp8S-0004xa-SV for discuss-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 11:30:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idp8S-0004wT-HJ for discuss@apps.ietf.org; Fri, 05 Oct 2007 11:30:40 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Idp8N-00011Q-4z for discuss@apps.ietf.org; Fri, 05 Oct 2007 11:30:40 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Idp8C-0009OS-My; Fri, 05 Oct 2007 11:30:24 -0400 Date: Fri, 05 Oct 2007 11:30:23 -0400 From: John C Klensin To: Stephane Bortzmeyer , discuss@apps.ietf.org Subject: Re: Encoding of small characters in draft-klensin-unicode-escapes-04 Message-ID: In-Reply-To: <20071005142434.GA26901@nic.fr> References: <3A8797AD0BB8B1EF4FAA7DE8@p3.JCK.COM> <20071005142434.GA26901@nic.fr> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Friday, 05 October, 2007 16:24 +0200 Stephane Bortzmeyer wrote: > On Thu, Oct 04, 2007 at 05:10:43PM -0400, > John C Klensin wrote > a message of 49 lines which said: > >> It now recommends either \u'NNNN..' > > [Small syntax detail, do not spend too much time on it.] > > Section 5.1 describes the content of the "Backslash-U with > Delimiters" form as "4*6HEXDIG". Why not "2*6HEXDIG"? It would > be more compact for the first characters and would be more > consistent with the other forms such as the "XML and HTML" one. > > My personal taste is that \u'20' is better than \u'0020'. First, I want to be clear that I don't feel strongly about any of this and will do what the community wants. However... One could use the two-digit form, but I think it is trouble. The Unicode folks, whose guidance I'm trying to follow except when it seems to violate good Internet or applications sense, never use less than four hex digits. And we have the problem with Perl (noted in that section now) that two-digit values are sometimes interpreted as ASCII and sometimes as "local one-octet character encoding, whatever that is". So the four-digit form helps emphasize that this is, in fact, Unicode and avoids any risk of confusion with local one-octet (or less) character sets, decimal encoding of octets, etc. > Section 6.2 contains a note which seems related (the risk that > small numbers are thought to represent octets, in the current > locale) but I do not think it is a serious risk since section > 2 clearly states that we encode Unicode code points, not > octets. And we all know that people often read specs in a sloppy or incomplete fashion. So I suggest that requiring four digits (or more) is more robust than permitting two. Whether the advantages of being able to write two digits outweigh that... well, I don't think so, but, if others strongly disagree, I'll change it. john From discuss-bounces@apps.ietf.org Fri Oct 05 11:55:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdpVj-0001vE-Rf; Fri, 05 Oct 2007 11:54:43 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IdpVj-0001v9-JZ for discuss-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 11:54:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdpVj-0001v1-A2 for discuss@apps.ietf.org; Fri, 05 Oct 2007 11:54:43 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdpVh-0001qW-Dj for discuss@apps.ietf.org; Fri, 05 Oct 2007 11:54:43 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IdpVX-000Aig-OH; Fri, 05 Oct 2007 11:54:32 -0400 Date: Fri, 05 Oct 2007 11:54:30 -0400 From: John C Klensin To: Stephane Bortzmeyer , discuss@apps.ietf.org Subject: Re: I-D Action:draft-klensin-net-utf8-04.txt Message-ID: <3DD121D8A8CB33BE639A9B9E@p3.JCK.COM> In-Reply-To: <20071005150759.GA29903@nic.fr> References: <20071005150759.GA29903@nic.fr> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Friday, 05 October, 2007 17:07 +0200 Stephane Bortzmeyer wrote: > On Fri, Oct 05, 2007 at 01:40:02AM -0400, > Internet-Drafts@ietf.org wrote > a message of 91 lines which said: > >> Title : Unicode Format for Network Interchange >> Author(s) : J. Klensin, M. Padlipsky >> Filename : draft-klensin-net-utf8-04.txt > > I have read and studied this I-D and I find it basically OK, > suitable for approval and very useful for the Internet, where > internationalization is an important issue. > > I have some reservations, which are mostly details: > >> Section 1.1 [...] preferred to the double-byte encoding of >> "extended ASCII" [RFC0698] > > This reference to a very obsolete system does not bring useful > information. Delete it or move it to the interesting "History > and Context" appendix. Officially, RFC698 is not obsolete and applies specifically to NVT-like streams, which is why it seemed worth singling out. The spec should have listed "obsoletes RFC 698", which means that this can't be in a section that is purely informative. I'll try to figure out a better way to handle it, but am going to leave the text more or less as is until I see further comments. A better alternative would be for someone to create an RFC titled something like "implications of the character set policy" that clears out internationalization cruft like RFC 698 and "extended ASCII". Opinions and volunteers would be welcome. >> Section 2.1 [...] None of those uses is inappropriate for >> streams of plain text. > > Isn't it a typo? It should be "appropriate". Yes. It was a type. Fixed in -05. There are several other typos, including syntax that omits closing single quotes, that have been reported offlist and fixed in -05. >> Section 3 [...] Recognition of the fact that some applications >> implementations may rely on operating system libraries over >> which they have little control and adherence to the >> robustness principle suggests that receivers of such strings >> should be prepared to receive unnormalized ones > > This is also a security issue. An attacker could deliberately > send unormalized text even if the specification says MUST. As > such, it is worth a mention in the security considerations. Reasonable idea. Text added. >> Section 5.2 [...] internationalized domain names (IDNA >> [RFC3490]) [...] specific difficulties with IDNA in this >> regard are discussed in [RFC4690] > > The two mentions of IDNA brings no value and really smell like > a personal issue. Discussions of the UTF-8 RFC are > understandable but other RFC talking about Unicode are not > mentioned. Why specifically IDNA? It isn't really an IDNA issue at all, but the issue with Unicode versioning and libraries. 4690 contains the best discussion of that subject of anything now published in the RFC series (the discussion in draft-klensin-idnabis-issues is arguably even better, but that document is in a sufficiently preliminary state that having this one reference it would be unwise). If you think it would significantly improve the document, I could make that text say, e.g., that IDNA, SASLPrep, and possibly other protocols are tied to Unicode 3.2 via Stringprep and then point to 4690. But, either way, it is just a comment about something we've done that is weak and should not be repeated for Net-Unicode and an informative reference for further reading. >> Section 6 [...] > > A mention about firewalls and unormalized UTF-8 streams could > be useful. Something like "Firewalls and other systems > interpreting UTF-8 streams should be developed with the clear > knowledge that an attacker may deliberately send unnormalized > text, for instance to avoid detection by naive text-matching > systems." Done. >> Appendix A [...] whois [RFC0954] > > If it is the current version, it should be RFC3912. If it is > the original one, which would make sense in an historical > section, it should be RFC0812. Here, I disagree. RFC954 was chosen because it was the last, and most clear, version of the original spec. RFC3912 is different in several respects and arguably introduces new ambiguities. I could make it "[RFC0812] [RFC0954]" if you think that would improve clarity. thanks, john From discuss-bounces@apps.ietf.org Fri Oct 05 11:58:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdpYx-0000dZ-0B; Fri, 05 Oct 2007 11:58:03 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IdpYw-0000dG-6C for discuss-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 11:58:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdpYv-0000bV-S5 for discuss@apps.ietf.org; Fri, 05 Oct 2007 11:58:01 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdpYu-0001x8-KU for discuss@apps.ietf.org; Fri, 05 Oct 2007 11:58:01 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IdpYu-000Ama-A8; Fri, 05 Oct 2007 11:58:00 -0400 Date: Fri, 05 Oct 2007 11:57:59 -0400 From: John C Klensin To: Stephane Bortzmeyer Subject: Re: Form feed in Net-UTF8? (Was: FWD: Re: Comments on Unicode Format for Network Interchange Message-ID: In-Reply-To: <20071005151227.GA31232@nic.fr> References: <398A6C120C8B166FCBD3BDAF@p3.JCK.COM> <20071005151227.GA31232@nic.fr> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Friday, 05 October, 2007 17:12 +0200 Stephane Bortzmeyer wrote: > Doug Ewell said: > >> > I recommend that the control code FF (form feed, U+000C) be >> > likewise permitted. The form feed function is well known >> > and well defined in almost all printing functions, and all >> > RFCs issued in modern times use FF to separate pages. It >> > would ironic indeed for the Internet-Draft to retain the >> > requirement that form feeds "SHOULD NOT be used unless >> > required by exceptional circumstances" while advancing >> > toward publication as an RFC, complete with form feeds! > > And I did not see anywhere a discussion of this specific > point. I notice that draft-klensin-net-utf8-04 still disallows > (actually, it is a SHOULD NOT in section 2.1) form feeds and > I'm not sure of the rationale. Why end-of-lines and not > end-of-pages? Because line breaks are required even for unformatted streams. FormFeeds are not. But I find the above arguments reasonably persuasive and will put FF back in unless others feel strongly about this. john From discuss-bounces@apps.ietf.org Fri Oct 05 12:22:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdpvN-00067s-Nw; Fri, 05 Oct 2007 12:21:13 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IdpvM-000676-Bd for discuss-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 12:21:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdpvM-00066x-26 for discuss@apps.ietf.org; Fri, 05 Oct 2007 12:21:12 -0400 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdpvF-0002bx-PQ for discuss@apps.ietf.org; Fri, 05 Oct 2007 12:21:12 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id l95GKdqV017802Fri, 5 Oct 2007 16:20:39 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1Idpuo-00072C-00; Fri, 05 Oct 2007 17:20:38 +0100 Date: Fri, 5 Oct 2007 17:20:38 +0100 From: "Clive D.W. Feather" To: John C Klensin Subject: Re: draft-klensin-net-utf8 and draft-klensin-unicode-escapes Message-ID: <20071005162038.GP90213@finch-staff-1.thus.net> References: <3A8797AD0BB8B1EF4FAA7DE8@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3A8797AD0BB8B1EF4FAA7DE8@p3.JCK.COM> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: discuss@apps.ietf.org, the.map@alum.mit.edu X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org John C Klensin said: > draft-klensin-unicode-escapes > -04 has been posted. It has been reorganized to make it > easier to follow and to respond to comments from several people > on and off the list. First thing I spotted: the syntax in 5.1 is missing the trailing quote mark. Section 4 is missing the references to ISO-C and Java. > draft-klensin-net-utf8 Section 2.1 item 3: "control characters" needs to be properly defined, since it's a SHOULD. Unicode.org is currently offline, but at the least you either need to make it explicit ranges (say U+0000 to U+001F and U+007F to U+009F), or base it on a Unicode character class. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | From discuss-bounces@apps.ietf.org Fri Oct 05 12:32:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idq5d-0006ss-3m; Fri, 05 Oct 2007 12:31:49 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Idq5c-0006sl-Rp for discuss-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 12:31:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idq5c-0006sd-IN for discuss@apps.ietf.org; Fri, 05 Oct 2007 12:31:48 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Idq5b-0003Dv-Bh for discuss@apps.ietf.org; Fri, 05 Oct 2007 12:31:48 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Idq5S-000C1Z-Fz; Fri, 05 Oct 2007 12:31:38 -0400 Date: Fri, 05 Oct 2007 12:31:37 -0400 From: John C Klensin To: "Clive D.W. Feather" Subject: Re: draft-klensin-unicode-escapes Message-ID: In-Reply-To: <20071005162038.GP90213@finch-staff-1.thus.net> References: <3A8797AD0BB8B1EF4FAA7DE8@p3.JCK.COM> <20071005162038.GP90213@finch-staff-1.thus.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: discuss@apps.ietf.org, the.map@alum.mit.edu X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Friday, 05 October, 2007 17:20 +0100 "Clive D.W. Feather" wrote: > John C Klensin said: >> draft-klensin-unicode-escapes >> -04 has been posted. It has been reorganized to make it >> easier to follow and to respond to comments from several >> people on and off the list. > > First thing I spotted: the syntax in 5.1 is missing the > trailing quote mark. Noted already and fixed. > Section 4 is missing the references to ISO-C and Java. I will happily accept and incorporate such references. However, I note that I've been encouraged to remove or minimize Section 4 and that anyone who is reading this and doesn't know what C or Java are probably won't want to use those forms (which is the idea). From discuss-bounces@apps.ietf.org Fri Oct 05 12:58:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdqV4-0001w4-5A; Fri, 05 Oct 2007 12:58:06 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IdqV2-0001te-Sk for discuss-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 12:58:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdqV2-0001tV-JI for discuss@apps.ietf.org; Fri, 05 Oct 2007 12:58:04 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdqV1-0004F3-AQ for discuss@apps.ietf.org; Fri, 05 Oct 2007 12:58:04 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IdqUv-000CQU-QS; Fri, 05 Oct 2007 12:57:57 -0400 Date: Fri, 05 Oct 2007 12:57:57 -0400 From: John C Klensin To: "Clive D.W. Feather" Subject: Re: draft-klensin-net-utf8 Message-ID: <99A43B12619CB831A2FDE27E@p3.JCK.COM> In-Reply-To: <20071005162038.GP90213@finch-staff-1.thus.net> References: <3A8797AD0BB8B1EF4FAA7DE8@p3.JCK.COM> <20071005162038.GP90213@finch-staff-1.thus.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: discuss@apps.ietf.org, the.map@alum.mit.edu X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Friday, 05 October, 2007 17:20 +0100 "Clive D.W. Feather" wrote: >> draft-klensin-net-utf8 > > Section 2.1 item 3: "control characters" needs to be properly > defined, since it's a SHOULD. Unicode.org is currently > offline, but at the least you either need to make it explicit > ranges (say U+0000 to U+001F and U+007F to U+009F), or base it > on a Unicode character class. Once upon a time, the criterion for the level of referencing and specificity in an RFC was "everyone, or at least everyone competent to use the spec, knows what one is talking about". Being pedantic for its own sake or on principle was not considered useful or desirable. If anyone is writing code that uses Unicode and doesn't know what a control character is, they are in much bigger trouble than this document can fix. And "C0" and "C1" are defined in Unicode as the names of parts of blocks. I'll make this change, but would encourage everyone to think carefully about whether we really want to go in the direction I think it represents. john From discuss-bounces@apps.ietf.org Fri Oct 05 14:50:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdsEv-0006OH-Bl; Fri, 05 Oct 2007 14:49:33 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IdsEu-0006OB-Hl for discuss-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 14:49:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdsEu-0006Nc-4X for discuss@apps.ietf.org; Fri, 05 Oct 2007 14:49:32 -0400 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdsEn-0008Vp-OG for discuss@apps.ietf.org; Fri, 05 Oct 2007 14:49:32 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id l95In43K008981Fri, 5 Oct 2007 18:49:05 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1IdsES-0009Z2-00; Fri, 05 Oct 2007 19:49:04 +0100 Date: Fri, 5 Oct 2007 19:49:04 +0100 From: "Clive D.W. Feather" To: John C Klensin Subject: Re: draft-klensin-unicode-escapes Message-ID: <20071005184904.GA36729@finch-staff-1.thus.net> References: <3A8797AD0BB8B1EF4FAA7DE8@p3.JCK.COM> <20071005162038.GP90213@finch-staff-1.thus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: discuss@apps.ietf.org, the.map@alum.mit.edu X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org John C Klensin said: >> Section 4 is missing the references to ISO-C and Java. > I will happily accept and incorporate such references. Sorry, I wasn't clear. They're referred to in the References section. They just aren't tagged in section 4. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | From discuss-bounces@apps.ietf.org Fri Oct 05 15:13:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idsah-0001Bh-VJ; Fri, 05 Oct 2007 15:12:03 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Idsag-0000zf-60 for discuss-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 15:12:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idsae-0000xH-Uy for discuss@apps.ietf.org; Fri, 05 Oct 2007 15:12:00 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdsaZ-00017h-9Z for discuss@apps.ietf.org; Fri, 05 Oct 2007 15:12:00 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IdsaS-000FFY-Tu; Fri, 05 Oct 2007 15:11:49 -0400 Date: Fri, 05 Oct 2007 15:11:47 -0400 From: John C Klensin To: "Clive D.W. Feather" Subject: Re: draft-klensin-unicode-escapes Message-ID: <4DDE3361BCC06B5EEA7107FF@p3.JCK.COM> In-Reply-To: <20071005184904.GA36729@finch-staff-1.thus.net> References: <3A8797AD0BB8B1EF4FAA7DE8@p3.JCK.COM> <20071005162038.GP90213@finch-staff-1.thus.net> <20071005184904.GA36729@finch-staff-1.thus.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: discuss@apps.ietf.org, the.map@alum.mit.edu X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Friday, 05 October, 2007 19:49 +0100 "Clive D.W. Feather" wrote: > John C Klensin said: >>> Section 4 is missing the references to ISO-C and Java. >> I will happily accept and incorporate such references. > > Sorry, I wasn't clear. They're referred to in the References > section. They just aren't tagged in section 4. Ah. Editing glitch. Will fix john From discuss-bounces@apps.ietf.org Fri Oct 05 20:04:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idx7p-0008Rh-I1; Fri, 05 Oct 2007 20:02:33 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Idx7n-0008O1-Rl for discuss-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 20:02:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idx7n-0008Mq-HM for discuss@apps.ietf.org; Fri, 05 Oct 2007 20:02:31 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Idx7h-0002PT-35 for discuss@apps.ietf.org; Fri, 05 Oct 2007 20:02:31 -0400 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8ED83142227; Fri, 5 Oct 2007 17:02:14 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXFOXcrVIBNR; Fri, 5 Oct 2007 17:01:09 -0700 (PDT) Received: from [10.1.1.107] (unknown [157.22.41.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id AA351142215; Fri, 5 Oct 2007 17:01:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <5E1B7B04-DAFE-41DC-ABE4-3575A646519F@osafoundation.org> Content-Type: multipart/alternative; boundary=Apple-Mail-1-720785139 To: Apps Discuss , Lisa Dusseault's Chairs Subject: Lisa's Apps Area Activity for Sept 2007 From: Lisa Dusseault Date: Fri, 5 Oct 2007 17:01:06 -0700 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-1-720785139 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Notes: - WG meeting schedule requests cutoff is already past. (http:// ietf.org/meetings/70-cutoff_dates.html) - Cutoff date for preliminary BOF requests is also past. - Received request for HTTP BOF, although as we're processing the HTTPBIS proposed charter, it might be a WG by Vancouver instead of a BOF. Document Status and Progress Active Documents: my action - draft-creed-ogc-urn (Informational) -- need to review now that URN namespace registration debate seems to be over - draft-goodwin-iso-urn (Proposed Standard) -- need to review latest version from author - draft-saintandre-jabberid (Experimental) -- need to do writeup - draft-saintandre-rfc4622bis (PS) -- need to do writeup Stalled, in review, waiting on other: - draft-adolf-dvb-urn (Info): in IETF Last Call - draft-snell-atompub-bidi (PS): pinged Unicode consortium for review on bidi approach - draft-mealling-epc-urn (Info): in IETF Last Call - draft-ietf-sieve-body (PS): Waiting for new version from authors - draft-ietf-imapext-sort (PS): Waiting for IMAPEXT i18n - draft-crocker-rfc4234bis (Standard): Waiting for new text from authors - draft-ietf-sieve-3028bis (PS): Waiting for new version incorporating quite a few changes - draft-montemurro-gsma-imei-urn (Experimental): Waiting for new version from authors Finished Processing -- RFC Ed queue and new RFCs - draft-crispin-collation-unicasemap (PS): in RFC Ed queue - draft-ietf-lemonade-rfc2192bis (PS): in RFC Ed queue - RFC 5005: Feed Paging and Archiving No longer on my plate: - draft-hartman-webauth-phishing (Info): Back to the author for more community input and revisions. - draft-snell-atompub-feature (PS): Decided not to shepherd this important AtomPub document because of unclear community consensus around required features. - draft-wilde-sms-uri (PS): Decided not to shepherd this URI proposal as-is because of security concerns around gatewaying to email. WG Status - SIEVE waiting for chairs and ADs to complete document writeups and document shepherding - IMAPEXT stalled waiting for i18n work to complete - ATOMPUB mailing lists active on non-WG-deliverable topics -- RFC for atompub protocol about to pop out of queue! - CALSIFY chugging through issues -- chairs declared RFC2445bis "closed" for new issues - USEFOR stalled on single WG deliverable Lisa --Apple-Mail-1-720785139 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
=A0- WG meeting schedule = requests cutoff is already past.=A0(http://ietf.org/mee= tings/70-cutoff_dates.html)
=A0- Cutoff = date for preliminary BOF requests is also past.=A0
=A0- Received request for HTTP BOF, although as = we're processing the HTTPBIS proposed charter, it might be a WG by = Vancouver instead of a BOF.


Active = Documents: my action
=A0-=A0draft-goodwin-iso-urn (Proposed Standard) -- = need to review latest version from author
=A0-=A0draft-saintandre-rfc4622bis= (PS) -- need to do writeup

Stalled, = in review, waiting on other:
=A0-=A0draft-adolf-dvb-urn (Info): in IETF Last = Call
=A0-=A0draft-snell-atompub-bidi=A0(PS): pinged Unicode consortium for = review on bidi approach
=A0-=A0draft-ietf-sieve-body (PS): Waiting for new = version from authors
=A0-=A0draft-ietf-imapext-sor= t (PS): Waiting for IMAPEXT i18n
=A0-=A0draft-ietf-sieve-3028bis = (PS): Waiting for new version incorporating quite a few = changes

Finished = Processing -- RFC Ed queue and new RFCs
draft-crispin-collation-unicasemap (PS): in RFC Ed = queue
=A0- RFC 5005: Feed Paging and Archiving

No longer on my = plate:
=A0-=A0draft-hartman-webauth-phishing (Info): = Back to the author for more community input and = revisions.
=A0-=A0draft-snell-atompub-feature (PS): = Decided not to shepherd this important AtomPub document because of = unclear community consensus around required features.
=A0-=A0draft-wilde-sms-uri (PS): Decided not = to shepherd this URI proposal as-is because of security concerns around = gatewaying to email.

WG = Status
=A0- SIEVE waiting for chairs = and ADs to complete document writeups and document shepherding
=A0- IMAPEXT stalled waiting for i18n work to = complete
=A0- ATOMPUB mailing lists = active on non-WG-deliverable=A0 topics -- RFC for atompub protocol about = to pop out of queue!
=A0- CALSIFY chugging = through issues -- chairs declared RFC2445bis "closed" for new = issues
=A0- USEFOR stalled on single WG = deliverable


Lisa=A0
= --Apple-Mail-1-720785139-- From discuss-bounces@apps.ietf.org Fri Oct 05 20:12:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdxGg-00050e-Un; Fri, 05 Oct 2007 20:11:42 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IdxGe-0004re-QA for discuss-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 20:11:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdxGe-0004rV-Fy for discuss@apps.ietf.org; Fri, 05 Oct 2007 20:11:40 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdxGY-0002gP-An for discuss@apps.ietf.org; Fri, 05 Oct 2007 20:11:40 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IdxGS-000NjK-Vr for discuss@apps.ietf.org; Fri, 05 Oct 2007 20:11:29 -0400 Date: Fri, 05 Oct 2007 20:11:28 -0400 From: John C Klensin To: discuss@apps.ietf.org Subject: draft-klensin-unicode-escapes-05 and draft-klensin-net-utf8-05 Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi. New versions of these documents have been posted for your reading pleasure, reflecting comments and discussions on this list (and some private correspondence about editorial issues) today. john From discuss-bounces@apps.ietf.org Fri Oct 05 20:31:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdxZQ-00077w-2z; Fri, 05 Oct 2007 20:31:04 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IdxZO-00077E-Oc for discuss-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 20:31:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdxZO-000776-Ez for discuss@apps.ietf.org; Fri, 05 Oct 2007 20:31:02 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdxZI-00037l-5r for discuss@apps.ietf.org; Fri, 05 Oct 2007 20:31:02 -0400 Received: from [192.168.0.2] (adsl-67-127-184-122.dsl.pltn13.pacbell.net [67.127.184.122]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l960UOSW005699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Oct 2007 17:30:24 -0700 Message-ID: <4706D71E.1060508@dcrocker.net> Date: Fri, 05 Oct 2007 17:30:22 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Apps Discuss Subject: Re: Use of LWSP in ABNF -- consensus call References: <46F545F1.1010806@bbiw.net> In-Reply-To: <46F545F1.1010806@bbiw.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: Paul Overell X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Folks, The consensus call that I issued 2 weeks ago received a few responses. All were supportive of the change, with only one request for changing a single word and one weak vote in favor of that change. My own view is that the change is not essential and is not supported strongly enough to warrant making the change and then re-querying for support of the revision. So I'll add the proposed text to the draft and we'll see whether that gets the Discuss removed. d/ Dave Crocker wrote: > > > On 5/14/2007 Lisa Dusseault wrote: > >> The IESG reviewed >> >> for publication as Internet Standard and would like to know if there >> is consensus to recommend against the use of LWSP in future >> specifications, as it has caused problems recently in DKIM and could >> cause problems in other places. >> >> Some discussion on this point already: >> - http://www1.ietf.org/mail-archive/web/ietf/current/msg46048.html >> - http://www1.ietf.org/mail-archive/web/discuss/current/msg00463.html >> - http://mipassoc.org/pipermail/ietf-dkim/2007q1/007295.html >> - >> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=66440 >> (in this tracker comment, Chris Newman recommended to remove LWSP, but >> for backward-compatibility it's probably better to keep it and >> recommend against use) > > > Folks, > > The current situation with elevating the ABNF document to full Internet > Standard is that Lisa has a Discuss hold on it, on behalf of an IESG > view that a warning note should be attached. > > Acting as an individual contributor, Chris Newman has offered the > following change to the document, as a possible means of resolving things: > > >> OLD: >> LWSP = *(WSP / CRLF WSP) >> ; linear white space (past newline) >> NEW: >> LWSP = *(WSP / CRLF WSP) >> ; Use of this linear-white-space rule permits >> ; lines containing only white space that are no >> ; longer legal in mail headers and have caused >> ; interoperability problems in other contexts. >> ; Do not use when defining mail headers and use >> ; with caution in other contexts. > > > The nature of the IETF process is such that there are no guarantees for > what will resolve a Discuss, but the signs are good that a consensus on > this list, for a note of this type, will suffice. > > The premise is that the discussion on this list, last May, had consensus > to retain the LWSP construct and consensus to add a warning. The text > that Chris is suggesting seems to accomplish this. > > In spite of saying "Do not use", the comment is non-normative, in formal > IETF specification terms. Yet it does seem to adequately describe the > problem and the way to deal with it. > > > > So, I'm going to ask for a consensus call on this > modification, where the assumption is that the text > is acceptable. > > All that is needed is for folk who *object* to speak up > and state their reasons. > > If there is consensus *against* this change, we'll have to > try something else. > > Absent a consensus *against* the wording change, we will > propose it to Lisa and see if that resolves her Discuss. > > This consensus call closes on Sunday, 30 September. > > > Thanks. > > d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From discuss-bounces@apps.ietf.org Sat Oct 06 00:21:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ie19n-00048N-GM; Sat, 06 Oct 2007 00:20:51 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ie19m-00045Z-4M for discuss-confirm+ok@megatron.ietf.org; Sat, 06 Oct 2007 00:20:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ie19l-00045R-Jw for discuss@apps.ietf.org; Sat, 06 Oct 2007 00:20:49 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ie19f-0008EW-DH for discuss@apps.ietf.org; Sat, 06 Oct 2007 00:20:49 -0400 X-IronPort-AV: E=Sophos;i="4.21,238,1188770400"; d="scan'208";a="155060333" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 06 Oct 2007 06:20:10 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l964K7dq028655; Sat, 6 Oct 2007 06:20:07 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp52.cisco.com [10.61.64.52]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l964JqbR026317; Sat, 6 Oct 2007 04:20:03 GMT Message-ID: <47070CCB.9040202@cisco.com> Date: Sat, 06 Oct 2007 06:19:23 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: Lisa's Apps Area Activity for Sept 2007 References: <5E1B7B04-DAFE-41DC-ABE4-3575A646519F@osafoundation.org> In-Reply-To: <5E1B7B04-DAFE-41DC-ABE4-3575A646519F@osafoundation.org> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=777; t=1191644407; x=1192508407; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20Lisa's=20Apps=20Area=20Activity=20for=20Sept=202007 |Sender:=20; bh=/3JIqSkgWBxRoIvjR78h1YmuKQz/GmPdEC/yzCh9NNE=; b=msDmOLOQmKCw3dPKvOqch/P7dxMF5NSly8ZKQIJBERP/N0L4mZVnvqxYHzT47tflsOj3JrTH AsMK8g3MYfQV5JVV7TU/EojAbe4psJQUJdXOw0z6btQklpe3cXw1Y/fl; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Apps Discuss , Lisa Dusseault's Chairs X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi Lisa, > > - CALSIFY chugging through issues -- chairs declared RFC2445bis > "closed" for new issues Just a bit more detail here. RFC2445bis is pretty much baked. We may have one issue open, and we will accept a small number of changes based on work that is now proceeding on RFC2446bis. RFC2446bis now has a list of open issues that can be found in our tracker, http://www.ofcourseimright.com/cgi-bin/roundup/calsify. Now is the time to add issues, as we will be closing that queue Real Soon Now. On RFC2446bis, we have a number of proposals to deprecate various components, including SEQUENCE. This is stirring some debate. Now is the time to participate in that debate. The mailing list is ietf-calsify@osafoundation.org. Thanks, Eliot From discuss-bounces@apps.ietf.org Sat Oct 06 01:31:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ie2EQ-0000sW-QU; Sat, 06 Oct 2007 01:29:42 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ie2EQ-0000of-4Y for discuss-confirm+ok@megatron.ietf.org; Sat, 06 Oct 2007 01:29:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ie2EP-0000dq-BN for discuss@apps.ietf.org; Sat, 06 Oct 2007 01:29:41 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ie2EG-0001QD-QS for discuss@apps.ietf.org; Sat, 06 Oct 2007 01:29:39 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l965TJiQ009776 for ; Sat, 6 Oct 2007 14:29:19 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 2d31_1612d8ee_73cd_11dc_8908_0014221fa3c9; Sat, 06 Oct 2007 14:29:18 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:45345) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 6 Oct 2007 14:25:29 +0900 Message-Id: <6.0.0.20.2.20071006120622.0a6d4b10@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 06 Oct 2007 12:12:17 +0900 To: John C Klensin , Stephane Bortzmeyer From: Martin Duerst Subject: Re: Form feed in Net-UTF8? (Was: FWD: Re: Comments onUnicode Format for Network Interchange In-Reply-To: References: <398A6C120C8B166FCBD3BDAF@p3.JCK.COM> <20071005151227.GA31232@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org FF is a tricky one. It's definitely used in RFCs, and can be helpful for printing (although less and less so). But in a protocol context, where pages are nonexisting, it will only cause trouble. So I'd suggest that the SHOULD NOT is kept, but give a bit more detail. For some shot at wording, I'd change: "SHOULD NOT be used unless required by exceptional circumstances" to something like: "SHOULD NOT be used unless the protocol or format has a need to express page breaks in plain text (as e.g. done in the format for RFCs)." Regards, Martin. At 00:57 07/10/06, John C Klensin wrote: > > >--On Friday, 05 October, 2007 17:12 +0200 Stephane Bortzmeyer > wrote: > >> Doug Ewell said: >> >>> > I recommend that the control code FF (form feed, U+000C) be >>> > likewise permitted. The form feed function is well known >>> > and well defined in almost all printing functions, and all >>> > RFCs issued in modern times use FF to separate pages. It >>> > would ironic indeed for the Internet-Draft to retain the >>> > requirement that form feeds "SHOULD NOT be used unless >>> > required by exceptional circumstances" while advancing >>> > toward publication as an RFC, complete with form feeds! >> >> And I did not see anywhere a discussion of this specific >> point. I notice that draft-klensin-net-utf8-04 still disallows >> (actually, it is a SHOULD NOT in section 2.1) form feeds and >> I'm not sure of the rationale. Why end-of-lines and not >> end-of-pages? > >Because line breaks are required even for unformatted streams. >FormFeeds are not. > >But I find the above arguments reasonably persuasive and will >put FF back in unless others feel strongly about this. > > john #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From discuss-bounces@apps.ietf.org Sat Oct 06 03:33:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ie47U-00033n-GI; Sat, 06 Oct 2007 03:30:40 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ie47T-00033f-KH for discuss-confirm+ok@megatron.ietf.org; Sat, 06 Oct 2007 03:30:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ie47O-00033K-GV for discuss@apps.ietf.org; Sat, 06 Oct 2007 03:30:34 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ie47I-0004Lr-0z for discuss@apps.ietf.org; Sat, 06 Oct 2007 03:30:34 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l967UJDC002577 for ; Sat, 6 Oct 2007 16:30:19 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 2d33_fd8c0e4c_73dd_11dc_9b03_0014221fa3c9; Sat, 06 Oct 2007 16:30:19 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:60019) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 6 Oct 2007 16:26:57 +0900 Message-Id: <6.0.0.20.2.20071006143908.0a6dcec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 06 Oct 2007 14:40:01 +0900 To: Lisa Dusseault , Apps Discuss , "Lisa Dusseault's Chairs" From: Martin Duerst Subject: Re: Lisa's Apps Area Activity for Sept 2007 In-Reply-To: <5E1B7B04-DAFE-41DC-ABE4-3575A646519F@osafoundation.org> References: <5E1B7B04-DAFE-41DC-ABE4-3575A646519F@osafoundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org At 09:01 07/10/06, Lisa Dusseault wrote: >WG Status > - IMAPEXT stalled waiting for i18n work to complete Any info on what kind of i18n work that is? Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From discuss-bounces@apps.ietf.org Sat Oct 06 04:18:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ie4rC-0003Q5-Gz; Sat, 06 Oct 2007 04:17:54 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ie4rB-0003Oy-0A for discuss-confirm+ok@megatron.ietf.org; Sat, 06 Oct 2007 04:17:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ie4rA-0003Oq-Mu for discuss@apps.ietf.org; Sat, 06 Oct 2007 04:17:52 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ie4r5-0005dZ-5t for discuss@apps.ietf.org; Sat, 06 Oct 2007 04:17:52 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Ie4qu-000AYA-Ey; Sat, 06 Oct 2007 04:17:36 -0400 Date: Sat, 06 Oct 2007 04:17:35 -0400 From: John C Klensin To: Martin Duerst , Stephane Bortzmeyer Subject: Re: Form feed in Net-UTF8? (Was: FWD: Re: Comments onUnicode Format for Network Interchange Message-ID: <16279928490191A12E3B99E8@p3.JCK.COM> In-Reply-To: <6.0.0.20.2.20071006120622.0a6d4b10@localhost> References: <398A6C120C8B166FCBD3BDAF@p3.JCK.COM> <20071005151227.GA31232@nic.fr> <6.0.0.20.2.20071006120622.0a6d4b10@localhost> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Saturday, 06 October, 2007 12:12 +0900 Martin Duerst wrote: > FF is a tricky one. It's definitely used in RFCs, and can > be helpful for printing (although less and less so). But > in a protocol context, where pages are nonexisting, it will > only cause trouble. So I'd suggest that the SHOULD NOT is kept, > but give a bit more detail. For some shot at wording, I'd > change: > > "SHOULD NOT be used unless required by exceptional > circumstances" > > to something like: > > "SHOULD NOT be used unless the protocol or format has a need > to express page breaks in plain text (as e.g. done in the > format for RFCs)." Martin, since I already shipped -05 and, thanks to the new automated system, it has been posted, please see how you like the treatment there. I think we agree on the principles, so would welcome suggestions for further tuning. While I could live with the text you propose above, it seems to me to lead onto a slippery slope. Try substituting, for "page breaks" above, terms like "alert sounds", "visual emphasis such as highlighting or colored characters", or "flashing lines". FormFeeds are much more frequent in text, and do appear in RFCs, but the principles are, I think, the same. john From discuss-bounces@apps.ietf.org Sun Oct 07 16:18:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IecXJ-00049o-Rj; Sun, 07 Oct 2007 16:15:37 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IeCaj-0000Ix-W9 for discuss-confirm+ok@megatron.ietf.org; Sat, 06 Oct 2007 12:33:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeCaj-0000BS-2I for discuss@apps.ietf.org; Sat, 06 Oct 2007 12:33:25 -0400 Received: from 74-134-5-162.dhcp.insightbb.com ([74.134.5.162] helo=episteme-software.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IeCaX-00011l-TW for discuss@apps.ietf.org; Sat, 06 Oct 2007 12:33:20 -0400 Received: from [74.134.5.163] (127.0.0.1) by episteme-software.com with ESMTP (EIMS X 3.3.2); Sat, 6 Oct 2007 11:32:51 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <6.0.0.20.2.20071006143908.0a6dcec0@localhost> References: <5E1B7B04-DAFE-41DC-ABE4-3575A646519F@osafoundation.org> <6.0.0.20.2.20071006143908.0a6dcec0@localhost> User-Agent: Eudora 6.2.5b1(Macintosh) Date: Sat, 6 Oct 2007 11:32:41 -0500 To: Martin Duerst From: Pete Resnick Subject: Re: Lisa's Apps Area Activity for Sept 2007 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 1.7 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-Mailman-Approved-At: Sun, 07 Oct 2007 16:15:36 -0400 Cc: Apps Discuss , Lisa Dusseault's Chairs X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 10/6/07 at 2:40 PM +0900, Martin Duerst wrote: >Any info on what kind of i18n work that is? http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-12.txt Our document editor was out sick for a bit. After he address a couple of WG LC comments, we're sending it out for IETF-wide Last Call. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From discuss-bounces@apps.ietf.org Sun Oct 07 16:39:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IectZ-0004xu-3q; Sun, 07 Oct 2007 16:38:37 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IectY-0004xR-Be for discuss-confirm+ok@megatron.ietf.org; Sun, 07 Oct 2007 16:38:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IectY-0004x4-25 for discuss@apps.ietf.org; Sun, 07 Oct 2007 16:38:36 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IectR-0000Gn-Om for discuss@apps.ietf.org; Sun, 07 Oct 2007 16:38:36 -0400 Received: from [10.6.159.200] (72-255-35-134.client.stsn.net [72.255.35.134]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l97Kbsmq001765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 7 Oct 2007 13:37:56 -0700 Message-ID: <4708F8DD.2010706@dcrocker.net> Date: Sun, 07 Oct 2007 08:18:53 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: discuss@apps.ietf.org Subject: Re: Form feed in Net-UTF8? (Was: FWD: Re: Comments onUnicode Format for Network Interchange References: <398A6C120C8B166FCBD3BDAF@p3.JCK.COM> <20071005151227.GA31232@nic.fr> <6.0.0.20.2.20071006120622.0a6d4b10@localhost> <16279928490191A12E3B99E8@p3.JCK.COM> In-Reply-To: <16279928490191A12E3B99E8@p3.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.4 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org John C Klensin wrote: > While I could live with the text you propose above, it seems to > me to lead onto a slippery slope. Try substituting, for "page > breaks" above, terms like "alert sounds", "visual emphasis such > as highlighting or colored characters", or "flashing lines". > FormFeeds are much more frequent in text, and do appear in RFCs, > but the principles are, I think, the same. Seems like the discussion is really distinguishing among different classes of use, where each might be labeled distinctly and have variants of permitted characters. (I'm not expressing an opinion about whether this is a good thing to do, but merely noting that I think it is what is driving the discussion. So the set for "data stream", such as protocol commands, needs minimal format effectors. Whereas "document stream" probably needs all the format effectors and other visual indicators. The reference to beeps suggests another role, which I suppose is a superset of format effectors and might be classed as "user interface" or somesuch. Mumble... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From discuss-bounces@apps.ietf.org Mon Oct 08 05:30:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ieouh-0000jI-69; Mon, 08 Oct 2007 05:28:35 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ieoug-0000ic-3T for discuss-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 05:28:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ieouf-0000iU-QH for discuss@apps.ietf.org; Mon, 08 Oct 2007 05:28:33 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ieoue-0008PO-J1 for discuss@apps.ietf.org; Mon, 08 Oct 2007 05:28:33 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 80F5F1C009B; Mon, 8 Oct 2007 11:28:31 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 7B6D01C0090; Mon, 8 Oct 2007 11:28:31 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 7528B58ECC6; Mon, 8 Oct 2007 11:28:31 +0200 (CEST) Date: Mon, 8 Oct 2007 11:28:31 +0200 From: Stephane Bortzmeyer To: John C Klensin Subject: Re: Form feed in Net-UTF8? (Was: FWD: Re: Comments on Unicode Format for Network Interchange Message-ID: <20071008092831.GA31185@nic.fr> References: <398A6C120C8B166FCBD3BDAF@p3.JCK.COM> <20071005151227.GA31232@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071005151227.GA31232@nic.fr> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Fri, Oct 05, 2007 at 05:12:27PM +0200, Stephane Bortzmeyer wrote a message of 18 lines which said: > I notice that draft-klensin-net-utf8-04 still disallows (actually, > it is a SHOULD NOT in section 2.1) form feeds and I'm not sure of > the rationale. Why end-of-lines and not end-of-pages? The new text in -05 is fine for me: Other than CR, LF, Space (SP, U+0020), and, with caution, FF (U+000C), control characters (U+0000 to U+001F and U+007F to U+009F) SHOULD generally be avoided. FF should be used only with caution: if its use assumes a page length, such assumptions may not be appropriate in international contexts (e.g., considering 8.5x11 inch paper versus A4). Other control characters are used to affect display format, control devices, or to structure files. None of those uses is appropriate for streams of plain text. In particular, the so-called "C1 Controls" (U+0080 through U+009F) MUST NOT appear. From discuss-bounces@apps.ietf.org Mon Oct 08 05:33:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeozQ-0007G3-Dw; Mon, 08 Oct 2007 05:33:28 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IeozP-0007FC-AB for discuss-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 05:33:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeozP-0007F4-0U for discuss@apps.ietf.org; Mon, 08 Oct 2007 05:33:27 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IeozI-00006q-Ky for discuss@apps.ietf.org; Mon, 08 Oct 2007 05:33:26 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ieoyt-0005gE-9d for discuss@apps.ietf.org; Mon, 08 Oct 2007 09:32:55 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Oct 2007 09:32:55 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Oct 2007 09:32:55 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: discuss@apps.ietf.org From: "Frank Ellermann" Subject: Re: draft-klensin-unicode-escapes-05 and draft-klensin-net-utf8-05 Date: Mon, 8 Oct 2007 11:30:03 +0200 Lines: 150 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org John C Klensin wrote: > New versions of these documents have been posted for your > reading pleasure The unicode-escapes-05 are fine. One observation: In 5.2 you mention how to encode a literal '&' as "&", that's enough to solve all issues with literal "&#x" constructs. In section 5.1 you don't mention a similar trick for "\u'" constructs, and "implementors" (i.e. protocol designers) might pick some '\\' convention to get a literal '\'. Is that as it should be? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D In net-utf8-05 2.1 I'm not sure about this recommendation: | CR SHOULD NOT appear except when followed by LF. There's no similar statement about a bare LF. If you want to permit bare LF for cursor control on dumb terminals, then you could also permit bare CR for this purpose. =20 If you want to prohibit bare CR as "line ending" (the topic of item 2 in section 2.1), then you could also prohibit a bare LF for this purpose, maybe you could also mention NEL. Combined with item 3 in 2.1 I think what you really want is to ban both bare CR _and_ bare LF, something like this: | CR SHOULD NOT appear except when followed by LF, and v.v. In 2.1 item 3 please s/FF/Formfeed/ and simplify this part: "FF should be used only with caution: if its use assumes a page length, such assumptions may not be appropriate in international contexts (e.g., considering 8.5x11 inch paper versus A4)". There's more about this (fonts, font sizes), you could simply state: "Formfeeds should be used only with caution, e.g. in legacy formats like Internet Drafts". At the end of 2.1 you use a "MUST NOT" about the CR. Either it's MUST NOT or SHOULD NOT. ITYM the latter, otherwise the following CR NUL "SHOULD" makes no=20 sense (for me). =20 There's no section 2.2 and no intro before section=20 2.1, please get rid of the unused subsection title. Section 3: | The section above requires that all Net-Unicode | strings be transmitted in normalized form. s/requires/recommends/ (SHOULD in 2.1 item 4) Section 4: | The normalization specified here, NFC s/specified/recommended/ (you don't specify NFC, section 3 explicitly says that NFC is specified by Unicode in UAX #15). Section 5.2: | IETF Standard UTF-8 is dependent on some definitions | not changing after Unicode Version 4.0. I'm not aware of such dependencies. UTF-8 depends on=20 two points: The will to limit Unicode to 21 bits, and=20 the will to outlaw "overlong" encodings. Both points are guaranteed in STD 63, they don't depend on anything defined by say UTC. The complete IDNA issue is IMO unrelated to "net-utf8". I'd delete the complete section 5.2, rewrite it from scratch, or something. =20 Appendix A: s/2068/2616/ or s/2068/1945/ (?) ITYM 1945 HTTP/1.0. Back to section 2.1: Before discussing FF (Formfeed) at all you should talk about HT. Many decent protocols use WSP as defined in the future ABNF 4234bis standard, i.e. SP or HT. Frank =20 =20 =20 From discuss-bounces@apps.ietf.org Mon Oct 08 05:52:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IepH8-00068r-4j; Mon, 08 Oct 2007 05:51:46 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IepH7-00061g-B8 for discuss-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 05:51:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IepH7-0005zc-0u for discuss@apps.ietf.org; Mon, 08 Oct 2007 05:51:45 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IepH5-0000ak-RH for discuss@apps.ietf.org; Mon, 08 Oct 2007 05:51:45 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 7C2BC1C0105; Mon, 8 Oct 2007 11:51:43 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 77DD01C008E; Mon, 8 Oct 2007 11:51:43 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 6B07958ECC6; Mon, 8 Oct 2007 11:51:43 +0200 (CEST) Date: Mon, 8 Oct 2007 11:51:43 +0200 From: Stephane Bortzmeyer To: Frank Ellermann Subject: Re: draft-klensin-unicode-escapes-05 and draft-klensin-net-utf8-05 Message-ID: <20071008095143.GA1139@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, Oct 08, 2007 at 11:30:03AM +0200, Frank Ellermann wrote a message of 150 lines which said: > The complete IDNA issue is IMO unrelated to "net-utf8". I'd delete > the complete section 5.2, rewrite it from scratch, or something. +++1 From discuss-bounces@apps.ietf.org Mon Oct 08 06:06:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IepUS-0007Xo-DN; Mon, 08 Oct 2007 06:05:32 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IepUQ-0007SJ-Ic for discuss-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 06:05:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IepUQ-0007SB-6e for discuss@apps.ietf.org; Mon, 08 Oct 2007 06:05:30 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IepUP-0000vE-0O for discuss@apps.ietf.org; Mon, 08 Oct 2007 06:05:30 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 9D6C71C010E for ; Mon, 8 Oct 2007 12:05:28 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 980A31C0105 for ; Mon, 8 Oct 2007 12:05:28 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 89E5158ECCE for ; Mon, 8 Oct 2007 12:05:28 +0200 (CEST) Date: Mon, 8 Oct 2007 12:05:28 +0200 From: Stephane Bortzmeyer To: discuss@apps.ietf.org Subject: Re: I-D Action:draft-klensin-unicode-escapes-05.txt Message-ID: <20071008100528.GA2772@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Fri, Oct 05, 2007 at 07:40:02PM -0400, Internet-Drafts@ietf.org wrote a message of 96 lines which said: > Title : ASCII Escaping of Unicode Characters > Author(s) : J. Klensin > Filename : draft-klensin-unicode-escapes-05.txt I have read and studied this I-D and I find it basically OK, suitable for approval and very useful for the Internet, where internationalization is an important issue. As noted by the draft, using a standard Unicode encoding such as UTF-8 would be better, but there are cases when it is impractical and this draft provides a nice solution for these cases. From discuss-bounces@apps.ietf.org Mon Oct 08 06:08:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IepX2-0000l8-9A; Mon, 08 Oct 2007 06:08:12 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IepX1-0000l1-Ao for discuss-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 06:08:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IepX1-0000kt-1E for discuss@apps.ietf.org; Mon, 08 Oct 2007 06:08:11 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IepWz-00011U-RQ for discuss@apps.ietf.org; Mon, 08 Oct 2007 06:08:11 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 7CEF21C010F; Mon, 8 Oct 2007 12:08:09 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 785501C0105; Mon, 8 Oct 2007 12:08:09 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 752D358ECCE; Mon, 8 Oct 2007 12:08:09 +0200 (CEST) Date: Mon, 8 Oct 2007 12:08:09 +0200 From: Stephane Bortzmeyer To: Frank Ellermann Subject: Re: draft-klensin-unicode-escapes-05 and draft-klensin-net-utf8-05 Message-ID: <20071008100809.GA3118@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, Oct 08, 2007 at 11:30:03AM +0200, Frank Ellermann wrote a message of 150 lines which said: > In section 5.1 you don't mention a similar trick for "\u'" > constructs, and "implementors" (i.e. protocol designers) > might pick some '\\' convention to get a literal '\'. Is > that as it should be? It seems well-covered in the current draft: > Since this specification does not recommend one specific syntax, > protocols specifications that use escapes MUST define the syntax > they are using, including any necessary escapes to permit the escape > sequence to be used literally. [...] > In addition, when an escape is needed for the escape mechanism > itself, the optimal one of those might differ from one context to > another. I would have preferred an official recommandation but it seems there is no consensus for one specific 'escape the escape' format. From discuss-bounces@apps.ietf.org Mon Oct 08 07:56:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IerDP-0000GF-J8; Mon, 08 Oct 2007 07:56:03 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IerDN-0000G6-Ec for discuss-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 07:56:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IerDN-0000Fc-4Y for discuss@apps.ietf.org; Mon, 08 Oct 2007 07:56:01 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IerDL-0004FS-TH for discuss@apps.ietf.org; Mon, 08 Oct 2007 07:56:01 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IerD7-0002WO-Dx for discuss@apps.ietf.org; Mon, 08 Oct 2007 11:55:45 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Oct 2007 11:55:45 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Oct 2007 11:55:45 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: discuss@apps.ietf.org From: "Frank Ellermann" Subject: Re: draft-klensin-unicode-escapes-05 and draft-klensin-net-utf8-05 Date: Mon, 8 Oct 2007 13:53:01 +0200 Lines: 8 Message-ID: References: <20071008100809.GA3118@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: -0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Stephane Bortzmeyer wrote: =20 > It seems well-covered in the current draft ACK, I forgot the overall clause in section 4 when I looked at the 5.1 and 5.2 details. Frank From discuss-bounces@apps.ietf.org Mon Oct 08 10:17:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IetOL-00036D-BX; Mon, 08 Oct 2007 10:15:29 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IetOJ-00035s-M8 for discuss-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 10:15:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IetOJ-00030x-58 for discuss@apps.ietf.org; Mon, 08 Oct 2007 10:15:27 -0400 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IetO8-0000Ye-Sm for discuss@apps.ietf.org; Mon, 08 Oct 2007 10:15:23 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id l98EErjP015161Mon, 8 Oct 2007 14:14:53 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1IetNl-000L9N-00; Mon, 08 Oct 2007 15:14:53 +0100 Date: Mon, 8 Oct 2007 15:14:53 +0100 From: "Clive D.W. Feather" To: Stephane Bortzmeyer Subject: Re: draft-klensin-unicode-escapes-05 and draft-klensin-net-utf8-05 Message-ID: <20071008141452.GK71445@finch-staff-1.thus.net> References: <20071008100809.GA3118@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071008100809.GA3118@nic.fr> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Frank Ellermann , discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Stephane Bortzmeyer said: >> In section 5.1 you don't mention a similar trick for "\u'" >> constructs, and "implementors" (i.e. protocol designers) >> might pick some '\\' convention to get a literal '\'. Is >> that as it should be? > > It seems well-covered in the current draft: > >> Since this specification does not recommend one specific syntax, >> protocols specifications that use escapes MUST define the syntax >> they are using, including any necessary escapes to permit the escape >> sequence to be used literally. > I would have preferred an official recommandation but it seems there > is no consensus for one specific 'escape the escape' format. However, since we're mentioning "&" as *a* syntax that always works, even though the more usual approach is "&", I think for completeness we should mention "\u'005C'" as *a* guaranteed way of getting a backslash, even if "\\" is more usual. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | From discuss-bounces@apps.ietf.org Mon Oct 08 10:20:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IetSd-0002gZ-FN; Mon, 08 Oct 2007 10:19:55 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IetSc-0002XR-2k for discuss-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 10:19:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IetSb-0002XJ-PM for discuss@apps.ietf.org; Mon, 08 Oct 2007 10:19:53 -0400 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IetSa-0000gx-GN for discuss@apps.ietf.org; Mon, 08 Oct 2007 10:19:53 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id l98EJkdR021671Mon, 8 Oct 2007 14:19:46 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1IetSU-000LHn-00; Mon, 08 Oct 2007 15:19:46 +0100 Date: Mon, 8 Oct 2007 15:19:46 +0100 From: "Clive D.W. Feather" To: John C Klensin Subject: Re: draft-klensin-unicode-escapes-05 and draft-klensin-net-utf8-05 Message-ID: <20071008141946.GL71445@finch-staff-1.thus.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org John C Klensin said: > > New versions of these documents have been posted for your > reading pleasure, reflecting comments and discussions on this > list (and some private correspondence about editorial issues) > today. unicode-escapes section 7 has a spurious closing double quote. Appendix A.1., comment after "BMP-form", what does "the one above" refer to? Nitpick: some slashes in the definition of HEXDIG have a space before them and some don't. You've also got two spaces after some = and three after others. You don't have an A.3 for Java. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | From discuss-bounces@apps.ietf.org Mon Oct 08 12:41:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ievey-0002Fw-N2; Mon, 08 Oct 2007 12:40:48 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ievey-0002Fq-2J for discuss-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 12:40:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ievex-00027S-OP for discuss@apps.ietf.org; Mon, 08 Oct 2007 12:40:47 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ieveh-0004mp-ND for discuss@apps.ietf.org; Mon, 08 Oct 2007 12:40:39 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id ECF832FA; Mon, 8 Oct 2007 12:40:11 -0400 (EDT) Received: from MCQWP2 (ip72-197-112-82.sd.sd.cox.net [72.197.112.82]) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 9AF7286B7F; Mon, 8 Oct 2007 12:40:08 -0400 (EDT) Date: Mon, 8 Oct 2007 09:39:45 -0700 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <29932517.20071008093945@pobox.com> To: Apps-Discusssion Subject: Re: Form feed in Net-UTF8? (Was: FWD: Re: Comments onUnicode Format for Network Interchange In-Reply-To: <4708F8DD.2010706@dcrocker.net> References: <398A6C120C8B166FCBD3BDAF@p3.JCK.COM> <20071005151227.GA31232@nic.fr> <6.0.0.20.2.20071006120622.0a6d4b10@localhost> <16279928490191A12E3B99E8@p3.JCK.COM> <4708F8DD.2010706@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Sun, 2007-10-07, Dave Crocker wrote: > John C Klensin wrote: >> While I could live with the text you propose above, it seems to >> me to lead onto a slippery slope. Try substituting, for "page >> breaks" above, terms like "alert sounds", "visual emphasis such >> as highlighting or colored characters", or "flashing lines". >> FormFeeds are much more frequent in text, and do appear in RFCs, >> but the principles are, I think, the same. > Seems like the discussion is really distinguishing among different classes of > use, where each might be labeled distinctly and have variants of permitted > characters. It seems to me that this draft is trying to cover two separate areas of concern: 1 - How to express information (UTF-8, NFC, CRLF line-endings, no BOM). 2 - What information to express. Is it necessary to tell prospective users of Network Text which characters are allowed for their application? Wouldn't it be simplier to merely specify the encoding to be used and then mention that use of things like control characters should be specified within the protocol definition? Since the use of "text" occurs in many varied contexts, not all of which are merely for display, I think that alerting users to the problems of control characters and making it their responsibility to address them is sufficient. -- Bill McQuillan From discuss-bounces@apps.ietf.org Mon Oct 08 12:43:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ievh6-0003fA-Fc; Mon, 08 Oct 2007 12:43:00 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ievh5-0003ev-2X for discuss-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 12:42:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ievh4-0003el-PE for discuss@apps.ietf.org; Mon, 08 Oct 2007 12:42:58 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ievgy-0004r0-E5 for discuss@apps.ietf.org; Mon, 08 Oct 2007 12:42:58 -0400 Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1Ievgo-000OWl-Ue; Mon, 08 Oct 2007 12:42:43 -0400 Date: Mon, 08 Oct 2007 12:42:41 -0400 From: John C Klensin To: "Clive D.W. Feather" Subject: Re: draft-klensin-unicode-escapes-05 and draft-klensin-net-utf8-05 Message-ID: <40631CD1A59A65DA1B88F394@[192.168.1.110]> In-Reply-To: <20071008141946.GL71445@finch-staff-1.thus.net> References: <20071008141946.GL71445@finch-staff-1.thus.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Monday, October 08, 2007 3:19 PM +0100 "Clive D.W. Feather" wrote: > John C Klensin said: >> >> New versions of these documents have been posted for your >> reading pleasure, reflecting comments and discussions on this >> list (and some private correspondence about editorial issues) >> today. > > unicode-escapes section 7 has a spurious closing double quote. Will check on this. > Appendix A.1., comment after "BMP-form", what does "the one > above" refer to? Probably the result of pulling that text out to a separate section. Will check. > Nitpick: some slashes in the definition of HEXDIG have a space > before them and some don't. You've also got two spaces after > some = and three after others. If the RFC Editor thinks this is important, I'm sure they will fix it. > You don't have an A.3 for Java. Because there was no specific syntax in the last draft that had the syntax in line. Re the FF and CR discussions: please understand that, if one were able to erase the entire history of text on the network and start over today, one might reasonably do something different. Or one might not. But, because this whole business is intended for untagged text, making incompatible changes in interpretation of strings is just not, IMO, a plausible option. CR was discussed more intensely in the net-utf8 draft because it is discussed more intensely in the NVT / Net-ASCII documents. Bare LF was discussed less because it wasn't considered much of an issue and because the negative effects of interpreting it differently than the sender intended were much less severe (e.g., one-line vertical indexing versus NewLine) than the consequences of getting the interpretation of bare CR wrong (NewLine versus overstriking). Anyone who has seen a terminal or other display render bare-LF text like this versus having lines overstuck or, worse, rewritten multiple times with each one being quickly erased, should understand this immediately. The LF case is readable, if annoying, and the source of the problem is almost immediately clear. The CR case obscures text: on a fast enough device, or on a system that canonicalizes before transmitting, one ends up looking only at the last line of a paragraph and has to guess what might have happened. I could try to incorporate a little more text along those lines in the document, but please remember that it has already been criticized for containing too much history and explanation rather than just laying out the rules. General comment on these two documents. In both cases, I started them because it appeared that they would be useful to the community. I am not strongly committed to them and my patience for nitpicking has just reached zero. So, I will generate -06 drafts if they are really needed, but that is it: if the community, or selected individuals, want the quest for perfection to drive out the opportunity to have something useful (but probably imperfect), this is your opportunity. Or, if there is someone who has more patience and time than I do who would like to take over and polish them to a high luster, please let me know. john From discuss-bounces@apps.ietf.org Mon Oct 08 13:04:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iew1F-0002Yq-Il; Mon, 08 Oct 2007 13:03:49 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Iew1F-0002YW-2M for discuss-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 13:03:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iew1E-0002Xy-OM for discuss@apps.ietf.org; Mon, 08 Oct 2007 13:03:48 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iew1D-00066D-Cc for discuss@apps.ietf.org; Mon, 08 Oct 2007 13:03:48 -0400 Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1Iew1C-000OwW-MX; Mon, 08 Oct 2007 13:03:47 -0400 Date: Mon, 08 Oct 2007 13:03:45 -0400 From: John C Klensin To: Bill McQuillan Subject: Re: Form feed in Net-UTF8? (Was: FWD: Re: Comments onUnicode Format for Network Interchange Message-ID: <18BEB54BDA79DAB1880CBBCE@[192.168.1.110]> In-Reply-To: <29932517.20071008093945@pobox.com> References: <398A6C120C8B166FCBD3BDAF@p3.JCK.COM> <20071005151227.GA31232@nic.fr> <6.0.0.20.2.20071006120622.0a6d4b10@localhost> <16279928490191A12E3B99E8@p3.JCK.COM> <4708F8DD.2010706@dcrocker.net> <29932517.20071008093945@pobox.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Apps-Discusssion X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Monday, October 08, 2007 9:39 AM -0700 Bill McQuillan wrote: > > On Sun, 2007-10-07, Dave Crocker wrote: >> John C Klensin wrote: >>> While I could live with the text you propose above, it seems >>> to me to lead onto a slippery slope. Try substituting, for >>> "page breaks" above, terms like "alert sounds", "visual >>> emphasis such as highlighting or colored characters", or >>> "flashing lines". FormFeeds are much more frequent in text, >>> and do appear in RFCs, but the principles are, I think, the >>> same. >> Seems like the discussion is really distinguishing among >> different classes of use, where each might be labeled >> distinctly and have variants of permitted characters. > > It seems to me that this draft is trying to cover two separate > areas of concern: > > 1 - How to express information (UTF-8, NFC, CRLF line-endings, > no BOM). > > 2 - What information to express. > > Is it necessary to tell prospective users of Network Text > which characters are allowed for their application? Wouldn't > it be simplier to merely specify the encoding to be used and > then mention that use of things like control characters should > be specified within the protocol definition? > > Since the use of "text" occurs in many varied contexts, not > all of which are merely for display, I think that alerting > users to the problems of control characters and making it > their responsibility to address them is sufficient. Bill, Dave, To me, the purpose of trying to develop an IETF specification is to promote interoperability. If you send me encoded characters that I don't know how to interpret, or don't reliably know how you intend that I interpret, we have an interoperability problem. That problem may be more or less severe depending on the range of possible interpretations and their consequences. The reason this document was developed was to reduce those interoperability problems and also to reduce the number of "N-squared" problems in which my receiving system is expected to understand all of the possible formats and interpretations that other systems can send out, even if they are explicitly identified. I hope it is obvious that, if one identifies each body of text, in-band, with a description of what characters are used and how they are to be interpreted, then the net-utf8 format is not needed. Everything that is needed is in the UTF8 and Unicode specs themselves. I assume it is equally obvious that it makes little difference --at least to the utility of this spec-- whether such a description is explicit and local or provided in the form of some label that points to an external definition of a class of characters. It seems to me that we have three plausible paths from here: (1) Go ahead with net-Unicode (net-utf8), with the understanding that some protocols and contexts will find it useful and others won't. (2) Try to insist that every protocol that transmits Unicode "plain-text" explicitly identifies the forms it is using (or the category to which it belongs, after defining those categories). (3) Decide that interoperability of text interpretation is not an issue and just drop these ideas. john From discuss-bounces@apps.ietf.org Tue Oct 09 05:46:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfBdt-0000w2-6t; Tue, 09 Oct 2007 05:44:45 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IfBdr-0000un-1O for discuss-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 05:44:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfBdq-0000uY-O0 for discuss@apps.ietf.org; Tue, 09 Oct 2007 05:44:42 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfBdk-0008St-6t for discuss@apps.ietf.org; Tue, 09 Oct 2007 05:44:42 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l999iRIL015209 for ; Tue, 9 Oct 2007 18:44:27 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 43ee_39a17f00_764c_11dc_900a_0014221fa3c9; Tue, 09 Oct 2007 18:44:26 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:46820) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 9 Oct 2007 18:41:02 +0900 Message-Id: <6.0.0.20.2.20071009110918.0a21b790@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 09 Oct 2007 18:17:39 +0900 To: John C Klensin From: Martin Duerst Subject: draft-klensin-net-utf8-05.txt (was: Re: Form feed in Net-UTF8?) In-Reply-To: <16279928490191A12E3B99E8@p3.JCK.COM> References: <398A6C120C8B166FCBD3BDAF@p3.JCK.COM> <20071005151227.GA31232@nic.fr> <6.0.0.20.2.20071006120622.0a6d4b10@localhost> <16279928490191A12E3B99E8@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: discuss@apps.ietf.org, Mark Davis X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org At 17:17 07/10/06, John C Klensin wrote: >Martin, since I already shipped -05 and, thanks to the new >automated system, it has been posted, please see how you like >the treatment there. I think we agree on the principles, so >would welcome suggestions for further tuning. I think the treatment of FF looks reasonable. What I'm missing is any mention of HT (horizontal tab). HT is often part of white space, e.g. in formats such as XML, and heavily used in programming languages,.... It may not be part of NVT ASCII; in that case, maybe a short note would help. (I later found HT mentioned in the Appendix, probably a pointer to that would be enough). As for the overall document, here are a few more comments: - 1.1, in my view, is still too much history. If the idea is just to establish the need for the new format, the details for UTF-8, UTF-16, and UTF-32, as one example, are not needed there. - In section 3, I don't see any MUST for NFC, although from reading the text, it very much seems like that was intended (and I'd agree that's the way to go). Looking around, I found this in Section 2. Putting it in Section 2 is okay, but then there should be some pointer in Section 3. Also, if the definition is in Section 2, adding more requirements in other sections isn't very helpful. It would be better to either include the "must not transmit unassigned codepoints" to Section 2, or to change point 4 in section 2 to say "normalized according to details described in section 3". BTW, Section 2 should not say "Unicode method "NFC""; this would be the first spec I see that calls NFC a 'method'. - Section 3 is written as if NFC were the only normalization form. E.g. "The section above requires that all Net-Unicode strings be transmitted in normalized form." or "The Unicode Consortium specifies a normalization method, known as NFC [NFC]...". This document doesn't need to got into details about other forms, but it shouldn't keep the informed or half-informed reader wondering "so, what about the other forms", or "any reason why they choose NFC?" or so. As the reason for NFC, I'd suggest some text like the following: "Of all normalization forms defined by Unicode, NFC is closest to actual use in practice and, in general requires the least work when converting from a non-Unicode encoding." - "Systems conforming to this specification MUST NOT transmit any string containing any code point that is unassigned in the version of Unicode and NFC on which they are dependent.": The 'and' here is somewhat problematic. First, the statement only works for 'version of Unicode', because NFC as such doesn't come with a list of assigned codepoints. The wording from http://unicode.org/standard/stability_policy.html#Normalization is better: "s only characters from a given version of the Unicode, and it is put into a normalized form in accordance with that version of Unicode". Second, the 'and' means that we are fine if at least one of the conditions is met, i.e. I can use a character from Unicode 5.0 with a normalization implementation from Unicode 3.0 and I'm still okay with the above text. - Section 4 starts with: "In retrospect, one of the advantages of ASCII". This is again too much focus on history. This fact can be mentioned e.g. at the end of the first paragraph, but the start of the section should concentrate on the problem at hand. Otherwise, this document already *reads* outdated now, just immagine how it will read in five or ten years. - Section 4 nails down normalization at Unicode version 3.2. Also, it says that an update may be necessary for any changes to normalization. In fact, after Unicode version 3.2, there are already corrigenda to normalization, and it would be good if this document said clearly how they should be dealt with. I would propose the following: Corrigendum #4: Five CJK Canonical Mapping Errors (see http://www.unicode.org/versions/corrigendum4.html): This fixes five obvious mapping errors. Obviously, the new mappings should be used, because the old mappings lead to data corruption. No explicit labeling of the new mappings is necessary. Corrigendum #5: Normalization Idempotency (see http://www.unicode.org/versions/corrigendum5.html): This fixes a logical inconsistency in the textual description of the normalization algorithm. No reasonably occurring text is affected (by an extremely generous definition of reasonably occurring). No explicit labeling of the new mappings is necessary, because data isn't actually affected. I also think that the discussion on normalization versions should be in the normalization section. - Section 4 says that non-assigned codepoints should not be used. Does that include or exculde codepoints in the private use areas? - Section 5.1 says: "During the development of this specification, there was some confusion about where it would be useful given that, e.g., MIME and HTTP have their own rules about UTF-8 character types." This reads as if there were special provisions in MIME or HTTP about UTF-8. Such a misunderstanding should be avoided. I'm not sure I understand what you are referring to, but if you mean line-ending conventions, then MIME is with you, and for HTTP, it's not an issue of UTF-8, but more general. If you are referring to the fact that MIME/HTTP don't require NFC normalization, then don't blame your spec; NFC wasn't around yet when - Later in section 5.1, it says: "In particular, if this proposal is approved, or even appears to be getting significant traction,": Obviously, such text will look weird in an eventual RFC, and should be reworded, e.g. to something like a simple applicability statement: This specification is intended for use by other specifications that have not yet defined how to use Unicode. Examples could be Telnet... or FTP... This specification is not inteded for use with specifications that already allow the use UTF-8, such as MIME or HTTP. - I remember a discussion about the fact that Unicode in theory can contain a base character followed by an unlimited number of combining characters, and that in a protocol context, checking such combinations may not be feasible (you in theory need a buffer of unlimited length). There was the idea to restrict this format to a certain number of combining character; where has this idea gone? From a protocol implementer's viewpoint, I think it is still necessary. It is actually defined at http://www.unicode.org/reports/tr15/tr15-26.html#Stream_Safe_Text_Format but I saw some problems there, too, so I'm pinging the Unicode guys. (the main problem is that it looks like this form ends up to always be based on NFKC, which would be counter-productive) - I suggest a different title for 5.2. The current title sounds too much like FUD. The title should make clear that it is about design decisions, and maybe it actually belongs into an appendix (it's not normative, as far as I understand). To reduce any potential remaining FUD, it should also be pointed out that although the current stability rules do not rule out that a new script with both precomposed and decomposed representation is encoded, the chance that this happens is pretty slim, because the precomposed/decomposed dichotomy mainly came from legacy encodings. Also, unless you add a new base letter or a new combining character, creating a new precomposed/decomposed pair for an existing script is impossible, and one can fairly assume that virtually all base letters AND combining characters are already encoded, and that for new ones, no precomposed encodings will be created, again for the same reasons as above. - 5.2 mentions "IETF Standard UTF-8" without a definition or a reference. Not sure what is inteded, so please clarify. - Sentences such as these: "While not specifically a security issue, the requirement in NVT, and hence here, that, except as "newline" (CR LF), the CR character never appear alone but only when followed by ASCII NUL (an octet with all bits zero) may be problematic for some programming languages, and hence a trap for the unwary, unless caution is used." should be reworded. If the RFC Editor does even just a halfway job, this sentence won't remain as it is, and it's better to fix it now than leave that to the RFC Editor (at least in my experience). I haven't read the Appendix in detail, but I don't think it affects the above comments. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From discuss-bounces@apps.ietf.org Tue Oct 09 05:46:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfBd3-0000Pf-V5; Tue, 09 Oct 2007 05:43:53 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IfBd2-0000Mo-OA for discuss-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 05:43:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfBd2-0000Mg-Ee for discuss@apps.ietf.org; Tue, 09 Oct 2007 05:43:52 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfBcy-0008RT-From discuss-bounces@apps.ietf.org Tue Oct 09 05:46:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfBdt-0000w2-6t; Tue, 09 Oct 2007 05:44:45 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IfBdr-0000un-1O for discuss-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 05:44:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfBdq-0000uY-O0 for discuss@apps.ietf.org; Tue, 09 Oct 2007 05:44:42 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfBdk-0008St-6t for discuss@apps.ietf.org; Tue, 09 Oct 2007 05:44:42 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l999iRIL015209 for ; Tue, 9 Oct 2007 18:44:27 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 43ee_39a17f00_764c_11dc_900a_0014221fa3c9; Tue, 09 Oct 2007 18:44:26 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:46820) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 9 Oct 2007 18:41:02 +0900 Message-Id: <6.0.0.20.2.20071009110918.0a21b790@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 09 Oct 2007 18:17:39 +0900 To: John C Klensin From: Martin Duerst Subject: draft-klensin-net-utf8-05.txt (was: Re: Form feed in Net-UTF8?) In-Reply-To: <16279928490191A12E3B99E8@p3.JCK.COM> References: <398A6C120C8B166FCBD3BDAF@p3.JCK.COM> <20071005151227.GA31232@nic.fr> <6.0.0.20.2.20071006120622.0a6d4b10@localhost> <16279928490191A12E3B99E8@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: discuss@apps.ietf.org, Mark Davis X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org At 17:17 07/10/06, John C Klensin wrote: >Martin, since I already shipped -05 and, thanks to the new >automated system, it has been posted, please see how you like >the treatment there. I think we agree on the principles, so >would welcome suggestions for further tuning. I think the treatment of FF looks reasonable. What I'm missing is any mention of HT (horizontal tab). HT is often part of white space, e.g. in formats such as XML, and heavily used in programming languages,.... It may not be part of NVT ASCII; in that case, maybe a short note would help. (I later found HT mentioned in the Appendix, probably a pointer to that would be enough). As for the overall document, here are a few more comments: - 1.1, in my view, is still too much history. If the idea is just to establish the need for the new format, the details for UTF-8, UTF-16, and UTF-32, as one example, are not needed there. - In section 3, I don't see any MUST for NFC, although from reading the text, it very much seems like that was intended (and I'd agree that's the way to go). Looking around, I found this in Section 2. Putting it in Section 2 is okay, but then there should be some pointer in Section 3. Also, if the definition is in Section 2, adding more requirements in other sections isn't very helpfu3b for discuss@apps.ietf.org; Tue, 09 Oct 2007 05:43:52 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IfBcj-0001Gu-SR for discuss@apps.ietf.org; Tue, 09 Oct 2007 09:43:33 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 09 Oct 2007 09:43:33 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 09 Oct 2007 09:43:33 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: discuss@apps.ietf.org From: "Frank Ellermann" Subject: Re: draft-klensin-unicode-escapes-05 and draft-klensin-net-utf8-05 Date: Tue, 9 Oct 2007 11:40:48 +0200 Lines: 23 Message-ID: References: <20071008141946.GL71445@finch-staff-1.thus.net> <40631CD1A59A65DA1B88F394@[192.168.1.110]> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org John C Klensin wrote: [bare CR vs. bare LF]=20 > I could try to incorporate a little more text along those lines=20 > in the document Maybe. The main issue why I mentioned it are some inconsistencies in the normative language (MUST vs. SHOULD) wrt CR. And my odd impression that net-utf8 tries to "ban" HT and bare CR, but still "permits" FF and bare LF. I'd like it better if both bare CR and bare LF are in one group, and both HT and FF in another group. > please remember that it has already been criticized for=20 > containing too much history and explanation I think at least Stephane and I liked the historical parts very much, e.g. the IAC (0xFF) info at the end of appendix B is not only fascinating, it's important. OTOH I'm not sure that net-utf8 is a good place to discuss general Unicode and NFC issues, let alone implications for IDNAbis. Maybe an informative reference to section 3 in RFC 4690 could cover most of this. Frank l. It would be better to either include the "must not transmit unassigned codepoints" to Section 2, or to change point 4 in section 2 to say "normalized according to details described in section 3". BTW, Section 2 should not say "Unicode method "NFC""; this would be the first spec I see that calls NFC a 'method'. - Section 3 is written as if NFC were the only normalization form. E.g. "The section above requires that all Net-Unicode strings be transmitted in normalized form." or "The Unicode Consortium specifies a normalization method, known as NFC [NFC]...". This document doesn't need to got into details about other forms, but it shouldn't keep the informed or half-informed reader wondering "so, what about the other forms", or "any reason why they choose NFC?" or so. As the reason for NFC, I'd suggest some text like the following: "Of all normalization forms defined by Unicode, NFC is closest to actual use in practice and, in general requires the least work when converting from a non-Unicode encoding." - "Systems conforming to this specification MUST NOT transmit any string containing any code point that is unassigned in the version of Unicode and NFC on which they are dependent.": The 'and' here is somewhat problematic. First, the statement only works for 'version of Unicode', because NFC as such doesn't come with a list of assigned codepoints. The wording from http://unicode.org/standard/stability_policy.html#Normalization is better: "s only characters from a given version of the Unicode, and it is put into a normalized form in accordance with that version of Unicode". Second, the 'and' means that we are fine if at least one of the conditions is met, i.e. I can use a character from Unicode 5.0 with a normalization implementation from Unicode 3.0 and I'm still okay with the above text. - Section 4 starts with: "In retrospect, one of the advantages of ASCII". This is again too much focus on history. This fact can be mentioned e.g. at the end of the first paragraph, but the start of the section should concentrate on the problem at hand. Otherwise, this document already *reads* outdated now, just immagine how it will read in five or ten years. - Section 4 nails down normalization at Unicode version 3.2. Also, it says that an update may be necessary for any changes to normalization. In fact, after Unicode version 3.2, there are already corrigenda to normalization, and it would be good if this document said clearly how they should be dealt with. I would propose the following: Corrigendum #4: Five CJK Canonical Mapping Errors (see http://www.unicode.org/versions/corrigendum4.html): This fixes five obvious mapping errors. Obviously, the new mappings should be used, because the old mappings lead to data corruption. No explicit labeling of the new mappings is necessary. Corrigendum #5: Normalization Idempotency (see http://www.unicode.org/versions/corrigendum5.html): This fixes a logical inconsistency in the textual description of the normalization algorithm. No reasonably occurring text is affected (by an extremely generous definition of reasonably occurring). No explicit labeling of the new mappings is necessary, because data isn't actually affected. I also think that the discussion on normalization versions should be in the normalization section. - Section 4 says that non-assigned codepoints should not be used. Does that include or exculde codepoints in the private use areas? - Section 5.1 says: "During the development of this specification, there was some confusion about where it would be useful given that, e.g., MIME and HTTP have their own rules about UTF-8 character types." This reads as if there were special provisions in MIME or HTTP about UTF-8. Such a misunderstanding should be avoided. I'm not sure I understand what you are referring to, but if you mean line-ending conventions, then MIME is with you, and for HTTP, it's not an issue of UTF-8, but more general. If you are referring to the fact that MIME/HTTP don't require NFC normalization, then don't blame your spec; NFC wasn't around yet when - Later in section 5.1, it says: "In particular, if this proposal is approved, or even appears to be getting significant traction,": Obviously, such text will look weird in an eventual RFC, and should be reworded, e.g. to something like a simple applicability statement: This specification is intended for use by other specifications that have not yet defined how to use Unicode. Examples could be Telnet... or FTP... This specification is not inteded for use with specifications that already allow the use UTF-8, such as MIME or HTTP. - I remember a discussion about the fact that Unicode in theory can contain a base character followed by an unlimited number of combining characters, and that in a protocol context, checking such combinations may not be feasible (you in theory need a buffer of unlimited length). There was the idea to restrict this format to a certain number of combining character; where has this idea gone? From a protocol implementer's viewpoint, I think it is still necessary. It is actually defined at http://www.unicode.org/reports/tr15/tr15-26.html#Stream_Safe_Text_Format but I saw some problems there, too, so I'm pinging the Unicode guys. (the main problem is that it looks like this form ends up to always be based on NFKC, which would be counter-productive) - I suggest a different title for 5.2. The current title sounds too much like FUD. The title should make clear that it is about design decisions, and maybe it actually belongs into an appendix (it's not normative, as far as I understand). To reduce any potential remaining FUD, it should also be pointed out that although the current stability rules do not rule out that a new script with both precomposed and decomposed representation is encoded, the chance that this happens is pretty slim, because the precomposed/decomposed dichotomy mainly came from legacy encodings. Also, unless you add a new base letter or a new combining character, creating a new precomposed/decomposed pair for an existing script is impossible, and one can fairly assume that virtually all base letters AND combining characters are already encoded, and that for new ones, no precomposed encodings will be created, again for the same reasons as above. - 5.2 mentions "IETF Standard UTF-8" without a definition or a reference. Not sure what is inteded, so please clarify. - Sentences such as these: "While not specifically a security issue, the requirement in NVT, and hence here, that, except as "newline" (CR LF), the CR character never appear alone but only when followed by ASCII NUL (an octet with all bits zero) may be problematic for some programming languages, and hence a trap for the unwary, unless caution is used." should be reworded. If the RFC Editor does even just a halfway job, this sentence won't remain as it is, and it's better to fix it now than leave that to the RFC Editor (at least in my experience). I haven't read the Appendix in detail, but I don't think it affects the above comments. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From discuss-bounces@apps.ietf.org Tue Oct 09 05:46:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfBd3-0000Pf-V5; Tue, 09 Oct 2007 05:43:53 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IfBd2-0000Mo-OA for discuss-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 05:43:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfBd2-0000Mg-Ee for discuss@apps.ietf.org; Tue, 09 Oct 2007 05:43:52 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfBcy-0008RT-3b for discuss@apps.ietf.org; Tue, 09 Oct 2007 05:43:52 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IfBcj-0001Gu-SR for discuss@apps.ietf.org; Tue, 09 Oct 2007 09:43:33 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 09 Oct 2007 09:43:33 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 09 Oct 2007 09:43:33 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: discuss@apps.ietf.org From: "Frank Ellermann" Subject: Re: draft-klensin-unicode-escapes-05 and draft-klensin-net-utf8-05 Date: Tue, 9 Oct 2007 11:40:48 +0200 Lines: 23 Message-ID: References: <20071008141946.GL71445@finch-staff-1.thus.net> <40631CD1A59A65DA1B88F394@[192.168.1.110]> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org John C Klensin wrote: [bare CR vs. bare LF]=20 > I could try to incorporate a little more text along those lines=20 > in the document Maybe. The main issue why I mentioned it are some inconsistencies in the normative language (MUST vs. SHOULD) wrt CR. And my odd impression that net-utf8 tries to "ban" HT and bare CR, but still "permits" FF and bare LF. I'd like it better if both bare CR and bare LF are in one group, and both HT and FF in another group. > please remember that it has already been criticized for=20 > containing too much history and explanation I think at least Stephane and I liked the historical parts very much, e.g. the IAC (0xFF) info at the end of appendix B is not only fascinating, it's important. OTOH I'm not sure that net-utf8 is a good place to discuss general Unicode and NFC issues, let alone implications for IDNAbis. Maybe an informative reference to section 3 in RFC 4690 could cover most of this. Frank From discuss-bounces@apps.ietf.org Tue Oct 09 09:32:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfFAX-0006cG-Pp; Tue, 09 Oct 2007 09:30:41 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IfFAW-0006br-9y for discuss-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 09:30:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfFAW-0006bi-0B for discuss@apps.ietf.org; Tue, 09 Oct 2007 09:30:40 -0400 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfFAP-00086h-QJ for discuss@apps.ietf.org; Tue, 09 Oct 2007 09:30:39 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id DFA3F24080E; Tue, 9 Oct 2007 14:30:02 +0200 (CEST) Received: by horcrux (Postfix, from userid 1000) id 88C41157D25; Tue, 9 Oct 2007 15:20:25 +0200 (CEST) Date: Tue, 9 Oct 2007 15:20:25 +0200 From: Stephane Bortzmeyer To: John C Klensin Subject: Re: draft-klensin-unicode-escapes-05 and draft-klensin-net-utf8-05 Message-ID: <20071009132025.GA19714@laperouse.bortzmeyer.org> References: <20071008141946.GL71445@finch-staff-1.thus.net> <40631CD1A59A65DA1B88F394@[192.168.1.110]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40631CD1A59A65DA1B88F394@[192.168.1.110]> X-Transport: UUCP rules X-Operating-System: Ubuntu 7.04 (feisty) User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: discuss@apps.ietf.org, "Clive D.W. Feather" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, Oct 08, 2007 at 12:42:41PM -0400, John C Klensin wrote a message of 82 lines which said: > I could try to incorporate a little more text along those lines in > the document, but please remember that it has already been > criticized for containing too much history and explanation rather > than just laying out the rules. Allow me a personal soapbox. I find that typical RFCs are terribly lacking rationales, history and background details. The focus on 'pure specification' makes difficult to understand the choices and is a sure recipe for reinventing bad ideas from time to time (or, worse, to violate a specification because it seems suboptimal). The standard IETF reply 'Read the archives of the working group, they are public, anyway', is a joke: no normal human being can digest two or three years of a typical WG mailing list archive and still do actual work. I understand the need to separate the specification from the rationale (for large RFC, this could be done by a split between two RFC, one standard and one informational) but this should not prevent us to have a 'Rationale and design choices' section. From discuss-bounces@apps.ietf.org Tue Oct 09 14:50:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfK9X-0004sU-NH; Tue, 09 Oct 2007 14:49:59 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IfK9X-0004sO-0v for discuss-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 14:49:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfK9W-0004qx-Mo for discuss@apps.ietf.org; Tue, 09 Oct 2007 14:49:58 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfK9Q-000899-DE for discuss@apps.ietf.org; Tue, 09 Oct 2007 14:49:58 -0400 Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1IfK96-000FU5-B5; Tue, 09 Oct 2007 14:49:32 -0400 Date: Tue, 09 Oct 2007 14:49:29 -0400 From: John C Klensin To: Stephane Bortzmeyer Subject: Re: draft-klensin-unicode-escapes-05 and draft-klensin-net-utf8-05 Message-ID: <8646B0EEEE62DEC759F18422@[192.168.1.110]> In-Reply-To: <20071009132025.GA19714@laperouse.bortzmeyer.org> References: <20071008141946.GL71445@finch-staff-1.thus.net> <40631CD1A59A65DA1B88F394@[192.168.1.110]> <20071009132025.GA19714@laperouse.bortzmeyer.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: discuss@apps.ietf.org, "Clive D.W. Feather" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Tuesday, October 09, 2007 3:20 PM +0200 Stephane Bortzmeyer wrote: > On Mon, Oct 08, 2007 at 12:42:41PM -0400, > John C Klensin wrote > a message of 82 lines which said: > >> I could try to incorporate a little more text along those >> lines in the document, but please remember that it has >> already been criticized for containing too much history and >> explanation rather than just laying out the rules. > > Allow me a personal soapbox. I find that typical RFCs are > terribly lacking rationales, history and background details. > The focus on 'pure specification' makes difficult to > understand the choices and is a sure recipe for reinventing > bad ideas from time to time (or, worse, to violate a > specification because it seems suboptimal). We also tend to forget that compliance with IETF standards is voluntary. If someone looks at a specification and says "that makes no sense to me", the odds of their implementing it just because the IETF says so are not high, certainly not as high as if they could look somewhere and say "ah, that was done for the following reason... even if I don't completely agree, it makes sense". It seems to me to be particularly important if we are modifying, rather than just following, some practice or existing form of a standard that is out there. One of the best reasons for doing so is if the existing practices are not consistent and the IETF work is an attempt to draw things back together or outline a path for the future, but that makes it all the more important to provide a rationale, lest people simply continue to do whatever occurs to them first. > The standard IETF reply 'Read the archives of the working > group, they are public, anyway', is a joke: no normal human > being can digest two or three years of a typical WG mailing > list archive and still do actual work. > > I understand the need to separate the specification from the > rationale (for large RFC, this could be done by a split > between two RFC, one standard and one informational) but this > should not prevent us to have a 'Rationale and design choices' > section. I think we are in violent agreement. john From discuss-bounces@apps.ietf.org Tue Oct 09 17:22:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfMW3-0001dH-S3; Tue, 09 Oct 2007 17:21:23 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IfMW2-0001d9-Kf for discuss-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 17:21:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfMW2-0001d1-B8 for discuss@apps.ietf.org; Tue, 09 Oct 2007 17:21:22 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfMVw-00046m-2k for discuss@apps.ietf.org; Tue, 09 Oct 2007 17:21:22 -0400 Received: from [127.0.0.1] (mail.songbird.com [208.184.79.10]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l99LKlsZ027376; Tue, 9 Oct 2007 14:20:48 -0700 Message-ID: <470BF0C1.2090303@ninebynine.org> Date: Tue, 09 Oct 2007 22:21:05 +0100 From: Graham Klyne User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: Issues around sponsoring individual documents References: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> In-Reply-To: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Lisa Dusseault wrote: > > The Applications area does not have a lot of attendees or WGs (I oversee > five, and of those five, three are within a document or two of > closing). Much of the current work is being done as individual > submissions (abbreviated IS in this email) [0]. I'd like to get some > input on how IS's should be handled. I have many opinions on IS > tradeoffs, having written several and sponsored more, but I'm trying to > phrase these questions without entirely presupposing my own answers, and > to reflect conflicted opinions and the criticisms I've heard. A late response, but a couple of considerations that I don't think have been entirely covered by the many thoughtful comments so far offered: 1. By forming a WG, there is an understanding (a contract or sorts?) that proposals for issues described by the WG charter will be given proper consideration, and appropriately progressed if they are of suitable quality. An IS has no such assurance, and as such the proposer has no ground for complaint if the work they do is summarily dismissed. This suggests to me that there is a reasonable judgement a proposer may make, and that IS is not simply a "short cut". 2. In contemplating an IS, I would expect that there be a presumption that any RFC publication (if the work is deemed worthy of such publication) would initially be as informational or experimental rather than standards track. These are considerations that, if suitably promoted as "health warnings" concerning IS's, may lead proposers themselves to make reasonable judgements about the appropriate route to follow rather than always requiring an AD to make the decision. > (BTW, I'm sure I can follow the advice of "Use your judgement" if anybody > decides to say that, but it doesn't really inform that judgement does it? ) In terms of informing judgement... if the case for an IS isn't fairly obvious, then I think the presumption would be to not offer support. (My mathematical analysis tutor would tell us "if something is obvious then either it can be proven in three lines or it's an assumption".) And technically, unless the rules changed without me noticing, a document can proceed as informational RFC without requiring IESG support, right? #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact From discuss-bounces@apps.ietf.org Thu Oct 11 02:48:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifrok-00044I-Da; Thu, 11 Oct 2007 02:46:46 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ifroh-0003uV-7J for discuss-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 02:46:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifroc-0003rp-91 for discuss@apps.ietf.org; Thu, 11 Oct 2007 02:46:38 -0400 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfroQ-0002Cx-Vg for discuss@apps.ietf.org; Thu, 11 Oct 2007 02:46:33 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id l9B6k4oO001942Thu, 11 Oct 2007 06:46:04 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1Ifro4-000DZL-00; Thu, 11 Oct 2007 07:46:04 +0100 Date: Thu, 11 Oct 2007 07:46:04 +0100 From: "Clive D.W. Feather" To: John C Klensin Subject: Re: draft-klensin-unicode-escapes-05 and draft-klensin-net-utf8-05 Message-ID: <20071011064604.GK46996@finch-staff-1.thus.net> References: <20071008141946.GL71445@finch-staff-1.thus.net> <40631CD1A59A65DA1B88F394@[192.168.1.110]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40631CD1A59A65DA1B88F394@[192.168.1.110]> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org John C Klensin said: >> You don't have an A.3 for Java. > Because there was no specific syntax in the last draft that had > the syntax in line. Appendix A.3. Java Form EmbeddedUnicodeChar = %x5C.7A 4HEXDIG > I could try to incorporate a little more text along those lines > in the document, but please remember that it has already been > criticized for containing too much history and explanation > rather than just laying out the rules. I am in favour of the history and explanation. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | From discuss-bounces@apps.ietf.org Thu Oct 11 10:07:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfygQ-0000sX-C6; Thu, 11 Oct 2007 10:06:38 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IfygO-0000nw-Dq for discuss-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 10:06:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfygN-0000no-Mu for discuss@apps.ietf.org; Thu, 11 Oct 2007 10:06:35 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfygI-0002wK-CO for discuss@apps.ietf.org; Thu, 11 Oct 2007 10:06:35 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Ifyff-000B9Q-E9; Thu, 11 Oct 2007 10:05:51 -0400 Date: Thu, 11 Oct 2007 10:05:50 -0400 From: John C Klensin To: "Clive D.W. Feather" Subject: Re: draft-klensin-unicode-escapes-05 and draft-klensin-net-utf8-05 Message-ID: In-Reply-To: <20071011064604.GK46996@finch-staff-1.thus.net> References: <20071008141946.GL71445@finch-staff-1.thus.net> <40631CD1A59A65DA1B88F394@[192.168.1.110]> <20071011064604.GK46996@finch-staff-1.thus.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Thursday, 11 October, 2007 07:46 +0100 "Clive D.W. Feather" wrote: > John C Klensin said: >>> You don't have an A.3 for Java. >> Because there was no specific syntax in the last draft that >> had the syntax in line. > > > Appendix A.3. Java Form > > EmbeddedUnicodeChar = %x5C.7A 4HEXDIG You mean %x5C.75, don't you? 7A is "z". >> I could try to incorporate a little more text along those >> lines in the document, but please remember that it has >> already been criticized for containing too much history and >> explanation rather than just laying out the rules. > > I am in favour of the history and explanation. Thanks. john From discuss-bounces@apps.ietf.org Thu Oct 11 11:19:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifzo6-0002cM-00; Thu, 11 Oct 2007 11:18:38 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ifzo4-0002cC-N4 for discuss-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 11:18:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifzo4-0002by-DR for discuss@apps.ietf.org; Thu, 11 Oct 2007 11:18:36 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ifzo3-0006Ju-6h for discuss@apps.ietf.org; Thu, 11 Oct 2007 11:18:36 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Ifznz-000EJ0-FM for discuss@apps.ietf.org; Thu, 11 Oct 2007 11:18:31 -0400 Date: Thu, 11 Oct 2007 11:18:30 -0400 From: John C Klensin To: discuss@apps.ietf.org Subject: draft-klensin-unicode-escapes-06 Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi. This draft has been posted, incorporating suggested changes from Frank, Clive, one problem that I spotted, and a comments received offlist, all of which I think are minor. I think we have reached the point of diminishing returns and that, unless someone suddenly sees a showstopper, it is time for us to ask Chris and Lisa to issue an IETF Last Call. Anyone see showstoppers or disagree for some other reason? john From discuss-bounces@apps.ietf.org Thu Oct 11 15:50:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig42F-0004DW-Hv; Thu, 11 Oct 2007 15:49:31 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ig42E-0004D7-1o for discuss-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 15:49:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig42D-0004Ct-OG for discuss@apps.ietf.org; Thu, 11 Oct 2007 15:49:29 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig42B-00029B-7h for discuss@apps.ietf.org; Thu, 11 Oct 2007 15:49:29 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Ig427-000Nds-Gp for discuss@apps.ietf.org; Thu, 11 Oct 2007 15:49:23 -0400 Date: Thu, 11 Oct 2007 15:49:22 -0400 From: John C Klensin To: discuss@apps.ietf.org Subject: draft-klensin-net-utf8-06 Message-ID: <93F25E18AB3DA3EB0599F092@p3.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Ok, this document just went into the queue and should appear momentarily (probably before this message goes up). It is clearly less ready than the unicode-escapes one, partially because of the addition of a lot of new or revised text, but I hope we are converging: I will probably not have time to generate another draft --except possibly for _very_ minor changes-- prior to at least the middle of next month. I've tried to deal with the comments from Frank, Stephane, Clive, a few offlist comments, and the very extensive analysis from Martin. The comments that follow address some suggested changes that I did not make plus a few things that seem to deserve comments. (1) We obviously have a tension between those who like the history, context, and explanations and those who don't. Oddly, at least one person who asked for less then turned around and complained that one decision wasn't explained. Given people on both sides, I've tried to strike a balance, but it clearly reflects my/our editorial preferences. (2) There are many ways in which the document could be more or less radically reorganized. Some might make it better. Barring really compelling arguments, we aren't going to do it: the move of some material to appendices already fouled up some references (I hope this iteration fixes all of them) and the payoff just doesn't seem worth the additional time and iterations. (3) This document affects protocols, which the unicode-escapes one almost exclusively affects documentation and how the IETF talks about things. I have consequently tagged this one as destined for Proposed Standard and the other one as BCP. If you disagree, this is probably the time to speak up. (4) I've tried to clarify the text in several places, but I'm not sure I got one bit adequately. For CR, the rule is MUST NOT appear bare (i.e., MUST be followed by LF or NUL) SHOULD NOT appear with NUL I believe that is consistent. (5) I've added some words about both HT and FF. One may need to look in the appendices to find all of them. (6) I've eliminated references to IDNA entirely, substituting one to Stringprep where that appeared necessary. (7) The document is now linked to Unicode 5.0, with previous versions, notably 3.2, referenced only non-normatively in discussion. I hope the revision was done correctly; please tell me if it was not. Moving to 5.0 eliminates any possible need to go into detail about NFC changes after 3.2 but not the need to caution against the risk of similar changes in the future. (8) While a few people advocated it, I can't see making the NFC requirement a MUST. First, there are certainly reasonable cases in which it is not appropriate. Second, if NFC on sending is a MUST, then receivers have the right to expect that they will see only NFC-normalized forms on input. That assumption is dangerous, since, in general, there is no way to know whether a sender is following this spec. I hope the text is now consistent with that position. best, john From discuss-bounces@apps.ietf.org Fri Oct 12 13:32:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgOLb-0004aN-UL; Fri, 12 Oct 2007 13:30:51 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IgOLa-0004Wp-MQ for discuss-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 13:30:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgOLa-0004UT-Bn for discuss@apps.ietf.org; Fri, 12 Oct 2007 13:30:50 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgOLR-0006Lg-Hv for discuss@apps.ietf.org; Fri, 12 Oct 2007 13:30:50 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 7439F240826; Fri, 12 Oct 2007 18:30:04 +0200 (CEST) Received: by horcrux (Postfix, from userid 1000) id 4E6B6157D25; Fri, 12 Oct 2007 10:10:17 +0200 (CEST) Date: Fri, 12 Oct 2007 10:10:18 +0200 From: Stephane Bortzmeyer To: discuss@apps.ietf.org Subject: Re: draft-klensin-net-utf8-06 Message-ID: <20071012081018.GA10028@laperouse.bortzmeyer.org> References: <93F25E18AB3DA3EB0599F092@p3.JCK.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <93F25E18AB3DA3EB0599F092@p3.JCK.COM> X-Transport: UUCP rules X-Operating-System: Ubuntu 7.04 (feisty) User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Thu, Oct 11, 2007 at 03:49:22PM -0400, John C Klensin wrote a message of 66 lines which said: > I hope we are converging: My opinion is that, yes, the document is better and more stable than it was. I've read and reviewed -06 and I find it suitable for Last Call, with no serious pending issues. > (2) There are many ways in which the document could be more or less > radically reorganized. The "historical" or "rationale" sentences (such as "In retrospect, one of the advantages of ASCII [X3.4-1978] when it was chosen was that the code space was full when the Standard was first published") could certainly be more separated from the normative text but I do not see this issue as a serious problem. The text seems clear. > (8) While a few people advocated it, I can't see making the NFC > requirement a MUST. [...] Second, if NFC on sending is a MUST, then > receivers have the right to expect that they will see only > NFC-normalized forms on input. That assumption is dangerous, since, > in general, there is no way to know whether a sender is following > this spec. While I agree with the SHOULD, I do not think the reason given above is a good one. If we follow it, *all* MUST in RFCs could be changed to SHOULD, in the name of the robustness principle. IMHO, the best reason for keeping the SHOULD ("applications should send a NFC-normalized stream") is the argument about libraries that the application does not control. From discuss-bounces@apps.ietf.org Sat Oct 13 16:50:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ignth-00053E-8X; Sat, 13 Oct 2007 16:47:45 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Igntf-00050h-Qz for discuss-confirm+ok@megatron.ietf.org; Sat, 13 Oct 2007 16:47:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Igntf-00050Y-7E for discuss@apps.ietf.org; Sat, 13 Oct 2007 16:47:43 -0400 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgntZ-0001kp-1T for discuss@apps.ietf.org; Sat, 13 Oct 2007 16:47:43 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 30389240817; Sat, 13 Oct 2007 21:47:06 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id DF49311829; Sat, 13 Oct 2007 22:44:21 +0200 (CEST) Date: Sat, 13 Oct 2007 22:44:21 +0200 From: Stephane Bortzmeyer To: John C Klensin Subject: Re: draft-klensin-unicode-escapes-06 Message-ID: <20071013204421.GA8544@sources.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Thu, Oct 11, 2007 at 11:18:30AM -0400, John C Klensin wrote a message of 14 lines which said: > I think we have reached the point of diminishing returns and that, > unless someone suddenly sees a showstopper, it is time for us to ask > Chris and Lisa to issue an IETF Last Call. I've read and reviewed -06 and I find it suitable for Last Call, with no serious pending issues. From discuss-bounces@apps.ietf.org Mon Oct 15 04:40:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhLTu-0003zj-Dr; Mon, 15 Oct 2007 04:39:22 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IhLTs-0003wi-KP for discuss-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 04:39:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhLTr-0003mQ-J1 for discuss@apps.ietf.org; Mon, 15 Oct 2007 04:39:19 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhLTg-0007XX-6K for discuss@apps.ietf.org; Mon, 15 Oct 2007 04:39:14 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IhLJS-00067E-Lf for discuss@apps.ietf.org; Mon, 15 Oct 2007 08:28:34 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Oct 2007 08:28:34 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Oct 2007 08:28:34 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: discuss@apps.ietf.org From: "Frank Ellermann" Subject: Re: draft-klensin-net-utf8-06 Date: Mon, 15 Oct 2007 10:17:33 +0200 Lines: 51 Message-ID: References: <93F25E18AB3DA3EB0599F092@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org John C Klensin wrote: > less ready than the unicode-escapes one, partially because of > the addition of a lot of new or revised text, but I hope we=20 > are converging Looking only at the diff, yes. You've added a recommendation to avoid private use code points, because they "do not have standard definitions or normalization interpretations". I think the latter is incorrect, they're by decree normalized. Maybe what you want to say is that they can't have canonical or compatible decompositions. IMO the obvious "no standard definition" alone is clearer and good enough to justify your recommendation. Not directly related to our draft, in 5.2 you write: | The latter is important because an unassigned code point=20 | always normalizes to itself. Something's really odd with this in the Unicode standard: For some unassigned code points it's "almost obvious" that they'll never end up in any NFX, unless they also get the non-character property. What I have in mind are "obvious gaps" in dingbats, mathematical symbols, and other blocks, where the abstract character corresponding to the given unassigned code point was already encoded elsewhere. =20 One of the earlier examples is u+2073. In theory they could say "whatever we'll do with that code point, it will be either a non-character, or have a canonical decomposition, or stay as is (unassigned) forever". Back to the draft, s/have been be tied/have been tied/ in 5.2.=20 =20 > I've added some words about both HT and FF. One may need to > look in the appendices to find all of them. Fine now. Over the weekend I read a related chapter in the Unicode standard, and I think you have to=20 mention LS u+2028 and maybe also PS u+2029 somewhere. Admittedly banning LS might upset some folks. IMO it's similar to the NEL case, LS might be even more obscure. OTOH I think that you shouldn't discuss IND u+0084, it's dead. TUS 5.0 says "formerly known as INDEX". Frank From discuss-bounces@apps.ietf.org Mon Oct 15 13:51:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhU4f-0005yS-9L; Mon, 15 Oct 2007 13:49:53 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IhU4d-0005y1-Sm for discuss-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 13:49:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhU4d-0005xr-42 for discuss@apps.ietf.org; Mon, 15 Oct 2007 13:49:51 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhU4W-0003ec-Mi for discuss@apps.ietf.org; Mon, 15 Oct 2007 13:49:51 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IhU4N-0004eJ-7v; Mon, 15 Oct 2007 13:49:35 -0400 Date: Mon, 15 Oct 2007 13:49:34 -0400 From: John C Klensin To: Frank Ellermann , discuss@apps.ietf.org Subject: Re: draft-klensin-net-utf8-06 Message-ID: <090481616F66605395036545@p3.JCK.COM> In-Reply-To: References: <93F25E18AB3DA3EB0599F092@p3.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Monday, 15 October, 2007 10:17 +0200 Frank Ellermann wrote: > John C Klensin wrote: > >> less ready than the unicode-escapes one, partially because of >> the addition of a lot of new or revised text, but I hope we >> are converging > > Looking only at the diff, yes. You've added a recommendation > to avoid private use code points, because they "do not have > standard definitions or normalization interpretations". > > I think the latter is incorrect, they're by decree normalized. > Maybe what you want to say is that they can't have canonical > or compatible decompositions. IMO the obvious "no standard > definition" alone is clearer and good enough to justify your > recommendation. Frank, in both this and the notes below, we are, I think, getting dangerously close to providing an interpretation and profile of Unicode. The bits of that that are necessary to get line-endings nailed down and to make the NFC recommendation clear are necessary but, when we start going into detail on how individual code points or blocks are interpreted, we are getting into territory that is very uncomfortable for me and, I believe, should be uncomfortable for the IETF. > Not directly related to our draft, in 5.2 you write: > | The latter is important because an unassigned code point > | always normalizes to itself. > > Something's really odd with this in the Unicode standard: > > For some unassigned code points it's "almost obvious" that > they'll never end up in any NFX, unless they also get the > non-character property. What I have in mind are "obvious > gaps" in dingbats, mathematical symbols, and other blocks, > where the abstract character corresponding to the given > unassigned code point was already encoded elsewhere. >... The set of issues involved here is the reason that the "Stable NF..." discussions started in the wake of some of the pre-RFC4690 discussions a year or more ago. I think we should continue to try very hard to avoid having it turn into an IETF problem. > One of the earlier examples is u+2073. In theory they > could say "whatever we'll do with that code point, it > will be either a non-character, or have a canonical > decomposition, or stay as is (unassigned) forever". They could say lots of things in theory and perhaps in practice. But they are also in the position in which, being human, it is possible for them to make mistakes. And, when they make a mistake of sufficient importance, they reserve the right to change things. Becoming more dependent than absolutely necessary on changes, or certain types of changes, being forbidden, impresses me as unwise... and probably unfair to both the IETF and Unicode communities. > Back to the draft, s/have been be tied/have been tied/ > in 5.2. Fixed in working draft for -07. Unless more changes come up, I won't post that draft except as part of a Last Call process -- too much clutter from too many drafts. >> I've added some words about both HT and FF. One may need to >> look in the appendices to find all of them. > > Fine now. Over the weekend I read a related chapter > in the Unicode standard, and I think you have to > mention LS u+2028 and maybe also PS u+2029 somewhere. Sorry. This gets into the picking and choosing of individual code points that we have tried to avoid, for the reasons above and otherwise. Note that the prohibition on IND, etc., is part of a general prohibition on C1 controls -- a clearly-defined range. The comments on those characters are just that, comments (the text was bad on that -- applying a SHOULD NOT to those characters and then a MUST NOT to the entire block. That has been fixed. > Admittedly banning LS might upset some folks. IMO it's > similar to the NEL case, LS might be even more obscure. > > OTOH I think that you shouldn't discuss IND u+0084, > it's dead. TUS 5.0 says "formerly known as INDEX". But it was taken into Unicode, if I recall, from ISO 8859, the associated supplemental controls standard, and the various other flavors of "Latin-NN". It went into those documents, if my memory is correct, precisely to correct ambiguities in the interpretation of LF and CR (LS presumably arose when even that wasn't sufficient in some environments). I think mentioning it because of the relationship to the pre-Unicode C1 controls might be helpful to some people and is harmless at worst. But I'd be happy to hear from others about this if people think it is important enough to delay a last call still longer. john From discuss-bounces@apps.ietf.org Mon Oct 15 15:40:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhVms-00072x-QD; Mon, 15 Oct 2007 15:39:38 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IhVmq-000723-VI for discuss-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 15:39:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhVmq-00071S-0b for discuss@apps.ietf.org; Mon, 15 Oct 2007 15:39:36 -0400 Received: from e36.co.us.ibm.com ([32.97.110.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhVmj-0000xP-Pe for discuss@apps.ietf.org; Mon, 15 Oct 2007 15:39:35 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e36.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l9FJdRk9020559 for ; Mon, 15 Oct 2007 15:39:27 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l9FJdQj5495384 for ; Mon, 15 Oct 2007 13:39:27 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l9FJdQKN012786 for ; Mon, 15 Oct 2007 13:39:26 -0600 Received: from localhost.localdomain (wecm-9-67-133-126.wecm.ibm.com [9.67.133.126]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l9FJdO1I012621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Oct 2007 13:39:26 -0600 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.1/8.12.5) with ESMTP id l9FJdIkM003350 for ; Mon, 15 Oct 2007 15:39:19 -0400 Message-Id: <200710151939.l9FJdIkM003350@localhost.localdomain> To: discuss@apps.ietf.org Subject: internationalization of URIs Date: Mon, 15 Oct 2007 15:39:18 -0400 From: Thomas Narten X-Spam-Score: -4.0 (----) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org As some of you may know, as part of testing the readiness of IDNs, ICANN has inserted a set of internationalized versions of ".test" into the root zone of the DNS. See http://www.icann.org/announcements/announcement-15oct07.htm for details. One of the questions that this has prompted (again) is what about that pesky "http:", that still needs to typed in ascii. And what about the rest of the URL for that matter. I know this is not a new issue, but could someone summarize the landscape here on what "needs to be done" to internationalize the rest of the URI (other than the DNS name)? Is this considered to be completely an application issue? (I note that URIs are ascii, but there are escaping mechanisms to handle other characters.) Is there additional IETF work that needs to be done here? Or does this all fall under application-specific enablement? Or is even worse, in that this largely falls outside of applications and more into what is typically done by OS libraries and on the type of internationalization support the OS provides indirectly? Thomas From discuss-bounces@apps.ietf.org Mon Oct 15 20:22:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhaAu-0005FO-Nk; Mon, 15 Oct 2007 20:20:44 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IhaAt-0005F3-4a for discuss-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 20:20:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhaAs-0005Dv-8a for discuss@apps.ietf.org; Mon, 15 Oct 2007 20:20:42 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhaAh-0002QN-OD for discuss@apps.ietf.org; Mon, 15 Oct 2007 20:20:38 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l9G0JcNF027049 for ; Tue, 16 Oct 2007 09:19:39 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 6072_7b89f8bc_7b7d_11dc_9a27_0014221fa3c9; Tue, 16 Oct 2007 09:19:38 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:34051) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 16 Oct 2007 09:16:05 +0900 Message-Id: <6.0.0.20.2.20071016083218.06e24710@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 16 Oct 2007 09:18:41 +0900 To: Thomas Narten , discuss@apps.ietf.org From: Martin Duerst Subject: Re: internationalization of URIs In-Reply-To: <200710151939.l9FJdIkM003350@localhost.localdomain> References: <200710151939.l9FJdIkM003350@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hello Thomas, I have some good news for you: For 'the rest of the URI', please have a look at RFC 3987 Internationalized Resource Identifiers (IRIs) (http://www.ietf.org/rfc/rfc3987). Work is currently going on to move this to Draft standard, please see: http://www.ietf.org/internet-drafts/draft-duerst-iri-bis-01.txt Please review and send your comments to public-iri@w3.org. As for the "http:", that's indeed a piece that some might say is missing. Even the IRI spec still My current take on this is as follows: 1) Only very few URI schemes are actually used widely, mostly only "http:" 2) On most browsers, "http:" can be dropped 3) Things like "http:" look like secret incantations or garbage to most end users familiar with the Latin script, too (that doesn't make it easier to type for people not familiar with the Latin script, though) 4) I think an easy way to help would be to provide a drop-down menu at the start of the address/location field e.g. in a browser or a Web page editor, with some of the following selections: http (Web Page Address) ftp (File Exchange) mailto (Email Address) ... [of course the explanatory text being in the user interface language] 5) Some browsers might automatically transscribe character sequences in non-Latin scripts corresponding to things such as "http://" or "ftp://" to Latin automatically when they appear at the start of the browser address/location bar. So e.g. somebody in Greece would type something like "$B&U&S&P(B://", and it would automatically be converted to "ftp://". [neither 4) nor 5) are currently implemented as far as I know, but they wouldn't be rocket science, and they would be pretty local, low-key solutions, and other, similar ideas, may also come up] 6) The next step would be to come up with some matching mechanism (the easy part :-) and some political framework to create parallel names for the schemes (the tough part :-(. I haven't looked at the details, but it might be possible to reuse NAPTR RRs or some such for the technical part. (that idea is due to James Seng, in personal communication at the Kuala Lumpur ICANN meeting in 2004). I'm sorry this is a bit browser-centric, but that's where I see most users use most URIs/IRIs. [Private rant: 1) and 2) together mean that non-ASCII TLDs are way more important than getting scheme names internationalized, despite of what some shy ICANN people might say ("we can't possibly move ahead with non-ASCII TLDs unless we have parallel versions of scheme names") or what some internationalization zealots might say ("everything or nothing")] Hope this helps. Regards, Martin. At 04:39 07/10/16, Thomas Narten wrote: >As some of you may know, as part of testing the readiness of IDNs, >ICANN has inserted a set of internationalized versions of ".test" into >the root zone of the DNS. See >http://www.icann.org/announcements/announcement-15oct07.htm for >details. > >One of the questions that this has prompted (again) is what about that >pesky "http:", that still needs to typed in ascii. And what about the >rest of the URL for that matter. > >I know this is not a new issue, but could someone summarize the >landscape here on what "needs to be done" to internationalize the rest >of the URI (other than the DNS name)? Is this considered to be >completely an application issue? (I note that URIs are ascii, but >there are escaping mechanisms to handle other characters.) > >Is there additional IETF work that needs to be done here? Or does this >all fall under application-specific enablement? > >Or is even worse, in that this largely falls outside of applications >and more into what is typically done by OS libraries and on the type >of internationalization support the OS provides indirectly? > >Thomas #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From discuss-bounces@apps.ietf.org Tue Oct 16 01:02:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IheYQ-0002Lh-F3; Tue, 16 Oct 2007 01:01:18 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IheYO-0002KY-I3 for discuss-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 01:01:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IheYN-0002JQ-Jd for discuss@apps.ietf.org; Tue, 16 Oct 2007 01:01:15 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IheYH-0002vf-BC for discuss@apps.ietf.org; Tue, 16 Oct 2007 01:01:15 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9G50w94009097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 15 Oct 2007 22:00:58 -0700 Received: from [98.207.5.180] (vpn-10-50-0-181.qualcomm.com [10.50.0.181]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9G50u3g000587; Mon, 15 Oct 2007 22:00:57 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <200710151939.l9FJdIkM003350@localhost.localdomain> References: <200710151939.l9FJdIkM003350@localhost.localdomain> Date: Mon, 15 Oct 2007 22:01:02 -0700 To: Thomas Narten , discuss@apps.ietf.org From: Ted Hardie Subject: Re: internationalization of URIs Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org At 3:39 PM -0400 10/15/07, Thomas Narten wrote: >As some of you may know, as part of testing the readiness of IDNs, >ICANN has inserted a set of internationalized versions of ".test" into >the root zone of the DNS. See >http://www.icann.org/announcements/announcement-15oct07.htm for >details. > >One of the questions that this has prompted (again) is what about that >pesky "http:", that still needs to typed in ascii. And what about the >rest of the URL for that matter. So, I've read Martin's answer, but I'd like to take a shot at this from a slightly different angle. Inside the IETF, we commonly treat IRIs as a presentation layer for URIs. There is a URI form for any IRI (and all URIs are also IRIs), so it is always possible to "stick to" the URI as the protocol element and as use IRIs as presentation elements. (The big exception to this is inside XML, where the "anyURI" element got deployed with a syntax that didn't really match URIs at all; the result is that those strings (which appear to be IRIs to the casual observer) are really protocol elements using different rules than those normally used by URIs.) When I read Martin's comments about drop-downs, elided scheme names, and similar tricks, my protocol-geek hat tightened on my head and gave me a pretty severe headache. Taking it off for a moment, though, showed me things are still okay. As presentation elements, things like drop-downs, inference of scheme by an initial www, and similar tricks are more reasonable. A big question, then, is whether we have all the bits we need to map between a presentation element and a protocol element, and whether all of those mechanisms need to be standardized. The answer to the first is almost certainly no. There are some contexts where the UI aspects of a decent presentation element are just beyond the IETF's expertise. Taking even a simple protocol element like the scheme portion of an HTTP URI and determining how best to represent that in, say, modern Mongolian as used by the Oirat is no easy task. The monk who developed it didn't have URIs in mind when Clear Script was being developed. Should we recommend they use the Latin letters in consequence? or the Cyrillic alphabet (as many other Mongolian speakers do)? Is either really the right choice? Especially, is it the right choice for the IETF to take on? If it is not clear, I think the answer to the question of whether all presentation elements need to be standardized is "not in the IETF, anyway". I think the IETF does need to make sure that presentation elements can use the UCS in useful and reasonable ways. We have worked on that, and there continues to be work on that, largely through the efforts of dedicated individuals at this point, rather than working groups. We also have agreed, as a community, to take on work on some work that does not rely on a presentation layer separation from the protocol. We have agreed to work on email addresses, as one example, and that working group decided not to use a pure presentation layer approach: This working group will address one basic approach to email internationalization. That approach is based on the use of an SMTP extension to enable both the use of UTF-8 in envelope address local- parts and optionally in domain-parts and the use of UTF-8 in mail headers -- both in address contexts and wherever encoded-words are permitted today. Its initial target will be a set of experimental RFCs that specify the details of this approach and provide the basis for generating and testing interoperable implementations. Its work will include examining whether "downgrading" -- transforming an internationalized message to one that is compatible with unextended SMTP clients and servers and unextended MUAs -- is feasible and appropriate and, if it is, specifying a way to do so. If it is not, the WG will evaluate whether the effort is worth taking forward. Other approaches may be considered by the formation of other working groups. (see http://www.ietf.org/html.charters/eai-charter.html for the full context). There will be consequences for lots of other protocol slots if this experiment succeeds, as there are lots of places for which there is a tacit assumption that the identifier can "look like" an email identifier (think SIP AoR s and certs, to take two examples). But the changes needed to those slots and the changes needed to the URIs which refer to those (or the IRI representation of those URIs) may not be quite the same. I doubt this has helped much, honestly, but hopefully the urge to correct my mistakes will prompt others to step in and say something more useful. regards, Ted From discuss-bounces@apps.ietf.org Tue Oct 16 02:52:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhgGo-0001RL-4t; Tue, 16 Oct 2007 02:51:14 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IhgGl-0001Oa-FT for discuss-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 02:51:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhgGV-0001B3-Ap for discuss@apps.ietf.org; Tue, 16 Oct 2007 02:50:55 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhgGO-0006kD-VT for discuss@apps.ietf.org; Tue, 16 Oct 2007 02:50:55 -0400 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1IhgFe-0008K2-9F for discuss@apps.ietf.org; Tue, 16 Oct 2007 06:50:02 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Oct 2007 06:50:02 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Oct 2007 06:50:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: discuss@apps.ietf.org From: "Frank Ellermann" Subject: Re: draft-klensin-net-utf8-06 Date: Tue, 16 Oct 2007 08:45:39 +0200 Lines: 47 Message-ID: References: <93F25E18AB3DA3EB0599F092@p3.JCK.COM> <090481616F66605395036545@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org John C Klensin wrote: > when we start going into detail on how individual code points or > blocks are interpreted, we are getting into territory that is very > uncomfortable for me and, I believe, should be uncomfortable for > the IETF. Yes, I'm not proposing to make the TUS "newline guidelines" worse, they are already bad enough. But it's easy (at least for me) to forget the odd LS case, but "users" of the net-utf8 RFC have to be aware that LS exists (in addition to the controls already covered in your I-D). =20 Most "users" of net-utf8 will be protocol designers, they need to know some relevant TUS dragons like LS, NFC, annotations, language tags, etc. [[And when EAI moves to standard track in some years we have to do something about LS in display names and addresses, before it hits say mailto-ter IRIs]]. [various kinds of unassigned code points]=20 > The set of issues involved here is the reason that the "Stable > NF..." discussions started in the wake of some of the > pre-RFC4690 discussions a year or more ago. I think we should > continue to try very hard to avoid having it turn into an IETF > problem. +1 It might still make sense if the next TUS version identifies such "unnormal unassigned gaps", it could simplify the IDNAbis work (just an example). > And, when they make a mistake of sufficient importance, they=20 > reserve the right to change things. In some areas. Elsewhere they can't fix an obvious typo in a character name s/KC/CK/, and had to invent a "normative alias" mechanism to mitigate it. > I'd be happy to hear from others about this if people think > it is important enough to delay a last call still longer. Let's start with the BCP on unicode-escapes, they don't depend on the net-utf8 PS. If you don't care about LS at the moment you could also decree that it's a potential issue for a later DS, but I think adding some "there be dragons" note about LS to net-utf8 now could be simple. Certainly no showstopper. Frank From discuss-bounces@apps.ietf.org Tue Oct 16 04:13:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhhWX-0006vm-Eh; Tue, 16 Oct 2007 04:11:33 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IhhWW-0006rf-6M for discuss-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 04:11:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhhWV-0006rU-DO for discuss@apps.ietf.org; Tue, 16 Oct 2007 04:11:31 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhhWP-00013o-7N for discuss@apps.ietf.org; Tue, 16 Oct 2007 04:11:31 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 23DC71C00EA; Tue, 16 Oct 2007 10:11:14 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 1F5E81C00D8; Tue, 16 Oct 2007 10:11:14 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 1136D58ECCF; Tue, 16 Oct 2007 10:11:14 +0200 (CEST) Date: Tue, 16 Oct 2007 10:11:14 +0200 From: Stephane Bortzmeyer To: Frank Ellermann Subject: Re: draft-klensin-net-utf8-06 Message-ID: <20071016081114.GA4599@nic.fr> References: <93F25E18AB3DA3EB0599F092@p3.JCK.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, Oct 15, 2007 at 10:17:33AM +0200, Frank Ellermann wrote=20 a message of 51 lines which said: > I think you have to mention LS u+2028 and maybe also PS u+2029 > somewhere. <=FCber-troll>We should drop the ambiguous, old, ASCII and typewriter-specific CR and LF and standardize only the Unicode proper characters, PS and LS for Net-UTF8. #define TROLL 0 I suggest the following text in 2.1 "Definitions": For compatibility reasons with the oldest practice, the Unicode characters U+2028, Line separator, and U+2029, Paragraph separator, are similarly NOT RECOMMENDED. From discuss-bounces@apps.ietf.org Tue Oct 16 10:47:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhngN-0000dF-Bk; Tue, 16 Oct 2007 10:46:07 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IhngL-0000aU-2Q for discuss-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 10:46:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhngK-0000aD-4W for discuss@apps.ietf.org; Tue, 16 Oct 2007 10:46:04 -0400 Received: from smtp.denic.de ([81.91.161.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhngC-000700-QO for discuss@apps.ietf.org; Tue, 16 Oct 2007 10:46:04 -0400 Received: from notes.rz.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1Ihng2-0006lH-EC; Tue, 16 Oct 2007 16:45:46 +0200 To: discuss@apps.ietf.org Subject: Comments on draft-klensin-net-utf8-06 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 From: Marcos Sanz/Denic Message-ID: Date: Tue, 16 Oct 2007 16:45:38 +0200 X-MIMETrack: Serialize by Router on notes/Denic at 16.10.2007 16:45:46, Serialize complete at 16.10.2007 16:45:46 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org To my eyes the document is in good shape, but it still leaves one of the issues at stake partially open: Section 2, bullet 2 says "CR SHOULD NOT appear except when followed by LF". The last paragraph of the section 2 says "CR MUST NOT appear unless it is immediately followed by LF (...) or NUL". To me the first of these statements is much less restrictive than the second. Nitpicking: * Section 1.1: s/variable length/variable-length/ for coherence with other text appearances * Section 3: s/to convert all canonically equivalent sequences a single unique form/to convert all canonically equivalent sequences into a single unique form/ * Section 4: The definition of the normalization stability is misleading, actually even wrong. Old text: That is, if a string does not contain any unassigned characters, and it is normalized according to NFC, it will always be normalized according to all future versions of the Unicode Standard. Suggested text: That is, if a string does not contain any unassigned characters for a given version of Unicode, and it is normalized according to the definition of NFC in that version, it will always result in the same normalized string according to all future versions of the Unicode Standard. * Section 4: "the string order of RFC 3629". It's not very clear to me what is meant with this. Byte order? Sorting order? * Section 4: I would drop the last paragraph, since it is a repetition of what is exhaustively explained in section 5.2. I got a parsing error at the last sentence of that paragraph anyway. * Section 5.2: s/[RFC3454])/[RFC3454]),/ * Section 5.2, bullet 4: "This process has been discussed in the Unicode Consortium under the name 'Stable NFC'". That might very well be but the only hits I get when googling for that string are this very draft and some contributions of the draft author to some mailing lists. So I cast doubt on the utility of introducing this new term here which is a pointer to nowhere. Is this again referring to the normalization stability policy of unicode? http://unicode.org/standard/stability_policy.html Best regards, Marcos Sanz From discuss-bounces@apps.ietf.org Tue Oct 16 11:52:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihoi1-0005Hr-6I; Tue, 16 Oct 2007 11:51:53 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ihohy-0005EY-TS for discuss-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 11:51:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihohx-0005Bb-Tg for discuss@apps.ietf.org; Tue, 16 Oct 2007 11:51:49 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ihohn-00019W-Av for discuss@apps.ietf.org; Tue, 16 Oct 2007 11:51:49 -0400 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Ihohb-000EIL-KS; Tue, 16 Oct 2007 11:51:27 -0400 Date: Tue, 16 Oct 2007 11:51:27 -0400 From: John C Klensin To: "Marcos Sanz/Denic" , discuss@apps.ietf.org Subject: Re: Comments on draft-klensin-net-utf8-06 Message-ID: <1CEEB76FCFC0070A7B2BDEAE@[10.1.0.164]> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Tuesday, 16 October, 2007 16:45 +0200 "Marcos Sanz/Denic" wrote: > To my eyes the document is in good shape, but it still leaves > one of the issues at stake partially open: > > Section 2, bullet 2 says "CR SHOULD NOT appear except when > followed by LF". The last paragraph of the section 2 says "CR > MUST NOT appear unless it is immediately followed by LF (...) > or NUL". To me the first of these statements is much less > restrictive than the second. Marcos (and others who have been trapped by this), While I would welcome suggestions about other text and ways to organize this, the two statements are perfectly consistent with each other, not a more restrictive/ less restrictive contradiction. It won't fit with the existing text and layout in this form, but what is being said is: if there is a CR, it MUST be followed by either LF or NUL however, NUL SHOULD be avoided too, so CR LF is the only recommended context in which CR SHOULD be used. > Nitpicking: > > * Section 1.1: s/variable length/variable-length/ for > coherence with other text appearances fixed in working draft. > * Section 3: s/to convert all canonically equivalent sequences > a single unique form/to convert all canonically equivalent > sequences into a single unique form/ s/into/to/, but fixed. > * Section 4: The definition of the normalization stability is > misleading, actually even wrong. > > Old text: > > That is, if a string does not contain any unassigned > characters, and it is normalized according to NFC, it will > always be normalized according to all future versions of the > Unicode Standard. > > Suggested text: > > That is, if a string does not contain any unassigned > characters for a given version of Unicode, and it is > normalized according to > the definition of NFC in that version, it will always result > in the same normalized string according to all future > versions of the Unicode Standard. The text that was used was supplied by Mark Davis after my first attempt didn't come out right. I'm happy to put anything in there that people agree to be correct, but please sort this out with him and/or other UTC members. > * Section 4: "the string order of RFC 3629". It's not very > clear to me what is meant with this. Byte order? Sorting > order? 3629 specifies a byte order (in section 4). It does not address or mention sort order except to note (in the introduction) that UTF-8 preserves it and that sort order based on code point sequence is likely to be fairly useless. I _think_ I would welcome text to clarify this but please note that it is not likely to be possible to use this spec without understanding and following 3629 (that is what the normative reference is all about). So I am loathe to cover things that are well-covered in 3629 lest more confusion be created. > * Section 4: I would drop the last paragraph, since it is a > repetition of what is exhaustively explained in section 5.2. > I got a parsing error at the last sentence of that paragraph > anyway. Hmm. It parses for me. But I agree about the redundancy, except for that last sentence, which makes a normative assertion about this specification that does not appear in Section 5. That last sentence could be restated, less formally, as: If one encounters a UTF-8 string in a protocol, and its syntax and properties are not specifically defined, then it is reasonable to assume that it conforms to this specification. That assumption might, of course, be wrong, which is one reason it is important to be careful about having string-receivers assume that the string-transmitter normalized it. I would appreciate input from others about what to do about this. > * Section 5.2: s/[RFC3454])/[RFC3454]),/ It is correct as written ("..stored in normalized form if...") although the long parenthetical note is a little obnoxious. Suggestions welcome. > * Section 5.2, bullet 4: "This process has been discussed in > the Unicode Consortium under the name 'Stable NFC'". That > might very well be but the only hits I get when googling for > that string are this very draft and some contributions of the > draft author to some mailing lists. So I cast doubt on the > utility of introducing this new term here which is a pointer > to nowhere. Is this again referring to the normalization > stability policy of unicode? > http://unicode.org/standard/stability_policy.html No. I will recheck the terminology. I'm going to hold the document for a few days before re-posting in the hope of getting comments from others. thanks and regards, john From discuss-bounces@apps.ietf.org Tue Oct 16 12:41:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhpSb-0005VM-1l; Tue, 16 Oct 2007 12:40:01 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IhpSY-0005P2-E4 for discuss-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 12:39:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhpSX-000564-9A for discuss@apps.ietf.org; Tue, 16 Oct 2007 12:39:57 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhpSN-0002gs-2R for discuss@apps.ietf.org; Tue, 16 Oct 2007 12:39:53 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 790022F9; Tue, 16 Oct 2007 12:39:18 -0400 (EDT) Received: from MCQWP2 (ip72-197-112-82.sd.sd.cox.net [72.197.112.82]) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 23ED589D8C; Tue, 16 Oct 2007 12:39:16 -0400 (EDT) Date: Tue, 16 Oct 2007 09:38:53 -0700 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <50134794.20071016093853@pobox.com> To: Apps-Discusssion Subject: Re: draft-klensin-net-utf8-06 In-Reply-To: <93F25E18AB3DA3EB0599F092@p3.JCK.COM> References: <93F25E18AB3DA3EB0599F092@p3.JCK.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org In section 2.1, I understand that the ONLY way to indicate the end of a line, for text parsing purposes, is the pair . Any other appearance of either CR or LF, whether or not allowed by a SHOULD, MUST NOT be considered to be a "line-ending" and only can be considered as text mark up. For example, this sentence is a single, malformed line. Right? A typo: Appendix B, bullet 4, penultimate line: interpreted as one or spaces, but, in general, it cannot be ^ more -- Bill McQuillan From discuss-bounces@apps.ietf.org Wed Oct 17 02:25:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii2KR-00077w-L5; Wed, 17 Oct 2007 02:24:27 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ii2KQ-00076a-01 for discuss-confirm+ok@megatron.ietf.org; Wed, 17 Oct 2007 02:24:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii2KO-0006yQ-MZ for discuss@apps.ietf.org; Wed, 17 Oct 2007 02:24:24 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ii2KD-0007if-NH for discuss@apps.ietf.org; Wed, 17 Oct 2007 02:24:20 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ii2Jv-0002ht-OK for discuss@apps.ietf.org; Wed, 17 Oct 2007 06:23:55 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 17 Oct 2007 06:23:55 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 17 Oct 2007 06:23:55 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: discuss@apps.ietf.org From: "Frank Ellermann" Subject: Re: Comments on draft-klensin-net-utf8-06 Date: Wed, 17 Oct 2007 08:21:08 +0200 Lines: 67 Message-ID: References: <1CEEB76FCFC0070A7B2BDEAE@[10.1.0.164]> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org John C Klensin wrote: >> * Section 4: "the string order of RFC 3629". It's not very >> clear to me what is meant with this. Byte order? Sorting >> order? =20 > 3629 specifies a byte order (in section 4). It does not address > or mention sort order except to note (in the introduction) that > UTF-8 preserves it and that sort order based on code point > sequence is likely to be fairly useless. =20 > I _think_ I would welcome text to clarify this Please simplify the remark and remove one "that": -| Were Unicode to be changed in a way that violated these -| assumptions, i.e., that either invalidated the string order -| of RFC 3629 or that that changed the stability of NFC as -| stated above, this specification would not apply. +| Were Unicode to be changed in a way that violated these +| assumptions, i.e., that changed the stability of NFC as +| stated above, this specification would not apply. UTF-8 as specified in STD 63 is stable. =20 > So I am loathe to cover things that are well-covered in=20 > 3629 lest more confusion be created. Yes, just don't mention the "byte-value lexicographic sorting order of UTF-8 strings", it's covered in STD 63, and besides not very interesting. >> * Section 4: I would drop the last paragraph, since it is a >> repetition of what is exhaustively explained in section 5.2. >> I got a parsing error at the last sentence of that paragraph >> anyway. Indeed, that paragraph is unnecessary. I also can't parse its first sentence. > That last sentence could be restated, less formally, as: =20 > If one encounters a UTF-8 string in a protocol, and its > syntax and properties are not specifically defined, then > it is reasonable to assume that it conforms to this > specification. I still don't understand this. What is an UTF-8 string with "unspecified syntax" ? STD 63 specifies the syntax of UTF-8, anything not following this syntax is invalid. The net-utf8 I-D doesn't specify any default properties, what is an assumption that "unspecified properties" conform to net-utf8 supposed to do ? =20 If you're talking about unassigned code points please say so. In that case it's covered in 5.2, and you can simply delete the last paragraph of section 4. > I'm going to hold the document for a few days before=20 > re-posting in the hope of getting comments from others. Please update the [NFC] reference, s/March 2005/2006-10-12/ for the version belonging to TUS 5.0. Frank From discuss-bounces@apps.ietf.org Thu Oct 18 04:47:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiR02-0008FK-II; Thu, 18 Oct 2007 04:45:02 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IiQzy-00087n-G0 for discuss-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 04:44:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiQzw-00084R-Vc for discuss@apps.ietf.org; Thu, 18 Oct 2007 04:44:56 -0400 Received: from smtp.denic.de ([81.91.161.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiQzp-0007La-1u for discuss@apps.ietf.org; Thu, 18 Oct 2007 04:44:56 -0400 Received: from notes.rz.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1IiQze-0003f8-2s; Thu, 18 Oct 2007 10:44:38 +0200 In-Reply-To: <1CEEB76FCFC0070A7B2BDEAE@[10.1.0.164]> To: John C Klensin Subject: Re: Comments on draft-klensin-net-utf8-06 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 From: Marcos Sanz/Denic Message-ID: Date: Thu, 18 Oct 2007 10:44:30 +0200 X-MIMETrack: Serialize by Router on notes/Denic at 18.10.2007 10:44:37, Serialize complete at 18.10.2007 10:44:37 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org John, > While I would welcome suggestions about other text and ways to > organize this, What about making a forecasting note right away under bullet 2: OLD TEXT: CR SHOULD NOT appear except when followed by LF. SUGGESTED TEXT: CR SHOULD NOT appear except when followed by LF. The other only allowed appearance is in the combination CR NUL, which is not recommended (see note at the end of this section). There is a similar contradictory (less restrictive at the beginning and suddenly more restrictive at the end) situation in bullet 3. The first sentence goes [...] control characters (U+0000 to U+001F and U+007F to U+009F) SHOULD generally be avoided vs the last sentence the so-called "C1 Controls" (U+0080 through U+009F) MUST NOT appear This is the nightmare for any implementor. The double negation doesn't provide for clarity either. What about changing OLD TEXT: control characters (U+0000 to U+001F and U+007F to U+009F) SHOULD generally be avoided. SUGGESTED TEXT control characters (U+0000 to U+001F and U+007F) SHOULD NOT be used and the so-called "C1 controls" (U+0080 to U+009F) MUST NOT be used. Then you can drop the last sentence of the bullet. > > Suggested text: > > > > That is, if a string does not contain any unassigned > > characters for a given version of Unicode, and it is > > normalized according to > > the definition of NFC in that version, it will always result > > in the same normalized string according to all future > > versions of the Unicode Standard. > > The text that was used was supplied by Mark Davis after my first > attempt didn't come out right. He'll certainly know better. > > * Section 4: "the string order of RFC 3629". It's not very > > clear to me what is meant with this. Byte order? Sorting > > order? > > 3629 specifies a byte order (in section 4). It does not address > or mention sort order except to note (in the introduction) that > UTF-8 preserves it and that sort order based on code point > sequence is likely to be fairly useless. > > I _think_ I would welcome text to clarify this I support Frank's suggestion, which I'll copy here again for clarity: -| Were Unicode to be changed in a way that violated these -| assumptions, i.e., that either invalidated the string order -| of RFC 3629 or that that changed the stability of NFC as -| stated above, this specification would not apply. +| Were Unicode to be changed in a way that violated these +| assumptions, i.e., that changed the stability of NFC as +| stated above, this specification would not apply. And again, UTF-8 as specified in STD 63 is stable. > So I am loathe to cover things that > are well-covered in 3629 lest more confusion be created. We fully agree. I only think that the reference in the old text is not necessary. > > * Section 4: I would drop the last paragraph, since it is a > > repetition of what is exhaustively explained in section 5.2. > > I got a parsing error at the last sentence of that paragraph > > anyway. > > Hmm. It parses for me. But I agree about the redundancy, Ok, so we drop it. Now about the last sentence: > except for that last sentence, which makes a normative assertion > about this specification that does not appear in Section 5. > That last sentence could be restated, less formally, as: > > If one encounters a UTF-8 string in a protocol, and its > syntax and properties are not specifically defined, then > it is reasonable to assume that it conforms to this > specification. The old formulation mentioned "unidentified UTF-8 strings", the new formulation mentions a UTF-8 string with syntax and properties "not specifically defined". I am sure you have something in mind, but it still doesn't get through. And you are aiming at a normative assertion, then normative language should be used and not something vague like "it is reasonable to assume". Thanks and best regards, Marcos From discuss-bounces@apps.ietf.org Thu Oct 18 05:12:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiRQ5-0005g6-De; Thu, 18 Oct 2007 05:11:57 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IiRQ3-0005es-U1 for discuss-confirm+ok@megatron.ietf.org; Thu, 18 Oct 2007 05:11:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiRQ2-0005cR-MR for discuss@apps.ietf.org; Thu, 18 Oct 2007 05:11:54 -0400 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiRPz-0007xN-6o for discuss@apps.ietf.org; Thu, 18 Oct 2007 05:11:52 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id l9I9BS74004960Thu, 18 Oct 2007 09:11:28 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1IiRPb-000PjW-00; Thu, 18 Oct 2007 10:11:27 +0100 Date: Thu, 18 Oct 2007 10:11:27 +0100 From: "Clive D.W. Feather" To: Marcos Sanz/Denic Subject: Re: Comments on draft-klensin-net-utf8-06 Message-ID: <20071018091127.GE93739@finch-staff-1.thus.net> References: <1CEEB76FCFC0070A7B2BDEAE@[10.1.0.164]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Marcos Sanz/Denic said: > There is a similar contradictory (less restrictive at the beginning and > suddenly more restrictive at the end) situation in bullet 3. The first > sentence goes > > [...] control characters (U+0000 to U+001F and U+007F to U+009F) SHOULD > generally be avoided > > vs the last sentence > > the so-called "C1 Controls" (U+0080 through U+009F) MUST NOT appear [...] Agreed. In addition, at the end of item 2 of section 2: OLD TEXT: The newer control characters IND (U+0084) and NEL ("Next Line", U+0085) might have been used to disambiguate the various line-ending situations, but, because their use has not been established on the Internet and many protocols require CRLF, they SHOULD NOT be used. SUGGESTED TEXT: The newer control characters IND (U+0084) and NEL ("Next Line", U+0085) might have been used to disambiguate the various line-ending situations, but, because their use has not been established on the Internet, because many protocols require CRLF, and because they fall within the "C1 Control", they MUST NOT be used. Nit-pick: right at the end of section 2, NUL should be described as U+0000 and not as X'00' (a notation which isn't well-defined). Or, if you are trying to distinguish octets from characters, use the RFC 4234 notation of %x00. Similarly, at the end of appendix B, IAC should be %xFF. Incidentally, %xFE is also not a problem for UTF-8, and %xF5-FD are probably not problems. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | From discuss-bounces@apps.ietf.org Sun Oct 21 11:19:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjcXM-0000IS-MX; Sun, 21 Oct 2007 11:16:20 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IjcXJ-0000H6-5L for discuss-confirm+ok@megatron.ietf.org; Sun, 21 Oct 2007 11:16:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjcXI-0000Dk-EE for discuss@apps.ietf.org; Sun, 21 Oct 2007 11:16:16 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjcX7-0003mV-6x for discuss@apps.ietf.org; Sun, 21 Oct 2007 11:16:11 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IjcWd-0002UQ-GX for discuss@apps.ietf.org; Sun, 21 Oct 2007 15:15:35 +0000 Received: from du-017a-127.access.de.clara.net ([213.221.75.127]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 21 Oct 2007 15:15:35 +0000 Received: from nobody by du-017a-127.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 21 Oct 2007 15:15:35 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: discuss@apps.ietf.org From: "Frank Ellermann" Subject: Re: Protocol Action: 'Augmented BNF for Syntax Specifications: ABNF' to Full Standard Date: Sun, 21 Oct 2007 17:15:14 +0200 Organization: http://purl.net/xyzzy Lines: 14 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: du-017a-127.access.de.clara.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org The IESG wrote: > as a Full Standard Thanks to Lisa, John, Julian, Dave, and all others... =20 > Technical Summary > This is ABNF. We use it in our RFCs. =20 ...indeed. While the 4234bis procedure turned out to be less "KISS" than this summary the STD will be fine. And maybe it's even important enough to justify a new STD 1. Frank From discuss-bounces@apps.ietf.org Mon Oct 22 06:26:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjuSK-0001P7-0j; Mon, 22 Oct 2007 06:24:20 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IjuSI-0001Jg-Hg for discuss-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 06:24:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjuSH-00016w-KF for discuss@apps.ietf.org; Mon, 22 Oct 2007 06:24:17 -0400 Received: from wa-out-1112.google.com ([209.85.146.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjuS7-0000Iq-BP for discuss@apps.ietf.org; Mon, 22 Oct 2007 06:24:13 -0400 Received: by wa-out-1112.google.com with SMTP id m16so1268396waf for ; Mon, 22 Oct 2007 03:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=sMgcIt3jVMM4zPMlxbn6XWuRwa4Ux4lnzBbTjFWclHM=; b=HoTMUqG+nwXNOptWNNzCDQk9unrkPrLbRaLLGD5ucMmaiAC3XkcjJgBUo5y5Hazq2hcZBs/fM2+RQWbFjdGLV0cWNJPycEzfkSZ9+W5JqNq7FPjWh4W2TaBYoLY8e2NPLXcBb5i1e5zkND/J9MuFzfOgu0UmnSWhIl1um6OOGB4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=LCHBnTaMK3wVCGINECXxvMtNc4go8J7EQGCu55JFH0WPxyHgS+C9DV0OYiFVwunWiw1As6ThFWGE/aqLdsA6gfEeSTS7EHtLCdrkYspP0ueLEYbHZBTGBkNTO+hhBfMt1cA30wGDuBVV7vMDCMJC0OIqlBf/zdW0npSBAn+IRJM= Received: by 10.114.181.6 with SMTP id d6mr5074621waf.1193048601125; Mon, 22 Oct 2007 03:23:21 -0700 (PDT) Received: by 10.114.161.15 with HTTP; Mon, 22 Oct 2007 03:23:21 -0700 (PDT) Message-ID: <517bf110710220323l493c61ccrcc2d72ee3801f60a@mail.gmail.com> Date: Mon, 22 Oct 2007 03:23:21 -0700 From: "Tim Bray" To: "John C Klensin" Subject: Re: draft-klensin-net-utf8-06 In-Reply-To: <93F25E18AB3DA3EB0599F092@p3.JCK.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <93F25E18AB3DA3EB0599F092@p3.JCK.COM> X-Google-Sender-Auth: f64a5dc8cce079ba X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tbray@textuality.com List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org My apologies for arriving late to the party. I got on a trans-Pacific flight with the draft in a browser window, but unfortunately not much else of the conversation, so this may be duplicative. This review of the draft raises, with one exception, issues of style and explication, and only one of these seems really serious to me: the term "code point" needs to be introduced early in the document to facilitate its use later; you really can't talk about Unicode intelligently without flinging the term around. I have one material point: standardizing on CRLF, rather than LF, for line-ending, seems questionable: - Lots of payload formats have their own rules about line ends; it's not clear to me that coupling line-ending rules to character-encoding rules is natural or beneficial. - XML, which constitutes a noticeable proportion of Internet protocol payloads, allows CRLF but requires parsers to convert it to LF before passing it on to the software. So this choice is going to waste (an admittedly small amount of) space and require extra data processing; the cost of not being able to pass a buffer-full of text to the receiving program without performing the CRLF->LF mapping and thus necessitating an additional copy of each byte seems to me worth worrying about. Now to style points: Section 1.1 "Historically, the Internet has been largely ASCII-based" I suggest "Historically, Internet protocols have been largely ASCII-based." The actual payload of the Internet has contained a high volume of non-English (and thus necessarily non-ASCII) text for some decades now. For reasons of brevity and clarity, I'd simply remove the following, which bulks up the paragraph and doesn't really add much value: "and no longer need to deal with per-script standards for character sets (e.g., one standard for each of Arabic, Cyrillic, Devanagari, etc., or even standards keyed to languages that are usually considered to share a script, such as French, German, or Swedish). " Here's a proposed slight redraft of the text introducing the encodings, which provides a bit of motivation, usefully introduces the term "code point", and is more precise: Unicode identifies each character by an integer, called its "code point", in the range 0-0x10ffff. These integers can be encoded into byte sequences for transmission in at least three standard and generally-recognized encoding forms, all of which are completely defined in The Unicode Standard and the documents cited below: - UTF-8 [RFC3629] defines a variable-length encoding that may be applied uniformly to all code points. - UTF-16 [RFC271] encodes the range of Unicode characters whose code points are less than 65536 straightforwardly as 16-bit integers, and provides a "surrogate" mechanism for encoding larger code points in 32 bits. - UTF-32 (also known as UCS-4) simply encodes each code point as a 32-bit integer. Section 2. "Characters must be coded"... would "encoded" be more consistent with usage elsewhere? " 2. Line-endings MUST be indicated by the sequence Carriage-Return (CR, U+000D) followed by Line-Feed (LF, U+000A), often known just as CRLF. " See above. " 5. As suggested in Section 6 of RFC 3629, the Byte Order Mark ("BOM") signature MUST NOT appear at the beginning of these text strings." It might be worth adding a note something along these lines: "The BOM is useful in establishing the endian-ness of UTF-16 and UTF-32 encodings, but serves no useful purpose in the context of UTF-8." "Systems conforming to this specification MUST NOT transmit any string containing any code point" - This is the first appearance of the term "code point", which needs defining. The edit I suggested above for section 1 would fix this. - Also, this sentence (which is important) seems to sit uneasily in this section about NFC; I would hoist it and promote it to near the top of section 2. Section 6. "The same security issues that apply to UTF-8, as discussed in [RFC3629], could be argued to apply to this standard form," That last clause is klunky, how about: "It could be argued that the same issues that apply to UTF-8, as discussed in [RFC3629], apply to this specification." Generally: I'd ruthlessly whack about 80% of the history and suchlike explication. Future consumers of this document, of which I predict there will be many, will need to consult and then cite the meat: "Unicode characters, UTF-8 encoding, NFC normalization upstream, be careful about Unicode versioning", and will benefit from some explanation of the technical advantages of the choices. The rest is of questionable value. -Tim From discuss-bounces@apps.ietf.org Mon Oct 22 06:38:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijuev-0004Mn-CR; Mon, 22 Oct 2007 06:37:21 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ijueu-0004IQ-7t for discuss-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 06:37:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijuet-00048R-7y for discuss@apps.ietf.org; Mon, 22 Oct 2007 06:37:19 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ijuej-0000qz-DN for discuss@apps.ietf.org; Mon, 22 Oct 2007 06:37:15 -0400 Received: (qmail invoked by alias); 22 Oct 2007 10:36:42 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.87]) [217.91.35.233] by mail.gmx.net (mp034) with SMTP; 22 Oct 2007 12:36:42 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19xU1Ii4Ulx/+xIu0hdUzZ0wTM2kmWuvr4kOCDdqJ S5VrSN8M6o1aBn Message-ID: <471C7D34.2000204@gmx.de> Date: Mon, 22 Oct 2007 12:36:36 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: tbray@textuality.com Subject: Re: draft-klensin-net-utf8-06 References: <93F25E18AB3DA3EB0599F092@p3.JCK.COM> <517bf110710220323l493c61ccrcc2d72ee3801f60a@mail.gmail.com> In-Reply-To: <517bf110710220323l493c61ccrcc2d72ee3801f60a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Tim Bray wrote: > ... > " 5. As suggested in Section 6 of RFC 3629, the Byte Order Mark > ("BOM") signature MUST NOT appear at the beginning of these text > strings." > > It might be worth adding a note something along these lines: "The BOM > is useful in establishing the endian-ness of UTF-16 and UTF-32 > encodings, but serves no useful purpose in the context of UTF-8." > ... The BOM doesn't server any purpose *here* (because we know it's UTF-8). In general, a BOM starting a UTF-8 encoded octet stream can be a useful hint to the recipient if out-of-band encoding information has been lost (such as when storing an HTTP response body in a simple file). Best regards, Julian From discuss-bounces@apps.ietf.org Mon Oct 22 07:49:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijvlu-0000cN-1r; Mon, 22 Oct 2007 07:48:38 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ijvls-0000bJ-4P for discuss-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 07:48:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijvlr-0000ac-79 for discuss@apps.ietf.org; Mon, 22 Oct 2007 07:48:35 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ijvlj-00045J-OE for discuss@apps.ietf.org; Mon, 22 Oct 2007 07:48:33 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IjvlJ-0008Ae-RP for discuss@apps.ietf.org; Mon, 22 Oct 2007 11:48:01 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Oct 2007 11:48:01 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Oct 2007 11:48:01 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: discuss@apps.ietf.org From: "Frank Ellermann" Subject: Re: draft-klensin-net-utf8-06 Date: Mon, 22 Oct 2007 13:45:18 +0200 Lines: 44 Message-ID: References: <93F25E18AB3DA3EB0599F092@p3.JCK.COM> <517bf110710220323l493c61ccrcc2d72ee3801f60a@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Tim Bray wrote: > - Lots of payload formats have their own rules about line ends The draft is about Internet protocols based on or closely related to "telnet" like "whois", it's not about payload formats like XML. [your "code point" proposal] > introduces the term "code point", and is more precise: >| Unicode identifies each character by an integer, called its >| "code point", in the range 0-0x10ffff. That might backfire, not all code points are characters, and not all abstract characters can be encoded by a single code point. The glossary in TUS 5.0 offers: | Code point: Any value in [...] the range of integers from 0 | to 10FFFF [hex.].=20 =20 [BOM] > It might be worth adding a note something along these lines: "The > BOM is useful in establishing the endian-ness of UTF-16 and UTF-32 > encodings, but serves no useful purpose in the context of UTF-8." It's an important "signature" for plain text files on platforms=20 where UTF-8 is not the local codepage. One of these platforms is quite popular. :-) For the purpose of the net-utf8 I-D just saying NO to BOMs is IMO good enough, RFC 3629 contains the fine print. > I'd ruthlessly whack about 80% of the history and suchlike > explication. Oops, no, the history is essential to understand old telnet issues like IAC without reading pre-historic RFCs with numbers below 821. > Future consumers of this document, of which I predict there will > be many, will need to consult and then cite the meat I think the future consumers are standard developers and protocol designers trying to update say RFC 3912. Appendix C lists future work, indirectly that defines the main audience for net-utf8. Frank From discuss-bounces@apps.ietf.org Mon Oct 22 15:11:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik2dy-0003YI-JU; Mon, 22 Oct 2007 15:08:54 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Ik2dx-0003Wa-EU for discuss-confirm+ok@megatron.ietf.org; Mon, 22 Oct 2007 15:08:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik2dw-0003VB-Fj for discuss@apps.ietf.org; Mon, 22 Oct 2007 15:08:52 -0400 Received: from ppsw-8.csi.cam.ac.uk ([131.111.8.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ik2c1-0002eF-3A for discuss@apps.ietf.org; Mon, 22 Oct 2007 15:08:52 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:35959) by ppsw-8.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1Ik2bf-00036E-Qx (Exim 4.67) (return-path ); Mon, 22 Oct 2007 20:06:31 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Ik2bf-0000tR-B3 (Exim 4.67) (return-path ); Mon, 22 Oct 2007 20:06:31 +0100 Date: Mon, 22 Oct 2007 20:06:31 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Frank Ellermann Subject: Re: draft-klensin-net-utf8-06 In-Reply-To: Message-ID: References: <93F25E18AB3DA3EB0599F092@p3.JCK.COM> <517bf110710220323l493c61ccrcc2d72ee3801f60a@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, 22 Oct 2007, Frank Ellermann wrote: > Tim Bray wrote: > > > I'd ruthlessly whack about 80% of the history and suchlike > > explication. > > Oops, no, the history is essential to understand old telnet issues > like IAC without reading pre-historic RFCs with numbers below 821. I also like the historical appendix. Tony. -- f.a.n.finch http://dotat.at/ SOUTHEAST ICELAND: NORTHERLY 5 AT FIRST IN EAST, OTHERWISE SOUTHEASTERLY 4 OR 5 INCREASING 6 OR 7. MODERATE OR ROUGH. RAIN LATER. GOOD, OCCASIONALLY MODERATE LATER. From discuss-bounces@apps.ietf.org Tue Oct 23 04:05:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkEkM-0007Rp-Dv; Tue, 23 Oct 2007 04:04:18 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IkEkK-0007RH-G1 for discuss-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 04:04:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkEkJ-0007Qw-CD for discuss@apps.ietf.org; Tue, 23 Oct 2007 04:04:15 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkEkC-0002JW-IO for discuss@apps.ietf.org; Tue, 23 Oct 2007 04:04:15 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l9N83RQs002456 for ; Tue, 23 Oct 2007 17:03:28 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 4983_6fd293dc_813e_11dc_94e6_0014221f2a2d; Tue, 23 Oct 2007 17:03:27 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:33943) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 23 Oct 2007 16:59:52 +0900 Message-Id: <6.0.0.20.2.20071023164439.09110ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 23 Oct 2007 16:58:39 +0900 To: Ted Hardie , Thomas Narten , discuss@apps.ietf.org From: Martin Duerst Subject: Re: internationalization of URIs In-Reply-To: References: <200710151939.l9FJdIkM003350@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: public-iri@w3.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hello Ted, Many thanks for your contribution. I'm cc'ing it (with my comments interspersed) to the public-iri@w3.org mailing list. At 14:01 07/10/16, Ted Hardie wrote: >At 3:39 PM -0400 10/15/07, Thomas Narten wrote: >>As some of you may know, as part of testing the readiness of IDNs, >>ICANN has inserted a set of internationalized versions of ".test" into >>the root zone of the DNS. See >>http://www.icann.org/announcements/announcement-15oct07.htm for >>details. >> >>One of the questions that this has prompted (again) is what about that >>pesky "http:", that still needs to typed in ascii. And what about the >>rest of the URL for that matter. > >So, I've read Martin's answer, but I'd like to take a shot at this from >a slightly different angle. Inside the IETF, we commonly treat IRIs >as a presentation layer for URIs. There is a URI form for any IRI >(and all URIs are also IRIs), so it is always possible to "stick to" the >URI as the protocol element and as use IRIs as presentation elements. >(The big exception to this is inside XML, where the "anyURI" element >got deployed with a syntax that didn't really match URIs at all; >the result is that those strings (which appear to be IRIs to the casual >observer) are really protocol elements using different rules than >those normally used by URIs.) Some additonal comments: - Atom, as an IETF standard, is an example where the IETF uses IRIs as protocol elements. Atom is also XML-based, so this doesn't contradict the above, but I just wanted to mention this for people who might think, from the above, the the IETF doesn't use IRIs. - RDF, whether written in XML or not, also uses IRIs. Because of the way RDF compares resource identifiers, converting from IRIs to URIs isn't a good idea in the case of RDF. - There is in principle nothing that would prevent the IETF from using IRIs as protocol elements in a new protocol. In my opinion, this would actually be the right thing. The conversion to URIs as protocol elements is there first and foremost for existing protocols that are based on URIs. >When I read Martin's comments about drop-downs, elided scheme >names, and similar tricks, my protocol-geek hat tightened on my head >and gave me a pretty severe headache. Taking it off for a moment, >though, showed me things are still okay. As presentation elements, >things like drop-downs, inference of scheme by an initial www, and >similar tricks are more reasonable. Detail: the scheme isn't inferenced by an initial www. A very quick test on one single browser showed that a leading 'ftp' label inferences ftp://, but there is no need for an initial www to infer http://. In general, yes, all these tricks are very much presentation issues. Overall, we can think about this in three layers: Final presentation: May include tricks as above,... IRI: sometimes protocol, sometimes presentation URI: protocol >A big question, then, is whether we have all the bits >we need to map between a presentation element and a protocol element, >and whether all of those mechanisms need to be standardized. >The answer to the first is almost certainly no. I fully agree. >There are some contexts >where the UI aspects of a decent presentation element are just beyond >the IETF's expertise. Taking even a simple protocol element like >the scheme portion of an HTTP URI and determining how best to represent >that in, say, modern Mongolian as used by the Oirat is no easy task. The monk >who developed it didn't have URIs in mind when Clear Script was being >developed. Should we recommend they use the Latin letters in consequence? or >the Cyrillic alphabet (as many other Mongolian speakers do)? Is either >really the right choice? Especially, is it the right choice for the IETF >to take on? > >If it is not clear, I think the answer to the question of whether all >presentation >elements need to be standardized is "not in the IETF, anyway". I think the IETF >does need to make sure that presentation elements can use the UCS in useful >and reasonable ways. We have worked on that, and there continues to be work on >that, largely through the efforts of dedicated individuals at this point, >rather than working groups. > >We also have agreed, as a community, to take on work on some work >that does not rely on a presentation layer separation from the protocol. >We have agreed to work on email addresses, as one example, >and that working group decided not to use a pure presentation layer >approach: Yes. I expect this way of designing protocols to become more frequent. For new protocols, for me, it would be a non-brainer. For existing protocols, the decision is of course much more difficult, and will once go one way, and once the other way. >This working group will address one basic approach to email >internationalization. That approach is based on the use of an SMTP >extension to enable both the use of UTF-8 in envelope address local- >parts and optionally in domain-parts and the use of UTF-8 in mail >headers -- both in address contexts and wherever encoded-words are >permitted today. Its initial target will be a set of experimental >RFCs that specify the details of this approach and provide the basis >for generating and testing interoperable implementations. Its work >will include examining whether "downgrading" -- transforming an >internationalized message to one that is compatible with unextended >SMTP clients and servers and unextended MUAs -- is feasible and >appropriate and, if it is, specifying a way to do so. If it is not, >the WG will evaluate whether the effort is worth taking forward. >Other approaches may be considered by the formation of other >working groups. > > (see http://www.ietf.org/html.charters/eai-charter.html for >the full context). There will be consequences for lots of >other protocol slots if this experiment succeeds, as there >are lots of places for which there is a tacit assumption that >the identifier can "look like" an email identifier (think SIP >AoR s and certs, to take two examples). But the changes needed >to those slots and the changes needed to the URIs which refer >to those (or the IRI representation of those URIs) may not be quite >the same. > >I doubt this has helped much, honestly, but hopefully the urge >to correct my mistakes will prompt others to step in and say >something more useful. > regards, > Ted I think this was very useful background, thanks a lot. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From discuss-bounces@apps.ietf.org Wed Oct 24 13:57:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkkSb-0000Ln-B6; Wed, 24 Oct 2007 13:56:05 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IkkSa-0000Lh-1j for discuss-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 13:56:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkkSZ-0000Kj-O2 for discuss@apps.ietf.org; Wed, 24 Oct 2007 13:56:03 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkkST-0007kA-FN for discuss@apps.ietf.org; Wed, 24 Oct 2007 13:56:03 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9OHtkh7013318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Oct 2007 10:55:46 -0700 Received: from [98.207.5.180] (carbuncle.qualcomm.com [129.46.226.27]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9OHthWC029003; Wed, 24 Oct 2007 10:55:44 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <6.0.0.20.2.20071023164439.09110ec0@localhost> References: <200710151939.l9FJdIkM003350@localhost.localdomain> <6.0.0.20.2.20071023164439.09110ec0@localhost> Date: Wed, 24 Oct 2007 10:55:43 -0700 To: Martin Duerst , Thomas Narten , discuss@apps.ietf.org From: Ted Hardie Subject: Re: internationalization of URIs Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -4.0 (----) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: public-iri@w3.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi Martin, Some comments below. I've kept your distribution, but I'd suggest we pick a place to continue discussion; suggest public-iri for followups. > >- There is in principle nothing that would prevent the IETF from > using IRIs as protocol elements in a new protocol. In my opinion, > this would actually be the right thing. The conversion to URIs > as protocol elements is there first and foremost for existing > protocols that are based on URIs. I agree that there is nothing to prevent the IETF from using IRIs as protocol elements. For the large majority of IETF protocols, though, this isn't the optimal choice. For most protocol slots, the aim isn't to present the element to a human, but to enable protocol processing to proceed in a deterministic way. This means that most protocol slots don't benefit in any meaningful way from the greatly increased set of unreserved characters. IRIs do introduce increased complexity in protocol processing (I believe your "Ladder of comparison" section describes some of the most critical ways), and when this is not needed because of human interaction it is simpler to avoid it. Any protocol that wishes to use IRIs is also strongly advised to take into account what restrictions of the UCS it wishes to make; as you point out in IRI-bis, section 6.1, a scheme-specific definition or processor may need to make a number of rules that exclude look-alikes in both characters and delims. Those will add increased complexity as well, especially if they vary from scheme to scheme. > >>When I read Martin's comments about drop-downs, elided scheme >>names, and similar tricks, my protocol-geek hat tightened on my head > >and gave me a pretty severe headache. Taking it off for a moment, > >though, showed me things are still okay. As presentation elements, >>things like drop-downs, inference of scheme by an initial www, and >>similar tricks are more reasonable. > >Detail: the scheme isn't inferenced by an initial www. A very quick >test on one single browser showed that a leading 'ftp' label inferences >ftp://, but there is no need for an initial www to infer http://. I actually didn't mean in browser behavior; sorry for being unclear. I mean that humans see "www" now and assume that they should plug it into a web browser; "infer a scheme" was probably not the ideal way of describing that, since most users don't think of the scheme in that process (though many browsers do prepend the scheme in final display). > >We also have agreed, as a community, to take on work on some work >>that does not rely on a presentation layer separation from the protocol. >>We have agreed to work on email addresses, as one example, >>and that working group decided not to use a pure presentation layer >>approach: > >Yes. I expect this way of designing protocols to become more frequent. >For new protocols, for me, it would be a non-brainer. For existing >protocols, the decision is of course much more difficult, and >will once go one way, and once the other way. For new protocol slots that will be exposed to humans, I agree that this will be more frequent. The tricky bit is always figuring out what will be. Thanks for your comments, regards, Ted