Subject: [nfsv4] NFSv4 I18n string type summary

From: <[email-masked]>
Date: Thu, 29 Jul 2010 17:15:30 -0400

David Black asked me to provide information on all the i18n-related
types in NFSv4.  It turns out that there is a section devoted to that
very purpose in draft-ietf-nfsv4-rfc3530bis-04.txt.  It is section 12.2
and starts on page 164.  The draft only expires on January 8, 2011 so is
available until that time or until a revision is published (I'm guessing
something like three months from now).

I've reproduced the text (minus heading crap) below and will try to give
people a brief summary of the summary here.  It will not fit in 144
characters, however.

There are a number of types of strings which are combinations of other
type such as users and groups which are the form principal@domain.
There is some preliminary processing defined for such types that defines
how to break these up into other types.  These mixture type will not be
further discussed here.  See table 6 in section 12.2 below.

Aside from these there are three classes of string types to deal with.

First are those that there is some existing internet specification on
which handling can be based.  Life is good.

+-----------------+----------------------------------------------------+
| Type            | Explanation and Discussion                         |
+-----------------+----------------------------------------------------+
| svrname4        | Server name as returned by server.  Not sent by    |
|                 | client, except in VERIFY/NVERIFY.  Handled by      |
|                 | IDNAbis rules with A-labels and UTF-8 strings      |
|                 | all allowed.                                       |
| prinsfx4        | Suffix part of principal, in the form of a domain  |
|                 | name.  Handled by IDNAbis rules with A-labels and  |
|                 | UTF-8 strings all allowed.                         |

+-----------------+----------------------------------------------------+

Next are the more troublesome and ideologically contentious types where
the issue is basically that we are communicating with entities that
exist and that we, in general, cannot change.  In the case of component
names and link text strings they are the file system, while in the case
of the principal names, it is whatever mechanism the implementations
have agreed upon to map between names and numeric ids.  We are
communicating with the file system which has its own rules for name
processing.  This makes a directive approach whereby the details of all
string processing are to be specified a non-starter.  I perceive some
reluctance to accept this fact and proceed in that light.

+-----------------+----------------------------------------------------+
| Type            | Explanation and Discussion                         |
+-----------------+----------------------------------------------------+
| component4      | Should be utf8 but clients may need to access file |
|                 | systems with a different name structure, possibly  |
|                 | including non-utf8 names.                          |
| linktext4       | Should be utf8 since text may include name         |
|                 | components. Because of the need to access existing |
|                 | existing file systems, this check may be inhibited.|
| prinpfx4        | Must match one of a list of valid users or groups  |
|                 | for that particular domain.                        |
+-----------------+----------------------------------------------------+

Finally, the following types, even though nominally UTF-8, have for
various no i18n-related processing defined in the protocol.

+-----------------+----------------------------------------------------+
| Type            | Explanation and Discussion                         |
+-----------------+----------------------------------------------------+
| comptag4        | Tags are debugging strings that are in the protocol|
|                 | for the purpose of helping protocol debugging.     |
|                 | There is no specification as to what should be in  |

|                 | They are defined as UTF-8 but are not validated for|

|                 | UTF-8 correctness by the receiver.  What would you |
|                 | do if it is wrong?                                 |
+-----------------+----------------------------------------------------+
| fattr4_mimetype | All mime types are validated by comparing them     |
|                 | against a fixed list, all of whose members consist |
|                 | only of ascii characters, making other i18n-related|

|                 | processing unnecessary.                            |
+-----------------+----------------------------------------------------+
| svraddr4        | Denotes something already validated as an IP       |
|                 | address, whether IPv4 or IPv6, which means it has  |
|                 | to be all ascii.                                   |
+-----------------+----------------------------------------------------+

------------------------------------------------------------------------

12.2.  String Type Overview

12.2.1.  Overall String Class Divisions

   NFS version 4 has to deal with with a large set of diffreent types of
   strings and because of the different role of each,
   internationalization issues will be different for each:

   o  For some types of strings, the fundamental internationalization-
      related decisions are the province of the file system or the
      security-handling functions of the server and the protocol's job
      is to establish the rules under which file systems and servers are
      allowed to exercise this freedom, to avoid adding to confusion.

   o  In other cases, the fundamental internationalization issues are
      the responsibility of other IETF groups and our jobis simply to
      reference those and perhaps make a few choices as to how they are
      to be used (e.g.  U-labels vs. A-labels).

   o  There are also cases in which a string has a small amount of NFS
      version 4 processing which results in one or more strings being
      referred to one of the other categories.

   We will divide strings to be dealt with into the following classes:

   MIX  indicating that there is small amount of preparatory processing
      that either picks an appropriate modes of internationalization
      handling or divides the string into a set of (two) strings with a
      different mode internationalization handling for each.  The
      details are discussed in the section "Types with Pre-processing to
      Resolve Mixture Issues".

   NIP  indicating that, for various reasons, there is no need for
      internationalization-specific processing to be performed.  The
      specifics of the various string types handled in this way are
      described in the section "String Types without
      Internationalization Processing".

   INET  indicating that the string needs to be processed in a fashion
      is goverened by non-NFS-specific internet specifications.  The
      details are discussed in the section "Types with Processing
      Defined by Other Internet Areas".

   NFS  indicating that the string needs to be processed in a fashion is
      goverened by NFSv4-specific consideration.  The primary focus is
      on enabling flexibility for the various file systems to be
      accessed and is described in the section "String Types with NFS-
      specific Processing".

