Re: [I18nrp] next steps

[Nico Williams <[e-mail]>]

On Mon, Jul 23, 2018 at 08:05:41PM -0700, Larry Masinter wrote:
> Is it time to talk about specific drafts?
> 
> This seems more general:
> 
> There is a problem in RFC 6365 “Terminology used…” that I think is at
> the core: It seems to imply that the way to compute equivalence of
> strings REQUIRES normalization to allow determining a~b iff
> normalize(a)==normalize(b).  But in general, the equivalence relations
> one might want, for usability reasons, don’t have an acceptable normal
> form.
> 
> Continuing to put in normalization as an essential step is doomed to
> failure. Some protocols may need to be redefined to allow
> non-normalized strings. 

Well, somewhere the equivalence check has to be done, else you have
problems.  But you're absolutely right that always normalizing isn't
always the right answer.

For protocols like remote filesystem protocols, the best thing to do is
to implement form-insensitive / form-preserving semantics in the
filesystem (but not the server component).

For security protocols where relying parties need never re-encode to
verify signatures, then form-insensitivity can work.  In many cases it's
easy and convenient enough to make issuers/authorities normalize anyways
-- so might as well do that.

For something like DNS, normalization really is necessary, and has to be
done on the client-side.  (Though with on-the-fly signing one could also
just put ToUnicode() and ToASCII() functionality on the server, but I
don't think this is needed, nor desirable, nor desired.)

I speculate that in most cases in Internet protocols where Unicode
strings are carried, the best behavior is form-insensitive /
form-preserving, with a few exceptions where either an authority
normalizes, or the clients do.

In particular, it was a mistake to require normalization for NFSv4.

Quite often NFSv4 clients (Unix and Unix-like clients) have no idea
whether the application is even providing Unicode strings (because the
locale information is not visible to the NFS client).

NFSv4 servers are almost never very tightly integrated with the
filesystem -- typically there is a pluggable filesystem layer.  And with
other access methods to content with (local POSIX API access, other
protocols), the servers are just not in a position to authoritatively
perform normalization -- this alone argues for putting all normalization
burdens on the filesystem, not the server component, not the clients.
And the realities of actual use and implementation prevent us from
effectively dictating a normal form: HFS+ normalizes to ~ NFD; input
methods generally produce pre-composed sequences.

Only f-i/f-p can work for NFSv4.

I have been pushing form-insensitive / form-preserving behavior for well
over a decade now.  It's been lonely.  Are you joining me? :)

Nico
--