Subject: RE: [[email-masked]: Comments on NFSv4 rfc3010bis- 05 draft]

From: "Noveck, Dave" <[email-masked]>
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:[email-masked]]
Sent: Friday, January 24, 2003 1:33 PM
To: Nicolas Williams
Cc: Noveck, Dave; Spencer Shepler; [email-masked]
Subject: Re: [[email-masked]: 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

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 26 Jan 2003 14:11:47 -0600

No, ASCII text is a legal sub-set of UTF-8.

8859-1/2, non-ASCII text, is NOT legal UTF-8.

Cheers,

Nico