Subject: I18N and Normalization

From: Spencer Shepler <[email-masked]>
Date: Thu, 03 Feb 2000 20:44:47 -0600

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. :-(

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.                           |

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 04 Feb 2000 05:59:22 +0000

At 02:44 04-02-00 , Spencer Shepler wrote:

>last draft).  

Spencer,

This raises a couple of questions in my mind.

- Is the choice of UNICODE over ISO-10646 deliberate ?
- If yes, why ?
- If not, might we please consider referencing ISO-10646 instead ?

The IETF trend is to work on the basis of ISO-10646 rather
than Unicode, partly because ISO is focused on coding for
information interchange whereas Unicode is focused on printing.
So, barring some particular (and preferably documented in
the draft) technical reason for citing Unicode, it would generally
be preferable to cite ISO-10646 for an IETF protocol.

UTF-8 is an encoding and as such is compatible with either 
ISO-10646 or Unicode.  While there is much commonality between
ISO-10646 and Unicode, they are not identical at present.

>Based on my 'research' and current understanding

UTF-8 has adverse implications for people who are not using
Western European languages.  For example, UTF-8 is not a very
friendly encoding for Vietnamese -- even though Vietnamese always
uses a Romanised alphabet (Quoc Ngu, to be specific).  It is
rather worse for Arabic or Chinese or Thai than for Western European
languages, to give another example.

Have you considered the outputs of the IAB Character Set Workshop
of several years back and run the internationalisation aspects
of this past folks who have been working in that area ?

(I once wrote a thesis on Chinese/Japanese-language computing,
hence my own interest. :-)

People I would suggest running this past for technical review
would include John Klensin, Harald Alvestrand, Ned Freed,
and Patrick Falstrom.  All of those folks have been involved
in Internationalisation aspects of other IETF protocols, so
are familiar with the Internationalisation issues.  Among
other things (and RFC-2277 not withstanding), you might discover
that the IAB and IESG are not rigid about UTF-8.

The conclusion of such an ad hoc review might well be to proceed
down the current path, but I think it would be valuable to have
such review before going to RFC.  I would guess that at least
two of the above folks could do such a review rapidly, so as not
to bog progress unduly.

Regards,

Ran
[email-masked]

---

From: Mike Eisler <[email-masked]>
Date: Fri, 4 Feb 2000 07:54:13 -0800 (PST)

> The IETF trend is to work on the basis of ISO-10646

The nfsv4 i-d is clearly biased toward ucs-4 and
refers to 10646-1. I agree that it would be more precise if
folks stopped talking about unicode support in nfsv4.

	-mre

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 04 Feb 2000 16:17:40 -0600

> - If not, might we please consider referencing ISO-10646 instead ?

Sorry for adding to the confusion.  As Mike has pointed out,
with the description of the use of UTF-8, UCS-4 use is implied.

Spencer