Re: Possible BofF question -- I18n (was: Re: Possible OBF question -- I18n)

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

Hi.

First a status report.  

Rather than wait until the last minute, I went ahead and pasted
a template description into the BOF wiki page.  The entry there
is a slightly shortened and rewritten version of my initial note
in this thread.
https://trac.tools.ietf.org/bof/trac/wiki/WikiStart

I've listed Patrik (without asking him) and myself as
"proponents" for this, but would be happy to add names (or have
others do so).   Spencer, I assumed it would be not be
appropriate to add you there, but you'd certainly be welcome if
I got that wrong.

Because I had to choose and because most of the i18n-specific
WGs have been in Apps/ART, I've put it into that area, but I
believe that IESG needs to figure out how to handle this.  I
could make a case for General (on the theory that many areas are
covered or that procedural changes might be needed) or for
Security (because the most recent major i18n interactions that I
know about have been with a WG there), but, again, the IESG
should decide.

   --------

Now a few comments on recent postings (after I went to work on
the template).  

* I think it would be a just dandy idea to require an "I18N
Considerations" section in every I-D or RFC.  I see only two
problems with it.  One is that we've had such a requirement for
documents that do have i18n issues for 20+ years and it hasn't
helped.  We've also had suggestions for including a statement
about i18n issues in Shepherd templates.   If the IESG were to
decide to enforce that requirement by changing the I-D checker
and refusing to consider any document that doesn't have at least
a clear "no issues" statement, we might make some progress, but
no one has yet convinced them it would be appropriate (that has
been tried several times, but mostly in individual or
directorate discussions).  The other is that, while I rather
like the idea of some sort of formal process or review by
experts, we explored that some years ago too.  It requires
committed experts and the difficulty in finding those is part of
the problem, not an obvious solution.   Speaking as a likely
stuckee, if the idea doesn't have a clear structure and a
commitment from the IESG and the community will be taken
seriously rather than as miscellaneous review input (i.e., more
like MIB Doctors input in their area of expertise rather than
notes from whomever drew the short straw, regardless of
expertise, on the Foo Area Review Team), staffing that effort
and keeping it staffed is likely a non-starter.   So, even if we
are agreed that a required  I-D/ RFC section would solve the
problem, we would still benefit from this BOF to start shorting
out those details.

* Neils, having spend months, probably years, of my life trying
to explain to assorted well-intentioned people in social
justice, human rights, and getting more people on the Internet
in a way that is fair and appropriate to their cultures spaces
why these are hard problems and that superficial solutions make
things worse, no, making this a human rights issue wouldn't
help.  I'm sorry to single out the documents to which you
pointed for special consideration, but RFC 8280 is an example of
a document that should have gotten serious i18n review and
apparently didn't.  The second question in Section 6.2.5 should
have set off alarms because character coding is only a tiny part
of the issues and not even the most important part.   Yes,
support for multiple "charsets" is a bad idea, but, because the
mappings from other CCSs and back are usually (but not always)
completely deterministic and reversible, a far less serious one
than a long series of other issues.  For a web-oriented
illustration of another set of important problems, I suggest
that you have a look at
https://w3c.github.io/typography/gap-analysis/language-matrix.html
.  I'm also very concerned that the last paragraph of that
section seems to argue for relaxing the "protocol identifier"
constrain while showing no evidence of understanding it beyond
what might be described as "multlingualism good".   If the Human
Rights Review Team were to start complaining about the absence
of Internationalization Consideration sections, I think that
would be positive, but the expertise needed to adequate consider
Human Rights issues and that needed to consider i18n ones is
very different and RFC 8280 may actually be proof of that.

* Crypto expert mindsets -- I agree with John Levine on this.
FWIW, a few of us have made the observation that this i18n area
is easy to learn about for one class of people.  Not impossible
for others, but seemingly hard to grasp.   That class of people
consists of those who had strong exposure to at least three
languages, using at least two scripts (ideally ones that are not
closely related, i.e., Greek, Latin, and Cyrillic may only count
as one... or not), before the age of about seven (connected to
the Chomsky hypothesis about roughly the point that most people
can no longer acquire languages and language intuition as a
child).  As Peter points out, "competence" is easier, but one
still has to get fairly deep into the characteristics of several
unrelated (at least in the last three or four thousand years or
so) writing systems to reach that point.  And even that ignores
issues with spoken language, which much of the linguistics
community would claim is the only thing that is important.

* Mentions of UTR#46 in general I18N contexts may be close to
mentioning Hitler under Godwin's Law.  It is strictly about IDNs
and not the general problem; its current version makes
assumptions equivalent to domain names not needing to be treated
as having important properties of identifiers; etc.  As I said,
I don't think this BOF effort is about particular protocol
issues.  However, as a non-protocol issue (and maybe the point
John Levine was trying to make) due in no small measure to
UTR#46 and the homebrew updates to IDNA2003 it has encouraged,
we have a large number (perhaps dozens) of interpretations about
what IDNA is "really" about and what the requirements "really"
are.   That is an operational and user predictability problem, a
security problem, etc.    

"No urgency"?  Only if one wants to see the IDN situation
deteriorate to the point that systems that are concerned about
privacy, malware, etc., will simply filter out all of them as a
good tradeoff against the risks.

And, again, I see IDNs as one issue here among many, not the
only or even the key issue.

   john