Subject: Re: [nfsv4] IDNA choices for servers for replicas/migration/referral -- Take 2

From: <[email-masked]>
Date: Mon, 14 Jun 2010 13:43:50 -0400

Given Nico's correction about whether U-labels are canonical, I'll
reissue this to reflect proper terminology.

*	A-labels stay as they are.
*	What we called in the previous version Gold-labels are actually
U-labels.
*	What we called U-labels in the previous version are just
UTF8-strings excluding A-labels, although we could call them Pb-labels
:-)

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

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

	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 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 UTF8-strings and SHOULD be
returned as U-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 UTF8-strings.
In the case of UTF8-strings, MUST be U-labels..

	Merger of SVR-2 and SVR-4.

SVR-7: Server names MAY be returned as either A-labels or UTF8-strings.
In the case of U-labels, SHOULD be U-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: 	Noveck, David  
> Sent:	Monday, June 14, 2010 12:50 PM
> To:	[email-masked]'
> Subject:	IDNA choices for servers for replicas/migration/referral
> 
> 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: <[email-masked]>
Date: Tue, 15 Jun 2010 22:09:19 -0400

Domain names also turn up in ACLs, the owner and owner_group attributes,
and path variable names.

IMHO, we should treat all domain names in the same fashion, and for that
reason, I think punycode A-labels are not appropriate because the above
entities are going to turn up in places that won't get converted back to
Unicode, and the result of not converting punycode back to Unicode is
gibberish in any language.  That, plus migration considerations lead me

returned as U-labels.

I would also add "and MUST NOT be returned as A-label punycode" to make
that clear.

My reasoning for preferring this over a MUST for U-labels (SVR-4) is
that if some server fails to normalize a Unicode domain name, that's not
a good reason for a client to throw up its hands and walk away ... but
any strange behavior that results at the client is the server's fault
for ignoring this "SHOULD" requirement (i.e., failure to carefully weigh
the full implications - see RFC 2119).

Thanks,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
> Sent: Monday, June 14, 2010 1:44 PM
> To: Noveck, David; [email-masked]
> Subject: Re: [nfsv4] IDNA choices for servers
forreplicas/migration/referral -- Take 2
> approaches to the issues here and that we put greatest stress on
coming
> I'm putting in a very small list of reasons for each why that might be
a
> I'm trying to include all possibilities that are not totally crazy.
Let
> complicated because information travels in both directions.
might
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: <[email-masked]>
Date: Wed, 16 Jun 2010 14:00:43 -0400

> Domain names also turn up in ACLs, the owner and owner_group 
> attributes, and path variable names.

Understood but all the "id@domain" cases have a few additional issues.
Those can be sent by the client to the server and also there is an
implicit comparison involved since the server will be comparing the
domain to the one or ones for which it has mapping support from user and
group names to user and group id.

I'm hoping that if we get agreement on the SVR-n choice, that will guide
us to put together a small list of choices consistent with that choice.
When I started to list the ID-n choices in a vacuum, the list was way
too big.

I've asked people to list their choices in order of preference, but I
guess we're not going to I that way.  Each person wants to explain why
their choice is the right one.  I just don't think that the discussion
that is bound to ensue is going to be very productive.  I want to arrive
at some choice that everybody can live with, even if nobody thinks it is
the right one.

So far I'm OK with all of the choices except doing nothing:

David B. is in favor of SVR-5 (which is fourth on my list)

Mike Eisler in some earlier discussions has argued for SVR-2 (second on
my list), although at that time some issues were not recognized, and his
opinion may have changed.  I'd like to hear how he feels now.

Nico has argued for SVR-3, In the past he has indicated he could accept
SVR-2.  This was before SVR-4 thru SVR-7 existed so I'd like to know how
he feel about things he will accept (not just what the best choice is).
This is particularly the case with SVR-2 and SVR-5.

In addition, I'd like to hear from anybody who hasn't expressed himself
on this issue that wants to.

I'd like to see if we can move from a situation in which SVR-2, SVR-3,
and SVR-5, have one advocate each.  Here it is: I'm the reasonable one
so clearly something is out of whack.  If you think a conference call
makes sense, give me some information of your availability and I'll try
to arrange something.

