Re: draft-klensin-net-utf8-06

["Frank Ellermann" <[e-mail]>]

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