Re: [nfsv4] New section 12 for internationalization document

[Chuck Lever III <[e-mail]>]

> On Sep 13, 2022, at 5:02 AM, David Noveck <[e-mail]> wrote:
> 
> It appears that Solaris will not accept a U-label containing an umlaut and requires that the client send the corresponding xn-label.
> 
> That's incompatible with internationalization-02 😞
> 
> To come up with an appropriate adjustment, I need the corresponding information for Linux:
> 
> Will the server accept a U-label containing an umlaut?
> 
> Will it accept the corresponding xn-label?
> 
> What does the Linux client do with domains containing umlauts?


Network capture details are available; email me privately. Summary below.


###
### Internationalized domain names and Oracle Linux NFS
###

Investigated on Oracle Linux 8.6 UEK6/UEK7 with nfs-utils-2.3.3-51.

The current state of the Oracle Linux NFS framework handling
internationalized domain names is the following:

1) idmapd.conf(5) and nfsidmap(5) accept and store both internationalized
domain names, IDN ( GermanäÄüÜöÖ߀.domain.de ) and Punycode transcripted domain
names ACE-strings ( xn--german-gta3ba4pa4ea5864i.domain.de ) for the 
systems NFSv4 domain.

2) nfsidmap(5)

Does accept both IDNs and Punycode ACE strings as domainnames.

3) NFS OTW

As can be observed with tcpdump(8) and tshark(1) both 
IDN or ACE string representation being used in the configuration,
are send IDNs OTW. Ie. the domainname including German Umlauts as IDN
is usable in the same way as its Punycode transcription in the
configuration.

4) noteworthy:

When performing the IDN testing I noted some odd behavior in
the network traces. In this case the servers READDIR reply for example
presented a mix of the IDN domain and the DNS domain as you can
see here for the Owner using the DNS domain and for the
Owner_Group using the IDN domain [1]:

<snip>
                      reco_attr: Owner (36)
                            fattr4_owner: [e-mail]
                                length: 18
                                contents: [e-mail]
                                fill bytes: opaque data
                        reco_attr: Owner_Group (37)
                            fattr4_owner_group: fbatschu@German���������
                                length: 42
                                contents: fbatschu@German���������
                                fill bytes: opaque data
<snip end>

in contrast, the servers READDIR reply when the ACE-string configuration
was tested, I've seen consistent results:

<snip>
                        reco_attr: Owner (36)
                            fattr4_owner: fbatschu@German���������
                                length: 42
                                contents: fbatschu@German���������
                                fill bytes: opaque data
                        reco_attr: Owner_Group (37)
                            fattr4_owner_group: fbatschu@German���������
                                length: 42
                                contents: fbatschu@German���������
                                fill bytes: opaque data
<snip end>

Or another test [2] with IDN domain that showed this READDIR reply
from the server, using the ACE-string instead, from where - I don't know?

<snip>
                        reco_attr: Owner (36)
                            fattr4_owner: [e-mail]
                                length: 47
                                contents: [e-mail]
                                fill bytes: opaque data
                        reco_attr: Owner_Group (37)
                            fattr4_owner_group: [e-mail]
                                length: 47
                                contents: [e-mail]
                                fill bytes: opaque data
<snip end>


--
Chuck Lever