-----Original Message-----
From: Black, David 
Sent: Tuesday, June 15, 2010 10:09 PM
To: Noveck, David; [email-masked]
Subject: RE: [nfsv4] IDNA choices for servers

returned as U-labels.

Thanks,
--David

Of [email-masked]
coming
a
Let
might

---

From: <[email-masked]>
Date: Wed, 16 Jun 2010 14:12:46 -0400

> I'm hoping that if we get agreement on the SVR-n choice, that will
guide us to put together a small
> list of choices consistent with that choice.  When I started to list
the ID-n choices in a vacuum,
> the list was way too big.

IMHO, this has gone too far in the other direction.  My view is that
there should be one rule for how NFSv4 treats all domain names (which
may distinguish client->server and server->client directions), and that
a decision about server names needs to be made with that goal in mind.

Nico may agree as he's been talking about domain name slots in general
as opposed to just server names.

Thanks,
--David

> Sent: Wednesday, June 16, 2010 2:01 PM
> To: Black, David; [email-masked]'
> Understood but all the "id@domain" cases have a few additional issues.
Those can be sent by the
> client to the server and also there is an implicit comparison involved
since the server will be
> comparing the domain to the one or ones for which it has mapping
support from user and group names to
> user and group id.
> 
> I'm hoping that if we get agreement on the SVR-n choice, that will
guide us to put together a small
> list of choices consistent with that choice.  When I started to list
the ID-n choices in a vacuum, the
> list was way too big.
guess we're not going to I that
> way.  Each person wants to explain why their choice is the right one.
I just don't think that the
> discussion that is bound to ensue is going to be very productive.  I
want to arrive at some choice
> that everybody can live with, even if nobody thinks it is the right
one.
> Mike Eisler in some earlier discussions has argued for SVR-2 (second
on my list), although at that
> time some issues were not recognized, and his opinion may have
changed.  I'd like to hear how he feels
> now.
> 
> Nico has argued for SVR-3, In the past he has indicated he could
accept SVR-2.  This was before SVR-4
> thru SVR-7 existed so I'd like to know how he feel about things he
will accept (not just what the best
> choice is).  This is particularly the case with SVR-2 and SVR-5.
> 
> In addition, I'd like to hear from anybody who hasn't expressed
himself on this issue that wants to.
> I'd like to see if we can move from a situation in which SVR-2, SVR-3,
and SVR-5, have one advocate
> each.  Here it is: I'm the reasonable one so clearly something is out
of whack.  If you think a
> conference call makes sense, give me some information of your
availability and I'll try to arrange
> something.
> 
> IMHO, we should treat all domain names in the same fashion, and for
that reason, I think punycode A-
> labels are not appropriate because the above entities are going to
turn up in places that won't get
> converted back to Unicode, and the result of not converting punycode
back to Unicode is gibberish in
> any language.  That, plus migration considerations lead me to favor
returned as U-labels.
> 
> I would also add "and MUST NOT be returned as A-label punycode" to
make that clear.
> My reasoning for preferring this over a MUST for U-labels (SVR-4) is
that if some server fails to
> normalize a Unicode domain name, that's not a good reason for a client
to throw up its hands and walk
> away ... but any strange behavior that results at the client is the
server's fault for ignoring this
> "SHOULD" requirement (i.e., failure to carefully weigh the full
implications - see RFC 2119).
> > From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
coming
Let
might
> > > No known comparison of servers, but still providing names that
allow
> > > Clients may have to deal with either, but clients are going to
have to
labels

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 16 Jun 2010 13:21:20 -0500

> a decision about server names needs to be made with that goal in mind.

That's a nice goal, but I believe we must at least analyze the use of
domainnames in user/group names separately from the use of domainnames
as server names for replicas/referrals.  If we can then decide to treat
them all the same, great -- I believe we can.

To restate my position, I'm currently neutral on any of:

 - clients and servers may send un-pre-processed Unicode domainnames
 - clients and servers may send U- and A-labels both
 - clients and servers must sent U-labels only
 - clients and servers must send A-labels only

I believe the last one reflects the current state of affairs in terms of
implementations, at least for one implementation, and probably many
others.  Normally that would be strong incentive to adopt that last one
as the official treatment of IDNs in this protocol, but if it's easy
enough to fix implementations and easy enough for admins to explicitly
stick to A-labels for interop with unfixed deployments, then I believe
all the other options are also feasible.

