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/ |