Subject: [nfsv4] one more try at RFC3530 internationalization.

From: "Noveck, David" <[email-masked]>
Date: Wed, 7 Aug 2013 15:40:18 -0400

I've been working with Tom Haynes and David Black to come with an 
approach to internationalization for RFC3530bis, that meets the IESG's 
objections and has a good chance of being approved. 

The approach to be taken is basically to get an internationalization 
description that matches what people have implemented.  I think it is 
pretty clear that does not match the stringprep-based approach taken in 
RFC3530, although we may have some issues proving that fact to the IESG, 
or more properly, giving Martin the information he needs to prove it to 
the IESG.

The internationalization approach in the curent RF3530bis draft,
draft-ietf-nfsv4-rfc3530bis-26 attempted to make the stringprep stuff 
non-normtive nd loosen it nough tht current implentations fit withiin
it.  unfortunately, the IESG ididn't like it, so we need something else.

The proposed approach is to base the new RFC3530bis handling of 
internationalization on the internationlization tretament in
draft-ietf-nfsv4-rfc3010bis-04, the last draft for rfc3530 before
it was stringprep-ized.  I feel that this is simple enough that we 
can clearly make the case, with the implementer's help, that this
is what current servers and clients do and getting RFC3530bis approved.

The rest of this mail surveys the intrnationalization-related changes
that are proposed to follow through on this approach.

As mentioned we are starting with Chapter 11 of 
draft-ietf-nfsv4-rfc3010bis-04 and making the following changes:

  o  Added an introductory section explaining that this is description 
     of current implementations, even though the words 
     MUST/SHOULD/MAY/should are used to guide future implementations.
  o  Deleted the sections containing a discussion of encoding 
     alternatives and put in simple statement that a UTF-8 encoding of 
     Unicode is to be used.
  o  Added a section distinguishing how different sorts of strings are 
     handled.
  o  In the normalization section changed "A later revision of this 
     specification may specify a particular normalization form" to 
     "A subsequent minor version of the NFSv4 protocol might specify 
     a particular normalization form."
  o  Added in a new section derived from section 12.6 of rfc3530bis.
  o  Added a new paragraph saying what server MAY and MAY NOT do 
     regarding normalization.
  o  In the error discussion replaced a "should" by "SHOULD".  This is 
     not primarily to strengthen the requirement, although that is the 
     effect.  It is mainly to make it clear that some servers will not 
     be doing it.  There are also other changes in that section to tie 
     in with that. 

There are another set of changes to undo the changes to the XDR to 
define more precisely what the utf-8 attributes of various sorts of 
strings are.  Basically we are leaving ascii_REQUIRED4 in and changing 
all instances of the new utf* types back to utf8string.  This includes
changes to draft-ietf-nfsv4-rfc3530bis-dox-x  plus the following changes
to draft-ietf-nfsv4-rfc3530bis outside the internationalization chapter.

  o  Deleting the definitions of these types in section 2.1.  Also the 
     uses of these types in this section.
  o  Adjust the definition in 2.2.6 (of fs_location4). Also another 
     occurrence of the same in 7.9)
  o  Fixing a similar definition in 6.2.1. (of nfs4ace4).

Any comments before we go ahead with a new draft based on this 
approach?

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 7 Aug 2013 20:28:38 +0000

Thanks for taking this one, David.

For the rest of the WG, a big part of this, as David outlines, is based on understanding what the current implementations have built/deployed.  In support of that, it would be a big help if you would send David a direct email with the choices made in your implementation with regards to i18n.

Spencer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Noveck, David
Sent: Wednesday, August 7, 2013 12:40 PM
To: nfsv4 list ([email-masked])
Subject: [nfsv4] one more try at RFC3530 internationalization.

I've been working with Tom Haynes and David Black to come with an approach to internationalization for RFC3530bis, that meets the IESG's objections and has a good chance of being approved. 

The approach to be taken is basically to get an internationalization description that matches what people have implemented.  I think it is pretty clear that does not match the stringprep-based approach taken in RFC3530, although we may have some issues proving that fact to the IESG, or more properly, giving Martin the information he needs to prove it to the IESG.

The internationalization approach in the curent RF3530bis draft,
draft-ietf-nfsv4-rfc3530bis-26 attempted to make the stringprep stuff non-normtive nd loosen it nough tht current implentations fit withiin it.  unfortunately, the IESG ididn't like it, so we need something else.

The proposed approach is to base the new RFC3530bis handling of internationalization on the internationlization tretament in draft-ietf-nfsv4-rfc3010bis-04, the last draft for rfc3530 before it was stringprep-ized.  I feel that this is simple enough that we can clearly make the case, with the implementer's help, that this is what current servers and clients do and getting RFC3530bis approved.

The rest of this mail surveys the intrnationalization-related changes that are proposed to follow through on this approach.

There are another set of changes to undo the changes to the XDR to define more precisely what the utf-8 attributes of various sorts of strings are.  Basically we are leaving ascii_REQUIRED4 in and changing all instances of the new utf* types back to utf8string.  This includes changes to draft-ietf-nfsv4-rfc3530bis-dox-x  plus the following changes to draft-ietf-nfsv4-rfc3530bis outside the internationalization chapter.

Any comments before we go ahead with a new draft based on this approach?

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Nico Williams <[email-masked]>
Date: Wed, 7 Aug 2013 17:26:24 -0500

> or more properly, giving Martin the information he needs to prove it to

Back then the IETF didn't have all that much experience with I18N.
Even recently the PRECIS WG was nearly making serious mistakes.  I
think our experience qualifies as experience to learn from.  I think
the IESG will surely understand.

> it.  unfortunately, the IESG ididn't like it, so we need something else.

We know from our experience with ZFS and NFS on top what is reasonable
and what is not w.r.t. filesystem object names:

 - it is reasonable to reject non-UTF-8

 - it is reasonable to do normalization- and/or case-insensitivity --
i.e., do any normalization and mapping on lookup (or on hashing at
create time) but always return the original name on READDIR, with a
security considerations note about aliasing

 - it is probably reasonable to not normalize for anything

 - normalize-on-create, mappings of any kind (e.g., case) are a
sometimes-desirable, sometimes-not feature, and in particular on most
Unix systems (not including OS X w/ HFS+) normalization-on-create and
any mappings on create lead to problems, therefore:

 - it is reasonable to not do *any* mappings or normalization on
create -- this has to be a choice made with application compatibility
in mind

 - all of this on a per-filesystem basis (or even per-directory), NOT
on a per-fileserver basis

>From experience in the SASL/PRECIS world we know that for *user* and
group names it's best to apply any and all normalization and mappings
on the server side.  The client need not do anything, though
normalizing doesn't hurt (but mappings, on the client side, *do*
hurt).

Actually, that applies to filesystem objects as well: the client
should do no mappings.

We really need to distinguish:

 - query strings (strings sent by the client to the server)

 - storage strings (what the filesystem/server stores)

 - display strings (what the user sees)

The preparation for query strings should be minimal; the identity
function will do, though the client MUST (but won't) convert between
non-UTF-8 and UTF-8, because a) the server SHOULD reject non-UTF-8,
and b) codeset aliasing sucks.

The preparation for storage strings is and should be
filesystem-specific.  For example, HFS+ normalizes on create to NFD
and is case-insensitive on lookup (IIRC).  Nothing an RFC says can
change that -- we must not even try.  What we can do is hope to get
codeset conversions right by dictating the use of UTF-8 on the wire:
then clients and servers can convert to/from whatever they use
locally.  For example, on Solaris 11 FAT and other such filesystems
can convert automatically to UTF-16 and/or to various code pages.

