From: Noveck, Dave (Dave.Noveck@netapp.com)
Date: 01/25/03-08:38:10 PM Z
Message-ID: <C8CF60CFC4D8A74E9945E32CF096548A072A48@SILVER.nane.netapp.com> From: "Noveck, Dave" <Dave.Noveck@netapp.com> Subject: RE: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis- 05 draft] Date: Sat, 25 Jan 2003 18:38:10 -0800 > The nfsv4 i18n follows the lead of IETF's stringprep RFC (which we > were asked to do by IESG). Presumably the folks who wrote it were > experts, and they strongly recommend KC for case insensitive matching. I'm not an expert but my understanding of normalization form KC is that under it "file" (that is, ascii f, ascii i, ascii l, ascii e) would be an invalid file name. Can anyone who is familiar with this stuff confirm or deny? -----Original Message----- From: Mike Eisler [mailto:mike@eisler.com] Sent: Friday, January 24, 2003 1:33 PM To: Nicolas Williams Cc: Noveck, Dave; Spencer Shepler; nfsv4-wg@sunroof.eng.sun.com Subject: Re: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis- 05 draft] Nicolas Williams wrote: > Er, no, utf8str_cs requires that a normalization form be used, just not > on the wire. So the problem of legacy filesystems remains even if we do > not act to recommend or require a specific normalization form on the > wire. It requires a normalization form only if the server is case insensitive. > > At least I feel the need for a "Normalization Forms for Dummies" document. > > Maybe other working group members do as well. Any pointers to something > > that will explain this stuff to those who have not already immersed > > themsleves in this area. > > There are several books with "Unicode" in the title (none in my office > right now). And the Unicode home page is a good place to start: > > http://www.unicode.org/ I find each visit to unicode.org ever more confusing. My most recent visit revealed that "16 bit" Unicode now has over 2^64 characters. It is absolutely impenetrable. The nfsv4 i18n follows the lead of IETF's stringprep RFC (which we were asked to do by IESG). Presumably the folks who wrote it were experts, and they strongly recommend KC for case insensitive matching. Now we have two other experts in the last 24 hours disagree, but with two more opinions. Clearly, no matter what we do in this area, it is highly probable we'll get it wrong. Just as clearly, normalization is not well thought out by the people specifying this; otherwise it would be much easier to grasp. So what do we want to do with the i-d that IESG has approved for publication. My inclination is to leave it alone, since I suspect we could delay it for 12 more months and still not reach consensus. Only via real experience will a practical truth emerge ... it may that IESG is right, it may be that Dan is right, Nico is right, Dave is right. My guess is it will be none of the above. Fixed in NFSv4.x (x > 0). -mre
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:49 AM Z CST