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

[David Noveck <[e-mail]>]

In attempting to rewrite section 12 on an as-implemented basis, I find I
need some information about how existing servers and clients deal with
internationalized domain names.

With regard to servers, I need to know how they deal with domain strings
beginning with "xn--":
   - do they simply treat such strings as
     presented, ignoring the Idna
     convention?
   - do they translate the portion past "--"
     from punycode to Unicode?
   - do they follow the recommended
     approach in rfc7530 (unlikely but
     possible)

Also need to know what checks are done for label   validity. In particular,
how/if checks for valid UTF-8 are done.

With regard to clients, need to know if any generate domain strings
beginning with "xn--.






On Tue, Aug 9, 2022, 11:06 AM David Noveck <[e-mail]> wrote:

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