12.2.2.  Divisions by Typedef Parent types

   There are a number of different string types within NFS version 4 and
   internationalization handling will be different for different types
   of strings.  Each the types will be in one of four groups based on
   the parent type that specifies the nature of its relationship to utf8
   and ascii.

   utf8_should/SHOULD:  indicating that strings of this type should be
      UTF-8 but clients and servers will not check for valid UTF-8
      encoding.

   utf8val_should/VSHOULD:  indicating that strings of this type should
      be and generally will be in the form of the UTF-8 encoding of
      Unicode.  Strings in most cases will be checked by the server for
      valid UTF-8 but for certain file systems, such checking may be
      inhibited.

   utf8val_must/VMUST:  indicating that strings of this type must be in
      the form of the UTF-8 encoding of Unicode.  Strings will be
      checked by the server for valid UTF-8 and the server should ensure
      that when sent to the client, they are valid UTF-8.

   ascii_must/ASCII:  indicating that strings of this type must be pure
      ASCII, and thus automatically UTF-8.  The processing of these
      string must ensure that they are only have ASCII characters but
      this need not be a separate step if any normally required check
      for validity inherently assures that only ASCII characters are
      present.

12.2.3.  Individual Types and Their Handling

   The first table outlines the handling for the primary string types,
   i.e. those not derived as a prefix or a suffix from a mixture type.

   +-----------------+---------+-------+-------------------------------+
   | Type            | Parent  | Class | Explanation                   |
   +-----------------+---------+-------+-------------------------------+
   | comptag4        | SHOULD  | NIP   | Should be utf8 but no         |
   |                 |         |       | validation by server or       |
   |                 |         |       | client is to be done.         |
   | component4      | VSHOULD | NFS   | Should be utf8 but clients    |
   |                 |         |       | may need to access file       |
   |                 |         |       | systems with a different name |
   |                 |         |       | structure. files systems with |
   |                 |         |       | non-utf8 names.               |
   | linktext4       | VSHOULD | NFS   | Should be utf8 since text may |
   |                 |         |       | include name components.      |
   |                 |         |       | Because of the need to access |
   |                 |         |       | existing file systems, this   |
   |                 |         |       | check may be inhibited.       |
   | fattr4_mimetype | ASCII   | NIP   | All mime types are ascii so   |
   |                 |         |       | no specific utf8 processing   |
   |                 |         |       | is required, given that you   |
   |                 |         |       | are comparing to that list.   |
   +-----------------+---------+-------+-------------------------------+

                                  Table 5

   There are a number of string types that are compound in that they may
   consist of multiple conjoined strings with different utf8-related
   processing for each.

   +---------+--------+-------+----------------------------------------+
   | Type    | Parent | Class | Explanation                            |
   +---------+--------+-------+----------------------------------------+
   | prin4   | VMUST  | MIX   | Consists of two parts separated by an  |
   |         |        |       | at-sign, a prinpfx4 and a prinsfx4.    |
   |         |        |       | These are described in the next table. |
   | server4 | VMUST  | MIX   | Is either an IP address (serveraddr4)  |
   |         |        |       | which has to be pure ascii or a server |
   |         |        |       | name svrname4, which is described      |
   |         |        |       | immediately below.                     |
   +---------+--------+-------+----------------------------------------+

                                  Table 6

   The last table describes the components of the compound types
   described above.

   +----------+-------+------+-----------------------------------------+
   | Type     | Class | Def  | Explanation                             |
   +----------+-------+------+-----------------------------------------+
   | svraddr4 | ASCII | NIP  | Server as IP address, whether IPv4 or   |
   |          |       |      | IPv6,                                   |
   | svrname4 | VMUST | INET | Server name as returned by server.  Not |
   |          |       |      | sent by client, except in               |
   |          |       |      | VERIFY/NVERIFY.                         |
   | prinsfx4 | VMUST | INET | Suffix part of principal, in the form   |
   |          |       |      | of a domain name.                       |
   | prinpfx4 | VMUST | NFS  | Must match one of a list of valid users |
   |          |       |      | or groups for that particular domain.   |
   +----------+-------+------+-----------------------------------------+

                                  Table 7