Re: [I18ndir] Early review of draft-dnoveck-nfsv4-internationalization-01

David Noveck <> Tue, 02 June 2020 12:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8385D3A0810 for <>; Tue, 2 Jun 2020 05:40:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kYO-tarRh4lz for <>; Tue, 2 Jun 2020 05:40:16 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5482D3A0808 for <>; Tue, 2 Jun 2020 05:40:16 -0700 (PDT)
Received: by with SMTP id mb16so12597937ejb.4 for <>; Tue, 02 Jun 2020 05:40:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=LN3rqTsG6r2kf4HZiCTYZEJoto9tpc62v9SLYTgIYw0=; b=T2YLEQ2dyiCB7yhIkrOAG37GnNZ6jfid4vzx7uI6uZ/aUB8lquctEa6A7wISAXSF28 Zqvf/qHRjNj47/DWxaUVma14FEkg6yaKt6cIeuMgZUOFrbn53XnVGgJNj2PF1s/UB6SV v6MgVBw7knedk/oIAVA9t611eKIum9Yv5SfcvFMutkOH2nyQ553PgIsOSTtRrEQyIf8N ISuDgRSHi5ZZZx3AaxaQnhDqK5EUurHxUyj5GHPqZBlzh3nGRVrHNAEegssvDRY3H2bX 7oXM6yDCnBoDT7jpMo0LR0cPMHne4zptxUkOjgk7Tx3uBnKdjrwA6ZVUFThqaMwDZtcv t7ng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=LN3rqTsG6r2kf4HZiCTYZEJoto9tpc62v9SLYTgIYw0=; b=fQnGMu9NA9nWbyW/1FYmtBoTD3QKOknasC3BSHRd7I8Afs4H4Q7lEA/pmIBmWtvLvy 8x3x8/U7ErpyAtAI6A7NEsVLXDGTvv+RXjE00TYQ4o6qJv65h1LzEhclj/3SGZwxvtkK pdubcfLh4oPbjKVFdA0gZxoYyLG/zMtaj8/MAmWkxaRTTROSOl0kyjsODfsj9nu80clG 2BjVYnhzGLVlFznRoIlZAO0+Wd84JDN+sp8Pm5sDHOdw9L7CWoWWOYsAHn9X4tgi7DRj 2WgA64cr4A1Gqw7a1qpQmnPPvNn0s7LTbbDiEqHQmGMj7VxVPDh8navtb34o7XK/RjtN S8ow==
X-Gm-Message-State: AOAM5306DgBQ5R3g8/ve+6USxv1yV8Bb9rLIz8kB7kYj9rxKTCzwWSI5 yeyxkDQxc9YCJblxeWAuUeQWN74Mwumpq8O0lUAC3A==
X-Google-Smtp-Source: ABdhPJycVYryYL9T9WbCjJeooP008mKg4C2JOmDUQnIbq2czW9v7P+vNBlfhu83kdpf+GPXDLGGwqDhDhuCAgIuEDXg=
X-Received: by 2002:a17:906:b55:: with SMTP id v21mr5321148ejg.298.1591101614390; Tue, 02 Jun 2020 05:40:14 -0700 (PDT)
MIME-Version: 1.0
References: <20200602060709.GQ18021@localhost>
In-Reply-To: <20200602060709.GQ18021@localhost>
From: David Noveck <>
Date: Tue, 2 Jun 2020 08:40:03 -0400
Message-ID: <>
Content-Type: multipart/alternative; boundary="00000000000087019505a7193655"
Archived-At: <>
Subject: Re: [I18ndir] Early review of draft-dnoveck-nfsv4-internationalization-01
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Internationalization Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Jun 2020 12:40:19 -0000

On Tue, Jun 2, 2020 at 2:07 AM Nico Williams <> wrote:

> I have reviewed draft-dnoveck-nfsv4-internationalization.

> In my opinion, this draft is extremely important to the Internet
> community and beyond, and should progress.  This being an early review,
> perhaps I should stop there.

In any case, you chose not to, which makes sense to me.   I find your
remarks interesting  even if though I do not agree with all of them.

> However, there is an important, long-running, low-volume debate to
> finally settle here, and it has to be settled in the I18N community.
> Fair enough, but I worry about the prospect of turning a long-running
low-volume debate into a long-running high-volume debate.

It would be nice to finally settle this but if it is not settled soon, this
is not going to help me.   Still, you will do what you think is best for
I18N overall and I'll try to adjust.

The architectures and realities of the relevant operating systems makes
> it impossible for us to practicably put the onus for I18N on the
> filesystem _protocols_.

I agree.

> No, that onus can _only_ live in the
> _filesystems_.

It's been placed on the protocols for a considrable time and the results
have not been all that positive.

Placing it on the filesytems would be an interesting alternative,but
filesystems are not really someting the IETF is charged with
standardizing.    It might be possible to create rules for filesystems used
by internet fileystems protocols and I would support such an effort.

> I cannot stress this enough.
> I think you stress it adequately.   Although there may well be resistance
to your views, I'm not sure additional stress on your valid points is the
answer.   I have to object to the word "only" as shared resposibility for
this might be viable approch.

> If you stop reading here, you can take just the above paragraph with you
> and consider it carefully.  If you continue reading, please forgive me
> for the length of this post.

I don't have a problem with the length of this post.   However, it will
take a while to respond to most of it.

> The document at hand is almost entirely dedicated to convincing the
> present audience of the above premise and fact.  Most of the first ten
> pages are non-normative text, and when it gets to what happens in
> reality... it's essentially still informative rather than normative
> text.

Given the nature of what this document and RFC7530 sought to do, it is
wrong consider "normative" and "informative" as alternatives.   It does not
seek to create norms but presents existing norms so that interoperable
implementations can be created.   These norms are derived from
existing implementations, since there are many implemtation that do not
follow the normative descriptions in RFC3530 and RFC5661 and many that do
follow RFC7530.

The I-D even modifies the meaning of RFC2119 so it can pretend to
> be normative while not really being normative,

The document does not modify the *meanings*  of the terms defined in

Section 2.1 affirms these meanings and does not appear with fingers
crosed.   Section 2.2 explain how the sttements in this document were
derived and are still compatible with Section 2.1.   This is the same
approach used in RFC7530 and the IESG had no problem with it.

all so it can continue
> the fiction that I18N belongs in NFSv4

I don't see how you can first point out that I agree with you on where
responsibility for this matter is best placed and then accuse (I think that
is the right word) me of collaborating in an effort to impose this supposed
fiction on the internet community.

For the record, while I feel that assigning the responsibility for this to
NFSv4 was a misjudgement that I would prefer to see corrected, there is no
way it can be categorized as a "fiction".  In any case, regardless of where
the responsibility for this matter is best placed, people implementing
NFSv4 clients andservers need reliable guidance of how they (and the
filesystems servers export) need to deal with internationalization issues.

> (and what about WebDAV? and SFTP? and ...?)

What about them?  I don't say anything about them because I don't know
anything about them, and feel it is best to get internationalization for
all minor versions of NFSv4 documented clearly, in order to be compatible
with an eventual rfc5661bis.

> and not in the filesystem.

My document does give appropriate attention to the role of the file
system.    While I agree it would probably be better to assign
responsibility in a more formal way, I'm not sure that is possible in a
resaonable time frame.   Note that the milestone for this document is
12/2020 and while that can move if necessary, this is needed for
rfc5661bis (no target date yet, but anything beyond two years might as well
be "never").

> Nico
> --