Subject: [nfsv4] Stringprep Compares

From: Steven Huntington <[email-masked]>
Date: Wed, 16 Mar 2005 10:26:37 -0800

Our internal I18N rep describes proper string compares using stringprep as

   1. Convert internal strings to UTF-8 (if needed)
   2. Perform stringprep on both the network UTF-8 string and internal
   UTF-8 string
   3. Compare the results

For an NFS lookup, the above process describes convert and stringprep "all"
exported file names to UTF-8 for comparison...

Performing this for each NFS request greatly impacts performance.
Converting and maintaining a cache within NFS introduces problems with file
deletes & renames outside of the NFS scope.

Any comments to the alternate approach (or vote of confidence) with running
the network filename string through stringprep, convert to an internal
CCSID, and passing the local CCSID filename to the underlying kernel API
for lookup comparisons.

Thanks,
Stevan C. Allen

[email-masked]    T/L 276-0352    Alt 408-779-1211
z/NFS Development: 5600 Cottle Rd. San Jose CA. 95193

Before deciding on a design:
      Is the design easy to explain?
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 16 Mar 2005 13:03:56 -0600

>    2. Perform stringprep on both the network UTF-8 string and internal

There is, IMO, a big I18N bug in RFC3530.  We've discussed this before.

Actually, two bugs:

1) It doesn't specify a normalization form for file names, yet it
   specifies a stringprep profile.  This is contradictory -- you cannot
   have a stringprep profile w/o a normalization form.

2) It doesn't say who is responsible for applying the stringprep
   profile, and doesn't deal with unassigned code points.

To improve performance we need to change the spec to:

a) specify a normalization form
b) specify a way to negotiate the use of currently unassigned code
   points (so NFSv4 can use them when they are assigned)
c) specify that the client is responsible for applying stringprep, while
   the server is responsible for verifying that the UTF-8 strings sent
   by the client are consistent with the required stringprep profile,
   but only on CREATEs -- the latter requires less computation and,
   possibly storage and would be avoided in most situations.

So, then, the server would only have to do significant I18N work when
handling file/directory creation requests, otherwise it would treat
names as octet strings.  The client would still have to stringprep
every name it sends to the server, else its LOOKUPs may fail to match
when they should succeed has the client stringprepped.

Note that for all-ASCII names the client and server I18N has little
impact on performance.

> exported file names to UTF-8 for comparison...

And when you try you run into (1).

> Performing this for each NFS request greatly impacts performance.

No kidding.  Note though that we can't avoid mandating a stringprep
profile for file names *somewhere*.  Users, of course, can avoid the use
of non-ASCII characters in file/directory names.

> CCSID, and passing the local CCSID filename to the underlying kernel API

CCSID?

Nico
--