Subject: Withdrawal of I18N and Normalization proposal

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

Based on the comments I have received, I am withdrawing
my previous proposal for the I18N and Normalization changes
and submit the following modification for addition to the
draft.

--
11.5.  Normalization

   The client and server operating environments may differ in their
   policies and operational methods with respect to character
   normalization (See [Unicode1] for a discussion of normalization
   forms).  This difference may also exist between applications on the
   same client.  This adds to the difficulty of providing a single
   normalization policy for the protocol that allows for maximal
   interoperability.  This issue is similar to the character case issues
   where the server may or may not support case insensitive file name
   matching and may or may not preserve the character case when storing
   file names.  The protocol does not mandate a particular behavior but
   allows for the various permutations.

   The NFS version 4 protocol does not mandate the use of a particular
   normalization form.  Therefore, the server and client can expect that
   they may receive unnormalized characters within protocol requests and
   responses.  If the operating environment requires normalization, then
   the implementation must normalize the various UTF-8 encoded strings
   within the protocol before presenting the information to an
   application (at the client) or local file system (at the server).

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 04 Feb 2000 20:19:33 +0000

>    application (at the client) or local file system (at the server).

It is my understanding that ISO JTC1 is aware of the IETF's pressing need
for ISO to undertake normalisation standards activity.  They might well
adopt input from the UNICODE Consortium, though that isn't clear yet,
certainly not clear to me.  I would guess that IETF would follow ISO JTC1's
lead should ISO develop standards for normalisation, but that is just my
guess.

I like the above basically, but would propose changing "form." in the
first sentence of the second paragraph into:
"form at this time.  A later revision of this specification might
specify a particular normalisation form.".
The point of this editorial change is to warn implementers that we
might specify a normalisation form in future so they should avoid
boxing themselves in.  Regrettably, normalisation is likely to reappear
as an issue down the road, even if it can be side stepped for now.  Sigh.

It would also be helpful if the draft were crystal clear that the
coded character set specified is ISO-10646 (as differentiated from
Unicode).  UCS-4 implies 10646, but real clarity would be helpful, IMHO.

Ran
[email-masked]

---

From: Mike Eisler <[email-masked]>
Date: Fri, 4 Feb 2000 18:52:10 -0800 (PST)

> "form at this time.

I think that's fine. With minor versioning, we are free to tweak the
meaning of the utf8 data type than NFSv4 defines.

	-mre

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 07 Feb 2000 12:43:24 -0600

> as an issue down the road, even if it can be side stepped for now.  Sigh.

Thanks for the suggestion.  It has been changed in the draft.

> Unicode).  UCS-4 implies 10646, but real clarity would be helpful, IMHO.

Okay.  This is the current wording:
--
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 of the UCS as
   defined by [ISO10646] allows for this type of access and follows the
   policy described in "IETF Policy on Character Sets and Languages",
   [RFC2277].  This choice is explained further in the following.