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