From: Nicolas Williams (Nicolas.Williams@sun.com)
Date: 01/27/03-06:45:16 PM Z
Date: Mon, 27 Jan 2003 18:45:16 -0600 From: Nicolas Williams <Nicolas.Williams@sun.com> Subject: Re: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis- 05 draft] Message-ID: <20030127184516.G16765@binky.central.sun.com> 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 On Mon, Jan 27, 2003 at 11:48:33AM -0800, Mike Eisler wrote: > 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:51 AM Z CST