In practice clients cannot really do codeset conversions because the
only place that such conversions can be done in Unix-like OSes is in
the C run-time's system call stubs (the kernel doesn't know about
user-land locales, and above the system call stubs is the app, which
shouldn't have to do these conversions).  To my knowledge no C library
does that.  This can be addressed by running only in UTF-8 locales,
but that's not 100% satisfactory, just 95%.  Client implementors that
care enough will go and fix their user-land C run-times, though I
doubt any will.

> is what current servers and clients do and getting RFC3530bis approved.

I've not read that.  Please see my proposal above.

Nico
--

---

From: "Noveck, David" <[email-masked]>
Date: Thu, 8 Aug 2013 14:02:01 -0400

> Back then the IETF didn't have all that much experience with I18N.

Now it has and everybody is sadder and a few people are wiser.  

> Even recently the PRECIS WG was nearly making serious mistakes.  

But they didn't actually make them?  Sounds pretty good to me.

> I think our experience qualifies as experience to learn from.  

I think so but I don't expect the rest of the IETF internationalization community to agree, at least for a while.

> I think the IESG will surely understand.

I believe you're unduly optimistic.

>> draft-ietf-nfsv4-rfc3010bis-04, the last draft for rfc3530 before it 
>> was stringprep-ized.  I feel that this is simple enough that we can 
>> clearly make the case, with the implementer's help, that this is what 
>> current servers and clients do and getting RFC3530bis approved.

> I've not read that.  Please see my proposal above.

When we have a new draft-ietf-nfsv4-rfc3050bis,incorporating the above, I'd ask you to read that and indicate any cases in which the things you think are reasonable (and have presumably implemented) are not at least ALLOWED by that new draft.  That draft will allow many things you think and I think are unreasonable, but our goal here is to allow all existing implementation behavior  so that Martin can confidently tell the IESG that rfc3530bis describes the actual implementations out there. 

-----Original Message-----
From: Nico Williams [mailto:[email-masked]] 
Sent: Wednesday, August 07, 2013 6:26 PM
To: Noveck, David
Cc: nfsv4 list ([email-masked])
Subject: Re: [nfsv4] one more try at RFC3530 internationalization.

On Wed, Aug 7, 2013 at 2:40 PM, Noveck, David <[email-masked]> wrote:
> pretty clear that does not match the stringprep-based approach taken 
> in RFC3530, although we may have some issues proving that fact to the 
> IESG, or more properly, giving Martin the information he needs to 
> prove it to the IESG.

Back then the IETF didn't have all that much experience with I18N.
Even recently the PRECIS WG was nearly making serious mistakes.  I think our experience qualifies as experience to learn from.  I think the IESG will surely understand.

> it.  unfortunately, the IESG ididn't like it, so we need something else.

We know from our experience with ZFS and NFS on top what is reasonable and what is not w.r.t. filesystem object names:

 - it is reasonable to do normalization- and/or case-insensitivity -- i.e., do any normalization and mapping on lookup (or on hashing at create time) but always return the original name on READDIR, with a security considerations note about aliasing

 - normalize-on-create, mappings of any kind (e.g., case) are a sometimes-desirable, sometimes-not feature, and in particular on most Unix systems (not including OS X w/ HFS+) normalization-on-create and any mappings on create lead to problems, therefore:

 - it is reasonable to not do *any* mappings or normalization on create -- this has to be a choice made with application compatibility in mind

 - all of this on a per-filesystem basis (or even per-directory), NOT on a per-fileserver basis

From experience in the SASL/PRECIS world we know that for *user* and group names it's best to apply any and all normalization and mappings on the server side.  The client need not do anything, though normalizing doesn't hurt (but mappings, on the client side, *do* hurt).

Actually, that applies to filesystem objects as well: the client should do no mappings.

The preparation for query strings should be minimal; the identity function will do, though the client MUST (but won't) convert between
non-UTF-8 and UTF-8, because a) the server SHOULD reject non-UTF-8, and b) codeset aliasing sucks.

The preparation for storage strings is and should be filesystem-specific.  For example, HFS+ normalizes on create to NFD and is case-insensitive on lookup (IIRC).  Nothing an RFC says can change that -- we must not even try.  What we can do is hope to get codeset conversions right by dictating the use of UTF-8 on the wire:
then clients and servers can convert to/from whatever they use locally.  For example, on Solaris 11 FAT and other such filesystems can convert automatically to UTF-16 and/or to various code pages.

In practice clients cannot really do codeset conversions because the only place that such conversions can be done in Unix-like OSes is in the C run-time's system call stubs (the kernel doesn't know about user-land locales, and above the system call stubs is the app, which shouldn't have to do these conversions).  To my knowledge no C library does that.  This can be addressed by running only in UTF-8 locales, but that's not 100% satisfactory, just 95%.  Client implementors that care enough will go and fix their user-land C run-times, though I doubt any will.

> draft-ietf-nfsv4-rfc3010bis-04, the last draft for rfc3530 before it 
> was stringprep-ized.  I feel that this is simple enough that we can 
> clearly make the case, with the implementer's help, that this is what 
> current servers and clients do and getting RFC3530bis approved.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 8 Aug 2013 14:45:43 -0500

> But they didn't actually make them?  Sounds pretty good to me.

Right.

> I think so but I don't expect the rest of the IETF internationalization
> community to agree, at least for a while.

Rough consensus and running code.  We have running code with interop
requirememts that make anything beyond what i described highly undesirable.
 I will explain this as many ways and as long as i have to till it sinks in.

> I believe you're unduly optimistic.

If so then we should get a head start on convincing the IESG.  I suppose
that means: a) submit an I-D, b) start a thread on [email-masked].

> When we have a new draft-ietf-nfsv4-rfc3050bis,incorporating the above,
> I'd ask you to read that and indicate any cases in which the things you
> think are reasonable (and have presumably implemented) are not at least
> ALLOWED by that new draft.  That draft will allow many things you think and
> I think are unreasonable, but our goal here is to allow all existing
> implementation behavior  so that Martin can confidently tell the IESG that
> rfc3530bis describes the actual implementations out there.
>

You don't sound so pessimistic after all.

Nico
--

---

From: Mike Kupfer <[email-masked]>
Date: Tue, 20 Aug 2013 18:05:48 -0700

Noveck, David wrote:

> When we have a new draft-ietf-nfsv4-rfc3050bis,incorporating the
> above, I'd ask you to read that and indicate any cases in which the
> things you think are reasonable (and have presumably implemented) are
> not at least ALLOWED by that new draft.  That draft will allow many
> things you think and I think are unreasonable, but our goal here is to
> allow all existing implementation behavior  so that Martin can
> confidently tell the IESG that rfc3530bis describes the actual
> implementations out there. 

I'm afraid the first bullet in 12.2 conflicts with what Solaris
implements, and I suspect it conflicts with other implementations.  That
section says

> 12.2.  String Encoding
> 
>    Strings that potentially contain non-ASCII Characters are represented
>    in NFSv4 using the UTF-8 encoding of Unicode.  See [RFC2279] for
>    precise encoding and decoding rules.
> 
>    Some details of the protocol treatment depend on the type of string:
> 
>    o  For strings that are component names, any non-ASCII characters
>       MUST be represented using the UTF-8 encoding of Unicode.

As Nico pointed out, Unix variants usually do locale interpretation at
user level; the kernel just sees a byte string.  If everything is done
in a UTF-8 locale, it all works.  But I can easily create a file whose
name is encoded in ISO 8859-1, and it's the 8859-1 encoding that gets
sent over the wire.  Depending on the string, that may or might not
appear to be a valid UTF-8 string.

>    o  For strings whose form is defined by other internet standards,
>       non-ASCII characters MUST be represented using the UTF-8 encoding
>       of Unicode.  In addition other sorts of restrictions defined by
>       those standards need to be addressed.  See section 11.4 for
>       details.

I don't know if this conflicts with the Solaris implementation.  (For
example, I don't know if Solaris enforces UTF-8 for the server portion
of an entry in fs_locations.)  I can look into this some more, but
there's no longer a Section 11.4, so I'm not sure what all would need to
be checked.

