Re: [nfsv4] New section 12 for internationalization document

David Noveck <davenoveck@gmail.com> Tue, 13 September 2022 09:02 UTC

Return-Path: <davenoveck@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C0CC1526EC for <nfsv4@ietfa.amsl.com>; Tue, 13 Sep 2022 02:02:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOk1FW-_Iici for <nfsv4@ietfa.amsl.com>; Tue, 13 Sep 2022 02:02:39 -0700 (PDT)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2A98C15257D for <nfsv4@ietf.org>; Tue, 13 Sep 2022 02:02:34 -0700 (PDT)
Received: by mail-ed1-x52e.google.com with SMTP id a41so4693503edf.4 for <nfsv4@ietf.org>; Tue, 13 Sep 2022 02:02:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=CAOU6nOgmHVcp3Nf9ZYUeb5hdD6SjW5S+O+vMOD72DI=; b=hQQJM6H2hATket1+tN7yeoxXkHwYLXLvjMrj85dWRtjsgwBKnM91DR4p2k858Sn1Zf zP2YJHXnHXwj24qPbEMqkLtBqO7Jliq4ijZChPmDJriPFBHUp5PbUtanUbyL3HYZjK5G WTFXIpbYU7YIcTe6JrzWCix4F5mJFaPmiewbs+eVLgTb5QRQD6ZRdrANuwVr2+FaUaSZ p2eL3CPZ+zCR7OhAl+Dj0EEn1gB9m5budNMrjmVHS/gkPwgGoG4si9LgD/POjxVWJn+H 8TJEoN5FtPEzt/CVIukRF2orYwMarowO4Db5sNeos8FlWuwpMGrZ6NdOUQ9yrTzzLEUU xqag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=CAOU6nOgmHVcp3Nf9ZYUeb5hdD6SjW5S+O+vMOD72DI=; b=YNJAAlfdsVRw3mtPf1xrH/Lrh8rXvKMRnbgPfrxs+fABgGQVc0Eb5jHtwrvmiA2b5O NY6XsC445Bna9iT4gMMptBuI5YueaRL150JCtbDrvvNpsYC3gn/TjOK8f5HdfpF7Vrmf uXQudojvu93zHf0tonIgS01NSFWwvh50lCDwWMimSzepBEUO0ni4uZ9HhVWqOa3Cgzd0 Z27pq65SOame+kd03Kx/HHqPHUJ3FwXVjLJl5h8m1x1QIeFw4pjS8MIrLSuJ6bXHbIOw 3pKLxiwsiRON3O9bd/eniotTNcfnKoLU7HzvKx08io2xFjeHYK0VPj+hZLa2kXgTOzWZ N0Aw==
X-Gm-Message-State: ACgBeo3t7FSgH8m1FfoKnngtYf+tvpQrfBkF7uAembVG0kB4/WBZ30eq g37/5rR2LQCz/jmnXESkjZJDLEBEQEoRlPFT9Hg=
X-Google-Smtp-Source: AA6agR6DWcDcTPk1x3OLnojqmX0hnHN/XUgDhHEnLBIbwkfXbMWLf8we9mm43hW6zZZMyD8XD/E1AVpv2cSdicIE20c=
X-Received: by 2002:a05:6402:1f01:b0:445:fbe8:4b2e with SMTP id b1-20020a0564021f0100b00445fbe84b2emr25122583edb.192.1663059752749; Tue, 13 Sep 2022 02:02:32 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR06MB5597CEAA47B4C87F7402B7F9E17E9@MN2PR06MB5597.namprd06.prod.outlook.com> <49434285-C3D1-4D5C-8B0A-138805C8FF03@oracle.com>
In-Reply-To: <49434285-C3D1-4D5C-8B0A-138805C8FF03@oracle.com>
From: David Noveck <davenoveck@gmail.com>
Date: Tue, 13 Sep 2022 05:02:20 -0400
Message-ID: <CADaq8jcB0a6mPya5ZXAUqySFj+9ta8x7-BKWFW2m2VhAKLryHg@mail.gmail.com>
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: "Noveck, David" <David.Noveck=40netapp.com@dmarc.ietf.org>, NFSv4 <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cd8ffa05e88b451d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/xgdzPl0o46pmeD5fYSxzUGlkS74>
Subject: Re: [nfsv4] New section 12 for internationalization document
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Sep 2022 09:02:43 -0000

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?

On Mon, Sep 12, 2022, 5:12 PM Chuck Lever III <chuck.lever@oracle.com>
wrote:

>
>
> > On Sep 6, 2022, at 2:16 PM, Noveck, David <David.Noveck=
> 40netapp.com@dmarc.ietf.org> 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 ) 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
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>