Re: Possible BofF question -- I18n

[[e-mail]]

Viktor is spot-on here. A few addtitional comments...

> > On Jun 5, 2018, at 1:50 AM, Barry Leiba <[e-mail]> wrote:
> >
> >> To see why consider comparing my first name as I usually write it
> >> (Nicolas) vs.  how it should be written (Nicolás).  The two strings
> >> should compare as not equivalent.  But the two ways to write the second
> >> form (with the &acute; precomposed vs. decomposed) should compare as
> >> equivalent (because they are).

> The above is a simple statement about *equivalence*

> > - does that mean that it's OK to have "nicolas" and "nicolás" as two
> > different usernames assigned to two different users?

> They are not equivalent, whether assigning both is a good idea
> is an entirely separate question.

And one which is highly context dependent. The most the IETF could possibly
do in this space is document some of the tradeoffs. And I question whether
it's in the IETF's job description to undertake such work.

> > - what about handling of "ä" vs "ae"?

> They are not equivalent. This is confusability question,
> not an equivalence question.

> >  Do we want to avoid assigning
> > "käse" and "kaese" as distinct usernames?

> Ditto.

> > These are only some of the reasons it's difficult.  And the number of
> > people who stand up and say, "oh, just <do this> and the problem is
> > solved," demonstrates that too too too many people *think* they
> > understand... and don't.

> Or do, but the participants are talking past each other...

More likely people are hearing what they want to - or have conditioned
themselves to - hear. A lot of times what people are actually saying is, "We
have no choice but to solve this problem, none of the solutions are ideal
because <reasons>, but I think the best we can do is to <do this>."

Somehow the first part of that is lost, leaving just the <do this> part, and
then the accusations of failing to understand - and worse - start flying.

This has been going on since I began participating in the IETF 29 years ago;
and frankly it got tiresome after the first month.

But there are three key differences between then and now.

The first is that back there was critical work to do: Internet email was
limited to ASCII text, charsets were a balkanized disaster, etc. Solving these
problems was difficult both technically and politically, but it was clear that
the benefits far outweighed the costs.

Fast forward to today, and most of those problems are solved: MIME/EAI/IDN,
Unicode/UTF-8, etc. The benefits of working on the remaining issues are far
smaller, and as for the costs ... a previous email in this thread actually had
the unbridled temerity to haul out the old "Americans think ASCII is
sufficient" line. The memories this calls forth are not good.

The second difference is that we now have decades of experience with how these
efforts actually go to look back on. And to be blunt, the track record of the
"experts" isn't exactly stellar.  For example, 25 years ago the expert
consensus was that any solution to the charset problem had to retain all of the
balkanization - and the specific proposal was to use a profile of ISO 2022 for
inline charset selection. As for Unicode, it was regarded as a hot mess
unworthy of any real consideration.

Back in 1992, Nathaniel Borenstein and I wrote in RFC 1341 that:

            It is our hope  that  ISO  10646  or  some  other
            effort  will  eventually define a single world character set
            which can then be specified for use in Internet mail, but in
            the  advance of that definition we cannot specify the use of
            ISO  10646,  Unicode,  or  any  other  character  set  whose
            definition is, as of this writing, incomplete.

This hardly seems like a contentious statement now, but it definitely was at
the time.

Of course anyone can be wrong. But there have been some real whoppers along the
way, and this along with the absolute certainty that accompanied them makes
trust somewhat difficult.

> Natural language issues are messy, and necessitate trade-offs,
> which trade-offs to make can be the subject of much debate.

Debating trade-offs is fine, even laudable. But a significant number of these
discussions aren't debates, they start out as or devolve into little more than
a series of personal attacks.

And this brings me to the third difference. Back in 1990 my tolerance for
condescension in general and ad-homs in particular was pretty high. (Although
not infinite, as some participants no doubt recall.) These days, not so much,
in  part because I've gotten old and cranky, but also because of changes in our
broader societal discourse. (Enough said on this last point.)

As a result of these differences I'm, shall we say, considerably more selective
in regards to participation. And I strongly doubt I'm alone in this.

> For example, in EAI, I find the decision to introduce non-identity
> content-transfer-encodings of composite MIME parts to be far more
> problematic than the problem it is intended to solve.  I wasn't
> around for the discussion, and probably would not have been able
> to change the outcome, but one way or the other someone would have
> had to walk away unhappy...

For me, EAI's end-to-end requirement is the far and away its most problematic
aspect, and one which in practice looks like it's going to  be ignored,
leading to egregiously incompliant implementations and all that implies.

Even so, I take your point. And I wonder to what extent support for
message/global is actually going to happen, although if just-send-UTF-8 comes
to rule the day you can just treat it as message/rfc822 and be done with it.

> (an alternative would introduce
> punycode encoding of localparts and break the sacrosanct rules about
> local parts being only understood at the destination, pick which
> axioms to violate, ... at least one).

First, having now done a full EAI implementation and seen how it interoperates,
it's quite clear to me that this is the approach we should have taken. (And
I say this as someone with their name on one of the core EAI documents.)

Second, I hope you realize that the local part interpretation rule is 
BS now and always has been. The problem is agents outside a given
ADMD at least have to be able to compare addresses for equality. (Mailing
lists managers are the obvious example of such an agent, but there are
countless others.)

And since most of these agents have elected to ignore ASCII case, anyone
who tried to take advantage of the supposed ability to have case-sensitive
local parts ends up in a world of hurt eventually.

This is going to be even more fun with EAI. Normalization of some sort is
pretty clearly needed, rule or no rule. And given the lack of specific advice
in the current standards, its not beyond possibility that case insensitivity
will again rule the day.

And yes, this is one of those "somethings" we should be discussing.

				Ned