[art] Re: [nfsv4] draft-ietf-nfsv4-internationalization- 15 early Artart review

--===============2407357736852931840==
Content-Type: multipart/alternative; boundary="000000000000b0815506521593a3"

--000000000000b0815506521593a3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, May 18, 2026 at 1:00=E2=80=AFAM Christoph Hellwig <[email protected]> wrot=
e:

> On Tue, May 12, 2026 at 08:31:11AM -0700, Arnt Gulbrandsen via Datatracke=
r
> wrote:
> > 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 th=
is
> > talking about deleting existing files? Surely not. I think this bullet
> point
> > needs rewriting.
>
> Independent of the style issues the sentence (at least the way I interpre=
t
> it), is both factually wrong and also confusing.
>
> "single byte encoding" is term not defined in this document or the obviou=
s
> references, but at least in Linux would include both 7-bit ASCII encoding
> and various different "code pages" for native language support.
>
> Traditional Unix file system treat filenames as completely opaque variabl=
e
> length arrays of bytes, with only '\0' special cased as the end of the
> string, and '/' disallowed in actual file names, but allowed in symlinks.
>

incompletely opaque, which has been a problem describing bu t hese are
typically dealt with as UTF8-unaware filesystems

.

>
> The file system in these servers is not aware of the chode pointcaracter
> set used
> at all,


True.


> so there is no way to present it as UTF-8 even if it wanted to
> (and this on-the fly conversion would have all kinds of other issues).
>

You can map each  code point to the numerically equivalent unicode code
poin.
The characters migt be different byt you don't care about that if you are
not interested in case-insensitivity or canonical-equivalence, which
youshouldn't be.

>
> Even under the (probably to bold) assumption that modern systems always
> use UTF-8, traditional Unix file system still are not aware of this,
> and would not reject invalid utf8 characters.


True.


> If we wanted to move this
> enforcement into the NFS server itself, it could easily break
> interoperability with local use of the NFS exported file system, which
> historically has been a very common use case.
>

That's why we have UTF8-unaware file systems. to avoid that mess.


> Also I'm not an expert on windows file systems, but the received knowledg=
e
> is that NTFS works very similar, but with 16-bit encodings, i.e., it
> is not restricted to valid unicode encodings.
>

True but the only internationalization approach that restricted encoding to
valid
unicode code points was theone in RFC3530  that was killed (for v4.0) by
RFC7530.  The goal here is to do the same for all minor versions.

RFC5661 implcitly allowed UTF8-unaware filesystems but kep the
restriction to assigned code points for any file systems in which
unicode features wee used.  That had to go as did the idea that v4.0
and v4.1 dealt with internationalization since everyboy doesthe
same for all minor versions.

Thanks for the comments.  Will try to make this clearer in the next
go-round.

--000000000000b0815506521593a3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, May 18,=
 2026 at 1:00=E2=80=AFAM Christoph Hellwig &lt;<a href=3D"mailto:[email protected]=
">[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">On Tue, May 12, 2026 at 08:31:11AM -0700, Arnt Gulbrandsen via =
Datatracker wrote:<br>
&gt; Page 18, 10, String Encoding. I don&#39;t understand what &quot;can be=
&quot; means here.<br>
&gt; &quot;Server file systems which used (past tense) single-byte characte=
r encodings<br>
&gt; can be converted to be UTF8-aware by rejecting non-UTF8 strings&quot;,=
 is this<br>
&gt; talking about deleting existing files? Surely not. I think this bullet=
 point<br>
&gt; needs rewriting.<br>
<br>
Independent of the style issues the sentence (at least the way I interpret<=
br>
it), is both factually wrong and also confusing.<br>
<br>
&quot;single byte encoding&quot; is term not defined in this document or th=
e obvious<br>
references, but at least in Linux would include both 7-bit ASCII encoding<b=
r>
and various different &quot;code pages&quot; for native language support.<b=
r>
<br>
Traditional Unix file system treat filenames as completely opaque variable<=
br>
length arrays of bytes, with only &#39;\0&#39; special cased as the end of =
the<br>
string, and &#39;/&#39; disallowed in actual file names, but allowed in sym=
links.<br></blockquote><div><br></div><div>incompletely opaque, which has b=
een a problem describing bu t hese=C2=A0are</div><div>typically dealt with =
as UTF8-unaware filesystems</div><div><br></div><div>.</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">
<br>
The file system in these servers is not aware of the chode pointcaracter se=
t used<br>
at all, </blockquote><div><br></div><div>True.</div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex">so there is no way to present i=
t as UTF-8 even if it wanted to<br>
(and this on-the fly conversion would have all kinds of other issues).<br><=
/blockquote><div><br></div><div>You can map each=C2=A0 code point to the nu=
merically equivalent unicode code poin.</div><div>The characters migt=C2=A0=
be different byt=C2=A0you don&#39;t care about that if you are</div><div>no=
t interested in case-insensitivity or canonical-equivalence, which youshoul=
dn&#39;t=C2=A0be.</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Even under the (probably to bold) assumption that modern systems always<br>
use UTF-8, traditional Unix file system still are not aware of this,<br>
and would not reject invalid utf8 characters.=C2=A0 </blockquote><div><br><=
/div><div>True.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex">If we wanted to move this<br>
enforcement into the NFS server itself, it could easily break<br>
interoperability with local use of the NFS exported file system, which<br>
historically has been a very common use case.<br></blockquote><div><br></di=
v><div>That&#39;s why we=C2=A0have UTF8-unaware file systems. to avoid that=
 mess.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
">
<br>
Also I&#39;m not an expert on windows file systems, but the received knowle=
dge<br>
is that NTFS works very similar, but with 16-bit encodings, i.e., it<br>
is not restricted to valid unicode encodings.<br></blockquote><div><br></di=
v><div>True but the only internationalization approach that restricted=C2=
=A0encoding=C2=A0to valid=C2=A0=C2=A0</div><div>unicode code points was the=
one=C2=A0in RFC3530=C2=A0 that was killed (for v4.0) by=C2=A0</div><div>RFC=
7530.=C2=A0 The goal here is=C2=A0to do the same for all minor versions.</d=
iv><div><br></div><div>RFC5661 implcitly=C2=A0allowed UTF8-unaware filesyst=
ems=C2=A0but kep the=C2=A0</div><div>restriction to assigned code points fo=
r any file systems in which</div><div>unicode features wee used.=C2=A0 That=
 had to go as did the idea that v4.0</div><div>and v4.1 dealt with internat=
ionalization since everyboy=C2=A0doesthe</div><div>same for all minor versi=
ons.</div><div><br></div><div>Thanks for the comments.=C2=A0 Will try to ma=
ke this clearer in the next</div><div>go-round.</div></div></div>

--000000000000b0815506521593a3--


--===============2407357736852931840==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KYXJ0IG1haWxp
bmcgbGlzdCAtLSBhcnRAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byBh
cnQtbGVhdmVAaWV0Zi5vcmcK

--===============2407357736852931840==--