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

From: Dan Oscarsson <[email-masked]>
Date: Tue, 28 Jan 2003 18:13:23 +0100 (CET)

>It is pretty clear to me that form C is not
>permissable for any IETF protocol that
>makes a normative reference to RFC3454.
>I infered from IESG's comments on the
>NFSv4 specification ( before it approved
>the version that refered to RFC3454)
>that compliance with RFC3454
>was not an option for us. The whole discussion
>about using form C or not is seems
>a like the earlier discussions as to whether to use
>UDP or not. It is irrelevant because of the direction
>IESG has mandated.

Why are you following RFC 3454?
It is created to support encoding domain names into ASCII to allow
legacy systems handle non-ASCII domain names.

It is not good for everything.

Form C is good because it preserves all sematics on the text.
If somebody creates a file name "a²" (a followed by superscript 2),
is that file names going to match file name "a2"?
That is what happens if you use form KC.
And should you be allowed to have a file named "a²" (a followed by
superscript 2)? If you use KC as format for storage you can only
store a file named "a2" (so the user creating the file as "a²"
will when listing the directory se that it has changed name to "a2").
Names are very important to people. Maybe we should also
normalise all letters to lower case?

While RFC 3454 have some good points about forbidden characters (those
mapped to nothing), normalisation form C is much more suitable for
file names than form KC.
When matching names for equality, you might use KC but as that
requires internal tables in the kernel and CPU power. 
To preserve CPU power, you could just match those characters
that have a one to one code point match. That would be enough for
most and work well.
Also doing case insensitive matching you can choose to use only
the one to one letter matching instead of also including the
one to many letters matching that is also available. That would also
be possible with less CPU and smaller tables, and be fine for most
people.

RFC 3454 "stringprep" is fine for the attributes in the NFSv4 protocol,
not for handling file names. 

   Dan