From: Spencer Shepler (shepler@eng.sun.com)
Date: 01/24/03-09:14:06 AM Z
Date: Fri, 24 Jan 2003 09:14:06 -0600 From: Spencer Shepler <shepler@eng.sun.com> Subject: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis-05 draft] Message-ID: <20030124151406.GA100497@shepler.eng.sun.com> Forwarding on behalf of Dan. -- Spencer Return-Path: <Dan.Oscarsson@kiconsulting.se> Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk.Eng.Sun.COM [129.146.1.45]) by jurassic.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0I9giL5516974 for <shepler@jurassic.Eng.Sun.COM>; Sat, 18 Jan 2003 01:42:44 -0800 (PST) Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0I9gigE017900 for <spencer.shepler@eng.sun.com>; Sat, 18 Jan 2003 01:42:44 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by sunmail2.sfbay.sun.com (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id h0I9ghk28225 for <spencer.shepler@sun.com>; Sat, 18 Jan 2003 01:42:43 -0800 (PST) Received: from malmo.trab.se (malmo.kicore.net [131.115.48.10]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA10315 for <spencer.shepler@sun.com>; Sat, 18 Jan 2003 02:42:42 -0700 (MST) Received: from terra (terra.malmo.kicore.net [217.212.0.22]) by malmo.trab.se (8.10.1/TRAB-primary-2) with SMTP id h0I9gZn02930 for <spencer.shepler@sun.com>; Sat, 18 Jan 2003 10:42:35 +0100 (MET) Message-Id: <200301180942.h0I9gZn02930@malmo.trab.se> Date: Sat, 18 Jan 2003 10:45:13 +0100 (CET) From: Dan Oscarsson <Dan.Oscarsson@kiconsulting.se> Reply-To: Dan Oscarsson <Dan.Oscarsson@kiconsulting.se> Subject: Comments on NFSv4 rfc3010bis-05 draft To: spencer.shepler@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8r0pO/lLBWGleL39s2LFDw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5 SunOS 5.9 sun4u sparc This is a comment on draft-ietf-nfsv4-rfc3010bis-05 I have for many years worked with internationalisation and when I look at the internationalisation section 11 in the draft I do not understand the choice made. First you have to separate the format used in the protocol from the way to match strings in server or client. It is somewhat unclear in the document. Looking at the most important string: utf8str_cs which is used in naming components and pathnames, I see that you do not specify a normalisation form. Why not? To create simple and effcient implementations it is very good if all strings are normalised. As names are important to people, normalisation form KC cannot be used. Instead normalisation form C MUST be used. This will allow all special forms of a character that a person what to have in a name be preserved. At the same time if will give a compact format to transmitt over the net and ONE single format to decode/encode in implementations. The "stringprep" document was created to handle matching of names in DNS, it is not generally suitable. If utf8str_cs strings need to be compared case insensitively, you have to use form KC and single character lower casing. The case mapping in stringprep will result in names that should be different will be matched as equivalent (this is due to going to far in case mapping). The table B.2 which the draft says to use when doing case insensitiv matching is only usefull if normalisation form KC has been used before. It cannot be used on unnormalised or form C text. As an implementor of programs handling UCS I want to have a simple efficient export/import of text as well as a good case insensitive matching. By always requiring normalisation form C I get simpler code and that form will never destroy any data in the text. In addition to from C I would prefer to have most of form KC applied, but only the part that equivalences equivalent characters. Form KC unfortunately does equivalencing of characters that are not equivalent and forcing some to be decomposed. I am sure that not mandating a normalisation form in NFSv4 will result in more complex code and more failurs due to mismatch between client/server handling. So why not normalise? Regards, Dan
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:48 AM Z CST