From: Dan Oscarsson (Dan.Oscarsson@kiconsulting.se)
Date: 01/28/03-11:13:23 AM Z
Message-Id: <200301281710.h0SHAbn00166@malmo.trab.se> Date: Tue, 28 Jan 2003 18:13:23 +0100 (CET) From: Dan Oscarsson <Dan.Oscarsson@kiconsulting.se> Subject: Re: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis- 05 draft] >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
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:51 AM Z CST