idnits 2.17.1 draft-ietf-webdav-ordering-protocol-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 20, 2003) is 7616 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) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2518 (Obsoleted by RFC 4918) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 WEBDAV Working Group J. Whitehead 3 Internet-Draft U.C. Santa Cruz 4 Expires: December 19, 2003 J. Reschke, Ed. 5 greenbytes 6 June 20, 2003 8 WebDAV Ordered Collections Protocol 9 draft-ietf-webdav-ordering-protocol-09 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on December 19, 2003. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This specification extends the WebDAV Distributed Authoring Protocol 40 to support server-side ordering of collection members. Of particular 41 interest are orderings that are not based on property values, and so 42 cannot be achieved using a search protocol's ordering option and 43 cannot be maintained automatically by the server. Protocol elements 44 are defined to let clients specify the position in the ordering of 45 each collection member, as well as the semantics governing the 46 ordering. 48 Distribution of this document is unlimited. Please send comments to 49 the Distributed Authoring and Versioning (WebDAV) working group at 50 w3c-dist-auth@w3.org [1], which may be joined by sending a message 51 with subject "subscribe" to w3c-dist-auth-request@w3.org [2]. 53 Discussions of the WEBDAV working group are archived at URL: http:// 54 lists.w3.org/Archives/Public/w3c-dist-auth/. 56 Table of Contents 58 1. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. Overview of Ordered Collections . . . . . . . . . . . . . . 7 62 4.1 Additional Collection properties . . . . . . . . . . . . . . 7 63 4.1.1 DAV:ordering-type (protected) . . . . . . . . . . . . . . . 7 64 5. Creating an Ordered Collection . . . . . . . . . . . . . . . 9 65 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 5.2 Example: Creating an Ordered Collection . . . . . . . . . . 10 67 6. Setting the Position of a Collection Member . . . . . . . . 11 68 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 6.2 Examples: Setting the Position of a Collection Member . . . 12 70 6.3 Examples: Renaming a member of an ordered collection . . . . 13 71 7. Changing a Collection Ordering: ORDERPATCH method . . . . . 14 72 7.1 Example: Changing a Collection Ordering . . . . . . . . . . 16 73 7.2 Example: Failure of an ORDERPATCH Request . . . . . . . . . 17 74 8. Listing the Members of an Ordered Collection . . . . . . . . 19 75 8.1 Example: PROPFIND on an Ordered Collection . . . . . . . . . 19 76 9. Relationship to versioned collections . . . . . . . . . . . 23 77 9.1 Collection Version Properties . . . . . . . . . . . . . . . 23 78 9.1.1 Additional semantics for 79 DAV:version-controlled-binding-set (protected) . . . . . . . 23 80 9.1.2 DAV:ordering-type (protected) . . . . . . . . . . . . . . . 23 81 9.2 Additional CHECKIN semantics . . . . . . . . . . . . . . . . 23 82 9.3 Additional CHECKOUT Semantics . . . . . . . . . . . . . . . 24 83 9.4 Additional UNCHECKOUT, UPDATE, and MERGE Semantics . . . . . 24 84 10. Capability Discovery . . . . . . . . . . . . . . . . . . . . 25 85 10.1 Example: Using OPTIONS for the Discovery of Support for 86 Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . 25 87 10.2 Example: Using Live Properties for the Discovery of 88 Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . 26 89 11. Security Considerations . . . . . . . . . . . . . . . . . . 28 90 11.1 Denial of Service and DAV:ordering-type . . . . . . . . . . 28 91 12. Internationalization Considerations . . . . . . . . . . . . 29 92 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 30 93 14. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . 31 94 15. Intellectual Property . . . . . . . . . . . . . . . . . . . 32 95 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33 96 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 97 Normative References . . . . . . . . . . . . . . . . . . . . 35 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 35 99 A. Extensions to the WebDAV Document Type Definition . . . . . 37 100 B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 38 101 B.1 Since draft-ietf-webdav-ordering-protocol dated December 102 1999 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 103 B.2 Since draft-ietf-webdav-ordering-protocol-02 . . . . . . . . 38 104 B.3 Since draft-ietf-webdav-ordering-protocol-03 . . . . . . . . 38 105 B.4 Since draft-ietf-webdav-ordering-protocol-04 . . . . . . . . 38 106 B.5 Since draft-ietf-webdav-ordering-protocol-05 . . . . . . . . 39 107 B.6 Since draft-ietf-webdav-ordering-protocol-06 . . . . . . . . 39 108 B.7 Since draft-ietf-webdav-ordering-protocol-07 . . . . . . . . 39 109 B.8 Since draft-ietf-webdav-ordering-protocol-08 . . . . . . . . 39 110 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 111 Intellectual Property and Copyright Statements . . . . . . . 42 113 1. Notational Conventions 115 Since this document describes a set of extensions to the WebDAV 116 Distributed Authoring Protocol [RFC2518], itself an extension to the 117 HTTP/1.1 protocol, the augmented BNF used here to describe protocol 118 elements is exactly the same as described in Section 2.1 of HTTP 119 [RFC2616]. Since this augmented BNF uses the basic production rules 120 provided in Section 2.2 of HTTP, these rules apply to this document 121 as well. 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 This document uses XML DTD fragments as a purely notational 128 convention. WebDAV request and response bodies can not be validated 129 due to the specific extensibility rules defined in section 23 of 130 [RFC2518] and due to the fact that all XML elements defined by this 131 specification use the XML namespace name "DAV:". In particular: 133 1. element names use the "DAV:" namespace, 135 2. element ordering is irrelevant, 137 3. extension elements (elements not already defined as valid child 138 elements) may be added anywhere, except when explicitly stated 139 otherwise, 141 4. extension attributes (attributes not already defined as valid for 142 this element) may be added anywhere, except when explicitly 143 stated otherwise. 145 2. Introduction 147 This specification builds on the collection infrastructure provided 148 by the WebDAV Distributed Authoring Protocol, adding support for the 149 server-side ordering of collection members. 151 There are many scenarios where it is useful to impose an ordering on 152 a collection at the server, such as expressing a recommended access 153 order, or a revision history order. The members of a collection 154 might represent the pages of a book, which need to be presented in 155 order if they are to make sense. Or an instructor might create a 156 collection of course readings, which she wants to be displayed in the 157 order they are to be read. 159 Orderings may be based on property values, but this is not always the 160 case. The resources in the collection may not have properties that 161 can be used to support the desired ordering. Orderings based on 162 properties can be obtained using a search protocol's ordering option, 163 but orderings not based on properties cannot. These orderings 164 generally need to be maintained by a human user. 166 The ordering protocol defined here focuses on support for such 167 human-maintained orderings. Its protocol elements allow clients to 168 specify the position of each collection member in the collection's 169 ordering, as well as the semantics governing the ordering. The 170 protocol is designed to allow support to be added in the future for 171 orderings that are maintained automatically by the server. 173 The remainder of this document is structured as follows: Section 3 174 defines terminology that will be used throughout the specification. 175 Section 4 provides an overview of ordered collections. Section 5 176 describes how to create an ordered collection, and Section 6 177 discusses how to set a member's position in the ordering of a 178 collection. Section 7 explains how to change a collection ordering. 179 Section 8 discusses listing the members of an ordered collection. 180 Section 9 discusses the impact on version-controlled collections (as 181 defined in [RFC3253]. Section 10 describes capability discovery. 182 Section 11 through Section 13 discuss security, internationalization, 183 and IANA considerations. The remaining sections provide supporting 184 information. 186 3. Terminology 188 The terminology used here follows that in [RFC2518] and [RFC3253]. 189 Definitions of the terms resource, Uniform Resource Identifier (URI), 190 and Uniform Resource Locator (URL) are provided in [RFC2396]. 192 Ordered Collection 194 A collection for which the results from a PROPFIND request are 195 guaranteed to be in the order specified for that collection 197 Unordered Collection 199 A collection for which the client cannot depend on the 200 repeatability of the ordering of results from a PROPFIND request 202 Client-Maintained Ordering 204 An ordering of collection members that is maintained on the server 205 based on client requests specifying the position of each 206 collection member in the ordering 208 Server-Maintained Ordering 210 An ordering of collection members that is maintained automatically 211 by the server, based on a client's choice of ordering semantics 213 This document uses the terms "precondition", "postcondition" and 214 "protected property" as defined in [RFC3253]. Servers MUST report 215 pre-/postcondition failures as described in section 1.6 of this 216 document. 218 4. Overview of Ordered Collections 220 If a collection is unordered, the client cannot depend on the 221 repeatability of the ordering of results from a PROPFIND request. By 222 specifying an ordering for a collection, a client requires the server 223 to follow that ordering whenever it responds to a PROPFIND request on 224 that collection. 226 Server-side orderings may be client-maintained or server-maintained. 227 For client-maintained orderings, a client must specify the ordering 228 position of each of the collection's members, either when the member 229 is added to the collection (using the Position header (Section 6)) or 230 later (using the ORDERPATCH (Section 7) method). For 231 server-maintained orderings, the server automatically positions each 232 of the collection's members according to the ordering semantics. 233 This specification supports only client-maintained orderings, but is 234 designed to allow future extension to server-maintained orderings. 236 A collection that supports ordering is not required to be ordered. 238 If a collection is ordered, each of its internal member URIs MUST be 239 in the ordering exactly once, and the ordering MUST NOT include any 240 URI that is not an internal member of the collection. The server is 241 responsible for enforcing these constraints on orderings. The server 242 MUST remove an internal member URI from the ordering when it is 243 removed from the collection. Removing an internal member MUST NOT 244 affect the ordering of the remaining internal members. The server 245 MUST add an internal member URI to the ordering when it is added to 246 the collection. 248 Only one ordering can be attached to any collection. Multiple 249 orderings of the same resources can be achieved by creating multiple 250 collections referencing those resources, and attaching a different 251 ordering to each collection. 253 An ordering is considered to be part of the state of a collection 254 resource. Consequently, the ordering is the same no matter which URI 255 is used to access the collection and is protected by locks or access 256 control constraints on the collection. 258 4.1 Additional Collection properties 260 A DAV:allprop PROPFIND request SHOULD NOT return any of the 261 properties defined in this document. 263 4.1.1 DAV:ordering-type (protected) 265 Indicates whether the collection is ordered and, if so, uniquely 266 identifies the semantics of the ordering being used. May also point 267 to an explanation of the semantics in human and / or machine-readable 268 form. At a minimum, this allows human users who add members to the 269 collection to understand where to position them in the ordering. 270 This property cannot be set using PROPPATCH. Its value can only be 271 set by including the Ordering-Type header with a MKCOL request or by 272 submitting an ORDERPATCH request. 274 Ordering types are identified by URIs that uniquely identify the 275 semantics of the collection's ordering. The following two URIs are 276 predefined: 278 DAV:custom The value DAV:custom indicates that the collection is 279 ordered, but the semantics governing the ordering are not being 280 advertised. 282 DAV:unordered The value DAV:unordered indicates that the collection 283 is not ordered. That is, the client cannot depend on the 284 repeatability of the ordering of results from a PROPFIND request. 286 An ordering-aware client interacting with an ordering-unaware server 287 (e.g., one that is implemented only according to [RFC2518]) SHOULD 288 assume that if a collection does not have the DAV:ordering-type 289 property, the collection is unordered. 291 293 5. Creating an Ordered Collection 295 5.1 Overview 297 When a collection is created, the client MAY request that it be 298 ordered and specify the semantics of the ordering by using the new 299 Ordering-Type header (defined below) with a MKCOL request. 301 For collections that are ordered, the client SHOULD identify the 302 semantics of the ordering with a URI in the Ordering-Type header, 303 although the client MAY simply set the header value to DAV:custom to 304 indicate that the collection is ordered but the semantics of the 305 ordering are not being advertised. Setting the value to a URI that 306 identifies the ordering semantics provides the information a human 307 user or software package needs to insert new collection members into 308 the ordering intelligently. Although the URI in the Ordering-Type 309 header MAY point to a resource that contains a definition of the 310 semantics of the ordering, clients SHOULD NOT access that resource, 311 in order to avoid overburdening its server. A value of DAV:unordered 312 in the Ordering-Type header indicates that the client wants the 313 collection to be unordered. If the Ordering-Type header is not 314 present, the collection will be unordered. 316 Additional Marshalling: 318 Ordering-Type = "Ordering-Type" ":" absoluteURI 319 ; absoluteURI: see RFC2396, section 3 321 The URI "DAV:unordered" indicates that the collection is not 322 ordered, while "DAV:custom" indicates that the collection is to be 323 ordered, but the semantics of the ordering is not being 324 advertised. Any other URI value indicates that the collection is 325 ordered, and identifies the semantics of the ordering. 327 Additional Preconditions: 329 (DAV:ordered-collections-supported): the server MUST support 330 ordered collections in the part of the URL namespace identified by 331 the request URL. 333 Additional Postconditions: 335 (DAV:ordering-type-set): if the Ordering-Type header was present, 336 the request MUST have created a new collection resource with the 337 DAV:ordering-type being set according to the Ordering-Type request 338 header. The collection MUST be ordered unless the ordering type 339 was "DAV:unordered". 341 5.2 Example: Creating an Ordered Collection 343 >> Request: 345 MKCOL /theNorth/ HTTP/1.1 346 Host: example.org 347 Ordering-Type: http://example.org/orderings/compass.html 349 >> Response: 351 HTTP/1.1 201 Created 353 In this example a new, ordered collection was created. Its 354 DAV:ordering-type property has as its value the URI from the 355 Ordering-Type header, http://example.org/orderings/compass.html. In 356 this case, the URI identifies the semantics governing a 357 client-maintained ordering. As new members are added to the 358 collection, clients or end users can use the semantics to determine 359 where to position the new members in the ordering. 361 6. Setting the Position of a Collection Member 363 6.1 Overview 365 When a new member is added to a collection with a client-maintained 366 ordering (for example, with PUT, COPY, or MKCOL), its position in the 367 ordering can be set with the new Position header. The Position header 368 allows the client to specify that an internal member URI should be 369 first in the collection's ordering, last in the collection's 370 ordering, immediately before some other internal member URI in the 371 collection's ordering, or immediately after some other internal 372 member URI in the collection's ordering. 374 If the Position request header is not used when adding a member to an 375 ordered collection, then: 377 o If the request is replacing an existing resource, the server MUST 378 preserve the present ordering. 380 o If the request is adding a new internal member URI to the 381 collection, the server MUST append the new member to the end of 382 the ordering. 384 Note to implementors: this specification does not mandate a 385 specific implementation of MOVE operations within the same parent 386 collection. Therefore, servers may either implement this as a 387 simple rename operation (preserving the collection member's 388 position), or as a sequence of "remove" and "add" (causing the 389 semantics of "adding a new member" to apply). Future revisions of 390 this specification may specify this behaviour more precisely based 391 on future implementation experience. 393 Additional Marshalling: 395 Position = "Position" ":" ("first" | "last" | 396 (("before" | "after") segment)) 398 segment is defined in Section 3.3 of [RFC2396]. 400 The segment is interpreted relative to the collection to which the 401 new member is being added. 403 When the Position header is present, the server MUST insert the 404 new member into the ordering at the specified location. 406 The "first" keyword indicates the new member is put in the 407 beginning position in the collection's ordering, while "last" 408 indicates the new member is put in the final position in the 409 collection's ordering. The "before" keyword indicates the new 410 member is added to the collection's ordering immediately prior to 411 the position of the member identified in the segment. Likewise, 412 the "after" keyword indicates the new member is added to the 413 collection's ordering immediately following the position of the 414 member identified in the segment. 416 If the request is replacing an existing resource, and the Position 417 header is present, the server MUST remove the internal member URI 418 from its previous position, and then insert it at the requested 419 position. 421 Additional Preconditions: 423 (DAV:collection-must-be-ordered): the target collection MUST be 424 ordered. 426 (DAV:segment-must-identify-member): the referenced segment MUST 427 identify a resource that exists and is different from the affected 428 resource. 430 Additional Postconditions: 432 (DAV:position-set): if a Position header was present, the request 433 MUST have created the new collection member at the specified 434 position. 436 6.2 Examples: Setting the Position of a Collection Member 438 >> Request: 440 COPY /~user/dav/spec08.html HTTP/1.1 441 Host: example.org 442 Destination: http://example.org/~slein/dav/spec08.html 443 Position: after requirements.html 445 >> Response: 447 HTTP/1.1 201 Created 449 This request resulted in the creation of a new resource at 450 example.org/~slein/dav/spec08.html. The Position header in this 451 example caused the server to set its position in the ordering of the 452 /~slein/dav/ collection immediately after requirements.html. 454 >> Request: 456 MOVE /i-d/draft-webdav-prot-08.txt HTTP/1.1 457 Host: example.org 458 Destination: http://example.org/~user/dav/draft-webdav-prot-08.txt 459 Position: first 461 >> Response: 463 HTTP/1.1 409 Conflict 464 Content-Type: text/xml; charset="utf-8" 465 Content-Length: xxxx 467 468 469 470 472 In this case, the server returned a 409 (Conflict) status code 473 because the /~user/dav/ collection is an unordered collection. 474 Consequently, the server was unable to satisfy the Position header. 476 6.3 Examples: Renaming a member of an ordered collection 478 The following sequence of requests will rename a collection member 479 while preserving it's position, independantly of how the server 480 implements the MOVE operation: 482 1. PROPFIND collection with depth 1, retrieving the 483 DAV:ordering-type property (an interactive client likely already 484 has done this in order to display the collection's content) 486 2. If the DAV:ordering-type property is present and doesn't equal 487 "dav:unordered" (thus if the collection is ordered), determine 488 current position (such as "first" or "after x") and setup 489 Position header accordingly. 491 3. Perform the MOVE operation, optionally supplying the Position 492 header computed in the previous step. 494 7. Changing a Collection Ordering: ORDERPATCH method 496 The ORDERPATCH method is used to change the ordering semantics of a 497 collection or to change the order of the collection's members in the 498 ordering or both. 500 The server MUST apply the changes in the order they appear in the 501 order XML element. The server MUST either apply all the changes or 502 apply none of them. If any error occurs during processing, all 503 executed changes MUST be undone and a proper error result returned. 505 If an ORDERPATCH request changes the ordering semantics, but does not 506 completely specify the order of the collection members, the server 507 MUST assign a position in the ordering to each collection member for 508 which a position was not specified. These server-assigned positions 509 MUST all follow the last one specified by the client. The result is 510 that all members for which the client specified a position are at the 511 beginning of the ordering, followed by any members for which the 512 server assigned positions. Note that the ordering of the 513 server-assigned positions is not defined by this document, therefore 514 servers can use whatever rule seems reasonable (for instance, 515 alphabetically or by creation date). 517 If an ORDERPATCH request does not change the ordering semantics, any 518 member positions not specified in the request MUST remain unchanged. 520 A request to reposition a collection member at the same place in the 521 ordering is not an error. 523 If an ORDERPATCH request fails, the server state preceding the 524 request MUST be restored. 526 Additional Marshalling: 528 The request body MUST be DAV:orderpatch element. 530 532 533 534 535 536 537 538 539 PCDATA value: segment, as defined in section 3.3 of [RFC2396]. 541 The DAV:ordering-type property is modified according to the 542 DAV:ordering-type element. 544 The ordering of internal member URIs in the collection identified 545 by the Request-URI is changed based on instructions in the 546 order-member XML elements in the order they appear in the request. 547 The order-member XML elements identify the internal member URIs 548 whose positions are to be changed, and describe their new 549 positions in the ordering. Each new position can be specified as 550 first in the ordering, last in the ordering, immediately before 551 some other internal member URI, or immediately after some other 552 internal member URI. 554 If a response body for a successful request is included, it MUST 555 be a DAV:orderpatch-response XML element. Note that this document 556 does not define any elements for the ORDERPATCH response body, but 557 the DAV:orderpatch-response element is defined to ensure 558 interoperability between future extensions that do define elements 559 for the ORDERPATCH response body. 561 563 Since multiple changes can be requested in a single ORDERPATCH 564 request, if any problems are encountered, the server MUST return a 565 207 (Multi-Status) response (defined in [RFC2518]), containing 566 DAV:response elements for either the request-URI (when the 567 DAV:ordering-type could not be modified) or URIs of collection 568 members to be repositioned (when an individual positioning request 569 expressed as DAV:order-member could not be fulfilled). 571 Preconditions: 573 (DAV:collection-must-be-ordered): see Section 6.1. 575 (DAV:segment-must-identify-member): see Section 6.1. 577 Postconditions: 579 (DAV:ordering-type-set): if the request body contained a 580 DAV:ordering-type element, the request MUST have set the 581 DAV:ordering-type property of the collection to the value 582 specified in the request. 584 (DAV:ordering-modified): if the request body contained 585 DAV:order-member elements, the request MUST have set the ordering 586 of internal member URIs in the collection identified by the 587 request-URI based on the instructions in the DAV:order-member 588 elements. 590 7.1 Example: Changing a Collection Ordering 592 Consider an ordered collection /coll-1, with bindings ordered as 593 follows: 595 three.html 596 four.html 597 one.html 598 two.html 600 >> Request: 602 ORDERPATCH /coll-1/ HTTP/1.1 603 Host: example.org 604 Content-Type: text/xml; charset="utf-8" 605 Content-Length: xxx 607 608 609 610 http://example.org/inorder.ord 611 612 613 two.html 614 615 616 617 one.html 618 619 620 621 three.html 622 623 624 625 four.html 626 627 628 630 >> Response: 632 HTTP/1.1 200 OK 633 In this example, after the request has been processed, the 634 collection's ordering semantics are identified by the URI http:// 635 example.org/inorder.ord. The value of the collection's 636 DAV:ordering-type property has been set to this URI. The request also 637 contains instructions for changing the positions of the collection's 638 internal member URIs in the ordering to comply with the new ordering 639 semantics. As the DAV:order-member elements are required to be 640 processed in the order they appear in the request, two.html is moved 641 to the beginning of the ordering, and then one.html is moved to the 642 beginning of the ordering. Then three.html is moved to the end of 643 the ordering, and finally four.html is moved to the end of the 644 ordering. After the request has been processed, the collection's 645 ordering is as follows: 647 one.html 648 two.html 649 three.html 650 four.html 652 7.2 Example: Failure of an ORDERPATCH Request 654 Consider a collection /coll-1/ with members ordered as follows: 656 nunavut.map 657 nunavut.img 658 baffin.map 659 baffin.desc 660 baffin.img 661 iqaluit.map 662 nunavut.desc 663 iqaluit.img 664 iqaluit.desc 666 >> Request: 668 ORDERPATCH /coll-1/ HTTP/1.1 669 Host: www.nunanet.com 670 Content-Type: text/xml; charset="utf-8" 671 Content-Length: xxx 673 674 675 676 nunavut.desc 677 678 679 nunavut.map 681 682 683 684 685 iqaluit.map 686 687 688 pangnirtung.img 689 690 691 692 694 >> Response: 696 HTTP/1.1 207 Multi-Status 697 Content-Type: text/xml; charset="utf-8" 698 Content-Length: xxx 700 701 702 703 http://www.nunanet.com/coll-1/iqaluit.map 704 HTTP/1.1 403 Forbidden 705 706 707 pangnirtung.img is not a collection member. 708 709 710 712 In this example, the client attempted to position iqaluit.map after a 713 URI that is not an internal member of the collection /coll-1/. The 714 server responded to this client error with a 403 (Forbidden) status 715 code, indicating the failed precondition 716 DAV:segment-must-identify-member. Because ORDERPATCH is an atomic 717 method, the request to reposition nunavut.desc (which would otherwise 718 have succeeded) failed as well, but doesn't need to be expressed in 719 the multistatus response body. 721 8. Listing the Members of an Ordered Collection 723 A PROPFIND request is used to retrieve a listing of the members of an 724 ordered collection, just as it is used to retrieve a listing of the 725 members of an unordered collection. 727 However, when responding to a PROPFIND on an ordered collection, the 728 server MUST order the response elements according to the ordering 729 defined on the collection. If a collection is unordered, the client 730 cannot depend on the repeatability of the ordering of results from a 731 PROPFIND request. 733 In a response to a PROPFIND with Depth: infinity, members of 734 different collections may be interleaved. That is, the server is not 735 required to do a breadth-first traversal. The only requirement is 736 that the members of any ordered collection appear in the order 737 defined for the collection. Thus for the hierarchy illustrated in 738 the following figure, where collection A is an ordered collection 739 with the ordering B C D, 741 A 742 /|\ 743 / | \ 744 B C D 745 / /|\ 746 E F G H 748 it would be acceptable for the server to return response elements in 749 the order A B E C F G H D or "A B E C H G F D" as well (if C is 750 unordered).. In this response, B, C, and D appear in the correct 751 order, separated by members of other collections. Clients can use a 752 series of Depth: 1 PROPFIND requests to avoid the complexity of 753 processing Depth: infinity responses based on depth-first traversals. 755 8.1 Example: PROPFIND on an Ordered Collection 757 Suppose a PROPFIND request is submitted to /MyColl/, which has its 758 members ordered as follows. 760 /MyColl/ 761 lakehazen.html 762 siorapaluk.html 763 iqaluit.html 764 newyork.html 766 >> Request: 768 PROPFIND /MyColl/ HTTP/1.1 769 Host: example.org 770 Depth: 1 771 Content-Type: text/xml; charset="utf-8" 772 Content-Length: xxxx 774 775 776 777 778 779 780 781 783 >> Response: 785 HTTP/1.1 207 Multi-Status 786 Content-Type: text/xml; charset="utf-8" 787 Content-Length: xxxx 789 790 792 793 http://example.org/MyColl/ 794 795 796 797 DAV:custom 798 799 800 801 HTTP/1.1 200 OK 802 803 804 805 806 807 HTTP/1.1 404 Not Found 808 809 810 811 http://example.org/MyColl/lakehazen.html 812 813 814 815 82N 816 817 HTTP/1.1 200 OK 818 819 820 821 822 823 HTTP/1.1 404 Not Found 824 825 826 827 http://example.org/MyColl/siorapaluk.html 829 830 831 832 78N 833 834 HTTP/1.1 200 OK 835 836 837 838 839 840 HTTP/1.1 404 Not Found 841 842 843 844 http://example.org/MyColl/iqaluit.html 845 846 847 848 62N 849 850 HTTP/1.1 200 OK 851 852 853 854 855 856 HTTP/1.1 404 Not Found 857 858 859 860 http://example.org/MyColl/newyork.html 861 862 863 864 45N 866 867 HTTP/1.1 200 OK 868 869 870 871 872 HTTP/1.1 404 Not Found 873 874 875 876 878 In this example, the server responded with a list of the collection 879 members in the order defined for the collection. 881 9. Relationship to versioned collections 883 The Versioning Extensions to WebDAV [RFC3253] introduce the concept 884 of versioned collections, recording both the dead properties and the 885 set of internal version-controlled bindings. This section defines how 886 this feature interacts with ordered collections. 888 This specification considers both the ordering type 889 (DAV:ordering-type property) and the ordering of collection members 890 to be part of the state of a collection. Therefore both MUST be 891 recorded upon CHECKIN or VERSION-CONTROL, and both MUST be restored 892 upon CHECKOUT, UNCHECKOUT or UPDATE (where for compatibility with 893 RFC3253, only the ordering of version-controlled members needs to be 894 maintained). 896 9.1 Collection Version Properties 898 9.1.1 Additional semantics for DAV:version-controlled-binding-set 899 (protected) 901 For ordered collections, the DAV:version-controlled-binding elements 902 MUST appear in the ordering defined for the checked-in ordered 903 collection. 905 9.1.2 DAV:ordering-type (protected) 907 The DAV:ordering-type property records the DAV:ordering-type property 908 of the checked-in ordered collection. 910 9.2 Additional CHECKIN semantics 912 Additional Postconditions: 914 (DAV:initialize-version-controlled-bindings-ordered): If the 915 request-URL identified a both ordered and version-controlled 916 collection, then the child elements of 917 DAV:version-controlled-binding-set of the new collection version 918 MUST appear in the ordering defined for that collection. 920 (DAV:initialize-collection-version-ordering-type): If the 921 request-URL identified a both ordered and version-controlled 922 collection, then the DAV:ordering-type property of the new 923 collection version MUST be a copy of the collection's 924 DAV:ordering-type property. 926 9.3 Additional CHECKOUT Semantics 928 Additional Postconditions: 930 (DAV:initialize-version-history-bindings-ordered): If the request 931 has been applied to a collection version with a DAV:ordering-type 932 other than "DAV:unordered", the bindings in the new working 933 collection MUST be ordered according to the collection version's 934 DAV:version-controlled-binding-set property. 936 (DAV:initialize-ordering-type): If the request has been applied to 937 a collection version, the DAV:ordering-type property of the new 938 working collection MUST be initialized from the collection 939 version's DAV:ordering-type property. 941 9.4 Additional UNCHECKOUT, UPDATE, and MERGE Semantics 943 Additional Postconditions: 945 (DAV:update-version-controlled-collection-members-ordered): If the 946 request modified the DAV:checked-in version of a 947 version-controlled collection and the DAV:ordering-type for the 948 checked-in version is not unordered ("DAV:unordered"), the 949 version-controlled members MUST be ordered according to the 950 checked-in version's DAV:version-controlled-binding-set property. 951 The ordering of non-version-controlled members is server-defined. 953 (DAV:update-version-ordering-type): If the request modified the 954 DAV:checked-in version of a version-controlled collection, the 955 DAV:ordering-type property MUST be updated from the checked-in 956 version's property. 958 10. Capability Discovery 960 Sections 9.1 and 15 of [RFC2518] describe the use of compliance 961 classes with the DAV header in responses to OPTIONS, to indicate 962 which parts of the Web Distributed Authoring protocols the resource 963 supports. This specification defines an OPTIONAL extension to 964 [RFC2518]. It defines a new compliance class, called 965 ordered-collections, for use with the DAV header in responses to 966 OPTIONS requests. If a collection resource does support ordering, 967 its response to an OPTIONS request may indicate that it does, by 968 listing the new ORDERPATCH method as one it supports, and by listing 969 the new ordered-collections compliance class in the DAV header. 971 When responding to an OPTIONS request, only a collection or a null 972 resource can include ordered-collections in the value of the DAV 973 header. By including ordered-collections, the resource indicates 974 that its internal member URIs can be ordered. It implies nothing 975 about whether any collections identified by its internal member URIs 976 can be ordered. 978 Furthermore, RFC 3253 [RFC3253] introduces the live properties 979 DAV:supported-method-set (section 3.1.3) and 980 DAV:supported-live-property-set (section 3.1.4). Servers MUST support 981 these properties as defined in RFC 3253. 983 10.1 Example: Using OPTIONS for the Discovery of Support for Ordering 985 >> Request: 987 OPTIONS /somecollection/ HTTP/1.1 988 Host: example.org 990 >> Response: 992 HTTP/1.1 200 OK 993 Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE 994 Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, ORDERPATCH 995 DAV: 1, 2, ordered-collections 997 The DAV header in the response indicates that the resource / 998 somecollection/ is level 1 and level 2 compliant, as defined in 999 [RFC2518]. In addition, /somecollection/ supports ordering. The 1000 Allow header indicates that ORDERPATCH requests can be submitted to / 1001 somecollection/. 1003 10.2 Example: Using Live Properties for the Discovery of Ordering 1005 >> Request: 1006 PROPFIND /somecollection HTTP/1.1 1007 Depth: 0 1008 Content-Type: text/xml; charset="utf-8" 1009 Content-Length: xxx 1011 1012 1013 1014 1015 1016 1017 1019 >> Response: 1020 HTTP/1.1 207 Multi-Status 1021 Content-Type: text/xml; charset="utf-8" 1022 Content-Length: xxx 1024 1025 1026 1027 http://example.org/somecollection 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 HTTP/1.1 200 OK 1055 1056 1057 1059 Note that actual responses MUST contain a complete list of supported 1060 live properties. 1062 11. Security Considerations 1064 This section is provided to make WebDAV applications aware of the 1065 security implications of this protocol. 1067 All of the security considerations of HTTP/1.1 and the WebDAV 1068 Distributed Authoring Protocol specification also apply to this 1069 protocol specification. In addition, ordered collections introduce a 1070 new security concern. This issue is detailed here. 1072 11.1 Denial of Service and DAV:ordering-type 1074 There may be some risk of denial of service at sites that are 1075 advertised in the DAV:ordering-type property of collections. 1076 However, it is anticipated that widely-deployed applications will use 1077 hard-coded values for frequently-used ordering semantics rather than 1078 looking up the semantics at the location specified by 1079 DAV:ordering-type. This risk will be further reduced if clients 1080 observe the recommendation of Section 5.1 that they not send requests 1081 to the URI in DAV:ordering-type. 1083 12. Internationalization Considerations 1085 This specification follows the practices of [RFC2518] in encoding all 1086 human-readable content using [XML] and in the treatment of names. 1087 Consequently, this specification complies with the IETF Character Set 1088 Policy [RFC2277]. 1090 WebDAV applications MUST support the character set tagging, character 1091 set encoding, and the language tagging functionality of the XML 1092 specification. This constraint ensures that the human-readable 1093 content of this specification complies with [RFC2277]. 1095 As in [RFC2518], names in this specification fall into three 1096 categories: names of protocol elements such as methods and headers, 1097 names of XML elements, and names of properties. Naming of protocol 1098 elements follows the precedent of HTTP, using English names encoded 1099 in USASCII for methods and headers. The names of XML elements used 1100 in this specification are English names encoded in UTF-8. 1102 For error reporting, [RFC2518] follows the convention of HTTP/1.1 1103 status codes, including with each status code a short, English 1104 description of the code (e.g., 423 Locked). Internationalized 1105 applications will ignore this message, and display an appropriate 1106 message in the user's language and character set. 1108 This specification introduces no new strings that are displayed to 1109 users as part of normal, error-free operation of the protocol. 1111 For rationales for these decisions and advice for application 1112 implementors, see [RFC2518]. 1114 13. IANA Considerations 1116 This document uses the namespaces defined by [RFC2518] for properties 1117 and XML elements. All other IANA considerations mentioned in 1118 [RFC2518] also apply to this document. 1120 14. Copyright 1122 To be supplied by the RFC Editor. 1124 15. Intellectual Property 1126 To be supplied by the RFC Editor. 1128 16. Contributors 1130 This document has benefited from significant contributions from Geoff 1131 Clemm, Jason Crawford, Jim Davis, Chuck Fay and Judith Slein. 1133 17. Acknowledgements 1135 This document has benefited from thoughtful discussion by Jim Amsden, 1136 Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen, Bruce Cragun, 1137 Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, Lisa 1138 Dusseault, Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, 1139 Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, Daniel 1140 LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra 1141 Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, 1142 John Stracke, John Tigue, John Turner, Kevin Wiggen, and others. 1144 Normative References 1146 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1147 Requirement Levels", BCP 14, RFC 2119, March 1997. 1149 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 1150 Languages", BCP 18, RFC 2277, January 1998. 1152 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1153 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1154 August 1998. 1156 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. 1157 Jensen, "HTTP Extensions for Distributed Authoring -- 1158 WEBDAV", RFC 2518, February 1999. 1160 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1161 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 1162 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1164 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J. 1165 Whitehead, "Versioning Extensions to WebDAV", RFC 3253, 1166 March 2002. 1168 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 1169 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C 1170 REC-xml, October 2000, . 1173 [1] 1175 [2] 1177 Authors' Addresses 1179 Jim Whitehead 1180 UC Santa Cruz, Dept. of Computer Science 1181 1156 High Street 1182 Santa Cruz, CA 95064 1183 US 1185 EMail: ejw@cse.ucsc.edu 1186 Julian F. Reschke (editor) 1187 greenbytes GmbH 1188 Salzmannstrasse 152 1189 Muenster, NW 48159 1190 Germany 1192 Phone: +49 251 2807760 1193 Fax: +49 251 2807761 1194 EMail: julian.reschke@greenbytes.de 1195 URI: http://greenbytes.de/tech/webdav/ 1197 Appendix A. Extensions to the WebDAV Document Type Definition 1199 1200 1201 1202 1203 1204 1205 1206 1207 1209 Appendix B. Change Log 1211 B.1 Since draft-ietf-webdav-ordering-protocol dated December 1999 1213 Updated contact information for all previous authors. 1214 Specify charset when using text/xml media type. 1215 Made sure artwork fits into 72 columns. 1216 Removed "Public" header from OPTIONS example. 1217 Added Julian Reschke to list of authors. 1218 Fixed broken XML in PROPFIND example and added DAV:orderingtype to 1219 list of requested properties. 1220 Added support for DAV:supported-live-property-set and 1221 DAV:supported-method-set as mandatory features. 1223 B.2 Since draft-ietf-webdav-ordering-protocol-02 1225 Updated change log to refer to expired draft version as "December 1226 1999" version. 1227 Started rewrite marshalling in RFC3253-style and added precondition 1228 and postcondition definitions. 1229 On his request, removed Geoff Clemm's name from the author list 1230 (moved to Acknowledgments). 1231 Renamed "References" to "Normative References". 1232 Removed reference to "MKREF" method. 1234 B.3 Since draft-ietf-webdav-ordering-protocol-03 1236 Added a set of issues regarding marshalling. 1237 Changed host names to use proper "example" domain names (no change 1238 tracking). Fixed host/destination header conflicts. Fixed "allow" 1239 header (multiline). Removed irrelevant response headers. Abbreviated 1240 some URIs (no change tracking). 1241 Removed Jim Davis and Chuck Fay from the author list (and added them 1242 to the Acknowledgements section). 1243 Updated section on setting the position when adding new members, 1244 removed old section on Position header. 1245 Started work on Index section. 1246 Changed structure for section 7 (no change tracking). 1247 Removed header and XML elements section (contents moved to other 1248 sections). 1249 Started new section on relation to versioned collections as per 1250 RFC3253. 1251 Do not return 424's for in ORDERPATCH multistatus (it's atomic 1252 anyway). 1254 B.4 Since draft-ietf-webdav-ordering-protocol-04 1256 Added proper reference to definition of "Coded-URL". 1258 Closed issue ordering-type-values (content model simplified and XML 1259 element / DAV property renamed) and updated examples. 1260 Renamed precondition DAV:orderingtype-set to DAV:ordering-type-set 1261 (no change tracking). 1262 Closed issue ordered-header-name (header name changed to 1263 "ordering-type", contents matches live property). 1264 Closed issue ordermember-format (now takes segment instead of href). 1265 Renamed compliance class to "ordered-collections" for consistency 1266 with newer specs, and to allow detection of compliance to final 1267 version of spec. 1268 Updated reference to XML spec to 1.0, 2nd edition. 1270 B.5 Since draft-ietf-webdav-ordering-protocol-05 1272 Typos fixed. 1273 Renamed DAV:ordermember to DAV:order-member. 1274 Made RFC3253-compatible pre/postcondition handling a MUST 1275 requirement. 1276 Reference definition of "protected property" from RFC3253. 1277 Added explanation of role of DTD fragments to Notation section. 1278 Clarified semantics for operations on versioned collections and 1279 collection versions. 1281 B.6 Since draft-ietf-webdav-ordering-protocol-06 1283 Added atomicity statement for ORDERPATCH method. 1285 B.7 Since draft-ietf-webdav-ordering-protocol-07 1287 Added issues "4.1-DELETE-behaviour", "6.1-safe-update", 1288 "6.1-when-are-members-added" and 1289 "9.4-UPDATE-non-version-controlled-members" and resolved them. Added 1290 new "contributors" section, and mention original authors such as 1291 Judith Slein there. 1293 B.8 Since draft-ietf-webdav-ordering-protocol-08 1295 Typos fixed. Added and resolved issues 1296 "6-position-preserving-rename", 1297 "7-clarify-positions-for-not-explicitly-mentioned-members", 1298 "7.1-surprising-ordering-type-in-DAV-ns" and 1299 "8-order-for-unordered-subcollections". 1301 Index 1303 C 1304 Client-Maintained Ordering 6 1306 D 1307 DAV:collection-must-be-ordered precondition 12 1308 DAV:custom ordering type 8 1309 DAV:initialize-collection-version-ordering-type 23 1310 DAV:initialize-ordering-type 24 1311 DAV:initialize-version-controlled-bindings-ordered postcondition 23 1312 DAV:initialize-version-history-bindings-ordered 24 1313 DAV:ordered-collections-supported precondition 9 1314 DAV:ordering-modified postcondition 15 1315 DAV:ordering-type property 7 1316 DAV:ordering-type-set postcondition 9, 15 1317 DAV:position-set postcondition 12 1318 DAV:segment-must-identify-member precondition 12 1319 DAV:unordered ordering type 8 1320 DAV:update-version-controlled-collection-members-ordered 24 1321 DAV:update-version-ordering-type 24 1323 H 1324 Headers 1325 Ordering-Type 9 1327 O 1328 Ordered Collection 6 1329 Ordering-Type header 9 1330 ORDERPATCH method 14 1332 P 1333 Postconditions 1334 DAV:initialize-collection-version-ordering-type 23 1335 DAV:initialize-ordering-type 24 1336 DAV:initialize-version-controlled-bindings-ordered 23 1337 DAV:initialize-version-history-bindings-ordered 24 1338 DAV:ordering-modified 15 1339 DAV:ordering-type-set 9, 15 1340 DAV:position-set 12 1341 DAV:update-version-controlled-collection-members-ordered 24 1342 DAV:update-version-ordering-type 24 1343 Preconditions 1344 DAV:collection-must-be-ordered 12 1345 DAV:ordered-collections-supported 9 1346 DAV:segment-must-identify-member 12 1347 Protected properties 1348 DAV:ordering-type 7 1350 S 1351 Server-Maintained Ordering 6 1353 U 1354 Unordered Collection 6 1356 Intellectual Property Statement 1358 The IETF takes no position regarding the validity or scope of any 1359 intellectual property or other rights that might be claimed to 1360 pertain to the implementation or use of the technology described in 1361 this document or the extent to which any license under such rights 1362 might or might not be available; neither does it represent that it 1363 has made any effort to identify any such rights. Information on the 1364 IETF's procedures with respect to rights in standards-track and 1365 standards-related documentation can be found in BCP-11. Copies of 1366 claims of rights made available for publication and any assurances of 1367 licenses to be made available, or the result of an attempt made to 1368 obtain a general license or permission for the use of such 1369 proprietary rights by implementors or users of this specification can 1370 be obtained from the IETF Secretariat. 1372 The IETF invites any interested party to bring to its attention any 1373 copyrights, patents or patent applications, or other proprietary 1374 rights which may cover technology that may be required to practice 1375 this standard. Please address the information to the IETF Executive 1376 Director. 1378 Full Copyright Statement 1380 Copyright (C) The Internet Society (2003). All Rights Reserved. 1382 This document and translations of it may be copied and furnished to 1383 others, and derivative works that comment on or otherwise explain it 1384 or assist in its implementation may be prepared, copied, published 1385 and distributed, in whole or in part, without restriction of any 1386 kind, provided that the above copyright notice and this paragraph are 1387 included on all such copies and derivative works. However, this 1388 document itself may not be modified in any way, such as by removing 1389 the copyright notice or references to the Internet Society or other 1390 Internet organizations, except as needed for the purpose of 1391 developing Internet standards in which case the procedures for 1392 copyrights defined in the Internet Standards process must be 1393 followed, or as required to translate it into languages other than 1394 English. 1396 The limited permissions granted above are perpetual and will not be 1397 revoked by the Internet Society or its successors or assignees. 1399 This document and the information contained herein is provided on an 1400 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1401 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1402 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1403 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1404 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1406 Acknowledgment 1408 Funding for the RFC Editor function is currently provided by the 1409 Internet Society.