From discuss-bounces@apps.ietf.org Wed Jan 03 16:03:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2DF8-0000TQ-MF; Wed, 03 Jan 2007 16:01:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2DF8-0000TG-3N for discuss@apps.ietf.org; Wed, 03 Jan 2007 16:01:50 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2DF5-00076N-IK for discuss@apps.ietf.org; Wed, 03 Jan 2007 16:01:50 -0500 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DF3D0142258; Wed, 3 Jan 2007 13:01:44 -0800 (PST) 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 10400-10; Wed, 3 Jan 2007 13:01:44 -0800 (PST) Received: from [192.168.1.101] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id BE0E1142256; Wed, 3 Jan 2007 13:01:43 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: Content-Type: multipart/alternative; boundary=Apple-Mail-14-572340620 To: Apps Discuss , Lisa Dusseault's Chairs Subject: Lisa's Apps Area Activity for December 2006 From: Lisa Dusseault Date: Wed, 3 Jan 2007 13:01:41 -0800 X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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-14-572340620 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Document Status and progress Active documents: - ABNF (RFC 4234) did a last call on Dec 11; got comments and currently discussing with authors - WIDEX Requirements (draft-ietf-widex-requirements): did a last call which ended Dec 25, got comments from David Black (Gen-art reviewer) and discussing with authors - draft-ietf-atompub-protocol-12: need to review changes against my comments - SMTP Auth (draft-siemborski-rfc2554bis) and POP3 Auth (draft- siemborski-1734bis): agreed to shepherd; currently discussing what Mandatory-to-Implement authentication mechanism is best. - draft-snell-atompub-feed-license: tried to get comments from IETF- last-call reviewers on new version... - draft-nottingham-atompub-feed-history: I'm behind on reviewing this one Stalled documents (next action is not in my court): - draft-ietf-usefor-usefor: waiting to see how progress on WG's usepro document turns out and whether a normative dependency there is the right thing to add to usefor. - draft-ietf-imapext-sort: Waiting for BASIC collation draft to progress - draft-ietf-imapext-annotate: waiting for RFC Ed notes from authors to finalize approval - draft-ietf-sieve-3028bis: waiting for another version with IANA considerations - draft-gulbrandsen-collation-basic: need new version WGs ATOMPUB: Discussing some draft -12 protocol issues and media types related to atom format RFC CALSIFY: somewhat of slowdown over holidays. IMAPEXT: New version of draft-ietf-imapext-i18n but otherwise quiet SIEVE: WGLC on draft-ietf-sieve-notify USEFOR: Great active discussion on protocol document edited by Russ Allbery. WIDEX: Will close WG once requirements draft is published. Other Apps Area Activity HTTP: participants are thinking of BOF so need to determine what scope of a WG would be State-machines: Stephane Bortzmeyer started a list to prepare a BOF on state-machine description languages Email server event notifications: discussion at notifications@ietf.org about requirements and use cases arising from Lemonade and elsewhere. SMTP/RFC2821, advancement to Draft Standard: some discussion at ietf- smtp@imc.org, volunteer draft editor found URI Templates: interesting discussions at uri@w3.org Lisa --Apple-Mail-14-572340620 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Document = Status and progress

Active = documents:
=A0- ABNF (RFC 4234) did=A0 a last call on=A0Dec = 11; got comments and currently discussing with authors
=A0- = WIDEX Requirements (draft-ietf-widex-requirements): did a last call = which ended Dec 25, got comments from David Black (Gen-art reviewer) and = discussing with authors
=A0- draft-ietf-atompub-protocol-12: = need to review changes against my comments
=A0- SMTP Auth = (draft-siemborski-rfc2554bis) and POP3 Auth (draft-siemborski-1734bis): = agreed to shepherd; currently discussing what Mandatory-to-Implement = authentication mechanism is = best.=A0
=A0-=A0draft-snell-atompub-feed-license: tried to get = comments from IETF-last-call reviewers on new = version...=A0
=A0-=A0draft-nottingham-atompub-feed-history: = I'm behind on reviewing this one

Stalled documents (next = action is not in my court):
=A0- draft-ietf-usefor-usefor: = waiting to see how progress on WG's usepro document turns out and = whether a normative dependency there is the right thing to add to = usefor.
=A0- draft-ietf-imapext-sort: Waiting for BASIC = collation draft to progress
=A0- draft-ietf-imapext-annotate: = waiting for RFC Ed notes from authors to finalize approval
=A0- = draft-ietf-sieve-3028bis: waiting for another version with IANA = considerations
=A0-=A0draft-gulbrandsen-collation-basic: need = new version

WGs

ATOMPUB: Discussing some = draft -12 protocol issues and media types related to atom format = RFC
CALSIFY: somewhat of slowdown over = holidays.
IMAPEXT: New version of draft-ietf-imapext-i18n but = otherwise quiet
SIEVE: WGLC on = draft-ietf-sieve-notify
USEFOR: Great active discussion on = protocol document edited by Russ Allbery.
WIDEX: Will close WG = once requirements draft is published.

Other Apps Area = Activity

HTTP: participants are = thinking of BOF so need to determine what scope of a WG would = be
State-machines:=A0 Stephane Bortzmeyer started a list to = prepare a BOF on state-machine description languages
Email = server event notifications: discussion at notifications@ietf.org about = requirements and use cases arising from Lemonade and = elsewhere.
SMTP/RFC2821, advancement to Draft Standard: some = discussion at =A0ietf-smtp@imc.org,= volunteer draft editor found
URI Templates: interesting = discussions at=A0uri@w3.org

