Early Review of draft-ietf-nfsv4-internationalization-15
review-ietf-nfsv4-internationalization-15-artart-early-gulbrandsen-2026-05-12-00

I am the designated ART reviewer for draft-ietf-nfsv4-internationalization.

I have considerable experience with internationalisation. My NFS experience is
limited to using it all the time and, uh, I distinctly remember reading the
original paper, thirty-some years ago ;)

The draft seems very valuable to NFS implementers who want to have effective
i18n support, but it's a hard read. I eventually gave up on the overlong
sentences, missing commas, stray command and so on, and will only comment on a
few in this review. The first spot where grammar really confused me was

  suggesting (even though the words "SHOULD NOT were used that

that I think should be

  suggesting (even though the words "SHOULD NOT" were used) that it

There were many, too many for a review like this. I may just send separate
messages with a diff — what's the source for this document?

Another reviewer noted that this document redefines terms from RFC2119. That
makes sense to me, though. "Clients must do this and that because effective
interop with existing code requires that", not ideal perhaps but it makes sense
given the realities of the present situation.

Some of the language really needs simplication. Like this sentence:

  These cases are simplified and made less subject to changes in
  expected choices as to normalization and case mapping by focusing
  the processing on providing comparisons that are insensitive to
  choices of characters within equivalence classes rather than on the
  selection of preferred characters from within such classes.

There's occasional annoying lack of clarity. Page 10 says "certain forms of
name caching can be interfered with", what forms? Pretending to be an
implementer, I'd want an example here to write a unit test or regression test.

Page 10 also confused me with a typo, "it is worth nothing that". It's worth
noting, not nothing, and I didn't understand it until I had the typo fixed.

Page 17, section 9, confused me. "The attribute still contains two flag bits",
which bits are these? 9.1 names two things, are those the two bits or are the
two historical bits something else?

Page 18, "when the recommentation is bypassed", when who does what?

Page 18, 10, String Encoding. I don't understand what "can be" means here.
"Server file systems which used (past tense) single-byte character encodings
can be converted to be UTF8-aware by rejecting non-UTF8 strings", is this
talking about deleting existing files? Surely not. I think this bullet point
needs rewriting.

Page 19 refers to UTS 46 for the string encoding specified by RFC 3492. UTS 46
refers to 3492, of course, but I'd say you might as well link directly to the
defining document.

Page 20 specifies that symbolic link targets are out of scope. What effect does
this have? What's the practical aspect of this? The whole document provides
advice to implementers, so I'm puzzled that there's none in this case.

Page 21 again refers to UTS 46, "the encoding algorithm in UTS 46", well, the
algorithm is in RFC 3492. (While I'm on the subject; there's some odd phrasing
here, e.g. unicode characters instead of codepoints, xn+ascii instead of ACE or
punycode. I don't think that's a major problem. Author's prerogative IMO.)

Page 23 mentions that RFC 3490 "might require... validate or rectify". I can't
find any instance of the word rectify in 3490, and can't tell what this
paragraph is about.

Page 26, "in making such the determinations" and the rest of the paragraph. "."
and ".." are certainly <128 but why are such rejections limited to <128?

Appendix A.4 looks hopeful to me. Is that based on code? Has anyone tried to do
this, such that accidental omissions or mistakes would be discovered? It looks
quite well-informed and capable, clearly written by smart people.

Appendix B has the same look.

I appreciate Appendix C. A couple of questions, though:

"A satisfactory modus vivendi may have been arrived at". The WG members ought
to know — has 7530 been widely implemented and do implementers consider it okay?

RFC 8881 is mentioned several times, once that it "specifies an entirely
different approach". It seems notable enough to get at least a couple of
sentences, it's a history appendix after all.

This review may sound more critical than I intended it to be. Reading the
document was hard, even though I can tell that the author and other WG members
understand the subject well and put in a lot of useful information.