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

[Nicolas Williams <[e-mail]>]

On Mon, Jun 14, 2010 at 03:31:04PM -0400, [e-mail] wrote:
> > Are we aiming for server implementation simplicity?  
> 
> Are you?  The degree of importance you assign it will govern your
> ordering of the list. 

As I stated elsewhere in that message: no, I'm not.  By "we" I meant:
the WG (we might need to seek consensus on that matter).

> > 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.

I thought I saw an option for very low-level validation of A-labels.
I'll look again and post a reference.  If not, then you're right and
there's no simplifying the server.  At which point I'd say: allow
un-pre-processed Unicode on the wire for domainname slots, which,
incidentally, David Thaler, an author of draft-iab-idn-encoding, just
blessed on the idna-update list:

Thaler> In my view, yes you're on the right track in having NFSv4 not
Thaler> want to do encoding conversion itself for name resolution but in
Thaler> expecting it to be done under getaddrinfo/getnameinfo.

Nico
--