idnits 2.17.1 draft-ietf-nfsv4-xattrs-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 278 has weird spacing: '...lthough colle...' == Line 720 has weird spacing: '...S4resok lxr_v...' == Line 972 has weird spacing: '...dded to nfs_a...' == Line 980 has weird spacing: '...dded to nfs_r...' -- The document date (August 22, 2017) is 2432 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'LEGAL' ** Obsolete normative reference: RFC 5661 (Obsoleted by RFC 8881) -- Possible downref: Non-RFC (?) normative reference: ref. 'NFSv4-vers' Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFSv4 Working Group M. Naik 3 Internet Draft Nutanix 4 Intended Status: Standards Track M. Eshel 5 Expires: February 23, 2018 IBM Almaden 6 August 22, 2017 8 File System Extended Attributes in NFSv4 9 draft-ietf-nfsv4-xattrs-07 11 Abstract 13 This document describes an OPTIONAL feature extending the NFSv4 14 protocol which allows extended attributes (hereinafter also referred 15 to as xattrs) to be interrogated and manipulated using NFSv4 clients. 16 Xattrs are provided by a file system to associate opaque metadata, 17 not interpreted by the file system, with files and directories. Such 18 support is present in many modern local file systems. New file 19 attributes are provided to allow clients to query the server for 20 xattr support, with that support consisting of new operations to get 21 and set xattrs on file system objects. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Uses of Extended Attributes . . . . . . . . . . . . . . . . . 5 63 3. Functional Gaps Due to Lack of NFSv4 Extended Attribute 64 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. File System Support for Extended Attributes . . . . . . . . . 6 66 5. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 6. Relationship with Named Attributes . . . . . . . . . . . . . . 7 68 7. XDR Description . . . . . . . . . . . . . . . . . . . . . . . 8 69 7.1. Code Components Licensing Notice . . . . . . . . . . . . . 9 70 7.2. XDR for Xattr Extension . . . . . . . . . . . . . . . . . 10 71 8. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 11 72 8.1. New definitions . . . . . . . . . . . . . . . . . . . . . 11 73 8.2. New Attribute . . . . . . . . . . . . . . . . . . . . . . 11 74 8.2.1. xattr_support . . . . . . . . . . . . . . . . . . . . 12 75 8.3. New Error Definitions . . . . . . . . . . . . . . . . . . 12 76 8.3.1. NFS4ERR_NOXATTR (Error Code 10095) . . . . . . . . . . 12 77 8.3.2. NFS4ERR_XATTR2BIG (Error Code 10096) . . . . . . . . . 12 78 8.4. New Operations . . . . . . . . . . . . . . . . . . . . . . 12 79 8.4.1. GETXATTR - Get an extended attribute of a file . . . . 13 80 8.4.2. SETXATTR - Set an extended attribute of a file . . . . 14 81 8.4.3. LISTXATTRS - List extended attributes of a file . . . 16 82 8.4.4. REMOVEXATTR - Remove an extended attribute of a file . 18 83 8.4.5. Valid Errors . . . . . . . . . . . . . . . . . . . . . 19 84 8.5. Modifications to Existing Operations . . . . . . . . . . . 20 85 8.6. Numeric Values Assigned to Protocol Extensions . . . . . . 21 86 8.7. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 22 87 8.8. Xattrs and File Locking . . . . . . . . . . . . . . . . . 24 88 8.9. pNFS Considerations . . . . . . . . . . . . . . . . . . . 24 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 90 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 92 11.1. Normative References . . . . . . . . . . . . . . . . . . 26 93 11.2. Informative References . . . . . . . . . . . . . . . . . 27 94 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 27 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 97 1. Introduction 99 Extended attributes, also called xattrs, are a means to associate 100 opaque metadata with file system objects, organized as key/value 101 pairs. They are especially useful when they add information that is 102 not, or cannot be, present in the associated object itself. User- 103 space applications can arbitrarily create, interrogate, and modify 104 the key/value pairs. 106 Extended attributes are file system-agnostic; applications use an 107 interface not specific to any file system to manipulate them. 108 Applications are not concerned about how the key/value pairs are 109 stored internally within the underlying file system. All major 110 operating systems provide facilities to access and modify extended 111 attributes. Many user space tools allow xattrs to be included 112 together with regular attributes that need to be preserved when 113 objects are updated, moved or copied. 115 Extended attributes have not previously been included within the 116 NFSv4 specification. One issue that needs to be addressed as part of 117 including them is that, as with named attributes, some aspects of 118 their handling are not precisely defined and they are not formally 119 documented by any standard (such as POSIX). Nevertheless, it appears 120 that xattrs are widely deployed and their support in modern disk- 121 based file systems is nearly universal. 123 There is no current specification of how xattrs could be mapped to 124 any existing file attributes defined in the NFSv4 protocol 125 ([RFC7530], [RFC5661], [RFC7862]). As a result, most NFSv4 client 126 implementations ignore application-specified xattrs. This state of 127 affairs results in data loss if one copies, over the NFSv4 protocol, 128 a file with xattrs from one file system to another that also supports 129 xattrs. 131 There is thus a need to provide a means by which such data loss can 132 be avoided. This will involve exposing xattrs within the NFSv4 133 protocol, despite the lack of completely compatible file system 134 implementations. 136 This document discusses (in Section 5) the reasons that NFSv4 named 137 attributes, as currently standardized in [RFC5661], are unsuitable 138 for representing xattrs. Instead, it describes a separate protocol 139 mechanism to support xattrs. As a consequence, xattrs and named 140 attributes will both be optional features with servers free to 141 support either, both, or neither. 143 1.1. Terminology 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 In this document, these words will appear with that interpretation 149 only when in ALL CAPS. Lower case uses of these words are not to be 150 interpreted as carrying RFC-2119 significance. 152 2. Uses of Extended Attributes 154 Applications can store tracking information in extended attributes. 155 Examples include storing metadata identifying the application that 156 created the file, a tag to indicate when the file was last verified 157 by a data integrity scrubber, or a tag to hold a checksum/crypto hash 158 of the file contents along with the date of that signature. Xattrs 159 can also be used for decorations or annotations. For example, a file 160 downloaded from a web server can be tagged with the URL, which can be 161 convenient if its source has to be determined in the future. 162 Likewise, an email attachment, when saved, can be tagged with the 163 message-id of the email, making it possible to trace the original 164 message. 166 Applications may need to behave differently when handling files of 167 varying types. For example, file managers, such as GNOME's, offer 168 unique icons, different click behavior, and special lists of 169 operations to perform depending on the file format. This can be 170 achieved by looking at the file extension (Windows), or interpret the 171 type by inspecting it (Unix MIME type). Some file managers generate 172 this information on the fly; others generate the information once and 173 then cache it. Those that cache the information tend to put it in a 174 custom database. The file manager must work to keep this database in 175 sync with the files, which can change without the file manager's 176 knowledge. A better approach is to dispense with the custom database 177 and store such metadata in extended attributes. This is easier to 178 maintain, provides faster access, and is readily accessible by 179 applications [Love]. 181 3. Functional Gaps Due to Lack of NFSv4 Extended Attribute Support 183 In addition to the prospect of data loss discussed above (in Section 184 1), arising from use of xattrs on local file systems, application use 185 of xattrs poses further difficulties given the current lack of xattr 186 support within NFSv4. As a result, certain applications may not be 187 supported by NFSv4 or may be supported in an unsatisfactory way. 188 Some examples are discussed below. 190 Swift, the OpenStack distributed object store, uses xattrs to store 191 an object's metadata along with all the data together in one file. 193 Swift-on-File [Swift] transfers the responsibility of maintaining 194 object durability and availability to the underlying file system. 195 Today, this requires a native file system client to mount the 196 volumes. Xattr support in NFSv4 would open up the possibility of 197 storing and consuming data from other storage systems, and facilitate 198 the migration of data between different backend storage systems. 200 Baloo, the file indexing and search framework for KDE, has moved to 201 storing metadata such as tags, ratings and comments, in file system 202 xattrs instead of a custom database for simplicity. Starting with 203 KDE Plasma 5.1, NFS is no longer supported due to its lack of xattr 204 support [KDE]. 206 4. File System Support for Extended Attributes 208 Extended attributes are supported by most modern file systems. 210 In Linux, ext3, ext4, JFS, XFS, Btrfs, among other file systems, 211 support extended attributes. The getfattr and setfattr utilities can 212 be used to retrieve and set xattrs. The names of the extended 213 attributes must be prefixed by the name of the category and a dot; 214 hence these categories are generally qualified as name spaces. 215 Currently, four namespaces exist: user, trusted, security and system 216 [Linux]. Recommendations on how they should be used have been 217 published [freedesktop]. 219 FreeBSD supports extended attributes in two universal namespaces - 220 user and system, although individual file systems are allowed to 221 implement additional namespaces [FreeBSD]. 223 Some file systems have facilities that are capable of storing both 224 extended attributes and named attributes. For discussion regarding 225 the relationship between these feature, see section 5. Solaris 9 and 226 later provides file "forks", logically represented as files within a 227 hidden directory that is associated with the target file [fsattr]. In 228 the NTFS file system, extended attributes may be stored within "file 229 streams" [NTFS]. 231 Xattrs can be retrieved and set through system calls or shell 232 commands and are generally supported by user-space tools that 233 preserve other file attributes. For example, the "rsync" remote copy 234 program will correctly preserve user extended attributes between 235 Linux/ext4 and OSX/hfs by stripping off the Linux-specific "user." 236 prefix. 238 5. Namespaces 240 Operating systems may define multiple "namespaces" in which xattrs 241 can be set. Namespaces are more than organizational classes; the 242 operating system may enforce different access policies and allow 243 different capabilities depending on the namespace. Linux, for 244 example, defines "security", "system", "trusted" and "user" 245 namespaces, the first three being specific to Linux [freedesktop]. 247 Implementations generally agree on the semantics of a "user" 248 namespace, that allows applications to store arbitrary user attribute 249 data with file system objects. Access to this namespace is 250 controlled via the normal file system attributes. As such, getting 251 and setting xattrs from the user namespace can be considered 252 interoperable across platforms and vendor implementations. 253 Attributes from other namespaces are typically platform-specific. 255 This document provides support for namespaces related to user-managed 256 metadata only, thus avoiding the need to specify the semantics 257 applicable to particular system-interpreted xattrs. The values of 258 xattrs are considered application data just as the contents of named 259 attributes, files, and symbolic links are. Servers have a 260 responsibility to store whatever value the client specifies and to 261 return it on demand. Xattr keys and values MUST NOT be interpreted by 262 the NFS clients and servers, as such behavior would lead to non- 263 interoperable implementations. If there were to be a need to specify 264 one or more attributes that servers need to act upon, the appropriate 265 semantics would be specified by adding a new attribute for the 266 purpose as provided for by [RFC5661] and [NFSv4-vers]. 268 6. Relationship with Named Attributes 270 [RFC7530] defines named attributes as opaque byte streams that are 271 associated with a directory or file and referred to by a string name. 272 Named attributes are intended to be used by client applications as a 273 method to associate application-specific data with a regular file or 274 directory. Although this makes xattrs similar in concept and use to 275 named attributes, there are important semantic differences. 277 File systems typically define operations to get and set individual 278 xattrs as being atomic, although collectively they may be 279 independent. Xattrs generally have size limits ranging from a few 280 bytes to several kilobytes; the maximum supported size is not 281 universally defined and is usually restricted by the file system. 282 Similar to ACLs, the amount of xattr data exchanged between the 283 client and server for get/set operations can be considered to fit in 284 a single COMPOUND request, bounded by the channel's negotiated 285 maximum size for requests. Named attributes, on the other hand, are 286 unbounded data streams and do not impose atomicity requirements. 288 Individual named attributes are analogous to files, and are opened 289 and closed just as files are. Caching of the data for these needs to 290 be handled just as data caching is for ordinary files following 291 close-to-open semantics. Xattrs, on the other hand, have caching 292 requirements similar to other file attributes. 294 Named attributes and xattrs have different semantics and are treated 295 by applications as belonging to disjoint namespaces. As a result, 296 mapping from one to the other would be, at best, a compromise. 297 Despite these differences, the underlying file system structure used 298 to store named attributes is generally capable of storing xattrs. 299 However, the converse is typically not the case because of the size 300 limits applicable to xattrs. 302 While it might be possible to write guidance about how a client can 303 use the named attribute mechanism to act like xattrs, such as by 304 carving out some namespace and specifying locking primitives to 305 enforce atomicity constraints on individual get/set operations, such 306 an approach is sufficiently problematic that it will not be attempted 307 here. A client application trying to use xattrs through named 308 attributes with a server that supported xattrs directly would get a 309 lower level of service, and could fail to cooperate on a local 310 application running on the server unless the server file system 311 defined its own interoperability constraints. File systems that 312 already implement xattrs and named attributes natively would need 313 additional guidance such as reserving named attribute namespace 314 specifically for implementation purposes. 316 7. XDR Description 318 This document contains the external data representation (XDR) 319 [RFC4506] description of the extended attributes. The XDR 320 description is embedded in this document in a way that makes it 321 simple for the reader to extract into a ready-to-compile form. The 322 reader can feed this document into the following shell script to 323 produce the machine readable XDR description of extended attributes: 325 327 #! /bin/sh 328 grep '^ *///' $* | sed 's?^ */// ??' | sed 's?^ *///$??' 330 332 That is, if the above script is stored in a file called "extract.sh", 333 and this document is in a file called "spec.txt", then the reader can 334 do: 336 sh extract.sh < spec.txt > xattr_prot.x 337 The effect of the script is to remove leading white space from each 338 line, plus a sentinel sequence of "///". 340 The initial section of the embedded XDR file header follows. 341 Subsequent XDR descriptions, with the sentinel sequence are embedded 342 throughout the document. 344 Note that the XDR code contained in this document depends on types 345 from the NFSv4.2 nfs4_prot.x file [RFC7863]. This includes both nfs 346 types that end with a 4, such as nfs_cookie4, count4, etc., as well 347 as more generic types such as opaque and bool. 349 To produce a compilable XDR file, following procedure is suggested: 350 o Extract the file nfs4_prot.x as described in [RFC7863]. 352 o Extract xattr_prot.x from this document as described above. 354 o Apply any changes required for other extensions to be included 355 together with the xattr extension. 357 o Perform modifications to nfs4_prot.x as described by comments 358 within xattr_prot.x. 360 o Extend the unions nfs_argop4 and nfs_resop4 to include cases for 361 the new operations defined in this document. 363 o Combine the XDR files for the base v4.2 protocol, and all needed 364 extensions by either concatenating the relevant XDR files, or 365 using file inclusion. 367 7.1. Code Components Licensing Notice 369 Both the XDR description and the scripts used for extracting the 370 XDR description are Code Components as described in Section 4 of 371 "Legal Provisions Relating to IETF Documents" [LEGAL]. These Code 372 Components are licensed according to the terms of that document. 374 376 /// /* 377 /// * Copyright (c) 2012 IETF Trust and the persons identified 378 /// * as authors of the code. All rights reserved. 379 /// * 380 /// * Redistribution and use in source and binary forms, with 381 /// * or without modification, are permitted provided that the 382 /// * following conditions are met: 383 /// * 384 /// * o Redistributions of source code must retain the above 385 /// * copyright notice, this list of conditions and the 386 /// * following disclaimer. 387 /// * 388 /// * o Redistributions in binary form must reproduce the above 389 /// * copyright notice, this list of conditions and the 390 /// * following disclaimer in the documentation and/or other 391 /// * materials provided with the distribution. 392 /// * 393 /// * o Neither the name of Internet Society, IETF or IETF 394 /// * Trust, nor the names of specific contributors, may be 395 /// * used to endorse or promote products derived from this 396 /// * software without specific prior written permission. 397 /// * 398 /// * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS 399 /// * AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED 400 /// * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 401 /// * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS 402 /// * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO 403 /// * EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE 404 /// * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 405 /// * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT 406 /// * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 407 /// * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS 408 /// * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF 409 /// * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, 410 /// * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING 411 /// * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF 412 /// * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 413 /// * 414 /// * This code was derived from RFC 7863. 415 /// * Please reproduce this note if possible. 416 /// */ 418 420 7.2. XDR for Xattr Extension 422 424 /// /* 425 /// * xattr_prot.x 426 /// */ 428 /// /* 429 /// * The following include statements are for example only. 430 /// * The actual XDR definition files are generated separately 431 /// * and independently and are likely to have a different name. 432 /// * %#include 433 /// * %#include 434 /// */ 436 438 8. Protocol Extensions 440 This section documents extensions to the NFSv4 protocol operations 441 to allow xattrs to be queried and modified by clients. A new 442 attribute is added to allow clients to determine if the file 443 system being accessed provides support for xattrs. New operations 444 are defined to allow xattr keys and values to be queried and set. 445 In addition, the ACCESS operation is extended by adding new mask 446 bits to provide access information relating to xattrs. 448 These changes follow applicable guidelines for valid NFSv4 XDR 449 protocol extension, as specified in [NFSv4-vers], and obey the 450 rules for extensions capable of being made without a change in 451 minor version number. 453 8.1. New definitions 455 457 /// typedef component4 xattrkey4; 458 /// typedef opaque xattrvalue4<>; 460 462 Each xattr is a key/value pair. xattrkey4 is a string denoting the 463 xattr key name, and an attrvalue4 which is a variable-length string 464 that identifies the value of the xattr. The handling of xattrkey4 465 with regard to internationalization-related issues is the same as 466 that for NFSv4 file names and named attribute names, as described in 467 [RFC7530]. Any regular file or directory may have a set of extended 468 attributes, each consisting of a key and associated value. The NFS 469 client or server MUST NOT interpret the contents of xattrkey4 or 470 xattrvalue4. 472 8.2. New Attribute 474 The per-fs read-only attribute described below may be used to 475 determine if xattrs are supported. Servers need not support this 476 attribute and some NFSv4.2 servers may be unaware of its existence. 477 Before interrogating this attribute using GETATTR, a client should 478 determine whether it is a supported attribute by interrogating the 479 supported_attrs attribute. 481 8.2.1. xattr_support 483 True, if the object's file system supports extended attributes. 485 Since xattr_support is not a REQUIRED attribute, server need not 486 support it. However, a client may reasonably assume that a server 487 (or file system) that does not support the xattr_support attribute 488 does not provide xattr support and act on that basis. 490 Note that the protocol does not enforce any limits on the number of 491 keys, the length of a key or the size of a value, or the total size 492 of xattrs that are allowed for a file. The server file system MAY 493 impose additional limits. In addition, a single xattr key or value 494 exchanged between the client and server for get/set operations is 495 limited by the channel's negotiated maximum size for requests and 496 responses. 498 8.3. New Error Definitions 500 502 /// /* Following lines are to be added to enum nfsstat4 */ 503 /// /* 504 /// NFS4ERR_NOXATTR = 10095, /* xattr does not exist */ 505 /// NFS4ERR_XATTR2BIG = 10096 /* xattr value is too big */ 506 /// */ 508 510 8.3.1. NFS4ERR_NOXATTR (Error Code 10095) 512 The specified xattr does not exist or the server is unable to 513 retrieve it. 515 8.3.2. NFS4ERR_XATTR2BIG (Error Code 10096) 517 The size of the xattr value specified as part of a SETXATTR 518 operation, or the collective size of all xattrs of the file resulting 519 from the SETXATTR operation, is bigger than that supported by the 520 underlying file system. 522 8.4. New Operations 524 Applications need to perform the following operations on a given 525 file's extended attributes [Love]: 527 o Given a file, return a list of all of the file's assigned extended 528 attribute keys. 530 o Given a file and a key, return the corresponding value. 532 o Given a file, a key, and a value, assign that value to the key. 534 o Given a file and a key, remove that extended attribute from the 535 file. 537 In order to meet these requirements, this section introduces four new 538 OPTIONAL operations, GETXATTR, SETXATTR, LISTXATTRS and REMOVEXATTR, 539 to query, set, list and remove xattrs respectively. A server MUST 540 support all four operations when they are directed to a file system 541 which supports the xattr_support attribute and returns TRUE when it 542 is interrogated. For file systems which either do not support the 543 xattr_support attribute or which returns FALSE when it is 544 interrogated, all of these operations MUST NOT be supported. GETXATTR 545 allows obtaining the value of an xattr key, SETXATTR allows creating 546 or replacing an xattr key with a value, LISTXATTRS enumerates all the 547 xattrs names, and REMOVEXATTR allows deleting a single xattr. 549 Note that some server implementations may not be aware of the 550 existence of these operations, thereby a client cannot always expect 551 that issuing one of them will either succeed or return 552 NFS4ERR_NOTSUPP. In some cases NFS4ERR_OP_ILLEGAL may be returned or 553 the request may encounter an XDR decode error on the server. As a 554 result, clients should only issue these operations after determining 555 that support is present. 557 8.4.1. GETXATTR - Get an extended attribute of a file 559 8.4.1.1. ARGUMENTS 561 563 /// struct GETXATTR4args { 564 /// /* CURRENT_FH: file */ 565 /// xattrkey4 gxa_name; 566 /// }; 568 570 8.4.1.2. RESULTS 571 573 /// union GETXATTR4res switch (nfsstat4 gxr_status) { 574 /// case NFS4_OK: 575 /// xattrvalue4 gxr_value; 576 /// default: 577 /// void; 578 /// }; 580 582 8.4.1.3. DESCRIPTION 584 The GETXATTR operation will obtain the value for the given extended 585 attribute key for the file system object specified by the current 586 filehandle. 588 The server will fetch the xattr value for the key that the client 589 requests if xattrs are supported by the server for the target file 590 system. If the server does not support xattrs on the target file 591 system, then it MUST NOT return a value and MUST return the 592 NFS4ERR_NOTSUPP error or another error indicating the request was not 593 understood. The server also MUST return NFS4ERR_NOXATTR if it 594 supports xattrs on the target but cannot obtain the requested data. 595 If the xattr value contained in the server response is such as to 596 cause the channel's negotiated maximum response size to be exceeded, 597 then the server MUST return NFS4ERR_REP_TOO_BIG in gxr_status. 599 8.4.1.4. IMPLEMENTATION 601 Clients that have cached an xattr may avoid the need to do a GETXATTR 602 by determining if the change attribute is the same as it was when the 603 xattr was fetched. If the client does not hold a delegation for the 604 file in question, it can do so with a GETATTR request to obtain the 605 change attribute and comparing its value to the change attribute 606 value fetched when the xattr value was obtained. This handling is 607 similar to how a client would revalidate other file attributes such 608 as ACLs. 610 When responding to such a GETATTR, the server will, if there is an 611 OPEN_DELEGATE_WRITE delegation held by another client for the file in 612 question, either obtain the actual current value of these attributes 613 from the client holding the delegation by using the CB_GETATTR 614 callback, or revoke the delegation. See Section 18.7.4 of [RFC5661] 615 for details. 617 8.4.2. SETXATTR - Set an extended attribute of a file 618 8.4.2.1. ARGUMENTS 620 622 /// enum setxattr_option4 { 623 /// SETXATTR4_EITHER = 0, 624 /// SETXATTR4_CREATE = 1, 625 /// SETXATTR4_REPLACE = 2 626 /// }; 628 /// struct SETXATTR4args { 629 /// /* CURRENT_FH: file */ 630 /// setxattr_option4 sxa_option; 631 /// xattrkey4 sxa_key; 632 /// xattrvalue4 sxa_value; 633 /// }; 635 637 8.4.2.2. RESULTS 639 641 /// union SETXATTR4res switch (nfsstat4 sxr_status) { 642 /// case NFS4_OK: 643 /// change_info4 sxr_info; 644 /// default: 645 /// void; 646 /// }; 648 650 8.4.2.3. DESCRIPTION 652 The SETXATTR operation changes one extended attribute of a file 653 system object. The change desired is specified by sxa_option. 654 SETXATTR4_CREATE is used to associate the given value with the given 655 extended attribute key for the file system object specified by the 656 current filehandle. The server MUST return NFS4ERR_EXIST if the 657 attribute key already exists. SETXATTR4_REPLACE is also used to set 658 an xattr, but the server MUST return NFS4ERR_NOXATTR if the attribute 659 key does not exist. By default (SETXATTR4_EITHER), the extended 660 attribute will be created if need be, or its value will be replaced 661 if the attribute exists. 663 If the xattr key and value contained in the client request are such 664 that the request would exceed the channel's negotiated maximum 665 request size, then the server MUST return NFS4ERR_REQ_TOO_BIG in 666 sxr_status. If the server file system imposes additional limits on 667 the size of key name or value, it MAY return NFS4ERR_XATTR2BIG. 669 A successful SETXATTR MUST change the file time_metadata and change 670 attributes if the xattr is created or the value assigned to xattr 671 changes. However, it is not NECESSARY to change these attributes if 672 there has been no actual change in the xattr value. Avoiding 673 attribute change in such situation is desirable as it avoids 674 unnecessary cache invalidation. 676 On success, the server returns the change_info4 information in 677 sxr_info. With the atomic field of the change_info4 data type, the 678 server will indicate if the before and after change attributes were 679 obtained atomically with respect to the SETXATTR operation. This 680 allows the client to determine if its cached xattrs are still valid 681 after the operation. See Section 8.7 for a discussion on xattr 682 caching. 684 8.4.2.4. IMPLEMENTATION 686 If the object whose xattr is being changed has a file delegation that 687 is held by a client other than the one doing the SETXATTR, the 688 delegation(s) must be recalled, and the operation cannot proceed to 689 actually change the xattr until each such delegation is returned or 690 revoked. In all cases in which delegations are recalled, the server 691 is likely to return one or more NFS4ERR_DELAY errors while the 692 delegation(s) remains outstanding, although it might not do that if 693 the delegations are returned quickly. 695 8.4.3. LISTXATTRS - List extended attributes of a file 697 8.4.3.1. ARGUMENTS 699 701 /// struct LISTXATTRS4args { 702 /// /* CURRENT_FH: file */ 703 /// nfs_cookie4 lxa_cookie; 704 /// count4 lxa_maxcount; 705 /// }; 707 709 8.4.3.2. RESULTS 710 712 /// struct LISTXATTRS4resok { 713 /// nfs_cookie4 lxr_cookie; 714 /// xattrkey4 lxr_names<>; 715 /// bool lxr_eof; 716 /// }; 718 /// union LISTXATTRS4res switch (nfsstat4 lxr_status) { 719 /// case NFS4_OK: 720 /// LISTXATTRS4resok lxr_value; 721 /// default: 722 /// void; 723 /// }; 725 727 8.4.3.3. DESCRIPTION 729 The LISTXATTRS operation retrieves a variable number of extended 730 attribute keys from the file system object specified by the current 731 filehandle, along with information to allow the client to request 732 additional attribute keys in a subsequent LISTXATTRS. 734 The arguments contain a cookie value that represents where the 735 LISTXATTRS should start within the list of xattrs. A value of 0 736 (zero) for lxa_cookie is used to start reading at the beginning of 737 the list. For subsequent LISTXATTRS requests, the client specifies a 738 cookie value that is provided by the server on a previous LISTXATTRS 739 request. 741 The lxa_maxcount value of the argument is the maximum number of bytes 742 for the result. This maximum size represents all of the data being 743 returned within the LISTXATTRS4resok structure and includes the XDR 744 overhead. The server may return less data. If the server is unable 745 to return a single xattr name within the maxcount limit, the error 746 NFS4ERR_TOOSMALL will be returned to the client. 748 On successful return, the server's response will provide a list of 749 extended attribute keys. The "lxr_eof" flag has a value of TRUE if 750 there are no more keys for the object. 752 The cookie value is only meaningful to the server and is used as a 753 "bookmark" for the xattr key. As mentioned, this cookie is used by 754 the client for subsequent LISTXATTRS operations so that it may 755 continue listing keys. The cookie is similar in concept to a READDIR 756 cookie or the READ offset but should not be interpreted as such by 757 the client. 759 On success, the current filehandle retains its value. 761 8.4.3.4. IMPLEMENTATION 763 The handling of cookie is similar to that of the READDIR operation. 764 It should be a rare occurrence that a server is unable to continue 765 properly listing xattrs with the provided cookie. The server should 766 make every effort to avoid this condition since the application at 767 the client may not be able to properly handle this type of failure. 769 8.4.4. REMOVEXATTR - Remove an extended attribute of a file 771 8.4.4.1. ARGUMENTS 773 775 /// struct REMOVEXATTR4args { 776 /// /* CURRENT_FH: file */ 777 /// xattrkey4 rxa_name; 778 /// }; 780 782 8.4.4.2. RESULTS 784 786 /// union REMOVEXATTR4res switch (nfsstat4 rxr_status) { 787 /// case NFS4_OK: 788 /// change_info4 rxr_info; 789 /// default: 790 /// void; 791 /// }; 793 795 8.4.4.3. DESCRIPTION 797 The REMOVEXATTR operation deletes one extended attribute of a file 798 system object specified by rxa_name. The server MUST return 799 NFS4ERR_NOXATTR if the attribute key does not exist. 801 A successful REMOVEXATTR MUST change the file time_metadata and 802 change attributes. 804 Similar to SETXATTR, the server communicates the value of the change 805 attribute immediately prior to, and immediately following, a 806 successful REMOVEXATTR operation in rxr_info. This allows the client 807 to determine if its cached xattrs are still valid after the 808 operation. See Section 8.7 for a discussion on xattr caching. 810 8.4.4.4. IMPLEMENTATION 812 If the object whose xattr is being removed has a file delegation that 813 is held by a client other than the one doing the REMOVEXATTR, the 814 delegation(s) must be recalled, and the operation cannot proceed to 815 delete the xattr until each such delegation is returned or revoked. 816 In all cases in which delegations are recalled, the server is likely 817 to return one or more NFS4ERR_DELAY errors while the delegation(s) 818 remains outstanding, although it might not do that if the delegations 819 are returned quickly. 821 8.4.5. Valid Errors 823 This section contains a table that gives the valid error returns for 824 each new protocol operation. The error code NFS4_OK (indicating no 825 error) is not listed but should be understood to be returnable by all 826 new operations. The error values for all other operations are 827 defined in Section 13.2 of [RFC7530] and Section 11.2 of [RFC7862]. 829 Valid Error Returns for Each New Protocol Operation 831 +----------------------+--------------------------------------------+ 832 | Operation | Errors | 833 +----------------------+--------------------------------------------+ 834 | GETXATTR | NFS4ERR_ACCESS, NFS4ERR_BADXDR, | 835 | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | 836 | | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, | 837 | | NFS4ERR_IO, NFS4ERR_MOVED, | 838 | | NFS4ERR_NAMETOOLONG, NFS4ERR_NOFILEHANDLE, | 839 | | NFS4ERR_NOTSUPP, NFS4ERR_NOXATTR, | 840 | | NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_PERM, | 841 | | NFS4ERR_REP_TOO_BIG, | 842 | | NFS4ERR_REP_TOO_BIG_TO_CACHE, | 843 | | NFS4ERR_REQ_TOO_BIG, | 844 | | NFS4ERR_RETRY_UNCACHED_REP, | 845 | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | 846 | | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE | 847 | SETXATTR | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, | 848 | | NFS4ERR_BADXDR, NFS4ERR_DEADSESSION, | 849 | | NFS4ERR_DELAY, NFS4ERR_DQUOT, | 850 | | NFS4ERR_EXIST, NFS4ERR_FHEXPIRED, | 851 | | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, | 852 | | NFS4ERR_NAMETOOLONG, NFS4ERR_NOFILEHANDLE, | 853 | | NFS4ERR_NOSPC, NFS4ERR_NOXATTR, | 854 | | NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_PERM, | 855 | | NFS4ERR_REP_TOO_BIG, | 856 | | NFS4ERR_REP_TOO_BIG_TO_CACHE, | 857 | | NFS4ERR_REQ_TOO_BIG, | 858 | | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_ROFS, | 859 | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | 860 | | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE, | 861 | | NFS4ERR_XATTR2BIG | 862 | LISTXATTRS | NFS4ERR_ACCESS, NFS4ERR_DEADSESSION, | 863 | | NFS4ERR_DELAY, NFS4ERR_INVAL, NFS4ERR_IO, | 864 | | NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, | 865 | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTSUPP, | 866 | | NFS4ERR_NOXATTR, NFS4ERR_OP_NOT_IN_SESSION,| 867 | | NFS4ERR_PERM, NFS4ERR_REP_TOO_BIG, | 868 | | NFS4ERR_REP_TOO_BIG_TO_CACHE, | 869 | | NFS4ERR_REQ_TOO_BIG, | 870 | | NFS4ERR_RETRY_UNCACHED_REP, | 871 | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | 872 | | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE | 873 | REMOVEXATTR | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, | 874 | | NFS4ERR_BADXDR, NFS4ERR_DEADSESSION, | 875 | | NFS4ERR_DELAY, NFS4ERR_DQUOT, | 876 | | NFS4ERR_EXIST, NFS4ERR_INVAL, NFS4ERR_IO, | 877 | | NFS4ERR_LOCKED, NFS4ERR_MOVED, | 878 | | NFS4ERR_NAMETOOLONG, NFS4ERR_NOFILEHANDLE, | 879 | | NFS4ERR_NOSPC, NFS4ERR_NOXATTR, | 880 | | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE, | 881 | | NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_PERM, | 882 | | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_ROFS, | 883 | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | 884 | | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE | 885 +----------------------+--------------------------------------------+ 887 8.5. Modifications to Existing Operations 889 In order to provide fine-grained access control to query or modify 890 extended attributes, new access rights are defined that can be 891 checked to determine if the client is permitted to perform the xattr 892 operation. 894 Note that in general, as explained in Section 18.1.4 of [RFC5661], a 895 client cannot reliably perform an access check with only current file 896 attributes and must verify access with the server. 898 This section extends the semantics of the ACCESS operation documented 899 in Section 18.1 of [RFC5661]. Three new access permissions can be 900 requested: 902 ACCESS4_XAREAD Query a file or directory for its xattr value 903 given a key. 905 ACCESS4_XAWRITE Modify xattr keys and/or values of a file or 906 directory. 908 ACCESS4_XALIST Query a file or directory to list its xattr keys. 910 As with the existing access permissions, the results of ACCESS are 911 advisory in nature, with no implication that such access will be 912 allowed or denied in the future. 914 The rules for the client and server follow: 916 o If the client is sending ACCESS in order to determine if the user 917 can read an xattr of the file with GETXATTR, the client should set 918 ACCESS4_XAREAD in the request's access field. 920 o If the client is sending ACCESS in order to determine if the user 921 can modify an xattr of the file with SETXATTR or REMOVEXATTR, the 922 client should set ACCESS4_XAWRITE in the request's access field. 924 o If the client is sending ACCESS in order to determine if the user 925 can list the xattr keys of the file with LISTXATTRS, the client 926 should set ACCESS4_XALIST in the request's access field. 928 8.6. Numeric Values Assigned to Protocol Extensions 930 This section lists the numeric values assigned new attributes and 931 operations to implement the xattr feature. To avoid inconsistent 932 assignments, these have been checked against the most recent 933 protocol version [RFC5661], the current minor version [RFC7862], 934 and all extensions currently approved as working group documents. 935 Development of interoperable prototypes should be possible using 936 these values, although it is possible that these values may be 937 modified before eventual publication as a standard-track document. 939 941 /// /* 942 /// * ACCESS - Check Access Rights 943 /// */ 944 /// const ACCESS4_XAREAD = 0x00000040; 945 /// const ACCESS4_XAWRITE = 0x00000080; 946 /// const ACCESS4_XALIST = 0x00000100; 948 /// /* 949 /// * New NFSv4 attribute 950 /// */ 951 /// typedef bool fattr4_xattr_support; 953 /// /* 954 /// * New RECOMMENDED Attribute 955 /// */ 956 /// const FATTR4_XATTR_SUPPORT = 82; 958 /// /* 959 /// * New NFSv4 operations 960 /// */ 961 /// /* Following lines are to be added to enum nfs_opnum4 */ 962 /// /* 963 /// OP_GETXATTR = 72, 964 /// OP_SETXATTR = 73, 965 /// OP_LISTXATTRS = 74, 966 /// OP_REMOVEXATTR = 75, 967 /// */ 969 /// /* 970 /// * New cases for Operation arrays 971 /// */ 972 /// /* Following lines are to be added to nfs_argop4 */ 973 /// /* 974 /// case OP_GETXATTR: GETXATTR4args opgetxattr; 975 /// case OP_SETXATTR: SETXATTR4args opsetxattr; 976 /// case OP_LISTXATTRS: LISTXATTRS4args oplistxattrs; 977 /// case OP_REMOVEXATTR: REMOVEXATTR4args opremovexattr; 978 /// */ 980 /// /* Following lines are to be added to nfs_resop4 */ 981 /// /* 982 /// case OP_GETXATTR: GETXATTR4res opgetxattr; 983 /// case OP_SETXATTR: SETXATTR4res opsetxattr; 984 /// case OP_LISTXATTRS: LISTXATTRS4res oplistxattrs; 985 /// case OP_REMOVEXATTR: REMOVEXATTR4res opremovexattr; 986 /// */ 988 990 8.7. Caching 992 The caching behavior for extended attributes is similar to other 993 file attributes such as ACLs and is affected by whether OPEN 994 delegation has been granted to a client or not. 996 Xattrs obtained from, or sent to, the server may be cached and 997 clients can use them to avoid subsequent GETXATTR requests, 998 provided that the client can ensure that the cached value has not 999 been subsequently modified by another client. Such assurance can 1000 be based on the client holding a delegation for the file in 1001 question or the client interrogating the change attribute to make 1002 sure that any cached value is still valid. Such caching may be 1003 read-only or write-through. 1005 When a delegation is in effect, some operations by a second client 1006 to a delegated file will cause the server to recall the delegation 1007 through a callback. For individual operations, we describe, under 1008 IMPLEMENTATION, when such operations are required to effect a 1009 recall. 1011 The result of local caching is that the individual xattrs 1012 maintained on clients may not be up-to-date. Changes made in one 1013 order on the server may be seen in a different order on one client 1014 and in a third order on another client. In order to limit 1015 problems that may arise due to separate operations to obtain 1016 individual xattrs and other file attributes, a client should treat 1017 xattrs just like other file attributes with respect to caching as 1018 detailed in section 10.6 of [RFC7530]. A client may validate its 1019 cached version of an xattr for a file by fetching the change 1020 attribute and assuming that if the change attribute has the same 1021 value as it did when the attributes were cached, then xattrs have 1022 not changed. If the client holds a delegation that ensures that 1023 the change attribute cannot be modified by another client, that it 1024 can dispense with actual interrogation of the change attribute. 1026 When a client is changing xattrs of a file, it needs to determine 1027 whether there have been changes made to the file by other clients. 1028 It does this by using the change attribute as reported before and 1029 after the change operation (SETXATTR or REMOVEXATTR) in the 1030 associated change_info4 value returned for the operation. The 1031 server is able to communicate to the client whether the 1032 change_info4 data is provided atomically with respect to the 1033 change operation. If the change values are provided atomically, 1034 the client has a basis for determining, given proper care, whether 1035 other clients are modifying the file in question. 1037 An effective way to enable the client to make this determination 1038 simply is for it to serialize all xattr changes made to a specific 1039 file. When this is done, and the server provides before and after 1040 values of the change attribute atomically, the client can simply 1041 compare the after value of the change attribute from one operation 1042 with the before value on the subsequent change operation modifying 1043 the file. When these are equal, the client is assured that no 1044 other client is modifying the file in question. 1046 If the comparison indicates that the file was updated by another 1047 client, the xattr cache associated with the modified file is 1048 purged from the client. If the comparison indicates no 1049 modification, the xattr cache can be updated on the client to 1050 reflect the file operation and the associated timeout can be 1051 extended. The post-operation change value needs to be saved as 1052 the basis for future change_info4 comparisons. 1054 Xattr caching requires that the client revalidate xattr cache data 1055 by inspecting the change attribute of a file at the point when an 1056 xattr was cached. This requires that the server update the change 1057 attribute when xattrs are modified. For a client to use the 1058 change_info4 information appropriately and correctly, the server 1059 must report the pre- and post-operation change attribute values 1060 atomically. When the server is unable to report the before and 1061 after values atomically with respect to the xattr update 1062 operation, the server must indicate that fact in the change_info4 1063 return value. When the information is not atomically reported, 1064 the client should not assume that other clients have not changed 1065 the xattrs. 1067 The protocol does not provide support for write-back caching of 1068 xattrs. As such, all modifications to xattrs should be done by 1069 requests to the server. The server should perform such updates 1070 synchronously. 1072 8.8. Xattrs and File Locking 1074 Xattr operations, for the most part, function independent of 1075 operations related to file locking state. For example, xattrs can 1076 be interrogated and modified without a corresponding OPEN 1077 operation. The server does not need to check for locks that 1078 conflict with xattr access or modify operations. For example, 1079 another OPEN specified with OPEN4_SHARE_DENY_READ or 1080 OPEN4_SHARE_DENY_BOTH does not prevent access to or modification 1081 of xattrs. Note that the server MUST still verify that the client 1082 is allowed to perform the xattr operation on the basis of access 1083 permissions. 1085 However, the presence of delegations may dictate how xattr 1086 operations interact with the state-related logic. Xattrs cannot 1087 be modified when a delegation for the corresponding file is held 1088 by another client. On the other hand, xattrs can be interrogated 1089 despite the holding of a write delegation by another client since 1090 updates are write-through to the server. 1092 8.9. pNFS Considerations 1094 All xattr operations are sent to the metadata server, which is 1095 responsible for fetching data from and effecting necessary changes 1096 to persistent storage. 1098 9. Security Considerations 1100 Since xattrs are application data, security issues are exactly the 1101 same as those relating to the storing of file data and named 1102 attributes. Clients MUST NOT accord any system-interpreted 1103 semantics to xattrs, since their use is restricted to user-managed 1104 metadata only as explained in Section 5. Extended attributes are 1105 various sorts of application data and the fact that the means of 1106 reference is slightly different in each case should not be 1107 considered security-relevant. As such, the additions to the NFS 1108 protocol for supporting extended attributes do not alter the 1109 security considerations of the NFSv4 protocol [RFC7530]. 1111 10. IANA Considerations 1113 The addition of xattr support to the NFSv4 protocol does not 1114 require any actions by IANA. This document limits xattr names to 1115 the user namespace, where application developers are allowed to 1116 define and use attributes as needed. Unlike named attributes, 1117 there is no namespace identifier associated with xattrs that may 1118 require registration. 1120 11. References 1122 11.1. Normative References 1124 [LEGAL] IETF Trust, "Legal Provisions Relating to IETF Documents", 1125 November 2008, . 1128 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1129 Requirement Levels", BCP 14, RFC 2119, DOI 1130 10.17487/RFC2119, March 1997, . 1133 [RFC4506] Eisler, M., Ed., "XDR: External Data Representation 1134 Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May 1135 2006, . 1137 [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 1138 "Network File System (NFS) Version 4 Minor Version 1 1139 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, 1140 . 1142 [RFC7530] Haynes, T., Ed., and D. Noveck, Ed., "Network File System 1143 (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, 1144 March 2015, . 1146 [RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor 1147 Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, 1148 November 2016, . 1150 [RFC7863] Haynes, T., "Network File System (NFS) Version 4 Minor 1151 Version 2 External Data Representation Standard (XDR) 1152 Description", RFC 7863, DOI 10.17487/RFC7863, November 1153 2016, . 1155 [RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor 1156 Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, 1157 November 2016, . 1159 [RFC7863] Haynes, T., "Network File System (NFS) Version 4 Minor 1160 Version 2 External Data Representation Standard (XDR) 1161 Description", RFC 7863, DOI 10.17487/RFC7863, November 1162 2016, . 1164 [NFSv4-vers] 1165 D. Noveck, "Rules for NFSv4 Extensions and Minor 1166 Versions", December 2016, . 1169 Work in progress. 1171 11.2. Informative References 1173 [freedesktop] 1174 "Guidelines for extended attributes", 1175 . 1177 [Linux] "Linux Programmer's Manual: xattr(7)", 1178 . 1180 [Love] Love, R., "Linux System Programming: Talking Directly to 1181 the Kernel and C Library", O'Reilly Media, Inc., 2007. 1183 [FreeBSD] "FreeBSD Man Pages - extattr", 1184 . 1186 [fsattr] "Oracle Man Pages - fsattr", 1187 . 1189 [NTFS] "File Streams", . 1192 [Swift] "Swift-on-File", 1193 . 1195 [KDE] Handa, V., "KDE Planet", 1196 . 1199 Appendix A. Acknowledgements 1201 This draft has attempted to capture the discussion on adding xattrs 1202 to the NFSv4 protocol from many participants on the IETF NFSv4 1203 mailing list. Those who provided valuable input and comments on 1204 earlier revisions of this draft include: Tom Haynes, Christoph 1205 Hellwig, Nico Williams, Dave Noveck, Benny Halevy and Andreas 1206 Gruenbacher. 1208 Authors' Addresses 1210 Manoj Naik 1211 Nutanix 1212 1740 Technology Drive, Suite 150, 1213 San Jose, CA 95110 1214 Email: manoj.naik@nutanix.com 1216 Marc Eshel 1217 IBM Almaden 1218 650 Harry Rd 1219 San Jose, CA 95120 1220 Phone: +1 408-927-1894 1221 Email: eshel@us.ibm.com