Re: [I18ndir] NFS i18n

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

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

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

> On 21 May 2020, at 13:57, Pete Resnick wrote:
> 
>> 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?
> 
> 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
<[e-mail]> 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