From: Mike Eisler (mike@eisler.com)
Date: 01/27/03-01:48:33 PM Z
Message-ID: <3E358D11.9040607@eisler.com>
Date: Mon, 27 Jan 2003 11:48:33 -0800
From: Mike Eisler <mike@eisler.com>
Subject: Re: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis- 05 draft]
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
Noveck, Dave wrote:
>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:rees@umich.edu]
>Sent: Monday, January 27, 2003 9:02 AM
>To: nfsv4-wg@sunroof.eng.sun.com
>Subject: Re: [Dan.Oscarsson@kiconsulting.se: 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?
>
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:50 AM Z CST