mike

---

From: Nico Williams <[email-masked]>
Date: Tue, 20 Aug 2013 20:44:59 -0500

> there's no longer a Section 11.4, so I'm not sure what all would need to

I don't know of any implementation that always rejects non-UTF-8 byte
sequences in the server for every filesystem.  Solaris (well, the last
build I'm familiar with, and Illumos) can be configured on a per-ZFS
dataset (filesystem) basis to reject non-UTF-8 file names.

There's no way to make this be different.  Requiring UTF-8 till we're
blue in the face won't make things better.  New deployments can
prevent non-UTF-8 appearing on their filesystems, and that's about it.
 And, really, we should deprecate non-UTF-8 locales (but we can't) and
we should have codeset conversion at the edges where it can be done
(i.e., libc syscall stubs) (but that almost certainly won't happen).
IMO the best we can do is: recommend rejection of non-UTF-8 and
recommend the use of UTF-8 locales.

People do face this problem in the field, and using UTF-8 locales is
how they deal with it; no special code needed on the server-side.

Nico
--

---

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 21 Aug 2013 01:52:12 +0000

> there's no longer a Section 11.4, so I'm not sure what all would need to

That should be Section 12.4.

Thanks, I'll update the document!

---

From: "Noveck, David" <[email-masked]>
Date: Thu, 22 Aug 2013 13:28:35 -0400

> Depending on the string, that may or might not appear to be a valid UTF-8 string.

So, as I've said before, we can make that "MUST" a "SHOULD",  but ...

The question that I'm worried that the IESG will raise is, "How does that affect interoperability?".

Note that we also have the following in 12.5:

   Where the client sends an invalid UTF-8 string, the server SHOULD
   return an NFS4ERR_INVAL error.  This includes cases in which
   inappropriate prefixes are detected and where the count includes
   trailing bytes that do not constitute a full UCS character.

So that if the client does not obey his "SHOULD" and the server obeys
his "SHOULD", NFS4ERR_INVAL will result and users will not be happy.

So the question is whether this has turned out to be an interoperability
problem for clients, and if not, why not?  This raises the question of
whether the server SHOULD is being adhered to by most servers and 
not just a few.

My impression was that only the Linux people were opposed to the server 
"SHOULD" being a "MUST".  At least they were the only ones raising this 
as an issue.  Is it true that servers ignoring this are widespread?  I hope 
not.  I recall that Nico described this as "reasonable" and I agree.

So, can I hear from server implementers on this point?  For server appliance
vendors, this is a yes-or-no question.  For other servers, there are two questions:

      Is this check made in the NFSv4 server itself?

       If not, is it made by the FS's typically used as targets of NFSv4 access, even if
       if  not necessarily all FS's (given that this is  "SHOULD")?

-----Original Message-----
From: Mike Kupfer [mailto:[email-masked]] 
Sent: Tuesday, August 20, 2013 9:06 PM
To: Noveck, David
Cc: Nico Williams; nfsv4 list ([email-masked])
Subject: Re: [nfsv4] one more try at RFC3530 internationalization. 

> implementations out there.

I'm afraid the first bullet in 12.2 conflicts with what Solaris implements, and I suspect it conflicts with other implementations.  That section says

>       MUST be represented using the UTF-8 encoding of Unicode.

As Nico pointed out, Unix variants usually do locale interpretation at user level; the kernel just sees a byte string.  If everything is done in a UTF-8 locale, it all works.  But I can easily create a file whose name is encoded in ISO 8859-1, and it's the 8859-1 encoding that gets sent over the wire.  Depending on the string, that may or might not appear to be a valid UTF-8 string.

>       those standards need to be addressed.  See section 11.4 for

I don't know if this conflicts with the Solaris implementation.  (For example, I don't know if Solaris enforces UTF-8 for the server portion of an entry in fs_locations.)  I can look into this some more, but there's no longer a Section 11.4, so I'm not sure what all would need to be checked.

mike

---

From: Nico Williams <[email-masked]>
Date: Thu, 22 Aug 2013 12:55:37 -0500

> The question that I'm worried that the IESG will raise is, "How does that affect interoperability?".

Interoperability is with what's been deployed.

We have, in the field, a large number of shared/networked/distributed
filesystem protocols, with multi-protocol servers sharing the same
filesystems with multiple protocols.  Some clients are also
multi-protocol capable, some aren't.

We can't really ignore non-Internet filesystem protocols.

An incomplete list of those protocols includes:

 - NFSv3
 - NFSv4
 - AFS
 - AppleTalk
 - SMB/CIFS (many versions)
 - SFTP
 - Lustre

In almost all cases use of UTF-8 locales is sufficient for I18N
interop, therefore the simplest way to get I18N interop is to
RECOMMEND the use of UTF-8 locales.  The glaring exception that I know
of is HFS+, which normalizes to NFD on create, which conflicts with
the common case that input methods produce NFC, therefore users can't
type filenames that will match what's on the filesystem, but they can
nonetheless pick files using graphical filesystem navigation / file
chooser UIs.

We also have filesystems (data) that predate NFSv4 or whatever next
minor version of it.

Interoperability then requires "reject non-UTF-8" be a per-filesystem
(or even per-directory) option.  I.e., we should make this a SHOULD,
not a MUST, and explain when a client or server might fail to enforce
a given recommendation (SHOULD).

I don't want to continue this "guess what the IESG will say" game,
though I will say that IMO the IESG ought to (and almost certainly
will) accept the above (SHOULD with explanations of when the SHOULD(s)
can/should be ignored).  Instead I propose we ask, either by actually
asking, of by progressing an Internet-Draft and seeing what the IESG
does with it.

> his "SHOULD", NFS4ERR_INVAL will result and users will not be happy.

It's a SHOULD.  Interop considerations are a valid reason to not heed
this SHOULD in *specific* cases (of specific filesystems).  We should
note this.

> whether the server SHOULD is being adhered to by most servers and

Since UTF-8 locale usage is growing the impact of rejecting non-UTF-8
names is going down.

> not.  I recall that Nico described this as "reasonable" and I agree.

I oppose any "MUST reject non-UTF-8" language as well.  I would be
surprised if any implementors agreed to such a MUST.

>       Is this check made in the NFSv4 server itself?

On Solaris it's made by the *filesystem*, not the NFSv4 server, or at
least it used to be so.

>        if  not necessarily all FS's (given that this is  "SHOULD")?

Yes, this.

Caveat emptor: I am not an NFSv4 implementor.

Nico
--

---

From: "Myklebust, Trond" <[email-masked]>
Date: Thu, 22 Aug 2013 18:15:34 +0000

> So, as I've said before, we can make that "MUST" a "SHOULD",  but ...

...but we SHOULD delete the entire paragraph since it it unlikely to
ever be implemented by any of the POSIX-compatible clients or
servers. :-)

> whether the server SHOULD is being adhered to by most servers and 

Stating that the lack of UTF-8 will cause interoperability problems is
turning the entire problem on its head and takes us back to the basic
reason why we wanted to change that entire section in 3530bis.

There is nothing in the NFSv3 protocol or in POSIX that tells the server
what encoding your application is using for the filenames. As far as I
know, very few existing NFSv3 servers have enforced a particular
encoding.
However we do know that there is a large legacy base out there with NFS
served filesystems with arbitrary encodings. They dinged us when Bruce
turned on UTF-8 checking in early versions of the Linux NFSv4 server.

IOW: the true interoperability problem here would be existing servers
that want to serve up the same files to both NFSv3 and NFSv4 clients.
They will break if their NFSv3 clients create files that cannot even be
looked up by the NFSv4 clients.

> not.  I recall that Nico described this as "reasonable" and I agree.

I seem to remember Nico admitting (after a week of arguing) that the
Solaris server does not currently enforce UTF-8 encoding for NFSv4
clients. This would make sense, since as far as I know, neither the UFS
or ZFS filesystems have mechanisms to enforce a particular encoding for
applications that are running directly on the server itself.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
[email-masked]
www.netapp.com

---

From: Nico Williams <[email-masked]>
Date: Thu, 22 Aug 2013 14:29:38 -0500

> know, very few existing NFSv3 servers have enforced a particular

Because it's the *filesystem* that ends up rejecting non-UTF-8
sequences (if it does), the fact that NFSv3 says nothing about it is
irrelevant.

The protocol is not relevant to this problem.  The I18N
codeset/encoding interop problem can arise even without any remote
filesystem protocols in the picture, using purely local access on any
system with POSIX or POSIX-like interfaces.

A Solaris (or FreeBSD, or Linux, or SmartOS, or...) NFSv3 fileserver
backended by ZFS can be configured to reject non-UTF-8 filenames, and
it will.

I'm willing to bet that most (if not all) NFSv4 servers
just-use-8/just-send-8 and defer all handling of filename
codeset/encoding matters to a) the filesystems, and b) the clients.

