draft-ietf-nfsv4-rfc3530bis-30.txt   draft-ietf-nfsv4-rfc3530bis-31.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 February 13, 2014
Expires: July 13, 2014 January 09, 2014 Expires: August 17, 2014
Network File System (NFS) Version 4 Protocol Network File System (NFS) Version 4 Protocol
draft-ietf-nfsv4-rfc3530bis-30.txt draft-ietf-nfsv4-rfc3530bis-31.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 July 13, 2014. This Internet-Draft will expire on August 17, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 4, line 9 skipping to change at page 4, line 9
5.5. Set-Only and Get-Only Attributes . . . . . . . . . . . . 39 5.5. Set-Only and Get-Only Attributes . . . . . . . . . . . . 39
5.6. REQUIRED Attributes - List and Definition References . . 39 5.6. REQUIRED Attributes - List and Definition References . . 39
5.7. RECOMMENDED Attributes - List and Definition 5.7. RECOMMENDED Attributes - List and Definition
References . . . . . . . . . . . . . . . . . . . . . . . 40 References . . . . . . . . . . . . . . . . . . . . . . . 40
5.8. Attribute Definitions . . . . . . . . . . . . . . . . . 41 5.8. Attribute Definitions . . . . . . . . . . . . . . . . . 41
5.8.1. Definitions of REQUIRED Attributes . . . . . . . . . 41 5.8.1. Definitions of REQUIRED Attributes . . . . . . . . . 41
5.8.2. Definitions of Uncategorized RECOMMENDED 5.8.2. Definitions of Uncategorized RECOMMENDED
Attributes . . . . . . . . . . . . . . . . . . . . . 43 Attributes . . . . . . . . . . . . . . . . . . . . . 43
5.9. Interpreting owner and owner_group . . . . . . . . . . . 49 5.9. Interpreting owner and owner_group . . . . . . . . . . . 49
5.10. Character Case Attributes . . . . . . . . . . . . . . . 52 5.10. Character Case Attributes . . . . . . . . . . . . . . . 52
6. Access Control Attributes . . . . . . . . . . . . . . . . . . 52 6. Access Control Attributes . . . . . . . . . . . . . . . . . . 53
6.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2. File Attributes Discussion . . . . . . . . . . . . . . . 53 6.2. File Attributes Discussion . . . . . . . . . . . . . . . 54
6.2.1. Attribute 12: acl . . . . . . . . . . . . . . . . . 53 6.2.1. Attribute 12: acl . . . . . . . . . . . . . . . . . 54
6.2.2. Attribute 33: mode . . . . . . . . . . . . . . . . . 68 6.2.2. Attribute 33: mode . . . . . . . . . . . . . . . . . 68
6.3. Common Methods . . . . . . . . . . . . . . . . . . . . . 68 6.3. Common Methods . . . . . . . . . . . . . . . . . . . . . 69
6.3.1. Interpreting an ACL . . . . . . . . . . . . . . . . 68 6.3.1. Interpreting an ACL . . . . . . . . . . . . . . . . 69
6.3.2. Computing a Mode Attribute from an ACL . . . . . . . 69 6.3.2. Computing a Mode Attribute from an ACL . . . . . . . 70
6.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 70 6.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 71
6.4.1. Setting the mode and/or ACL Attributes . . . . . . . 71 6.4.1. Setting the mode and/or ACL Attributes . . . . . . . 71
6.4.2. Retrieving the mode and/or ACL Attributes . . . . . 72 6.4.2. Retrieving the mode and/or ACL Attributes . . . . . 73
6.4.3. Creating New Objects . . . . . . . . . . . . . . . . 72 6.4.3. Creating New Objects . . . . . . . . . . . . . . . . 73
7. NFS Server Name Space . . . . . . . . . . . . . . . . . . . . 74 7. NFS Server Name Space . . . . . . . . . . . . . . . . . . . . 75
7.1. Server Exports . . . . . . . . . . . . . . . . . . . . . 74 7.1. Server Exports . . . . . . . . . . . . . . . . . . . . . 75
7.2. Browsing Exports . . . . . . . . . . . . . . . . . . . . 74 7.2. Browsing Exports . . . . . . . . . . . . . . . . . . . . 75
7.3. Server Pseudo Filesystem . . . . . . . . . . . . . . . . 75 7.3. Server Pseudo Filesystem . . . . . . . . . . . . . . . . 76
7.4. Multiple Roots . . . . . . . . . . . . . . . . . . . . . 75 7.4. Multiple Roots . . . . . . . . . . . . . . . . . . . . . 76
7.5. Filehandle Volatility . . . . . . . . . . . . . . . . . 76 7.5. Filehandle Volatility . . . . . . . . . . . . . . . . . 76
7.6. Exported Root . . . . . . . . . . . . . . . . . . . . . 76 7.6. Exported Root . . . . . . . . . . . . . . . . . . . . . 77
7.7. Mount Point Crossing . . . . . . . . . . . . . . . . . . 76 7.7. Mount Point Crossing . . . . . . . . . . . . . . . . . . 77
7.8. Security Policy and Name Space Presentation . . . . . . 77 7.8. Security Policy and Name Space Presentation . . . . . . 77
8. Multi-Server Namespace . . . . . . . . . . . . . . . . . . . 77 8. Multi-Server Namespace . . . . . . . . . . . . . . . . . . . 78
8.1. Location Attributes . . . . . . . . . . . . . . . . . . 78 8.1. Location Attributes . . . . . . . . . . . . . . . . . . 78
8.2. File System Presence or Absence . . . . . . . . . . . . 78 8.2. File System Presence or Absence . . . . . . . . . . . . 79
8.3. Getting Attributes for an Absent File System . . . . . . 79 8.3. Getting Attributes for an Absent File System . . . . . . 80
8.3.1. GETATTR Within an Absent File System . . . . . . . . 79 8.3.1. GETATTR Within an Absent File System . . . . . . . . 80
8.3.2. READDIR and Absent File Systems . . . . . . . . . . 80 8.3.2. READDIR and Absent File Systems . . . . . . . . . . 81
8.4. Uses of Location Information . . . . . . . . . . . . . . 81 8.4. Uses of Location Information . . . . . . . . . . . . . . 82
8.4.1. File System Replication . . . . . . . . . . . . . . 82 8.4.1. File System Replication . . . . . . . . . . . . . . 82
8.4.2. File System Migration . . . . . . . . . . . . . . . 82 8.4.2. File System Migration . . . . . . . . . . . . . . . 83
8.4.3. Referrals . . . . . . . . . . . . . . . . . . . . . 83 8.4.3. Referrals . . . . . . . . . . . . . . . . . . . . . 84
8.5. Location Entries and Server Identity . . . . . . . . . . 84 8.5. Location Entries and Server Identity . . . . . . . . . . 85
8.6. Additional Client-Side Considerations . . . . . . . . . 84 8.6. Additional Client-Side Considerations . . . . . . . . . 85
8.7. Effecting File System Referrals . . . . . . . . . . . . 85 8.7. Effecting File System Referrals . . . . . . . . . . . . 86
8.7.1. Referral Example (LOOKUP) . . . . . . . . . . . . . 86 8.7.1. Referral Example (LOOKUP) . . . . . . . . . . . . . 87
8.7.2. Referral Example (READDIR) . . . . . . . . . . . . . 90 8.7.2. Referral Example (READDIR) . . . . . . . . . . . . . 90
8.8. The Attribute fs_locations . . . . . . . . . . . . . . . 92 8.8. The Attribute fs_locations . . . . . . . . . . . . . . . 93
8.8.1. Inferring Transition Modes . . . . . . . . . . . . . 94 8.8.1. Inferring Transition Modes . . . . . . . . . . . . . 95
9. File Locking and Share Reservations . . . . . . . . . . . . . 95 9. File Locking and Share Reservations . . . . . . . . . . . . . 96
9.1. Opens and Byte-Range Locks . . . . . . . . . . . . . . . 96 9.1. Opens and Byte-Range Locks . . . . . . . . . . . . . . . 97
9.1.1. Client ID . . . . . . . . . . . . . . . . . . . . . 97 9.1.1. Client ID . . . . . . . . . . . . . . . . . . . . . 97
9.1.2. Server Release of Client ID . . . . . . . . . . . . 100 9.1.2. Server Release of Client ID . . . . . . . . . . . . 100
9.1.3. Stateid Definition . . . . . . . . . . . . . . . . . 100 9.1.3. Stateid Definition . . . . . . . . . . . . . . . . . 101
9.1.4. lock-owner . . . . . . . . . . . . . . . . . . . . . 106 9.1.4. lock-owner . . . . . . . . . . . . . . . . . . . . . 107
9.1.5. Use of the Stateid and Locking . . . . . . . . . . . 107 9.1.5. Use of the Stateid and Locking . . . . . . . . . . . 107
9.1.6. Sequencing of Lock Requests . . . . . . . . . . . . 109 9.1.6. Sequencing of Lock Requests . . . . . . . . . . . . 110
9.1.7. Recovery from Replayed Requests . . . . . . . . . . 110 9.1.7. Recovery from Replayed Requests . . . . . . . . . . 111
9.1.8. Interactions of multiple sequence values . . . . . . 110 9.1.8. Interactions of multiple sequence values . . . . . . 111
9.1.9. Releasing state-owner State . . . . . . . . . . . . 111 9.1.9. Releasing state-owner State . . . . . . . . . . . . 112
9.1.10. Use of Open Confirmation . . . . . . . . . . . . . . 112 9.1.10. Use of Open Confirmation . . . . . . . . . . . . . . 113
9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 113 9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 114
9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . 114 9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . 114
9.4. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 114 9.4. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 115
9.5. Lease Renewal . . . . . . . . . . . . . . . . . . . . . 115 9.5. Lease Renewal . . . . . . . . . . . . . . . . . . . . . 116
9.6. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 116 9.6. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 116
9.6.1. Client Failure and Recovery . . . . . . . . . . . . 116 9.6.1. Client Failure and Recovery . . . . . . . . . . . . 117
9.6.2. Server Failure and Recovery . . . . . . . . . . . . 117 9.6.2. Server Failure and Recovery . . . . . . . . . . . . 117
9.6.3. Network Partitions and Recovery . . . . . . . . . . 118 9.6.3. Network Partitions and Recovery . . . . . . . . . . 119
9.7. Recovery from a Lock Request Timeout or Abort . . . . . 126 9.7. Recovery from a Lock Request Timeout or Abort . . . . . 127
9.8. Server Revocation of Locks . . . . . . . . . . . . . . . 126 9.8. Server Revocation of Locks . . . . . . . . . . . . . . . 127
9.9. Share Reservations . . . . . . . . . . . . . . . . . . . 128 9.9. Share Reservations . . . . . . . . . . . . . . . . . . . 128
9.10. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 128 9.10. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 129
9.10.1. Close and Retention of State Information . . . . . . 129 9.10.1. Close and Retention of State Information . . . . . . 130
9.11. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 130 9.11. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 130
9.12. Short and Long Leases . . . . . . . . . . . . . . . . . 131 9.12. Short and Long Leases . . . . . . . . . . . . . . . . . 131
9.13. Clocks, Propagation Delay, and Calculating Lease 9.13. Clocks, Propagation Delay, and Calculating Lease
Expiration . . . . . . . . . . . . . . . . . . . . . . . 131 Expiration . . . . . . . . . . . . . . . . . . . . . . . 132
9.14. Migration, Replication and State . . . . . . . . . . . . 132 9.14. Migration, Replication and State . . . . . . . . . . . . 132
9.14.1. Migration and State . . . . . . . . . . . . . . . . 132 9.14.1. Migration and State . . . . . . . . . . . . . . . . 133
9.14.2. Replication and State . . . . . . . . . . . . . . . 133 9.14.2. Replication and State . . . . . . . . . . . . . . . 133
9.14.3. Notification of Migrated Lease . . . . . . . . . . . 133 9.14.3. Notification of Migrated Lease . . . . . . . . . . . 134
9.14.4. Migration and the Lease_time Attribute . . . . . . . 134 9.14.4. Migration and the Lease_time Attribute . . . . . . . 135
10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 135 10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 135
10.1. Performance Challenges for Client-Side Caching . . . . . 135 10.1. Performance Challenges for Client-Side Caching . . . . . 136
10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 136 10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 137
10.2.1. Delegation Recovery . . . . . . . . . . . . . . . . 138 10.2.1. Delegation Recovery . . . . . . . . . . . . . . . . 138
10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 142 10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 143
10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 143 10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 143
10.3.2. Data Caching and File Locking . . . . . . . . . . . 144 10.3.2. Data Caching and File Locking . . . . . . . . . . . 144
10.3.3. Data Caching and Mandatory File Locking . . . . . . 145 10.3.3. Data Caching and Mandatory File Locking . . . . . . 146
10.3.4. Data Caching and File Identity . . . . . . . . . . . 146 10.3.4. Data Caching and File Identity . . . . . . . . . . . 146
10.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 147 10.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 147
10.4.1. Open Delegation and Data Caching . . . . . . . . . . 149 10.4.1. Open Delegation and Data Caching . . . . . . . . . . 150
10.4.2. Open Delegation and File Locks . . . . . . . . . . . 150 10.4.2. Open Delegation and File Locks . . . . . . . . . . . 151
10.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 151 10.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 151
10.4.4. Recall of Open Delegation . . . . . . . . . . . . . 154 10.4.4. Recall of Open Delegation . . . . . . . . . . . . . 154
10.4.5. OPEN Delegation Race with CB_RECALL . . . . . . . . 156 10.4.5. OPEN Delegation Race with CB_RECALL . . . . . . . . 156
10.4.6. Clients that Fail to Honor Delegation Recalls . . . 156 10.4.6. Clients that Fail to Honor Delegation Recalls . . . 157
10.4.7. Delegation Revocation . . . . . . . . . . . . . . . 157 10.4.7. Delegation Revocation . . . . . . . . . . . . . . . 158
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 . . . 159
10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 159 10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 160
10.7. Data and Metadata Caching and Memory Mapped Files . . . 161 10.7. Data and Metadata Caching and Memory Mapped Files . . . 162
10.8. Name Caching . . . . . . . . . . . . . . . . . . . . . . 163 10.8. Name Caching . . . . . . . . . . . . . . . . . . . . . . 164
10.9. Directory Caching . . . . . . . . . . . . . . . . . . . 164 10.9. Directory Caching . . . . . . . . . . . . . . . . . . . 165
11. Minor Versioning . . . . . . . . . . . . . . . . . . . . . . 165 11. Minor Versioning . . . . . . . . . . . . . . . . . . . . . . 166
12. Internationalization . . . . . . . . . . . . . . . . . . . . 168 12. Internationalization . . . . . . . . . . . . . . . . . . . . 168
12.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 168 12.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 168
12.2. Limitations on internationalization-related 12.2. Limitations on internationalization-related
processing in the NFSv4 context . . . . . . . . . . . . 169 processing in the NFSv4 context . . . . . . . . . . . . 170
12.3. Summary of Server Behavior Types . . . . . . . . . . . . 170 12.3. Summary of Server Behavior Types . . . . . . . . . . . . 171
12.4. String Encoding . . . . . . . . . . . . . . . . . . . . 171 12.4. String Encoding . . . . . . . . . . . . . . . . . . . . 171
12.5. Normalization . . . . . . . . . . . . . . . . . . . . . 171 12.5. Normalization . . . . . . . . . . . . . . . . . . . . . 172
12.6. Types with Processing Defined by Other Internet Areas . 172 12.6. Types with Processing Defined by Other Internet Areas . 173
12.7. UTF-8 Related Errors . . . . . . . . . . . . . . . . . . 173 12.7. UTF-8 Related Errors . . . . . . . . . . . . . . . . . . 174
12.8. Servers that accept file component names that are not 12.8. Servers that accept file component names that are not
valid UTF-8 strings . . . . . . . . . . . . . . . . . . 174 valid UTF-8 strings . . . . . . . . . . . . . . . . . . 174
13. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 175 13. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 175
13.1. Error Definitions . . . . . . . . . . . . . . . . . . . 175 13.1. Error Definitions . . . . . . . . . . . . . . . . . . . 175
13.1.1. General Errors . . . . . . . . . . . . . . . . . . . 177 13.1.1. General Errors . . . . . . . . . . . . . . . . . . . 177
13.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 178 13.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 178
13.1.3. Compound Structure Errors . . . . . . . . . . . . . 179 13.1.3. Compound Structure Errors . . . . . . . . . . . . . 180
13.1.4. File System Errors . . . . . . . . . . . . . . . . . 180 13.1.4. File System Errors . . . . . . . . . . . . . . . . . 181
13.1.5. State Management Errors . . . . . . . . . . . . . . 182 13.1.5. State Management Errors . . . . . . . . . . . . . . 183
13.1.6. Security Errors . . . . . . . . . . . . . . . . . . 183 13.1.6. Security Errors . . . . . . . . . . . . . . . . . . 184
13.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 184 13.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 184
13.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 184 13.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 185
13.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 186 13.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 186
13.1.10. Client Management Errors . . . . . . . . . . . . . . 186 13.1.10. Client Management Errors . . . . . . . . . . . . . . 187
13.1.11. Attribute Handling Errors . . . . . . . . . . . . . 187 13.1.11. Attribute Handling Errors . . . . . . . . . . . . . 187
13.2. Operations and their valid errors . . . . . . . . . . . 187 13.2. Operations and their valid errors . . . . . . . . . . . 188
13.3. Callback operations and their valid errors . . . . . . . 194 13.3. Callback operations and their valid errors . . . . . . . 195
13.4. Errors and the operations that use them . . . . . . . . 195 13.4. Errors and the operations that use them . . . . . . . . 196
14. NFSv4 Requests . . . . . . . . . . . . . . . . . . . . . . . 199 14. NFSv4 Requests . . . . . . . . . . . . . . . . . . . . . . . 200
14.1. Compound Procedure . . . . . . . . . . . . . . . . . . . 200 14.1. Compound Procedure . . . . . . . . . . . . . . . . . . . 201
14.2. Evaluation of a Compound Request . . . . . . . . . . . . 200 14.2. Evaluation of a Compound Request . . . . . . . . . . . . 201
14.3. Synchronous Modifying Operations . . . . . . . . . . . . 201 14.3. Synchronous Modifying Operations . . . . . . . . . . . . 202
14.4. Operation Values . . . . . . . . . . . . . . . . . . . . 201 14.4. Operation Values . . . . . . . . . . . . . . . . . . . . 202
15. NFSv4 Procedures . . . . . . . . . . . . . . . . . . . . . . 202 15. NFSv4 Procedures . . . . . . . . . . . . . . . . . . . . . . 203
15.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 202 15.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 203
15.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 202 15.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 203
15.3. Operation 3: ACCESS - Check Access Rights . . . . . . . 206 15.3. Operation 3: ACCESS - Check Access Rights . . . . . . . 207
15.4. Operation 4: CLOSE - Close File . . . . . . . . . . . . 209 15.4. Operation 4: CLOSE - Close File . . . . . . . . . . . . 210
15.5. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 210 15.5. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 211
15.6. Operation 6: CREATE - Create a Non-Regular File Object . 212 15.6. Operation 6: CREATE - Create a Non-Regular File Object . 213
15.7. Operation 7: DELEGPURGE - Purge Delegations Awaiting 15.7. Operation 7: DELEGPURGE - Purge Delegations Awaiting
Recovery . . . . . . . . . . . . . . . . . . . . . . . . 215 Recovery . . . . . . . . . . . . . . . . . . . . . . . . 216
15.8. Operation 8: DELEGRETURN - Return Delegation . . . . . . 216 15.8. Operation 8: DELEGRETURN - Return Delegation . . . . . . 217
15.9. Operation 9: GETATTR - Get Attributes . . . . . . . . . 217 15.9. Operation 9: GETATTR - Get Attributes . . . . . . . . . 218
15.10. Operation 10: GETFH - Get Current Filehandle . . . . . . 219 15.10. Operation 10: GETFH - Get Current Filehandle . . . . . . 220
15.11. Operation 11: LINK - Create Link to a File . . . . . . . 220 15.11. Operation 11: LINK - Create Link to a File . . . . . . . 221
15.12. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 221 15.12. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 222
15.13. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 225 15.13. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 226
15.14. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 227 15.14. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 228
15.15. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 228 15.15. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 229
15.16. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 230 15.16. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 231
15.17. Operation 17: NVERIFY - Verify Difference in 15.17. Operation 17: NVERIFY - Verify Difference in
Attributes . . . . . . . . . . . . . . . . . . . . . . . 231 Attributes . . . . . . . . . . . . . . . . . . . . . . . 232
15.18. Operation 18: OPEN - Open a Regular File . . . . . . . . 232 15.18. Operation 18: OPEN - Open a Regular File . . . . . . . . 233
15.19. Operation 19: OPENATTR - Open Named Attribute 15.19. Operation 19: OPENATTR - Open Named Attribute
Directory . . . . . . . . . . . . . . . . . . . . . . . 242 Directory . . . . . . . . . . . . . . . . . . . . . . . 243
15.20. Operation 20: OPEN_CONFIRM - Confirm Open . . . . . . . 243 15.20. Operation 20: OPEN_CONFIRM - Confirm Open . . . . . . . 244
15.21. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 245 15.21. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 246
15.22. Operation 22: PUTFH - Set Current Filehandle . . . . . . 246 15.22. Operation 22: PUTFH - Set Current Filehandle . . . . . . 247
15.23. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 247 15.23. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 248
15.24. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 248 15.24. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 249
15.25. Operation 25: READ - Read from File . . . . . . . . . . 249 15.25. Operation 25: READ - Read from File . . . . . . . . . . 250
15.26. Operation 26: READDIR - Read Directory . . . . . . . . . 251 15.26. Operation 26: READDIR - Read Directory . . . . . . . . . 252
15.27. Operation 27: READLINK - Read Symbolic Link . . . . . . 255 15.27. Operation 27: READLINK - Read Symbolic Link . . . . . . 256
15.28. Operation 28: REMOVE - Remove Filesystem Object . . . . 256 15.28. Operation 28: REMOVE - Remove Filesystem Object . . . . 257
15.29. Operation 29: RENAME - Rename Directory Entry . . . . . 258 15.29. Operation 29: RENAME - Rename Directory Entry . . . . . 259
15.30. Operation 30: RENEW - Renew a Lease . . . . . . . . . . 260 15.30. Operation 30: RENEW - Renew a Lease . . . . . . . . . . 261
15.31. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 261 15.31. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 262
15.32. Operation 32: SAVEFH - Save Current Filehandle . . . . . 262 15.32. Operation 32: SAVEFH - Save Current Filehandle . . . . . 263
15.33. Operation 33: SECINFO - Obtain Available Security . . . 263 15.33. Operation 33: SECINFO - Obtain Available Security . . . 264
15.34. Operation 34: SETATTR - Set Attributes . . . . . . . . . 267 15.34. Operation 34: SETATTR - Set Attributes . . . . . . . . . 268
15.35. Operation 35: SETCLIENTID - Negotiate Client ID . . . . 269 15.35. Operation 35: SETCLIENTID - Negotiate Client ID . . . . 270
15.36. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID . 273 15.36. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID . 274
15.37. Operation 37: VERIFY - Verify Same Attributes . . . . . 276 15.37. Operation 37: VERIFY - Verify Same Attributes . . . . . 277
15.38. Operation 38: WRITE - Write to File . . . . . . . . . . 278 15.38. Operation 38: WRITE - Write to File . . . . . . . . . . 279
15.39. Operation 39: RELEASE_LOCKOWNER - Release Lockowner 15.39. Operation 39: RELEASE_LOCKOWNER - Release Lockowner
State . . . . . . . . . . . . . . . . . . . . . . . . . 282 State . . . . . . . . . . . . . . . . . . . . . . . . . 283
15.40. Operation 10044: ILLEGAL - Illegal operation . . . . . . 283 15.40. Operation 10044: ILLEGAL - Illegal operation . . . . . . 284
16. NFSv4 Callback Procedures . . . . . . . . . . . . . . . . . . 284 16. NFSv4 Callback Procedures . . . . . . . . . . . . . . . . . . 285
16.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 284 16.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 285
16.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 284 16.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 285
16.2.6. Operation 3: CB_GETATTR - Get Attributes . . . . . . 286 16.2.6. Operation 3: CB_GETATTR - Get Attributes . . . . . . 287
16.2.7. Operation 4: CB_RECALL - Recall an Open Delegation . 287 16.2.7. Operation 4: CB_RECALL - Recall an Open Delegation . 288
16.2.8. Operation 10044: CB_ILLEGAL - Illegal Callback 16.2.8. Operation 10044: CB_ILLEGAL - Illegal Callback
Operation . . . . . . . . . . . . . . . . . . . . . 288 Operation . . . . . . . . . . . . . . . . . . . . . 289
17. Security Considerations . . . . . . . . . . . . . . . . . . . 289 17. Security Considerations . . . . . . . . . . . . . . . . . . . 290
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 291 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 292
18.1. Named Attribute Definitions . . . . . . . . . . . . . . 291 18.1. Named Attribute Definitions . . . . . . . . . . . . . . 292
18.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 292 18.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 293
18.1.2. Updating Registrations . . . . . . . . . . . . . . . 292 18.1.2. Updating Registrations . . . . . . . . . . . . . . . 293
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 292 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 293
19.1. Normative References . . . . . . . . . . . . . . . . . . 292 19.1. Normative References . . . . . . . . . . . . . . . . . . 293
19.2. Informative References . . . . . . . . . . . . . . . . . 293 19.2. Informative References . . . . . . . . . . . . . . . . . 294
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 296 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 297
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 297 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 298
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 297 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 298
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 19, line 28 skipping to change at page 19, line 28
| | UTF-8 encoding for strings. | | | UTF-8 encoding for strings. |
| utf8str_cis | typedef utf8string utf8str_cis; | | utf8str_cis | typedef utf8string utf8str_cis; |
| | Case-insensitive UTF-8 string. | | | Case-insensitive UTF-8 string. |
| utf8str_cs | typedef utf8string utf8str_cs; | | utf8str_cs | typedef utf8string utf8str_cs; |
| | Case-sensitive UTF-8 string. | | | Case-sensitive UTF-8 string. |
| utf8str_mixed | typedef utf8string utf8str_mixed; | | utf8str_mixed | typedef utf8string utf8str_mixed; |
| | UTF-8 strings with a case-sensitive prefix and | | | UTF-8 strings with a case-sensitive prefix and |
| | a case-insensitive suffix. | | | a case-insensitive suffix. |
| component4 | typedef utf8str_cs component4; | | component4 | typedef utf8str_cs component4; |
| | Represents pathname components. | | | Represents pathname components. |
| linktext4 | typedef opaque linktext4; | | linktext4<> | typedef opaque linktext4<>; |
| | Symbolic link contents ("symbolic link" is | | | Symbolic link contents ("symbolic link" is |
| | defined in an Open Group [openg_symlink] | | | defined in an Open Group [openg_symlink] |
| | standard). | | | standard). |
| ascii_REQUIRED4 | typedef utf8string ascii_REQUIRED4; | | ascii_REQUIRED4 | typedef utf8string ascii_REQUIRED4; |
| | String MUST be sent as ASCII and thus is | | | String MUST be sent as ASCII and thus is |
| | automatically UTF-8. | | | automatically UTF-8. |
| pathname4 | typedef component4 pathname4<>; | | pathname4 | typedef component4 pathname4<>; |
| | Represents path name for fs_locations. | | | Represents path name for fs_locations. |
| nfs_lockid4 | typedef uint64_t nfs_lockid4; | | nfs_lockid4 | typedef uint64_t nfs_lockid4; |
| verifier4 | typedef opaque verifier4[NFS4_VERIFIER_SIZE]; | | verifier4 | typedef opaque verifier4[NFS4_VERIFIER_SIZE]; |
skipping to change at page 26, line 23 skipping to change at page 26, line 23
additional security flavor of RPCSEC_GSS has been introduced which additional security flavor of RPCSEC_GSS has been introduced which
uses the functionality of GSS-API [RFC2743]. This allows for the use uses the functionality of GSS-API [RFC2743]. This allows for the use
of various security mechanisms by the RPC layer without the of various security mechanisms by the RPC layer without the
additional implementation overhead of adding RPC security flavors. additional implementation overhead of adding RPC security flavors.
For NFSv4, the RPCSEC_GSS security flavor MUST be used to enable the For NFSv4, the RPCSEC_GSS security flavor MUST be used to enable the
mandatory security mechanism. Other flavors, such as, AUTH_NONE, mandatory security mechanism. Other flavors, such as, AUTH_NONE,
AUTH_SYS, and AUTH_DH MAY be implemented as well. AUTH_SYS, and AUTH_DH MAY be implemented as well.
3.2.1. Security mechanisms for NFSv4 3.2.1. Security mechanisms for NFSv4
RPCSEC_GSS, via GSS-API, normalizes access to mechanisms that provide RPCSEC_GSS, via GSS-API, supports multiple mechanisms that provide
security services. Therefore, NFSv4 clients and servers MUST support security services. For interoperability, NFSv4 clients and servers
the Kerberos V5 security mechanism. MUST support the Kerberos V5 security mechanism.
The use of RPCSEC_GSS requires selection of mechanism, quality of The use of RPCSEC_GSS requires selection of mechanism, quality of
protection (QOP), and service (authentication, integrity, privacy). protection (QOP), and service (authentication, integrity, privacy).
For the mandated security mechanisms, NFSv4 specifies that a QOP of For the mandated security mechanisms, NFSv4 specifies that a QOP of
zero is used, leaving it up to the mechanism or the mechanism's zero is used, leaving it up to the mechanism or the mechanism's
configuration to map QOP zero to an appropriate level of protection. configuration to map QOP zero to an appropriate level of protection.
Each mandated mechanism specifies a minimum set of cryptographic Each mandated mechanism specifies a minimum set of cryptographic
algorithms for implementing integrity and privacy. NFSv4 clients and algorithms for implementing integrity and privacy. NFSv4 clients and
servers MUST be implemented on operating environments that comply servers MUST be implemented on operating environments that comply
with the REQUIRED cryptographic algorithms of each REQUIRED with the REQUIRED cryptographic algorithms of each REQUIRED
skipping to change at page 49, line 41 skipping to change at page 49, line 41
The time of last modification to the object. The time of last modification to the object.
5.8.2.40. Attribute 54: time_modify_set 5.8.2.40. Attribute 54: time_modify_set
Sets the time of last modification to the object. SETATTR use only. Sets the time of last modification to the object. SETATTR use only.
5.9. Interpreting owner and owner_group 5.9. Interpreting owner and owner_group
The RECOMMENDED attributes "owner" and "owner_group" (and also users The RECOMMENDED attributes "owner" and "owner_group" (and also users
and groups within the "acl" attribute) are represented in terms of a and groups used as values of the "who" field within nfs4ace
UTF-8 string. To avoid a representation that is tied to a particular structures used in the acl attribute) are represented in the form of
underlying implementation at the client or server, the use of the UTF-8 strings. This format avoids use of a representation that is
UTF-8 string has been chosen. Note that section 6.1 of RFC 2624 tied to a particular underlying implementation at the client or
[RFC2624] provides additional rationale. It is expected that the server. Note that section 6.1 of [RFC2624] provides additional
client and server will have their own local representation of owner rationale. It is expected that the client and server will have their
and owner_group that is used for local storage or presentation to the own local representation of owners and groups that is used for local
end user. Therefore, it is expected that when these attributes are storage or presentation to the application via API's that expect such
transferred between the client and server, the local representation a representation. Therefore, the protocol requires that when these
is translated to a syntax of the form "user@dns_domain". This will attributes are transferred between the client and server, the local
allow for a client and server that do not use the same local representation is translated to a string of the form "identifier@
representation the ability to translate to a common syntax that can dns_domain". This allows clients and servers that do not use the
be interpreted by both. same local representation to effectively interoperate since they both
use a common syntax that can be interpreted by both.
Similarly, security principals may be represented in different ways Similarly, security principals may be represented in different ways
by different security mechanisms. Servers normally translate these by different security mechanisms. Servers normally translate these
representations into a common format, generally that used by local representations into a common format, generally that used by local
storage, to serve as a means of identifying the users corresponding storage, to serve as a means of identifying the users corresponding
to these security principals. When these local identifiers are to these security principals. When these local identifiers are
translated to the form of the owner attribute, associated with files translated to the form of the owner attribute, associated with files
created by such principals, they identify, in a common format, the created by such principals, they identify, in a common format, the
users associated with each corresponding set of security principals. users associated with each corresponding set of security principals.
skipping to change at page 50, line 29 skipping to change at page 50, line 30
that maps a numeric identifier to the user@dns_domain syntax. A name that maps a numeric identifier to the user@dns_domain syntax. A name
service may also be used to accomplish the translation. A server may service may also be used to accomplish the translation. A server may
provide a more general service, not limited by any particular provide a more general service, not limited by any particular
translation (which would only translate a limited set of possible translation (which would only translate a limited set of possible
strings) by storing the owner and owner_group attributes in local strings) by storing the owner and owner_group attributes in local
storage without any translation or it may augment a translation storage without any translation or it may augment a translation
method by storing the entire string for attributes for which no method by storing the entire string for attributes for which no
translation is available while using the local representation for translation is available while using the local representation for
those cases in which a translation is available. those cases in which a translation is available.
Servers that do not provide support for all possible values of the Servers that do not provide support for all possible values of user
owner and owner_group attributes SHOULD return an error and group strings SHOULD return an error (NFS4ERR_BADOWNER) when a
(NFS4ERR_BADOWNER) when a string is presented that has no string is presented that has no translation, as the value to be set
translation, as the value to be set for a SETATTR of the owner, for a SETATTR of the owner or owner_group attributes or as part of
owner_group, or acl attributes. When a server does accept an owner the value of the acl attribute When a server does accept a user or
or owner_group value as valid on a SETATTR (and similarly for the group string as valid on a SETATTR, it is promising to return that
owner and group strings in an acl), it is promising to return that
same string (for which see below) when a corresponding GETATTR is same string (for which see below) when a corresponding GETATTR is
done. For some internationalization-related exceptions where this is done, as long as there has been no further change in the
not possible, see below. Configuration changes (including changes corresponding attribute before the GETATTR. For some
from the mapping of the string to the local representation) and ill- internationalization-related exceptions where this is not possible,
constructed name translations (those that contain aliasing) may make see below. Configuration changes (including changes from the mapping
that promise impossible to honor. Servers should make appropriate of the string to the local representation) and ill-constructed name
efforts to avoid a situation in which these attributes have their translations (those that contain aliasing) may make that promise
values changed when no real change to ownership has occurred. impossible to honor. Servers should make appropriate efforts to
avoid a situation in which these attributes have their values changed
when no real change to either ownership or acls has occurred.
The "dns_domain" portion of the owner string is meant to be a DNS The "dns_domain" portion of the owner string is meant to be a DNS
domain name. For example, user@example.org. Servers should accept domain name. For example, "user@example.org". Servers should accept
as valid a set of users for at least one domain. A server may treat as valid a set of users for at least one domain. A server may treat
other domains as having no valid translations. A more general other domains as having no valid translations. A more general
service is provided when a server is capable of accepting users for service is provided when a server is capable of accepting users for
multiple domains, or for all domains, subject to security multiple domains, or for all domains, subject to security
constraints. constraints.
As an implementation guide, both clients and servers may provide a As an implementation guide, both clients and servers may provide a
means to configure the "dns_domain" portion of the owner string. For means to configure the "dns_domain" portion of the owner string. For
example, the DNS domain name might be "lab.example.org", but the user example, the DNS domain name might be "lab.example.org", but the user
names are defined in "example.org". In the absence of such a names are defined in "example.org". In the absence of such a
configuration, or as a default, the current DNS domain name of the configuration, or as a default, the current DNS domain name of the
server should be the value used for the "dns_domain". server should be the value used for the "dns_domain".
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 an
U-label (see [RFC5890]), if presented using a form other than a equivalent U-label (see [RFC5890]), if presented using a form
U-label. See Section 12.6 for details. other than an U-label. See Section 12.6 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, as a result
normalization issues, although it will always be a canonically of Unicode normalization at the server. The result SHOULD be a
equivalent string. canonically equivalent Unicode string [UNICODE]. Other sorts of
string modification, including case mapping or folding, SHOULD NOT
be done as such modifications may cause the server to merge
identities that are separate at the client.
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
a basis for translation into its own internal format. Even though a basis for translation into its own internal format. Even though
the attribute value cannot be translated, it may still be useful. In the attribute value cannot be translated, it may still be useful. In
the case of a client, the attribute string may be used for local the case of a client, the attribute string may be used for local
display of ownership. display of ownership.
skipping to change at page 52, line 25 skipping to change at page 52, line 31
the the client should only use named identifiers of the form "user@ the the client should only use named identifiers of the form "user@
dns_domain". dns_domain".
The owner string "nobody" may be used to designate an anonymous user, The owner string "nobody" may be used to designate an anonymous user,
which will be associated with a file created by a security principal which will be associated with a file created by a security principal
that cannot be mapped through normal means to the owner attribute. that cannot be mapped through normal means to the owner attribute.
5.10. Character Case Attributes 5.10. Character Case Attributes
With respect to the case_insensitive and case_preserving attributes, With respect to the case_insensitive and case_preserving attributes,
each Universal Multiple-octet coded Character Set-4 (UCS-4) case insensitive comparisons of Unicode characters SHOULD use Unicode
[ISO.10646-1.1993] character (which UTF-8 encodes) has a "long Default Case Folding as defined in Chapter 3 of the Unicode Standard
descriptive name" RFC1345 [RFC1345] which may or may not include the [UNICODE], and MAY override that behavior for specific selected
word "CAPITAL" or "SMALL". The presence of SMALL or CAPITAL allows characters with the case folding defined in the SpecialCasing.txt
an NFS server to implement unambiguous and efficient table driven [SPECIALCASING] file in section 3.13 of the Unicode Standard.
mappings for case insensitive comparisons, and non-case-preserving
storage, although there are variations that occur additional The SpecialCasing.txt file replaces the Default Case Folding with
characters with a name including "SMALL" or "CAPITAL" are added in a locale and context-dependent case folding for specific situations.
subsequent version of Unicode. An example of locale and context-dependent case folding is that LATIN
CAPITAL LETTER I ("I", U+0049) is default case folded to LATIN SMALL
LETTER I ("i", U+0069); however, Turkish and several other languages)
treat an "I" character with a dot as a different letter than an "I"
character without a dot, therefore in such languages, unless an I is
before a dot_above, the "I" (U+0049) character should be case folded
to a different character, LATIN SMALL LETTER DOTLESS I (U+0131).
The [UNICODE] and [SPECIALCASING] references in this RFC are for
version 6.3.0 of the Unicode standard, as that was the latest version
of Unicode when this RFC was published. Implementations SHOULD
always use the latest version of Unicode
(http://www.unicode.org/versions/latest/).
6. Access Control Attributes 6. Access Control Attributes
Access Control Lists (ACLs) are file attributes that specify fine Access Control Lists (ACLs) are file attributes that specify fine
grained access control. This chapter covers the "acl", "aclsupport", grained access control. This chapter covers the "acl", "aclsupport",
"mode", file attributes, and their interactions. Note that file "mode", file attributes, and their interactions. Note that file
attributes may apply to any file system object. attributes may apply to any file system object.
6.1. Goals 6.1. Goals
skipping to change at page 170, line 10 skipping to change at page 170, line 41
o The NFSv4 client is part of an extensive set of client-side o The NFSv4 client is part of an extensive set of client-side
software components whose design and internal interfaces are not software components whose design and internal interfaces are not
within the IETF's purview, limiting the degree to which a within the IETF's purview, limiting the degree to which a
particular character encoding may be made standard. particular character encoding may be made standard.
o Server-side handling of file component names is typically o Server-side handling of file component names is typically
implemented within a server-side physical file system, whose implemented within a server-side physical file system, whose
handling of character encoding and normalization is not handling of character encoding and normalization is not
specifiable by the IETF. specifiable by the IETF.
o Typical implementation patterns in Unix systems may mean that the o Typical implementation patterns in Unix systems result in the
NFSv4 client has no knowledge of the character encoding being NFSv4 client having no knowledge of the character encoding being
used, which may even vary between processes on the same client used, which may even vary between processes on the same client
system. system.
o Users may need access to files stored previously with non-UTF-8 o Users may need access to files stored previously with non-UTF-8
encodings, or with UTF-8 encodings that do not match any encodings, or with UTF-8 encodings that do not match any
particular normalization form. particular normalization form.
12.3. Summary of Server Behavior Types 12.3. Summary of Server Behavior Types
As mentioned in Section 12.6, servers MAY reject component name As mentioned in Section 12.6, servers MAY reject component name
strings that are not valid UTF-8. This leads to a number of types of 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 valid server behavior as outlined below. When these are combined
with the valid normalization-related behaviors as described in with the valid normalization-related behaviors as described in
Section 12.4, this leads to the combined behaviors outlined below. Section 12.4, this leads to the combined behaviors outlined below.
o Servers which do limit file component names to UTF-8 strings exist o Servers which limit file component names to UTF-8 strings exist
with all of the forms of normalization-related handling described with normalization-related handling described in Section 12.4.
in Section 12.4. These are best described as "UTF-8-only These are best described as "UTF-8-only servers".
servers".
o Servers which do not limit file component names to UTF-8 strings o Servers which do not limit file component names to UTF-8 strings
are very common and are necessary to deal with clients/ are very common and are necessary to deal with clients/
applications not oriented to the use of UTF-8. Such servers applications not oriented to the use of UTF-8. Such servers
ignore normalization-related issues and there is no way for them ignore normalization-related issues and there is no way for them
to implement either normalization or representation-independent to implement either normalization or representation-independent
lookups. These are best described as "UTF-8-unaware servers" lookups. These are best described as "UTF-8-unaware servers"
since they treat file component names as uninterpreted strings of since they treat file component names as uninterpreted strings of
bytes and have no knowledge of the characters represented. Such bytes and have no knowledge of the characters represented. Such
servers ignore normalization-related issues and there is no way servers ignore normalization-related issues and there is no way
for them to implement either normalization or representation- for them to implement either normalization or representation-
independent lookups. See Section 12.7 for details. independent lookups. See Section 12.7 for details.
o It is possible for a server to allow component names which are not o It is possible for a server to allow component names which are not
valid UTF-8, while still being aware of the structure of UTF-8 valid UTF-8, while still being aware of the structure of UTF-8
strings. Such servers could implement either normalization or strings. Such servers could implement either normalization or
representation-independent lookups, but apply those techniques representation-independent lookups, but apply those techniques
only to valid UTF-8 strings. Such servers are not known to exist only to valid UTF-8 strings. Such servers are not common, but it
and SHOULD NOT be implemented because of the possibility that a is possible to configure at least one known server to have this
filename using one character set may, by accident, have the behavior. This behavior SHOULD NOT be used due to the possibility
appearance of a UTF-8 filename. See Section 12.7 for details. that a filename using one character set 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 with respect to the other character
set.
12.4. String Encoding 12.4. String Encoding
Strings that potentially contain non-ASCII Characters are generally Strings that potentially contain non-ASCII Characters are generally
represented in NFSv4 using the UTF-8 encoding of Unicode. See represented in NFSv4 using the UTF-8 encoding of Unicode. See
[RFC2279] for precise encoding and decoding rules. [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 which are component names, the preferred encoding for o For strings which are component names, the preferred encoding for
skipping to change at page 171, line 29 skipping to change at page 172, line 18
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 other forms of name encoding. Also, files stored using other forms of name encoding. Also,
normalization-related processing (see Section 12.5) of a string normalization-related processing (see Section 12.5) of a string
not encoded in UTF-8 could result in inappropriate name not encoded in UTF-8 could result in inappropriate name
modification or aliasing. In cases in which one has a non-UT8- modification or aliasing. In cases in which one has a non-UT8-
name that accidentally conforms to UTF-8 rules, substitution of name that accidentally conforms to UTF-8 rules, substitution of
canonically equivalent strings can change the non-UTF-8 encoded canonically equivalent strings can change the non-UTF-8 encoded
name drastically. name drastically.
o For strings whose form is defined by other internet standards, o For strings based on domain names, non-ASCII characters MUST be
non-ASCII characters MUST be represented using the UTF-8 encoding represented using the UTF-8 encoding of Unicode, and additional
of Unicode. In addition other sorts of restrictions defined by string format restrictions apply. See Section 12.6 for details.
those standards need to be addressed. See Section 12.6 for
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.5. Normalization 12.5. 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 [UNICODE] 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
file names. The protocol does not mandate a particular behavior but file names. The protocol does not mandate a particular behavior but
allows for a range of useful behaviors. allows for a range of useful behaviors.
The NFS version 4 protocol does not mandate the use of a particular The NFS version 4 protocol does not mandate the use of a particular
skipping to change at page 172, line 35 skipping to change at page 173, line 22
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 does not filesystem. Servers MUST NOT reject a file name because it does not
conform to a particular normalization form. conform to a particular normalization form.
12.6. Types with Processing Defined by Other Internet Areas 12.6. 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 that NFSv4 deals with that are based
processing is defined by other Internet standards, and where issues on domain names. Processing of such strings is defined by other
related to different handling choices by server operating systems or Internet standards, and hence the processing behavior for such
server file systems do not apply. strings should be consistent across all server operating systems and
server file systems.
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
server to the client. The exception is use of the fs_locations server to the client. The exception is use of the fs_locations
attribute in a VERIFY or NVERIFY operation. attribute in a VERIFY or NVERIFY operation.
o Principal suffixes which are used to denote sets of users and o Principal suffixes which are used to denote sets of users and
groups, and are in the form of domain names. groups, and are in the form of domain names.
The general rules for handling all of these domain-related strings The general rules for handling all of these domain-related strings
are similar and independent of the role of the sender or receiver as are similar and independent of the role of the sender or receiver as
client or server although the consequences of failure to obey these client or server although the consequences of failure to obey these
rules may be different for client or server. The server can report rules may be different for client or server. The server can report
errors when it is sent invalid strings, whereas the client will errors when it is sent invalid strings, whereas the client will
simply ignore invalid string or use a default value in their place. simply ignore invalid string or use a default value in their place.
The string sent SHOULD be in the form of a U-label although it MAY be The string sent SHOULD be in the form of an U-label although it MAY
in the form of an A-label or a UTF-8 string that would not map to be in the form of an A-label or a UTF-8 domain name that is not a
itself when canonicalized by applying ToUnicode(ToASCII(...)). The properly formatted U-label. The receiver needs to be able to accept
receiver needs to be able to accept domain and server names in any of domain and server names in any of the formats allowed. The server
the formats allowed. The server MUST reject, using the error MUST reject, using the error NFS4ERR_INVAL, a string which is not
NFS4ERR_INVAL, a string which is not valid UTF-8 or which begins with valid UTF-8 or which begins with "xn--" and violates the rules for a
"xn--" and violates the rules for a valid A-label. valid A-label.
When a domain string is part of id@domain or group@domain, the server When a domain string is part of id@domain or group@domain, the server
SHOULD map domain strings which are A-labels (see [RFC5890]) or are SHOULD map domain strings which are A-labels (see [RFC5890]) or are
UTF-8 domain names which are not U-labels, to the corresponding UTF-8 domain names which are not U-labels, to the corresponding
U-label, using ToUnicode(domain) or ToUnicode(ToASCII(domain)). As a U-label, using ToUnicode(domain) or ToUnicode(ToASCII(domain)). As a
result, the domain name returned within a userid on a GETATTR may not result, the domain name returned within a userid on a GETATTR may not
match that sent when the userid is set using SETATTR, although when match that sent when the userid is set using SETATTR, although when
this happens, the domain will be in the form of a U-label. When the this happens, the domain will be in the form of an U-label. When the
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.
skipping to change at page 173, line 48 skipping to change at page 174, line 36
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 them, are described in Section 12.8. to receiving them, are described in Section 12.8.
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 does not fit into 16 bits when converted from UTF-8 to a Unicode
characters only), the server should return an NFS4ERR_BADCHAR error. codepoint), 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.8. Servers that accept file component names that are not valid UTF-8 12.8. Servers that accept file component names that are not valid UTF-8
strings strings
skipping to change at page 174, line 36 skipping to change at page 175, line 23
Nonetheless, when such a server uses a broader notion of string Nonetheless, when such a server uses a broader notion of string
equivalence than recommended in the preceding paragraph the following equivalence than recommended in the preceding paragraph the following
considerations apply: considerations apply:
o Outside of 7-bit ASCII, string processing that changes string o Outside of 7-bit ASCII, string processing that changes string
contents is usually specific to a character set and hence is contents is usually specific to a character set and hence is
generally unsafe when the character set is unknown. This generally unsafe when the character set is unknown. This
processing could change the filename in an unexpected fashion, processing could change the filename in an unexpected fashion,
rendering the file inaccessible to the application or client that rendering the file inaccessible to the application or client that
created or renamed the file and to others expecting the original created or renamed the file and to others expecting the original
filename. 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 o Unicode normalization is particularly dangerous, as such
processing assumes that the string is UTF-8. When that assumption processing assumes that the string is UTF-8. When that assumption
is false because a different character set was used to create the is false because a different character set was used to create the
filename, normalization may corrupt the filename with respect to filename, normalization may corrupt the filename with respect to
that character set, rendering the file inaccessible to the that character set, rendering the file inaccessible to the
application that created it and others expecting the original application that created it and others expecting the original
filename. filename. Hence, Unicode normalization SHOULD NOT be performed,
because it may cause incorrect string modification or aliasing.
When non-UTF-8 component names are accepted in an environment in
which string processing occurs (e.g., to support a broader notion of
string equivalence than binary equality), the following
considerations apply:
o Portions of a string that are not valid UTF-8 cannot be Unicode
normalized because they do not represent Unicode characters.
o Nonetheless, it is possible to perform Unicode normalization on
valid UTF-8 substrings in a string that is not valid UTF-8 by
selectively ignoring substrings that are not valid UTF-8. This
MUST NOT be done since doing so would result in incorrect string
modification or aliasing.
13. Error Values 13. Error Values
NFS error numbers are assigned to failed operations within a Compound NFS error numbers are assigned to failed operations within a Compound
(COMPOUND or CB_COMPOUND) request. A Compound request contains a (COMPOUND or CB_COMPOUND) request. A Compound request contains a
number of NFS operations that have their results encoded in sequence number of NFS operations that have their results encoded in sequence
in a Compound reply. The results of successful operations will in a Compound reply. The results of successful operations will
consist of an NFS4_OK status followed by the encoded results of the consist of an NFS4_OK status followed by the encoded results of the
operation. If an NFS operation fails, an error status will be operation. If an NFS operation fails, an error status will be
entered in the reply and the Compound request will be terminated. entered in the reply and the Compound request will be terminated.
skipping to change at page 292, line 41 skipping to change at page 293, line 41
The registrant is always permitted to update the point of contact The registrant is always permitted to update the point of contact
field. To make any other change will require Expert Review or IESG field. To make any other change will require Expert Review or IESG
Approval. Approval.
19. References 19. References
19.1. Normative References 19.1. Normative References
[I-D.ietf-nfsv4-rfc3530bis-dot-x] [I-D.ietf-nfsv4-rfc3530bis-dot-x]
Haynes, T. and D. Noveck, "NFSv4 Version 0 XDR Haynes, T. and D. Noveck, "NFSv4 Version 0 XDR
Description", draft-ietf-nfsv4-rfc3530bis-dot-x-18 (work Description", draft-ietf-nfsv4-rfc3530bis-dot-x-21 (work
in progress), Aug 2013. in progress), Feb 2014.
[ISO.10646-1.1993]
International Organization for Standardization,
"Information Technology - Universal Multiple-octet coded
Character Set (UCS) - Part 1: Architecture and Basic
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.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998. 10646", RFC 2279, January 1998.
skipping to change at page 293, line 35 skipping to change at page 294, line 29
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010. RFC 5890, August 2010.
[RFC5891] Klensin, J., "Internationalized Domain Names in [RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891, August 2010. Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC6649] Astrand, L. and T. Yu, "Deprecate DES, RC4-HMAC-EXP, and [RFC6649] Astrand, L. and T. Yu, "Deprecate DES, RC4-HMAC-EXP, and
Other Weak Cryptographic Algorithms in Kerberos", Other Weak Cryptographic Algorithms in Kerberos",
RFC 6649, July 2012. RFC 6649, July 2012.
[Unicode1] [SPECIALCASING]
The Unicode Consortium, "The Unicode Standard, Version The Unicode Consortium, "SpecialCasing-6.3.0.txt", Unicode
3.0, ISBN 0-201-61633-5". Character Database , September 2013, <http://
www.unicode.org/Public/6.3.0/ucd/SpecialCasing.txt>.
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version
6.3.0", September 2013,
<http://www.unicode.org/versions/Unicode6.3.0/>.
[openg_symlink] [openg_symlink]
The Open Group, "Section 3.372 of Chapter 3 of Base The Open Group, "Section 3.372 of Chapter 3 of Base
Definitions of The Open Group Base Specifications Issue 6, Definitions of The Open Group Base Specifications Issue 6,
IEEE Std 1003.1, 2004 Edition, HTML Version IEEE Std 1003.1, 2004 Edition, HTML Version
(www.opengroup.org), ISBN 1931624232", 2004. (www.opengroup.org), ISBN 1931624232", 2004.
19.2. Informative References 19.2. Informative References
[Chet] Juszczak, C., "Improving the Performance and Correctness [Chet] Juszczak, C., "Improving the Performance and Correctness
skipping to change at page 294, line 20 skipping to change at page 295, line 19
[P1003.1e] [P1003.1e]
Institute of Electrical and Electronics Engineers, Inc., Institute of Electrical and Electronics Engineers, Inc.,
"IEEE Draft P1003.1e", 1997. "IEEE Draft P1003.1e", 1997.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC1094] Nowicki, B., "NFS: Network File System Protocol [RFC1094] Nowicki, B., "NFS: Network File System Protocol
specification", RFC 1094, March 1989. specification", RFC 1094, March 1989.
[RFC1345] Simonsen, K., "Character Mnemonics and Character Sets",
RFC 1345, June 1992.
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS
Version 3 Protocol Specification", RFC 1813, June 1995. Version 3 Protocol Specification", RFC 1813, June 1995.
[RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", [RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2",
RFC 1833, August 1995. RFC 1833, August 1995.
[RFC2054] Callaghan, B., "WebNFS Client Specification", RFC 2054, [RFC2054] Callaghan, B., "WebNFS Client Specification", RFC 2054,
October 1996. October 1996.
[RFC2055] Callaghan, B., "WebNFS Server Specification", RFC 2055, [RFC2055] Callaghan, B., "WebNFS Server Specification", RFC 2055,
skipping to change at page 298, line 5 skipping to change at page 299, line 5
Thomas Haynes (editor) Thomas Haynes (editor)
NetApp NetApp
495 E Java Dr 495 E Java Dr
Sunnyvale, CA 95054 Sunnyvale, CA 95054
USA USA
Phone: +1 408 419 3018 Phone: +1 408 419 3018
Email: thomas@netapp.com Email: thomas@netapp.com
David Noveck (editor) David Noveck (editor)
EMC Corporation 26 Locust Ave
228 South Street Lexington, MA 02421
Hopkinton, MA 01748
US US
Phone: +1 508 249 5748 Phone: +1 781 572 8038
Email: david.noveck@emc.com Email: davenoveck@gmail.com
 End of changes. 64 change blocks. 
259 lines changed or deleted 262 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/