Dave Noveck, your SRV-* options are... too many to keep track of.  Above
I present just four options that are much easier to track.

Nico
--

---

From: <[email-masked]>
Date: Wed, 16 Jun 2010 14:44:38 -0400

I believe that having one list, unless something is gravely wrong with
it, is much less confusing than having multiple lists and having to map
among them.

Thanks for your prompt response.  I do appreciate it. 

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Wednesday, June 16, 2010 2:21 PM
To: Black, David
Cc: Noveck, David; [email-masked]
Subject: Re: [nfsv4] IDNA choices for servers

Nico
--

---

From: <[email-masked]>
Date: Wed, 16 Jun 2010 14:44:11 -0400

> (which may distinguish client->server and server->client directions)

I don't see the distinction (other than syntactic) between one rule that
distinguishes directions and two rules, one for each direction.  In
either case you'd like the handling of each direction to be consistent
as possible.

But let's adopt your syntactic constraint and see where it takes us.

Let's take SVR-5 as the start and address both directions:

     Domains will be expressed in the form of UTF-8 strings and
     MUST NOT be expressed in A-label format.  When sent by the client
     to the server in A-label format, the server 
         [A. MUST treat that domain and thus id's including it as
             unknown;
          B. MUST return NFS4ERR_INVAL].
     Domains sent in either direction SHOULD be in the canonical U-label
     format.
     When a domain is received by the server and it is not a canonical
     U-label, it SHOULD be treated as the corresponding U-label.
     The server MAY treat UTF-8 domain strings associated with id's as 
     opaque without conversion to a U-label. 

The issue of error return is only applicable to the server receiving
something from the client and the issue of whether the server maps (MUST
or SHOULD) all strings that correspond to a given U-label is likewise
something that only applies to that the server does.

This a pretty big rule and might be divided into sub-rules, but I think
we have the consistency you are looking for.

-----Original Message-----
From: Black, David 
Sent: Wednesday, June 16, 2010 2:13 PM
To: Noveck, David; [email-masked]'
Subject: RE: [nfsv4] IDNA choices for servers

Thanks,
--David

Those can be sent by the
since the server will be
one.
of whack.  If you think a
returned as U-labels.
make that clear.
coming
Let
might
allow
have to
labels

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 17 Jun 2010 17:51:27 -0500

On Mon, Jun 14, 2010 at 01:43:50PM -0400, [email-masked] wrote:
> ...

Reviewing this list, I'm OK with all of these choices.

> SVR-2: Server names MAY be returned as either A-labels or UTF8-strings

My preference for SVR-2 is based on the idea that we can either fix
deployed client implementations to correctly handle non-A-labels (by
applying ToASCII() and/or ToUnicode(ToASCII()) as necessary), and that
where we can't then sysadmins can limit themselves to using A-labels in
these domainname slots.

If my rationale for preferring SRV-2 is overly optimistic, then my
second preference is for SVR-1.

Nico
--

---

From: <[email-masked]>
Date: Tue, 22 Jun 2010 17:29:31 -0400

Since Nico and I say we will accept all the options and David Black has
only indicated he wants SVR-5, one possibility is simply to adopt SVR-5,
but I'm troubled by having asked Nico to accept a wide range of
possibilities and responding "Thanks for being so accommodating.
Because you took my advice, you lose to the guy who selected one".

It occurs to me that there is a possible compromise between SVR-2 and
SVR-5.  I'll call this SVR-8.  Am I doing this just to annoy Nico?  I
don't think so, but one can never be sure.

SVR-8:

     Domains MAY be expressed as A-labels or UTF-8 strings.  They 
     SHOULD be expressed as U-labels.

So here is the statement (BOTH-8) that address both:

     Domains MAY be expressed as A-labels or UTF-8 strings.  They must
be
     valid UTF-8 in any case and the server returns NFS4ERR_INVAL when
     the client sends a string which is not valid UTF-8. 

     When a domain is received by the server and it is not a canonical
     U-label, it SHOULD be treated as the corresponding U-label but if
     it not, it MUST be treated as opaque so that the id and group 
     names returned by the server match those sent by the client.

For completeness, here are.

