Subject: [I18ndir] NFS i18n

From: "Pete Resnick" <[email-masked]>
Date: Thu, 21 May 2020 12:57:33 -0500

We've been asked to do an early review the NFS i18n document 
(draft-dnoveck-nfsv4-internationalization; about 23 pages). Does anybody 
want to be the official reviewer, or shall I randomly pick the next 
person on the list?

(As always, the assumption for this kind of document is that you would 
write up a review and then post the review here before you send it out 
to the authors to see if anyone spots any other issues.)

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

---

From: "Marc Blanchet" <[email-masked]>
Date: Thu, 21 May 2020 14:22:32 -0400

On 21 May 2020, at 13:57, Pete Resnick wrote:

> (draft-dnoveck-nfsv4-internationalization; about 23 pages). Does 
> anybody want to be the official reviewer, or shall I randomly pick the 
> next person on the list?

I’m no volunteering, but I would expect that they would have a Precis 
(RFC8264) profile or if not, why they are not using one. A quick 
browsing does not seem to tell that.

Marc.

> I18ndir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i18ndir

---

From: "John Levine" <[email-masked]>
Date: 21 May 2020 21:26:38 -0000

In article <[email-masked]>,
>browsing does not seem to tell that.

You need to read the i18n parts of RFC7530 (NFSv4) and RFC5661
(NFSv4.1 and 4.2) and the comments on them in the draft. They created
a stringprep profile for NFSv4.1 a decade ago which nobody ever
implemented.

My quick scan says that NFS character sets are a historical mess but
they seem to be making the best of it and trying to end up at UTF-8
with some reasonable normalization. They specifically note that
normalization and case mapping is language specific with the Turkish
"i" as an example so it is locale dependent. Most of this draft is
unchanged from Sec 12 of RFC 7530 with the biggest change I can see a
switch from IDNA2003 to IDNA2008 for things like server names which
are domain names. Filenames are not domain names so IDNA doesn't
apply.

One thing I would suggest is an appendix at the end summarizing the changes
from RFC7530.  They're mentioned in the text but it'd be nice to have them
in one place for NFS implementors who have already slogged through the
300 and 600 page documents this updates.

R's,
John
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Nico Williams <[email-masked]>
Date: Thu, 21 May 2020 17:48:59 -0500

On Thu, May 21, 2020 at 09:26:38PM -0000, John Levine wrote:
> >I???m no volunteering, but I would expect that they would have a Precis 

[The following is all about I18N as to file names, not domainnames.]

NFSv4 servers can't realistically support varying locales by client, I
don't think.  Among other things, client-side NFSv4 kernels, therefore
in-kernel NFSv4 clients, are usually unaware of user processes' locales
(certainly in Unix and Unix-like systems).

Moreover, on classic Unix and Unix-like systems, the NFSv4 server can't
really implement I18N for file names either!  That has to be done by the
filesystem, or else by the NFSv4 server *and all other* filesystem
access methods, such as SMB/CIFS, AFS, WebDAV, POSIX system calls, WIN32
system calls, etc.

Due to the pluggable VFS (virtual filesystem) design of many systems on
top of which one might build an NFSv4 server, normative I18N language in
the NFSv4 RFCs ends up either having to be implemented either in the
filesystems and not the NFSv4 server, or it has to be implemented in all
access methods including the NFSv4 server (see above list), or not at
all.

Note in particular that POSIX system call access methods as implemented
in most systems (all? I think so) simply do not know anything about the
locale of user processes calling those system calls, not even about the
codeset of the file name and path strings given to those system calls!

Co-existence of POSIX access methods and NFSv4 servers almost of
necessity drives I18N requirements into the filesystem, well below the
NFSv4 server.

Thus it is my opinion is that NFSv4 shouldn't have that much to say
normatively about I18N for file names!  Instead we should have an RFC
laying out requirements and recommendations for filesystems used via
Internet remote/distributed filesystem protocols.

> One thing I would suggest is an appendix at the end summarizing the
> changes from RFC7530.  They're mentioned in the text but it'd be nice
> to have them in one place for NFS implementors who have already
> slogged through the 300 and 600 page documents this updates.

+1

Nico
--

---

