Re: [I18ndir] draft-bray-unichars-01

[John C Klensin <[e-mail]>]

Tim,

I'm not sure who is paying attention to this list either.  I
normally would not, but seeing traffic on it, your name, and the
recommendation from Francesca (copied) was enough to get me to
read it and respond.

Inline below. 

--On Tuesday, August 29, 2023 11:37 -0500 Tim Bray
<[e-mail]> wrote:

> Hello I18ndir (anyone still here?), Paul Hoffman and I just
> submitted draft-bray-unichars-01 - our AD Francesca Palombini
> suggested we notify this list:
> https://datatracker.ietf.org/doc/draft-bray-unichars/
> 
> This draft fell out of a conversation originally provoked by
> this errata report: https://www.rfc-editor.org/errata/eid7603
> 
> It revealed a distressing lack of consensus about Unicode
> characters and code points and character repertoires. I feel
> personally bad because I am the editor of a couple of RFCs
> that are open to criticism on this front.

I would have described it as a distressing (I've used stronger
words) lack of knowledge on those and other points.  The problem
is not, IMO, a lack of consensus among those well-informed
enough to either agree or to thoroughly understand the issues
and why we are disagreeing.  The problem, at least IMO, is that
i18n work, including the Unicode-specific issues you mention
above, lies somewhat at the periphery of the IETF's work and
core expertise, with many people wanting to (or feeling a need
to) move beyond ASCII but not wanting to make the investment to
understand the issues... instead either just wanting to be told
what to do, preferably in a few very short sentences, or
resisting any input that would make their core work more
complex.  Things are further complicated by people who write
and/or speak one language other than English and conclude that
what they have learned from comparing the two makes them i18n
experts.  In theory, the ART Area review team (which took over
the reviewing process when i18ndir ran out of energy for the
rest of what Patrik, myself, and a few others hoped for from the
directorate) should catch and resolve most of the issues, but
there is a knowledge problem (and occasionally a few other
problems) there as well and IETF Last Call (and sometimes even
"early" reviews) tend to come late enough in the process to make
authors and WGs who thought they were finished to react with
some horror to suggested changes or force-fed clue
administration.  Or we might try to expect the RPC to sort
things out but that is _really_ late and, as evidenced by the
recent discussions of draft-hoffman-rfc7997bis on the RSWG list,
there are questions about expertise, consistency among
documents, and what sort of guidance (or education) should be
given to them there too.

> So, this tries to say "here's how an RFC should specify
> which Unicode characters it supports".  We think this would
> be useful to multiple groups almost immediately, including
> especially those who don't realize the area can be
> problematic.

If they are willing to read it and pay attention.  FWIW, when I
wrote what became RFC 5137/ BCP 137 fifteen-odd years ago --a
document that both this draft and Paul's rfc7997bis one
reference-- the intention was almost exactly the same: to
educate about the issues and suggest what should be done.  I
believe that the need for these new I-Ds now are indicative that
I/we failed.  That may have been because 5137 was (deliberately)
not explicitly normative enough about one particular mechanism
(something this draft avoids as well) but I suspect that it was
also because too few people were willing to dig in even that far.

> Anyhow, the purpose of this note is to ask your advice on how
> to take this forward. We think this works well as an
> individual submission.   We don't *think* it needs a working
> group, but that's not our call. The draft doesn't express
> any opinions about best practices, it just points out several
> alternative character repertoires, provides ABNF, and discusses
> their trade-offs.  None of them are wrong.

Two suggestions, neither of which is an answer to your question
but that might help inform it:

(1) This I-D and draft-hoffman-rfc7997bis-03 (or its RSWG
successor) seem to overlap somewhat.  I suggest that you and
your co-author sit down and figure out what the relationship
should be, alter one document or the other (or both) as
appropriate, and, unless you are going to drop one or the other,
provide a clear explanation of the relationship somewhere. I
would prefer that be in both I-Ds even if the text is marked
"remove before RFC publication", but you might have better ideas.

(2) Stop dancing around the "no opinions about best practices"
and "none of them are wrong" issues.  Something does not need to
be wrong for us to recognize and settle on something else.  This
is just a situation were consistency across I-Ds and RFCs is
good and anything else is a source of confusion.  Fifteen years
after RFC 5137, we ought to be able to say, at least, "this is
what you SHOULD do and and, if there is a reason to do something
else, you MUST PROVIDE a clear explanation of the choice to the
community (and to be absolutely consistent about it within the
document).   While our reasoning and/or the way we would
describe the history may differ a bit, I think that is
essentially the same point that Carsten made recently [1].   If
we can't get community rough consensus about a single preferred
form with anything else treated as an exception that requires
explicit justification and explanation, we have problems that
this document won't solve or, IMO, even make better.

I'll be in a better position to makes suggestions about what
should be done about this document when I see a revision (or
revisions to both it and the rfc7997bis document) along the
lines of the above.  Francesca probably will be too.

And, Francesca, welcome back.  My plan had been to give you a
few weeks to settle in before dropping the i18n mess into your
lap again.  So much for good intentions.

best,
  john



[1]
https://mailarchive.ietf.org/arch/msg/art/q37e8UuvGXpw1VR9hIcw5syFhCA