Re: New draft (Was: I-D ACTION:draft-klensin-unicode-escapes-00.txt

John C Klensin <john-ietf@jck.com> Tue, 30 January 2007 00:53 UTC

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 <john-ietf@jck.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Subject: Re: New draft (Was: I-D ACTION:draft-klensin-unicode-escapes-00.txt
Message-ID: <EF59DA6FD89C4F19750C68C3@p3.JCK.COM>
In-Reply-To: <uppsr2hs59srbd7eufbcul5a1ekl7i09nl@hive.bjoern.hoehrmann.de>
References: <875A124D75A8B481E176CF06@p3.JCK.COM> <uppsr2hs59srbd7eufbcul5a1ekl7i09nl@hive.bjoern.hoehrmann.de>
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 <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org


--On Monday, 29 January, 2007 22:32 +0100 Bjoern Hoehrmann
<derhoermi@gmx.net> 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 <obscenity>, 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 <p>Bj&#xf6rn</p> 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