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

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 27 Jan 2003 06:20:51 -0800

I'm OK with C *provisionally*.  Let me explain.  I think
one of the problems that we have had in this area is that
we are too quick to agree to some of this stuff, before we
understand the full implications.

I believe this what happened when the stringprep went in.  
You can argue (endlessly) whether this was a good idea or not
but I think it is clear that we did not really understand
the implications.  I think the reason was that most of us
find this stuff really complicated and unpleasant and we'd
rather just get it out of the way go on to talk about something 
else.

Let's not repeat our mistake and settle on something until 
we have done enough implementation work to be sure that we
are really OK with the implications in actual filesystems.

So one question that we need to examine is our old friend
linktext4.  Are we saying that a server MUST reject creation
of a symlink if it doesn't obey the rules of normalization 
form C, and if so, with what error?  If not, are we saying
that we should normalize to form C on readlink.  And of course
there is the issue of those existing symlinks on existing
filesystems, even those that are encoded in UTF-8.  If they
don't match form C, should we fail (what error), normalize to
C, or just the return the damn data?  Enquiring minds want to
know.

-----Original Message-----
From: Jim Rees [mailto:[email-masked]]
Sent: Monday, January 27, 2003 9:02 AM
To: [email-masked]
Subject: Re: [[email-masked]: Comments on NFSv4
rfc3010bis-05 draft] 

Form C sounds right to me.  Is there free sample normalization code
available somewhere?  How about for the other forms?

---

From: Mike Eisler <[email-masked]>
Date: Mon, 27 Jan 2003 11:48:33 -0800

This  is why I deliberately choose a conservative
route:

    - the forms that included domain names followed IETF's standards for
        i81n of DNS domain names.

    - the filename form doesn't  mandate a normalization form
        (Nico and I will have to agree to disagree on this one)
        for case sensistive file name handling

    - the filename forms does mandate KC for case sensistive
        handling, since stringprep listed KC for
        case insensistive handling as a SHOULD. Given that
        DNS domains are case insensitive, it seemed illogical
        to me that an operating environment would use KC for
        case insensitive handling in one namespace (DNS),
        and something else for another (files).

As for symlinks they are pretty much a bag of bits that are
meaningful only to client (and even then not  necessarily)
that created them. I don't think servers should be
modifying them during CREATE or READSYMLINK.

    -mre

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 27 Jan 2003 18:45:16 -0600

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?

  Is the server allowed or required to normalize, to a form of its
  choosing, filenames referenced by the clients?

Thanks,

Nico

---

From: Mike Eisler <[email-masked]>
Date: Mon, 27 Jan 2003 17:44:26 -0800

>  Must the server prevent equal filenames with unequal encodings from
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).

>  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