BOTH-5[AB]:

     Domains will be expressed in the form of valid UTF-8 strings and
     MUST NOT be expressed in A-label format.  The server MUST return
     NFS4ERR_INVAL when the client sends a string which is not valid
UTF-8.   

     When sent by the client to the server in A-label format, the server

BOTH-2:

     Domains may be expressed using A-labels or UTF-8 strings.  When 
     the client sends a string which is not valid UTF-8, the server 
     must return the error NFS4ERR_INVAL. 

     When a domain is received by the server, if it is not either an
     A-label or a U-label, it SHOULD be treated as one of the
     corresponding canonical forms, either A-label or U-label.  If 
     the server does not do so, it MUST treat those domains as
     opaque so that the id and group names returned by the server 
     match those sent by the client.

Since SVR-8 is a merger of SVR-2 and SVR-5, I'm going to assume that
Nico is OK with it unless he tells me otherwise.  I'd like to hear from
David Black as to his opinion.  Also anybody else who isn't
automatically hitting delete on this issue by now.

Within the next few days, I'd like to start on finishing up the revised
Chapter 11 so if you have opinions this issue, let me know.  Note that
this is not a "speak now or forever hold your peace" situation.  There
will be a draft for you to look at a few weeks before Maastricht and if
you are not blown away by its brilliance in resolving these difficult
issues :-), you will be perfectly free to tell the working group why it
is way off the mark.  

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Thursday, June 17, 2010 6:51 PM
To: Noveck, David
Cc: [email-masked]
Subject: SVR-* preferences (Re: [nfsv4] IDNA choices for servers for
replicas/migration/referral) -- Take 2

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 22 Jun 2010 16:47:59 -0500

> Because you took my advice, you lose to the guy who selected one".

If I'd had a strong preference, I'd have stated it.

> don't think so, but one can never be sure.

Funny guy.

>      SHOULD be expressed as U-labels.

That's fine, but note that that SHOULD and MAY imply a MUST on the other
side, and so we should state it.

My version of the same, generalized to handle the SETATTR
(client->server) case:

   Nodes SHOULD send domainnames on the wire as U-labels.  Peers MUST be
   prepared to accept domainnames in A-label, U-label and unprepared
   UTF-8.  Nodes MAY send A-labels for interoperability with IDN-unaware
   peers (ones that don't meet the requirement stated in the previous
   sentence).  Nodes also MAY send unprepared UTF-8.

   Clients and servers both can be nodes (senders) and peers (receivers)
   in this context; clients send domainnames when setting ACLs on
   filesystem objects.

At the end of the second sentence above I'd add this to clarify that
MUST:

   (i.e., they MUST be prepared to apply ToASCII() or
   ToUnicode(ToASCII()) to domainname labels received on the wire prior
   to using them in other domainname slots, and they MUST be prepared
   for those operations to fail)

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 22 Jun 2010 17:01:20 -0500

> So here is the statement (BOTH-8) that address both:

I've agreed in principle and suggested an alternative way of stating SVR-8.

I need to separately respond to this:

>      U-label, it SHOULD be treated as the corresponding U-label ...

What's the point?  When a node receives a domainname in the NFSv4
protocol it should be prepared to apply ToUnicode(ToASCII()) or
ToASCII() to that domainname depending on where the node places that
domainname next.

I.e., if you're going to resolve a domainname (e.g., a replica server or
referral destination) then the receipient MUST apply ToASCII() before
formatting a DNS query.  And if you're going to format an LDAP base DN
using DC name attributes (e.g., in the case of ACL entry subjects) then
the receipient should also apply ToASCII().  But if the receipient is
going to store the domainname for later use then it could store it
as-is, or it could apply either ToUnicode(ToASCII()) or ToASCII() if it
wants to.

This, however:

>                                                             ... but if

can't be implemented.  Many servers will store not name@domain but UIDs,
GIDs, SIDs and such identifiers instead, resolving them back to
name@domain in the GETATTR case as needed.  There's no way to preserve
the form of <domain> between SETATTR and GETATTR in such
implementations.

In the FedFS ADMIN case I think we want to have the server preserve the
form of the domainname when sending fs4_locations to clients.  But
that's another story.

Nico
--

---

From: <[email-masked]>
Date: Wed, 23 Jun 2010 11:22:23 -0400

