Re: [precis] Ambiguity in specification of case mapping in RFC 7613 and draft-ietf-precis-nickname

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

--On Thursday, October 01, 2015 12:15 -0400 Tom Worster
<[e-mail]> wrote:

> Thanks, John, for the most interesting email I got this week:)

:-)   I wish that this work were a lot less interesting, but so
it goes.
 
> It raises a question I would like to ask not only to you. As an
> implementer working through the specs, I got the clear
> impression that, while the PRECIS framework can potentially be
> useful for various things, the four profiles are explicitly
> specified exclusively for the purpose of string comparison
> operations on usernames, passwords and nicknames. If someone
> uses them for some other purpose and thereby causes problems,
> it's not RFC 7613's fault.

I'm in a bit of a difficult position on this because I was never
a big PRECIS fan.  It is probably best for you to assume that
the reasons are very technical (most are) but the main reason
why I didn't spot the paragraph you found and provide that
explanation before or during IETF Last Call is that I simply
gave up (after getting the WG to agree to resolve some problems
I considered much more significant).  So, if you have questions
about intent, Peter, ALexey, or others may be better qualified
to answer them.

> The question is, did I get the wrong impression?
> 
> If not then the discussion of how the profiles should specify
> case map/folding, which is specified only in the profiles, is
> simpler. The points to resolve being, as John put it, the
> "false positives".

Yes and no.  Maybe it is useful to think about it this way.  If
I'm a user, I want the systems and interfaces to be as intuitive
as possible relative to whatever I already know or think I do.
If I'm looking at text written in a particular language, I
expect the identifiers embedded in that text to obey that
language's rules (or what I think they are).  That argues for a
highly localized environment in which, e.g.,
French-as-used-in-France and France-as-used-in-Quebec have
different case matching rules and Arabic-language use of Arabic
script is a lot different from Persian-language use of Arabic
script even before one gets to "two sets of digits" or an
interesting discussion known to some specialists as "a digit is
a digit".

On the other hand, if I'm a system or library designer who
really wants to develop a single library, based around a single
profile and/or easily-switched tables, I really want a single
worldwide approach because trying to work things out separately
for every language, script, and location is almost impossible to
think about (and trying probably leads to madness)

Each of those groups is justified in believing that the other
group is living in an alternate, and profoundly unrealistic,
reality.  For some purposes, we can have a common code base and
allow considerable user choice, but if you and I could make
different choices about whether two valid strings match as
identifiers, we (and everyone else) are in big trouble.  In
IDNA2008, we tried (and failed, btw) to simply disallow all of
the characters that led to difficult edge cases.  PRECIS made a
different, profile-based, set of decisions that, on the one
hand, allow doing things that may be more intuitive for users
and that, on the other, may lead to surprises or contradictions.

For basic Latin script, the case-matching problem was solved
with Multics circa 40 years ago, albeit brutally (a solution
carried into Unix): if something doesn't match at the bitstring
level, it doesn't match and people just need to get used to it.
That causes obvious problems with expectations and assumptions,
but is at least 100% ambiguous.   As soon as one starts marching
down the path of case-independence for non-ASCII and then
non-Latin characters, it gets hard to explain to users -- users
whom we've managed to convince that computers are smart and
adaptable -- why "Color" and "color" should match but "colour"
(or even "couleur" or "Farbe") don't match and are different.

> Fwiw, the (immature and inadequately tested) implementation is
> open at https://github.com/tom--/precis

Good luck.
    john