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

From: "Noveck, Dave" <[email-masked]>
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:[email-masked]]
Sent: Friday, January 24, 2003 3:11 PM
To: [email-masked]
Subject: Re: [[email-masked]: 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