I'm having trouble with "MUST be prepared".  "MUST" is used to indicate
something you have to do and being prepared seems like a state of mind.
If you try to define the consequences of that state of mind, then you
start getting into the client's interactions with other protocols and
implementations and getting normative there seems better avoided.

I'm OK with "need to be prepared". 

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Tuesday, June 22, 2010 5:48 PM
To: Noveck, David
Cc: [email-masked]
Subject: Re: SVR-* preferences (Re: [nfsv4] IDNA choices for servers for

Funny guy.

Nico
--

---

From: <[email-masked]>
Date: Wed, 23 Jun 2010 11:35:56 -0400

> ToASCII() to that domainname depending on where the node places that

This is the server and the only case I know of where the server receives
a domainname is when it is part of an id or group.  In that case, you
may not place the domainname anywhere, but rather match against a short
list (often a singleton) of domains that you know how to to turn into
numeric uid's and gid's.  So what I'm saying here is that if the domain
part of id@domain is different from what is on your list but that they
map to the same U-label, you SHOULD accept it as equivalent (and return
the U-label on GETATTR as discussed below).

> the form of <domain> between SETATTR and GETATTR in such

I guess I need to clarify.

This is for the case where the SHOULD cannot be implemented.  So there
are two choices:

Preferred (SHOULD) case: 
 
     You accept any form, and give back the U-label.

Non-preferred (MAY) case:

     You accept only one form and give that exact form back.

If you accept multiple forms, then you don't have to retain the
distinction of those forms.    

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Tuesday, June 22, 2010 6:01 PM
To: Noveck, David
Cc: [email-masked]
Subject: Re: SVR-* preferences (Re: [nfsv4] IDNA choices for servers for

> So here is the statement (BOTH-8) that address both:

I've agreed in principle and suggested an alternative way of stating
SVR-8.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 23 Jun 2010 11:02:10 -0500

> something you have to do and being prepared seems like a state of mind.

The fundamental thing about IDNA is that if you have an IDN you have
have to be ready to put it in A-label or U-label form depending on what
you might do with that IDN.  Want to resolve it to an IP address?  The
you MUST put it in A-label form.  That's what the "MUST be prepared
to..." is about.

If we only ever sent A-labels then there'd be no need to say "MUST be
prepared to...".  (You'd want to show users U-labels, but you don't
_have to_.)

> I'm OK with "need to be prepared". 

You mean use indicative mode because this is really a requirement of
IDNA, not ours?  OK, I can live with that.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 23 Jun 2010 11:04:00 -0500

> the U-label on GETATTR as discussed below).

Fine.

>      You accept any form, and give back the U-label.

I thought SVR-8 didn't say SHOULD send U-label, so why make that a
sub-rule just for ACE subject domains?

> distinction of those forms.    

I don't think we need to give two options.  KISS.

Nico
--

---

From: <[email-masked]>
Date: Wed, 23 Jun 2010 18:58:18 -0400

I think I'm ok with this.  I still don't like punycode A-labels on the
wire, but I think that is captured by the "SHOULD" for canonical
U-labels, and I can live with the implied "SHOULD NOT" for A-labels.

Thanks,
--David

Of [email-masked]
> Sent: Tuesday, June 22, 2010 5:30 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [nfsv4] SVR-* preferences (Re: IDNA choices for servers
forreplicas/migration/referral) -
> - Take 2

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 23 Jun 2010 18:12:28 -0500

> U-labels, and I can live with the implied "SHOULD NOT" for A-labels.

Could it be we have consensus?!  :)

(If you really hate A-labels and never want them on the wire then your
only choice is U-labels or raw UTF-8, or either.  But no matter what you
can't avoid having to use A-labels somewhere in the implementation of
the client, the server, or both.  As for avoiding A-labels simply
because they "clash" with the XDR types of the fields in question only
prevents the use of A-labels to interop with old peers that don't know
jack about IDNA -- not really a desirable result.)

Nico
--

---

From: <[email-masked]>
Date: Thu, 24 Jun 2010 09:02:18 -0400

Nico,

> jack about IDNA -- not really a desirable result.)