> turned on UTF-8 checking in early versions of the Linux NFSv4 server.

It's all about the filesystems, NOT the protocol.

> that want to serve up the same files to both NFSv3 and NFSv4 clients.

NFSv3 is orthogonal (and irrelevant) to this problem.  So is NFSv4.
The only relevant information is:

 - what do the underlying filesystems do

 - what do the clients send/expect, which, in turn, really means:

 - what locales are used on the clients

There's no way to change this in the NFSv4 server stack because of the
legacy and multi-protocol issues.

We can and should RECOMMEND (SHOULD) that servers (or filesystems)
reject non-UTF-8 filenames and explain that this is in practice a
per-filesystem (or per-directory) setting.

We can and should RECOMMEND that clients do codeset/encoding
conversions where possible.  For Unix/POSIX systems that kinda means
that codeset/encoding conversions must be done at the system call stub
layer, and is not likely to get implemented (though there's no barrier
to it either), therefore we should also RECOMMEND the use of UTF-8
locales on such systems.  I don't know exactly what advice to give for
non-POSIX systems, but I suspect it should be roughly the same.

> looked up by the NFSv4 clients.

If they are all using UTF-8 locales (or all using ISO-8859-1 locales,
or ISO-8859-15, or ...) then it works out regardless of which of NFSv3
or NFSv4 (or whatever) is in use.

The protocol is NOT a factor.  Whatever RFC3530 says is irrelevant.
In practice we have:

a) clients just-use-8/just-send-8,
b) servers defer to the filesystem,

and

c) filesystems do a variety of things.

Some Solaris filesystems can be configured with "code pages" to
convert to/from.  The convention is that between the system call layer
and the VFS boundary UTF-8 should be used, so the filesystem can
convert to/from UTF-8, but this is a convention that is routinely
violated when user-land is running non-UTF-8 locales.

> applications that are running directly on the server itself.

FWIW I don't recall arguing that the Solaris server enforces UTF-8, at
least not in recent times.  (And, of course, I'm no longer familiar
with *latest* Solaris implementation details).

Nico
--

---

From: "Noveck, David" <[email-masked]>
Date: Thu, 22 Aug 2013 16:03:52 -0400

> Interoperability then requires "reject non-UTF-8" be a per-filesystem (or even per-directory) option. 
> I.e., we should make this a SHOULD, not a MUST, 

It is a SHOULD in -27.

> and explain when a client or server might fail to enforce a given recommendation (SHOULD).

Do you have some suggested text for that explanation that we could put into the next rfc3530bis draft?

> I don't want to continue this "guess what the IESG will say" game

I'm not thrilled with it either, but since we have some people who will actually be dealing with the
IESG on this issue (Martin and either Spencer or David Black as document shepherd), we have to
help them by anticipating the questions that will be asked. 

>  Interop considerations are a valid reason to not heed this SHOULD in *specific* cases (of specific filesystems).  
> We should note this.

If we can do this in a way that doesn't cause more IESG questions than it will answer, then great.

There I am again, playing the "What will the IESG say?" game.  Sigh.

> I oppose any "MUST reject non-UTF-8" language as well.  

As do I.

> I would be surprised if any implementors agreed to such a MUST.

It's not that implementers agreed to the MUST, but most did not explicitly object.  In fact,  we
had RFC3530 saying (by reference to stringprep)  that servers MUST reject any character not defined in 
Unicode 3.2  (as well as a lot of other bizarre stuff) and I didn't notice anybody objecting on the list.

-----Original Message-----
From: Nico Williams [mailto:[email-masked]] 
Sent: Thursday, August 22, 2013 1:56 PM
To: Noveck, David
Cc: Mike Kupfer; nfsv4 list ([email-masked])
Subject: Re: [nfsv4] one more try at RFC3530 internationalization.

We have, in the field, a large number of shared/networked/distributed filesystem protocols, with multi-protocol servers sharing the same filesystems with multiple protocols.  Some clients are also multi-protocol capable, some aren't.

 - NFSv3
 - NFSv4
 - AFS
 - AppleTalk

In almost all cases use of UTF-8 locales is sufficient for I18N interop, therefore the simplest way to get I18N interop is to RECOMMEND the use of UTF-8 locales.  The glaring exception that I know of is HFS+, which normalizes to NFD on create, which conflicts with the common case that input methods produce NFC, therefore users can't type filenames that will match what's on the filesystem, but they can nonetheless pick files using graphical filesystem navigation / file chooser UIs.

We also have filesystems (data) that predate NFSv4 or whatever next minor version of it.

Interoperability then requires "reject non-UTF-8" be a per-filesystem (or even per-directory) option.  I.e., we should make this a SHOULD, not a MUST, and explain when a client or server might fail to enforce a given recommendation (SHOULD).

I don't want to continue this "guess what the IESG will say" game, though I will say that IMO the IESG ought to (and almost certainly
will) accept the above (SHOULD with explanations of when the SHOULD(s) can/should be ignored).  Instead I propose we ask, either by actually asking, of by progressing an Internet-Draft and seeing what the IESG does with it.

> his "SHOULD", NFS4ERR_INVAL will result and users will not be happy.

It's a SHOULD.  Interop considerations are a valid reason to not heed this SHOULD in *specific* cases (of specific filesystems).  We should note this.

> So the question is whether this has turned out to be an 
> interoperability problem for clients, and if not, why not?  This 
> raises the question of whether the server SHOULD is being adhered to 
> by most servers and not just a few.

Since UTF-8 locale usage is growing the impact of rejecting non-UTF-8 names is going down.

> My impression was that only the Linux people were opposed to the 
> server "SHOULD" being a "MUST".  At least they were the only ones 
> raising this as an issue.  Is it true that servers ignoring this are 
> widespread?  I hope not.  I recall that Nico described this as "reasonable" and I agree.

I oppose any "MUST reject non-UTF-8" language as well.  I would be surprised if any implementors agreed to such a MUST.

> So, can I hear from server implementers on this point?  For server 
> appliance vendors, this is a yes-or-no question.  For other servers, there are two questions:
>

On Solaris it's made by the *filesystem*, not the NFSv4 server, or at least it used to be so.

Yes, this.

Nico
--

---

From: "Myklebust, Trond" <[email-masked]>
Date: Thu, 22 Aug 2013 20:17:06 +0000

> sequences (if it does), the fact that NFSv3 says nothing about it is

It's not irrelevant.

We _want_ people to be able to migrate from NFSv3 to NFSv4 and to be
able to continue to retrieve _all_ their data.

We _want_ to support legacy server installations that haven't previously
enforced any particular encoding, and can therefore have a _mixture_ of
encodings. Don't forget that in POSIX, the character encoding is part of
the locale, and is therefore per-process. It's not at all uncommon in
some workplaces to find koi-8 encoded filenames on the same volume (and
in some cases same directory) as ISO-8859-1 and cp850 filenames.

