Re: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis-05 draft]

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

From: Nicolas Williams (Nicolas.Williams@sun.com)
Date: 02/06/03-11:56:50 AM Z


Date: Thu, 6 Feb 2003 11:56:50 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
Subject: Re: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis-05 draft]
Message-ID: <20030206115650.B18728@binky.central.sun.com>

Perhaps there is a neat compromise:

 - RECOMMEND a normalization form to clients that they are responsible
   for using and converting to/from

 - RECOMMEND that the server enforce a normalization form ONLY for new
   filenames (creates/renames/links)

This way the server can guarantee that the filesystem will contain only
filenames with the proper normalization without having to perform
normalization very often (only when files are created/renamed/linked
with non-ASCII names), thus limiting the perf impact of doing
normalization on the server, and the client is responsible for
normalizing before doing LOOKUPs.

(Multi-protocol servers may have to deal with normalization more
generally, but that's a function of the protocols in question).

Section 11.4 of the draft already specifies an error to make this
possible.  All that'd be needed is an I-D that hands down the two
recommendations.

Cheers,

Nico

On Thu, Feb 06, 2003 at 09:30:08AM -0800, Noveck, Dave wrote:
...
> As to checking form C, it really doesn't make much difference
> to me whether the spec requires the server to check it.  Saying 
> that the client has to produce correct form C, but that the 
> server doesn't have to check it, with the client getting "weird" 
> results if he uses the wrong form, is not something that I
> would be prepared to live with.  I would wind up checking
> the normalization rather than having to wonder, in any 
> internationalization situation in which something wierd 
> happened, whether a client with bad normalization was involved.
...


New Message Reply About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.2 : 03/04/05-02:12:06 AM Z CST