From: Mike Eisler (mike@eisler.com)
Date: 01/27/03-07:44:26 PM Z
Message-ID: <3E35E07A.8060105@eisler.com>
Date: Mon, 27 Jan 2003 17:44:26 -0800
From: Mike Eisler <mike@eisler.com>
Subject: Re: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis- 05 draft]
Nicolas Williams wrote:
>Mike,
>
>Clarify this for me (I'm pretty sure of the answer, but perhaps I'm
>reading too much into section 11.1.1):
>
> Must the server prevent equal filenames with unequal encodings from
> being created?
>
Yes, under limited circumstances.
The profile for NFSv4 file names refers to RFC3454, and specifically
tables B.1. Any characters the server receives from the client that are in
Table B.1 of RFC3454 MUST be mapped to nothing. So filenames containing
any of these few dozen or characters have the offending characters
removed before processing LOOJUP, OPEN, CREATE, et. al.
If the NFSv4 server is performing case insensitive matching, then
after processing table B.1 mapping, table B.2 mapping (to map
case) is then done. The results are then normalized with form KC.
(Section 2 of RFC3454 clearly distinguishes mapping steps from
Unicode normalization steps).
If the server is not doing case insensitive matching, then NFSv4 servers
are not required to do normalization.
I could have written the NFSv4 specification to say that no
normalization for case insenstive matching was required, and
thus the mapping phase would use Table B.3. But as
I've written before, it seemed silly that the strings with
domain names would use KC, and other strings would
not use KC (and a different mapping table).
>
>
> Is the server allowed or required to normalize, to a form of its
> choosing, filenames referenced by the clients?
>
If the server advertised that it is supporting one of the case insensitive
attributes, it MUST use form KC. If neither of the case
attributes is supported by the server, then normalization is
optional by the implementation and
could be made a SHOULD or MUST in a future
revision of the specification, such as advancement to DRAFT
status, or in a minor revision. Given
that that we are riding RFC3454, the only
normalization form we could use in the future is KC.
See section 4 of RFC3454. One excerpt is
constructed in an interesting way. After
previously stating that the choices for protocols
are no normalization or use KC,
the section says:
There is a third form of normalization, Unicode normalization with
form C. If a profile is going to use a Unicode normalization, it
MUST use Unicode normalization form KC.
It is pretty clear to me that form C is not
permissable for any IETF protocol that
makes a normative reference to RFC3454.
I infered from IESG's comments on the
NFSv4 specification ( before it approved
the version that refered to RFC3454)
that compliance with RFC3454
was not an option for us. The whole discussion
about using form C or not is seems
a like the earlier discussions as to whether to use
UDP or not. It is irrelevant because of the direction
IESG has mandated.
-mre
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:51 AM Z CST