Subject: RE: I18N and Normalization

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 4 Feb 2000 07:30:01 -0800

> A proposal has been made in the area of internationalization
> that deals with what is referred to as normalization.
> In short, normalization is a method to remove duplicates
> or ambiguites that are part of the Unicode Standard.  The
> normalization methodologies are part of the Unicode 3.0 
> standard (to which the NFSv4 I-D now refers as of the
> last draft).  Based on my 'research' and current understanding
> the specification of the use of a normalized form for the
> UTF-8 encoding seems prudent for NFSv4.
> 
> Therefore, I have updated the I-D to include the necessary
> statements with respect to this issue.  For those who are
> interested, there are two pointers that I can provide that
> contain additional information.  If you are unfamiliar with
> the Unicode Standard, these pointers will seem rather
> cryptic. :-(

The converse, that if one were familiar with the Unicode Standard,
these pointers would not seem cryptic, is something that I'll
just have to take on faith :-)

> 
> http://www.w3.org/TR/charmod/
> http://www.unicode.org/unicode/reports/tr15/

> Here is the updated text:  |
> --
> 11.  Internationalization
> 
> The primary issue in which NFS needs to deal with
> internationalization, or i18n, is with respect to file names and
> other strings as used within the protocol.  NFS' choice of string
> representation must allow reasonable name/string access to clients
> which use various languages.  The UTF-8 encoding allows for this type
> of access and follows the policy described in "IETF Policy on          |
> Character Sets and Languages", [RFC2277].  To furhter ease             |
> interoperability with respect to the UTF-8 encoding, the client and    |
> server should also use the Normalized Form C of the Unicode Standard   |
> [Unicode1].  These choices are explained further in the following.     |
> 
> -and-
> 
> 11.5.  Normalization                                                   |
> 
> The use of a normalization methodology eases the binary comparison of  |
> strings for equality.  The Unicode Standard allows for instances that  |
> a character may be represented in more than one encoding.  Using the   |
> Normalized Form C, as defined in the Unicode Standard, provides a      |
> method to encode characters such that they may be easily compared for  |
> equality in binary form.  Therefore, the use of Normalized Form C      |
> will ease potential incompatibilities when comparing file names or     |
> other strings in the NFS version 4 protocol.  It is suggested that     |
> both client and server use Normalized Form C in combination with the   |
> UTF-8 encoding to increase interoperability.                           |

I'm not sure what it means for the server to use Normalized Form C.
There are a few places (e.g. some file attributes) in which the 
server returns strings which it didn't get from the client and I
understand the suggestion as it applies to those.  The most common
sort of strings the server will be sending will be filenames and
and these derive from the client (or local filesystem operations).
Unless you are asking the server to normalize any unnormalized
filenames (which has problems when a client can't find a file
it just created in a READDIR result), he is only going to be
using Normalized Form C to the degree his clients (and local
applications) do.