It's not "hate" - IMHO, NFS use of A-labels on the wire is a design
mistake, because those A-labels are going to leak out into contexts
where they really should not be used.  For example, an ACL config file
that contains domain names in A-label format is just plain wrong from a
human interface standpoint (IMHO) ditto for an ACL config interface that
displays or accepts A-labels.

I understand that A-labels are a necessary intermediate representation
for domain resolution from U-labels to IP addresses, but my preference
is to try to keep A-labels in that functional intermediate
representation "box" as much as possible.  With respect to that goal,
A-labels on the wire distribute domain resolution across client and
server in a fashion that makes no sense to me (i.e., intermediate
representation exposed for no good reason).  I can live with allowing
A-labels on the wire for those whose design preferences don't match mine
and/or for implementations that hit DNS-like constraints which make
U-labels unworkable ... but don't ask me to be enthusiastic about either
situation ;-).

Thanks,
--David

> Sent: Wednesday, June 23, 2010 7:12 PM
> To: Black, David

---

From: <[email-masked]>
Date: Thu, 24 Jun 2010 10:39:55 -0400

Saying that A-labels SHOULD NOT be used seems a reasonable way to
express a lack of enthusiasm. :-) 

-----Original Message-----
From: Black, David 
Sent: Thursday, June 24, 2010 9:02 AM
To: Nicolas Williams
Cc: Noveck, David; [email-masked]
Subject: RE: [nfsv4] SVR-* preferences (Re: IDNA choices for servers
forreplicas/migration/referral) -- Take 2

Nico,

Thanks,
--David

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 24 Jun 2010 12:18:38 -0500

> displays or accepts A-labels.

[Given that we appear to have consensus, all I'm doing here is picking
tangential nits.]

I do not think that accepting A-labels in a UI is "just plain wrong".
It is a fact of life under IDNA that A-labels will leak into some UIs --
that is bad, but really a result of our desire to have IDN interop even
in the face of legacy implementations.  Nor can we say that that desire
is "just plain wrong".  We, the IETF, should not unilaterally force
vendors to either break legacy deployments or backport features --
_that_ would be "just plain wrong".

> U-labels unworkable ... but don't ask me to be enthusiastic about either

This is NOT about aesthetic preferences.  This is about being able to
have servers and domains with non-ASCII characters in them without
causing existing deployments of NFSv4 to fail to use those servers/
domains.  By giving implementors and/or sysadmins the option to send
A-labels on the wire to implementations that don't support IDNA, we
allow those IDNs to work with existing deployments of NFSv4 that don't
support IDNA.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 24 Jun 2010 12:27:08 -0500

> express a lack of enthusiasm. :-) 

I much prefer MAY to SHOULD NOT here.  The rationale for sending
A-labels is simple: to be able to use IDNs with peers that don't
support IDNA (i.e., they don't know that they may need to apply
ToASCII() in order to resolve server names, or to format LDAP base DNs,
etcetera).  As long as we have deployed implementations that don't
support IDNA then we need to retain the option to send A-labels.

The RFC2119 language for "option" is 'OPTIONAL' or 'MAY', not 'SHOULD
NOT' nor 'NOT RECOMMENDED'.

Eventually this MAY can be strengthened to a SHOULD NOT, or even to a
MUST NOT.  At this moment I think SHOULD NOT is too strong.  The
question is: can we write text that captures this?  I think so: say
"nodes MAY send A-labels" and "implementations MAY reject A-labels" and
explain under what circumstances one might do either.

Nico
--

---

From: <[email-masked]>
Date: Thu, 24 Jun 2010 14:17:42 -0400

There's a smiley there.  

We looked at many choices here which ranged from MUST to MUST NOT
regarding A-labels.  You accepted versions that specified MUST NOT but
in light of your concerns we softened that to SHOULD NOT.

I know that you would prefer MAY to SHOULD NOT, but others have the
reverse preference and we need to reach a consensus.  I thought we had
it.  Everybody cannot have their top preference on this issue and people
trying to get it will only mean delay.

If you still feel buyer's remorse on this issue, there will be an
adequate opportunity to discuss this after the draft is out.

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Thursday, June 24, 2010 1:27 PM
To: Noveck, David
Cc: Black, David; [email-masked]
Subject: Re: [nfsv4] SVR-* preferences (Re: IDNA choices for servers

Nico
--