From: Dan Oscarsson (Dan.Oscarsson@kiconsulting.se)
Date: 02/06/03-10:48:32 AM Z
Message-Id: <200302061645.h16Gjen06372@malmo.trab.se> Date: Thu, 6 Feb 2003 17:48:32 +0100 (CET) From: Dan Oscarsson <Dan.Oscarsson@kiconsulting.se> Subject: Re: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis-05 draft] >What I was getting at is that if the server does not enforce a >normalization form for filenames then the clients had better use one >normalization form to avoid interop problems, and if the client does the >normalization then that task can be moved to user-level, as in libc. > Yes, and because of that I think the protocol must mandate normalisation form C. Then the server (kernel) code kan assume the format to be that and do not need to do any normalisation. If a client sends text in another form and thereby violates the protocol strange things may happen and bad answers. That is ok, that should happen if you do not follow the protocol. The whole meaning of defining a protocol is to agree on what "language" to speak and the meaning of the "words". If the protocol says UCS form C encoded using UTF-8 and somebody transmitts UCS-2 you violates the protocol. If we define the normalisation form to be "undefined", we get a protocol where the "words" are loosly defined. I see no reason to allow more than one form of a "word". Why complicate the world? By selecting the most favoured normalisation form many systems can directely send text over the protocol without change. Both the Unix community and the World Wide Web have selected form C to be used. I am sure there are many more. Dan
This archive was generated by hypermail 2.1.2 : 03/04/05-02:12:05 AM Z CST