Subject: RE: [[email-masked]: Comments on NFSv4 rfc3010bis-05 draft]

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 6 Feb 2003 09:30:08 -0800

I want to separate the two issues.  Checking UTF-8 and
checking form C.

It's my impression that the spec already requires that 
you check stuff that supposed to be utf-8 and reject it
if it isn't valid utf-8.  I can't quote a specific statement
to that effect but when it says that that's what's valid, my 
conclusion is that anything else is invalid.  In fact,
on my bug list (way down, to be sure) is a problem that
Peter Astrand's test suite complains that I don't reject 
a *tag* that doesn't consist of valid UTF-8.

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.

I'm assuming that checking for valid normalization form C
is simpler than actually doing the normalization.  I'm hoping
that for most actual strings processed the execution time
will be roughly comparable to just checking UTF-8, even though
there will obviously be examples that are considerably more 
expensive to process.

-----Original Message-----
From: Jim Rees [mailto:[email-masked]]
Sent: Thursday, February 06, 2003 12:09 PM
To: [email-masked]
Subject: Re: [[email-masked]: Comments on NFSv4
rfc3010bis-05 draft] 

I would be opposed to requiring the server to check file names for valid
UTF-8 form C.  Is this really necessary?  Unix (and nfs) file systems have
never checked file names for validity in the past.  This can result in some
suprising behavior if the application (or client) misbehave, but I would
vote for sticking with tradition on this one.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 6 Feb 2003 11:37:07 -0600

> I want to separate the two issues.  Checking UTF-8 and

These two are, in fact, distinct.

> a *tag* that doesn't consist of valid UTF-8.

The spec speaks of UTF-8 throughout - I don't see how it could be
construed as correct behaviour to allow non-UTF-8 encodings or invalid
UTF-8 encodings (e.g., overlong sequences).

> happened, whether a client with bad normalization was involved.

It would be useful to have benchamrks of Unicode normalization.

> there will obviously be examples that are considerably more 

Your assumption is correct.  I don't know about the perf aspect, but
users of mostly-ASCII filenames would likely not notice any impact.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 6 Feb 2003 11:56:50 -0600

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

...
> happened, whether a client with bad normalization was involved.
...