[art] draft-ietf-nfsv4-internationalization-15 early Artart re view
David Noveck <[email protected]> Wed, 13 May 2026 09:47:36 -0400
| Newsgroups | gmane.ietf.apps-discuss,gmane.ietf.nfsv4 |
|---|---|
| Message-ID | <CADaq8jfJqSn8A5GFBuWX7y5V32X-GuiNTV+uk_1TFKFwrq6Z+w@mail.gmail.com> |
--===============3933644708120477428== Content-Type: multipart/alternative; boundary="000000000000bcacde0651b339d4" --000000000000bcacde0651b339d4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tuesday, May 12, 2026, Arnt Gulbrandsen via Datatracker <[email protected]= g> wrote: > Document: draft-ietf-nfsv4-internationalization > Title: Internationalization for the NFSv4 Protocols > Reviewer: Arnt Gulbrandsen > Review result: Almost Ready > > I am the designated ART reviewer for draft-ietf-nfsv4-internationalizatio= n. Thanks for taking this on. > > I have considerable experience with internationalisation. My NFS > experience is > limited to using it all the time and, uh, I distinctly remember reading t= he > original paper, thirty-some years ago ;) It's been awfully long time. I have been trying to understand the reasons for that. > > 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. Will try to improve things based on your helpful comments. > 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 Will fix. > > There were many, too many for a review like this. I may just send separat= e > messages with a diff Works for me. > =E2=80=94 what's the source for this document? It's the corresponding .xml file. You can get it from the datatracker. > > Another reviewer noted that this document redefines terms from RFC2119. > That > makes sense to me, though. "Clients must do this and that because effecti= ve > interop with existing code requires that", not ideal perhaps but it makes > sense > given the realities of the present situation. Unfortunately, not all readers would be aware of the realities of the current situation. I may need to be more direct about the situation which involves multiple versions specifying things incorrectly while implementers ignored the incorrect specification. Normally, when you have changed the spec, you have to deal with how changes affect existing implementations. Here you are still worried but the job of the spec was to follow implementations which justifiably ignored the incorrect specification. > 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. How about the following replacement: Previous treatments of Internationalization have focused on selecting a desired case or normalization form and converting to those presumably better forms. A better choice is to avoid such choices and focus instead on providing comparisons that are insensitive to case and the choice of a particular string from a set of canonically equivalent strings. > 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 fixe= d. Will fix. > 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? > The former. Will clarify the text. > Page 18, "when the recommentation is bypassed", when who does what? > Will say the following: bypassing the recommendation above by not setting the FSCHARSET_CAP4_CONTAINS_NON_UTF8 flag to be the complement of the FSCHARSET_CAP4_ALLOWS_ONLY_UTF8 flag. Hope that is OK. > > 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. > Right: Now proposing: Server file systems which contain only single-byte character encodings can be presented as UTF8-aware by rejecting non-UTF8 strings and rejecting multi-byte UTF-8 strings as containing unacceptable character.s. The use of form-insensitive comparisons is limited to cases in which both comparands fit it one byte so these cases ae better presented as UTF8-unaware > 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. > Will do. > > Page 20 specifies that symbolic link targets are out of scope. What effec= t > does > this have? What's the practical aspect of this? The whole document provid= es > advice to implementers, so I'm puzzled that there's none in this case. > It has the following: The contents of symbolic links (of type linktext4 in the XDR) MUST be treated as opaque data by NFSv4 servers. Although UTF-8 encoding is often used, it need not be. In this respect, the contents of symbolic links are like the contents of regular files in that their encoding is not within the scope of thisspecification. > > Page 21 again refers to UTS 46, "the encoding algorithm in UTS 46", well, > the > algorithm is in RFC 3492. Will correct. > (While I'm on the subject; there's some odd phrasing > here, e.g. unicode characters instead of codepoints, That seemed more natural to me in a document in which other character encodings are not always to be tossed on the scrapheap of history. xn+ascii instead of ACE or > punycode. I will clarify "xn+asscii". I don't know what ACE is and I avoided "punycode" based on J. Klensin's advice. > 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. > I wasn't sure about specific which is why I said "mght". Instead of rectify, would "correct" be better? > > 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? > Rewritten as follows: In making such the determinations regarding returning NFS4ERR_BADCHAR, servers would be depending on the character encoding used even when the encoding using UTF-8 is not enforced. Where such rejections are limited to characters whose values are below 128, clients are, as a practical matter, safe if their encodings are consistent with UTF-8 in the handling of byte values 127 and below. > > Appendix A.4 looks hopeful to me. Is that based on code? No. > > Has anyone tried to do > this, such that accidental omissions or mistakes would be discovered? I didn' t havevtimevforvthatvwhich itchy I placed this in an appendix since it was not ready for a stsndard and I didn't to lose the work. > > 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 =E2=80=94 has 7530 been widely implemented and do implementers co= nsider it > okay? Yes but the causality is the reverse what you would have expected. People did not read RFC7530 and implement that. Instead people implemented what made sense to them and RFC7530 attempted to document the way that worked. The verification consisted of working group discussion and discussion with individual the vast majority who had fllowed the UTF8-unaware approach. I made special efforts to consult with those who had implemented the UTF8-aware approach, icluding those that interaced with the ZFS filesystem that implemented form-insensitive name comprisons within the filesystem. > > 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. I'll add some stuff. When I wrote this I tried to hold off repeated descriptions of things that had previously been done wrong. Intend to say: When <xref target=3D"RFC881"/> was oublished, it made no change in the speficaton of internationalization since the focus of that effort was on te work to deal metter with file system migration issues > 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. > > > > --000000000000bcacde0651b339d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><br>On Tuesday, May 12, 2026, Arnt Gulbrandsen via Dat= atracker <<a href=3D"mailto:[email protected]" target=3D"_blank">noreply@= ietf.org</a>> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Document: draft-i= etf-nfsv4-internationalization<br> Title: Internationalization for the NFSv4 Protocols<br> Reviewer: Arnt Gulbrandsen<br> Review result: Almost Ready<br> <br> I am the designated ART reviewer for draft-ietf-nfsv4-internationalization.= </blockquote><div><br></div><div>Thanks for taking this on.</div><div>=C2= =A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde= r-left:1px #ccc solid;padding-left:1ex"> <br> I have considerable experience with internationalisation. My NFS experience= is<br> limited to using it all the time and, uh, I distinctly remember reading the= <br> original paper, thirty-some years ago ;)</blockquote><div><br></div><div>It= 's been awfully long time. I have=C2=A0been=C2=A0 trying to understand = the reasons for that.</div><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> The draft seems very valuable to NFS implementers who want to have effectiv= e<br> i18n support, but it's a hard read. I eventually gave up on the overlon= g<br> sentences, missing commas, stray command and so on, and will only comment o= n a<br> few in this review.</blockquote><div><br></div><div>Will try to improve thi= ngs based on your helpful comments.</div><div>=C2=A0</div><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex">=C2=A0The first spot where grammar really confused me was<br> <br> =C2=A0 suggesting (even though the words "SHOULD NOT were used that<br= > <br> that I think should be<br> <br> =C2=A0 suggesting (even though the words "SHOULD NOT" were used) = that it</blockquote><div><br></div><div>Will fix.=C2=A0</div><div>=C2=A0</d= iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left= :1px #ccc solid;padding-left:1ex"> <br> There were many, too many for a review like this. I may just send separate<= br> messages with a diff </blockquote><div><br></div><div>Works for me.</div><d= iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex">=E2=80=94 what's the sour= ce for this document?</blockquote><div><br></div><div>It's the correspo= nding .xml file. You can get it from the datatracker.</div><div>=C2=A0</div= ><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1= px #ccc solid;padding-left:1ex"> <br> Another reviewer noted that this document redefines terms from RFC2119. Tha= t<br> makes sense to me, though. "Clients must do this and that because effe= ctive<br> interop with existing code requires that", not ideal perhaps but it ma= kes sense<br> given the realities of the present situation.</blockquote><div><br></div><d= iv>Unfortunately, not all readers would be aware of the realities of the cu= rrent situation.=C2=A0 I may need to be more direct about the situation whi= ch involves multiple versions specifying things incorrectly while implement= ers ignored the incorrect specification.=C2=A0 Normally, when you have chan= ged the spec, you=C2=A0have to deal with how changes affect existing implem= entations.=C2=A0 Here you are still worried but the job of the spec was to = follow implementations which justifiably ignored the incorrect specificatio= n.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 = 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> Some of the language really needs simplication. Like this sentence:<br> <br> =C2=A0 These cases are simplified and made less subject to changes in<br> =C2=A0 expected choices as to normalization and case mapping by focusing<br= > =C2=A0 the processing on providing comparisons that are insensitive to<br> =C2=A0 choices of characters within equivalence classes rather than on the<= br> =C2=A0 selection of preferred characters from within such classes.</blockqu= ote><div><br></div><div>How about the following replacement:</div><div><br>= </div><div>Previous treatments of Internationalization have focused on sele= cting a desired case or normalization form and converting to those presumab= ly better forms.=C2=A0 A better choice is to avoid such choices and focus i= nstead on providing comparisons that are insensitive to case and the choice= of a particular string from a set of canonically equivalent strings.</div>= <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex"> <br> There's occasional annoying lack of clarity. Page 10 says "certain= forms of<br> name caching can be interfered with", what forms? Pretending to be an<= br> implementer, I'd want an example here to write a unit test or regressio= n test.<br> <br> Page 10 also confused me with a typo, "it is worth nothing that".= It's worth<br> noting, not nothing, and I didn't understand it until I had the typo fi= xed.</blockquote><div><br></div><div>Will fix.=C2=A0</div><div><br></div><b= lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px = #ccc solid;padding-left:1ex"> <br> Page 17, section 9, confused me. "The attribute still contains two fla= g bits",<br> which bits are these? 9.1 names two things, are those the two bits or are t= he<br> two historical bits something else?<br></blockquote><div><br></div><div>The= former.=C2=A0 Will clarify the text.=C2=A0</div><div><br></div><blockquote= class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli= d;padding-left:1ex"> <br> Page 18, "when the recommentation is bypassed", when who does wha= t?<br></blockquote><div><br></div><div>Will say the following:</div><div><b= r></div><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><di= v>bypassing the recommendation above =C2=A0by not setting the</div></blockq= uote><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"> FSCHA= RSET_CAP4_CONTAINS_NON_UTF8 flag to be the</blockquote><blockquote style=3D= "margin:0 0 0 40px;border:none;padding:0px"> complement of the FSCHARSET_CA= P4_ALLOWS_ONLY_UTF8 flag.<br><br><br></blockquote>Hope that is OK.<br><bloc= kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc= c solid;padding-left:1ex"> <br> Page 18, 10, String Encoding. I don't understand what "can be"= ; means here.<br> "Server file systems which used (past tense) single-byte character enc= odings<br> can be converted to be UTF8-aware by rejecting non-UTF8 strings", is t= his<br> talking about deleting existing files? Surely not. I think this bullet poin= t<br> needs rewriting.<br></blockquote><div><br></div><div>Right:=C2=A0 Now propo= sing:</div><div><br></div><blockquote style=3D"margin:0 0 0 40px;border:non= e;padding:0px">Server file systems which contain only single-byte character= encodings<br> can be presented as UTF8-aware by rejecting non-UTF8<br> str= ings and rejecting multi-byte UTF-8 strings as containing<div>unacceptable = character.s.</div><div> The use of form-insensitive comparisons is limited = to</div><div> cases in which both comparands fit it one byte so these cases= ae</div><div><div>better presented as UTF8-unaware=C2=A0</div></div></bloc= kquote><div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo= rder-left:1px #ccc solid;padding-left:1ex"> <br> Page 19 refers to UTS 46 for the string encoding specified by RFC 3492. UTS= 46<br> refers to 3492, of course, but I'd say you might as well link directly = to the<br> defining document.<br></blockquote><div><br></div><div>Will do.=C2=A0</div>= <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> Page 20 specifies that symbolic link targets are out of scope. What effect = does<br> this have? What's the practical aspect of this? The whole document prov= ides<br> advice to implementers, so I'm puzzled that there's none in this ca= se.<br></blockquote><div><br></div><div>It has the following:</div></div><b= lockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><div><div><pr= e style=3D"color:rgb(0,0,0);white-space:pre-wrap"><font face=3D"arial, sans= -serif">The contents of symbolic links (of type linktext4 in the XDR) MUST<= br>be treated as opaque data by NFSv4 servers. Although UTF-8<br>encoding = is often used, it need not be. In this respect, the<br>contents of symboli= c links are like the contents of regular files in that <br>their encoding i= s not within the scope of thisspecification.</font></pre></div></div></bloc= kquote><div><div><font face=3D"arial, sans-serif">=C2=A0</font></div><block= quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc= solid;padding-left:1ex"> <br> Page 21 again refers to UTS 46, "the encoding algorithm in UTS 46"= ;, well, the<br> algorithm is in RFC 3492. </blockquote><div><br></div><div>Will correct.</d= iv><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0= .8ex;border-left:1px #ccc solid;padding-left:1ex">(While I'm on the su= bject; there's some odd phrasing<br> here, e.g. unicode characters instead of codepoints, </blockquote><div><br>= </div><div>That seemed more natural to me in a document in which other</div= ><div>character=C2=A0encodings=C2=A0 are not always to be tossed on the scr= apheap of history.=C2=A0</div><div><br></div><blockquote class=3D"gmail_quo= te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"= >xn+ascii instead of ACE or<br> punycode. </blockquote><div><br></div><div>I will clarify "xn+asscii&q= uot;.=C2=A0 =C2=A0 I don't know what ACE is and I avoided "punycod= e" based on=C2=A0</div><div>J. Klensin's advice.=C2=A0 =C2=A0</div= ><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .= 8ex;border-left:1px #ccc solid;padding-left:1ex">I don't think that'= ;s a major problem. Author's prerogative IMO.)<br> <br> Page 23 mentions that RFC 3490 "might require... validate or rectify&q= uot;. I can't<br> find any instance of the word rectify in 3490, and can't tell what this= <br> paragraph is about.<br></blockquote><div><br></div><div>I wasn't sure a= bout specific which is why I said "mght".=C2=A0 Instead of rectif= y, would</div><div>"correct" be better?=C2=A0</div><blockquote cl= ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p= adding-left:1ex"> <br> Page 26, "in making such the determinations" and the rest of the = paragraph. "."<br> and ".." are certainly <128 but why are such rejections limite= d to <128?<br></blockquote><div><br></div><div>Rewritten as follows:</di= v><div><br></div>=C2=A0 =C2=A0 =C2=A0 In making such the determinations reg= arding returning<br>=C2=A0 =C2=A0 =C2=A0 NFS4ERR_BADCHAR, servers would be = depending on the character<br>=C2=A0 =C2=A0 =C2=A0 encoding used even when = the<br>=C2=A0 =C2=A0 =C2=A0 encoding using UTF-8 is not enforced.=C2=A0 Whe= re such rejections<br>=C2=A0 =C2=A0 =C2=A0 are limited to characters whose = values are below 128, clients are,<br>=C2=A0 =C2=A0 =C2=A0 as a practical m= atter, safe if their encodings are consistent with<br><div>=C2=A0 =C2=A0 = =C2=A0 UTF-8 in the handling of byte values 127 and below.=C2=A0</div><bloc= kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc= c solid;padding-left:1ex"> <br> Appendix A.4 looks hopeful to me. Is that based on code?=C2=A0</blockquote>= <div><br></div><div>No.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu= ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex= "><br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex">Has anyone tried to do<br= > this, such that accidental omissions or mistakes would be discovered?=C2=A0= </blockquote><div><br></div><div>I didn' t havevtimevforvthatvwhich itc= hy I placed this in an appendix since it was not ready for a stsndard=C2=A0= and I didn't to lose the work.</div><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br= ></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex">It looks<br> quite well-informed and capable, clearly written by smart people.<br> <br> Appendix B has the same look.<br> <br> I appreciate Appendix C. A couple of questions, though:<br> <br> "A satisfactory modus vivendi may have been arrived at". The WG m= embers ought<br> to know =E2=80=94 has 7530 been widely implemented and do implementers cons= ider it okay?</blockquote><div><br></div><div>Yes but the causality is the = reverse what you would have expected.=C2=A0 People did not read</div><div>R= FC7530 and implement that.=C2=A0 Instead people implemented what made sense= to them</div><div>and RFC7530 attempted to document the way that worked.= =C2=A0 The verification</div><div>consisted of=C2=A0working group discussio= n and discussion=C2=A0with individual the</div><div>vast majority who had f= llowed=C2=A0the UTF8-unaware approach.=C2=A0 I made special</div><div>effor= ts to consult with those=C2=A0who had implemented=C2=A0 the UTF8-aware=C2= =A0</div><div>approach, icluding=C2=A0those that interaced=C2=A0with the ZF= S filesystem=C2=A0that</div><div>implemented form-insensitive name compriso= ns=C2=A0within the</div><div>filesystem.</div><blockquote class=3D"gmail_qu= ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex= "> <br> RFC 8881 is mentioned several times, once that it "specifies an entire= ly<br> different approach". It seems notable enough to get at least a couple = of<br> sentences, it's a history appendix after all.</blockquote><div><br></di= v><div>I'll add some stuff.=C2=A0 When I wrote this I tried to hold off= repeated descriptions of things that had previously been done wrong.</div>= </div><div><br></div><div>Intend to say:</div><div><br></div><blockquote st= yle=3D"margin:0 0 0 40px;border:none;padding:0px"><div>When <xref target= =3D"RFC881"/> was oublished, it made no change</div><div> in t= he speficaton of internationalization since the focus of</div><div> that ef= fort was on te work to deal metter with file system</div><div> migration is= sues</div></blockquote></div><blockquote class=3D"gmail_quote" style=3D"mar= gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1= ex"> <br> This review may sound more critical than I intended it to be. Reading the<b= r> document was hard, even though I can tell that the author and other WG memb= ers<br> understand the subject well and put in a lot of useful information.<br> <br> <br> <br> </blockquote> --000000000000bcacde0651b339d4-- --===============3933644708120477428== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KYXJ0IG1haWxp bmcgbGlzdCAtLSBhcnRAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byBh cnQtbGVhdmVAaWV0Zi5vcmcK --===============3933644708120477428==--