> backended by ZFS can be configured to reject non-UTF-8 filenames, and

Sure. It may break the odd POSIX application, but there would be no
problems retrieving data that has already been stored.

My problem with RFC3530 is not that it enforces a particular encoding on
new files. It's that it prevents me from accessing existing files.

> per-filesystem (or per-directory) setting.

If this is entirely up to the filesystem to enforce, then such a
recommendation would be pointless in a NFSv4 protocol document.

> non-POSIX systems, but I suspect it should be roughly the same.

No. This assumes that such a conversion is possible without any
consequences for the applications. You have not demonstrated that this
is the case.

It certainly is not possible to convert arbitrary UTF-8 names back into
an iso-8859-x encoding, for instance, which would make READDIR rather
problematic for the client to deal with.

NetApp

---

From: "Noveck, David" <[email-masked]>
Date: Thu, 22 Aug 2013 16:31:52 -0400

> My problem with RFC3530 is not that it enforces a particular encoding on new files. 
> It's that it prevents me from accessing existing files.

My problems with RFC3530 internationalization include:

a) it was never implemented.
b) there is exactly zero chance that it ever will be implemented.
c) it is totally insane.

I can understand how Martin might not want to mention c) to the IESG, but that's up to him.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Myklebust, Trond
Sent: Thursday, August 22, 2013 4:17 PM
To: Nico Williams
Cc: nfsv4 list ([email-masked])
Subject: Re: [nfsv4] one more try at RFC3530 internationalization.

On Thu, 2013-08-22 at 14:29 -0500, Nico Williams wrote:
> > Stating that the lack of UTF-8 will cause interoperability problems 
> > is turning the entire problem on its head and takes us back to the 
> > basic reason why we wanted to change that entire section in 3530bis.
> >
> > There is nothing in the NFSv3 protocol or in POSIX that tells the 
> > server what encoding your application is using for the filenames. As 
> > far as I know, very few existing NFSv3 servers have enforced a 
> > particular encoding.
> 

It's not irrelevant.

We _want_ people to be able to migrate from NFSv3 to NFSv4 and to be able to continue to retrieve _all_ their data.

We _want_ to support legacy server installations that haven't previously enforced any particular encoding, and can therefore have a _mixture_ of encodings. Don't forget that in POSIX, the character encoding is part of the locale, and is therefore per-process. It's not at all uncommon in some workplaces to find koi-8 encoded filenames on the same volume (and in some cases same directory) as ISO-8859-1 and cp850 filenames.

> backended by ZFS can be configured to reject non-UTF-8 filenames, and 

Sure. It may break the odd POSIX application, but there would be no problems retrieving data that has already been stored.

My problem with RFC3530 is not that it enforces a particular encoding on new files. It's that it prevents me from accessing existing files.

> > However we do know that there is a large legacy base out there with 
> > NFS served filesystems with arbitrary encodings. They dinged us when 
> > Bruce turned on UTF-8 checking in early versions of the Linux NFSv4 server.
> 
> > IOW: the true interoperability problem here would be existing 
> > servers that want to serve up the same files to both NFSv3 and NFSv4 clients.
> 

If this is entirely up to the filesystem to enforce, then such a recommendation would be pointless in a NFSv4 protocol document.

> non-POSIX systems, but I suspect it should be roughly the same.

No. This assumes that such a conversion is possible without any consequences for the applications. You have not demonstrated that this is the case.

It certainly is not possible to convert arbitrary UTF-8 names back into an iso-8859-x encoding, for instance, which would make READDIR rather problematic for the client to deal with.

NetApp

---

From: Nico Williams <[email-masked]>
Date: Thu, 22 Aug 2013 15:54:18 -0500

> able to continue to retrieve _all_ their data.

But you can't get them to stop using any other non-obsolete filesystem
protocol (SMB/CIFS, Lustre, WebDAV, ...).  The point is that it is the
filesystem, not the fileserver's job to deal with this[*].

[*] Mostly.  A filesystem protocol might have to deal with file path
component separators, but by and large it's the filesystem's job, not
the fileserver's.

> in some cases same directory) as ISO-8859-1 and cp850 filenames.

Correct.  I think we agree.  I'm not sure that we disagree on
anything, except, perhaps, how we should approach the IESG about this.

> problems retrieving data that has already been stored.

Ah, yes, any such rejection should be at CREATE time only.  In all
other cases (LOOKUP, READDIR), the server should just-send-8, and the
client should just-take-8.

It might well be useful to have properties for advertising whether a
filesystem is UTF-8 clean, but clients won't need this.  A filesystem
that uses some non-Unicode, non-ASCII codeset can be expected and
required to convert to UTF-8.

The convention should be: on the wire NFSv4 expects UTF-8, but if you
just-send-8 then interop is dependent on a) filesystem configuration,
b) client configuration, both at layers other than the NFSv4 server or
client stacks.

> new files. It's that it prevents me from accessing existing files.

I don't recall the exact wording, but I agree that that would be a bad result.

> recommendation would be pointless in a NFSv4 protocol document.

Not entirely.  Suppose you have a filesystem known to only handle
SHIFT-JIS or some such.  The fileserver *could* know to convert
to/from that and UTF-8, and that would be the correct thing to do.
But if either the filesystem enforces UTF-8 only or it's just-use-8,
then there's nothing for the fileserver to do.  Additionally, advice
to *filesystem* implementors could be given in an Internet RFC, and
arguably we should do that since... we have the experience to share
and advice to give.

> consequences for the applications. You have not demonstrated that this

Such an implementation would depend on reliably implementing a "UTF-8
in the middle" convention.  If one fails to, then one will have
interop problems... not much different than the interop problems one
already has.

I think the right thing to do would be to make libc syscall stub
filename codeset conversion configurable.  In the absence of such
stubs, or when conversions are disabled, the only way to get interop
is to use locales with the same codeset consistently across all
relevant clients.

> problematic for the client to deal with.

Indeed, but whatever codeset you're using in the client process'
locale, you can get invalid (semantically or otherwise) filenames.
It's not a question of whether conversions are done or attempted
somewhere, but whether you have mixed codeset filesystem metadata
contents.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 22 Aug 2013 17:10:28 -0500

> I can understand how Martin might not want to mention c) to the IESG, but that's up to him.

Our collective fear of conflict with the IESG is not exactly reasonable
either.  For one, they might easily observe these threads, so not
writing our preferred I-D text isn't shielding them from that preferred
text.  More than that, not telling them about reality would be a very
bad thing if indeed their expectations are not realistic.  The NFSv4 WG
is chartered in the IETF -- dealing with the IESG is a requirement.

