Re: [nfsv4] New section 12 for internationalization document

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

On Sep 13, 2022, at 2:02 AM, David Noveck <[e-mail]<mailto:[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?

Unfortunately I don't have any idea how to answer any of these questions. Since NetApp has a Linux team that you have some influence over, can you ask them to test it for you?


On Mon, Sep 12, 2022, 5:12 PM Chuck Lever III <[e-mail]<mailto:[e-mail]>> wrote:


> On Sep 6, 2022, at 2:16 PM, Noveck, David <David.Noveck=[e-mail]<mailto:[e-mail]>> wrote:
>
>
>
> The attached is prompted by the advice about the subject that I received from David Black and the implementation information that Chuck Lever and Rick Macklem provided.
>
> Thanks for all the help.
>
> The goal of the revised section 12 is to not make existing server implementations non-compliant while also not making a server implementation that conforms to rfc7530 non-compliant.  There is a possibility that clients that conform to rfc7530 and use strings beginning with "xn--" will become non-compliant but since these would not work with many existing servers, I'm not particularly worried about that happening.
>
> Please look at the attached and comment.  I intend to submit internationalization-02 in about a week.

The Solaris team has reported test-based answers to earlier questions
about their implementation of i18n support for NFSv4.


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

1) SMF

sharectl(8) and SMF accept and store both internationalized domain names,
IDN ( GermanäÄüÜöÖ߀.domain.de<http://xn--lzg.domain.de/> ) [1] and Punycode transcripted domain,
names ACE-strings [2] ( xn--german-gta3ba4pa4ea5864i.domain.de<http://xn--german-gta3ba4pa4ea5864i.domain.de/> ) for the
corresponding SMF property value.

2) NFSMAPID

nfsmapid(8) verifies and tests the domainname portion based on
the rules and recommendations from RFC1033 and RFC1035

RFC 1033  DOMAIN ADMINISTRATORS OPERATIONS GUIDE
https://www.rfc-editor.org/rfc/rfc1033.html

RFC 1035 DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
https://www.rfc-editor.org/rfc/rfc1035.html
https://www.rfc-editor.org/rfc/rfc1035.html#section-2.3.1

which where valid at the time of our NFSv4 implementation back
in Solaris 10, (GA 3/2005).

Currently nfsmapid(8) rejects IDNs outside the
range of documented values of isalpha() and isdigit()
per ctype(3C). Ie. the German IDNs with German Umlauts [3]
are rejected by nfsmapid(8) as invalid domainnames
and the fallback DNS domainname on the system is used instead.

However, nfsmapid(8) does accept Punycode ACE strings
as domainnames and passes those up for usage.

3) NFS OTW

As 2) implies, IDNs outside the usual ASCII sets/locale settings
are rejected as NFSv4 domainnames and are thus not usable [5].
Ie. the domainname including German Umlauts is not usable.

However, Punycode ACE strings as domainnames do work and
are send OTW and are properly used on both the server
and the client side [6]. Solaris does not apply any translation
of Punycode ACE strings representing domains, they are just
passed around like any other regular domainname.


--
Chuck Lever



_______________________________________________
nfsv4 mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever