draft-ietf-nfsv4-rfc3530bis-28.txt   draft-ietf-nfsv4-rfc3530bis-29.txt 
NFSv4 T. Haynes, Ed. NFSv4 T. Haynes, Ed.
Internet-Draft NetApp Internet-Draft NetApp
Obsoletes: 3530 (if approved) D. Noveck, Ed. Obsoletes: 3530 (if approved) D. Noveck, Ed.
Intended status: Standards Track EMC Intended status: Standards Track EMC
Expires: April 22, 2014 October 19, 2013 Expires: June 1, 2014 November 28, 2013
Network File System (NFS) Version 4 Protocol Network File System (NFS) Version 4 Protocol
draft-ietf-nfsv4-rfc3530bis-28.txt draft-ietf-nfsv4-rfc3530bis-29.txt
Abstract Abstract
The Network File System (NFS) version 4 is a distributed file system The Network File System (NFS) version 4 is a distributed file system
protocol which builds on the heritage of NFS protocol version 2, RFC protocol which builds on the heritage of NFS protocol version 2, RFC
1094, and version 3, RFC 1813. Unlike earlier versions, the NFS 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS
version 4 protocol supports traditional file access while integrating version 4 protocol supports traditional file access while integrating
support for file locking and the mount protocol. In addition, support for file locking and the mount protocol. In addition,
support for strong security (and its negotiation), compound support for strong security (and its negotiation), compound
operations, client caching, and internationalization have been added. operations, client caching, and internationalization have been added.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 22, 2014. This Internet-Draft will expire on June 1, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 6, line 12 skipping to change at page 6, line 12
10.5. Data Caching and Revocation . . . . . . . . . . . . . . 158 10.5. Data Caching and Revocation . . . . . . . . . . . . . . 158
10.5.1. Revocation Recovery for Write Open Delegation . . . 158 10.5.1. Revocation Recovery for Write Open Delegation . . . 158
10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 159 10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 159
10.7. Data and Metadata Caching and Memory Mapped Files . . . 161 10.7. Data and Metadata Caching and Memory Mapped Files . . . 161
10.8. Name Caching . . . . . . . . . . . . . . . . . . . . . . 163 10.8. Name Caching . . . . . . . . . . . . . . . . . . . . . . 163
10.9. Directory Caching . . . . . . . . . . . . . . . . . . . 164 10.9. Directory Caching . . . . . . . . . . . . . . . . . . . 164
11. Minor Versioning . . . . . . . . . . . . . . . . . . . . . . 165 11. Minor Versioning . . . . . . . . . . . . . . . . . . . . . . 165
12. Internationalization . . . . . . . . . . . . . . . . . . . . 168 12. Internationalization . . . . . . . . . . . . . . . . . . . . 168
12.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 168 12.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 168
12.2. String Encoding . . . . . . . . . . . . . . . . . . . . 169 12.2. Limitations on internationalization-related
12.3. Normalization . . . . . . . . . . . . . . . . . . . . . 169 processing in the NFSv4 context . . . . . . . . . . . . 169
12.4. Types with Processing Defined by Other Internet Areas . 170 12.3. String Encoding . . . . . . . . . . . . . . . . . . . . 169
12.5. UTF-8 Related Errors . . . . . . . . . . . . . . . . . . 171 12.4. Normalization . . . . . . . . . . . . . . . . . . . . . 170
12.6. Handling of component names that are not valid UTF-8 12.5. Types with Processing Defined by Other Internet Areas . 171
12.6. UTF-8 Related Errors . . . . . . . . . . . . . . . . . . 172
12.7. Handling of component names that are not valid UTF-8
strings . . . . . . . . . . . . . . . . . . . . . . . . 172 strings . . . . . . . . . . . . . . . . . . . . . . . . 172
13. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 173 13. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 173
13.1. Error Definitions . . . . . . . . . . . . . . . . . . . 173 13.1. Error Definitions . . . . . . . . . . . . . . . . . . . 174
13.1.1. General Errors . . . . . . . . . . . . . . . . . . . 175 13.1.1. General Errors . . . . . . . . . . . . . . . . . . . 175
13.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 176 13.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 176
13.1.3. Compound Structure Errors . . . . . . . . . . . . . 177 13.1.3. Compound Structure Errors . . . . . . . . . . . . . 178
13.1.4. File System Errors . . . . . . . . . . . . . . . . . 178 13.1.4. File System Errors . . . . . . . . . . . . . . . . . 179
13.1.5. State Management Errors . . . . . . . . . . . . . . 180 13.1.5. State Management Errors . . . . . . . . . . . . . . 181
13.1.6. Security Errors . . . . . . . . . . . . . . . . . . 181 13.1.6. Security Errors . . . . . . . . . . . . . . . . . . 182
13.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 182 13.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 182
13.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 182 13.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 183
13.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 184 13.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 184
13.1.10. Client Management Errors . . . . . . . . . . . . . . 184 13.1.10. Client Management Errors . . . . . . . . . . . . . . 185
13.1.11. Attribute Handling Errors . . . . . . . . . . . . . 185 13.1.11. Attribute Handling Errors . . . . . . . . . . . . . 185
13.2. Operations and their valid errors . . . . . . . . . . . 185 13.2. Operations and their valid errors . . . . . . . . . . . 186
13.3. Callback operations and their valid errors . . . . . . . 192 13.3. Callback operations and their valid errors . . . . . . . 193
13.4. Errors and the operations that use them . . . . . . . . 193 13.4. Errors and the operations that use them . . . . . . . . 194
14. NFSv4 Requests . . . . . . . . . . . . . . . . . . . . . . . 197 14. NFSv4 Requests . . . . . . . . . . . . . . . . . . . . . . . 198
14.1. Compound Procedure . . . . . . . . . . . . . . . . . . . 198 14.1. Compound Procedure . . . . . . . . . . . . . . . . . . . 199
14.2. Evaluation of a Compound Request . . . . . . . . . . . . 198 14.2. Evaluation of a Compound Request . . . . . . . . . . . . 199
14.3. Synchronous Modifying Operations . . . . . . . . . . . . 199 14.3. Synchronous Modifying Operations . . . . . . . . . . . . 200
14.4. Operation Values . . . . . . . . . . . . . . . . . . . . 199 14.4. Operation Values . . . . . . . . . . . . . . . . . . . . 200
15. NFSv4 Procedures . . . . . . . . . . . . . . . . . . . . . . 200 15. NFSv4 Procedures . . . . . . . . . . . . . . . . . . . . . . 201
15.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 200 15.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 201
15.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 200 15.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 201
15.3. Operation 3: ACCESS - Check Access Rights . . . . . . . 204 15.3. Operation 3: ACCESS - Check Access Rights . . . . . . . 205
15.4. Operation 4: CLOSE - Close File . . . . . . . . . . . . 207 15.4. Operation 4: CLOSE - Close File . . . . . . . . . . . . 208
15.5. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 208 15.5. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 209
15.6. Operation 6: CREATE - Create a Non-Regular File Object . 210 15.6. Operation 6: CREATE - Create a Non-Regular File Object . 211
15.7. Operation 7: DELEGPURGE - Purge Delegations Awaiting 15.7. Operation 7: DELEGPURGE - Purge Delegations Awaiting
Recovery . . . . . . . . . . . . . . . . . . . . . . . . 213 Recovery . . . . . . . . . . . . . . . . . . . . . . . . 214
15.8. Operation 8: DELEGRETURN - Return Delegation . . . . . . 214 15.8. Operation 8: DELEGRETURN - Return Delegation . . . . . . 215
15.9. Operation 9: GETATTR - Get Attributes . . . . . . . . . 215 15.9. Operation 9: GETATTR - Get Attributes . . . . . . . . . 216
15.10. Operation 10: GETFH - Get Current Filehandle . . . . . . 217 15.10. Operation 10: GETFH - Get Current Filehandle . . . . . . 218
15.11. Operation 11: LINK - Create Link to a File . . . . . . . 218 15.11. Operation 11: LINK - Create Link to a File . . . . . . . 219
15.12. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 219 15.12. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 220
15.13. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 223 15.13. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 224
15.14. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 225 15.14. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 226
15.15. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 226 15.15. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 227
15.16. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 228 15.16. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 229
15.17. Operation 17: NVERIFY - Verify Difference in 15.17. Operation 17: NVERIFY - Verify Difference in
Attributes . . . . . . . . . . . . . . . . . . . . . . . 229 Attributes . . . . . . . . . . . . . . . . . . . . . . . 230
15.18. Operation 18: OPEN - Open a Regular File . . . . . . . . 230 15.18. Operation 18: OPEN - Open a Regular File . . . . . . . . 231
15.19. Operation 19: OPENATTR - Open Named Attribute 15.19. Operation 19: OPENATTR - Open Named Attribute
Directory . . . . . . . . . . . . . . . . . . . . . . . 240 Directory . . . . . . . . . . . . . . . . . . . . . . . 241
15.20. Operation 20: OPEN_CONFIRM - Confirm Open . . . . . . . 241 15.20. Operation 20: OPEN_CONFIRM - Confirm Open . . . . . . . 242
15.21. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 243 15.21. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 244
15.22. Operation 22: PUTFH - Set Current Filehandle . . . . . . 244 15.22. Operation 22: PUTFH - Set Current Filehandle . . . . . . 245
15.23. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 245 15.23. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 246
15.24. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 246 15.24. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 247
15.25. Operation 25: READ - Read from File . . . . . . . . . . 247 15.25. Operation 25: READ - Read from File . . . . . . . . . . 248
15.26. Operation 26: READDIR - Read Directory . . . . . . . . . 249 15.26. Operation 26: READDIR - Read Directory . . . . . . . . . 250
15.27. Operation 27: READLINK - Read Symbolic Link . . . . . . 253 15.27. Operation 27: READLINK - Read Symbolic Link . . . . . . 254
15.28. Operation 28: REMOVE - Remove Filesystem Object . . . . 254 15.28. Operation 28: REMOVE - Remove Filesystem Object . . . . 255
15.29. Operation 29: RENAME - Rename Directory Entry . . . . . 256 15.29. Operation 29: RENAME - Rename Directory Entry . . . . . 257
15.30. Operation 30: RENEW - Renew a Lease . . . . . . . . . . 258 15.30. Operation 30: RENEW - Renew a Lease . . . . . . . . . . 259
15.31. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 259 15.31. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 260
15.32. Operation 32: SAVEFH - Save Current Filehandle . . . . . 260 15.32. Operation 32: SAVEFH - Save Current Filehandle . . . . . 261
15.33. Operation 33: SECINFO - Obtain Available Security . . . 261 15.33. Operation 33: SECINFO - Obtain Available Security . . . 262
15.34. Operation 34: SETATTR - Set Attributes . . . . . . . . . 265 15.34. Operation 34: SETATTR - Set Attributes . . . . . . . . . 266
15.35. Operation 35: SETCLIENTID - Negotiate Client ID . . . . 267 15.35. Operation 35: SETCLIENTID - Negotiate Client ID . . . . 268
15.36. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID . 271 15.36. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID . 272
15.37. Operation 37: VERIFY - Verify Same Attributes . . . . . 274 15.37. Operation 37: VERIFY - Verify Same Attributes . . . . . 275
15.38. Operation 38: WRITE - Write to File . . . . . . . . . . 276 15.38. Operation 38: WRITE - Write to File . . . . . . . . . . 277
15.39. Operation 39: RELEASE_LOCKOWNER - Release Lockowner 15.39. Operation 39: RELEASE_LOCKOWNER - Release Lockowner
State . . . . . . . . . . . . . . . . . . . . . . . . . 280 State . . . . . . . . . . . . . . . . . . . . . . . . . 281
15.40. Operation 10044: ILLEGAL - Illegal operation . . . . . . 281 15.40. Operation 10044: ILLEGAL - Illegal operation . . . . . . 282
16. NFSv4 Callback Procedures . . . . . . . . . . . . . . . . . . 282 16. NFSv4 Callback Procedures . . . . . . . . . . . . . . . . . . 283
16.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 282 16.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 283
16.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 282 16.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 283
16.2.6. Operation 3: CB_GETATTR - Get Attributes . . . . . . 284 16.2.6. Operation 3: CB_GETATTR - Get Attributes . . . . . . 285
16.2.7. Operation 4: CB_RECALL - Recall an Open Delegation . 285 16.2.7. Operation 4: CB_RECALL - Recall an Open Delegation . 286
16.2.8. Operation 10044: CB_ILLEGAL - Illegal Callback 16.2.8. Operation 10044: CB_ILLEGAL - Illegal Callback
Operation . . . . . . . . . . . . . . . . . . . . . 286 Operation . . . . . . . . . . . . . . . . . . . . . 287
17. Security Considerations . . . . . . . . . . . . . . . . . . . 287 17. Security Considerations . . . . . . . . . . . . . . . . . . . 288
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 289 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 290
18.1. Named Attribute Definitions . . . . . . . . . . . . . . 289 18.1. Named Attribute Definitions . . . . . . . . . . . . . . 290
18.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 290 18.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 291
18.1.2. Updating Registrations . . . . . . . . . . . . . . . 290 18.1.2. Updating Registrations . . . . . . . . . . . . . . . 291
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 290 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 291
19.1. Normative References . . . . . . . . . . . . . . . . . . 290 19.1. Normative References . . . . . . . . . . . . . . . . . . 291
19.2. Informative References . . . . . . . . . . . . . . . . . 291 19.2. Informative References . . . . . . . . . . . . . . . . . 292
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 294
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 295 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 295
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 295 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 296
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 296
1. Introduction 1. Introduction
1.1. NFS Version 4 Goals 1.1. NFS Version 4 Goals
The Network Filesystem version 4 (NFSv4) protocol is a further The Network Filesystem version 4 (NFSv4) protocol is a further
revision of the NFS protocol defined already by versions 2 [RFC1094] revision of the NFS protocol defined already by versions 2 [RFC1094]
and 3 [RFC1813]. It retains the essential characteristics of and 3 [RFC1813]. It retains the essential characteristics of
previous versions: design for easy recovery, independent of transport previous versions: design for easy recovery, independent of transport
protocols, operating systems and file systems, simplicity, and good protocols, operating systems and file systems, simplicity, and good
skipping to change at page 51, line 21 skipping to change at page 51, line 21
As mentioned above, it is desirable that a server when accepting a As mentioned above, it is desirable that a server when accepting a
string of the form user@domain or group@domain in an attribute, string of the form user@domain or group@domain in an attribute,
return this same string when that corresponding attribute is fetched. return this same string when that corresponding attribute is fetched.
Internationalization issues (for a general discussion of which see Internationalization issues (for a general discussion of which see
Section 12) may make this impossible and the client needs to take Section 12) may make this impossible and the client needs to take
note of the following situations: note of the following situations:
o The string representing the domain may be converted to equivalent o The string representing the domain may be converted to equivalent
U-label (see [RFC5890]), if presented using a form other than a U-label (see [RFC5890]), if presented using a form other than a
U-label. See Section 12.4 for details. U-label. See Section 12.5 for details.
o The user or group may be returned in a different form, due to o The user or group may be returned in a different form, due to
normalization issues, although it will always be a canonically normalization issues, although it will always be a canonically
equivalent string. equivalent string.
In the case where there is no translation available to the client or In the case where there is no translation available to the client or
server, the attribute value will be constructed without the "@". server, the attribute value will be constructed without the "@".
Therefore, the absence of the "@" from the owner or owner_group Therefore, the absence of the "@" from the owner or owner_group
attribute signifies that no translation was available at the sender attribute signifies that no translation was available at the sender
and that the receiver of the attribute should not use that string as and that the receiver of the attribute should not use that string as
skipping to change at page 168, line 37 skipping to change at page 168, line 37
o Behavior implemented by no existing clients or servers is o Behavior implemented by no existing clients or servers is
described using "MUST NOT", if such behavior poses described using "MUST NOT", if such behavior poses
interoperability problems. interoperability problems.
o Behavior implemented by most existing clients or servers, where o Behavior implemented by most existing clients or servers, where
that behavior is more desirable than any alternative is described that behavior is more desirable than any alternative is described
using "SHOULD", since new implementations need to follow that using "SHOULD", since new implementations need to follow that
existing practice unless there are strong reasons to do otherwise. existing practice unless there are strong reasons to do otherwise.
This also holds for "SHOULD NOT". The converse holds for "SHOULD NOT".
o Behavior implemented by some not all existing clients or servers, o Behavior implemented by some not all existing clients or servers,
is described using "MAY", indicating that new implementations have is described using "MAY", indicating that new implementations have
a choice as to whether they will behave in that way. Thus, new a choice as to whether they will behave in that way. Thus, new
implementations will have the same flexibility that existing ones implementations will have the same flexibility that existing ones
do. do.
o Behavior implemented by all existing clients or servers, so far as o Behavior implemented by all existing clients or servers, so far as
is known, but where there remains some uncertainty as to details is known, but where there remains some uncertainty as to details
is described using "should". Such cases primarily concern details is described using "should". Such cases primarily concern details
of error returns. New implementations should follow existing of error returns. New implementations should follow existing
practice even though such situations generally do not affect practice even though such situations generally do not affect
interoperability. interoperability.
In the case of a MAY, SHOULD, or SHOULD NOT that applies to servers, In the case of a MAY, SHOULD, or SHOULD NOT that applies to servers,
clients need to be aware that there are servers which may or may nlot clients need to be aware that there are servers which may or may not
take the specified action, and they need to be prepared for either take the specified action, and they need to be prepared for either
eventuality. eventuality.
12.2. String Encoding 12.2. Limitations on internationalization-related processing in the
NFSv4 context
Strings that potentially contain non-ASCII Characters are represented There are a number of noteworthy circumstances that limit the degree
in NFSv4 using the UTF-8 encoding of Unicode. See [RFC2279] for to which internationalization-related processing can be made
precise encoding and decoding rules. 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 may be made standard.
o Server-side handling of file component names is typically
implemented within a server-side physical file system, whose
handling of character encoding and normalization is not
specifiable by the IETF.
o Typical implementation patterns in Unix systems may mean that the
NFSv4 client has no knowledge of the character encoding being
used, which may 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 do not match any
particular normalization form.
12.3. String Encoding
Strings that potentially contain non-ASCII Characters are generally
represented in NFSv4 using the UTF-8 encoding of Unicode. See
[RFC2279] for precise encoding and decoding rules.
Some details of the protocol treatment depend on the type of string: Some details of the protocol treatment depend on the type of string:
o For strings that are component names, any non-ASCII characters o For strings which are component names, the preferred encoding for
SHOULD be represented using the UTF-8 encoding of Unicode. any non-ASCII characters is any non-ASCII characters is the UTF-8
representation of Unicode.
In many cases, clients have no knowledge of the encoding being In many cases, clients have no knowledge of the encoding being
used, with the encoding done at user-level under control of a per- used, with the encoding done at user-level under control of a per-
process locale specification. As a result, it may be impossible process locale specification. As a result, it may be impossible
for the NFSv4 client to enforce use of UTF-8. Use of non-UTF-8 for the NFSv4 client to enforce use of UTF-8. Use of non-UTF-8
encodings can be problematic since it may interfere with access to encodings can be problematic since it may interfere with access to
files stored using encoding and because normalization-related files stored using other forms of name encoding. Also,
processing (see Section 12.3) would result in name aliasing in the normalization-related processing (see Section 12.4) of a string
case of a non-UTF-8 encoding resulted characters strings that have not encoded in UTF-8 could result in inappropriate name
multiple equivalent Unicode encodings. modification or aliasing. In cases in which one has a non-UT8-
name that accidentally conforms to UTF-8 rules, substitution of
canonically equivalent strings can change the non-UTF-8 encoded
name drastically.
o For strings whose form is defined by other internet standards, o For strings whose form is defined by other internet standards,
non-ASCII characters MUST be represented using the UTF-8 encoding non-ASCII characters MUST be represented using the UTF-8 encoding
of Unicode. In addition other sorts of restrictions defined by of Unicode. In addition other sorts of restrictions defined by
those standards need to be addressed. See Section 12.4 for those standards need to be addressed. See Section 12.5 for
details. details.
o The contents of symbolic links (of type linktext4 in the XDR) MUST o The contents of symbolic links (of type linktext4 in the XDR) MUST
be treated as opaque data by NFSv4 servers. Although UTF-8 be treated as opaque data by NFSv4 servers. Although UTF-8
encoding is often used, it need not be. In this respect, the encoding is often used, it need not be. In this respect, the
contents of symbolic links are like the contents of regular files contents of symbolic links are like the contents of regular files
in that their encoding is not within the scope of this in that their encoding is not within the scope of this
specification. specification.
o For other sorts of strings, any non-ASCII characters SHOULD be o For other sorts of strings, any non-ASCII characters SHOULD be
represented using the UTF-8 encoding of Unicode. represented using the UTF-8 encoding of Unicode.
12.3. Normalization 12.4. Normalization
The client and server operating environments may differ in their The client and server operating environments may differ in their
policies and operational methods with respect to character policies and operational methods with respect to character
normalization (See [Unicode1] for a discussion of normalization normalization (See [Unicode1] for a discussion of normalization
forms). This difference may also exist between applications on the forms). This difference may also exist between applications on the
same client. This adds to the difficulty of providing a single same client. This adds to the difficulty of providing a single
normalization policy for the protocol that allows for maximal normalization policy for the protocol that allows for maximal
interoperability. This issue is similar to the character case issues interoperability. This issue is similar to the character case issues
where the server may or may not support case insensitive file name where the server may or may not support case insensitive file name
matching and may or may not preserve the character case when storing matching and may or may not preserve the character case when storing
skipping to change at page 170, line 34 skipping to change at page 171, line 16
normalization-insensitive string comparisons without modifying name normalization-insensitive string comparisons without modifying name
to match a particular normalization form. Except in cases in which to match a particular normalization form. Except in cases in which
component names are excluded from normalization-related handling component names are excluded from normalization-related handling
because they are not valid UTF-8 strings, a server MUST make the same 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 choice (as to whether to normalize or not, the target form of
normalization and whether to do normalization-insensitive string normalization and whether to do normalization-insensitive string
comparisons) in the same way for all accesses to a particular comparisons) in the same way for all accesses to a particular
filesystem. Servers MUST NOT reject a file name because it doesn't a filesystem. Servers MUST NOT reject a file name because it doesn't a
conform to a particular normalization form. conform to a particular normalization form.
12.4. Types with Processing Defined by Other Internet Areas 12.5. Types with Processing Defined by Other Internet Areas
There are two types of strings which NFSv4 deals with whose There are two types of strings which NFSv4 deals with whose
processing is defined by other Internet standards, and where issues processing is defined by other Internet standards, and where issues
related to different handling choices by server operating systems or related to different handling choices by server operating systems or
server file systems do not apply. server file systems do not apply.
These are as follows: These are as follows:
o Server names as they appear in the fs_locations attribute. Note o Server names as they appear in the fs_locations attribute. Note
that for most purposes, such server names will only be sent by the that for most purposes, such server names will only be sent by the
skipping to change at page 171, line 35 skipping to change at page 172, line 17
server does not map domain strings which are not U-labels into a server does not map domain strings which are not U-labels into a
U-label, which it MAY do, it MUST NOT modify the domain, and the U-label, which it MAY do, it MUST NOT modify the domain, and the
domain returned on a GETATTR of the userid MUST be the same as that domain returned on a GETATTR of the userid MUST be the same as that
used when setting the userid by the SETATTR. used when setting the userid by the SETATTR.
The server MAY implement VERIFY and NVERIFY without translating The server MAY implement VERIFY and NVERIFY without translating
internal state to a string form, so that, for example, a user internal state to a string form, so that, for example, a user
principal which represents a specific numeric user id, will match a principal which represents a specific numeric user id, will match a
different principal string which represents the same numeric user id. different principal string which represents the same numeric user id.
12.5. UTF-8 Related Errors 12.6. UTF-8 Related Errors
Where the client sends an invalid UTF-8 string, the server MAY return Where the client sends an invalid UTF-8 string, the server MAY return
an NFS4ERR_INVAL error. This includes cases in which inappropriate an NFS4ERR_INVAL error. This includes cases in which inappropriate
prefixes are detected and where the count includes trailing bytes prefixes are detected and where the count includes trailing bytes
that do not constitute a full UCS character. that do not constitute a full UCS character.
Requirements for server handling of component names which are not Requirements for server handling of component names which are not
valid UTF-8, when a server does not return NFS4ERR_INVAL in response valid UTF-8, when a server does not return NFS4ERR_INVAL in response
to receiving these are described in Section 12.6. to receiving them, are described in Section 12.7.
Where the client supplied string is not rejected with NFS4ERR_INVAL Where the client supplied string is not rejected with NFS4ERR_INVAL
but contains characters that are not supported by the server as a but contains characters that are not supported by the server as a
value for that string (e.g., names containing slashes or characters value for that string (e.g., names containing slashes, or characters
that have more than two octets on a filesystem that supports Unicode that have more than two octets on a filesystem that supports Unicode
characters only), the server should return an NFS4ERR_BADCHAR error. characters only), the server should return an NFS4ERR_BADCHAR error.
Where a UTF-8 string is used as a file name, and the file system, Where a UTF-8 string is used as a file name, and the file system,
while supporting all of the characters within the name, does not while supporting all of the characters within the name, does not
allow that particular name to be used, the error should return the allow that particular name to be used, the error should return the
error NFS4ERR_BADNAME. This includes such situations as file system error NFS4ERR_BADNAME. This includes such situations as file system
prohibitions of "." and ".." as file names for certain operations, prohibitions of "." and ".." as file names for certain operations,
and similar constraints and similar constraints
12.6. Handling of component names that are not valid UTF-8 strings 12.7. Handling of component names that are not valid UTF-8 strings
In cases in which the server receives a component name that is not a In cases in which the server receives a component name that is not a
valid UTF-8 string, the required handling depends on whether a file valid UTF-8 string, the required handling depends on whether a file
object is being created or looked up. Object creation happens for object is being created or looked up. Object creation happens for
the component name in LINK and CREATE, and the second component name the component name in LINK and CREATE, and the second component name
in RENAME. Object lookup happens for the component name in LOOKUP in RENAME. Object lookup happens for the component name in LOOKUP
and REMOVE, and the first component name in RENAME. The component and REMOVE, and the first component name in RENAME. The component
name in OPEN will result in object lookup and also object creation if name in OPEN will result in object lookup and also object creation if
the lookup fails and the other OPEN parameters allow file creation. the lookup fails and the other OPEN parameters allow file creation.
With regard to normalization-related processing, it is generally With regard to normalization-related processing, it is generally
inhibited, both in the case of object creation and object lookup: inhibited, both in the case of object creation and object lookup:
o Characters which are not valid UTF-8, have no canonically o Characters which are not valid UTF-8 have no canonically
equivalent Unicode string so normalization-related processing equivalent Unicode string, so normalization-related processing
cannot happen. cannot happen.
o In cases in which a string has valid UTF-8 character strings that o In cases in which a string has valid UTF-8 character strings that
do have canonically equivalent Unicode strings, but if the do have canonically equivalent Unicode strings, but if the
component name is not valid UTF-8, the server MAY perform component name is not valid UTF-8, the server MAY perform
normalization-related processing on valid UTF-8 substrings within normalization-related processing on valid UTF-8 substrings within
it that do have canonical equivalents. it that do have canonical equivalents.
When creation of a component name which is not valid UTF-8 occurs, When creation of a component name which is not valid UTF-8 occurs,
and is allowed by the server: and is allowed by the server:
skipping to change at page 212, line 16 skipping to change at page 213, line 16
server will return the error NFS4ERR_EXIST. server will return the error NFS4ERR_EXIST.
For the directory where the new file object was created, the server For the directory where the new file object was created, the server
returns change_info4 information in cinfo. With the atomic field of returns change_info4 information in cinfo. With the atomic field of
the change_info4 struct, the server will indicate if the before and the change_info4 struct, the server will indicate if the before and
after change attributes were obtained atomically with respect to the after change attributes were obtained atomically with respect to the
file object creation. file object creation.
If the objname is of zero length, NFS4ERR_INVAL will be returned. If the objname is of zero length, NFS4ERR_INVAL will be returned.
The objname is also subject to the normal UTF-8, character support, The objname is also subject to the normal UTF-8, character support,
and name checks. See Section 12.5 for further discussion. and name checks. See Section 12.6 for further discussion.
If the objname has a length of 0 (zero), or if objname does not obey If the objname has a length of 0 (zero), or if objname does not obey
the UTF-8 definition, the error NFS4ERR_INVAL will be returned. the UTF-8 definition, the error NFS4ERR_INVAL will be returned.
The current filehandle is replaced by that of the new object. The current filehandle is replaced by that of the new object.
The createattrs specifies the initial set of attributes for the The createattrs specifies the initial set of attributes for the
object. The set of attributes may include any writable attribute object. The set of attributes may include any writable attribute
valid for the object type. When the operation is successful, the valid for the object type. When the operation is successful, the
server will return to the client an attribute mask signifying which server will return to the client an attribute mask signifying which
skipping to change at page 227, line 26 skipping to change at page 228, line 26
component and if the object exists the current filehandle is replaced component and if the object exists the current filehandle is replaced
with the component's filehandle. with the component's filehandle.
If the component cannot be evaluated either because it does not exist If the component cannot be evaluated either because it does not exist
or because the client does not have permission to evaluate the or because the client does not have permission to evaluate the
component, then an error will be returned and the current filehandle component, then an error will be returned and the current filehandle
will be unchanged. will be unchanged.
If the component is of zero length, NFS4ERR_INVAL will be returned. If the component is of zero length, NFS4ERR_INVAL will be returned.
The component is also subject to the normal UTF-8, character support, The component is also subject to the normal UTF-8, character support,
and name checks. See Section 12.5 for further discussion. and name checks. See Section 12.6 for further discussion.
15.15.5. IMPLEMENTATION 15.15.5. IMPLEMENTATION
If the client wants to achieve the effect of a multi-component If the client wants to achieve the effect of a multi-component
lookup, it may construct a COMPOUND request such as (and obtain each lookup, it may construct a COMPOUND request such as (and obtain each
filehandle): filehandle):
PUTFH (directory filehandle) PUTFH (directory filehandle)
LOOKUP "pub" LOOKUP "pub"
GETFH GETFH
skipping to change at page 237, line 24 skipping to change at page 238, line 24
OPEN4_RESULT_CONFIRM indicates that the client MUST execute an OPEN4_RESULT_CONFIRM indicates that the client MUST execute an
OPEN_CONFIRM operation before using the open file. OPEN_CONFIRM operation before using the open file.
OPEN4_RESULT_LOCKTYPE_POSIX indicates the server's file locking OPEN4_RESULT_LOCKTYPE_POSIX indicates the server's file locking
behavior supports the complete set of Posix locking techniques behavior supports the complete set of Posix locking techniques
[fcntl]. From this the client can choose to manage file locking [fcntl]. From this the client can choose to manage file locking
state in a way to handle a mis-match of file locking management. state in a way to handle a mis-match of file locking management.
If the component is of zero length, NFS4ERR_INVAL will be returned. If the component is of zero length, NFS4ERR_INVAL will be returned.
The component is also subject to the normal UTF-8, character support, The component is also subject to the normal UTF-8, character support,
and name checks. See Section 12.5 for further discussion. and name checks. See Section 12.6 for further discussion.
When an OPEN is done and the specified open-owner already has the When an OPEN is done and the specified open-owner already has the
resulting filehandle open, the result is to "OR" together the new resulting filehandle open, the result is to "OR" together the new
share and deny status together with the existing status. In this share and deny status together with the existing status. In this
case, only a single CLOSE need be done, even though multiple OPENs case, only a single CLOSE need be done, even though multiple OPENs
were completed. When such an OPEN is done, checking of share were completed. When such an OPEN is done, checking of share
reservations for the new OPEN proceeds normally, with no exception reservations for the new OPEN proceeds normally, with no exception
for the existing OPEN held by the same owner. In this case, the for the existing OPEN held by the same owner. In this case, the
stateid returned as an "other" field that matches that of the stateid returned as an "other" field that matches that of the
previous open while the "seqid" field is incremented to reflect the previous open while the "seqid" field is incremented to reflect the
skipping to change at page 255, line 33 skipping to change at page 256, line 33
corresponding file system object, the object may be destroyed. corresponding file system object, the object may be destroyed.
For the directory where the filename was removed, the server returns For the directory where the filename was removed, the server returns
change_info4 information in cinfo. With the atomic field of the change_info4 information in cinfo. With the atomic field of the
change_info4 struct, the server will indicate if the before and after change_info4 struct, the server will indicate if the before and after
change attributes were obtained atomically with respect to the change attributes were obtained atomically with respect to the
removal. removal.
If the target is of zero length, NFS4ERR_INVAL will be returned. The If the target is of zero length, NFS4ERR_INVAL will be returned. The
target is also subject to the normal UTF-8, character support, and target is also subject to the normal UTF-8, character support, and
name checks. See Section 12.5 for further discussion. name checks. See Section 12.6 for further discussion.
On success, the current filehandle retains its value. On success, the current filehandle retains its value.
15.28.5. IMPLEMENTATION 15.28.5. IMPLEMENTATION
NFSv3 required a different operator RMDIR for directory removal and NFSv3 required a different operator RMDIR for directory removal and
REMOVE for non-directory removal. This allowed clients to skip REMOVE for non-directory removal. This allowed clients to skip
checking the file type when being passed a non-directory delete checking the file type when being passed a non-directory delete
system call (e.g., unlink() [unlink] in POSIX) to remove a directory, system call (e.g., unlink() [unlink] in POSIX) to remove a directory,
as well as the converse (e.g., a rmdir() on a non-directory) because as well as the converse (e.g., a rmdir() on a non-directory) because
skipping to change at page 258, line 7 skipping to change at page 259, line 7
struct, the server will indicate if the before and after change struct, the server will indicate if the before and after change
attributes were obtained atomically with respect to the rename. attributes were obtained atomically with respect to the rename.
If the oldname refers to a named attribute and the saved and current If the oldname refers to a named attribute and the saved and current
filehandles refer to different file system objects, the server will filehandles refer to different file system objects, the server will
return NFS4ERR_XDEV just as if the saved and current filehandles return NFS4ERR_XDEV just as if the saved and current filehandles
represented directories on different file systems. represented directories on different file systems.
If the oldname or newname is of zero length, NFS4ERR_INVAL will be If the oldname or newname is of zero length, NFS4ERR_INVAL will be
returned. The oldname and newname are also subject to the normal returned. The oldname and newname are also subject to the normal
UTF-8, character support, and name checks. See Section 12.5 for UTF-8, character support, and name checks. See Section 12.6 for
further discussion. further discussion.
15.29.5. IMPLEMENTATION 15.29.5. IMPLEMENTATION
The RENAME operation must be atomic to the client. The statement The RENAME operation must be atomic to the client. The statement
"source and target directories must reside on the same file system on "source and target directories must reside on the same file system on
the server" means that the fsid fields in the attributes for the the server" means that the fsid fields in the attributes for the
directories are the same. If they reside on different file systems, directories are the same. If they reside on different file systems,
the error, NFS4ERR_XDEV, is returned. the error, NFS4ERR_XDEV, is returned.
skipping to change at page 291, line 8 skipping to change at page 292, line 8
"Information Technology - Universal Multiple-octet coded "Information Technology - Universal Multiple-octet coded
Character Set (UCS) - Part 1: Architecture and Basic Character Set (UCS) - Part 1: Architecture and Basic
Multilingual Plane", ISO Standard 10646-1, May 1993. Multilingual Plane", ISO Standard 10646-1, May 1993.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997. Requirement Levels", March 1997.
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997. Specification", RFC 2203, September 1997.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
Languages", BCP 18, RFC 2277, January 1998. 10646", RFC 2279, January 1998.
[RFC2743] Linn, J., "Generic Security Service Application Program [RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC5403] Eisler, M., "RPCSEC_GSS Version 2", RFC 5403, [RFC5403] Eisler, M., "RPCSEC_GSS Version 2", RFC 5403,
February 2009. February 2009.
[RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 5531, May 2009. Specification Version 2", RFC 5531, May 2009.
skipping to change at page 293, line 6 skipping to change at page 294, line 6
[RFC2755] Chiu, A., Eisler, M., and B. Callaghan, "Security [RFC2755] Chiu, A., Eisler, M., and B. Callaghan, "Security
Negotiation for WebNFS", RFC 2755, January 2000. Negotiation for WebNFS", RFC 2755, January 2000.
[RFC3010] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., [RFC3010] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "Network File System Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3010, December 2000. (NFS) version 4 Protocol", RFC 3010, December 2000.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002. an On-line Database", RFC 3232, January 2002.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454,
December 2002.
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "Network File System Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3530, April 2003. (NFS) version 4 Protocol", RFC 3530, April 2003.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Version 5 Generic Security Service Application Program Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism: Version 2", RFC 4121, Interface (GSS-API) Mechanism: Version 2", RFC 4121,
July 2005. July 2005.
[RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
 End of changes. 36 change blocks. 
114 lines changed or deleted 143 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/