Re: draft-klensin-unicode-escapes-01

[Frank Ellermann <[e-mail]>]

John C Klensin wrote:

> Sorry, but, IMO, for a document like this which is merely giving
> examples (at this point), "very widely deployed and used" trumps
> "horrible".

When I mentioned hex. NCRs I meant XML, not SGML and its many ways
to save keystrokes.

>> Probably the I-D should mention that one famous exception from
>> its rule to avoid encoded UTF-8 is the URL form of IRIs.

> Why?  I don't see that (and a few other cases) as "exceptions"
> (famous or not), but as mistakes from which we should learn and,
> I hope, have learned.

The overall RFC 2277 rule is IMO "if you don't know what it is or
can't say what it is, it's UTF-8, and if that theory fails it's
UNKNOWN-8BIT".  And unlike RFC 2231 an URL can't say what it is.

>> wouldn't it be better to say "21 bits - rather than the 7 bits
>> of ASCII -"?

> No, because of net-ascii and some other issues, probably not.
> Again, because the important issue here is that this stuff is
> about escapes, you are picking nits that belong elsewhere

That nit is closely related to escape mechanisms providing for
31 or 32 bits, and attempts to get rid of leading zeros in these
mechanisms, which could fail without explicit delimiters.

> U+NNNN[N[N]] versus U+[[N]N]NNNN is a matter of taste.

If the idea is to reflect appendix A of Unicode 5, it talks about
stripping leading zeros until four digits are left.  In table A.1
it has U+HHHH vs. U-HHHHHHHHH, saying that this is the same as
\uHHHH vs. \UHHHHHHHH.  I haven't seen U-HHHHHHHH before, and I
won't miss it if you don't want to talk about it in the draft.

> my editorial judgment and preferences are going to prevail...
> at least until the document gets far enough along that I have
> to start arm-wrestling with the RFC Editor and _their_ judgment
> and preferences.

Oops, sorry, I thought the intended status was BCP, "an attempt
to prohibit escapes for UTF-8 entirely".

> If you don't like my writing style -- and many people don't --
> please take on these efforts yourselves and let me complain
> about your style (or not) some of the time.

I like it, your drafts are almost always very interesting.  I was
really surprised when I stumbled over RFC 2345 some day ago, it
supports UTF-8 for whois.  So that wasn't a DeNIC invention after
all, and it's clearly older than RFC 3912 chapter 4.

But "interesting" sometimes includes "controversial", and then the
intended status is relevant.  As you say it makes no sense to nit-
pick your personal preferences.

> nit-picking is easy and may be fun, but it tends to block,
> rather than contribute to, progress.

I don't read 99% of all drafts, and I don't try to contribute to
99.9%.  The remaining 0.1% somehow attracted my attention, often
because I like them, the opposite is also possible.  No idea how
easy it generally is, but this article alone took me about three
hours, because I tried to find out what "net ascii" really is, why
your "net utf-8" mentions an RFC that's not more available, where
the Unicode 5 notational conventions are, etc.

> unless your purpose is to introduce delays and lay down obstacles

Escaping that with <rant> and adding a qualifier doesn't make it
better.  If you don't want a discussion about the draft it's okay,
as you say we're free to submit our own drafts about this and / or
related topics.

Frank