Let's write the text we believe is correct.  We all seem to be close to on
the same page on this.  My proposal (but someone wordsmith it) follows.
I think this may be something we want to separate into an RFC that is not
specific to NFSv4, as it's really NOT specific to NFSv4.

   For legacy and multi-protocol interoperability reasons we cannot
   enforce the use of Unicode.  In order to improve internationalization
   and interoperability we make the following statements of assumptions,
   recommendations, and requirements:

    o We assume that NFSv4 servers may share more than one filesystem
      and that some filesystems may contain legacy filesystem object
      names that use different codesets.

    o We assume that clients generally send UTF-8, with no particular
      normalization form, using codepoints from whatever Unicode version
      they implement.

    o We RECOMMEND that filesystems (note: not fileservers) be
      configurable as to whether to permit or reject non-UTF-8
      filesystem object names at create time.  We RECOMMEND that
      filesystems default to rejecting non-UTF-8 filesystem object
      names at create time.

    o If a filesystem is known to use a specific non-Unicode codeset, or
      a Unicode encoding other than UTF-8, then the NFSv4 server sharing
      such a filesystem MUST convert to/from the filesystem's
      codeset/encoding and UTF-8.

      That is, we assume UTF-8 is used "in the middle"; any conversions
      to/from UTF-8 are to be done at the edge, where there exists
      knowledge of what codeset is in use on both sides of that edge.
      On the NFSv4 server-side the edge is the filesystem.

      On the other hand, if a filesystem is not known to use any one
      codeset/encoding (or the NFSv4 is not told), then the NFSv4 server
      MUST treat filesystem object names as opaque 8-bit clean octet
      strings (see next item in this list).

    o NFSv4 servers MUST handle arbitrary 8-bit-clean octet strings for
      filesystem object names on lookup and directory read operations,
      and MUST pass them to/from NFSv4 clients as-is, unmodified in any
      way.

    o We RECOMMEND that clients implement codeset/encoding conversions
      at their "edge".  For some client implementations the edge may be
      in a component other than the NFSv4 client proper (e.g., at the
      user-mode side of the system call layer).

      This is an important consideration: many NFSv4 client
      implementations are (or are effectively as good as) external
      components plugged in to larger operating systems.  It may not be
      possible for such an NFSv4 client implementation to ensure
      internationalization interoperability as it will likely have no
      knowledge of what codeset/encoding the user's application are
      using or expect -- in this case the NFSv4 client implementation is
      part of the "middle".  Locally rejecting non-UTF-8 is not an
      appropriate behavior for this specification to require, as doing
      so necessarily precludes NFSv4 interoperability to access "legacy"
      filesystem contents.

    o We recommend (note: not RFC2119 RECOMMEND) that users and/or
      operating system implementors use UTF-8 locales exclusively to
      ensure internationalization interoperability across multiple
      remote filesystem sharing protocols.  We also recommend that users
      convert filesystem object names to UTF-8 in filesystems that have
      non-UTF-8, non-ASCII filesystem object names.

   Note that we do not require nor recommend any profile of Unicode
   string preparation [RFC3454].  Individual filesystems may implement
   one or another Unicode string preparation profile.

   Note that there are interoperability problems related to Uniode
   normalization.  NFSv4 servers may not be in a position to address
   these, as, once more, filesystems may be external components.  To
   address this we RECOMMEND that filesystems implement one of the
   following options:

   1) Normalize on CREATE and, optionally, on LOOKUP.

      It is best to normalize to NFC in this case as most input modes
      output Unicode in NFC (or close enough).  [Add references?
      I've never seen any Unicode input mode documentation
      stating what Unicode form is used for its output.]

      No normalization is needed on READDIR.

   2) Normalization-insensitive LOOKUP / normalization-preserving
      CREATE.

      No normalization is needed on READDIR.

      Note that this option has an aliasing problem with a security
      consideration: applications which implement authorization by
      testing the existence of objects by name may be fooled by users
      who can create objects with aliases of those names.

   Each of these options can be said to conflict with POSIX [add
   reference to POSIX] [add rationales for how each of (1) and (2)
   do/might conflict with POSIX].  Both are likely to result in
   internationalization interoperability, though (1) depends on the
   filesystem and the Unicode input modes in use producing the same
   Unicode normal form.

   There exist filesystems that normalize on CREATE only; one normalizes
   to NFD [add reference to HFS+].

   There exist filesystems that support normalization-insensitive LOOKUP
   [add reference to ZFS].

What do you think?

Nico
--

---

From: "Myklebust, Trond" <[email-masked]>
Date: Fri, 23 Aug 2013 00:12:24 +0000

>    There exist filesystems that support normalization-insensitive LOOKUP

I think that if we recommend normalisation on CREATE but not LOOKUP,
then that will cause problems for a number of applications. Operations
like mknod, mkdir, makedev, mkfifo, ... all create objects on the
filesystem, but don't automatically open them for you. It is therefore
easy to imagine an application that tries to make a filesystem object
such as a directory or fifo, and then can't figure out how to open/use
that object because LOOKUP won't find the original name; only the
normalised name.

If you normalise on CREATE, I therefore think you should normalise on
LOOKUP (and OPEN, LINK, RENAME, REMOVE, ...) too. However if there is a
chance that your filesystem could store anything that is not normalised,
then the option to normalise on the NFS server is an obvious no-go.

NetApp

---

From: Nico Williams <[email-masked]>
Date: Thu, 22 Aug 2013 19:18:01 -0500

Fundamentally, we can only do codeset/encoding conversions at the
boundaries where we have knowledge of what codesets/encodings are used
on both sides of those boundaries.  We can only avoid the need for
such conversions by using Unicode everywhere, but this is really not
an option.

We'd *like* the only such boundary in NFSv4 to be "the wire", but the
reality is that the actual boundaries are:

 - the VFS/filesystem boundary (on the server side)
 - the user-mode/kernel-mode system call boundary (on the client)

Those are not the boundaries for the NFSv4 client nor server.  On the
server-side we can at best consider the VFS part of the server and
then we can consider that a boundary (VFS/filesystem) to be one of the
NFSv4 server's boundaries.  On the client side there's not really
anything we can do to get the NFSv4 stack involved.

We can define "NFSv4 client" and "NFSv4 server" to encompass the real
boundaries listed above, but that's not realistic for implementors.

We can do things like normalization and stringprep, but the only
natural place to do those is at the filesystem.  It helps to think of:

 - query strings (strings sent by clients)
 - display strings (strings sent back by servers)
 - storage strings (strings stored by the servers)

There's no need to normalize/prep query strings, especially not if the
server would do it anyways.  There's no need for the client to
normalize display strings either -- they are as they are.  But the
filesystems have to (well, not *have* to, but should) do something
about matching query strings to storage strings and about producing
storage strings.  Therefore any normalization/stringprep
considerations belong squarely in the filesystem.  For an
implementation where the "NFSv4 server" and "filesystem" are very
closely coupled there's no real distinction, but generally that's not
the case.

We need well-defined terms that allow us to refer to entire stacks and
portions of them with precision, so as to avoid confusion when we
specify the I18N aspects of NFSv4.

I would challenge anyone to describe an I18N interop scheme that does
not involve specifying boundaries as above and does not involve
requiring Unicode everywhere (i.e., deprecate non-Unicode locales) to
avoid the need for such boundaries.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 22 Aug 2013 19:21:29 -0500

> then the option to normalise on the NFS server is an obvious no-go.

Right, if you normalize on CREATE you also have to on LOOKUP.
READDIRs may not match caller/client expectations, which is how
normalize-on-create breaks POSIX.

Normalization-insensitive LOOKUPs are no more problematic than
case-insensitive LOOKUPs, and actually somewhat less so (but note the
security consideration in my proposed text).  And if n-i LOOKUPs break
POSIX, it's in exactly the same way that c-i LOOKUPS would/do.

This is why ZFS implements normalization-insensitive behavior rather
than normalize-on-CREATE.

Nico
--

---

From: "Myklebust, Trond" <[email-masked]>
Date: Fri, 23 Aug 2013 00:25:18 +0000

> avoid the need for such boundaries.

Then with the above language, I will restate my previous argument as such:

"query strings must match storage strings, otherwise you have an application-visible problem."

Cheers
  Trond

---

From: Nico Williams <[email-masked]>
Date: Thu, 22 Aug 2013 19:55:44 -0500

> "query strings must match storage strings, otherwise you have an
application-visible problem."

That means you can't normalize at all, anywhere other than the
application.  That may be a fine conclusion, but it too fails to describe
reality.  If we distinguish query strings in the context of CREATE vs.
LOOKUP we can get back to normalize on CREATE (and LOKUP) vs n-i LOOKUP.  I
think all the are reasonable options for users, with n-i being the most
transparently interoperable.  (Back when Apple was considering using ZFS
they changed it to match HFS+ behavior, and this was noticed when it broke
git.  So we know that normalize on CREATE, at least when normalizing to
NFD, is not terribly interoperable, but ZFS has been using n-i LOOKUPS for
years without trouble, so we know n-i interops well enough!)

