Re: [nfsv4] IDNA choices for servers for replicas/migration/referral

[<[e-mail]>]

> Are we aiming for server implementation simplicity?  

Are you?  The degree of importance you assign it will govern your
ordering of the list. 
 
> If so, A-labels all
> the way is the simplest solution (servers wouldn't have to implement
> IDNA, but they would have to check labels sent by clients to see that
> they are valid-looking A-labels). 

I have to make sure that the underlying string is normalized.  I have to
normalize the corresponding UTF-8 string and see if that winds up with
the same value.  There may be a slightly optimized (n-i/n-p)-like that
checks this in line which is faster but it isn't going to be much
simpler.  There may other prep-like stuff to check.  Also, before I do
that I have to un-Punycode (steroidi-code? :) it.

So that is essentially the code to convert an A-label-like string to a
U-label in that it returns all of the errors of such a process although
it doesn't actually have to output the U-label in the case of success.
The server is going to implement a very large portion of IDNA.

The other piece is that they are going to get, from configuration files
or such, strings with server names in them.  If it is ever possible that
they receive something that that is a UTF8-string (non-ascii) server
names, then they have to convert it to an A-label.  

    

-----Original Message-----
From: Nicolas Williams [mailto:[e-mail]] 
Sent: Monday, June 14, 2010 1:07 PM
To: Noveck, David
Cc: [e-mail]
Subject: Re: [nfsv4] IDNA choices for servers for
replicas/migration/referral

On Mon, Jun 14, 2010 at 12:49:31PM -0400, [e-mail] wrote:
> This is a list of possible choices and I'm hoping to get enough of a
> consensus that it can be incorporated in the next draft of RFC3530bis,
> to be released in time for Maastricht.  My intension is that while we
> want to get the best choice, we realize that there are many different
> approaches to the issues here and that we put greatest stress on
coming
> up with an acceptable option that everybody can live with it, even it
is
> not the first choice, for what to you are very good reasons.
> 
> I'm putting in a very small list of reasons for each why that might be
a
> good choice.  Not necessarily my opinion.  

Are we aiming for server implementation simplicity?  If so, A-labels all
the way is the simplest solution (servers wouldn't have to implement
IDNA, but they would have to check labels sent by clients to see that
they are valid-looking A-labels).  But this would actually impair
deployment with name services other than DNS (see my other post today
about that, and see draft-iab-idn-encoding); I'm not sure that that's a
problem.

The most flexible scheme is to allow clients to send unnormalized UTF-8
and require that servers send either only U-labels (canonical, what you
call Gold-labels; but it turns out 'U-label' means just that), or
U-/A-labels at the server's discretion.  But then servers would have to
implement IDNA, no ifs ands or buts.

Alternatives in between would require that both, clients and servers
implement IDNA.  Clients will generally have to implement IDNA, if not
because of NFSv4, then because of other apps, so requiring them to
implement IDNA is not a big deal.

Looking at it from our point of view, having a general-purpose-OS-based-
implementation, both for the client and the server, forcing the server
to implement IDNA is not really any different from forcing the client to
implement it.  Therefore I'm neutral as to which, if not both, of the
client and server should have to implement IDNA.  Thoughts?

Nico
--