[nfsv4] comment w.r.t. fs_charset_cap in draft-ietf-nfsv4-internationalization-03

[Rick Macklem <[e-mail]>]

Hi,

I don't think I completely agree with this paragraph in the draft:

      With regard to the flag FSCHARSET_CAP4_CONTAINS_NON_UTF8, it has
      proved impossible to determine, from existing treatments of this
      attribute, any value that might be helpful here.  As a result, we
      are forced to assume that this flag is always a complement of
      FSCHARSET_CAP4_ALLOWS_ONLY_UTF8 and that any result in which it is
      not so is to be ignored, with the appropriate handling being the
      same as would apply if the attribute were not supported.

I believe that is possible to have a server that would return a
fs_charset_cap4 == 0 (ie neither flag set).
- Such a server would allow non-UTF8 component names.
- There are no non-UTF8 file names in the server's directory tree.

Now, whether or not this case is useful to a client is questionable,
but it does seem to be possible to have neither flag set.
(I, personally, would have preferred the following wording for the
 two flags, but I'd guess that would be a change in semantics not
 allowed for this document?)

For the first flag:
     The first
      flag is FSCHARSET_CAP4_CONTAINS_NON_UTF8, which, if set to one,
      tells the client that the file system contains non-UTF-8
--> I would have preferred "might contain" instead of "contains" since,
       as you note, a file system is unlikely to keep track of the count of
       non-UTF8 file name components and flip this bit based on that count.

For the second flag:
     The second flag is FSCHARSET_CAP4_ALLOWS_ONLY_UTF8, which, if set
      to one, indicates that the server will accept (and generate) only
      UTF-8 characters on the file system.
--> I would have preferred this without the "(and generate)" since that is
       what the FreeBSD server can optionally do. It either does the first flag
       or it checks for UTF-8 for component name arguments, but allows non-UTF8
       names in replies to Readdir, etc.
       --> This was my interpretation of RFC3530 long ago, w.r.t. checking for UTF-8
              component names.
Put another way, the FreeBSD server can optionally be configured to not allow the
Lookup/Open.. of non-UTF8 component names, but they could exist in the file system
via NFSv3 or local POSIX open(O_CREAT) and they will be in a Readdir reply.
(This might be my mis-interpretation of RFC3530, but since you have been interested
 in extant implementations...)

The FreeBSD server does not implement the fs_charset_cap attribute, btw.

rick