From: Noveck, Dave (Dave.Noveck@netapp.com)
Date: 01/24/03-02:22:29 PM Z
Message-ID: <C8CF60CFC4D8A74E9945E32CF096548A379095@SILVER.nane.netapp.com> From: "Noveck, Dave" <Dave.Noveck@netapp.com> Subject: RE: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis- 05 draft] Date: Fri, 24 Jan 2003 12:22:29 -0800 I agree that we should not change anything in the spec. But I am going to say that: > We can continue to build consensus around this issue is over-sanguine. Maybe we can try to build consensus around this issue. Right now the only consensus is that this whole issue is one big pain! -----Original Message----- From: Spencer Shepler [mailto:shepler@eng.sun.com] Sent: Friday, January 24, 2003 3:11 PM To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis- 05 draft] On Fri, Nicolas Williams wrote: > > > So what do we want to do with the i-d that IESG has approved for > > publication. My inclination is to leave it alone, since I suspect we > > could delay it for 12 more months and still not reach consensus. > > Only via real experience will a practical truth emerge ... it may that > > IESG is right, it may be that Dan is right, Nico is right, Dave is right. My > > guess is it will be none of the above. Fixed in NFSv4.x (x > 0). > > I'd like to see the WG RECOMMEND to clients _a_ normalization form for > utf8str_cs. > > I think we may not be able to change the spec to require that that norm > form be used on the wire for utf8str_cs types, not at this late a date, > though that is what I would have preferred. Problem is, I don't think > it will ever be possible or worthwhile anymore to make this change later > if we don't do it now. Is that a big deal? Well, only if you think > that having full-blown Unicode normalization facilities in the server > implementations of NFSv4 (which may be required for multi-protocol > servers anyways) is a big deal. Hindsight is 20/20... I would prefer to leave the current I-D as is and let it become an RFC. We can continue to build consensus around this issue and either publish a seperate RFC covering this specific issue and/or incorporate the work into the Draft version of the NFSv4 RFC. Spencer
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:49 AM Z CST