Internationalization for the NFSv4 Protocols
draft-dnoveck-nfsv4-internationalization-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Author | David Noveck | ||
| Last updated | 2020-03-09 | ||
| Replaced by | draft-ietf-nfsv4-internationalization | ||
| RFC stream | (None) | ||
| Formats | |||
| Reviews |
I18NDIR Early review
by Nicolás Williams
On the Right Track
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-dnoveck-nfsv4-internationalization-01
NFSv4 D. Noveck
Internet-Draft NetApp
Updates: 5661, 7530 (if approved) March 9, 2020
Intended status: Standards Track
Expires: September 10, 2020
Internationalization for the NFSv4 Protocols
draft-dnoveck-nfsv4-internationalization-01
Abstract
This document describes the handling of internationalization for all
NFSv4 protocols, including NFSv4.0, NFSv4.1, NFSv4.2 and extensions
thereof, and future minor versions.
It updates RFC7530 and RFC5661.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2020.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Noveck Expires September 10, 2020 [Page 1]
Internet-Draft NFSv4 Inernationalization March 2020
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language Definition . . . . . . . . . . . . 4
2.2. Requirements Language Derivation . . . . . . . . . . . . 4
3. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Limitations on Internationalization-Related Processing in the
NFSv4 Context . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Summary of Server Behavior Types . . . . . . . . . . . . . . 10
6. String Encoding . . . . . . . . . . . . . . . . . . . . . . . 11
7. Normalization . . . . . . . . . . . . . . . . . . . . . . . . 12
8. String Types with Processing Defined by Other Internet Areas 12
8.1. Effect of IDNA Changes . . . . . . . . . . . . . . . . . 14
8.2. Potential Compatibility Issues Related to IDNA Changes . 15
9. Errors Related to UTF-8 . . . . . . . . . . . . . . . . . . . 17
10. Servers That Accept File Component Names That Are Not Valid
UTF-8 Strings . . . . . . . . . . . . . . . . . . . . . . . . 18
11. Future Minor Versions and Extensions . . . . . . . . . . . . 19
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
13. Security Considerations . . . . . . . . . . . . . . . . . . . 20
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
14.1. Normative References . . . . . . . . . . . . . . . . . . 21
14.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
Internationalization is a complex topic with its own set of
terminology (see [19]). The topic is made more complex for the NFSv4
protocols by the tangled history described in Section 3. This
document is based on the actual behavior of NFSv4 client and server
implementations (for all existing minor versions) and is intended to
serve as a basis for further implementations to be developed that can
interact with existing implementations as well as those to be
developed in the future.
Note that the behaviors on which this document are based are each
demonstrated by a combination of an NFSv4 server implementation
proper and a server-side physical file system. It is common for
servers and physical file systems to be configurable as to the
behavior shown. In the discussion below, each configuration that
shows different behavior is considered separately.
Noveck Expires September 10, 2020 [Page 2]
Internet-Draft NFSv4 Inernationalization March 2020
As a consequence of this choice, normative terms defined in RFC2119
[1] are derived from implementation behavior, rather than the other
way around, as is more commonly the case. The specifics are
discussed in Section 2.
With regard to the question of interoperability with existing
specifications for NFSv4 minor versions, different minor versions
pose different issues.
o With regard to NFSv4.0 as defined in RFC7530 [3], no significant
interoperability issues are expected to arise because the
internationalization in that specification, which is the basis for
this one, was also based on the behavior of existing
implementations. Although, in a formal sense, the treatment of
internationalization here supersedes that in RFC7530 [3], the
treatments are intended to be essentailly the same in order to
eliminate interoperability issues.
Because of a change in the handling of Internationalized domain
names, there are some differences from the handling in RFC7530
[3], as discussed in Section 3. For a discussion of those
differences and potential compatibility issues, see Sections 8.1
and 8.2.
o With regard to NFSv4.1 as defined RFC5661 [4], the situation is
quite different. The approach to internationalization specified
in that document was never implemented, and implementers were
either unaware of the troublesome implications of that approach or
chose to ignore the existing specification as essentially
unimplementable. An internationalization approach compatible with
that specified in RFC7530 [3] tended to be followed, despite the
fact that, in other respects, NFSv4.1 considered to be a separate
protocol.
If there were NFSv4 servers who obeyed the internationalization
dictates within RFC5661 [4], or clients that expected servers to
do so, they would fail to interoperate with typical clients and
servers when dealing with non-UTF8 file names, which are quite
common. As no such implementation have come to our attention, it
has to be assumed that they do not exist and interoperability with
existing implementations as described here is an appropriate basis
for this document.
2. Requirements Language
Noveck Expires September 10, 2020 [Page 3]
Internet-Draft NFSv4 Inernationalization March 2020
2.1. Requirements Language Definition
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as BCP 14 [1] [2] when, and only when,
they appear in all capitals, as shown here.
2.2. Requirements Language Derivation
Although the key words "MUST", "SHOULD", and "MAY" retain their
normal meanings, as described above, we need to explain how the
statements involving these terms were defined. In the case of
statements within Section 8, these derive from the requirements of
other internet specifications. However, in other cases, this
specification's descriptions was derived from existing implementation
patterns requiring that we explain how the normative terms used
derive from the behavior of existing implementations, in those
situations in which existing implementation behavior patterns can be
determined.
o Behavior implemented by all existing clients or servers is
described using "MUST", since new implementations need to follow
existing ones to be assured of interoperability. While it is
possible that different behavior might be workable, we have found
no case where this seems reasonable.
The converse holds for "MUST NOT": if a type of behavior poses
interoperability problems, it MUST NOT be implemented by any
existing clients or servers.
o Behavior implemented by most existing clients or servers, where
that behavior is more desirable than any alternative, is described
using "SHOULD", since new implementations need to follow that
existing practice unless there are strong reasons to do otherwise.
The converse holds for "SHOULD NOT".
o Behavior implemented by some, but not all, existing clients or
servers is described using "MAY", indicating that new
implementations have a choice as to whether they will behave in
that way. Thus, new implementations will have the same
flexibility that existing ones do.
o Behavior implemented by all existing clients or servers, so far as
is known -- but where there remains some uncertainty as to details
-- is described using "should". Such cases primarily concern
details of error returns. New implementations should follow
Noveck Expires September 10, 2020 [Page 4]
Internet-Draft NFSv4 Inernationalization March 2020
existing practice even though such situations generally do not
affect interoperability.
There are also cases in which certain server behaviors, while not
known to exist, cannot be reliably determined not to exist. In part,
this is a consequence of the long period of time that has elapsed
since the publication of the defining specifications, resulting in a
situation in which those involved in t implementation work may no
longer be involved in or aware of working group activities.
In the case of possible server behavior that is neither known to
exist nor known not to exist, we use "SHOULD NOT" and "MUST NOT" as
follows, and similarly for "SHOULD" and "MUST".
o In some cases, the potential behavior is not known to exist but is
of such a nature that, if it were in fact implemented,
interoperability difficulties would be expected and reported,
giving us cause to conclude that the potential behavior is not
implemented. For such behavior, we use "MUST NOT". Similarly, we
use "MUST" to apply to the contrary behavior.
o In other cases, potential behavior is not known to exist but the
behavior, while undesirable, is not of such a nature that we are
able to draw any conclusions about its potential existence. In
such cases, we use "SHOULD NOT". Similarly, we use "SHOULD" to
apply to the contrary behavior.
In the case of a "MAY", "SHOULD", or "SHOULD NOT" that applies to
servers, clients need to be aware that there are servers that may or
may not take the specified action, and they need to be prepared for
either eventuality.
3. History
The history of internationalization within NFSv4 is discussed in this
section. Despite the fact that NFSv4.0 and subsequent minor versions
have differed in many ways, the actual implementations of
internationalization have remained the same and internationalized
names have been handled without regard to the minor version being
used. As a result, this document is able to treat
internationalization for all NFSv4 minor versions together.
During the period from the publication of RFC3010 [14] until now, two
different perspectives with regard to internationalization have been
held and represented, to varying degrees, in specifications for NFSv4
minor versions.
Noveck Expires September 10, 2020 [Page 5]
Internet-Draft NFSv4 Inernationalization March 2020
o The perspective held by NFSv4 implementers treated most aspects of
internationalization as basically outside the scope of what NFSv4
client and server implementers could deal with. This was because
the POSIX interface treated filenames as uninterpreted strings of
bytes, because the file systems used by NFSv4 servers treated
filenames similarly, and because those file systems contained
files with internationalized names using a number of different
encoding methods, chosen by the users of the POSIX interface.
From this perspective, wider support for internationalized names
and general use of universal encodings was a matter for users and
applications and not for protocol implementers or designers.
o Within the IETF in general and in the IESG, there was a feeling
that new protocols, such as NFSv4, could not avoid dealing with
internationalization issues, making it difficult to treat these
matters, as the implementers' perspective would have it, as
essentially out of scope.
As specifications were developed, approved, and at times rewritten,
this fundamental difference of approach was never fully resolved,
although, with the publication of RFC7530 [3], a satisfactory modus
vivendi may have been arrived at.
Although many specifications were published dealing with NFSv4
internationalization, all minor versions used the same implementation
approach, even when the current specification for that minor version
specified an entirely different approach. As a result, we need to
treat the history of NFSv4 internationalization below as an
integrated whole, rather than treating individual minor versions
separately.
o The approach to internationalization specified in RFC3010 [14]
sidestepped the conflict of approaches cited above by discussing
the reasons that UTF-8 encoding was desirable while leaving
filenames as uninterpreted strings of bytes. The issue of string
normalization was avoided by saying "The NFS version 4 protocol
does not mandate the use of a particular normalization form at
this time."
Despite this approach's inconsistency with general IETF
expectations regarding internationalization, RFC3010 was published
as a Proposed Standard. NFSv4.0 implementation related to
internationalization of filenames followed the same paradigm used
by NFSv3, assuring interoperability with files created using that
protocol, as well as with those created using local means of file
creation.
Noveck Expires September 10, 2020 [Page 6]
Internet-Draft NFSv4 Inernationalization March 2020
o When it became necessary, because of issues with byte-range
locking, to create an rfc3010bis, no change to the previously
approved approach seemed indicated and the drafts submitted up
until [21] closely followed RFC3010 as regards
internationalization. The IESG then decided that a different
approach to internationalization was required, to be based on
stringprep [15] and rfc3010bis was accordingly revised, replacing
all of the Internationalization section, before being published as
RFC3530 [18].
These changes required the rejection of file names that were not
valid UTF-8, file names that included code points not, at the time
of publication, assigned a Unicode character (e.g. capital eszett)
or that were not allowed by stringprep (e.g. Zero-width joiner
and non-joiner characters). Because these restrictions would have
caused the set of valid file names to be different on NFS-mounted
and local file systems there was no chance of them ever being
implemented.
Because these specification changes were made without working
group involvement, most implementers were unaware of them while
those who were aware of the changes ignored them and continued to
develop implementations based on the internationalization approach
specified in RFC3010.
o When NFsv4.1 was being developed, it seemed that no changes in
internationalization would be required. Many people were unaware
of the stringprep-based requirements which made the NFSv4.0
internationalization specified in RFC3530 unimplementable. As a
result, the internationalization specified in RFC5661 [4] was the
same as that in RFC3530.
As a result, even though NFSv4.1 was a separate protocol and could
have had a different approach to internationalization, for a
considerable time, internationalization for both protocols was
specified to be the same (in RFC3530 and RFC5661) while the actual
implementations of the two minor versions both followed the
approach specified in RFC3010, despite its obsoleted status.
o When work started on rfc3530bis it was clear that issues related
to internationalization had to be addressed. When the
implications of the stringprep references in RFC3530 were
discussed with implementers it became clear that mandating that
NFSv4.0 filenames conform to stringprep was not appropriate.
While some working group members articulated the view that,
because of the need to maintain compatibility with the POSIX
interface and existing file systems, internationalization for
NFSv4 could not be successfully addressed by the IETF, the
Noveck Expires September 10, 2020 [Page 7]
Internet-Draft NFSv4 Inernationalization March 2020
rfc3530bis draft submitted to the IESG did not explicitly embrace
the implementers' perspective set forth above.
The draft submitted to the IESG and RFC7530 [3] as published
provided an explanation (see Section 4) as to why restrictions on
character encodings were not viable. It allowed non-UTF-8
encodings to be used for internationalized filenames while
defining UTF-8 as the preferred encoding and allowing servers to
reject non-UTF-8 string as invalid. Other stringprep-based string
restrictions were eliminated. With regard to normalization, it
continued to defer the matter, leaving open the possibility that
one might be chosen later.
This approach is compatible, in implementation terms, with that
specified in RFC3010 [14], allowing it to be used compatibly with
existing implementations for all existing minor versions. This is
despite the fact that RFC5661 [4] specifies an entirely different
approach.
As a result of discussions leading up to the publishing of
RFC7530, it was discovered that some local file systems used with
NFSv4 were configured to be both normalization-aware and
normalization-preserving, mapping all canonically equivalent file
names to the same file while preserving the form actually used to
create the file, of whatever form, normalized or not. This
behavior, which is legal according to RFC3010, which says little
about name mapping is probably illegal according to stringprep.
Nevertheless, it was expressly pointed out in RFC7530 as a valid
choice to deal with normalization issues, since it allows
normalization-aware processing without the difficulties that arise
in imposing a particular normalization form, as described in
Section 7.
In its discussion of internationalized domain names, RFC7530 [3]
adopted an approach compatible with IDNA2003, rather than
attempting to derive the specification from the behavior of
existing implementations.
o When IDNA2003 was replaced by IDNA2008, the internationalization
specified by [3] was not changed. Also, it appears unlikely that
implementations were changed to reflect that shift.
o NFSv4.2 made no changes to internationalization. As a result,
RFC7862 [5] which made no mention of internationalization,
implicitly aligned internationalization in NFSv4.2 with that in
NFSv4.1, as specified by RFC5661 [4].
Noveck Expires September 10, 2020 [Page 8]
Internet-Draft NFSv4 Inernationalization March 2020
As a result of this implicit alignment, there is no need for this
document to specifically address NFSv4.2 or be marked as updating
RFC7862. It is sufficient that it updates RFC5661, which
specifies the internationalization for NFSv4.1, inherited by
NFSv4.2.
The above history, can, for the purposes of the rest of this document
be summarized in the following statements:
o The actual treatment of internationalization within NFSv4 has not
been affected by the particular minor version used, despite the
fact that the specifications for the minor versions have often
differed in their treatment of internationalization.
o With regard to filenames, implementations have followed the
internationalization approach specified in RFC3010, which is
compatible with the treatment in RFC7530.
o With regard to internationalized domain names, RFC7530 [3]
specified an approach compatible with IDNA at the time of
publication. However, no detailed analysis was done to determine
whether NFSv4 implementations actually followed that approach
In order to deal with all NFSv4 minor versions, this document follows
the internationalization approach defined in RFC7530, with some
changes motivated by the shift from IDNA2003 to IDNA2008. The
intention is to maintain compatibility with all existing NFSv4 minor
versions. Potential compatibility issues with regard to the IDNA
shift are discussed in Section 8.2. Issues relating to potential
future minor versions and protocol extensions are dealt with in
Section 11.
4. Limitations on Internationalization-Related Processing in the NFSv4
Context
There are a number of noteworthy circumstances that limit the degree
to which internationalization-related encoding and normalization-
related restrictions can be made universal with regard to NFSv4
clients and servers:
o The NFSv4 client is part of an extensive set of client-side
software components whose design and internal interfaces are not
within the IETF's purview, limiting the degree to which a
particular character encoding might be made standard.
o Server-side handling of file component names is typically
implemented within a server-side physical file system, whose
Noveck Expires September 10, 2020 [Page 9]
Internet-Draft NFSv4 Inernationalization March 2020
handling of character encoding and normalization is not
specifiable by the IETF.
o Typical implementation patterns in UNIX systems result in the
NFSv4 client having no knowledge of the character encoding being
used, which might even vary between processes on the same client
system.
o Users may need access to files stored previously with non-UTF-8
encodings, or with UTF-8 encodings that are not in accord with any
particular normalization form.
5. Summary of Server Behavior Types
Servers MAY reject component name strings that are not valid UTF-8.
This leads to a number of types of valid server behavior, as outlined
below. When these are combined with the valid normalization-related
behaviors as described in Section 6, this leads to the combined
behaviors outlined below.
o Servers that limit file component names within a given file system
to UTF-8 strings exist with normalization-related handling as
described in Section 6. These are best described as behaving as
"UTF-8-only servers".
o Servers that do not limit file component names on particular file
systems to UTF-8 strings are very common and are necessary to deal
with clients/applications not oriented to the use of UTF-8. Such
servers ignore normalization-related issues, and there is no way
for them to implement either normalization or representation-
independent lookups. These are best described as behaving as
"UTF-8-unaware servers" for such file systems, since they treat
file component names as uninterpreted strings of bytes and have no
knowledge of the characters represented. See Section 9 for
details.
o It is possible for a server to allow component names that are not
valid UTF-8, while still being aware of the structure of UTF-8
strings. Such servers could implement either normalization or
representation-independent lookups but apply those techniques only
to valid UTF-8 strings. Such servers are not common, but it is
possible to configure at least one known server to have this
behavior. This behavior SHOULD NOT be used due to the possibility
that a filename using one encoding may, by coincidence, have the
appearance of a UTF-8 filename; the results of UTF-8 normalization
or representation-independent lookups are unlikely to be correct
in all cases, when considered from the viewpoint of the other
encoding.
Noveck Expires September 10, 2020 [Page 10]
Internet-Draft NFSv4 Inernationalization March 2020
6. String Encoding
Strings that potentially contain characters outside the ASCII range
[10] are generally represented in NFSv4 using the UTF-8 encoding [8]
of Unicode [11]. See [8] for precise encoding and decoding rules.
Some details of the protocol treatment depend on the type of string:
o For strings that are component names, the preferred encoding for
any non-ASCII characters is the UTF-8 representation of Unicode.
In many cases, clients have no knowledge of the encoding being
used, with the encoding done at the user level under the control
of a per-process locale specification. As a result, it may be
impossible for the NFSv4 client to enforce the use of UTF-8. The
use of non-UTF-8 encodings can be problematic, since it may
interfere with access to files stored using other forms of name
encoding. Also, normalization-related processing (see Section 7)
of a string not encoded in UTF-8 could result in inappropriate
name modification or aliasing. In cases in which one has a non-
UTF-8 encoded name that accidentally conforms to UTF-8 rules,
substitution of canonically equivalent strings can change the non-
UTF-8 encoded name drastically.
The kinds of modification and aliasing mentioned here can lead to
both false negatives and false positives, depending on the strings
in question, which can result in security issues such as elevation
of privilege and denial of service (see [20] for further
discussion).
o For strings based on domain names, non-ASCII characters MUST be
represented using the UTF-8 encoding of Unicode, and additional
string format restrictions may apply. See Section 8 for details.
o The contents of symbolic links (of type linktext4 in the XDR) MUST
be treated as opaque data by NFSv4 servers. Although UTF-8
encoding is often used, it need not be. In this respect, the
contents of symbolic links are like the contents of regular files
in that their encoding is not within the scope of this
specification.
o For other sorts of strings, any non-ASCII characters SHOULD be
represented using the UTF-8 encoding of Unicode.
Noveck Expires September 10, 2020 [Page 11]
Internet-Draft NFSv4 Inernationalization March 2020
7. Normalization
The client and server operating environments can potentially differ
in their policies and operational methods with respect to character
normalization (see [11] for a discussion of normalization forms).
This difference may also exist between applications on the same
client. This adds to the difficulty of providing a single
normalization policy for the protocol that allows for maximal
interoperability. This issue is similar to the issues of character
case where the server may or may not support case-insensitive
filename matching and may or may not preserve the character case when
storing filenames. The protocol does not mandate a particular
behavior but allows for a range of useful behaviors.
The NFSv4 protocol does not mandate the use of a particular
normalization form. A subsequent minor version of the NFSv4 protocol
might specify a particular normalization form, although there would
be difficulties in doing so (see Section 11 for details). In any
case, the server and client can expect that they may receive
unnormalized characters within protocol requests and responses. If
the operating environment requires normalization, then the
implementation will need to normalize the various UTF-8 encoded
strings within the protocol before presenting the information to an
application (at the client) or local file system (at the server).
Server implementations MAY normalize filenames to conform to a
particular normalization form before using the resulting string when
looking up or creating a file. Servers MAY also perform
normalization-insensitive string comparisons without modifying the
names to match a particular normalization form. Except in cases in
which component names are excluded from normalization-related
handling because they are not valid UTF-8 strings, a server MUST make
the same choice (as to whether to normalize or not, the target form
of normalization, and whether to do normalization-insensitive string
comparisons) in the same way for all accesses to a particular file
system. Servers SHOULD NOT reject a filename because it does not
conform to a particular normalization form, as this would deny access
to clients that use a different normalization form or clients acting
on behalf of application that use a different normalization form.
8. String Types with Processing Defined by Other Internet Areas
There are two types of strings that NFSv4 deals with that are based
on domain names. Processing of such strings is defined by other
Internet standards, and hence the processing behavior for such
strings should be consistent across all server operating systems and
server file systems.
Noveck Expires September 10, 2020 [Page 12]
Internet-Draft NFSv4 Inernationalization March 2020
This section differs from other sections of this document in two
respects:
o The normative statements within this section are not derived from
the behavior from existing NFSv4 implementations, but derive
instead from existing RFCs.
o Because of the switch from IDNA2003 [16] [17] to IDNA2008 [6],
this section is necessarily different from the corresponding
section (i.e. Section 12.6) of [3]. The differences are
discussed in Section 8.1.
Because of this shift, there could be compatibility issues to be
expected between implementations obeying Section 12.6 of [3] and
those following this document. Whether such compatibility issues
actually exist depends on the behavior of NFSv4 implementations and
how domain names are actually used in existing implementations.
These matters will be discussed in Section 8.2.
The types of strings referred to above are as follows:
o Server names as they appear in the fs_locations and
fs_locations_info attribute. Notes that for most purposes, such
server names will only be sent by the server to the client. The
exception is the use of these attributes in a VERIFY or NVERIFY
operation.
o Principal suffixes that are used to denote sets of users and
groups, and are in the form of domain names.
The general rules for handling all of these domain-related strings
are similar and independent of the role of the sender or receiver as
client or server, although the consequences of failure to obey these
rules may be different for client or server. The server can report
errors when it is sent invalid strings, whereas the client will
simply ignore an invalid string or use a default value in its place.
The string sent SHOULD be in the form of one or more unvalidated
U-labels as defined by [6]. In cases where this cannot be done, the
string will instead be in the form of one or more LDH labels [6].
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, any of the following:
o a string that is not valid UTF-8.
Noveck Expires September 10, 2020 [Page 13]
Internet-Draft NFSv4 Inernationalization March 2020
o a string that contains an XN-label (begins with "xn--") for which
the characters after "xn--" are not valid output of the Punycode
algorithm [7].
o a string that contains a reserved LDH label which is not an
XN-label.
When a domain string is part of id@domain or group@domain, there are
two possible approaches:
1. The server generally treats the domain string as a series of
unvalidated U-labels. In cases where the domain string is a
series of unvalidated A-labels or Non-Reserved LDH (NR-LDH)
labels, it converts them to U-labels using the Punycode algorithm
[7]. 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 of an unvalidated U-label.
2. The server treats the domain string as a series of unvalidated
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.
For VERIFY and NVERIFY, additional string processing requirements
apply to verification of the owner and owner_group attributes; see
the section entitled "Interpreting owner and owner_group" for the
document specifying the minor version in question (RFC750 [3],
RFC5661 [4])
8.1. Effect of IDNA Changes
Overall, the effect of the shift to IDNA2008 is to limit the degree
of understanding of the IDNA-based restrictions on domain names that
were expected of NFSv4 in RFC7530 [3]. Despite this specification,
the degree to which implementations actually implemented such
restrictions is open to question and will be discussed in detail in
Section 8.2
In analyzing how various cases are to be dealt with according to
RFC7530, there a number of troubling uncertainties that arise in
trying to interpret the existing specification:
Noveck Expires September 10, 2020 [Page 14]
Internet-Draft NFSv4 Inernationalization March 2020
o There are a number of cases in which "SHOULD" is used that are
confusing. According to RFC2119 [1], "SHOULD" means that "there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course". To fully
understand a particular "SHOULD", there needs to be enough context
to determine whether particular reasons for ignoring the item are
in fact valid, and sufficient guidance to understand the
implication of ignoring the item. In the absence of such
information, the relevant fact is that the peer needs to deal with
the item being ignored, making the implications of a "SHOULD" hard
to distinguish from those of "MAY".
o While the document states. "the general rules for handling all of
these domain-related strings are similar and independent of the
role of the sender or receiver as client or server", all of the
following text is explicitly about the server's options, choices
and responsibilities, leaving the client case unclear.
o In a number of places within the paragraph describing server
approach #1, the word "can" is used as in the text "the server can
use the ToUnicode function", leaving it unclear whether the server
can choose to do anything else and if so what.
The following cases are those where RFC7530 requires use of IDNA
handling and this requirement could, if implementations follow them,
create potential compatibility issues, which need to be understood.
o The degree to which RFC3490 [16] requires that characters other
than U+002E (full stop) be treated as label separators, including
U+3002 (ideographic full stop), U+FF0E (fullwidth full stop),
U+FF61 (halfwidth ideographic full stop).
o The degree to which RFC3490 [16] that server or client needs to
validate a putative A-label or U-label or to rectify it if it is
not valid.
8.2. Potential Compatibility Issues Related to IDNA Changes
There are a number of factors relating to the handling of domain
names within NFSv4 implementations that are important in
understanding why any compatibility issues might be less troubling
than a comparison of the two IDNA approaches might suggest:
o Much of the potentially conflicting IDNA-related behavior required
or recommended for the server by RFC7530 [3] might not actually be
implemented, limiting the potential harmful effects of ceasing to
mandate it.
Noveck Expires September 10, 2020 [Page 15]
Internet-Draft NFSv4 Inernationalization March 2020
o Even if such behavior were implemented by servers, no
compatibility issue would arise unless clients actually relied on
the server to implement it. Given that none of this behavior is
made required, the chances of that occurring is quite small.
o The range of potential values for user and group attributes sent
by clients are often quite small with implementations commonly
restricting all such values to a single domain string. This is
even though RFCs 7530 [3] and 5661 [4] are written without mention
of such restrictions.
Specification of users and groups in the "id@domain" format within
NFSv4 was adopted to enable expansion of the spaces of users and
groups beyond the 32-bit id spaces mandated in NFSv3 [13] and
NFsv2 [12]. While one obstacle to expansion was eliminated, most
implementations were unable to actually effect that expansion,
principally because the physical file systems used assume that
user and group identifiers fit in 32 bits each and the vnode
interfaces used by server implementations make similar
assumptions.
Given these restrictions, the typical implementation pattern is
for servers to accept only a single domain, specified as part of
the server configuration, together with information necessary to
effect the appropriate name-to-id mappings.
o The other uses of domain names in NFSv4, to represent hostnames in
location attributes, the values are generated by the server and
will normally include only include hostnames within DNS-registered
domains.
Keeping the above in mind, we can see that interoperability issues,
while they might exist are unlikely to raise major challenges as
looking to the following specific cases shows
o When an internationalized domain name is used as part of a user or
group, it would need to be configured as such, with the domain
string known to both client and server.
While it is theoretically possible that a client might work with
an invalid domain string and rely on the server to correct it to
an IDNA-acceptable one, such a scenario has to be considered
extremely unlikely, since it would depend on multiple servers
implementing the same correction, especially since there is no
evidence of such corrections ever having been implemented by NFSv4
servers.
Noveck Expires September 10, 2020 [Page 16]
Internet-Draft NFSv4 Inernationalization March 2020
o When an internationalized domain in a location string is meant to
specify a registered domain, similar considerations apply.
While it is theoretically possible that a client might work with
an invalid domain string and rely on the server to correct it to
the appropriate registered one, such a scenario has to be
considered extremely unlikely, since it would depend on multiple
servers implementing the same correction, especially since there
is no evidence of such corrections ever having beeen inimplemented
by NFSv4 servers.
o When an internationalized domain in a location string is meant to
specify a non-registered domain, any such server-applied
corrections would be useless.
In this situation, any potential interoperability issue would
arise from rejecting the name, which has to be considered as what
should have been done in the first place.
9. Errors Related to UTF-8
Where the client sends an invalid UTF-8 string, the server MAY return
an NFS4ERR_INVAL error. This includes cases in which inappropriate
prefixes are detected and where the count includes trailing bytes
that do not constitute a full Multiple-Octet Coded Universal
Character Set (UCS) character.
Requirements for server handling of component names that are not
valid UTF-8, when a server does not return NFS4ERR_INVAL in response
to receiving them, are described in Section 10.
Where the string supplied by the client is not rejected with
NFS4ERR_INVAL but contains characters that are not supported by the
server as a value for that string (e.g., names containing slashes, or
characters that do not fit into 16 bits when converted from UTF-8 to
a Unicode codepoint), the server should return an NFS4ERR_BADCHAR
error.
Where a UTF-8 string is used as a filename, and the file system,
while supporting all of the characters within the name, does not
allow that particular name to be used, the server should return the
error NFS4ERR_BADNAME. This includes such situations as file system
prohibitions of "." and ".." as filenames for certain operations, and
similar constraints.
Noveck Expires September 10, 2020 [Page 17]
Internet-Draft NFSv4 Inernationalization March 2020
10. Servers That Accept File Component Names That Are Not Valid UTF-8
Strings
As stated previously, servers MAY accept, on all or on some subset of
the physical file systems exported, component names that are not
valid UTF-8 strings. A typical pattern is for a server to use
UTF-8-unaware physical file systems that treat component names as
uninterpreted strings of bytes, rather than having any awareness of
the character set being used.
Such servers SHOULD NOT change the stored representation of component
names from those received on the wire and SHOULD use an octet-by-
octet comparison of component name strings to determine equivalence
(as opposed to any broader notion of string comparison). This is
because the server has no knowledge of the character encoding being
used.
Nonetheless, when such a server uses a broader notion of string
equivalence than what is recommended in the preceding paragraph, the
following considerations apply:
o Outside of 7-bit ASCII, string processing that changes string
contents is usually specific to a character set and hence is
generally unsafe when the character set is unknown. This
processing could change the filename in an unexpected fashion,
rendering the file inaccessible to the application or client that
created or renamed the file and to others expecting the original
filename. Hence, such processing should not be performed, because
doing so is likely to result in incorrect string modification or
aliasing.
o Unicode normalization is particularly dangerous, as such
processing assumes that the string is UTF-8. When that assumption
is false because a different character set was used to create the
filename, normalization may corrupt the filename with respect to
that character set, rendering the file inaccessible to the
application that created it and others expecting the original
filename. Hence, Unicode normalization SHOULD NOT be performed,
because it may cause incorrect string modification or aliasing.
When the above recommendations are not followed, the resulting string
modification and aliasing can lead to both false negatives and false
positives, depending on the strings in question, which can result in
security issues such as elevation of privilege and denial of service
(see [20] for further discussion).
Noveck Expires September 10, 2020 [Page 18]
Internet-Draft NFSv4 Inernationalization March 2020
11. Future Minor Versions and Extensions
As stated above, all current NFSv4 minor versions allow use of non-
UTF-8 encodings, allow servers a choice of whether to be aware of
normalization issues or not, and allows servers a number of choices
about how to address normalization issues. This range of choices
reflects the need to accommodate existing file systems and user
expectations about character handling which in turn reflect the
assumptions of the POSIX model of handling file names.
While it is theoretically possible for a subsequent minor version to
change these aspects of the protocol (see [9]), this section will
explain why any such change is highly unlikely, making it expected
that these aspects of NFSv4 internationalization handling will be
retained indefinitely. As a result, any new minor version
specification document that made such a change would have to be
marked as updating or obsoleting this document
No such change could be done as an extension to an existing minor
version or in a new minor version consisting only of OPTIONAL
features. Such a change could only be done in a new minor version,
which like minor version one, was prepared to be incompatible to some
degree with the previous minor versions. While it appears unlikely
that such minor versions will be adopted, the possibility cannot be
excluded, so we need to explore the difficulties of changing the
aspects of internationalization handling mentioned above.
o Establishing UTF-8 as the sole means of encoding for
internationalized characters, would make inaccessible existing
files stored with other encodings. Further, unless there were a
corresponding change in the UNIX file interface model, it would
cause the set of valid names for local and remote files to
diverge.
o Imposing a particular normalization form, in the sense of refusing
to create to allow access to files whose UTF-8-encoded names are
not of the selected normalization form would give rise to similar
difficulties.
o Defining a preferred normalization form to be returned as the
names of all internationalized files, would result in applications
having to deal with sudden unexplained changes of file names for
existing files.
None of the above appears likely since there does not seem to be any
corresponding benefits to justify the difficulties that they would
create.
Noveck Expires September 10, 2020 [Page 19]
Internet-Draft NFSv4 Inernationalization March 2020
There would also be difficulties in otherwise reducing the set of
three acceptable normalization handling options, without reducing it
to a single option by imposing a specific normalization form.
o Eliminating the possibility of a single possible normalization
form, would pose similar difficulties to imposing the other one,
even if representation-independent comparisons were also allowed.
In either case, a specific normalization form would be disfavored,
with no corresponding benefit.
o Allowing only representation-independent lookups would not impose
difficulties for clients, but there are reasons to doubt it could
be universally implemented, since such name comparisons would have
to be done within the file system itself.
Such a change could only be made once support file system support
for representation-independent file lookups would become commonly
available. As long as the POSIX file naming model continues its
sway, that would be unlikely to happen.
One possible internationalization-related extension that the working
could adopt would be definition of an OPTIONAL per-fs attribute
defining the internationalization-related handling for that file
system. That would allow clients to be aware of server choices in
this area and could be adopted without disrupting existing clients
and servers.
12. IANA Considerations
The current document does not require any actions by IANA.
13. Security Considerations
Unicode in the form of UTF-8 is generally is used for file component
names (i.e., both directory and file components). However, other
character sets may also be allowed for these names. For the owner
and owner_group attributes and other sorts strings whose form is
affected by standard outside NFSv4 (see Section 8.) are always
encoded as UTF-8. String processing (e.g., Unicode normalization)
raises security concerns for string comparison. See Sections 8 and 7
as well as the respective Sections 5.9 of RFC7530 [3] and RFC5661 [4]
for further discussion. See [20] for related identifier comparison
security considerations. File component names are identifiers with
respect to the identifier comparison discussion in [20] because they
are used to identify the objects to which ACLs are applied (See the
respective Sections 6 of RFC7530 [3] and RFC5661 [4]).
Noveck Expires September 10, 2020 [Page 20]
Internet-Draft NFSv4 Inernationalization March 2020
14. References
14.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[2] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[3] Haynes, T., Ed. and D. Noveck, Ed., "Network File System
(NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,
March 2015, <https://www.rfc-editor.org/info/rfc7530>.
[4] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
"Network File System (NFS) Version 4 Minor Version 1
Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010,
<https://www.rfc-editor.org/info/rfc5661>.
[5] Haynes, T., "Network File System (NFS) Version 4 Minor
Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862,
November 2016, <https://www.rfc-editor.org/info/rfc7862>.
[6] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>.
[7] Costello, A., "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications
(IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
<https://www.rfc-editor.org/info/rfc3492>.
[8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[9] Noveck, D., "Rules for NFSv4 Extensions and Minor
Versions", RFC 8178, DOI 10.17487/RFC8178, July 2017,
<https://www.rfc-editor.org/info/rfc8178>.
[10] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, October 1969,
<http://www.rfc-editor.org/info/rfc20>.
Noveck Expires September 10, 2020 [Page 21]
Internet-Draft NFSv4 Inernationalization March 2020
[11] The Unicode Consortium, "The Unicode Standard, Version
7.0.0", (Mountain View, CA: The Unicode Consortium,
2014 ISBN 978-1-936213-09-2), June 2014,
<http://www.unicode.org/versions/latest/>.
14.2. Informative References
[12] Nowicki, B., "NFS: Network File System Protocol
specification", RFC 1094, DOI 10.17487/RFC1094, March
1989, <https://www.rfc-editor.org/info/rfc1094>.
[13] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS
Version 3 Protocol Specification", RFC 1813,
DOI 10.17487/RFC1813, June 1995,
<https://www.rfc-editor.org/info/rfc1813>.
[14] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "NFS version 4
Protocol", RFC 3010, DOI 10.17487/RFC3010, December 2000,
<https://www.rfc-editor.org/info/rfc3010>.
[15] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454,
DOI 10.17487/RFC3454, December 2002,
<https://www.rfc-editor.org/info/rfc3454>.
[16] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, DOI 10.17487/RFC3490, March 2003,
<https://www.rfc-editor.org/info/rfc3490>.
[17] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
Profile for Internationalized Domain Names (IDN)",
RFC 3491, DOI 10.17487/RFC3491, March 2003,
<https://www.rfc-editor.org/info/rfc3491>.
[18] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3530, DOI 10.17487/RFC3530,
April 2003, <https://www.rfc-editor.org/info/rfc3530>.
[19] Hoffman, P. and J. Klensin, "Terminology Used in
Internationalization in the IETF", BCP 166, RFC 6365,
DOI 10.17487/RFC6365, September 2011,
<https://www.rfc-editor.org/info/rfc6365>.
Noveck Expires September 10, 2020 [Page 22]
Internet-Draft NFSv4 Inernationalization March 2020
[20] Thaler, D., Ed., "Issues in Identifier Comparison for
Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May
2013, <https://www.rfc-editor.org/info/rfc6943>.
[21] Shepler, S., "NFS version 4 Protocol", draft-ietf-
nfsv4-rfc3010bis-04 (work in progress), October 2002.
Appendix A. Acknowledgements
This document is based, in large part, on Section 12 of [3] and all
the people who contributed to that work, have helped make this
document possible, including David Black, Peter Staubach, Nico
Williams, Mike Eisler, Trond Myklebust, James Lentini, Mike Kupfer
and Peter Saint-Andre.
The author wishes to thank Tom Haynes for his timely suggestion to
pursue the task of dealing with internationalization on an NFSv4-wide
basis.
Author's Address
David Noveck
NetApp
1601 Trapelo Road
Waltham, MA 02451
United States of America
Phone: +1 781 572 8038
Email: davenoveck@gmail.com
Noveck Expires September 10, 2020 [Page 23]