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

[David Noveck <[e-mail]>]

On Tue, Aug 2, 2022, 9:33 AM Black, David <[e-mail]> wrote:

> >>>       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.
> >>
> >>I would expect server implementations to do exactly that, but it'd be
> good >to check - would compliance with that "MUST" be a problem for any
> >known implementations?
> >>
> >>If so, please explain how the GETATTR and SETATTR user id values could
> >differ.
> > For the FreeBSD name<->id mapping daemon, the domain string is
> > considered to be case independent.
> > i.e., UoGuelph.ca is considered the same as uoguelph.ca
> > I think I did this because that is how DNS host domain names have
> > traditionally been handled.
>

It appears they can't be now.  How disruptive would it be to change this
for ASCII names?

>
> Unfortunately, the concept of case independence is significantly more
> complex in Unicode.


It is not only more complex. You cannot do case conversion using the text
string alone.

A common example is that in ASCII, 'i' is the lower-case counterpart of
> 'I', but that's not always the case for Unicode, e.g., in Turkish, the
> lower case counterpart of 'I' is U+0131 (&inodot), LATIN SMALL LETTER
> DOTLESS I (https://en.wikipedia.org/wiki/Dotless_I), and applying ASCII
> case independence produced incorrect results, as there are words in Turkish
> that differ only in dotted-i vs. dotless-i.
>
> The "method one" that is proposed for elimination dealt with Unicode case
> insensitivity via use of ToASCII and ToUnicode - Unicode case mapping is
> buried in the NAMEPREP step.  Unfortunately, the entire NAMEPREP framework
> (including those mechanisms) is obsolete for a number of good reasons,
> including its dependence on a specific version of Unicode.  Case
> insensitivity of domain names has been moved to input processing, as
> indicated by this item in Appendix A of RFC 5891 (
> https://datatracker.ietf.org/doc/html/rfc5891#appendix-A):


Method one has to go.


>
>    4.   Remove the mapping and normalization steps from the protocol and
>         have them, instead, done by the applications themselves,
>         possibly in a local fashion, before invoking the protocol.
>

This doesn't address cases in which the domain name is formulated by the
server. There is no obvious "application" on the server.  The important
case is multiple domains in multi-server namespace.


> For NFS, the likely upshot is that language/locale-dependent (case)
> mapping and normalization has to be done by the client or code above it.


That works for mount and the client side of referrals.  To deal with this
in full, we should simply say the protocol does modify the domain to either
an equivalent one with a  changed case or a canonically equivalent one.

ASCII case insensitivity would be safe for a server that enforces a
> restriction to 7-bit ASCII, but it's not safe in general for UTF-8.
>

Yes but not sure what spec should say about that case



> Thanks, --David.


Thanks for the guidance.  Will provide an updated section for discussion in
about a week. After that, will try to produce internationalization-02.

>
> -----Original Message-----
> From: Rick Macklem <[e-mail]>
> Sent: Monday, August 1, 2022 8:37 PM
> To: Black, David; David Noveck
> Cc: NFSv4
> Subject: Re: [nfsv4] My probable non-participation in IETF114 meeting --
> missing agenda items
>
>
> [EXTERNAL EMAIL]
>
> Black, David <David.Black=[e-mail]> wrote:
> >Dave,
> >
> >> The core issue derives from the following text in RFC7530:
> >
> >[ ... SNIP ...]
> >
> >> The above text was suggested by David Black based on discussions with
> internationalization experts, and had no problems getting accepted by the
> IESG.
> >
> >In light of what has (not) transpired since then ...
> >
> >> 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.
> >
> >... while I could patch the text to deal with RFC 3490 being obsolete, I
> think "running code" wins this one ... i.e., I suggest that the WG proceed
> to:
> >
> >>    - eliminate the use of method one.
> >
> >That creates a small item to deal with, as method 2 contains a "MUST"
> >requirement that would apply to all implementations:
> >
> >
> >>       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.
> >
> >I would expect server implementations to do exactly that, but it'd be
> good >to check - would compliance with that "MUST" be a problem for any
> >known implementations?
> >
> >If so, please explain how the GETATTR and SETATTR user id values could
> >differ.
> For the FreeBSD name<->id mapping daemon, the domain string is
> considered to be case independent.
> ie. UoGuelph.ca is considered the same as uoguelph.ca
> I think I did this because that is how DNS host domain names have
> traditionally been handled.
>
> rick
>
> Thanks, --David
>
> From: nfsv4 <[e-mail]> On Behalf Of David Noveck
> Sent: Thursday, July 28, 2022 9:57 AM
> To: Benjamin Kaduk
> Cc: Noveck, David; NFSv4
> Subject: Re: [nfsv4] My probable non-participation in IETF114 meeting --
> missing agenda items
>
>
> [EXTERNAL EMAIL]
> 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 [datatracker.ietf.org]<
> https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc5890__;!!LpKI!gD1BRtFwwUpp8etNt74yc4T_v57MvYaRpGrXsWpU9X61X1wbdZB1UvN3ftbQldXRpIblsAw3UTPVR6jQoVSp$>].
> If that is impractical, it can instead be in
>
>    the form of one or more LDH labels [RFC5890 [datatracker.ietf.org]<
> https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc5890__;!!LpKI!gD1BRtFwwUpp8etNt74yc4T_v57MvYaRpGrXsWpU9X61X1wbdZB1UvN3ftbQldXRpIblsAw3UTPVR6jQoVSp$>]
> 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 [
> datatracker.ietf.org]<
> https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc3492__;!!LpKI!gD1BRtFwwUpp8etNt74yc4T_v57MvYaRpGrXsWpU9X61X1wbdZB1UvN3ftbQldXRpIblsAw3UTPVR8HVeyrh$
> >].
>
>
>
>    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 [datatracker.ietf.org]<
> https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc3492__;!!LpKI!gD1BRtFwwUpp8etNt74yc4T_v57MvYaRpGrXsWpU9X61X1wbdZB1UvN3ftbQldXRpIblsAw3UTPVR8HVeyrh$>].
> 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 [
> datatracker.ietf.org]<
> https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc3490__;!!LpKI!gD1BRtFwwUpp8etNt74yc4T_v57MvYaRpGrXsWpU9X61X1wbdZB1UvN3ftbQldXRpIblsAw3UTPVRw5pOT9y$>]
> 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 [
> datatracker.ietf.org]<
> https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc3490__;!!LpKI!gD1BRtFwwUpp8etNt74yc4T_v57MvYaRpGrXsWpU9X61X1wbdZB1UvN3ftbQldXRpIblsAw3UTPVRw5pOT9y$>]
> 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]<mailto:
> [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]<mailto:[e-mail]>
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/nfsv4__;!!LpKI!j7NGRO1t2zpt74VohXnTaCVcI5yF4q6IlWSmly-txDjG1Zsps-m41aBflmY1EC2eDKCuH3y92J99lxNwrwyZXw$
> [ietf[.]org] [ietf.org]<
> https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/nfsv4__;!!LpKI!gD1BRtFwwUpp8etNt74yc4T_v57MvYaRpGrXsWpU9X61X1wbdZB1UvN3ftbQldXRpIblsAw3UTPVR46uD3g8$
> >p
>