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

From: <[email-masked]>
Date: Mon, 14 Jun 2010 12:49:31 -0400

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.  

SVR-1: Server names MUST be returned as A-labels

	Canonical form of return which does give rise to any issues that
might cause anybody within the working group to face a heresy trial.

	No known comparison of servers, but still providing names that
allow comparisons has to be considered a good things.

SVR-2: Server names MAY be returned as either A-labels or U-labels

	Maximum flexibility and ensures that current implementations are
conformant.

	Clients may have to deal with either, but clients are going to
have to have conversion abilities anyway. 

SVR-3: Server names MUST be returned as U-labels

	Most conformant with the structure of the protocol and its basic
handling of internationalization.

	Names not canonical but there is really no strong reason to be.

SVR-4: Server names MUST be returned as Gold-labels (A-labels converted
to U-labels)

	Also conformant with basic handling of internationalization.

	Even though no clear requirement for server comparison provides
non-Punycoded option on a level with all aspects of SVR-1 

SVR-5: Server names MUST be returned as U-labels and SHOULD be returned
as Gold-labels (U-labels derived from A-labels).

	Similar to SVR-4, but more liberal in allowing non-canonical
labels

SVR-6: Server names MAY be returned as either A-labels or U-labels.  In
the case of U-labels, MUST be Gold-labels (U-labels derived from
A-labels).

	Merger of SVR-2 and SVR-4.

SVR-7: Server names MAY be returned as either A-labels or U-labels.  In
the case of U-labels, SHOULD be Gold-labels (U-labels derived from
A-labels).

	Merger of SVR-2 and SVR-5.

I'm trying to include all possibilities that are not totally crazy.  Let
me know if there is one you think should be added.

Will try to come up with a similar list for ID cases, which is more
complicated because information travels in both directions.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 14 Jun 2010 12:06:45 -0500

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

---

From: <[email-masked]>
Date: Mon, 14 Jun 2010 15:31:04 -0400

> 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
> 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:[email-masked]] 
Sent: Monday, June 14, 2010 1:07 PM
To: Noveck, David
Cc: [email-masked]
Subject: Re: [nfsv4] IDNA choices for servers for
replicas/migration/referral

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 14 Jun 2010 14:37:54 -0500

> Are you?  The degree of importance you assign it will govern your

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

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