From: "John R Levine" <[email-masked]>
Date: 21 May 2020 21:34:41 -0400

>> with some reasonable normalization. ...

> NFSv4 servers can't realistically support varying locales by client, ...

I agree, but a NFS server in Turkey will want to use Turkish case mapping, 
not some generic UTS46 one-size-fits-badly mapping.  That's the point, 
they don't prescribe a single mapping.

> normatively about I18N for file names!

It doesn't.  How about reading the draft, and comparing it to the part of 
the NFS RFC it updates, and reviewing it for us?

R's,
John

PS:

> Instead we should have an RFC laying out requirements and 
> recommendations for filesystems used via Internet remote/distributed 
> filesystem protocols.

That strikes me as something the IETF is very poorly qualified to do, and 
that nobody would pay attention to since it would be about 40 years too 
late.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: John C Klensin <[email-masked]>
Date: Thu, 21 May 2020 22:07:10 -0400

(written before John Levine's and Nico's comments)

--On Thursday, May 21, 2020 14:22 -0400 Marc Blanchet
<[email-masked]> wrote:

>> (draft-dnoveck-nfsv4-internationalization; about 23 pages).
>> Does  anybody want to be the official reviewer, or shall I
>> randomly pick the  next person on the list?
> 
> I'm no volunteering, but I would expect that they would have
> a Precis (RFC8264) profile or if not, why they are not using
> one. A quick browsing does not seem to tell that.

I have glanced at the document -- not read it, just done a bit
of spot-checking and, motivated by that checking, taken a glance
at 7530. 

Quick observations below. You are welcome to use this as a
mini-review at this point because I don't see how we can do a
meaningful review until these issues are resolved:

(1) RFC 7530 describes domain name-like operations in terms of
IDNA2008  rather badly botches its description of IDNA2008.
However, that is rather thoroughly botched, e.g., specifying
some actions that are not likely to work if the IDNA2008 specs
are being followed.  For example, conversion of NR-LDH labels
into U-labels is not meaningful.  Then it starts talking about
use of ToUnicode (an IDNA2003 operation) to make conversions to
"labels that generally conform to the U-label syntax"... but
U-labels are not just a matter of syntax.  That document's
getting through the IETF review process indicates to me that we
had some rather serious problems with i18n-related reviews back
then.  Time to get that fixed.  I note that Peter is
acknowledged as having provided I18n expertise; I'm having
trouble believing that, in part because the PRECIS work was well
underway by  the time and I cannot imagine his overlooking some
of those IDNA2008-related details.  Similar problems apparently
occurred even earlier when Stringprep (with the Nameprep
profile) was applied to apparently semi-arbitrary strings, not
just domain names).  All water over the dam unless we cannot
figure out how to learn from our mistakes.  And one of those
lessons, IMO, is that we should try to get things right this
time.

(2) Section 3 of the new document makes really interesting
reading, both generally and because one of its bullet points
says:

 o In its discussion of internationalized domain names,
	RFC7530 [3] adopted an approach compatible with
	IDNA2003, rather than attempting to derive the
	specification from the behavior of existing
	implementations.

But that is simply not true.  7530 references IDNA2008, uses
IDNA2008 terminology and rules and suggestions based on it.    I
haven't read it closely enough to understand whether it tries to
serve the same function as UTR#46 (which it does not mention
and, perhaps fortunately, this I-D does not mention it either).

(3) I agree with Mark.  If the I-D is going to say anything at
all i18n-ish about non-DNS identifiers (and it definitely does),
it should be referencing PRECIS, either to recommend it or to
advise why not.  Even if I agreed with Nico's suggestion (about
which I have mixed feelings; see below), this document would
need to normatively reference that one and that one would either
need to start from PRECIS or explain why not.

(4) --On Thursday, May 21, 2020 17:48 -0500 Nico Williams
<[email-masked]> wrote:

> Thus it is my opinion is that NFSv4 shouldn't have that much
> to say normatively about I18N for file names!  Instead we
> should have an RFC laying out requirements and recommendations
> for filesystems used via Internet remote/distributed
> filesystem protocols.