---

From: "Myklebust, Trond" <[email-masked]>
Date: Fri, 23 Aug 2013 01:10:15 +0000

On Thu, 2013-08-22 at 19:55 -0500, Nico Williams wrote:
> 
> On Aug 22, 2013 7:25 PM, "Myklebust, Trond"
> application.  That may be a fine conclusion, but it too fails to
> describe reality.  If we distinguish query strings in the context of
> CREATE vs. LOOKUP we can get back to normalize on CREATE (and LOKUP)
> vs n-i LOOKUP.  I think all the are reasonable options for users, with
> n-i being the most transparently interoperable.  (Back when Apple was
> considering using ZFS they changed it to match HFS+ behavior, and this
> was noticed when it broke git.  So we know that normalize on CREATE,
> at least when normalizing to NFD, is not terribly interoperable, but
> ZFS has been using n-i LOOKUPS for years without trouble, so we know
> n-i interops well enough!)

The change in language didn't help? My point was a very general one: if
your application can't save the string that was used for the CREATE, and
reuse it for a LOOKUP/OPEN of the same object, then your storage design
is fundamentally broken.

If NFSv4 can't get that right, then we should disband the WG.

NetApp

---

From: Nico Williams <[email-masked]>
Date: Thu, 22 Aug 2013 20:42:36 -0500

> If NFSv4 can't get that right, then we should disband the WG.

Ah, forgive me.  Yes, that's fair, and n-i LOOKUP works.

---

From: Mike Kupfer <[email-masked]>
Date: Fri, 23 Aug 2013 11:55:25 -0700

> Since UTF-8 locale usage is growing the impact of rejecting non-UTF-8

I have not heard of component encoding being an interoperability issue
for Solaris.

As to why it's not a problem, as Nico notes, we are surely benefiting
from the increased use of UTF-8 locales.  Also, I suspect that most NFS
usage is within a given domain (site or organization), and that most of
the systems within that domain use, if not UTF-8, compatible encodings.
Or if the encodings are incompatible (e.g., 8859-1 versus 8859-2), users
have learned to work around the resulting glitches.

Do we do any i18n-related testing at BATs or Connectathon?

> On Solaris it's made by the *filesystem*, not the NFSv4 server, or at

Right, I don't see any UTF-8 enforcement in the NFS layer.  ZFS has a
per-fs option to validate a component name as UTF-8.  It's disabled by
default in Solaris.  UFS does not appear to have any UTF-8 checks.

mike

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 23 Aug 2013 15:14:52 -0400

> specific to NFSv4, as it's really NOT specific to NFSv4.

How does any of this help NFSv4 implementors?  How many of these
recommendations fix actual problems that any of us have seen?

>       filesystems default to rejecting non-UTF-8 filesystem object

OK to those three, I guess, don't know how useful this is.

>       codeset/encoding and UTF-8.

Does any implementation do this?  How would an implementation that
previously has not done this (e.g. the Linux and, I'm guessing, Solaris
servers) turn this on without users suddenly seeing filenames change?

>       and MUST pass them to/from NFSv4 clients as-is, unmodified in any

Pass them between NFSv4 clients and what?  The filesystem?  I don't know
how to apply this statement to an appliance where everything below the
protocol level may be a black box.

I ran out of steam here.

The less internationalization language the better, is my only
request....

--b.

---

From: Mike Kupfer <[email-masked]>
Date: Fri, 23 Aug 2013 12:17:44 -0700

Nico Williams wrote:

> My proposal (but someone wordsmith it) follows.

I'll point out that this proposal is focused on component strings.  I
don't mean this to detract from the proposal, just to point out that
there are other pieces of the internationalization puzzle that we need
to work out, too (e.g., domains and host names).

>       codeset/encoding and UTF-8.

I don't know about MUST here.  I'm not an expert in natural languages,
but I've been told that for some codesets, you cannot safely do a
roundtrip conversion from the codeset to UTF-8 then back to the original
codeset.  (I assume this means that there are multiple code points in
the original codeset that map to a single UTF-8 code point.)  This issue
may be more important for file content than names, but I'd be hesitant
to use MUST before we fully understand all the issues.

mike

---

From: Nico Williams <[email-masked]>
Date: Fri, 23 Aug 2013 14:35:33 -0500

Let's look:

>>    [...]

Solaris can convert to/from various codepages for, IIRC, FAT
filesystems.  Granted, this happens in the filesystem, not in the
NFSv4 server, so you're right, this requirement is not really
appropriate.  But the location of boundaries between "NFSv4 server",
"VFS", and "filesystem" is rather implementation-specific, so the
requirement should stay somehow, but it could be re-worded.

I should remove that requirement and instead add text about boundaries
where I18N tasks are necessary, then explain that NFSv4
implementations only need to perform such tasks when they happen to
reach one of those boundaries.

> protocol level may be a black box.

Yes, the filesystem.  It just means that filenames should be treated
as opaque, except (see above) when the server specifically knows that
it has to do some conversion at an implementation-internal boundary
where the only thing that can be done to improve I18N interop is to
assume UTF-8 on the NFSv4-server side of that boundary.

In the case of an implementation like Solaris (and many others,
probably also *BSD, Linux, ...) the above translates into "treat
filenames as opaque; apply no conversions".

> The less internationalization language the better, is my only

