Re: [nfsv4] My probable non-participation in IETF114 meeting -- missing agenda items

[David Noveck <[e-mail]>]

The core issue derives from the following text in RFC7530:

   string sent SHOULD be in the form of one or more U-labels as
   defined by [RFC5890
<https://datatracker.ietf.org/doc/html/rfc5890>].  If that is
impractical, it can instead be in
   the form of one or more LDH labels [RFC5890
<https://datatracker.ietf.org/doc/html/rfc5890>] or a UTF-8 domain
name
   that contains labels that are not properly formatted U-labels.  The
   receiver needs to be able to accept domain and server names in any of
   the formats allowed.  The server MUST reject, using the error
   NFS4ERR_INVAL, a string that is not valid UTF-8, or that contains an
   ASCII label that is not a valid LDH label, or that contains an
   XN-label (begins with "xn--") for which the characters after "xn--"
   are not valid output of the Punycode algorithm [RFC3492
<https://datatracker.ietf.org/doc/html/rfc3492>].

   When a domain string is part of id@domain or group@domain, there are
   two possible approaches:

   1.  The server treats the domain string as a series of U-labels.  In
       cases where the domain string is a series of A-labels or
       Non-Reserved LDH (NR-LDH) labels, it converts them to U-labels
       using the Punycode algorithm [RFC3492
<https://datatracker.ietf.org/doc/html/rfc3492>].  In cases where the
       domain string is a series of other sorts of LDH labels, the
       server can use the ToUnicode function defined in [RFC3490
<https://datatracker.ietf.org/doc/html/rfc3490>] to
       convert the string to a series of labels that generally conform
       to the U-label syntax.  In cases where the domain string is a
       UTF-8 string that contains non-U-labels, the server can attempt
       to use the ToASCII function defined in [RFC3490
<https://datatracker.ietf.org/doc/html/rfc3490>] and then the
       ToUnicode function on the string to convert it to a series of
       labels that generally conform to the U-label syntax.  As a
       result, the domain string returned within a user id on a GETATTR
       may not match that sent when the user id is set using SETATTR,
       although when this happens, the domain will be in the form that
       generally conforms to the U-label syntax.

   2.  The server does not attempt to treat the domain string as a
       series of U-labels; specifically, it does not map a domain string
       that is not a U-label into a U-label using the methods described
       above.  As a result, the domain string returned on a GETATTR of
       the user id MUST be the same as that used when setting the
       user id by the SETATTR.

   A server SHOULD use the first method.




The above text was suggested by David Black based on discussions with
internationalization experts, and had  no problems getting accepted by the
IESG.
.

The first method references RFC 3490, now obsolete, so cannot be
transferred to a new NFSv4 internationalization document

This reference should, almost certainly, not have appeared in RFC7530, but
I'm not sure how it was approved.

It seems very unlikely that the first method was ever implemented by any
NFSv4 server, despite the fact it is recommended above.

The basis of the recommendation is quite unclear and it is not easy to
determine a situation in which the use of the first method would be
needed/desirable.  Further, the use of "SHOULD" leaves unanswered the
question of what are valid reasons to bypass the recommendation.

The existing handling is not transferrable to other NFSv4.  We need to  do
one of the following:

   - eliminate the use of method one.

   - provide an alternative the process in method 1 that does not depend on
RFC3490.



On Mon, Jul 25, 2022, 10:21 PM Benjamin Kaduk <[e-mail]> wrote:

> Hi David,
>
> On Mon, Jul 18, 2022 at 01:05:25PM +0000, Noveck, David wrote:
> >
> >   *   draft-ietf-nfsv4-internationalization is now expired.  In order to
> get it anywhere wglc, I have to address the issues in section 12.
> >
> > I haven't been able to get idna information from the working group or
> the internationalization people. Please provide viable sources on email.
> Ifno willing experts are to be found, will need to do further research and
> may have to update 7530 to not support idna, if that is possible.
>
> While I don't consider myself an internationalization person, I do know a
> few who would probably qualify.  Please forgive my only sporadic
> attentiveness to this list -- is there a clean summary of the open issues
> that I could send to people and ask for help?
>
> Thanks,
>
> Ben
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4p
>