Lisa
= --Apple-Mail-14-572340620-- From discuss-bounces@apps.ietf.org Fri Jan 05 22:08:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H31tR-00088T-Ux; Fri, 05 Jan 2007 22:06:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H31tQ-00088K-M2 for discuss@apps.ietf.org; Fri, 05 Jan 2007 22:06:48 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H31tP-0003xh-40 for discuss@apps.ietf.org; Fri, 05 Jan 2007 22:06:48 -0500 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 82914142267 for ; Fri, 5 Jan 2007 19:06:44 -0800 (PST) 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 15139-07 for ; Fri, 5 Jan 2007 19:06:43 -0800 (PST) Received: from [192.168.1.101] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D28A4142266 for ; Fri, 5 Jan 2007 19:06:42 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.2) To: Apps Discuss Message-Id: <09D1FD62-D1E0-4310-B4B2-D73DA2B59B11@osafoundation.org> Content-Type: multipart/alternative; boundary=Apple-Mail-30-767038995 References: <20070105202532.GA24058@sources.org> From: Lisa Dusseault Subject: Fwd: New mailing list: language for IETF state machines Date: Fri, 5 Jan 2007 19:06:39 -0800 X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 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-30-767038995 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed FYI Lisa Begin forwarded message: > From: Stephane Bortzmeyer > Date: January 5, 2007 12:25:32 PM PST > To: ietf@ietf.org > Subject: New mailing list: language for IETF state machines > > While IETF has a formal standardized language to describe grammars > (ABNF, in RFC 4234), it has no language to describe state machines, > leaving authors to use tables or list of transitions or ASCII-art > (which leads some people to ask for a "richer" format for RFCs). > > I believe it would be a good idea to have such a language (see > http://www1.ietf.org/mail-archive/web/ietf/current/msg42592.html for a > rationale) so I wrote an Internet-draft > (draft-bortzmeyer-language-state-machines-01.txt) describing a > candidate, Cosmogol (further documented in http://www.cosmogol.fr/). > > There is now a mailing list, to see if there is sufficient interest > for the IETF to go on, have a BoF in Prague, may be create a Working > Group, etc: > > cosmogol@ietf.org > > https://www1.ietf.org/mailman/listinfo/cosmogol > > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf --Apple-Mail-30-767038995 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 FYI=A0

Lisa

Begin = forwarded message:

From: = Stephane Bortzmeyer <bortzmeyer@nic.fr>
Date: = January 5, 2007 12:25:32 PM PST
Subject: = New mailing list: language for IETF state = machines
While IETF has a formal = standardized language to describe grammars
(ABNF, = in RFC 4234), it has no language to describe state machines,
leaving authors to use tables or list of transitions = or ASCII-art
(which leads some people to ask = for a "richer" format for RFCs).

I believe it would be a good = idea to have such a language (see
rationale) so I wrote an = Internet-draft
candidate, Cosmogol (further documented in http://www.cosmogol.fr/).

There is = now a mailing list, to see if there is sufficient interest
for the IETF to go on, have a BoF in Prague, may be = create a Working
Group, etc:






Ietf mailing list
=

= --Apple-Mail-30-767038995-- From discuss-bounces@apps.ietf.org Sat Jan 06 10:04:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3D4t-0007aL-Kv; Sat, 06 Jan 2007 10:03:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3ArE-0006gy-Qn for discuss@ietf.org; Sat, 06 Jan 2007 07:41:08 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3AmT-0005iF-1Q for discuss@ietf.org; Sat, 06 Jan 2007 07:36:18 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 7340326C0B6 for ; Sat, 6 Jan 2007 13:36:03 +0100 (CET) X-Virus-Scanned: by amavisd-new at mx2.nic.fr Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id C00DC26C156 for ; Sat, 6 Jan 2007 13:36:00 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id B385358EBC3 for ; Sat, 6 Jan 2007 13:36:00 +0100 (CET) Date: Sat, 6 Jan 2007 13:36:00 +0100 From: Stephane Bortzmeyer To: discuss@ietf.org Subject: New mailing list: language for IETF state machines Message-ID: <20070106123600.GA29785@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.17-2-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: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Sat, 06 Jan 2007 10:03:22 -0500 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 While IETF has a formal standardized language to describe grammars (ABNF, in RFC 4234), it has no language to describe state machines, leaving authors to use tables or list of transitions or ASCII-art (which leads some people to ask for a "richer" format for RFCs). I believe it would be a good idea to have such a language (see http://www1.ietf.org/mail-archive/web/ietf/current/msg42592.html for a rationale) so I wrote an Internet-draft (draft-bortzmeyer-language-state-machines-01.txt) describing a candidate, Cosmogol (further documented in http://www.cosmogol.fr/). There is now a mailing list, to see if there is sufficient interest for the IETF to go on, have a BoF in Prague, may be create a Working Group, etc: cosmogol@ietf.org https://www1.ietf.org/mailman/listinfo/cosmogol From discuss-bounces@apps.ietf.org Fri Jan 19 10:36:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7vlB-0001CT-9L; Fri, 19 Jan 2007 10:34:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7vlA-0001C1-2i for discuss@apps.ietf.org; Fri, 19 Jan 2007 10:34:32 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7vl8-0001H9-Bl for discuss@apps.ietf.org; Fri, 19 Jan 2007 10:34:32 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1H7vl6-00067b-8v for discuss@apps.ietf.org; Fri, 19 Jan 2007 10:34:28 -0500 Date: Fri, 19 Jan 2007 10:34:27 -0500 From: John C Klensin To: discuss@apps.ietf.org Subject: FWD: I-D ACTION:draft-klensin-unicode-escapes-00.txt Message-ID: <891E235E7A867F0DB506C90A@p3.JCK.COM> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========05D389A84DE102F97465==========" X-Spam-Score: 0.1 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff 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 --==========05D389A84DE102F97465========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi. At the Apps Area meeting at the last IETF, there was a discussion of ways of referring to or escaping a Unicode character in an ASCII protocol or context. I took an action to write a short I-D that explicitly recommended the use of form that reference Unicode code points directly rather than, e.g., encoding the octets of UTF-8. That document has been posted and, with the concurrence of the ADs, discussion has been directed to the discuss@apps.ietf.org list. If you have any interest in internationalization issues, a careful reading of, and comments on, this proposal would be greatly appreciated. In the absence of comments, I will be pushing for Last Call fairly soon. thanks, john --==========05D389A84DE102F97465========== Content-Type: message/rfc822; name="I-D ACTION:draft-klensin-unicode-escapes-00.txt" Return-path: Envelope-to: klensin+ietf@jck.com Delivery-date: Thu, 18 Jan 2007 15:52:21 -0500 Received: from [156.154.16.145] (helo=megatron.ietf.org) by bs.jck.com with esmtp (Exim 4.34) id 1H7eFA-000OpH-Ug for klensin+ietf@jck.com; Thu, 18 Jan 2007 15:52:21 -0500 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7eDZ-000866-Gf; Thu, 18 Jan 2007 15:50:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7eDR-0007o4-3a for i-d-announce@ietf.org; Thu, 18 Jan 2007 15:50:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H7eDQ-00005x-Pk for i-d-announce@ietf.org; Thu, 18 Jan 2007 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 7E658176EE for ; Thu, 18 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H7eCw-0004Pv-3N for i-d-announce@ietf.org; Thu, 18 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 18 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Subject: I-D ACTION:draft-klensin-unicode-escapes-00.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: i-d-announce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ASCII Escaping of Unicode Characters Author(s) : J. Klensin Filename : draft-klensin-unicode-escapes-00.txt Pages : 8 Date : 2007-1-18 There are a number of circumstances in which an escape mechanism is needed in conjunction with a protocol to encode characters that cannot by represented or transmitted directly. With ASCII coding the traditional escape has been either the decimal or hexadecimal offset of the character, written in a variety of different ways. The move to Unicode, where characters occupy two or more octets and may be coded in several different forms, has further complicated the question of escapes. This document discusses some the options now in use and makes a proposal for general use in IETF protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-klensin-unicode-escapes-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-klensin-unicode-escapes-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-klensin-unicode-escapes-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-18124301.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-klensin-unicode-escapes-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-klensin-unicode-escapes-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-18124301.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- --==========05D389A84DE102F97465==========-- From discuss-bounces@apps.ietf.org Fri Jan 19 11:38:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7wie-00086g-93; Fri, 19 Jan 2007 11:36:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7wid-00086b-B1 for discuss@apps.ietf.org; Fri, 19 Jan 2007 11:35:59 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7wiZ-0000Io-2f for discuss@apps.ietf.org; Fri, 19 Jan 2007 11:35:59 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 61CE556458; Fri, 19 Jan 2007 11:35:52 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-pWBSs0Bbbs; Fri, 19 Jan 2007 11:35:46 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 3076556440; Fri, 19 Jan 2007 11:35:45 -0500 (EST) Message-ID: <45B0F363.6020102@cs.utk.edu> Date: Fri, 19 Jan 2007 11:35:47 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: John C Klensin Subject: Re: FWD: I-D ACTION:draft-klensin-unicode-escapes-00.txt References: <891E235E7A867F0DB506C90A@p3.JCK.COM> In-Reply-To: <891E235E7A867F0DB506C90A@p3.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 based on a quick scan, it mostly looks fine to me, with a few caveats: - it should be clear that this is for newly-designed protocols only. it shouldn't be interpreted as a request to change existing protocols (including deployed and nonstandard protocols being standardized by IETF), as this would generally break backward compatibility by changing the meaning of '\' - it should be clear that this is for occasional use of non-ASCII characters within a protocol field that is constrained to contain only ASCII characters (or a subset), rather than a recommendation for how to represent non-ASCII characters in a protocol field that is capable of carrying, say, UTF-8. if the text already makes this clear, I apologize for not reading the document more carefully. it might also be worthwhile to recommend this notation for use in describing character literals in RFCs, in such a way that it could be referenced by such RFCs. Keith > At the Apps Area meeting at the last IETF, there was a > discussion of ways of referring to or escaping a Unicode > character in an ASCII protocol or context. I took an action to > write a short I-D that explicitly recommended the use of form > that reference Unicode code points directly rather than, e.g., > encoding the octets of UTF-8. > > That document has been posted and, with the concurrence of the > ADs, discussion has been directed to the discuss@apps.ietf.org > list. > > If you have any interest in internationalization issues, a > careful reading of, and comments on, this proposal would be > greatly appreciated. > > In the absence of comments, I will be pushing for Last Call > fairly soon. From discuss-bounces@apps.ietf.org Fri Jan 19 11:40:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7wld-0000zk-7n; Fri, 19 Jan 2007 11:39:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7wlb-0000un-JL for discuss@apps.ietf.org; Fri, 19 Jan 2007 11:39:03 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7wlX-0000iR-Af for discuss@apps.ietf.org; Fri, 19 Jan 2007 11:39:03 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1H7wlU-0006QW-PF for discuss@apps.ietf.org; Fri, 19 Jan 2007 11:38:57 -0500 Date: Fri, 19 Jan 2007 11:38:56 -0500 From: John C Klensin To: discuss@apps.ietf.org Subject: Typographical error in draft-klensin-unicode-escapes-00 Message-ID: <86EE78FED516BB38D35A7729@p3.JCK.COM> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 1.1 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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. It has been called to my attention that I should have checked the ABNF syntax rules more carefully before posting this draft. The productions for Hex-quad and Full-form should not have spaces between the repeat count and the token. The right sides should read 4*4HexDigit and 2*2Hex-Quad respectively. Fixed in the working draft -- I'm not going to create confusion by re-posting at this time. john From discuss-bounces@apps.ietf.org Fri Jan 19 11:45:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7wq7-0002Rs-KP; Fri, 19 Jan 2007 11:43:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7wq6-0002Rn-PL for discuss@apps.ietf.org; Fri, 19 Jan 2007 11:43:42 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7wq2-0001Fx-Hm for discuss@apps.ietf.org; Fri, 19 Jan 2007 11:43:42 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 2AF8A56478; Fri, 19 Jan 2007 11:43:38 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChTd2BMkAfnZ; Fri, 19 Jan 2007 11:43:32 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id E5674563F1; Fri, 19 Jan 2007 11:43:31 -0500 (EST) Message-ID: <45B0F536.2040208@cs.utk.edu> Date: Fri, 19 Jan 2007 11:43:34 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: John C Klensin Subject: Re: FWD: I-D ACTION:draft-klensin-unicode-escapes-00.txt References: <891E235E7A867F0DB506C90A@p3.JCK.COM> In-Reply-To: <891E235E7A867F0DB506C90A@p3.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 one more caveat: protocol specifications need to specify this notation explicitly (either directly or by reference to the published RFC) if they are going to use it. conversely, this notation SHOULD NOT (maybe MUST NOT) be used unless it is part of the protocol specification. one problem I see with introducing any new notation for characters is that it does create normalization issues by introducing additional ways to say the same thing. e.g. after introducing this notation, "A" could also be expressed as \u0041 or \U00000041. and it then becomes necessary to manage this conversion when copying fields from one protocol that supports the new notation (or in which it is benign) to another protocol that does not support the notation. as an example of a potential source of problems, I'd hate to see this notation end up in X.509 certs. From discuss-bounces@apps.ietf.org Fri Jan 19 12:42:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7xjO-0000Rn-1L; Fri, 19 Jan 2007 12:40:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7xjM-0000Lv-Rj for discuss@apps.ietf.org; Fri, 19 Jan 2007 12:40:48 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7xjM-0002E7-67 for discuss@apps.ietf.org; Fri, 19 Jan 2007 12:40:48 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1H7xjL-0006ij-4g; Fri, 19 Jan 2007 12:40:47 -0500 Date: Fri, 19 Jan 2007 12:40:46 -0500 From: John C Klensin To: Keith Moore Subject: Re: FWD: I-D ACTION:draft-klensin-unicode-escapes-00.txt Message-ID: In-Reply-To: <45B0F363.6020102@cs.utk.edu> References: <891E235E7A867F0DB506C90A@p3.JCK.COM> <45B0F363.6020102@cs.utk.edu> X-Mailer: Mulberry/4.0.7 (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: 093efd19b5f651b2707595638f6c4003 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, 19 January, 2007 11:35 -0500 Keith Moore wrote: > based on a quick scan, it mostly looks fine to me, with a few > caveats: > > - it should be clear that this is for newly-designed protocols > only. it shouldn't be interpreted as a request to change > existing protocols (including deployed and nonstandard > protocols being standardized by IETF), as this would generally > break backward compatibility by changing the meaning of '\' That was intended to be clear already. If it is not sufficiently so, suggested text, or at least a place to put it, would be welcome. More generally, I'm not completely wild about the \u and \U conventions, as you can probably deduce from the text. It seemed like the best choice on balance, but this is an area in which, were a consensus to emerge around something else, I would enthusiastically agree. > - it should be clear that this is for occasional use of > non-ASCII characters within a protocol field that is > constrained to contain only ASCII characters (or a subset), > rather than a recommendation for how to represent non-ASCII > characters in a protocol field that is capable of carrying, > say, UTF-8. > > if the text already makes this clear, I apologize for not > reading the document more carefully. I don't know if it is clear enough or not. At some level, if you didn't conclude that it was clear on reading the draft, then that is evidence that it isn't clear enough... but I don't know how carefully you read it. Certainly I agree with both points and would welcome suggestions as to how they can be clarified if they are not sufficiently clear. > it might also be worthwhile to recommend this notation for use > in describing character literals in RFCs, in such a way that > it could be referenced by such RFCs. Yeah. The document does address this, but (deliberately) more or less in passing. Again, I'd welcome specific community input and suggestions about this. I've looked at several RFCs and U+NNNN seems to be the preferred format for character literals and, more commonly, for identifying the code point associated with a named character. It is also, fwiw, the one I prefer for that purpose. But it is fairly poor for inline use in a protocol. The authoritative definition and reference for that form is the "Code Points" section of "Appendix A: Notational Conventions" of Unicode 5.0 (the reference to the book is the I-D). I don't believe that we add value by repeating that definition in an RFC, but could be easily talked out of that position. >From your followup note... > one more caveat: protocol specifications need to specify this > notation explicitly (either directly or by reference to the > published RFC) if they are going to use it. conversely, this > notation SHOULD NOT (maybe MUST NOT) be used unless it is part > of the protocol specification. Please suggest text for specifying those rules. I constructed this rather more as advice to protocol designers and, to a lesser extent, to document authors, rather than a base for notational definitions to be included by reference. That could be changed, but I'd welcome textual suggestions. > one problem I see with introducing any new notation for > characters is that it does create normalization issues by > introducing additional ways to say the same thing. e.g. after > introducing this notation, "A" could also be expressed as > \u0041 or \U00000041. and it then becomes necessary to manage > this conversion when copying fields from one protocol that > supports the new notation (or in which it is benign) to > another protocol that does not support the notation. We are, unfortunately, already _deep_ into that problem. Part of what motivated this draft was to prevent it from getting worse. And, using the example above, the conversion between \u0041 and \U00000041 is obvious. You can even do it by eye, and the relationship to %41 is equally clear. However, consider that "A" with a Diaeresis (U+00C4 -- note the use of the "code point" notation here). We then have \u00C4 and \U000000C4, which are easily mapped visually to each other and to the code point form, which can easily be looked up in a table if you don't know what it represents. But it is also, if I have done the calculation correctly, %C3%83 and that form (used in URIs and IRIs) is seriously non-intuitive and certainly can't be converted visually. > as an example of a potential source of problems, I'd hate to > see this notation end up in X.509 certs. To which I'd have to say "what would you like to see?". My personal answer is that I'd prefer to see those certs contain UTF-8 encoding with escapes used only to discuss or present the certs in contexts in which the UTF-8 and native characters are not available (and maybe if it is, for explanation and clarity). But I don't think this spec has much impact on that problem. If it should, I'd welcome text suggestions. General observation: I generated this document because it became clear that someone needed to something. The alternative was that we continue to drift toward a "every protocol makes its own choices, ignoring all others" situation, with many of them favoring escaped UTF-8 (which I consider to be nearly the worst possible choice for most circumstances... for reasons that should be clear even from the trivial examples above). But I have no particularly strong commitment to any particular recommendation as long as we establish a recommendation. From this point forward, I'm more or less acting as secretary/editor for whatever comments and consensus emerge rather than trying to advocate a particular solution or specification. One implication of that is that if anyone believes that additional text, clarification, or specification belongs in the document, I would really appreciate very specific textual suggestions. john From discuss-bounces@apps.ietf.org Sun Jan 21 16:09:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8juK-0006yV-Cj; Sun, 21 Jan 2007 16:07:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8juJ-0006yP-1u for discuss@apps.ietf.org; Sun, 21 Jan 2007 16:07:19 -0500 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8juH-00073l-QA for discuss@apps.ietf.org; Sun, 21 Jan 2007 16:07:19 -0500 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 921AF24080E; Sun, 21 Jan 2007 22:07:08 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id F0C7611431; Sun, 21 Jan 2007 22:06:42 +0100 (CET) Date: Sun, 21 Jan 2007 22:06:42 +0100 From: Stephane Bortzmeyer To: John C Klensin Subject: Escaping the escape (Was: I-D ACTION:draft-klensin-unicode-escapes-00.txt Message-ID: <20070121210642.GA10676@sources.org> References: <891E235E7A867F0DB506C90A@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <891E235E7A867F0DB506C90A@p3.JCK.COM> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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, Jan 19, 2007 at 10:34:27AM -0500, John C Klensin wrote a message of 179 lines which said: > In the absence of comments, I will be pushing for Last Call fairly > soon. I may be blind but I do not see a discussion about how to escape the escape sequence. For instance, when discussing the XML standard (&#nnnn;), there is no mention that it requires a way to write a bare & (&). In the same way, if you use the \unnnn standard, how do you ensure that you can still write a real \u string if you want it? It seems this is important enough to postpone the Last Call. From discuss-bounces@apps.ietf.org Sun Jan 21 16:18:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8k3t-0002OT-WB; Sun, 21 Jan 2007 16:17:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8k3s-0002M9-R6 for discuss@apps.ietf.org; Sun, 21 Jan 2007 16:17:12 -0500 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8k3r-0008Mp-J9 for discuss@apps.ietf.org; Sun, 21 Jan 2007 16:17:12 -0500 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 1DE1424080E; Sun, 21 Jan 2007 22:17:08 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id 3AF1811433; Sun, 21 Jan 2007 22:12:55 +0100 (CET) Date: Sun, 21 Jan 2007 22:12:55 +0100 From: Stephane Bortzmeyer To: John C Klensin Subject: Re: Typographical error in draft-klensin-unicode-escapes-00 Message-ID: <20070121211255.GA11223@sources.org> References: <86EE78FED516BB38D35A7729@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86EE78FED516BB38D35A7729@p3.JCK.COM> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 1.2 (+) 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, Jan 19, 2007 at 11:38:56AM -0500, John C Klensin wrote a message of 18 lines which said: > It has been called to my attention that I should have checked the > ABNF syntax rules more carefully before posting this draft. There is another strange thing: BMP-form = "\u" Hex-quad Full-form = "\U" 2*2 Hex-quad How can you tell one from the other before you encounter the second Hex-quad? By the case of the U, as it seems from reading the text following the grammar? If so, this is wrong because ABNF strings are case-insensitive so one should use: BMP-form = "\" %x75 Hex-quad Full-form = "\" %x55 2*2Hex-quad From discuss-bounces@apps.ietf.org Mon Jan 22 01:41:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8sqi-0006Jh-Af; Mon, 22 Jan 2007 01:40:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8sqh-0006Jb-CX for discuss@apps.ietf.org; Mon, 22 Jan 2007 01:40:11 -0500 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8sqc-0003X3-J1 for discuss@apps.ietf.org; Mon, 22 Jan 2007 01:40:11 -0500 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 l0M6e2Ql004888Mon, 22 Jan 2007 06:40:03 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1H8sqY-000FxG-00; Mon, 22 Jan 2007 06:40:02 +0000 Date: Mon, 22 Jan 2007 06:40:02 +0000 From: "Clive D.W. Feather" To: John C Klensin Subject: Re: Typographical error in draft-klensin-unicode-escapes-00 Message-ID: <20070122064002.GA60599@finch-staff-1.thus.net> References: <86EE78FED516BB38D35A7729@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86EE78FED516BB38D35A7729@p3.JCK.COM> User-Agent: Mutt/1.5.3i X-Spam-Score: 1.1 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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: > The right sides > should read > 4*4HexDigit and > 2*2Hex-Quad > respectively. While these are not incorrect, they are confusing to many readers. ABNF allows you to write these as: 4HexDigit and 2Hex-Quad respectively, and I recommend you do so. -- 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 Jan 22 03:49:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8uqt-0000U1-IT; Mon, 22 Jan 2007 03:48:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8uqr-0000Tu-Gi for discuss@apps.ietf.org; Mon, 22 Jan 2007 03:48:29 -0500 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8uqq-0005rp-3v for discuss@apps.ietf.org; Mon, 22 Jan 2007 03:48:29 -0500 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 l0M8mRL1003927Mon, 22 Jan 2007 08:48:27 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1H8uqp-000IuS-00; Mon, 22 Jan 2007 08:48:27 +0000 Date: Mon, 22 Jan 2007 08:48:27 +0000 From: "Clive D.W. Feather" To: John C Klensin Subject: Re: FWD: I-D ACTION:draft-klensin-unicode-escapes-00.txt Message-ID: <20070122084827.GI60599@finch-staff-1.thus.net> References: <891E235E7A867F0DB506C90A@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <891E235E7A867F0DB506C90A@p3.JCK.COM> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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: > If you have any interest in internationalization issues, a > careful reading of, and comments on, this proposal would be > greatly appreciated. Please remove the term "extended ASCII" from 1.1 - there is no such thing. If you want to talk about an 8 bit character set, then "the ISO 8859 family" would do. At the end of 3.1, you can't say "the same considerations" apply to Punycode and such encodings, because they *are* more compact (your third and textually closest point). I disagree with the claim that the \u notation is easier to read and less "ugly and awkward" than the HTML one. Is: Ank\uabcdef really easier to parse than: Ankꯍef ? I think - particularly in contexts using alphabetic text - that having a clear and obvious delimiter is much more preferable and will produce far less mistakes. I can accept that the specific HTML notation is a bit clumsy, and in particular that the use of 'x' implies other bases are available. Therefore I would prefer something like \u(xxxx). The text in 3.2 implies that \U is followed by 6 digits, not 8. That risk of confusion (particularly since Unicode ends at U+10FFFF) is itself reason for concern with any undelimited option. I haven't seen a "consensus" that there isn't a problem with being case-sensitive; the fact that you messed up the ABNF on this particular point is evidence that this is unwise. I know C does it that way (and in retrospect, I would have fought harder for doing it differently), but C has always been case sensitive in such matters. IETF protocols mostly aren't. Reference [ISO-C-Chars] is wrong - the \u and \U notation was added to ISO 9899 in the 1999 edition, not in that TR. They aren't extensions; they are part of the core language. -- 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 Jan 22 03:53:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8uvS-0000vh-Op; Mon, 22 Jan 2007 03:53:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8uvR-0000ux-8L for discuss@apps.ietf.org; Mon, 22 Jan 2007 03:53:13 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8uvP-0007LF-Uz for discuss@apps.ietf.org; Mon, 22 Jan 2007 03:53:13 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1H8uvK-0003B8-JP; Mon, 22 Jan 2007 03:53:06 -0500 Date: Mon, 22 Jan 2007 03:53:06 -0500 From: John C Klensin To: "Clive D.W. Feather" Subject: Re: Typographical error in draft-klensin-unicode-escapes-00 Message-ID: In-Reply-To: <20070122064002.GA60599@finch-staff-1.thus.net> References: <86EE78FED516BB38D35A7729@p3.JCK.COM> <20070122064002.GA60599@finch-staff-1.thus.net> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 1.1 (+) 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 Monday, 22 January, 2007 06:40 +0000 "Clive D.W. Feather" wrote: > John C Klensin said: >> The right sides >> should read >> 4*4HexDigit and >> 2*2Hex-Quad >> respectively. > > While these are not incorrect, they are confusing to many > readers. ABNF allows you to write these as: > > 4HexDigit and > 2Hex-Quad > > respectively, and I recommend you do so. Clive, I actually find it less confusing to be explicit about the lower and upper bounds. But will think on it further, especially if others have strong opinions. More later today on your more recent note. john From discuss-bounces@apps.ietf.org Mon Jan 22 04:03:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8v4X-0005fz-Cr; Mon, 22 Jan 2007 04:02:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8v4V-0005fD-UO for discuss@apps.ietf.org; Mon, 22 Jan 2007 04:02:35 -0500 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8v4U-0000Yj-2p for discuss@apps.ietf.org; Mon, 22 Jan 2007 04:02:35 -0500 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 l0M92UmJ010234Mon, 22 Jan 2007 09:02:30 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1H8v4Q-000JIz-00; Mon, 22 Jan 2007 09:02:30 +0000 Date: Mon, 22 Jan 2007 09:02:30 +0000 From: "Clive D.W. Feather" To: John C Klensin Subject: Re: FWD: I-D ACTION:draft-klensin-unicode-escapes-00.txt Message-ID: <20070122090230.GJ60599@finch-staff-1.thus.net> References: <891E235E7A867F0DB506C90A@p3.JCK.COM> <45B0F363.6020102@cs.utk.edu> 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: 73734d43604d52d23b3eba644a169745 Cc: discuss@apps.ietf.org, Keith Moore 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: >> - it should be clear that this is for newly-designed protocols >> only. it shouldn't be interpreted as a request to change >> existing protocols (including deployed and nonstandard >> protocols being standardized by IETF), as this would generally >> break backward compatibility by changing the meaning of '\' > > That was intended to be clear already. If it is not > sufficiently so, suggested text, or at least a place to put it, > would be welcome. How about adding "new" before "protocols" in the middle paragraph of 1.1 and the abstract? >> - it should be clear that this is for occasional use of >> non-ASCII characters within a protocol field that is >> constrained to contain only ASCII characters (or a subset), >> rather than a recommendation for how to represent non-ASCII >> characters in a protocol field that is capable of carrying, >> say, UTF-8. > I don't know if it is clear enough or not. At some level, if > you didn't conclude that it was clear on reading the draft, then > that is evidence that it isn't clear enough... but I don't know > how carefully you read it. I don't think it would hurt to add something in 1.1. I'm not sure how to word it, but something about "Some protocols already accept native UTF-8 or some other encoding of Unicode, and this recommendation does not apply to such protocols.". > I've looked at several RFCs > and U+NNNN seems to be the preferred format for character > literals and, more commonly, for identifying the code point > associated with a named character. It is also, fwiw, the one I > prefer for that purpose. But it is fairly poor for inline use > in a protocol. The authoritative definition and reference for > that form is the "Code Points" section of "Appendix A: > Notational Conventions" of Unicode 5.0 (the reference to the > book is the I-D). I don't have that book. The online version 4.1 suggests the notation , which can be abbreviated to <0061, 0030>. This would still need some kind of introductory indicator (like \u) to show that it's a Unicode escape. >> one more caveat: protocol specifications need to specify this >> notation explicitly (either directly or by reference to the >> published RFC) if they are going to use it. conversely, this >> notation SHOULD NOT (maybe MUST NOT) be used unless it is part >> of the protocol specification. > Please suggest text for specifying those rules. I constructed > this rather more as advice to protocol designers and, to a > lesser extent, to document authors, rather than a base for > notational definitions to be included by reference. That could > be changed, but I'd welcome textual suggestions. "This specification is a recommendation to protocol designers and document authors. A protocol or other specification MUST NOT be interpreted as using it unless it explicitly copies this syntax or refers to this RFC as normative." > But it is also, if I have done > the calculation correctly, %C3%83 and that form (used in URIs > and IRIs) is seriously non-intuitive and certainly can't be > converted visually. I certainly agree that encoding of UTF-8 sequences is the wrong thing to do. Oh: you should explicitly forbid the use of surrogates to encode characters above U+FFFF. > But I > have no particularly strong commitment to any particular > recommendation as long as we establish a recommendation. (1) I agree that anything is better than nothing. (2) While \uXXXX is better than encoded UTF-8, it's far worse than something explicitly delimited. -- 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 Jan 22 04:04:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8v5i-0006t6-Qf; Mon, 22 Jan 2007 04:03:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8v5g-0006nj-Hd for discuss@apps.ietf.org; Mon, 22 Jan 2007 04:03:48 -0500 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8v5f-0000sq-3r for discuss@apps.ietf.org; Mon, 22 Jan 2007 04:03:48 -0500 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 l0M93juu010654Mon, 22 Jan 2007 09:03:46 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1H8v5d-000JJe-00; Mon, 22 Jan 2007 09:03:45 +0000 Date: Mon, 22 Jan 2007 09:03:45 +0000 From: "Clive D.W. Feather" To: Stephane Bortzmeyer Subject: Re: Escaping the escape (Was: I-D ACTION:draft-klensin-unicode-escapes-00.txt Message-ID: <20070122090345.GK60599@finch-staff-1.thus.net> References: <891E235E7A867F0DB506C90A@p3.JCK.COM> <20070121210642.GA10676@sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070121210642.GA10676@sources.org> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: discuss@apps.ietf.org, John C Klensin 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: > I may be blind but I do not see a discussion about how to escape the > escape sequence. For instance, when discussing the XML standard > (&#nnnn;), there is no mention that it requires a way to write a bare > & (&). > > In the same way, if you use the \unnnn standard, how do you ensure > that you can still write a real \u string if you want it? To write the string "\u1234", you write "\u005Cu1234". Isn't that obvious enough not to need stating? -- 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 Jan 22 04:23:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8vNw-0004Ds-Te; Mon, 22 Jan 2007 04:22:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8vNw-0004Bo-0H for discuss@apps.ietf.org; Mon, 22 Jan 2007 04:22:40 -0500 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8vNu-0006ww-Cz for discuss@apps.ietf.org; Mon, 22 Jan 2007 04:22:39 -0500 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 l0M9MbWi022446Mon, 22 Jan 2007 09:22:37 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1H8vNt-000Js7-00; Mon, 22 Jan 2007 09:22:37 +0000 Date: Mon, 22 Jan 2007 09:22:37 +0000 From: "Clive D.W. Feather" To: John C Klensin Subject: Re: Typographical error in draft-klensin-unicode-escapes-00 Message-ID: <20070122092237.GL60599@finch-staff-1.thus.net> References: <86EE78FED516BB38D35A7729@p3.JCK.COM> <20070122064002.GA60599@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: 1.1 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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: >> While these are not incorrect, they are confusing to many >> readers. ABNF allows you to write these as: >> >> 4HexDigit and >> 2Hex-Quad >> >> respectively, and I recommend you do so. > > Clive, I actually find it less confusing to be explicit about > the lower and upper bounds. We may have to agree to disagree. When I see "4*4XXX", it makes me wonder if the author actually meant "4*" or "*4" and misunderstood the notation. Incidentally, there's no significance to the groupings of 4 in the \u notation, so I see little point in introducing "Hex-quad". The term "BMP" is, as I understand it, deprecated these days. So I would just write: EmbeddedUnicodeChar = %x5C.75 4HexDigit / %x5C.55 8HexDigit or if you really want: EmbeddedUnicodeChar = UnicodeShortForm / UnicodeLongForm UnicodeShortForm = %x5C.75 4HexDigit UnicodeLongForm = %x5C.55 8HexDigit [Note that you omitted the / from your definition.] -- 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 Jan 22 04:26:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8vQx-0006HB-4i; Mon, 22 Jan 2007 04:25:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8vQv-0006F8-QP for discuss@apps.ietf.org; Mon, 22 Jan 2007 04:25:45 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H8vQu-0007XJ-D9 for discuss@apps.ietf.org; Mon, 22 Jan 2007 04:25:45 -0500 Received: (qmail invoked by alias); 22 Jan 2007 09:25:43 -0000 Received: from p508FA741.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.167.65] by mail.gmx.net (mp034) with SMTP; 22 Jan 2007 10:25:43 +0100 X-Authenticated: #1915285 Message-ID: <45B48313.20005@gmx.de> Date: Mon, 22 Jan 2007 10:25:39 +0100 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: "Clive D.W. Feather" Subject: Re: Escaping the escape (Was: I-D ACTION:draft-klensin-unicode-escapes-00.txt References: <891E235E7A867F0DB506C90A@p3.JCK.COM> <20070121210642.GA10676@sources.org> <20070122090345.GK60599@finch-staff-1.thus.net> In-Reply-To: <20070122090345.GK60599@finch-staff-1.thus.net> 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, John C Klensin 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 Clive D.W. Feather schrieb: > Stephane Bortzmeyer said: >> I may be blind but I do not see a discussion about how to escape the >> escape sequence. For instance, when discussing the XML standard >> (&#nnnn;), there is no mention that it requires a way to write a bare >> & (&). >> >> In the same way, if you use the \unnnn standard, how do you ensure >> that you can still write a real \u string if you want it? > > To write the string "\u1234", you write "\u005Cu1234". Isn't that obvious > enough not to need stating? I would understand "obvious" as "the first thing I can think of". Under that assumption, I would find it obvious if "\\u" would do the trick, thus any backslash needs to be escaped. Best regards, Julian From discuss-bounces@apps.ietf.org Mon Jan 22 04:28:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8vSX-0007QI-Am; Mon, 22 Jan 2007 04:27:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8vSV-0007Q3-Oq for discuss@apps.ietf.org; Mon, 22 Jan 2007 04:27:23 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8vSU-0007hq-7g for discuss@apps.ietf.org; Mon, 22 Jan 2007 04:27:23 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 0BD6B26C206 for ; Mon, 22 Jan 2007 10:27:12 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id E5C6B26C1CF for ; Mon, 22 Jan 2007 10:27:11 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id D7AB158ED18 for ; Mon, 22 Jan 2007 10:27:11 +0100 (CET) Date: Mon, 22 Jan 2007 10:27:11 +0100 From: Stephane Bortzmeyer To: discuss@apps.ietf.org Subject: Re: FWD: I-D ACTION:draft-klensin-unicode-escapes-00.txt Message-ID: <20070122092711.GA4517@nic.fr> References: <891E235E7A867F0DB506C90A@p3.JCK.COM> <45B0F363.6020102@cs.utk.edu> <20070122090230.GJ60599@finch-staff-1.thus.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070122090230.GJ60599@finch-staff-1.thus.net> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.17-2-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: 856eb5f76e7a34990d1d457d8e8e5b7f 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, Jan 22, 2007 at 09:02:30AM +0000, Clive D.W. Feather wrote a message of 87 lines which said: > I certainly agree that encoding of UTF-8 sequences is the wrong > thing to do. ++++1 > (1) I agree that anything is better than nothing. +0.5 > (2) While \uXXXX is better than encoded UTF-8, it's far worse than > something explicitly delimited. +1 (parsing programs author's POV) From discuss-bounces@apps.ietf.org Mon Jan 22 04:29:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8vTc-0007gK-Td; Mon, 22 Jan 2007 04:28:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8vTb-0007gD-I3 for discuss@apps.ietf.org; Mon, 22 Jan 2007 04:28:31 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8vTZ-0007wn-9V for discuss@apps.ietf.org; Mon, 22 Jan 2007 04:28:31 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id E817126C206; Mon, 22 Jan 2007 10:28:28 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id CCE8126C1A7; Mon, 22 Jan 2007 10:28:28 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id C0BEA58ED18; Mon, 22 Jan 2007 10:28:28 +0100 (CET) Date: Mon, 22 Jan 2007 10:28:28 +0100 From: Stephane Bortzmeyer To: "Clive D.W. Feather" Subject: Re: Escaping the escape (Was: I-D ACTION:draft-klensin-unicode-escapes-00.txt Message-ID: <20070122092828.GB4517@nic.fr> References: <891E235E7A867F0DB506C90A@p3.JCK.COM> <20070121210642.GA10676@sources.org> <20070122090345.GK60599@finch-staff-1.thus.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070122090345.GK60599@finch-staff-1.thus.net> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.17-2-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: 30ac594df0e66ffa5a93eb4c48bcb014 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, Jan 22, 2007 at 09:03:45AM +0000, Clive D.W. Feather wrote a message of 17 lines which said: > To write the string "\u1234", you write "\u005Cu1234". Isn't that > obvious enough not to need stating? It was not obvious to me, I did not even think of it (\\u1234 seemed more reasonable). From discuss-bounces@apps.ietf.org Mon Jan 22 04:32:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8vWf-0008U9-3Y; Mon, 22 Jan 2007 04:31:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8vWd-0008Tz-Mn for discuss@apps.ietf.org; Mon, 22 Jan 2007 04:31:39 -0500 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8vWc-000054-Ao for discuss@apps.ietf.org; Mon, 22 Jan 2007 04:31:39 -0500 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 l0M9Vbim027718Mon, 22 Jan 2007 09:31:37 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1H8vWb-000K9S-00; Mon, 22 Jan 2007 09:31:37 +0000 Date: Mon, 22 Jan 2007 09:31:37 +0000 From: "Clive D.W. Feather" To: Stephane Bortzmeyer Subject: Re: Escaping the escape (Was: I-D ACTION:draft-klensin-unicode-escapes-00.txt Message-ID: <20070122093137.GO60599@finch-staff-1.thus.net> References: <891E235E7A867F0DB506C90A@p3.JCK.COM> <20070121210642.GA10676@sources.org> <20070122090345.GK60599@finch-staff-1.thus.net> <20070122092828.GB4517@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070122092828.GB4517@nic.fr> User-Agent: Mutt/1.5.3i 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 Stephane Bortzmeyer said: >> To write the string "\u1234", you write "\u005Cu1234". Isn't that >> obvious enough not to need stating? > > It was not obvious to me, I did not even think of it (\\u1234 seemed > more reasonable). Sorry, I was a bit terse there. You can always do things by escaping the \ using the same notation; that seemed obvious enough not to need stating. I agree that \\ is easier to read, but it might not be compatible with other uses of \ in the protocol this is going into. As such, it might be seen as inappropriate to require it. However, we could add it as a MAY. -- 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 Tue Jan 23 03:30:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9H1k-0003yO-3m; Tue, 23 Jan 2007 03:29:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9H1j-0003yJ-GU for discuss@apps.ietf.org; Tue, 23 Jan 2007 03:29:11 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9H1i-00089f-6s for discuss@apps.ietf.org; Tue, 23 Jan 2007 03:29:11 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 9B77526C21F; Tue, 23 Jan 2007 09:29:03 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 80CBF26C20D; Tue, 23 Jan 2007 09:29:03 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 7400458ED0B; Tue, 23 Jan 2007 09:29:03 +0100 (CET) Date: Tue, 23 Jan 2007 09:29:03 +0100 From: Stephane Bortzmeyer To: ltru@lists.ietf.org Subject: Re: ASCII escapes for Unicode characters Message-ID: <20070123082903.GA28270@nic.fr> References: <45B2FF2C.51E9@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45B2FF2C.51E9@xyzzy.claranet.de> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.17-2-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: 1ac7cc0a4cd376402b85bc1961a86ac2 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 Sun, Jan 21, 2007 at 06:50:36AM +0100, Frank Ellermann wrote a message of 17 lines which said: > for LTRU because we intentionally picked the 􂍅 style there, > and maybe it's also relevant for I-D.phillips-record-jar Although it is far from clear in the I-D text, the discussion about the draft (http://www1.ietf.org/mail-archive/web/discuss/current/msg00411.html) showed that it is intended for *new* protocols only so this draft is probably off-topic for LTRU, unless we decide to switch to a completely new registry format. From discuss-bounces@apps.ietf.org Wed Jan 24 10:09:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9jjF-0005Ph-05; Wed, 24 Jan 2007 10:08:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9jjD-0005PU-Kq for discuss@apps.ietf.org; Wed, 24 Jan 2007 10:07:59 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9jjB-0003Xr-Qm for discuss@apps.ietf.org; Wed, 24 Jan 2007 10:07:59 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1H9itK-00010e-Cj for discuss@apps.ietf.org; Wed, 24 Jan 2007 09:14:22 -0500 Date: Wed, 24 Jan 2007 09:14:21 -0500 From: John C Klensin To: discuss@apps.ietf.org Subject: Next step (Was: I-D ACTION:draft-klensin-unicode-escapes-00.txt Message-ID: X-Mailer: Mulberry/4.0.7 (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: 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 Hi. I've gotten a very large amount of mail about this draft, actually more addressed to me personally than on the list. The mail seems to me to fall into three categories: (1) Evidence that I still cannot do ABNF properly, plus a few other editorial issues. The most important of the ABNF issues is that "u" and "U" cannot be specified as different without escaping both into their character code positions (since character-literals in ABNF are case-insensitive). The person who pointed that out suggested that this is yet more evidence that \u and \U are a bad choice, but that question is part of (3). All of these editorial and ABNF problems are easily fixed. (2) Concerns about "escaping the escape", with some differences in opinion about what the escape-escape should be. (3) Distaste for the particular \uNNNN and \UNNNNNNNN mechanisms chosen, with several different preferences for what should be chosen instead. I have seen nothing that expresses a strong preference for the "encode UTF-8 octets" forms instead of the "represent Unicode code points" forms. The preference for the latter was the mail purpose of this document/ effort, so we are making progress. Let's assume that the issues in (1) and (2) can be fairly easily addressed, (1) more easily than (2), obviously. If it is helpful, I can immediately issue a new draft to correct the editorial and ABNF issues that have been identified, clearing up (1). But I'd like to focus on (3), which is where the showstoppers presumably lie. I don't see how to get agreement on a single form: almost everyone who doesn't like \u / \U likes something different... there is no evidence in the notes I have received that indicates one uniform strong preference in the community as to what the syntax should be. One possibility is that I can revise the document to indicate that there are many syntax possibilities and that decisions should be made on a protocol-by-protocol basis, being sure to note how to escape the escape for whatever is chosen. Or someone can suggest a way for us to make a choice. Thoughts? john From discuss-bounces@apps.ietf.org Wed Jan 24 10:31:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9k66-0003vp-Tv; Wed, 24 Jan 2007 10:31:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9k65-0003vf-LD for discuss@apps.ietf.org; Wed, 24 Jan 2007 10:31:37 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9k64-000853-Cd for discuss@apps.ietf.org; Wed, 24 Jan 2007 10:31:37 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 77C9F26C281; Wed, 24 Jan 2007 16:31:26 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 5D7D526C26D; Wed, 24 Jan 2007 16:31:26 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 4F61658E9F0; Wed, 24 Jan 2007 16:31:26 +0100 (CET) Date: Wed, 24 Jan 2007 16:31:26 +0100 From: Stephane Bortzmeyer To: John C Klensin Subject: Re: Next step (Was: I-D ACTION:draft-klensin-unicode-escapes-00.txt Message-ID: <20070124153126.GA12389@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.17-2-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: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 Wed, Jan 24, 2007 at 09:14:21AM -0500, John C Klensin wrote a message of 52 lines which said: > I don't see how to get agreement on a single form: almost everyone > who doesn't like \u / \U likes something different... there is no > evidence in the notes I have received that indicates one uniform > strong preference in the community as to what the syntax should be. But there is (may be) a rough consensus that every scheme with explicit delimiters (&#xNNNN; or \u{NNNNN}) is better than any scheme without them? If so, it would be a progress. From discuss-bounces@apps.ietf.org Wed Jan 24 13:28:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9mr3-0000YT-Vz; Wed, 24 Jan 2007 13:28:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9kln-0004nU-IJ for discuss@apps.ietf.org; Wed, 24 Jan 2007 11:14:43 -0500 Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9klm-0000V8-5S for discuss@apps.ietf.org; Wed, 24 Jan 2007 11:14:43 -0500 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id LAA08010; Wed, 24 Jan 2007 11:14:30 -0500 (EST) From: der Mouse Message-Id: <200701241614.LAA08010@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Wed, 24 Jan 2007 11:03:10 -0500 (EST) To: discuss@apps.ietf.org Subject: Re: Next step (Was: I-D ACTION:draft-klensin-unicode-escapes-00.txt In-Reply-To: References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-Mailman-Approved-At: Wed, 24 Jan 2007 13:28:17 -0500 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 mail seems to me to fall into three categories: > (1) Evidence that I still cannot do ABNF properly, plus a few other > editorial issues. The most important of the ABNF issues is that "u" > and "U" cannot be specified as different without escaping both into > their character code positions (since character-literals in ABNF are > case-insensitive). This says to me that ABNF is the wrong tool for the job here. It seems to me that we really want to specify "backslash" "lowercase u" and "backslash" "uppercase U" rather than octet sequences, so that the result is not tied to ASCII (while it's unlikely that anyone wants to inject Unicode into EBCDIC text, I just don't like seeing a problem "fixed" by introducing other problems in a workaround instead of addressing the real problem). If ABNF can't do what we want, I'd say, use something better-suited to the need. Perhaps it would be enough to say that the spec uses ABNF except that the character after the backslash is case-sensitive? That said, I don't consider this a showstopper - not that my opinion of what is or isn't a showstopper necessarily matters.... /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From discuss-bounces@apps.ietf.org Wed Jan 24 14:35:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9ntk-0002zP-AQ; Wed, 24 Jan 2007 14:35:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9ntj-0002zK-Hi for discuss@apps.ietf.org; Wed, 24 Jan 2007 14:35:07 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9nti-0000MR-0l for discuss@apps.ietf.org; Wed, 24 Jan 2007 14:35:07 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1H9nth-0003Wl-GU for discuss@apps.ietf.org; Wed, 24 Jan 2007 14:35:05 -0500 Date: Wed, 24 Jan 2007 14:35:04 -0500 From: John C Klensin To: discuss@apps.ietf.org Subject: Re: Next step (Was: I-D ACTION:draft-klensin-unicode-escapes-00.txt Message-ID: <44DA3CBB505158A28B67C222@p3.JCK.COM> X-Mailer: Mulberry/4.0.7 (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: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 Wednesday, 24 January, 2007 11:03 -0500 der Mouse wrote: >> The mail seems to me to fall into three categories: > >> (1) Evidence that I still cannot do ABNF properly, plus a few >> other editorial issues. The most important of the ABNF >> issues is that "u" and "U" cannot be specified as different >> without escaping both into their character code positions >> (since character-literals in ABNF are case-insensitive). > This says to me that ABNF is the wrong tool for the job here. > It seems to me that we really want to specify "backslash" > "lowercase u" and "backslash" "uppercase U" rather than octet > sequences, so that the result is not tied to ASCII (while it's > unlikely that anyone wants to inject Unicode into EBCDIC text, > I just don't like seeing a problem "fixed" by introducing > other problems in a workaround instead of addressing the real > problem). It is clear to me that, if we can decide what we are trying to do, we can invent ABNF to do it -- without introducing the constraint about which you are concerned. It may be a bit clumsy, but it is feasible. The main problem here is a personal one: for historical reasons going back long before there was an IETF, I've never been a big ABNF fan. I'm even less of a fan of some of the extensions in RFC 2234/ 4234 which I consider fussy, too extensive, and unnecessary. While I have accepted the IETF consensus on ABNF (with the extensions), that distaste, aggravated by the onset of old age, has impeded my learning it well and preventing my remembering all of the details that I have learned from one time to the next. The IETF should certainly not make decisions on the basis of my problems with ABNF; even I won't make decisions on that basis. I very much appreciate the efforts of those who have learned that they have to check my work and their patience in correcting it. But let's make the right decisions and not get hung up on my idiosyncrasies. > If ABNF can't do what we want, I'd say, use something > better-suited to the need. Perhaps it would be enough to say > that the spec uses ABNF except that the character after the > backslash is case-sensitive? As I said, I'm confident we can figure something out. That would certainly be among the alternatives although my instinct would be to hunt up Dave and Paul and ask them for advice, at least as a first step. > That said, I don't consider this a showstopper - not that my > opinion of what is or isn't a showstopper necessarily > matters.... Nor mine. john From discuss-bounces@apps.ietf.org Wed Jan 24 15:43:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9ox6-0003CY-DP; Wed, 24 Jan 2007 15:42:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9ox5-0003CR-I7 for discuss@apps.ietf.org; Wed, 24 Jan 2007 15:42:39 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9ox4-00086x-8n for discuss@apps.ietf.org; Wed, 24 Jan 2007 15:42:39 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1H9ox3-00045t-QD; Wed, 24 Jan 2007 15:42:37 -0500 Date: Wed, 24 Jan 2007 15:42:37 -0500 From: John C Klensin To: Stephane Bortzmeyer Subject: Re: Next step (Was: I-D ACTION:draft-klensin-unicode-escapes-00.txt Message-ID: <48AE8F8343DFAA3BC6DEB491@p3.JCK.COM> In-Reply-To: <20070124153126.GA12389@nic.fr> References: <20070124153126.GA12389@nic.fr> X-Mailer: Mulberry/4.0.7 (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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 Wednesday, 24 January, 2007 16:31 +0100 Stephane Bortzmeyer wrote: > On Wed, Jan 24, 2007 at 09:14:21AM -0500, > John C Klensin wrote > a message of 52 lines which said: > >> I don't see how to get agreement on a single form: almost >> everyone who doesn't like \u / \U likes something >> different... there is no evidence in the notes I have >> received that indicates one uniform strong preference in the >> community as to what the syntax should be. > > But there is (may be) a rough consensus that every scheme with > explicit delimiters (&#xNNNN; or \u{NNNNN}) is better than any > scheme without them? If so, it would be a progress. Much as I would personally prefer that answer, I haven't seen such a consensus emerge yet. john From discuss-bounces@apps.ietf.org Wed Jan 24 20:19:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9tGJ-0008A0-QU; Wed, 24 Jan 2007 20:18:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9s8U-0008By-He for discuss@apps.ietf.org; Wed, 24 Jan 2007 19:06:38 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9s8T-0001t4-2V for discuss@apps.ietf.org; Wed, 24 Jan 2007 19:06:38 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H9s8L-0006KT-19 for discuss@apps.ietf.org; Thu, 25 Jan 2007 01:06:29 +0100 Received: from d253188.dialin.hansenet.de ([80.171.253.188]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Jan 2007 01:06:29 +0100 Received: from nobody by d253188.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Jan 2007 01:06:29 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: discuss@apps.ietf.org From: Frank Ellermann Subject: Re: Next step Date: Thu, 25 Jan 2007 01:05:35 +0100 Organization: Lines: 94 Message-ID: <45B7F44F.4675@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d253188.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a X-Mailman-Approved-At: Wed, 24 Jan 2007 20:18:46 -0500 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: > actually more addressed to me personally than on the list. Hi, I hope the issue with the list "eating" my mails is now fixed, and try it again (minus typos, but keeping the ABNF issue because "8 vs. 6 digits" might be still unclear): ~~~ I-D ~~~ [U+NNNN] This document proposes that a specific variation on the latter SHOULD be used in protocols unless other considerations apply and explains that choice. I disagree with that proposal, more below. - BMP-form = "\u" Hex-quad - Full-form = "\U" 2*2 Hex-quad + BMP-form = %x5C.75 Hex-quad ; starting with lower case "\u" + Full-form = %x5C.55 2*2 Hex-quad ; starting with upper case "\U" You fixed something there already resulting in either four or six digits, but for a case-sensitive u vs. U you can't use "u" or "U" in ABNF. Sometimes this ABNF feature is annnoying. Looking at your fix, is that still either four or *_eight_* instead of six digits ? (e.g., in RFCs) although the U+NNNN form MAY be used when Unicode character encoding is clearly expected. It SHOULD be used for the purpose of talking _about_ Unicode points in the prose of Internet drafts and RFCs, but it SHOULD NOT be used to encode only the non-ASCII characters in Unicode strings. It MAY be used to encode complete obviously delimited Unicode strings. - This specification recommends that, in the absence of - compelling reasons to do otherwise, the Unicode code point forms be - used rather than the UTF-8 ones. There are several reasons for this, - including: + This specification recommends that, in the absence of + compelling reasons to do otherwise, the Unicode code point forms + SHOULD be used rather than the UTF-8 ones. There are several + reasons for this, including: Adding a SHOULD to 3.1, otherwise folks won't believe it. o Perl uses the form \x(NNN...). The advantage of this form is that there are explicit delimiters Indeed, hitting the important C044 point in [CharMod]. o Java uses the form \uNNNN, but can represent characters outside Plane 0 (i.e., above U+FFFF) only by the use of surrogate pairs. One of the reasons why anything with \u or \U is a non-starter, there are too many incompatible conventions in use. Codings that depend on surrogates SHOULD NOT be used. Strong ACK. o HTML and XML use the form &#xNNNN;. Like the Perl form, this form has a clear terminator, reducing ambiguity. However, it is generally considered ugly and awkward outside of its native HTML, XML, and similar contexts. IMO it is THE encoding. It's also trivial to convert files using this technique into XML. For the RFC 4646 language subtag registry I use a simple gawk script. There is one significant disadvantage of the recommended form. The No, there are more, folks will assume that it's a convention they know or a variant of U+NNNN[N[N]] with an arbitrary number of leading 0s. Nobody will use \U012345 when they can hope to get away with \U12345. should not introduce any security issues that are not present as a My objections are also security considerations, because folks will screw up with this encoding it could cause havoc. 6.1. Normative References There should be a normative reference to the [CharMod] bible, and especially to its conformance criteria C042 up to C048 starting at http://www.w3.org/TR/charmod/#C042 In theory your proposal is compatible with C044, but in practice I fear that it won't work as you expect it. I could live with e.g. "authors SHOULD either pick hex. NCRs as in XML or" (your proposal), but in fact I think that the XML-notation is much better. Frank From discuss-bounces@apps.ietf.org Wed Jan 24 20:19:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9tGJ-00089v-N8; Wed, 24 Jan 2007 20:18:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9now-0008R1-Nh for discuss@apps.ietf.org; Wed, 24 Jan 2007 14:30:10 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9nou-0007KT-9k for discuss@apps.ietf.org; Wed, 24 Jan 2007 14:30:10 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1H9not-0003TF-L0; Wed, 24 Jan 2007 14:30:07 -0500 Date: Wed, 24 Jan 2007 14:30:06 -0500 From: John C Klensin To: der Mouse , discuss@apps.ietf.org Subject: Re: Next step (Was: I-D ACTION:draft-klensin-unicode-escapes-00.txt Message-ID: In-Reply-To: <200701241614.LAA08010@Sparkle.Rodents.Montreal.QC.CA> References: <200701241614.LAA08010@Sparkle.Rodents.Montreal.QC.CA> X-Mailer: Mulberry/4.0.7 (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: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-Mailman-Approved-At: Wed, 24 Jan 2007 20:18:46 -0500 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 Wednesday, 24 January, 2007 11:03 -0500 der Mouse wrote: >> The mail seems to me to fall into three categories: > >> (1) Evidence that I still cannot do ABNF properly, plus a few >> other editorial issues. The most important of the ABNF >> issues is that "u" and "U" cannot be specified as different >> without escaping both into their character code positions >> (since character-literals in ABNF are case-insensitive). > This says to me that ABNF is the wrong tool for the job here. > It seems to me that we really want to specify "backslash" > "lowercase u" and "backslash" "uppercase U" rather than octet > sequences, so that the result is not tied to ASCII (while it's > unlikely that anyone wants to inject Unicode into EBCDIC text, > I just don't like seeing a problem "fixed" by introducing > other problems in a workaround instead of addressing the real > problem). It is clear to me that, if we can decide what we are trying to do, we can invent ABNF to do it -- without introducing the constraint about which you are concerned. It may be a bit clumsy, but it is feasible. The main problem here is a personal one: for historical reasons going back long before there was an IETF, I've never been a big ABNF fan. I'm even less of a fan of some of the extensions in RFC 2234/ 4234 which I consider fussy, too extensive, and unnecessary. While I have accepted the IETF consensus on ABNF (with the extensions), that distaste, aggravated by the onset of old age, has impeded my learning it well and preventing my remembering all of the details that I have learned from one time to the next. The IETF should certainly not make decisions on the basis of my problems with ABNF; even I won't make decisions on that basis. I very much appreciate the efforts of those who have learned that they have to check my work and their patience in correcting it. But let's make the right decisions and not get hung up on my idiosyncrasies. > If ABNF can't do what we want, I'd say, use something > better-suited to the need. Perhaps it would be enough to say > that the spec uses ABNF except that the character after the > backslash is case-sensitive? As I said, I'm confident we can figure something out. That would certainly be among the alternatives although my instinct would be to hunt up Dave and Paul and ask them for advice, at least as a first step. > That said, I don't consider this a showstopper - not that my > opinion of what is or isn't a showstopper necessarily > matters.... Nor mine. john From discuss-bounces@apps.ietf.org Wed Jan 24 20:19:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9tGJ-0008A0-QU; Wed, 24 Jan 2007 20:18:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9s8U-0008By-He for discuss@apps.ietf.org; Wed, 24 Jan 2007 19:06:38 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9s8T-0001t4-2V for discuss@apps.ietf.org; Wed, 24 Jan 2007 19:06:38 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H9s8L-0006KT-19 for discuss@apps.ietf.org; Thu, 25 Jan 2007 01:06:29 +0100 Received: from d253188.dialin.hansenet.de ([80.171.253.188]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Jan 2007 01:06:29 +0100 Received: from nobody by d253188.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Jan 2007 01:06:29 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: discuss@apps.ietf.org From: Frank Ellermann Subject: Re: Next step Date: Thu, 25 Jan 2007 01:05:35 +0100 Organization: Lines: 94 Message-ID: <45B7F44F.4675@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d253188.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a X-Mailman-Approved-At: Wed, 24 Jan 2007 20:18:46 -0500 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: > actually more addressed to me personally than on the list. Hi, I hope the issue with the list "eating" my mails is now fixed, and try it again (minus typos, but keeping the ABNF issue because "8 vs. 6 digits" might be still unclear): ~~~ I-D ~~~ [U+NNNN] This document proposes that a specific variation on the latter SHOULD be used in protocols unless other considerations apply and explains that choice. I disagree with that proposal, more below. - BMP-form = "\u" Hex-quad - Full-form = "\U" 2*2 Hex-quad + BMP-form = %x5C.75 Hex-quad ; starting with lower case "\u" + Full-form = %x5C.55 2*2 Hex-quad ; starting with upper case "\U" You fixed something there already resulting in either four or six digits, but for a case-sensitive u vs. U you can't use "u" or "U" in ABNF. Sometimes this ABNF feature is annnoying. Looking at your fix, is that still either four or *_eight_* instead of six digits ? (e.g., in RFCs) although the U+NNNN form MAY be used when Unicode character encoding is clearly expected. It SHOULD be used for the purpose of talking _about_ Unicode points in the prose of Internet drafts and RFCs, but it SHOULD NOT be used to encode only the non-ASCII characters in Unicode strings. It MAY be used to encode complete obviously delimited Unicode strings. - This specification recommends that, in the absence of - compelling reasons to do otherwise, the Unicode code point forms be - used rather than the UTF-8 ones. There are several reasons for this, - including: + This specification recommends that, in the absence of + compelling reasons to do otherwise, the Unicode code point forms + SHOULD be used rather than the UTF-8 ones. There are several + reasons for this, including: Adding a SHOULD to 3.1, otherwise folks won't believe it. o Perl uses the form \x(NNN...). The advantage of this form is that there are explicit delimiters Indeed, hitting the important C044 point in [CharMod]. o Java uses the form \uNNNN, but can represent characters outside Plane 0 (i.e., above U+FFFF) only by the use of surrogate pairs. One of the reasons why anything with \u or \U is a non-starter, there are too many incompatible conventions in use. Codings that depend on surrogates SHOULD NOT be used. Strong ACK. o HTML and XML use the form &#xNNNN;. Like the Perl form, this form has a clear terminator, reducing ambiguity. However, it is generally considered ugly and awkward outside of its native HTML, XML, and similar contexts. IMO it is THE encoding. It's also trivial to convert files using this technique into XML. For the RFC 4646 language subtag registry I use a simple gawk script. There is one significant disadvantage of the recommended form. The No, there are more, folks will assume that it's a convention they know or a variant of U+NNNN[N[N]] with an arbitrary number of leading 0s. Nobody will use \U012345 when they can hope to get away with \U12345. should not introduce any security issues that are not present as a My objections are also security considerations, because folks will screw up with this encoding it could cause havoc. 6.1. Normative References There should be a normative reference to the [CharMod] bible, and especially to its conformance criteria C042 up to C048 starting at http://www.w3.org/TR/charmod/#C042 In theory your proposal is compatible with C044, but in practice I fear that it won't work as you expect it. I could live with e.g. "authors SHOULD either pick hex. NCRs as in XML or" (your proposal), but in fact I think that the XML-notation is much better. Frank From discuss-bounces@apps.ietf.org Wed Jan 24 20:19:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9tGJ-00089v-N8; Wed, 24 Jan 2007 20:18:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9now-0008R1-Nh for discuss@apps.ietf.org; Wed, 24 Jan 2007 14:30:10 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9nou-0007KT-9k for discuss@apps.ietf.org; Wed, 24 Jan 2007 14:30:10 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1H9not-0003TF-L0; Wed, 24 Jan 2007 14:30:07 -0500 Date: Wed, 24 Jan 2007 14:30:06 -0500 From: John C Klensin To: der Mouse , discuss@apps.ietf.org Subject: Re: Next step (Was: I-D ACTION:draft-klensin-unicode-escapes-00.txt Message-ID: In-Reply-To: <200701241614.LAA08010@Sparkle.Rodents.Montreal.QC.CA> References: <200701241614.LAA08010@Sparkle.Rodents.Montreal.QC.CA> X-Mailer: Mulberry/4.0.7 (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: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-Mailman-Approved-At: Wed, 24 Jan 2007 20:18:46 -0500 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 Wednesday, 24 January, 2007 11:03 -0500 der Mouse wrote: >> The mail seems to me to fall into three categories: > >> (1) Evidence that I still cannot do ABNF properly, plus a few >> other editorial issues. The most important of the ABNF >> issues is that "u" and "U" cannot be specified as different >> without escaping both into their character code positions >> (since character-literals in ABNF are case-insensitive). > This says to me that ABNF is the wrong tool for the job here. > It seems to me that we really want to specify "backslash" > "lowercase u" and "backslash" "uppercase U" rather than octet > sequences, so that the result is not tied to ASCII (while it's > unlikely that anyone wants to inject Unicode into EBCDIC text, > I just don't like seeing a problem "fixed" by introducing > other problems in a workaround instead of addressing the real > problem). It is clear to me that, if we can decide what we are trying to do, we can invent ABNF to do it -- without introducing the constraint about which you are concerned. It may be a bit clumsy, but it is feasible. The main problem here is a personal one: for historical reasons going back long before there was an IETF, I've never been a big ABNF fan. I'm even less of a fan of some of the extensions in RFC 2234/ 4234 which I consider fussy, too extensive, and unnecessary. While I have accepted the IETF consensus on ABNF (with the extensions), that distaste, aggravated by the onset of old age, has impeded my learning it well and preventing my remembering all of the details that I have learned from one time to the next. The IETF should certainly not make decisions on the basis of my problems with ABNF; even I won't make decisions on that basis. I very much appreciate the efforts of those who have learned that they have to check my work and their patience in correcting it. But let's make the right decisions and not get hung up on my idiosyncrasies. > If ABNF can't do what we want, I'd say, use something > better-suited to the need. Perhaps it would be enough to say > that the spec uses ABNF except that the character after the > backslash is case-sensitive? As I said, I'm confident we can figure something out. That would certainly be among the alternatives although my instinct would be to hunt up Dave and Paul and ask them for advice, at least as a first step. > That said, I don't consider this a showstopper - not that my > opinion of what is or isn't a showstopper necessarily > matters.... Nor mine. john From discuss-bounces@apps.ietf.org Thu Jan 25 03:02:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9zXz-000727-Kk; Thu, 25 Jan 2007 03:01:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9zXy-00071C-Ha for discuss@apps.ietf.org; Thu, 25 Jan 2007 03:01:26 -0500 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9zXu-0004Ij-4c for discuss@apps.ietf.org; Thu, 25 Jan 2007 03:01:26 -0500 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 l0P81I0X001275Thu, 25 Jan 2007 08:01:18 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1H9zXq-00053L-00; Thu, 25 Jan 2007 08:01:18 +0000 Date: Thu, 25 Jan 2007 08:01:18 +0000 From: "Clive D.W. Feather" To: John C Klensin Subject: Re: Next step (Was: I-D ACTION:draft-klensin-unicode-escapes-00.txt Message-ID: <20070125080118.GE18174@finch-staff-1.thus.net> References: <20070124153126.GA12389@nic.fr> <48AE8F8343DFAA3BC6DEB491@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48AE8F8343DFAA3BC6DEB491@p3.JCK.COM> User-Agent: Mutt/1.5.3i 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 John C Klensin said: >> But there is (may be) a rough consensus that every scheme with >> explicit delimiters (&#xNNNN; or \u{NNNNN}) is better than any >> scheme without them? If so, it would be a progress. > Much as I would personally prefer that answer, I haven't seen > such a consensus emerge yet. Well, let's start by seeing if there is. I've seen three people here in favour of it. I've seen you saying that one variety (the XML one) is ugly, but I don't know if you think that that outweighs the benefits of explicit delimiters. So: is there anybody here - including John - who thinks that the chosen format SHOULD NOT use explicit delimiters? -- 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 Jan 25 03:05:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9zbZ-0000cj-6m; Thu, 25 Jan 2007 03:05:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9zbY-0000ce-18 for discuss@apps.ietf.org; Thu, 25 Jan 2007 03:05:08 -0500 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9zbW-00055Q-Jb for discuss@apps.ietf.org; Thu, 25 Jan 2007 03:05:08 -0500 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 l0P855tR003373Thu, 25 Jan 2007 08:05:05 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1H9zbV-00057v-00; Thu, 25 Jan 2007 08:05:05 +0000 Date: Thu, 25 Jan 2007 08:05:05 +0000 From: "Clive D.W. Feather" To: John C Klensin Subject: Re: Next step (Was: I-D ACTION:draft-klensin-unicode-escapes-00.txt Message-ID: <20070125080505.GF18174@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: 9ed51c9d1356100bce94f1ae4ec616a9 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: > The mail seems to me to fall into three categories: [...] > I have seen nothing that expresses a strong preference for the > "encode UTF-8 octets" forms instead of the "represent Unicode > code points" forms. The preference for the latter was the mail > purpose of this document/ effort, so we are making progress. Good. I presume that we can also throw out any suggestion of using surrogates for code points above U+FFFF. > Let's assume that the issues in (1) and (2) can be fairly easily > addressed, Agreed - they're nitpicks rather than core issues. Once we've solved the core points, they'll fall down easily. > If it is > helpful, I can immediately issue a new draft to correct the > editorial and ABNF issues that have been identified, clearing up > (1). > > But I'd like to focus on (3), which is where the showstoppers > presumably lie. I would suggest we solve those first, then worry about a new draft. > One possibility is that I can revise the > document to indicate that there are many syntax possibilities > and that decisions should be made on a protocol-by-protocol > basis, being sure to note how to escape the escape for whatever > is chosen. I don't think that's beneficial at this point. Let's explore the delimited versus undelimited question first. -- 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 Jan 25 03:06:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9zcZ-0001Py-1S; Thu, 25 Jan 2007 03:06:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9zcX-0001Pt-VU for discuss@apps.ietf.org; Thu, 25 Jan 2007 03:06:09 -0500 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9zcV-0005Pf-JH for discuss@apps.ietf.org; Thu, 25 Jan 2007 03:06:09 -0500 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 l0P866dp003784Thu, 25 Jan 2007 08:06:06 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1H9zcU-00058s-00; Thu, 25 Jan 2007 08:06:06 +0000 Date: Thu, 25 Jan 2007 08:06:06 +0000 From: "Clive D.W. Feather" To: John C Klensin Subject: Re: Next step (Was: I-D ACTION:draft-klensin-unicode-escapes-00.txt Message-ID: <20070125080606.GG18174@finch-staff-1.thus.net> References: <200701241614.LAA08010@Sparkle.Rodents.Montreal.QC.CA> 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: d6b246023072368de71562c0ab503126 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: >> If ABNF can't do what we want, I'd say, use something >> better-suited to the need. Perhaps it would be enough to say >> that the spec uses ABNF except that the character after the >> backslash is case-sensitive? > > As I said, I'm confident we can figure something out. That > would certainly be among the alternatives although my instinct > would be to hunt up Dave and Paul and ask them for advice, at > least as a first step. Paul works in the same building as me, so I'll happily deal with that once we know what we're trying to do. -- 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 Jan 25 03:11:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9zhW-0004Ap-Mh; Thu, 25 Jan 2007 03:11:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9zhW-0004Aj-7P for discuss@apps.ietf.org; Thu, 25 Jan 2007 03:11:18 -0500 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9zhU-0007ST-Px for discuss@apps.ietf.org; Thu, 25 Jan 2007 03:11:18 -0500 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 l0P8BGrw006061Thu, 25 Jan 2007 08:11:16 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1H9zhT-0005Ic-00; Thu, 25 Jan 2007 08:11:15 +0000 Date: Thu, 25 Jan 2007 08:11:15 +0000 From: "Clive D.W. Feather" To: Frank Ellermann Subject: Re: Next step Message-ID: <20070125081115.GH18174@finch-staff-1.thus.net> References: <45B7F44F.4675@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45B7F44F.4675@xyzzy.claranet.de> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 Frank Ellermann said: > o Java uses the form \uNNNN, but can represent characters outside > Plane 0 (i.e., above U+FFFF) only by the use of surrogate pairs. > > One of the reasons why anything with \u or \U is a non-starter, there > are too many incompatible conventions in use. In particular, C uses \U with 8 hex digits because, at the time, there was a serious possibility that ISO 10646 would still allow all 32 bits (or at least 31) to be used. Had it been a few years later, we would probably have make \U indicate 6 hex digits rather than 8. > There is one significant disadvantage of the recommended form. The > > No, there are more, folks will assume that it's a convention they know > or a variant of U+NNNN[N[N]] with an arbitrary number of leading 0s. > Nobody will use \U012345 when they can hope to get away with \U12345. +1 > should not introduce any security issues that are not present as a > > My objections are also security considerations, because folks will > screw up with this encoding it could cause havoc. +2 If UTF-8 can make a security issue out of having more than one way to encode a character, so can we. [Which reminds me: being able to encode ASCII characters in this form might be a security issue as well, or it might be a useful benefit.] > In theory your proposal is compatible with C044, but in practice I > fear that it won't work as you expect it. I could live with e.g. > "authors SHOULD either pick hex. NCRs as in XML or" (your proposal), > but in fact I think that the XML-notation is much better. My only, small, discomfort is that people will expect all protocols to accept both hex (ሴ) and decimal (Ӓ). -- 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 Jan 25 06:59:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA3Fc-0003oH-Fe; Thu, 25 Jan 2007 06:58:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA3Fb-0003nw-Mk for discuss@apps.ietf.org; Thu, 25 Jan 2007 06:58:43 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA3Fa-0002Na-BO for discuss@apps.ietf.org; Thu, 25 Jan 2007 06:58:43 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HA3FY-000ACX-PK; Thu, 25 Jan 2007 06:58:40 -0500 Date: Thu, 25 Jan 2007 06:58:40 -0500 From: John C Klensin To: "Clive D.W. Feather" Subject: Re: Next step (Was: I-D ACTION:draft-klensin-unicode-escapes-00.txt Message-ID: <9A1900D9A9C2207B3C75C33A@p3.JCK.COM> In-Reply-To: <20070125080118.GE18174@finch-staff-1.thus.net> References: <20070124153126.GA12389@nic.fr> <48AE8F8343DFAA3BC6DEB491@p3.JCK.COM> <20070125080118.GE18174@finch-staff-1.thus.net> X-Mailer: Mulberry/4.0.7 (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: c1c65599517f9ac32519d043c37c5336 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, 25 January, 2007 08:01 +0000 "Clive D.W. Feather" wrote: > John C Klensin said: >>> But there is (may be) a rough consensus that every scheme >>> with explicit delimiters (&#xNNNN; or \u{NNNNN}) is better >>> than any scheme without them? If so, it would be a progress. >> Much as I would personally prefer that answer, I haven't seen >> such a consensus emerge yet. > > Well, let's start by seeing if there is. > > I've seen three people here in favour of it. I've seen you > saying that one variety (the XML one) is ugly, but I don't > know if you think that that outweighs the benefits of explicit > delimiters. > > So: is there anybody here - including John - who thinks that > the chosen format SHOULD NOT use explicit delimiters? I personally favor explicit delimiters, I have all along. My definition of "ugly" involves two things. The first may be unavoidable, the second is not: (i) Use of a sequence of special characters, none of which may be completely familiar to those who don't regularly use a fairly full set of Roman characters and both of which, IIR, are assigned to "national use" positions in ISO 646 BV, meaning that they may show up in even more different ways in some presentations. (ii) If we are going to use explicit delimiters, my aesthetic and historical sense, and the ability to get help from common programming-oriented editors and syntax-checkers, favors paired delimiters over subjectively unmatched ones, e.g., X(nnnn...) or U'nnnn...' in preference to &#nnnn...; These are, however, just matters of personal taste. john From discuss-bounces@apps.ietf.org Thu Jan 25 09:48:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA5tQ-0005OW-Mj; Thu, 25 Jan 2007 09:48:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA5tP-0005Nb-GA for discuss@apps.ietf.org; Thu, 25 Jan 2007 09:47:59 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA5tO-0005qE-5q for discuss@apps.ietf.org; Thu, 25 Jan 2007 09:47:59 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HA5tI-000BLF-AD; Thu, 25 Jan 2007 09:47:52 -0500 Date: Thu, 25 Jan 2007 09:47:51 -0500 From: John C Klensin To: "Clive D.W. Feather" Subject: Re: Typographical error in draft-klensin-unicode-escapes-00 Message-ID: <638CDDD4BD2EE58B558CB643@p3.JCK.COM> In-Reply-To: <20070122092237.GL60599@finch-staff-1.thus.net> References: <86EE78FED516BB38D35A7729@p3.JCK.COM> <20070122064002.GA60599@finch-staff-1.thus.net> <20070122092237.GL60599@finch-staff-1.thus.net> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 1.1 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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, 22 January, 2007 09:22 +0000 "Clive D.W. Feather" wrote: > We may have to agree to disagree. When I see "4*4XXX", it > makes me wonder if the author actually meant "4*" or "*4" and > misunderstood the notation. I am skipping ABNF quibbles for -01, leaving it for -02 (I hope). It would take very little more of this particular discussion for me to shift back to pure BNF and write a justification for it rather than trying to use ABNF at all. The tool is, IMO, complicating clear expression here, rather than aiding it. However, see my note from yesterday. However... > Incidentally, there's no significance to the groupings of 4 in > the \u notation, so I see little point in introducing > "Hex-quad". That terminology was appropriated from the C documents. > The term "BMP" is, as I understand it, deprecated > these days. I thought so too, until I discovered that it is extensively used in the Unicode 5.0 book. Take it up with the UTC :-( > So I would just write: > > EmbeddedUnicodeChar = %x5C.75 4HexDigit / %x5C.55 8HexDigit > > or if you really want: > > EmbeddedUnicodeChar = UnicodeShortForm / UnicodeLongForm > UnicodeShortForm = %x5C.75 4HexDigit > UnicodeLongForm = %x5C.55 8HexDigit > > [Note that you omitted the / from your definition.] Caught and fixed. Thanks. john From discuss-bounces@apps.ietf.org Fri Jan 26 16:57:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAZ35-000394-WB; Fri, 26 Jan 2007 16:55:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAZ35-00038w-Cu for discuss@apps.ietf.org; Fri, 26 Jan 2007 16:55:55 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAZ34-00068k-3A for discuss@apps.ietf.org; Fri, 26 Jan 2007 16:55:55 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HAZ2s-0001Ti-EV for discuss@apps.ietf.org; Fri, 26 Jan 2007 22:55:42 +0100 Received: from d254130.dialin.hansenet.de ([80.171.254.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 22:55:42 +0100 Received: from nobody by d254130.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 22:55:42 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: discuss@apps.ietf.org From: Frank Ellermann Subject: Re: Next step Date: Fri, 26 Jan 2007 22:55:12 +0100 Organization: Lines: 23 Message-ID: <45BA78C0.4DA2@xyzzy.claranet.de> References: <45B7F44F.4675@xyzzy.claranet.de> <20070125081115.GH18174@finch-staff-1.thus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254130.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) 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 Clive D.W. Feather wrote: >> In theory your proposal is compatible with C044, but in practice I >> fear that it won't work as you expect it. I could live with e.g. >> "authors SHOULD either pick hex. NCRs as in XML or" (your proposal), >> but in fact I think that the XML-notation is much better. > My only, small, discomfort is that people will expect all protocols > to accept both hex (ሴ) and decimal (Ӓ). Then they are at odds with and , and missed the most important W3C last call in this millennium... slighty exaggerated. Seriously, that's something where a MUST might do what we both want. RFC 4646 chapter 3.1 simply states this as fact, and it uses MUSTard elsewhere rather frankly. Decimal NCRs are horrible, and the last browser worldwide not supporting hex. NCRs in text/html is under my firm control... :-) Frank From discuss-bounces@apps.ietf.org Fri Jan 26 17:35:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAZfD-00015p-23; Fri, 26 Jan 2007 17:35:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAZfA-00015f-Vz for discuss@apps.ietf.org; Fri, 26 Jan 2007 17:35:18 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAZf9-00042O-Lz for discuss@apps.ietf.org; Fri, 26 Jan 2007 17:35:16 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HAZf2-00085B-DP for discuss@apps.ietf.org; Fri, 26 Jan 2007 23:35:08 +0100 Received: from d254130.dialin.hansenet.de ([80.171.254.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 23:35:08 +0100 Received: from nobody by d254130.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 23:35:08 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: discuss@apps.ietf.org From: Frank Ellermann Subject: Re: Next step Date: Fri, 26 Jan 2007 23:34:46 +0100 Organization: Lines: 26 Message-ID: <45BA8206.3532@xyzzy.claranet.de> References: <20070124153126.GA12389@nic.fr> <48AE8F8343DFAA3BC6DEB491@p3.JCK.COM> <20070125080118.GE18174@finch-staff-1.thus.net> <9A1900D9A9C2207B3C75C33A@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254130.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: [􂍅 might be ugly] > Use of a sequence of special characters, none of which may > be completely familiar to those who don't regularly use a > fairly full set of Roman characters and both of which, IIR, > are assigned to "national use" positions in ISO 646 BV No C trigraph for "&", but "#" has "??=". IMO that's a historic foot note, nobody used weird "national variants" of ASCII for at least a decade. And we're talking about US ASCII anyway. > the ability to get help from common programming-oriented > editors and syntax-checkers, favors paired delimiters over > subjectively unmatched ones Is that about protocols needing a new escape mechanism, or about the prose in RFCs ? In the former case some piece of software will do it, in the latter case an editor macro can take care of the raw UTF-8 or whatever it is. An example is for an XEDIT-clone. Frank From discuss-bounces@apps.ietf.org Mon Jan 29 09:06:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBX7n-0005rx-HV; Mon, 29 Jan 2007 09:04:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBX7m-0005rr-I0 for discuss@apps.ietf.org; Mon, 29 Jan 2007 09:04:46 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBX7k-0007ci-9f for discuss@apps.ietf.org; Mon, 29 Jan 2007 09:04:46 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HBX7g-000Luz-7D; Mon, 29 Jan 2007 09:04:40 -0500 Date: Mon, 29 Jan 2007 09:04:39 -0500 From: John C Klensin To: "Clive D.W. Feather" Subject: Re: FWD: I-D ACTION:draft-klensin-unicode-escapes-00.txt Message-ID: <212BD43DEF5902CBAAEE9CB9@p3.JCK.COM> X-Mailer: Mulberry/4.0.7 (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: 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 Monday, 22 January, 2007 08:48 +0000 "Clive D.W. Feather" wrote: > Please remove the term "extended ASCII" from 1.1 - there is no > such thing. If you want to talk about an 8 bit character set, > then "the ISO 8859 family" would do. FWIW, while I fixed this text, more or less as you suggested (and it needed fixing), there actually was an ANSI Standard "ASCII-8" for a while. If I recall, it was ultimately withdrawn in favor of ANSI/INCITS endorsement of ISO 8859-1, but "extended ASCII" was actually well-defined. john From discuss-bounces@apps.ietf.org Mon Jan 29 09:09:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBXBI-0007Gy-GY; Mon, 29 Jan 2007 09:08:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBXBH-0007Gq-KM for discuss@apps.ietf.org; Mon, 29 Jan 2007 09:08:23 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBXBG-00082w-8z for discuss@apps.ietf.org; Mon, 29 Jan 2007 09:08:23 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HBWdc-000LkU-Br for discuss@apps.ietf.org; Mon, 29 Jan 2007 08:33:36 -0500 Date: Mon, 29 Jan 2007 08:33:35 -0500 From: John C Klensin To: discuss@apps.ietf.org Subject: New draft (Was: I-D ACTION:draft-klensin-unicode-escapes-00.txt Message-ID: <875A124D75A8B481E176CF06@p3.JCK.COM> X-Mailer: Mulberry/4.0.7 (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: 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 Hi. We have reached the point at which several people are repeating essentially the same suggestions. That probably represents progress, but it also indicates to me that the -00 version of the draft has outlived its usefulness. I've just submitted draft-klensin-unicode-escapes-01.txt and assume it will show up in the posting directory today or tomorrow. Highlights (if I got things right): * All of the typographic editorial errors that have been identified have been fixed. * The preference for \u / \U has been removed and the document restructured to express no preference among the several ways to denote Unicode code points. However, the preference of many for paired delimiters has been made explicit, as has a prohibition on surrogates. * The issue of escaping escapes has been avoided, leaving that problem to the applications and protocols that use the escapes. That may not be good enough, but it at least moves us forward and should facilitate a focused discussion. There are two sets of suggestions I haven't followed (yet): * Frank made a strong recommendation that we make an explicit and normative reference to W3C's CharMod spec and call out several of its explicit rules. There is a tradeoff with length, additional need to read other documents, and general document and reading complexity. It may no longer be needed. Opinions and comments welcome. * I have not touched the ABNF associated with the \u / \U case. I have inserted an explicit placeholder but, as discussed on this list, I think we need to figure out what we want to do and then go back and adjust the metalanguage productions. In particular, there has been one strong suggestion, with which I agree, that we not take the obvious approach of substituting %x5C.75 for "\u", since the intent is a character string abstraction (independent of the implementation character set) rather than specific octets. thanks, john From discuss-bounces@apps.ietf.org Mon Jan 29 09:37:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBXdF-0001jw-NV; Mon, 29 Jan 2007 09:37:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBXdD-0001jr-Tu for discuss@apps.ietf.org; Mon, 29 Jan 2007 09:37:15 -0500 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBXd8-0003jb-Hc for discuss@apps.ietf.org; Mon, 29 Jan 2007 09:37:15 -0500 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 l0TEb21D003119Mon, 29 Jan 2007 14:37:02 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1HBXd0-00072N-00; Mon, 29 Jan 2007 14:37:02 +0000 Date: Mon, 29 Jan 2007 14:37:02 +0000 From: "Clive D.W. Feather" To: John C Klensin Subject: Re: FWD: I-D ACTION:draft-klensin-unicode-escapes-00.txt Message-ID: <20070129143702.GN2032@finch-staff-1.thus.net> References: <212BD43DEF5902CBAAEE9CB9@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <212BD43DEF5902CBAAEE9CB9@p3.JCK.COM> 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: >> Please remove the term "extended ASCII" from 1.1 - there is no >> such thing. If you want to talk about an 8 bit character set, >> then "the ISO 8859 family" would do. > > FWIW, while I fixed this text, more or less as you suggested > (and it needed fixing), there actually was an ANSI Standard > "ASCII-8" for a while. If I recall, it was ultimately withdrawn > in favor of ANSI/INCITS endorsement of ISO 8859-1, but "extended > ASCII" was actually well-defined. Hmm, I live and learn. Do you have a document number or something that I can investigate further? A bit of googling suggests you are correct but doesn't tell me any more than that. -- 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 Jan 29 19:54:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBhG3-00009d-OU; Mon, 29 Jan 2007 19:53:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBhG3-00009V-CO for discuss@apps.ietf.org; Mon, 29 Jan 2007 19:53:59 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBhG1-00025m-W7 for discuss@apps.ietf.org; Mon, 29 Jan 2007 19:53:59 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HBhG1-0000VJ-Ci; Mon, 29 Jan 2007 19:53:57 -0500 Date: Mon, 29 Jan 2007 19:53:56 -0500 From: John C Klensin To: Bjoern Hoehrmann Subject: Re: New draft (Was: I-D ACTION:draft-klensin-unicode-escapes-00.txt Message-ID: In-Reply-To: References: <875A124D75A8B481E176CF06@p3.JCK.COM> X-Mailer: Mulberry/4.0.7 (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: 02ec665d00de228c50c93ed6b5e4fc1a 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, 29 January, 2007 22:32 +0100 Bjoern Hoehrmann wrote: >... >> * The issue of escaping escapes has been avoided, >> leaving that problem to the applications and protocols >> that use the escapes. That may not be good enough, but >> it at least moves us forward and should facilitate a >> focused discussion. > > I think better discussion of this case, and also escaping > characters with some pre-defined meaning inside a protocol > element that accepts UTF-8, is necessary. E.g., in section 1.1 > it is said "This recommen- dation is not applicable to > protocols that already accept native UTF-8 or some other > encoding of Unicode." I am not sure how to read that in such a > case. If the protocol can actually accept UTF-8 (or UTF-16 or UTF-32), this recommendation is not applicable at all. If it is somehow necessary to escape Unicode characters that have special interpretations in those environments, that is the problem of the relevant protocols. Beyond that, I'm always open to suggested text. > Some nits: > > In section 3 I am not sure how to read "U+NNN[N[N]]". Perhaps > there is an "N" missing? That is correct. And , I thought I had caught all of those. Fixed in -02. Sorry. > I think this should say instead in > prose that four to six digits should be used. Section 1.1 uses > "U+NNNN[N[N]]", there I'd prefer to simply use U+NNNN or > U+NNNNNN. But, as long as five characters is permissible (and it is a frequent case), either of those two cases would be wrong. I've added prose in the working draft for -02 to the first case. > In section 5.2 it is said HTML uses the &#xNNNN; form and that > this form has a clear terminator. This is not really false but > HTML allows to omit the terminator if it is not needed, for > example

Björn

is also valid. I would suggest to > mention only XML or note that HTML's mechanism is similar to > that of XML. Good. Will fix. thanks, john From discuss-bounces@apps.ietf.org Mon Jan 29 23:39:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBkl6-0002XU-Fk; Mon, 29 Jan 2007 23:38:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBkl5-0002XP-05 for discuss@apps.ietf.org; Mon, 29 Jan 2007 23:38:15 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBkl3-0003PN-G4 for discuss@apps.ietf.org; Mon, 29 Jan 2007 23:38:14 -0500 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0U4cCkq014945 for ; Mon, 29 Jan 2007 21:38:12 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCN00F01XZ8TO00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for discuss@apps.ietf.org; Mon, 29 Jan 2007 21:38:12 -0700 (MST) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCN00ABAZJMGE00@mail-amer.sun.com>; Mon, 29 Jan 2007 21:38:12 -0700 (MST) Date: Mon, 29 Jan 2007 20:38:09 -0800 From: Chris Newman Subject: TLS 1.1/1.2 impact on applications protocols To: Apps Discuss Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Pasi Eronen , Eric Rescorla 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 changes that are happening in the TLS WG with the publication of TLS 1.1 and the upcoming TLS 1.2 do have a significant impact on application deployment. Many of our application protocols make TLS 1.0 mandatory-to-implement. I'd like to see a discussion of the importance of transition to 1.2 (when it comes out) and the real-world problems that might occur. Do we need to update our application protocol specifications to mandate the newer version? Or perhaps we need an app-area RFC which does that to a set of application protocols? Can we just have a blanket exception to the standards status (proposed/draft/full) reference rules for the TLS base spec (and trust the TLS WG to do the right thing)? It seems more important to keep up-to-date on security technology than to have normative reference purity. Perhaps this would be a good topic for the Prague apparea meeting? - Chris From discuss-bounces@apps.ietf.org Tue Jan 30 13:37:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBxps-0004fi-28; Tue, 30 Jan 2007 13:36:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwMh-0007Nw-AM for discuss@apps.ietf.org; Tue, 30 Jan 2007 12:01:51 -0500 Received: from cliffie.verisignlabs.com ([65.201.175.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBwMg-0000k4-37 for discuss@apps.ietf.org; Tue, 30 Jan 2007 12:01:51 -0500 Received: from monsoon.verisignlabs.com (scooter.bo.verisignlabs.com [172.25.170.10]) by cliffie.verisignlabs.com (Postfix) with ESMTP id 8D0961366CF; Tue, 30 Jan 2007 12:01:39 -0500 (EST) Received: from dul1shollenbl1 (dul1shollenb-l1.vcorp.ad.vrsn.com [10.131.30.36]) by monsoon.verisignlabs.com (Postfix) with ESMTP id 61C45137B6A; Tue, 30 Jan 2007 12:01:39 -0500 (EST) From: "Scott Hollenbeck" To: "Scott Hollenbeck" References: Subject: RE: TLS 1.1/1.2 impact on applications protocols Date: Tue, 30 Jan 2007 12:02:35 -0500 Message-ID: <000001c74490$70856c00$241e830a@vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C74466.87AF6400" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcdEKJRA18rbkd0zTamFdBqqZCWWwAANiYwg In-Reply-To: x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 x-olkeid: 02C41520214F5DC94561F2428A95B2A51BA14756 X-MS-TNEF-Correlator: 000000006412D0F74E2E1D4D922E972CF1AB7EB307003CD14E451751BD42BA48AAA50B07BAD60000000B1E3600008DF021A98B708045980B2056266E8E3600000D04E52A0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 X-Mailman-Approved-At: Tue, 30 Jan 2007 13:36:03 -0500 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 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C74466.87AF6400 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Chris Newman [mailto:Chris.Newman@Sun.COM] > Sent: Monday, January 29, 2007 11:38 PM > To: Apps Discuss > Cc: Pasi Eronen; Eric Rescorla > Subject: TLS 1.1/1.2 impact on applications protocols > > The changes that are happening in the TLS WG with the > publication of TLS 1.1 and the upcoming TLS 1.2 do have a > significant impact on application deployment. Many of our > application protocols make TLS 1.0 mandatory-to-implement. > I'd like to see a discussion of the importance of transition > to 1.2 (when it comes out) and the real-world problems that > might occur. Do we need to update our application protocol > specifications to mandate the newer version? Or perhaps we > need an app-area RFC which does that to a set of application > protocols? > > Can we just have a blanket exception to the standards status > (proposed/draft/full) reference rules for the TLS base spec > (and trust the TLS WG to do the right thing)? It seems more > important to keep up-to-date on security technology than to > have normative reference purity. > > Perhaps this would be a good topic for the Prague apparea meeting? I just ran into this very situation in the process of bringing EPP (RFCs 3730 - 3734) to Draft. The IESG was OK with a normative downward reference to TLS 1.0 and some additional text to note that the work is still evolving. Here's what we agreed to say: "When layered over TCP, the Transport Layer Security (TLS) Protocol version 1.0 [RFC2246] or its successors (such as TLS 1.1 [RFC4346]), using the latest version supported by both parties, MUST be used to provide integrity, confidentiality, and mutual strong client-server authentication." The reference to 2246 is normative; a downref note and exception processing was required. The reference to 4346 is informative. This approach worked because EPP does not depend on any version-specific features of TLS. The situation may well be different for other protocols. -Scott- ------=_NextPart_000_0001_01C74466.87AF6400 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IiMRAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQYABwABAAAAAAAAAQOQBgBACwAAIAAAAAIBMQABAAAARgAAAAAA AABkEtD3Ti4dTZIulyzxq36zBwA80U5FF1G9QrpIqqULB7rWAAAACx41AACN8CGpi3CARZgLIFYm bo42AAAF1j5TAAAAAB4AcAABAAAALQAAAFRMUyAxLjEvMS4yIGltcGFjdCBvbiBhcHBsaWNhdGlv bnMgcHJvdG9jb2xzAAAAAAIBcQABAAAAGwAAAAHHRCiUQNfK25HdM02phXQaqmQllsAADYmMIAAC AQoOAQAAAC4AAAAAAAAAZBLQ904uHU2SLpcs8at+swEAPNFORRdRvUK6SKqlCwe61gAAAAseNwAA AAADABQOAQAAAB4AKA4BAAAAKgAAADAwMDAwMDBjAXNhaC1pZXRmQHRlbmd3YXIuY29tAXRlbmd3 YXIuY29tAAAAHgApDgEAAAAqAAAAMDAwMDAwMGMBc2FoLWlldGZAdGVuZ3dhci5jb20BdGVuZ3dh ci5jb20AAAACAQkQAQAAABUGAAARBgAAhgkAAExaRnW5IzGkAwAKAHJjcGcxMjXiMgNDdGV4BUEB AwH3/wqAAqQD5AcTAoAP8wBQBFY/CFUHshElDlEDAQIAY2jhCsBzZXQyBgAGwxEl9jMERhO3MBIs ETMI7wn3tjsYHw4wNREiDGBjAFAzCwkBZDM2FlALpiA+1CAtHRJPBRBnC4AHQMMF0AeQc2FnZR0T CuOrCoAc8EYDYToSIGgFEBsHowOCWwDAAxB0bzoFH6MuIARAU3VuLvBDT01dHrcGYAIwH4ACTQIg ZGF5LCBKhQBwdQrAeSAyOSOQAQHQMDcgMTE6M9A4IFBNHrdUINAQwJRwcAQgRAQAY3UEEkke1UNj H4BQYQCQIOpFA2BuCfA7J+EN4AfwjweQBaELYCJIdWJqBZAJIwFUTAXwMS4xL18qoBRAB3AKsCog IAIgIIphJiBsDeBhdGkCIH0EIHADYCDAF5EmyCVXaLRlIBPRbh5ABCB0E+B/BUAKwC5QE+AmIAnw C4BnHysQA6Au8C5QKmJXRyDvA/Au8DBDHsZwKeAr9iuAnmYqViuwI1AwQ3VwBaBObS/iKmQUQGRv L3F21y5QKTgAkGcDAGYsAQIwbysfMnQBAAtQbwbAIuEu/iAF0ABwJBAy0QhhHrc3mvssmADAazB0 KqAWUAOBI2ArIMAkAC0gwC028Wxl8zi1HsZJJzOgK/A74SDA9zYgCeA1gWQmdDKVMFI28dsXwQBw Yy5QQHJyAHIyg+cexj8xKuIody5AA6AxEM8uYANwB5EIYHQpM3cYIPkHQC13KQEzoCyRAmA9oKcu 1R7GNEBnaCtxYyaQ6nI48UQ1IHcuUCggCYD/PyI0ADzBQXE5sTpvF5E1qP0vsGM2cyw0PzE8lD8R LkG/KCBIQAXANWAUACxBPzkA/x1gLIAEkC+BBCBIQR7GSHMbA5ErwS0vQSkwUkZD/TDwaA3gMTA1 EC7GPzEpMH8UETLCN5oxlyymTiAtPkP7A5FIQWomoAVANUUCYABw/zvgBUAOwEFgBTAykj8xMFLf VkA8ogsgBCBYcXQmoB63jigskUEAFBBkL2RB0MEBgC9mdWxsRIAYIO5mBJAJ8EFhclsQB5ECEPsF wDBWYiewWFFLgVl4M4P/XABWQTBZPzE1EUTjR0Mu8PUv4SlOIUkFQD9hRjEEYP8vUR7GQOZR4zvg OGAz8T0i/0kUA6AUEEexMRAkEA6wE9D6bhehZ2UBLoE/Ih7GNUP9ZWByAMAsMDVhW2gyEGTS+zjw LT5QTpVgoU7hCGBFobJiNXJnbwRwPyFwKJH1XGZQQdBnClArslBzB4DvFCAv4VSWHsRJVhRB0TAR /1gDH9FNsSQQQgEj4DKDMCXvLJFBYAQRMtFiBRAuoC/iOEVQUENQUMEEIDM3bjMWUB6gc2E0RIA/ MUTHWrI48S4ySUVTMOEnsD1OQEsw9CkwZyg1EHduv3VwCyBbWT8xPBYzgnNEAf0rsGQ/wCwyHcEO sz8xZWDvTONR0i5BRXFrNuBY8gMQaQMgZXYG8HYv4TjxSP1bkSdO4S8CSEEeMAnRSKPJHiB5Om4a IldDggtgNnlbkTOgb02xJcBDUM8jkDBTQdJBAiBMgAIGUf1ktSgqYUSAbJBKhU21PEPCW1DBMjI0 NiIwBbG/MRBY8RrQcbIFsAQgKIWhb3YRBCAzBoSSNHPwhQAp/yOQJqAv4jBSC2AOsFZBg9bvhaAm IBfBSJFiJBAG4DEhDwqxLDAHkCOQTVVTVH9rAiagSJQskXyQAQBvcmXvCcBk4SOQBaBuNoABAAIw 9wcxjUMzgm1EYCPgAyBWQFsoATAAYyvwIuEtFBByPYCCYURgQ4EsMCwULiL/bhouMneLhNJ7smcn KFA/of93AVtheoQzgldocYUv4nVy8RggcXVpGCF0tXeLh6L/e7ILgFxhZ1R0sx/RK8EDYP8A0DEw e3KKIgWQkKBdQXLC/1FjepE4QgnwgFEroTlBTbX/kCBLhVxQRTBZQBggceMqYf90tXB4AMAkEEhA fCFrET/AfwEgW5IFQFxiipESgSyXLlluGi1TBaACQC0exH0BpVAAAAACARQ6AQAAABAAAACP8+43 je0bRqy31Tj3/VkmAwDeP59OAAADAAlZAQAAAAsAk4AIIAYAAAAAAMAAAAAAAABGAAAAAIKFAAAB AAAAHgDLgIYDAgAAAAAAwAAAAAAAAEYBAAAAFAAAAHgALQBtAGkAbQBlAG8AbABlAAAAAQAAAC4A AABQcm9kdWNlZCBCeSBNaWNyb3NvZnQgTWltZU9MRSBWNi4wMC4yOTAwLjMwMjgAAAAeAOKAhgMC AAAAAADAAAAAAAAARgEAAAASAAAAeAAtAG8AbABrAGUAaQBkAAAAAAABAAAAKQAAADAyQzQxNTIw MjE0RjVEQzk0NTYxRjI0MjhBOTVCMkE1MUJBMTQ3NTYAAAAAHgDngAggBgAAAAAAwAAAAAAAAEYA AAAAg4UAAAEAAAATAAAANjUxMDMxNjEyLTMwMDEyMDA3AAAeAD6BhgMCAAAAAADAAAAAAAAARgEA AAASAAAAeAAtAG0AYQBpAGwAZQByAAAAAAABAAAAHAAAAE1pY3Jvc29mdCBPZmZpY2UgT3V0bG9v ayAxMQALAB8OAQAAAAIB+A8BAAAAEAAAAKyFOM+XaUdEmQWpVGYbja0CAfoPAQAAABAAAABkEtD3 Ti4dTZIulyzxq36zAwD+DwUAAAADAA00/T8FAAMADzT9PwUAAgEUNAEAAAAQAAAAVJShwCl/EBul hwgAKyolFx4A+j8BAAAAEgAAAEhvbGxlbmJlY2ssIFNjb3R0AAAAAgHiZQEAAAAUAAAAyDxZaA21 Iked9h1VNlq3igAH5GsCAeNlAQAAABUAAAAUyDxZaA21Iked9h1VNlq3igAH5GsAAAACAX8AAQAA AI0AAAAwMDAwMDAwMDY0MTJEMEY3NEUyRTFENEQ5MjJFOTcyQ0YxQUI3RUIzMDcwMDNDRDE0RTQ1 MTc1MUJENDJCQTQ4QUFBNTBCMDdCQUQ2MDAwMDAwMEIxRTM2MDAwMDhERjAyMUE5OEI3MDgwNDU5 ODBCMjA1NjI2NkU4RTM2MDAwMDBEMDRFNTJBMDAwMAAAAAADAAYQ/kqn3wMABxAzBgAAAwAQEAEA AAADABEQAAAAAB4ACBABAAAAZQAAAC0tLS0tT1JJR0lOQUxNRVNTQUdFLS0tLS1GUk9NOkNIUklT TkVXTUFOTUFJTFRPOkNIUklTTkVXTUFOQFNVTkNPTVNFTlQ6TU9OREFZLEpBTlVBUlkyOSwyMDA3 MTE6MzhQTVQAAAAAbC8= ------=_NextPart_000_0001_01C74466.87AF6400-- From discuss-bounces@apps.ietf.org Tue Jan 30 16:50:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC0rv-0001LQ-Go; Tue, 30 Jan 2007 16:50:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC0rt-0001LL-Fo for discuss@apps.ietf.org; Tue, 30 Jan 2007 16:50:21 -0500 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC0ro-0000RV-Px for discuss@apps.ietf.org; Tue, 30 Jan 2007 16:50:21 -0500 Received: from [192.168.1.102] (unknown [59.167.190.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 074DC51931 for ; Tue, 30 Jan 2007 16:50:12 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <000001c74490$70856c00$241e830a@vcorp.ad.vrsn.com> References: <000001c74490$70856c00$241e830a@vcorp.ad.vrsn.com> Content-Type: multipart/mixed; boundary=Apple-Mail-6-760565169 Message-Id: <811E6993-8834-40A1-BB83-6838D60BE885@mnot.net> X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: TLS 1.1/1.2 impact on applications protocols Date: Wed, 31 Jan 2007 08:50:09 +1100 To: Apps Discuss X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 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-6-760565169 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed The language Scott references ("using the latest version supported by both parties") seems reasonable, but I think what's being asked for is for the latest version to automatically become MTI. Cheers, On 2007/01/31, at 4:02 AM, Scott Hollenbeck wrote: >> -----Original Message----- >> From: Chris Newman [mailto:Chris.Newman@Sun.COM] >> Sent: Monday, January 29, 2007 11:38 PM >> To: Apps Discuss >> Cc: Pasi Eronen; Eric Rescorla >> Subject: TLS 1.1/1.2 impact on applications protocols >> >> The changes that are happening in the TLS WG with the >> publication of TLS 1.1 and the upcoming TLS 1.2 do have a >> significant impact on application deployment. Many of our >> application protocols make TLS 1.0 mandatory-to-implement. >> I'd like to see a discussion of the importance of transition >> to 1.2 (when it comes out) and the real-world problems that >> might occur. Do we need to update our application protocol >> specifications to mandate the newer version? Or perhaps we >> need an app-area RFC which does that to a set of application >> protocols? >> >> Can we just have a blanket exception to the standards status >> (proposed/draft/full) reference rules for the TLS base spec >> (and trust the TLS WG to do the right thing)? It seems more >> important to keep up-to-date on security technology than to >> have normative reference purity. >> >> Perhaps this would be a good topic for the Prague apparea meeting? > > I just ran into this very situation in the process of bringing EPP > (RFCs > 3730 - 3734) to Draft. The IESG was OK with a normative downward > reference > to TLS 1.0 and some additional text to note that the work is still > evolving. > Here's what we agreed to say: > > "When layered over TCP, the Transport Layer Security (TLS) Protocol > version > 1.0 [RFC2246] or its successors (such as TLS 1.1 [RFC4346]), using the > latest version supported by both parties, MUST be used to provide > integrity, > confidentiality, and mutual strong client-server authentication." > > The reference to 2246 is normative; a downref note and exception > processing > was required. The reference to 4346 is informative. This approach > worked > because EPP does not depend on any version-specific features of > TLS. The > situation may well be different for other protocols. > > -Scott- --Apple-Mail-6-760565169 Content-Transfer-Encoding: base64 Content-Type: application/ms-tnef; x-unix-mode=0666; name=winmail.dat Content-Disposition: attachment; filename=winmail.dat eJ8+IiMRAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQYABwABAAAAAAAAAQOQBgBACwAAIAAAAAIBMQABAAAARgAAAAAA AABkEtD3Ti4dTZIulyzxq36zBwA80U5FF1G9QrpIqqULB7rWAAAACx41AACN8CGpi3CARZgLIFYm bo42AAAF1j5TAAAAAB4AcAABAAAALQAAAFRMUyAxLjEvMS4yIGltcGFjdCBvbiBhcHBsaWNhdGlv bnMgcHJvdG9jb2xzAAAAAAIBcQABAAAAGwAAAAHHRCiUQNfK25HdM02phXQaqmQllsAADYmMIAAC AQoOAQAAAC4AAAAAAAAAZBLQ904uHU2SLpcs8at+swEAPNFORRdRvUK6SKqlCwe61gAAAAseNwAA AAADABQOAQAAAB4AKA4BAAAAKgAAADAwMDAwMDBjAXNhaC1pZXRmQHRlbmd3YXIuY29tAXRlbmd3 YXIuY29tAAAAHgApDgEAAAAqAAAAMDAwMDAwMGMBc2FoLWlldGZAdGVuZ3dhci5jb20BdGVuZ3dh ci5jb20AAAACAQkQAQAAABUGAAARBgAAhgkAAExaRnW5IzGkAwAKAHJjcGcxMjXiMgNDdGV4BUEB AwH3/wqAAqQD5AcTAoAP8wBQBFY/CFUHshElDlEDAQIAY2jhCsBzZXQyBgAGwxEl9jMERhO3MBIs ETMI7wn3tjsYHw4wNREiDGBjAFAzCwkBZDM2FlALpiA+1CAtHRJPBRBnC4AHQMMF0AeQc2FnZR0T CuOrCoAc8EYDYToSIGgFEBsHowOCWwDAAxB0bzoFH6MuIARAU3VuLvBDT01dHrcGYAIwH4ACTQIg ZGF5LCBKhQBwdQrAeSAyOSOQAQHQMDcgMTE6M9A4IFBNHrdUINAQwJRwcAQgRAQAY3UEEkke1UNj H4BQYQCQIOpFA2BuCfA7J+EN4AfwjweQBaELYCJIdWJqBZAJIwFUTAXwMS4xL18qoBRAB3AKsCog IAIgIIphJiBsDeBhdGkCIH0EIHADYCDAF5EmyCVXaLRlIBPRbh5ABCB0E+B/BUAKwC5QE+AmIAnw C4BnHysQA6Au8C5QKmJXRyDvA/Au8DBDHsZwKeAr9iuAnmYqViuwI1AwQ3VwBaBObS/iKmQUQGRv L3F21y5QKTgAkGcDAGYsAQIwbysfMnQBAAtQbwbAIuEu/iAF0ABwJBAy0QhhHrc3mvssmADAazB0 KqAWUAOBI2ArIMAkAC0gwC028Wxl8zi1HsZJJzOgK/A74SDA9zYgCeA1gWQmdDKVMFI28dsXwQBw Yy5QQHJyAHIyg+cexj8xKuIody5AA6AxEM8uYANwB5EIYHQpM3cYIPkHQC13KQEzoCyRAmA9oKcu 1R7GNEBnaCtxYyaQ6nI48UQ1IHcuUCggCYD/PyI0ADzBQXE5sTpvF5E1qP0vsGM2cyw0PzE8lD8R LkG/KCBIQAXANWAUACxBPzkA/x1gLIAEkC+BBCBIQR7GSHMbA5ErwS0vQSkwUkZD/TDwaA3gMTA1 EC7GPzEpMH8UETLCN5oxlyymTiAtPkP7A5FIQWomoAVANUUCYABw/zvgBUAOwEFgBTAykj8xMFLf VkA8ogsgBCBYcXQmoB63jigskUEAFBBkL2RB0MEBgC9mdWxsRIAYIO5mBJAJ8EFhclsQB5ECEPsF wDBWYiewWFFLgVl4M4P/XABWQTBZPzE1EUTjR0Mu8PUv4SlOIUkFQD9hRjEEYP8vUR7GQOZR4zvg OGAz8T0i/0kUA6AUEEexMRAkEA6wE9D6bhehZ2UBLoE/Ih7GNUP9ZWByAMAsMDVhW2gyEGTS+zjw LT5QTpVgoU7hCGBFobJiNXJnbwRwPyFwKJH1XGZQQdBnClArslBzB4DvFCAv4VSWHsRJVhRB0TAR /1gDH9FNsSQQQgEj4DKDMCXvLJFBYAQRMtFiBRAuoC/iOEVQUENQUMEEIDM3bjMWUB6gc2E0RIA/ MUTHWrI48S4ySUVTMOEnsD1OQEsw9CkwZyg1EHduv3VwCyBbWT8xPBYzgnNEAf0rsGQ/wCwyHcEO sz8xZWDvTONR0i5BRXFrNuBY8gMQaQMgZXYG8HYv4TjxSP1bkSdO4S8CSEEeMAnRSKPJHiB5Om4a IldDggtgNnlbkTOgb02xJcBDUM8jkDBTQdJBAiBMgAIGUf1ktSgqYUSAbJBKhU21PEPCW1DBMjI0 NiIwBbG/MRBY8RrQcbIFsAQgKIWhb3YRBCAzBoSSNHPwhQAp/yOQJqAv4jBSC2AOsFZBg9bvhaAm IBfBSJFiJBAG4DEhDwqxLDAHkCOQTVVTVH9rAiagSJQskXyQAQBvcmXvCcBk4SOQBaBuNoABAAIw 9wcxjUMzgm1EYCPgAyBWQFsoATAAYyvwIuEtFBByPYCCYURgQ4EsMCwULiL/bhouMneLhNJ7smcn KFA/of93AVtheoQzgldocYUv4nVy8RggcXVpGCF0tXeLh6L/e7ILgFxhZ1R0sx/RK8EDYP8A0DEw e3KKIgWQkKBdQXLC/1FjepE4QgnwgFEroTlBTbX/kCBLhVxQRTBZQBggceMqYf90tXB4AMAkEEhA fCFrET/AfwEgW5IFQFxiipESgSyXLlluGi1TBaACQC0exH0BpVAAAAACARQ6AQAAABAAAACP8+43 je0bRqy31Tj3/VkmAwDeP59OAAADAAlZAQAAAAsAk4AIIAYAAAAAAMAAAAAAAABGAAAAAIKFAAAB AAAAHgDLgIYDAgAAAAAAwAAAAAAAAEYBAAAAFAAAAHgALQBtAGkAbQBlAG8AbABlAAAAAQAAAC4A AABQcm9kdWNlZCBCeSBNaWNyb3NvZnQgTWltZU9MRSBWNi4wMC4yOTAwLjMwMjgAAAAeAOKAhgMC AAAAAADAAAAAAAAARgEAAAASAAAAeAAtAG8AbABrAGUAaQBkAAAAAAABAAAAKQAAADAyQzQxNTIw MjE0RjVEQzk0NTYxRjI0MjhBOTVCMkE1MUJBMTQ3NTYAAAAAHgDngAggBgAAAAAAwAAAAAAAAEYA AAAAg4UAAAEAAAATAAAANjUxMDMxNjEyLTMwMDEyMDA3AAAeAD6BhgMCAAAAAADAAAAAAAAARgEA AAASAAAAeAAtAG0AYQBpAGwAZQByAAAAAAABAAAAHAAAAE1pY3Jvc29mdCBPZmZpY2UgT3V0bG9v ayAxMQALAB8OAQAAAAIB+A8BAAAAEAAAAKyFOM+XaUdEmQWpVGYbja0CAfoPAQAAABAAAABkEtD3 Ti4dTZIulyzxq36zAwD+DwUAAAADAA00/T8FAAMADzT9PwUAAgEUNAEAAAAQAAAAVJShwCl/EBul hwgAKyolFx4A+j8BAAAAEgAAAEhvbGxlbmJlY2ssIFNjb3R0AAAAAgHiZQEAAAAUAAAAyDxZaA21 Iked9h1VNlq3igAH5GsCAeNlAQAAABUAAAAUyDxZaA21Iked9h1VNlq3igAH5GsAAAACAX8AAQAA AI0AAAAwMDAwMDAwMDY0MTJEMEY3NEUyRTFENEQ5MjJFOTcyQ0YxQUI3RUIzMDcwMDNDRDE0RTQ1 MTc1MUJENDJCQTQ4QUFBNTBCMDdCQUQ2MDAwMDAwMEIxRTM2MDAwMDhERjAyMUE5OEI3MDgwNDU5 ODBCMjA1NjI2NkU4RTM2MDAwMDBEMDRFNTJBMDAwMAAAAAADAAYQ/kqn3wMABxAzBgAAAwAQEAEA AAADABEQAAAAAB4ACBABAAAAZQAAAC0tLS0tT1JJR0lOQUxNRVNTQUdFLS0tLS1GUk9NOkNIUklT TkVXTUFOTUFJTFRPOkNIUklTTkVXTUFOQFNVTkNPTVNFTlQ6TU9OREFZLEpBTlVBUlkyOSwyMDA3 MTE6MzhQTVQAAAAAbC8= --Apple-Mail-6-760565169 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed -- Mark Nottingham http://www.mnot.net/ --Apple-Mail-6-760565169-- From discuss-bounces@apps.ietf.org Tue Jan 30 19:46:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC3bn-00061O-R3; Tue, 30 Jan 2007 19:45:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC3bm-00061I-Cl for discuss@apps.ietf.org; Tue, 30 Jan 2007 19:45:54 -0500 Received: from nz-out-0506.google.com ([64.233.162.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC3bl-0002Vh-54 for discuss@apps.ietf.org; Tue, 30 Jan 2007 19:45:54 -0500 Received: by nz-out-0506.google.com with SMTP id z3so34634nzf for ; Tue, 30 Jan 2007 16:45:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Ro+Tr85dixAYYR1zzRXbc8ul3KdCS+WZIp+wv6F2UbuRMWoJ+W9nLz3qCKoksxkCn7CoX+F9EzMxgDQw1YMR9WRFOExFVjpHbuu2PAQlsJqNpNTNHXLUUWgir8b9dOfwpLfaDdey/U6W8/MBqUaKvvLyE2IthEKRQS/Pv3tWVY4= Received: by 10.35.17.12 with SMTP id u12mr268766pyi.1170204352142; Tue, 30 Jan 2007 16:45:52 -0800 (PST) Received: by 10.35.71.14 with HTTP; Tue, 30 Jan 2007 16:45:52 -0800 (PST) Message-ID: <517bf110701301645u1a0e5658v3f8beeca2a1136ce@mail.gmail.com> Date: Tue, 30 Jan 2007 16:45:52 -0800 From: "Tim Bray" To: "John C Klensin" Subject: Re: New draft (Was: I-D ACTION:draft-klensin-unicode-escapes-00.txt In-Reply-To: <875A124D75A8B481E176CF06@p3.JCK.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <875A124D75A8B481E176CF06@p3.JCK.COM> X-Google-Sender-Auth: 83c20ebab7132798 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 Pardon me for being late to this party, I was on vacation in Australia. I think this is a positive contribution. First, a detail point: In section 5.4, it's probably relevant that per the Java Language Specification (http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#95413p) it's clear that a Java character literal or variable represents, not a Unicode character, but a UTF-16 code point. I guess the conclusion is that it may be OK in certain circumstances to use \uNNNN, but it's not OK to explain that by calling out to Java. Second: I think that the discussion shows that the syntax problems around representing Unicode characters in ASCII and other Unicode-oblivious texts are tricky; witness the issues with delimiters and ABNF/case. This is further evidence, were any needed, that IETF Working Groups SHOULD NOT specify Internet protocols which may be used to transfer text but are not capable of representing the Unicode character set, either by specifying the use of either hard-wired UTF-8 or alternatively XML, both of which have cracked this nut. So here's a proposed recasting of second para of 1.1: When one moves to Unicode [Unicode] [ISO10646], where characters occupy two or more octets and may be coded in several different forms, the question of escapes becomes even more complicated. In particular, we have seen fairly extensive use of both hexadecimal representations of the UTF-8 encoding [RFC3629] of a character and variations on the U+NNNN[N[N]] notation commonly used in conjunction with the Unicode Standard. New protocols that are required to carry textual content SHOULD be designed in such a way that the full repertoire of Unicode characters may be represented in that text; UTF-8 and XML are both good options. This document proposes that existing protocols being internationalized SHOULD use some contextually-appropriate variation of the U+NNNN[N[N]] notation unless other considerations outweigh those described here. From discuss-bounces@apps.ietf.org Wed Jan 31 05:44:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCCwL-0003gq-VB; Wed, 31 Jan 2007 05:43:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCCwK-0003gi-4a for discuss@apps.ietf.org; Wed, 31 Jan 2007 05:43:44 -0500 Received: from mtagate7.de.ibm.com ([195.212.29.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCCwD-0007gk-Oo for discuss@apps.ietf.org; Wed, 31 Jan 2007 05:43:44 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate7.de.ibm.com (8.13.8/8.13.8) with ESMTP id l0VAhanB145544 for ; Wed, 31 Jan 2007 10:43:36 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0VAhaN61957892 for ; Wed, 31 Jan 2007 11:43:36 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0VAha84001907 for ; Wed, 31 Jan 2007 11:43:36 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0VAhZqs001898; Wed, 31 Jan 2007 11:43:36 +0100 Received: from [9.4.210.81] ([9.4.210.81]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA284542; Wed, 31 Jan 2007 11:43:35 +0100 Message-ID: <45C072D7.7060409@zurich.ibm.com> Date: Wed, 31 Jan 2007 11:43:35 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Mark Nottingham Subject: Re: TLS 1.1/1.2 impact on applications protocols References: <000001c74490$70856c00$241e830a@vcorp.ad.vrsn.com> <811E6993-8834-40A1-BB83-6838D60BE885@mnot.net> In-Reply-To: <811E6993-8834-40A1-BB83-6838D60BE885@mnot.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 2007-01-30 22:50, Mark Nottingham wrote: > The language Scott references ("using the latest version supported by > both parties") seems reasonable, but I think what's being asked for is > for the latest version to automatically become MTI. I can imagine that creating considerable confusion for people using RFCs in procurement requirements and the like. Obviously it's highly desirable from a security PoV, but if we make RFCs refer to variable quantities, we create great complications for the consumers of our work. Brian > > Cheers, > > > On 2007/01/31, at 4:02 AM, Scott Hollenbeck wrote: > >>> -----Original Message----- >>> From: Chris Newman [mailto:Chris.Newman@Sun.COM] >>> Sent: Monday, January 29, 2007 11:38 PM >>> To: Apps Discuss >>> Cc: Pasi Eronen; Eric Rescorla >>> Subject: TLS 1.1/1.2 impact on applications protocols >>> >>> The changes that are happening in the TLS WG with the >>> publication of TLS 1.1 and the upcoming TLS 1.2 do have a >>> significant impact on application deployment. Many of our >>> application protocols make TLS 1.0 mandatory-to-implement. >>> I'd like to see a discussion of the importance of transition >>> to 1.2 (when it comes out) and the real-world problems that >>> might occur. Do we need to update our application protocol >>> specifications to mandate the newer version? Or perhaps we >>> need an app-area RFC which does that to a set of application >>> protocols? >>> >>> Can we just have a blanket exception to the standards status >>> (proposed/draft/full) reference rules for the TLS base spec >>> (and trust the TLS WG to do the right thing)? It seems more >>> important to keep up-to-date on security technology than to >>> have normative reference purity. >>> >>> Perhaps this would be a good topic for the Prague apparea meeting? >> >> I just ran into this very situation in the process of bringing EPP (RFCs >> 3730 - 3734) to Draft. The IESG was OK with a normative downward >> reference >> to TLS 1.0 and some additional text to note that the work is still >> evolving. >> Here's what we agreed to say: >> >> "When layered over TCP, the Transport Layer Security (TLS) Protocol >> version >> 1.0 [RFC2246] or its successors (such as TLS 1.1 [RFC4346]), using the >> latest version supported by both parties, MUST be used to provide >> integrity, >> confidentiality, and mutual strong client-server authentication." >> >> The reference to 2246 is normative; a downref note and exception >> processing >> was required. The reference to 4346 is informative. This approach >> worked >> because EPP does not depend on any version-specific features of TLS. The >> situation may well be different for other protocols. >> >> -Scott- > > > -- > Mark Nottingham http://www.mnot.net/ > From discuss-bounces@apps.ietf.org Wed Jan 31 08:55:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCFvM-0004c6-O7; Wed, 31 Jan 2007 08:54:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCFvL-0004YY-7k for discuss@apps.ietf.org; Wed, 31 Jan 2007 08:54:55 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCFvI-00056x-E1 for discuss@apps.ietf.org; Wed, 31 Jan 2007 08:54:55 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id C79D056429; Wed, 31 Jan 2007 08:54:51 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sd-dAK9IY9nG; Wed, 31 Jan 2007 08:54:43 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id CFCA35640D; Wed, 31 Jan 2007 08:54:39 -0500 (EST) Message-ID: <45C09FAC.7040007@cs.utk.edu> Date: Wed, 31 Jan 2007 08:54:52 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: TLS 1.1/1.2 impact on applications protocols References: <000001c74490$70856c00$241e830a@vcorp.ad.vrsn.com> <811E6993-8834-40A1-BB83-6838D60BE885@mnot.net> <45C072D7.7060409@zurich.ibm.com> In-Reply-To: <45C072D7.7060409@zurich.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Apps Discuss , Mark Nottingham 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 2007-01-30 22:50, Mark Nottingham wrote: >> The language Scott references ("using the latest version supported by >> both parties") seems reasonable, but I think what's being asked for is >> for the latest version to automatically become MTI. > > I can imagine that creating considerable confusion for people using > RFCs in procurement requirements and the like. Obviously it's highly > desirable from a security PoV, but if we make RFCs refer to variable > quantities, we create great complications for the consumers of > our work. on the other hand, we don't really want to re-issue entire RFCs just to allow the incorporation of a new version of TLS, do we? nor do I think it's reasonable to retroactively make a new version of TLS MTI for an existing RFC number. it might be that the easiest way out is to issue some number of "profile" RFCs so that, for instance, RFC XXXX says "the version of FOO that conforms to RFC XXXX consists of an implementation that conforms to the requirements of RFC YYYY except that TLS 1.2 as described in RFC ZZZZ MUST be used rather than another version of TLS." the downside is that we'd be tempted to use these "profile" RFCs as an excuse to list errata, and fixes for those errata, for each of those protocols. this would delay publication and adoption, and perhaps invite long drawn-out processes for second-guessing the original specification like the one we saw in DRUMS. (not that I don't think DRUMS was a good thing to do, but there was a tremendous amount of second-guessing rather than just clarification, and I'm probably as guilty as anyone. I guess it's a slippery slope between the two) more broadly, I actually think that IF we can figure out how to avoid that kind of second-guessing, we should for each of our be periodically issuing a document that describes the applicability, current state of maturity and deployment, and errata and fixes for that specification...and that such documents should to some extent replace our current use of standardization status as a means of recommending or not recommending a particular protocol. that might help us make a transition away from three stages (proposed, draft, full) to one or two. Keith From discuss-bounces@apps.ietf.org Wed Jan 31 12:53:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJdR-0003Uq-M3; Wed, 31 Jan 2007 12:52:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJdQ-0003Ud-F4 for discuss@apps.ietf.org; Wed, 31 Jan 2007 12:52:40 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCJdP-0006Q5-0q for discuss@apps.ietf.org; Wed, 31 Jan 2007 12:52:40 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HCJdO-000IFz-5v; Wed, 31 Jan 2007 12:52:38 -0500 Date: Wed, 31 Jan 2007 12:52:37 -0500 From: John C Klensin To: Tim Bray Subject: Re: New draft (Was: I-D ACTION:draft-klensin-unicode-escapes-00.txt Message-ID: X-Mailer: Mulberry/4.0.7 (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: 3002fc2e661cd7f114cb6bae92fe88f1 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 Tuesday, 30 January, 2007 16:45 -0800 Tim Bray wrote: > Pardon me for being late to this party, I was on vacation in > Australia. I think this is a positive contribution. > > First, a detail point: In section 5.4, it's probably relevant > that > per the Java Language Specification > (http://java.sun.com/docs/books/jls/third_edition/html/lexical > .html#95413p) > it's clear that a Java character literal or variable > represents, not a > Unicode character, but a UTF-16 code point. I guess the > conclusion > is that it may be OK in certain circumstances to use \uNNNN, > but it's > not OK to explain that by calling out to Java. > > Second: I think that the discussion shows that the syntax > problems > around representing Unicode characters in ASCII and other > Unicode-oblivious texts are tricky; witness the issues with > delimiters > and ABNF/case. This is further evidence, were any needed, > that IETF > Working Groups SHOULD NOT specify Internet protocols which may > be used > to transfer text but are not capable of representing the > Unicode > character set, either by specifying the use of either > hard-wired UTF-8 > or alternatively XML, both of which have cracked this nut. > > So here's a proposed recasting of second para of 1.1: > > When one moves to Unicode [Unicode] [ISO10646], where > characters > occupy two or more octets and may be coded in several > different > forms, the question of escapes becomes even more > complicated. In > particular, we have seen fairly extensive use of both > hexadecimal > representations of the UTF-8 encoding [RFC3629] of a > character and > variations on the U+NNNN[N[N]] notation commonly used in > conjunction > with the Unicode Standard. > > New protocols that are required to carry textual content > SHOULD be designed > in such a way that the full repertoire of Unicode characters > may be > represented > in that text; UTF-8 and XML are both good options. > > This document proposes that existing protocols being > internationalized SHOULD > use some contextually-appropriate variation of the > U+NNNN[N[N]] > notation unless > other considerations outweigh those described here. Tim, While I think I agree with you about your second proposed paragraph above ("New protocols..."), I think my instructions with this document is to keep it narrow and to focus on escapes, not on general advice to protocol designers about Unicode or internationalization more broadly. So I don't want to go so far as to make specific (or even specific-sounding) suggestions. This effort, and some others, have convinced me that we are getting closer to the time at which RFC 2277/ BCP 18 needs to be reopened, reviewed, and updated, but this document isn't the right place to do it, at least IMO. But most of your text is better than mine; let me see what I can do. I have adjusted the Java text. thanks, john