Sure.   And here is where I have some sympathy for the author of
this I-D and his many predecessors. Folks started trying to
reach agreement on the file system abstractions needed for such
requirements and recommendations in, IIR. mid or late 1970.
Failed then.  Have tried again multiple times over the last 49
or 50 years, which is one of the reasons NFS (the original ones
and its successors) is such a mess.   The things that have
succeeded, more or less, are FTP (but not the Unix-derived
command line version) that was intended to allow almost any file
system one could come up with and narrow the conversion
optionss/ requirements and things built on a principle that
might be described as "my file system is more important than
everyone else's and they can either adapt to my way of doing
things or lose.   The original version of NFS essentially
followed the latter model and things got into trouble when the
details of how file systems were organized, naming conventions,
etc., started to converge. And, even more in fairness to the
evolving collection of NFSv4 specs, the authors are trying to
reflect current practice and the current practice is not
consistent.  Of course, the i18n issues are only a small part of
that problem.

  best,
    john

---

From: John C Klensin <[email-masked]>
Date: Thu, 21 May 2020 23:13:18 -0400

--On Thursday, May 21, 2020 21:34 -0400 John R Levine
<[email-masked]> wrote:

> I agree, but a NFS server in Turkey will want to use Turkish
> case mapping, not some generic UTS46 one-size-fits-badly
> mapping.  That's the point, they don't prescribe a single
> mapping.

Of course, an NFS server in Turkey (or anywhere else) serving
out a file system where names or case-sensitive (such as Unix)
won't want to do case mapping at all.  And that is a fairly good
example of why this is sensitive... and why these folks would be
better off recommending appropriate profiles of PRECIS -- if
necessary, somewhat localized ones-- rather than rolling their
own.  It is also the reason why they need to much more careful
approach to normalization than the handwaving I think I noticed
as I went quickly through the draft.

   john

---

From: Nico Williams <[email-masked]>
Date: Thu, 21 May 2020 22:31:59 -0500

On Thu, May 21, 2020 at 09:34:41PM -0400, John R Levine wrote:
> not some generic UTS46 one-size-fits-badly mapping.  That's the point, they
> don't prescribe a single mapping.

Indeed, a configurable, server-side one-size-fits-all for each
filesystem is preferable to a one-size-fits-all for all implementations.

> the NFS RFC it updates, and reviewing it for us?

I haven't read it yet.  But the document I reviewed years ago did have
much to say.  Also, I'm making a general point: that this shouldn't be
about NFSv4 specifically but about filesystems generally -- I don't have
to have read this document to make that point.

That said, I can volunteer to review it.  Is there a deadline?

> that nobody would pay attention to since it would be about 40 years too

You argue "who are we to tell filesystem implementors?", but telling
NFSv4 server implementors is not much different, and is strictly worse.

Specifically you could do a global search for "NFSv4 server" (and
similar phrases) and replace with "filesystem", add text explanining the
motivation for directing the latter rather than the former, and
otherwise the rest of the document's contents stays exactly the same.

Saying what one filesystem _protocol_ must do for I18N instead of what a
_filesystem_ must do for I18N is asking for conflicts with other
protocols, and also putting server implementors who are not also the
filesystem implementors in a very tough spot.

Text describing pluggable filesystem architectures and the architectural
constraints would also be good.  I'd be willing to contribute such text.

Pretending that because "we don't do filesystems, just protocols", we
can advise only protocol designers and server implementors as to I18N,
is suboptimal for the reasons above, and does not magically cause us not
to be imposing requirements on filesystems anyways.

Pretending that is also incorrect: there clearly are participants in the
NFSv4 WG who implement filesystems, and there are IETF participants who
are not NFSv4 WG participants who have sufficient experience.

Anyways, we don't really have a choice but to develop the expertise if
we're going to pretend that telling the server what to do is good enough
when in fact doing so imposes on the filesystem implementor.  At the
very least we must acknowledge that we're doing just that and the risks
involved.

Nico
--

---

From: "Pete Resnick" <[email-masked]>
Date: Sat, 23 May 2020 10:36:33 -0500

On 21 May 2020, at 22:31, Nico Williams wrote:

> That said, I can volunteer to review it.

Excellent. Thanks. I'll put it in the tracker.

> Is there a deadline?

Let's say 2 weeks.

pr