Re: draft-klensin-net-utf8-06

"Frank Ellermann" <nobody@xyzzy.claranet.de> Tue, 16 October 2007 06:51 UTC

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhgGo-0001RL-4t; Tue, 16 Oct 2007 02:51:14 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IhgGl-0001Oa-FT for discuss-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 02:51:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhgGV-0001B3-Ap for discuss@apps.ietf.org; Tue, 16 Oct 2007 02:50:55 -0400
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhgGO-0006kD-VT for discuss@apps.ietf.org; Tue, 16 Oct 2007 02:50:55 -0400
Received: from root by ciao.gmane.org with local (Exim 4.43) id 1IhgFe-0008K2-9F for discuss@apps.ietf.org; Tue, 16 Oct 2007 06:50:02 +0000
Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <discuss@apps.ietf.org>; Tue, 16 Oct 2007 06:50:02 +0000
Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <discuss@apps.ietf.org>; Tue, 16 Oct 2007 06:50:02 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: discuss@apps.ietf.org
From: "Frank Ellermann" <nobody@xyzzy.claranet.de>
Subject: Re: draft-klensin-net-utf8-06
Date: Tue, 16 Oct 2007 08:45:39 +0200
Lines: 47
Message-ID: <ff1mrb$ufr$1@ger.gmane.org>
References: <93F25E18AB3DA3EB0599F092@p3.JCK.COM> <fev7so$bt0$1@ger.gmane.org> <090481616F66605395036545@p3.JCK.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <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

John C Klensin wrote:

> when we start going into detail on how individual code points or
> blocks are interpreted, we are getting into territory that is very
> uncomfortable for me and, I believe, should be uncomfortable for
> the IETF.

Yes, I'm not proposing to make the TUS "newline guidelines" worse,
they are already bad enough.  But it's easy (at least for me) to
forget the odd LS case, but "users" of the net-utf8 RFC have to be
aware that LS exists (in addition to the controls already covered
in your I-D).
 
Most "users" of net-utf8 will be protocol designers, they need to
know some relevant TUS dragons like LS, NFC, annotations, language
tags, etc.  [[And when EAI moves to standard track in some years
we have to do something about LS in display names and addresses,
before it hits say mailto-ter IRIs]].

 [various kinds of unassigned code points] 
> The set of issues involved here is the reason that the "Stable
> NF..." discussions started in the wake of some of the
> pre-RFC4690 discussions a year or more ago.  I think we should
> continue to try very hard to avoid having it turn into an IETF
> problem.

+1  It might still make sense if the next TUS version identifies
such "unnormal unassigned gaps", it could simplify the IDNAbis
work (just an example).

> And, when they make a mistake of sufficient importance, they 
> reserve the right to change things.

In some areas.  Elsewhere they can't fix an obvious typo in a
character name s/KC/CK/, and had to invent a "normative alias"
mechanism to mitigate it.

> I'd be happy to hear from others about this if people think
> it is important enough to delay a last call still longer.

Let's start with the BCP on unicode-escapes, they don't depend
on the net-utf8 PS.  If you don't care about LS at the moment
you could also decree that it's a potential issue for a later
DS, but I think adding some "there be dragons" note about LS
to net-utf8 now could be simple.  Certainly no showstopper.

 Frank