From: Dan Oscarsson (Dan.Oscarsson@kiconsulting.se)
Date: 01/27/03-01:55:37 AM Z
Message-Id: <200301270755.h0R7tHAT007430@valinor.malmo.trab.se> Date: Mon, 27 Jan 2003 08:55:37 +0100 (CET) From: Dan Oscarsson <Dan.Oscarsson@kiconsulting.se> Subject: Re: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis-05 draft] >I think NFSv4 must require at the very least that filenames be stored >normalized to some form (we should probably specify if it can be a K >form or not, but D vs. C is not so important) and let clients and >servers deal with that. This is pretty much what the draft says or >implies. The Open Source Unix and Linux community have for internationalisation selected UCS normalised using form C and encoded using UTF-8 as the standard to be used on Unix and Linux. The same form and encoding have been selected by W3C for the webb. So there is a lot of software that does or will handle form C encoded text. From what I have seen there will be very little software that will handle or use normalisation form D, KD or KC. So NFSv4 should use the same as most do (or will do): normalising form C. But we cannot require it in storage, only on the wire. It is on the wire, that is between systems, that it must be standardised to one simple format. Systems can use any format they want. A system which uses normalising form C as its local format for staorage will have a simpler implementation than others, and that will help push system vendors to move to the most common format used. UCS normalising form C is compact and do not destroy any information, so it is best. The K forms destroy data and the D form takes more space and breaks the semantic concept of letter on some letters. Yes, it may result in additional code in servers, but many system can create very efficient code to convert between legacy character set and UCS normalising form C. So I think it will not be that expensive. Dan
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:50 AM Z CST