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

["Black, David" <[e-mail]>]

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

Unfortunately, the concept of case independence is significantly more complex in Unicode.  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): 

   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.

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

Thanks, --David

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