Re: [nfsv4] one more try at RFC3530 internationalization.

[Nico Williams <[e-mail]>]

On Wed, Aug 7, 2013 at 2:40 PM, Noveck, David <[e-mail]> wrote:
> I've been working with Tom Haynes and David Black to come with an
> approach to internationalization for RFC3530bis, that meets the IESG's
> objections and has a good chance of being approved.
>
> The approach to be taken is basically to get an internationalization
> description that matches what people have implemented.  I think it is
> pretty clear that does not match the stringprep-based approach taken in
> RFC3530, although we may have some issues proving that fact to the IESG,
> or more properly, giving Martin the information he needs to prove it to
> the IESG.

Back then the IETF didn't have all that much experience with I18N.
Even recently the PRECIS WG was nearly making serious mistakes.  I
think our experience qualifies as experience to learn from.  I think
the IESG will surely understand.

> The internationalization approach in the curent RF3530bis draft,
> draft-ietf-nfsv4-rfc3530bis-26 attempted to make the stringprep stuff
> non-normtive nd loosen it nough tht current implentations fit withiin
> it.  unfortunately, the IESG ididn't like it, so we need something else.

We know from our experience with ZFS and NFS on top what is reasonable
and what is not w.r.t. filesystem object names:

 - it is reasonable to reject non-UTF-8

 - it is reasonable to do normalization- and/or case-insensitivity --
i.e., do any normalization and mapping on lookup (or on hashing at
create time) but always return the original name on READDIR, with a
security considerations note about aliasing

 - it is probably reasonable to not normalize for anything

 - normalize-on-create, mappings of any kind (e.g., case) are a
sometimes-desirable, sometimes-not feature, and in particular on most
Unix systems (not including OS X w/ HFS+) normalization-on-create and
any mappings on create lead to problems, therefore:

 - it is reasonable to not do *any* mappings or normalization on
create -- this has to be a choice made with application compatibility
in mind

 - all of this on a per-filesystem basis (or even per-directory), NOT
on a per-fileserver basis

>From experience in the SASL/PRECIS world we know that for *user* and
group names it's best to apply any and all normalization and mappings
on the server side.  The client need not do anything, though
normalizing doesn't hurt (but mappings, on the client side, *do*
hurt).

Actually, that applies to filesystem objects as well: the client
should do no mappings.

We really need to distinguish:

 - query strings (strings sent by the client to the server)

 - storage strings (what the filesystem/server stores)

 - display strings (what the user sees)

The preparation for query strings should be minimal; the identity
function will do, though the client MUST (but won't) convert between
non-UTF-8 and UTF-8, because a) the server SHOULD reject non-UTF-8,
and b) codeset aliasing sucks.

The preparation for storage strings is and should be
filesystem-specific.  For example, HFS+ normalizes on create to NFD
and is case-insensitive on lookup (IIRC).  Nothing an RFC says can
change that -- we must not even try.  What we can do is hope to get
codeset conversions right by dictating the use of UTF-8 on the wire:
then clients and servers can convert to/from whatever they use
locally.  For example, on Solaris 11 FAT and other such filesystems
can convert automatically to UTF-16 and/or to various code pages.

In practice clients cannot really do codeset conversions because the
only place that such conversions can be done in Unix-like OSes is in
the C run-time's system call stubs (the kernel doesn't know about
user-land locales, and above the system call stubs is the app, which
shouldn't have to do these conversions).  To my knowledge no C library
does that.  This can be addressed by running only in UTF-8 locales,
but that's not 100% satisfactory, just 95%.  Client implementors that
care enough will go and fix their user-land C run-times, though I
doubt any will.

> The proposed approach is to base the new RFC3530bis handling of
> internationalization on the internationlization tretament in
> draft-ietf-nfsv4-rfc3010bis-04, the last draft for rfc3530 before
> it was stringprep-ized.  I feel that this is simple enough that we
> can clearly make the case, with the implementer's help, that this
> is what current servers and clients do and getting RFC3530bis approved.

I've not read that.  Please see my proposal above.

Nico
--