From: Spencer Shepler (shepler@eng.sun.com)
Date: 02/07/00-12:43:24 PM Z
Message-ID: <389F124C.5428ED2F@eng.sun.com> Date: Mon, 07 Feb 2000 12:43:24 -0600 From: Spencer Shepler <shepler@eng.sun.com> Subject: Re: Withdrawal of I18N and Normalization proposal RJ Atkinson wrote: > > At 23:15 04-02-00 , Spencer Shepler wrote: > > >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). > > 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. Thanks for the suggestion. It has been changed in the draft. > 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. 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.
This archive was generated by hypermail 2.1.2 : 03/04/05-01:48:04 AM Z CST