I'm trying to minimize it.  We can't have zero I18N language.  We
could separate the I18N language into a separate RFC on account of
"it's not really specific to NFSv4" (for the implementations I know
it's not at all specific to NFSv4!).  But NFSv4 would still have to
reference it.

Do you really think the text I proposed is not an improvement over
RFC3530?  What's objectionable?  Its effect happens to be to remove
the need for *any* I18N code in NFSv4 clients and servers that I'm
familiar with!  It moves the responsibility for I18N to other places.
It may be a lot of text (I don't think so, but you should judge that),
but it's effect is exactly what -I think- you want: no I18N code in
NFSv4 implementations.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 23 Aug 2013 14:41:48 -0500

> to work out, too (e.g., domains and host names).

Yes, I knew this, but I thought we should tackle that first and get to
user/group names and such later.

I think I should re-cast this text as a boundary analysis and specify
requirements/recommendations for components at those boundaries,
noting that most NFSv4 implementations don't reach those boundaries
(therefore there's nothing for them to do).

> to use MUST before we fully understand all the issues.

The impossibility of some round-tripping is an interesting problem
that I'd rather punt on by allowing the implementation to address that
as it wishes (e.g., punycode things) or by referencing some other spec
that addresses that.  Some conversions round-trip just fine (e.g.,
Unicode encoding conversions, like UTF-8<->UTF-16).

But I do need to re-word that requirement in the context of boundary
analysis text, because in common implementations that requirement
wouldn't affect the NFSv4 stack at all because the NFSv4 server does
not interact directly with the filesystem (there being a VFS in
between).  As it is that requirement is distracting (see Bruce's
response and my reply).

Nico
--

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 23 Aug 2013 15:44:08 -0400

> reach one of those boundaries.

Why (here and below) are we talking about implementation internals at
all?

--b.

---

From: Nico Williams <[email-masked]>
Date: Fri, 23 Aug 2013 15:07:26 -0500

> Why (here and below) are we talking about implementation internals at

Because we can only do things like "normalize" or "re-encode" at
appropriate boundaries.  Those boundaries require identification.  It
is perfectly legitimate to design/implement NFSv4 in such a way that
it never reaches those boundaries -- this is particular appealing a
design when one is implementing a node that speaks multiple remote
filesystem protocols, in which case no requirements we specify (at
least for filenames) will affect the NFSv4 portion of such an
implementation.

We don't need to actually speak of "VFS" in normative text (whether
it's appropriate to speak of "VFS", "process", "system call",
"user-mode", and so on in an RFC is a separate topic), but I don't
think we can't require that every NFSv4 implementation reach all those
boundaries where I18N tasks can be performed -- I for one would
object, and I suspect so would most participants here.

Let me ask you this: what do you want the net result to be?  You've
said something along the lines of minimal I18N language, but that's
not useful feedback: I don't know how to address it.

At some point the rubber meets the road, where that happens in *your*
implementation, what do you think should happen w.r.t. I18N?  My guess
is that "nothing" will almost certainly fail at the IESG and IETF, but
"my implementation does not reach any such boundaries, therefore
there's nothing for my implementation to do" should work out fine as
long as systemic recommendations/requirements are still stated.  I'm
proposing the latter.

Clearly, some implementors would have to address "systemic" I18N
recommendations/requirements (e.g, Solaris and Illumos derivatives
implementors), while some could punt/dispatch each point to a
different responsible party (e.g., Linux, where on the client side an
NFSv4 implementor could punt to glibc, and an NFSv4 server implementor
could punt to the individual filesystems).  That seems like a
reasonable outcome, and anyways, it reflects reality.  (Even Linux
with ZFS-on-Linux matches what I've described Solaris does for I18N!)

Nico
--

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 23 Aug 2013 16:36:41 -0400

> least for filenames) will affect the NFSv4 portion of such an

I don't really understand what we're talking about now, so I'll drop
out.

I'll do my best to review any specific language.  It would be helpful to
me if it was clear exactly which language is intended for 3530bis and
which for some other document.

--b.

---

From: "Noveck, David" <[email-masked]>
Date: Fri, 23 Aug 2013 16:59:41 -0400

> My point was a very general one: if your application can't save the string that was used for the CREATE, 
> and reuse it for a LOOKUP/OPEN of the same object, then your storage design is fundamentally broken.

Agreed.

Now look at the last paragraph of section 12.3 of -27.   As I read it, it gives the server four options, which
all meet your criterion, assuming that the client just leaves well enough alone as far as normalization.

The choices (allowed by "MAY" language) are:

      No server normalization.

     Server normalizes to NFC but doesn't reject unnormalized strings.

     Server normalizes to NFD but doesn't reject unnormalized strings.

    Server does normalization-insensitive LOOKUP's.

So the good news (at least I think it's good) is that the group can go on.

> If NFSv4 can't get that right, then we should disband the WG.

Gee.  I'm surprised it's not a "MUST" :-)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Myklebust, Trond
Sent: Thursday, August 22, 2013 9:10 PM
To: Nico Williams
Cc: nfsv4 list ([email-masked])
Subject: Re: [nfsv4] one more try at RFC3530 internationalization.

> n-i interops well enough!)

The change in language didn't help? My point was a very general one: if your application can't save the string that was used for the CREATE, and reuse it for a LOOKUP/OPEN of the same object, then your storage design is fundamentally broken.

NetApp

---

From: Nico Williams <[email-masked]>
Date: Fri, 23 Aug 2013 16:08:26 -0500

> The choices (allowed by "MAY" language) are:

With a note describing how users can cope.

>      Server normalizes to NFD but doesn't reject unnormalized strings.

These are on CREATE.  I think such servers should/must also normalize
on LOOKUP, else -> bad user experience.

>     Server does normalization-insensitive LOOKUP's.

Yes.

> So the good news (at least I think it's good) is that the group can go on.

:)

---

From: "Noveck, David" <[email-masked]>
Date: Fri, 23 Aug 2013 20:01:33 -0400

> With a note describing how users can cope.

What problem do you see users having to cope with?

> These are on CREATE.  I think such servers should/must also normalize on LOOKUP, else -> bad user experience

I don't read it that way:

>   Server implementations MAY normalize file names to conform to a
>   particular normalization form before using the resulting string when
>   looking up or creating a file.

It certainly doesn't say just CREATE.

I suppose someone might interpret the "MAY ... looking up or creating" to mean that he may 
make different choices for different operations.

How about:

>   Server implementations MAY normalize file names to conform to a
>   particular normalization form before using the resulting string when
>  looking up or creating a file, as long as the same choice (as to whether
>  to normalize and which normalization form to use) is always made for 
>  all operations in the same filesystem.

Sigh!

-----Original Message-----
From: Nico Williams [mailto:[email-masked]] 
Sent: Friday, August 23, 2013 5:08 PM
To: Noveck, David
Cc: Myklebust, Trond; nfsv4 list ([email-masked])
Subject: Re: [nfsv4] one more try at RFC3530 internationalization.

>      Server normalizes to NFD but doesn't reject unnormalized strings.

These are on CREATE.  I think such servers should/must also normalize on LOOKUP, else -> bad user experience.

Yes.

:)

---

From: Nico Williams <[email-masked]>
Date: Fri, 23 Aug 2013 20:12:05 -0500

> What problem do you see users having to cope with?

The presence of multiple objects with equivalent names where
uniqueness is expected.

Also, the inability to type a name that matches an object's name as
shown in a directory listing.

> I don't read it that way:

OK, sure, if the option is that the server always normalizes file
names sent by the client.

Nico
--

---

From: Mike Kupfer <[email-masked]>
Date: Sun, 25 Aug 2013 17:21:19 -0700

> user/group names and such later.

Okay, that sounds like a reasonable approach.

mike

---

From: Mike Kupfer <[email-masked]>
Date: Sun, 25 Aug 2013 17:48:12 -0700

Nico Williams wrote:

> Let me ask you this: what do you want the net result to be?  

Here's my take on what the i18n section should cover, at least for
component names:

1. It should describe what is needed to interoperate with existing
   implementations.  That would include things like "if you don't
   know how the string is encoded, just pass it through".

   If we don't know of any implementations that actually do conversions
   to/from UTF-8, we should be skeptical about suggesting a conversion,
   even as a MAY.  That is, we should refrain from language that
   encourages implementations to change what they send over the wire,
   unless it's needed to address a problem that people are actually
   running into.

2. Some sort of discussion about the whole ecosystem seems okay, perhaps
   unavoidable.

   I like your idea of describing things in terms of the system
   boundaries.  But the description needs to be simple and concrete
   enough that people can wrap their heads around it.  If it's too
   general or abstract, it'll be too hard to understand.
   
mike

---

From: "Noveck, David" <[email-masked]>
Date: Mon, 26 Aug 2013 12:55:00 -0400

I understand that there are lots of things people might like to see, but right now I'd like people to 
focus on chapter 12 of draft-ietf-nfsv4-rfc3530bis-27.  If you have specific changes that you'd
like to see in future drafts, please suggest the wording changes you want.  On the other hand, 
if you don't think this is a reasonable basis to go forward with in the rfc3530bis time frame, please 
say so and draft a replacement chapter. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Kupfer
Sent: Sunday, August 25, 2013 8:48 PM
To: Nico Williams
Cc: J. Bruce Fields; Myklebust, Trond; nfsv4 list ([email-masked])
Subject: Re: [nfsv4] one more try at RFC3530 internationalization.

> Let me ask you this: what do you want the net result to be?  

Here's my take on what the i18n section should cover, at least for component names:

   
mike

---

From: Mike Kupfer <[email-masked]>
Date: Tue, 27 Aug 2013 10:12:35 -0700

Noveck, David wrote:

> I understand that there are lots of things people might like to see,
> but right now I'd like people to focus on chapter 12 of
> draft-ietf-nfsv4-rfc3530bis-27.  If you have specific changes that
> you'd like to see in future drafts, please suggest the wording changes
> you want.  On the other hand, if you don't think this is a reasonable
> basis to go forward with in the rfc3530bis time frame, please say so
> and draft a replacement chapter.

Okay, I'll work on some specific replacement text.  It may take a few
weeks, as I will have to juggle this with other tasks.

mike