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.