Network Working Group J. Whitehead
Request for Comments: 3648 U.C. Santa Cruz
Category: Standards Track J. Reschke, Ed.
greenbytes
December 2003
Network Working Group J. Whitehead
Request for Comments: 3648 U.C. Santa Cruz
Category: Standards Track J. Reschke, Ed.
greenbytes
December 2003
Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol
Web分布式创作和版本控制（WebDAV）有序集合协议
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This specification extends the Web Distributed Authoring and Versioning (WebDAV) Protocol to support the server-side ordering of collection members. Of particular interest are orderings that are not based on property values, and so cannot be achieved using a search protocol's ordering option and cannot be maintained automatically by the server. Protocol elements are defined to let clients specify the position in the ordering of each collection member, as well as the semantics governing the ordering.
此规范扩展了Web分布式创作和版本控制（WebDAV）协议，以支持集合成员的服务器端排序。特别令人感兴趣的是不基于属性值的排序，因此无法使用搜索协议的排序选项实现，也无法由服务器自动维护。定义协议元素是为了让客户端指定每个集合成员在排序中的位置，以及控制排序的语义。
Table of Contents
目录
1. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview of Ordered Collections . . . . . . . . . . . . . . . 5
4.1. Additional Collection properties . . . . . . . . . . . . 6
4.1.1. DAV:ordering-type (protected). . . . . . . . . . 6
5. Creating an Ordered Collection . . . . . . . . . . . . . . . . 7
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Example: Creating an Ordered Collection. . . . . . . . . 8
6. Setting the Position of a Collection Member. . . . . . . . . . 8
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Examples: Setting the Position of a Collection Member. . 10
6.3. Examples: Renaming a member of an ordered collection . . 10
7. Changing a Collection Ordering: ORDERPATCH method. . . . . . . 11
7.1. Example: Changing a Collection Ordering. . . . . . . . . 13
7.2. Example: Failure of an ORDERPATCH Request. . . . . . . . 14
8. Listing the Members of an Ordered Collection . . . . . . . . . 16
8.1. Example: PROPFIND on an Ordered Collection . . . . . . . 17
9. Relationship to versioned collections. . . . . . . . . . . . . 19
9.1. Collection Version Properties. . . . . . . . . . . . . . 20
9.1.1. Additional semantics for
DAV:version-controlled-binding-set (protected) . 20
9.1.2. DAV:ordering-type (protected). . . . . . . . . . 20
9.2. Additional CHECKIN semantics . . . . . . . . . . . . . . 20
9.3. Additional CHECKOUT Semantics. . . . . . . . . . . . . . 20
9.4. Additional UNCHECKOUT, UPDATE, and MERGE Semantics . . . 21
10. Capability Discovery . . . . . . . . . . . . . . . . . . . . . 21
10.1. Example: Using OPTIONS for the Discovery of Support for
Ordering . . . . . . . . . . . . . . . . . . . . . . . . 22
10.2. Example: Using Live Properties for the Discovery of
Ordering . . . . . . . . . . . . . . . . . . . . . . . . 22
11. Security Considerations. . . . . . . . . . . . . . . . . . . . 23
11.1. Denial of Service and DAV:ordering-type . . . . . . . . 23
12. Internationalization Considerations. . . . . . . . . . . . . . 24
13. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 24
14. Intellectual Property Statement. . . . . . . . . . . . . . . . 25
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
17. Normative References . . . . . . . . . . . . . . . . . . . . . 26
A. Extensions to the WebDAV Document Type Definition. . . . . . . 27
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 30
1. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview of Ordered Collections . . . . . . . . . . . . . . . 5
4.1. Additional Collection properties . . . . . . . . . . . . 6
4.1.1. DAV:ordering-type (protected). . . . . . . . . . 6
5. Creating an Ordered Collection . . . . . . . . . . . . . . . . 7
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Example: Creating an Ordered Collection. . . . . . . . . 8
6. Setting the Position of a Collection Member. . . . . . . . . . 8
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Examples: Setting the Position of a Collection Member. . 10
6.3. Examples: Renaming a member of an ordered collection . . 10
7. Changing a Collection Ordering: ORDERPATCH method. . . . . . . 11
7.1. Example: Changing a Collection Ordering. . . . . . . . . 13
7.2. Example: Failure of an ORDERPATCH Request. . . . . . . . 14
8. Listing the Members of an Ordered Collection . . . . . . . . . 16
8.1. Example: PROPFIND on an Ordered Collection . . . . . . . 17
9. Relationship to versioned collections. . . . . . . . . . . . . 19
9.1. Collection Version Properties. . . . . . . . . . . . . . 20
9.1.1. Additional semantics for
DAV:version-controlled-binding-set (protected) . 20
9.1.2. DAV:ordering-type (protected). . . . . . . . . . 20
9.2. Additional CHECKIN semantics . . . . . . . . . . . . . . 20
9.3. Additional CHECKOUT Semantics. . . . . . . . . . . . . . 20
9.4. Additional UNCHECKOUT, UPDATE, and MERGE Semantics . . . 21
10. Capability Discovery . . . . . . . . . . . . . . . . . . . . . 21
10.1. Example: Using OPTIONS for the Discovery of Support for
Ordering . . . . . . . . . . . . . . . . . . . . . . . . 22
10.2. Example: Using Live Properties for the Discovery of
Ordering . . . . . . . . . . . . . . . . . . . . . . . . 22
11. Security Considerations. . . . . . . . . . . . . . . . . . . . 23
11.1. Denial of Service and DAV:ordering-type . . . . . . . . 23
12. Internationalization Considerations. . . . . . . . . . . . . . 24
13. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 24
14. Intellectual Property Statement. . . . . . . . . . . . . . . . 25
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
17. Normative References . . . . . . . . . . . . . . . . . . . . . 26
A. Extensions to the WebDAV Document Type Definition. . . . . . . 27
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 30
Since this document describes a set of extensions to the WebDAV Distributed Authoring Protocol [RFC2518], which is itself an extension to the HTTP/1.1 protocol, the augmented BNF used here to describe protocol elements is exactly the same as described in Section 2.1 of HTTP [RFC2616]. Since this augmented BNF uses the basic production rules provided in Section 2.2 of HTTP, these rules apply to this document as well.
由于本文档描述了WebDAV分布式创作协议[RFC2518]的一组扩展，该协议本身就是HTTP/1.1协议的扩展，因此此处用于描述协议元素的扩展BNF与HTTP[RFC2616]第2.1节中描述的完全相同。由于此扩展BNF使用HTTP第2.2节中提供的基本生成规则，因此这些规则也适用于本文档。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document uses XML DTD fragments as a purely notational convention. WebDAV request and response bodies can not be validated due to the specific extensibility rules defined in section 23 of [RFC2518] and due to the fact that all XML elements defined by this specification use the XML namespace name "DAV:". In particular:
本文档使用XML DTD片段作为纯粹的符号约定。由于[RFC2518]第23节中定义的特定扩展性规则以及本规范定义的所有XML元素都使用XML命名空间名称“DAV:”，因此无法验证WebDAV请求和响应主体。特别地：
1. element names use the "DAV:" namespace,
1. 元素名称使用“DAV:”名称空间，
2. element ordering is irrelevant,
2. 元素排序是不相关的，
3. extension elements (elements not already defined as valid child elements) may be added anywhere, except where explicitly stated otherwise,
3. 扩展元素（尚未定义为有效子元素的元素）可以添加到任何位置，除非另有明确说明，
4. extension attributes (attributes not already defined as valid for this element) may be added anywhere, except where explicitly stated otherwise.
4. 扩展属性（尚未定义为此元素有效的属性）可以添加到任何位置，除非另有明确说明。
This specification builds on the collection infrastructure provided by the WebDAV Distributed Authoring Protocol, adding support for the server-side ordering of collection members.
本规范建立在WebDAV分布式创作协议提供的集合基础设施之上，增加了对集合成员服务器端排序的支持。
There are many scenarios in which it is useful to impose an ordering on a collection at the server, such as expressing a recommended access order, or a revision history order. The members of a collection might represent the pages of a book, which need to be presented in order if they are to make sense, or an instructor might create a collection of course readings that she wants to be displayed in the order they are to be read.
在许多情况下，对服务器上的集合施加排序非常有用，例如表示建议的访问顺序或修订历史顺序。一个集合的成员可能代表一本书的页面，如果它们要有意义，就需要按顺序呈现，或者讲师可能创建一个她希望按阅读顺序显示的课程阅读集合。
Orderings may be based on property values, but this is not always the case. The resources in the collection may not have properties that
排序可能基于属性值，但情况并非总是如此。集合中的资源可能没有
can be used to support the desired ordering. Orderings based on properties can be obtained using a search protocol's ordering option, but orderings not based on properties cannot. These orderings generally need to be maintained by a human user.
可用于支持所需的订购。可以使用搜索协议的排序选项获取基于属性的排序，但不能获取不基于属性的排序。这些订单通常需要由人工用户维护。
The ordering protocol defined here focuses on support for such human-maintained orderings. Its protocol elements allow clients to specify the position of each collection member in the collection's ordering, as well as the semantics governing the order. The protocol is designed to allow additional support in the future for orderings that are maintained automatically by the server.
这里定义的订购协议侧重于支持此类人工维护的订购。它的协议元素允许客户端指定每个集合成员在集合顺序中的位置，以及控制顺序的语义。该协议旨在允许将来对服务器自动维护的订单提供额外的支持。
The remainder of this document is structured as follows: Section 3 defines terminology that will be used throughout the specification. Section 4 provides an overview of ordered collections. Section 5 describes how to create an ordered collection, and Section 6 discusses how to set a member's position in the ordering of a collection. Section 7 explains how to change a collection ordering. Section 8 discusses listing the members of an ordered collection. Section 9 discusses the impact on version-controlled collections (as defined in [RFC3253]). Section 10 describes capability discovery. Sections 11 through 13 discuss security, internationalization, and IANA considerations. The remaining sections provide supporting information.
本文件其余部分的结构如下：第3节定义了整个规范中将使用的术语。第4节概述了有序集合。第5节介绍如何创建有序集合，第6节讨论如何设置成员在集合排序中的位置。第7节说明如何更改集合顺序。第8节讨论列出有序集合的成员。第9节讨论了对版本控制集合的影响（如[RFC3253]中的定义）。第10节描述了能力发现。第11至13节讨论了安全性、国际化和IANA考虑事项。其余部分提供了支持信息。
The terminology used here follows that in [RFC2518] and [RFC3253]. Definitions of the terms resource, Uniform Resource Identifier (URI), and Uniform Resource Locator (URL) are provided in [RFC2396].
此处使用的术语遵循[RFC2518]和[RFC3253]中的术语。[RFC2396]中提供了术语资源、统一资源标识符（URI）和统一资源定位器（URL）的定义。
Ordered Collection
有序收集
A collection for which the results from a PROPFIND request are guaranteed to be in the order specified for that collection.
一种集合，其PROPFIND请求的结果保证为该集合指定的顺序。
Unordered Collection
无序收集
A collection for which the client cannot depend on the repeatability of the ordering of results from a PROPFIND request.
客户端无法依赖PROPFIND请求结果排序的可重复性的集合。
Client-Maintained Ordering
客户维持订购
An ordering of collection members that is maintained on the server based on client requests specifying the position of each collection member in the ordering.
在服务器上维护的集合成员的排序，基于指定每个集合成员在排序中的位置的客户端请求。
Server-Maintained Ordering
服务器维护的订购
An ordering of collection members that is maintained automatically by the server, based on a client's choice of ordering semantics.
由服务器根据客户端选择的排序语义自动维护的集合成员的排序。
Ordering Semantics
排序语义
In general, ordering semantics are the set of structures or meanings applied to the ordering of the member of a specific collection. Within this document, "ordering semantics" refers specifically to the structure specified in the DAV:ordering-type property. See Section 4.1.1 for more information on DAV:ordering-type.
通常，排序语义是应用于特定集合成员排序的一组结构或意义。在本文档中，“排序语义”特别指DAV:ordering-type属性中指定的结构。有关DAV：订购类型的更多信息，请参见第4.1.1节。
This document uses the terms "precondition", "postcondition" and "protected property" as defined in [RFC3253]. Servers MUST report pre-/postcondition failures as described in section 1.6 of this document.
本文件使用[RFC3253]中定义的术语“前提条件”、“后条件”和“受保护财产”。服务器必须报告本文档第1.6节所述的前置/后置条件故障。
If a collection is not ordered, the client cannot depend on the repeatability of the ordering of results from a PROPFIND request. By specifying an ordering for a collection, a client requires the server to follow that ordering whenever it responds to a PROPFIND request on that collection.
如果集合未排序，则客户端无法依赖PROPFIND请求结果排序的可重复性。通过为集合指定排序，客户机要求服务器在响应该集合上的PROPFIND请求时遵循该排序。
Server-side orderings may be client-maintained or server-maintained. For client-maintained orderings, a client must specify the ordering position of each of the collection's members, either when the member is added to the collection (using the Position header (Section 6)) or later (using the ORDERPATCH (Section 7) method). For server-maintained orderings, the server automatically positions each of the collection's members according to the ordering semantics. This specification supports only client-maintained orderings, but is designed to allow the future extension with server-maintained orderings.
服务器端订单可以由客户端维护，也可以由服务器维护。对于客户机维护的订购，客户机必须在将成员添加到集合（使用位置标题（第6节））或更高版本（使用ORDERPATCH（第7节）方法）时指定集合中每个成员的订购位置。对于服务器维护的排序，服务器会根据排序语义自动定位集合的每个成员。此规范仅支持客户端维护的订单，但旨在允许将来使用服务器维护的订单进行扩展。
A collection that supports ordering is not required to be ordered.
支持排序的集合不需要排序。
If a collection is ordered, each of its internal member URIs MUST appear in the ordering exactly once, and the ordering MUST NOT include any URIs that are not internal members of the collection. The server is responsible for enforcing these constraints on orderings. The server MUST remove an internal member URI from the ordering when it is removed from the collection. Removing an internal member MUST NOT affect the ordering of the remaining
如果对集合进行了排序，则其每个内部成员URI必须在排序中正好出现一次，并且排序中不得包含任何不是集合内部成员的URI。服务器负责对订单实施这些约束。从集合中删除内部成员URI时，服务器必须从排序中删除该URI。移除内部构件不得影响剩余构件的顺序
internal members. The server MUST add an internal member URI to the ordering when it is added to the collection.
内部成员。将内部成员URI添加到集合时，服务器必须将其添加到排序中。
Only one ordering can be attached to any collection. Multiple orderings of the same resources can be achieved by creating multiple collections referencing those resources, and attaching a different ordering to each collection.
任何集合只能附加一个订单。通过创建引用这些资源的多个集合，并将不同的排序附加到每个集合，可以实现相同资源的多个排序。
An ordering is considered to be part of the state of a collection resource. Consequently, the ordering is the same no matter which URI is used to access the collection and is protected by locks or access control constraints on the collection.
排序被视为集合资源状态的一部分。因此，无论使用哪个URI访问集合，并且受集合上的锁或访问控制约束的保护，顺序都是相同的。
A DAV:allprop PROPFIND request SHOULD NOT return any of the properties defined in this document.
DAV:allprop PROPFIND请求不应返回此文档中定义的任何属性。
The DAV:ordering-type property indicates whether the collection is ordered and, if so, uniquely identifies the semantics of the ordering. It may also point to an explanation of the semantics in human and/or machine-readable form. At a minimum, this allows human users who add members to the collection to understand where to position them in the ordering. This property cannot be set using PROPPATCH. Its value can only be set by including the Ordering-Type header with a MKCOL request or by submitting an ORDERPATCH request.
DAV:ordering-type属性指示集合是否已排序，如果已排序，则唯一标识排序的语义。它还可以指向人类和/或机器可读形式的语义解释。至少，这允许向集合中添加成员的人工用户了解他们在排序中的位置。无法使用PROPPATCH设置此属性。只能通过在MKCOL请求中包含Ordering Type标头或提交ORDERPATCH请求来设置其值。
Ordering types are identified by URIs that uniquely identify the semantics of the collection's ordering. The following two URIs are predefined:
排序类型由唯一标识集合排序语义的URI标识。预定义了以下两个URI：
DAV:custom: The value DAV:custom indicates that the collection is ordered, but the semantics governing the ordering are not being advertised.
DAV:custom：值DAV:custom表示集合已排序，但未公布控制排序的语义。
DAV:unordered: The value DAV:unordered indicates that the collection is not ordered. That is, the client cannot depend on the repeatability of the ordering of results from a PROPFIND request.
DAV:unordered：值DAV:unordered表示集合未排序。也就是说，客户端不能依赖PROPFIND请求结果排序的可重复性。
An ordering-aware client interacting with an ordering-unaware server (e.g., one that is implemented only according to [RFC2518]) SHOULD assume that the collection is unordered if a collection does not have the DAV:ordering-type property.
如果集合不具有DAV:ordering type属性，则与不知道排序的服务器（例如，仅根据[RFC2518]实现的服务器）交互的了解排序的客户端应假定集合是无序的。
<!ELEMENT ordering-type (href) >
<!ELEMENT ordering-type (href) >
When a collection is created, the client MAY request that it be ordered and specify the semantics of the ordering by using the new Ordering-Type header (defined below) with a MKCOL request.
创建集合时，客户端可以请求对其进行排序，并通过使用新的排序类型头（定义如下）和MKCOL请求来指定排序的语义。
For collections that are ordered, the client SHOULD identify the semantics of the ordering with a URI in the Ordering-Type header, although the client MAY simply set the header value to DAV:custom to indicate that the collection is ordered but the semantics of the ordering are not being advertised. Setting the value to a URI that identifies the ordering semantics provides the information a human user or software package needs to insert new collection members into the ordering intelligently. Although the URI in the Ordering-Type header MAY point to a resource that contains a definition of the semantics of the ordering, clients SHOULD NOT access that resource to avoid overburdening its server. A value of DAV:unordered in the Ordering-Type header indicates that the client wants the collection to be unordered. If the Ordering-Type header is not present, the collection will be unordered.
对于已排序的集合，客户机应该在ordering Type标头中使用URI标识排序的语义，尽管客户机可以简单地将标头值设置为DAV:custom，以指示集合已排序，但未公布排序的语义。将该值设置为标识排序语义的URI，可以提供人工用户或软件包智能地将新集合成员插入到排序中所需的信息。尽管Ordering Type标头中的URI可能指向包含排序语义定义的资源，但客户端不应访问该资源以避免服务器负担过重。Ordering Type标头中的值DAV:unordered表示客户端希望集合无序。如果排序类型标头不存在，则集合将无序。
Additional Marshalling:
附加编组：
Ordering-Type = "Ordering-Type" ":" absoluteURI
; absoluteURI: see RFC2396, section 3
Ordering-Type = "Ordering-Type" ":" absoluteURI
; absoluteURI: see RFC2396, section 3
The URI "DAV:unordered" indicates that the collection is not ordered, while "DAV:custom" indicates that the collection is to be ordered, but the semantics of the ordering is not being advertised. Any other URI value indicates that the collection is ordered, and identifies the semantics of the ordering.
URI“DAV:unordered”表示集合没有排序，而“DAV:custom”表示集合要排序，但排序的语义没有被公布。任何其他URI值都指示集合已排序，并标识排序的语义。
Additional Preconditions:
其他先决条件：
(DAV:ordered-collections-supported): the server MUST support ordered collections in the part of the URL namespace identified by the request URL.
（DAV：支持的有序集合）：服务器必须支持由请求URL标识的URL命名空间部分中的有序集合。
Additional Postconditions:
附加后条件：
(DAV:ordering-type-set): if the Ordering-Type header was present, the request MUST have created a new collection resource with the DAV:ordering-type being set according to the Ordering-Type request header. The collection MUST be ordered unless the ordering type is "DAV:unordered".
（DAV:ordering type set）：如果存在ordering type标头，则请求必须已创建了一个新的集合资源，并且DAV:ordering type是根据ordering type请求标头设置的。除非订购类型为“DAV:无序”，否则必须订购集合。
>> Request:
>>请求：
MKCOL /theNorth/ HTTP/1.1
Host: example.org
Ordering-Type: http://example.org/orderings/compass.html
MKCOL /theNorth/ HTTP/1.1
Host: example.org
Ordering-Type: http://example.org/orderings/compass.html
>> Response:
>>答复：
HTTP/1.1 201 Created
HTTP/1.1201已创建
In this example, a new ordered collection was created. Its DAV:ordering-type property has the URI from the Ordering-Type header as its value http://example.org/orderings/compass.html. In this case, the URI identifies the semantics governing a client-maintained ordering. As new members are added to the collection, clients or end users can use the semantics to determine where to position the new members in the ordering.
在本例中，创建了一个新的有序集合。它的DAV:ordering-type属性将ordering-type头中的URI作为其值http://example.org/orderings/compass.html. 在本例中，URI标识了管理客户机维护的排序的语义。随着新成员添加到集合中，客户机或最终用户可以使用语义来确定新成员在排序中的位置。
When a new member is added to a collection with a client-maintained ordering (for example, with PUT, COPY, or MKCOL), its position in the ordering can be set with the new Position header. The Position header allows the client to specify that an internal member URI should be first in the collection's ordering, last in the collection's ordering, immediately before some other internal member URI in the collection's ordering, or immediately after some other internal member URI in the collection's ordering.
当使用客户端维护的排序（例如，使用PUT、COPY或MKCOL）将新成员添加到集合中时，可以使用新位置标头设置其在排序中的位置。Position标头允许客户端指定内部成员URI应位于集合排序中的第一位、集合排序中的最后一位、集合排序中的其他内部成员URI之前或集合排序中的其他内部成员URI之后。
If the Position request header is not used when adding a member to an ordered collection, then:
如果在向有序集合添加成员时未使用职位请求标头，则：
o If the request is replacing an existing resource, the server MUST preserve the present ordering.
o 如果请求正在替换现有资源，服务器必须保留当前顺序。
o If the request is adding a new internal member URI to the collection, the server MUST append the new member to the end of the ordering.
o 如果请求向集合添加新的内部成员URI，服务器必须将新成员追加到排序的末尾。
Note to implementers: this specification does not mandate a specific implementation of MOVE operations within the same parent collection. Therefore, servers may either implement this as a simple rename operation (preserving the collection member's position), or as a sequence of "remove" and "add" (causing the semantics of "adding a
实现者注意：本规范不要求在同一父集合中实现特定的移动操作。因此，服务器可以将其实现为一个简单的重命名操作（保留集合成员的位置），也可以实现为一个“remove”和“add”序列（产生“adding”的语义）
new member" to apply). Future revisions of this specification may specify this behaviour more precisely based on future implementation experience.
新成员“适用）。本规范的未来版本可能会根据未来的实施经验更精确地规定此行为。
Additional Marshalling:
附加编组：
Position = "Position" ":" ("first" | "last" |
(("before" | "after") segment))
Position = "Position" ":" ("first" | "last" |
(("before" | "after") segment))
segment is defined in Section 3.3 of [RFC2396].
[RFC2396]第3.3节定义了段。
The segment is interpreted relative to the collection to which the new member is being added.
该段相对于要添加新成员的集合进行解释。
When the Position header is present, the server MUST insert the new member into the ordering at the specified location.
当存在位置标头时，服务器必须在指定位置将新成员插入到订单中。
The "first" keyword indicates that the new member is placed in the beginning position in the collection's ordering, while "last" indicates that the new member is placed in the final position in the collection's ordering. The "before" keyword indicates that the new member is added to the collection's ordering immediately prior to the position of the member identified in the segment. Likewise, the "after" keyword indicates that the new member is added to the collection's ordering immediately following the position of the member identified in the segment.
“first”关键字表示新成员在集合排序中处于起始位置，而“last”表示新成员在集合排序中处于最终位置。“before”关键字表示新成员在片段中标识的成员位置之前立即添加到集合的排序中。同样，“after”关键字表示新成员将添加到集合的排序中，紧跟在段中标识的成员的位置之后。
If the request is replacing an existing resource and the Position header is present, the server MUST remove the internal member URI from its current position, and insert it at the newly requested position.
如果请求正在替换现有资源且存在位置标头，则服务器必须从其当前位置删除内部成员URI，并将其插入新请求的位置。
Additional Preconditions:
其他先决条件：
(DAV:collection-must-be-ordered): the target collection MUST be ordered.
（DAV：必须对集合进行排序）：必须对目标集合进行排序。
(DAV:segment-must-identify-member): the referenced segment MUST identify a resource that exists and is different from the affected resource.
（DAV：段必须标识成员）：引用的段必须标识存在的资源，并且与受影响的资源不同。
Additional Postconditions:
附加后条件：
(DAV:position-set): if a Position header is present, the request MUST create the new collection member at the specified position.
（DAV：位置集）：如果存在位置标头，则请求必须在指定位置创建新的集合成员。
>> Request:
>>请求：
COPY /~user/dav/spec08.html HTTP/1.1
Host: example.org
Destination: http://example.org/~slein/dav/spec08.html
Position: after requirements.html
COPY /~user/dav/spec08.html HTTP/1.1
Host: example.org
Destination: http://example.org/~slein/dav/spec08.html
Position: after requirements.html
>> Response:
>>答复：
HTTP/1.1 201 Created
HTTP/1.1201已创建
This request resulted in the creation of a new resource at example.org/~slein/dav/spec08.html. The Position header in this example caused the server to set its position in the ordering of the /~slein/dav/ collection immediately after requirements.html.
此请求导致在example.org/~slein/dav/spec08.html上创建一个新资源。本例中的Position头导致服务器在requirements.html之后立即设置其在/~slein/dav/集合顺序中的位置。
>> Request:
>>请求：
MOVE /i-d/draft-webdav-prot-08.txt HTTP/1.1
Host: example.org
Destination: http://example.org/~user/dav/draft-webdav-prot-08.txt
Position: first
MOVE /i-d/draft-webdav-prot-08.txt HTTP/1.1
Host: example.org
Destination: http://example.org/~user/dav/draft-webdav-prot-08.txt
Position: first
>> Response:
>>答复：
HTTP/1.1 409 Conflict
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 409 Conflict
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:error xmlns:D="DAV:">
<D:collection-must-be-ordered/>
</D:error>
<?xml version="1.0" encoding="utf-8" ?>
<D:error xmlns:D="DAV:">
<D:collection-must-be-ordered/>
</D:error>
In this case, the server returned a 409 (Conflict) status code because the /~user/dav/ collection is an unordered collection. Consequently, the server was unable to satisfy the Position header.
在本例中，服务器返回了409（冲突）状态代码，因为/~user/dav/集合是无序集合。因此，服务器无法满足位置标头。
The following sequence of requests will rename a collection member while preserving its position, independently of how the server implements the MOVE operation:
以下请求序列将重命名集合成员，同时保留其位置，与服务器实现移动操作的方式无关：
1. PROPFIND collection with depth 1, retrieving the DAV:ordering-type property (an interactive client has already likely done this in order to display the collection's content).
1. PROPFIND集合，深度为1，检索DAV:ordering-type属性（交互客户端可能已经这样做了，以便显示集合的内容）。
2. If the DAV:ordering-type property is present and does not equal "dav:unordered" (thus if the collection is ordered), determine the current position (such as "first" or "after x") and setup the Position header accordingly.
2. 如果存在DAV:ordering type属性且该属性不等于“DAV:unordered”（因此，如果集合已排序），则确定当前位置（例如“first”或“after x”），并相应地设置位置标头。
3. Perform the MOVE operation, optionally supplying the Position header computed in the previous step.
3. 执行移动操作，可选地提供在上一步中计算的位置标头。
The ORDERPATCH method is used to change the ordering semantics of a collection, to change the order of the collection's members in the ordering, or both.
ORDERPATCH方法用于更改集合的排序语义，或更改集合成员在排序中的顺序，或同时更改两者。
The server MUST apply the changes in the order they appear in the order XML element. The server MUST either apply all the changes or apply none of them. If any error occurs during processing, all executed changes MUST be undone and a proper error result returned.
服务器必须按照更改在order XML元素中出现的顺序应用更改。服务器必须应用所有更改或不应用任何更改。如果在处理过程中发生任何错误，则必须撤消所有执行的更改，并返回正确的错误结果。
If an ORDERPATCH request changes the ordering semantics, but does not completely specify the order of the collection members, the server MUST assign a position in the ordering to each collection member for which a position was not specified. These server-assigned positions MUST follow the last position specified by the client. The result is that all members for which the client specified a position are at the beginning of the ordering, followed by any members for which the server assigned positions. Note that the ordering of the server-assigned positions is not defined by this document, therefore servers can use whatever rule seems reasonable (for instance, alphabetically or by creation date).
如果ORDERPATCH请求更改了排序语义，但未完全指定集合成员的顺序，则服务器必须为未指定位置的每个集合成员分配排序中的位置。这些服务器分配的位置必须跟随客户端指定的最后一个位置。结果是，客户机为其指定位置的所有成员都位于排序的开头，然后是服务器为其指定位置的任何成员。请注意，本文档未定义服务器分配位置的顺序，因此服务器可以使用任何合理的规则（例如，按字母顺序或创建日期）。
If an ORDERPATCH request does not change the ordering semantics, any member positions not specified in the request MUST remain unchanged.
如果ORDERPATCH请求未更改排序语义，则请求中未指定的任何成员位置必须保持不变。
A request to reposition a collection member to the same place in the ordering is not an error.
将集合成员重新定位到排序中相同位置的请求不是错误。
If an ORDERPATCH request fails, the server state preceding the request MUST be restored.
如果ORDERPATCH请求失败，则必须恢复请求之前的服务器状态。
Additional Marshalling:
附加编组：
The request body MUST be DAV:orderpatch element.
请求正文必须是DAV:orderpatch元素。
<!ELEMENT orderpatch (ordering-type?, order-member*) >
<!ELEMENT orderpatch (ordering-type?, order-member*) >
<!ELEMENT order-member (segment, position) >
<!ELEMENT position (first | last | before | after)>
<!ELEMENT segment (#PCDATA)>
<!ELEMENT first EMPTY >
<!ELEMENT last EMPTY >
<!ELEMENT before segment >
<!ELEMENT after segment >
<!ELEMENT order-member (segment, position) >
<!ELEMENT position (first | last | before | after)>
<!ELEMENT segment (#PCDATA)>
<!ELEMENT first EMPTY >
<!ELEMENT last EMPTY >
<!ELEMENT before segment >
<!ELEMENT after segment >
PCDATA value: segment, as defined in section 3.3 of [RFC2396].
PCDATA值：段，如[RFC2396]第3.3节所定义。
The DAV:ordering-type property is modified according to the DAV:ordering-type element.
将根据DAV:ordering-type元素修改DAV:ordering-type属性。
The ordering of internal member URIs in the collection identified by the Request-URI is changed based on instructions in the order-member XML elements. Specifically, in the order that they appear in the request. The order-member XML elements identify the internal member URIs whose positions are to be changed, and describe their new positions in the ordering. Each new position can be specified as first in the ordering, last in the ordering, immediately before some other internal member URI, or immediately after some other internal member URI.
由请求URI标识的集合中内部成员URI的顺序将根据order成员XML元素中的说明进行更改。具体来说，按照它们在请求中出现的顺序。order成员XML元素标识要更改位置的内部成员URI，并描述它们在排序中的新位置。可以将每个新位置指定为排序中的第一个位置、排序中的最后一个位置、紧跟在其他内部成员URI之前或紧跟在其他内部成员URI之后。
If a response body for a successful request is included, it MUST be a DAV:orderpatch-response XML element. Note that this document does not define any elements for the ORDERPATCH response body, but the DAV:orderpatch-response element is defined to ensure interoperability between future extensions that do define elements for the ORDERPATCH response body.
如果包含成功请求的响应主体，则它必须是DAV:orderpatch响应XML元素。请注意，本文档没有为ORDERPATCH响应主体定义任何元素，但定义了DAV:ORDERPATCH响应元素以确保将来的扩展之间的互操作性，这些扩展确实为ORDERPATCH响应主体定义了元素。
<!ELEMENT orderpatch-response ANY>
<!ELEMENT orderpatch-response ANY>
Since multiple changes can be requested in a single ORDERPATCH request, the server MUST return a 207 (Multi-Status) response (defined in [RFC2518]), containing DAV:response elements for either the request-URI (when the DAV:ordering-type could not be modified) or URIs of collection members to be repositioned (when an individual positioning request expressed as DAV:order-member could not be fulfilled) if any problems are encountered.
由于可以在单个ORDERPATCH请求中请求多个更改，服务器必须返回207（多状态）响应（在[RFC2518]中定义），其中包含请求URI（无法修改DAV:ordering类型时）或要重新定位的集合成员URI的DAV:response元素（当单个定位请求表示为DAV:订单成员无法满足时）如果遇到任何问题。
Preconditions:
先决条件：
(DAV:collection-must-be-ordered): see Section 6.1.
（DAV：必须订购托收）：见第6.1节。
(DAV:segment-must-identify-member): see Section 6.1.
（DAV：段必须识别成员）：见第6.1节。
Postconditions:
后条件：
(DAV:ordering-type-set): if the request body contained a DAV:ordering-type element, the request MUST have set the DAV:ordering-type property of the collection to the value specified in the request.
（DAV:ordering type set）：如果请求正文包含DAV:ordering type元素，则请求必须已将集合的DAV:ordering type属性设置为请求中指定的值。
(DAV:ordering-modified): if the request body contained DAV:order-member elements, the request MUST have set the ordering of internal member URIs in the collection identified by the request-URI based upon the instructions in the DAV:order-member elements.
（DAV:ordering-modified）：如果请求主体包含DAV:order成员元素，则请求必须根据DAV:order成员元素中的说明设置由请求URI标识的集合中内部成员URI的顺序。
Consider an ordered collection /coll-1, with bindings ordered as follows:
考虑有序集合/COL-1，其绑定顺序如下：
three.html four.html one.html two.html
three.html four.html one.html two.html
>> Request:
>>请求：
ORDERPATCH /coll-1/ HTTP/1.1
Host: example.org
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
ORDERPATCH /coll-1/ HTTP/1.1
Host: example.org
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<?xml version="1.0" ?>
<d:orderpatch xmlns:d="DAV:">
<d:ordering-type>
<d:href>http://example.org/inorder.ord</d:href>
</d:ordering-type>
<d:order-member>
<d:segment>two.html</d:segment>
<d:position><d:first/></d:position>
</d:order-member>
<d:order-member>
<d:segment>one.html</d:segment>
<d:position><d:first/></d:position>
</d:order-member>
<?xml version="1.0" ?>
<d:orderpatch xmlns:d="DAV:">
<d:ordering-type>
<d:href>http://example.org/inorder.ord</d:href>
</d:ordering-type>
<d:order-member>
<d:segment>two.html</d:segment>
<d:position><d:first/></d:position>
</d:order-member>
<d:order-member>
<d:segment>one.html</d:segment>
<d:position><d:first/></d:position>
</d:order-member>
<d:order-member>
<d:segment>three.html</d:segment>
<d:position><d:last/></d:position>
</d:order-member>
<d:order-member>
<d:segment>four.html</d:segment>
<d:position><d:last/></d:position>
</d:order-member>
</d:orderpatch>
<d:order-member>
<d:segment>three.html</d:segment>
<d:position><d:last/></d:position>
</d:order-member>
<d:order-member>
<d:segment>four.html</d:segment>
<d:position><d:last/></d:position>
</d:order-member>
</d:orderpatch>
>> Response:
>>答复：
HTTP/1.1 200 OK
HTTP/1.1200ok
In this example, after the request has been processed, the collection's ordering semantics are identified by the URI http:// example.org/inorder.ord. The value of the collection's DAV:ordering-type property has been set to this URI. The request also contains instructions for changing the positions of the collection's internal member URIs in the ordering to comply with the new ordering semantics. As the DAV:order-member elements are required to be processed in the order they appear in the request, two.html is moved to the beginning of the ordering, and then one.html is moved to the beginning of the ordering. Then three.html is moved to the end of the ordering, and finally four.html is moved to the end of the ordering. After the request has been processed, the collection's ordering is as follows:
在本例中，在处理请求后，集合的排序语义由URI http://example.org/inorder.ord标识。集合的DAV:ordering-type属性的值已设置为此URI。该请求还包含更改集合的内部成员URI在排序中的位置以符合新的排序语义的说明。由于DAV:order成员元素需要按照它们在请求中出现的顺序进行处理，因此将two.html移到ordering的开头，然后将one.html移到ordering的开头。然后将three.html移到排序的末尾，最后将four.html移到排序的末尾。处理请求后，集合的顺序如下所示：
one.html two.html three.html four.html
one.html two.html three.html four.html
Consider a collection /coll-1/ with members ordered as follows:
考虑一个集合/COL-1，成员按如下顺序排序：
nunavut.map nunavut.img baffin.map baffin.desc baffin.img iqaluit.map nunavut.desc iqaluit.img iqaluit.desc
nunavut.map nunavut.img baffin.map baffin.desc baffin.img iqaluit.map nunavut.desc iqaluit.img iqaluit.desc
>> Request:
>>请求：
ORDERPATCH /coll-1/ HTTP/1.1
Host: www.nunanet.com
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
ORDERPATCH /coll-1/ HTTP/1.1
Host: www.nunanet.com
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<?xml version="1.0" ?>
<d:orderpatch xmlns:d="DAV:">
<d:order-member>
<d:segment>nunavut.desc</d:segment>
<d:position>
<d:after>
<d:segment>nunavut.map</d:segment>
</d:after>
</d:position>
</d:order-member>
<d:order-member>
<d:segment>iqaluit.map</d:segment>
<d:position>
<d:after>
<d:segment>pangnirtung.img</d:segment>
</d:after>
</d:position>
</d:order-member>
</d:orderpatch>
<?xml version="1.0" ?>
<d:orderpatch xmlns:d="DAV:">
<d:order-member>
<d:segment>nunavut.desc</d:segment>
<d:position>
<d:after>
<d:segment>nunavut.map</d:segment>
</d:after>
</d:position>
</d:order-member>
<d:order-member>
<d:segment>iqaluit.map</d:segment>
<d:position>
<d:after>
<d:segment>pangnirtung.img</d:segment>
</d:after>
</d:position>
</d:order-member>
</d:orderpatch>
>> Response:
>>答复：
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<?xml version="1.0" ?>
<d:multistatus xmlns:d="DAV:">
<d:response>
<d:href>http://www.nunanet.com/coll-1/iqaluit.map</d:href>
<d:status>HTTP/1.1 403 Forbidden</d:status>
<d:responsedescription>
<d:error><d:segment-must-identify-member/></d:error>
pangnirtung.img is not a collection member.
</d:responsedescription>
</d:response>
</d:multistatus>
<?xml version="1.0" ?>
<d:multistatus xmlns:d="DAV:">
<d:response>
<d:href>http://www.nunanet.com/coll-1/iqaluit.map</d:href>
<d:status>HTTP/1.1 403 Forbidden</d:status>
<d:responsedescription>
<d:error><d:segment-must-identify-member/></d:error>
pangnirtung.img is not a collection member.
</d:responsedescription>
</d:response>
</d:multistatus>
In this example, the client attempted to position iqaluit.map after a URI that is not an internal member of the collection /coll-1/. The server responded to this client error with a 403 (Forbidden) status code, indicating the failed precondition DAV:segment-must-identify-member. Because ORDERPATCH is an atomic method, the request to reposition nunavut.desc (which would otherwise have succeeded) failed as well, but does not need to be expressed in the multistatus response body.
在本例中，客户端试图将iqaluit.map定位在不是集合/coll-1/内部成员的URI之后。服务器以403（禁止）状态代码响应此客户端错误，指示失败的前提条件DAV:段必须标识成员。由于ORDERPATCH是一种原子方法，因此重新定位nunavut.desc（否则会成功）的请求也会失败，但不需要在multistatus响应主体中表示。
A PROPFIND request is used to retrieve a listing of the members of an ordered collection, just as it is used to retrieve a listing of the members of an unordered collection.
PROPFIND请求用于检索有序集合的成员列表，就像它用于检索无序集合的成员列表一样。
However, when responding to a PROPFIND on an ordered collection, the server MUST order the response elements according to the ordering defined on the collection. If a collection is unordered, the client cannot depend on the repeatability of the ordering of results from a PROPFIND request.
但是，当响应有序集合上的PROPFIND时，服务器必须根据集合上定义的顺序对响应元素进行排序。如果集合未排序，则客户端无法依赖PROPFIND请求结果排序的可重复性。
In a response to a PROPFIND with Depth: infinity, members of different collections may be interleaved. That is, the server is not required to do a breadth-first traversal. The only requirement is that the members of any ordered collection appear in the order defined for that collection. Thus, for the hierarchy illustrated in the following figure, where collection A is an ordered collection with the ordering B C D,
作为对PROPFIND with Depth:infinity的响应，不同集合的成员可能会交错。也就是说，服务器不需要进行广度优先遍历。唯一的要求是，任何有序集合的成员都必须按照为该集合定义的顺序出现。因此，对于下图所示的层次结构，其中集合A是具有排序B C D的有序集合，
A
/|\
/ | \
B C D
/ /|\
E F G H
A
/|\
/ | \
B C D
/ /|\
E F G H
it would be acceptable for the server to return response elements in the order A B E C F G H D or "A B E C H G F D" as well (if C is unordered). In this response, B, C, and D appear in the correct order, separated by members of other collections. Clients can use a series of Depth: 1 PROPFIND requests to avoid the complexity of processing Depth: infinity responses based on depth-first traversals.
服务器返回响应元素的顺序也可以是abecfghd或“abechgfd”（如果C是无序的）。在这个响应中，B、C和D以正确的顺序出现，由其他集合的成员分隔。客户机可以使用一系列深度：1 PROPFIND请求来避免处理基于深度优先遍历的深度：无限响应的复杂性。
Suppose a PROPFIND request is submitted to /MyColl/, which has its members ordered as follows.
假设一个PROPFIND请求提交到/MyColl/，其成员顺序如下。
/MyColl/ lakehazen.html siorapaluk.html iqaluit.html newyork.html
/MyColl/lakehazen.html siorapaluk.html iqaluit.html newyork.html
>> Request:
>>请求：
PROPFIND /MyColl/ HTTP/1.1
PROPFIND /MyColl/ HTTP/1.1
Host: example.org
Depth: 1
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Host: example.org
Depth: 1
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" ?>
<D:propfind xmlns:D="DAV:">
<D:prop xmlns:J="http://example.org/jsprops/">
<D:ordering-type/>
<D:resourcetype/>
<J:latitude/>
</D:prop>
</D:propfind>
<?xml version="1.0" ?>
<D:propfind xmlns:D="DAV:">
<D:prop xmlns:J="http://example.org/jsprops/">
<D:ordering-type/>
<D:resourcetype/>
<J:latitude/>
</D:prop>
</D:propfind>
>> Response:
>>答复：
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" ?>
<D:multistatus xmlns:D="DAV:"
xmlns:J="http://example.org/jsprops/">
<D:response>
<D:href>http://example.org/MyColl/</D:href>
<D:propstat>
<D:prop>
<D:ordering-type>
<D:href>DAV:custom</D:href>
</D:ordering-type>
<D:resourcetype><D:collection/></D:resourcetype>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
<?xml version="1.0" ?>
<D:multistatus xmlns:D="DAV:"
xmlns:J="http://example.org/jsprops/">
<D:response>
<D:href>http://example.org/MyColl/</D:href>
<D:propstat>
<D:prop>
<D:ordering-type>
<D:href>DAV:custom</D:href>
</D:ordering-type>
<D:resourcetype><D:collection/></D:resourcetype>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop>
<J:latitude/>
</D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://example.org/MyColl/lakehazen.html</D:href>
<D:propstat>
<D:prop>
<D:resourcetype/>
<J:latitude>82N</J:latitude>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop>
<D:ordering-type/>
</D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href
>http://example.org/MyColl/siorapaluk.html</D:href>
<D:propstat>
<D:prop>
<D:resourcetype/>
<J:latitude>78N</J:latitude>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop>
<D:ordering-type/>
</D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://example.org/MyColl/iqaluit.html</D:href>
<D:propstat>
<D:prop>
<D:resourcetype/>
<J:latitude>62N</J:latitude>
</D:prop>
</D:propstat>
<D:propstat>
<D:prop>
<J:latitude/>
</D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://example.org/MyColl/lakehazen.html</D:href>
<D:propstat>
<D:prop>
<D:resourcetype/>
<J:latitude>82N</J:latitude>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop>
<D:ordering-type/>
</D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href
>http://example.org/MyColl/siorapaluk.html</D:href>
<D:propstat>
<D:prop>
<D:resourcetype/>
<J:latitude>78N</J:latitude>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop>
<D:ordering-type/>
</D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://example.org/MyColl/iqaluit.html</D:href>
<D:propstat>
<D:prop>
<D:resourcetype/>
<J:latitude>62N</J:latitude>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop>
<D:ordering-type/>
</D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://example.org/MyColl/newyork.html</D:href>
<D:propstat>
<D:prop>
<D:resourcetype/>
<J:latitude>45N</J:latitude>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
<D:propstat>
<D:prop>
<D:ordering-type/>
</D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat>
</D:propstat>
</D:response>
</D:multistatus>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop>
<D:ordering-type/>
</D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://example.org/MyColl/newyork.html</D:href>
<D:propstat>
<D:prop>
<D:resourcetype/>
<J:latitude>45N</J:latitude>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
<D:propstat>
<D:prop>
<D:ordering-type/>
</D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat>
</D:propstat>
</D:response>
</D:multistatus>
In this example, the server responded with a list of the collection members in the order defined for the collection.
在本例中，服务器按照为集合定义的顺序响应集合成员列表。
The Versioning Extensions to WebDAV [RFC3253] introduce the concept of versioned collections, recording both the dead properties and the set of internal version-controlled bindings. This section defines how this feature interacts with ordered collections.
WebDAV的版本控制扩展[RFC3253]引入了版本化集合的概念，记录了失效属性和内部版本控制绑定集。本节定义此功能如何与有序集合交互。
This specification considers both the ordering type (DAV:ordering-type property) and the ordering of collection members to be part of the state of a collection. Therefore, both MUST be recorded upon CHECKIN or VERSION-CONTROL, and both MUST be restored upon CHECKOUT, UNCHECKOUT or UPDATE (where for compatibility with RFC 3253, only the ordering of version-controlled members needs to be maintained).
本规范将排序类型（DAV:ordering type属性）和集合成员的排序都视为集合状态的一部分。因此，两者都必须在签入或版本控制时记录，并且都必须在签出、取消选中或更新时恢复（为了与RFC 3253兼容，只需要维护版本控制成员的顺序）。
9.1.1. Additional semantics for DAV:version-controlled-binding-set (protected)
9.1.1. DAV的附加语义：版本控制绑定集（受保护）
For ordered collections, the DAV:version-controlled-binding elements MUST appear in the ordering defined for the checked-in ordered collection.
对于有序集合，DAV:version-controlled绑定元素必须出现在为签入的有序集合定义的顺序中。
The DAV:ordering-type property records the DAV:ordering-type property of the checked-in ordered collection.
DAV:ordering-type属性记录签入的有序集合的DAV:ordering-type属性。
Additional Postconditions:
附加后条件：
(DAV:initialize-version-controlled-bindings-ordered): If the request-URL identified a both ordered and version-controlled collection, then the child elements of DAV:version-controlled-binding-set of the new collection version MUST appear in the ordering defined for that collection.
（DAV:初始化已排序的版本控制绑定）：如果请求URL同时标识了已排序和版本控制的集合，则新集合版本的DAV:版本控制绑定集的子元素必须显示在为该集合定义的顺序中。
(DAV:initialize-collection-version-ordering-type): If the request-URL identified a both ordered and version-controlled collection, then the DAV:ordering-type property of the new collection version MUST be a copy of the collection's DAV:ordering-type property.
（DAV:initialize collection version ordering type）：如果请求URL同时标识了已排序和版本控制的集合，则新集合版本的DAV:ordering type属性必须是集合的DAV:ordering type属性的副本。
Additional Postconditions:
附加后条件：
(DAV:initialize-version-history-bindings-ordered): If the request has been applied to a collection version with a DAV:ordering-type other than "DAV:unordered", the bindings in the new working collection MUST be ordered according to the collection version's DAV:version-controlled-binding-set property.
（DAV:initialize version history bindings ordered）：如果请求已应用于DAV:ordering类型不是“DAV:unordered”的集合版本，则新工作集合中的绑定必须根据集合版本的DAV:version controlled binding set属性进行排序。
(DAV:initialize-ordering-type): If the request has been applied to a collection version, the DAV:ordering-type property of the new working collection MUST be initialized from the collection version's DAV:ordering-type property.
（DAV:初始化排序类型）：如果请求已应用于集合版本，则必须从集合版本的DAV:排序类型属性初始化新工作集合的DAV:排序类型属性。
Additional Postconditions:
附加后条件：
(DAV:update-version-controlled-collection-members-ordered): If the request modified the DAV:checked-in version of a version-controlled collection and the DAV:ordering-type for the checked-in version is not unordered ("DAV:unordered"), the version-controlled members MUST be ordered according to the checked-in version's DAV:version-controlled-binding-set property. The ordering of non-version-controlled members is server-defined.
（DAV:已订购的更新版本控制集合成员）：如果请求修改了版本控制集合的DAV:签入版本，并且签入版本的DAV:订购类型不是无序的（“DAV:无序”），受版本控制的成员必须根据签入版本的DAV:version-controlled绑定集属性进行排序。非版本控制成员的顺序由服务器定义。
(DAV:update-version-ordering-type): If the request modified the DAV:checked-in version of a version-controlled collection, the DAV:ordering-type property MUST be updated from the checked-in version's property.
（DAV:更新版本排序类型）：如果请求修改了版本控制集合的DAV:签入版本，则必须从签入版本的属性更新DAV:排序类型属性。
Sections 9.1 and 15 of [RFC2518] describe the use of compliance classes with the DAV header in responses to OPTIONS, indicating which parts of the Web Distributed Authoring protocols the resource supports. This specification defines an OPTIONAL extension to [RFC2518]. It defines a new compliance class, called ordered-collections, for use with the DAV header in responses to OPTIONS requests. If a collection resource does support ordering, its response to an OPTIONS request may indicate that it does, by listing the new ORDERPATCH method as one it supports, and by listing the new ordered-collections compliance class in the DAV header.
[RFC2518]的第9.1节和第15节描述了在响应选项时使用符合性类和DAV头，指出了资源支持的Web分布式创作协议的哪些部分。本规范定义了[RFC2518]的可选扩展。它定义了一个新的符合性类，称为ordered collections，用于DAV头以响应选项请求。如果集合资源确实支持排序，则它对选项请求的响应可能表明它支持排序，方法是将新的ORDERPATCH方法列为它支持的方法，并在DAV标头中列出新的ordered collections compliance类。
When responding to an OPTIONS request, only a collection or a null resource can include ordered-collections in the value of the DAV header. By including ordered-collections, the resource indicates that its internal member URIs can be ordered. It implies nothing about whether any collections identified by its internal member URIs can be ordered.
响应选项请求时，只有集合或空资源才能在DAV标头的值中包含有序集合。通过包含已排序的集合，资源指示其内部成员URI可以排序。它并不意味着是否可以对其内部成员URI标识的任何集合进行排序。
Furthermore, RFC 3253 [RFC3253] introduces the live properties DAV:supported-method-set (section 3.1.3) and DAV:supported-live-property-set (section 3.1.4). Servers MUST support these properties as defined in RFC 3253.
此外，RFC 3253[RFC3253]介绍了活动属性DAV:支持的方法集（第3.1.3节）和DAV:支持的活动属性集（第3.1.4节）。服务器必须支持RFC 3253中定义的这些属性。
10.1. Example: Using OPTIONS for the Discovery of Support for Ordering
10.1. 示例：使用选项查找对订购的支持
>> Request:
>>请求：
OPTIONS /somecollection/ HTTP/1.1
Host: example.org
OPTIONS /somecollection/ HTTP/1.1
Host: example.org
>> Response:
>>答复：
HTTP/1.1 200 OK Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, ORDERPATCH DAV: 1, 2, ordered-collections
HTTP/1.1 200确定允许：选项、获取、头、发布、放置、删除、跟踪、复制、移动允许：MKCOL、PROPFIND、PROPPATCH、锁定、解锁、ORDERPATCH DAV:1、2、有序集合
The DAV header in the response indicates that the resource /somecollection/ is level 1 and level 2 compliant, as defined in [RFC2518]. In addition, /somecollection/ supports ordering. The Allow header indicates that ORDERPATCH requests can be submitted to /somecollection/.
响应中的DAV标头表示资源/somecollection/符合[RFC2518]中定义的级别1和级别2。此外，/somecollection/支持订购。Allow标头指示ORDERPATCH请求可以提交到/somecollection/。
>> Request:
PROPFIND /somecollection HTTP/1.1
Depth: 0
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
>> Request:
PROPFIND /somecollection HTTP/1.1
Depth: 0
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<?xml version="1.0" encoding="UTF-8" ?>
<propfind xmlns="DAV:">
<prop>
<supported-live-property-set/>
<supported-method-set/>
</prop>
</propfind>
<?xml version="1.0" encoding="UTF-8" ?>
<propfind xmlns="DAV:">
<prop>
<supported-live-property-set/>
<supported-method-set/>
</prop>
</propfind>
>> Response:
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
>> Response:
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<?xml version="1.0" encoding="utf-8" ?>
<multistatus xmlns="DAV:">
<response>
<href>http://example.org/somecollection</href>
<propstat>
<prop>
<?xml version="1.0" encoding="utf-8" ?>
<multistatus xmlns="DAV:">
<response>
<href>http://example.org/somecollection</href>
<propstat>
<prop>
<supported-live-property-set>
<supported-live-property>
<prop><ordering-type/></prop>
</supported-live-property>
<!-- ... other live properties omitted for brevity ... -->
</supported-live-property-set>
<supported-method-set>
<supported-method name="COPY" />
<supported-method name="DELETE" />
<supported-method name="GET" />
<supported-method name="HEAD" />
<supported-method name="LOCK" />
<supported-method name="MKCOL" />
<supported-method name="MOVE" />
<supported-method name="OPTIONS" />
<supported-method name="ORDERPATCH" />
<supported-method name="POST" />
<supported-method name="PROPFIND" />
<supported-method name="PROPPATCH" />
<supported-method name="PUT" />
<supported-method name="TRACE" />
<supported-method name="UNLOCK" />
</supported-method-set>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
</multistatus>
<supported-live-property-set>
<supported-live-property>
<prop><ordering-type/></prop>
</supported-live-property>
<!-- ... other live properties omitted for brevity ... -->
</supported-live-property-set>
<supported-method-set>
<supported-method name="COPY" />
<supported-method name="DELETE" />
<supported-method name="GET" />
<supported-method name="HEAD" />
<supported-method name="LOCK" />
<supported-method name="MKCOL" />
<supported-method name="MOVE" />
<supported-method name="OPTIONS" />
<supported-method name="ORDERPATCH" />
<supported-method name="POST" />
<supported-method name="PROPFIND" />
<supported-method name="PROPPATCH" />
<supported-method name="PUT" />
<supported-method name="TRACE" />
<supported-method name="UNLOCK" />
</supported-method-set>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
</multistatus>
Note that actual responses MUST contain a complete list of supported live properties.
请注意，实际响应必须包含受支持的活动属性的完整列表。
This section is provided to make WebDAV implementers aware of the security implications of this protocol.
本节旨在使WebDAV实现者了解此协议的安全含义。
All of the security considerations of HTTP/1.1 and the WebDAV Distributed Authoring Protocol specification also apply to this protocol specification. In addition, ordered collections introduce a new security concern. This issue is detailed here.
HTTP/1.1和WebDAV分布式创作协议规范的所有安全注意事项也适用于本协议规范。此外，有序集合引入了一个新的安全问题。这个问题在这里详述。
There may be some risk of denial of service at sites that are advertised in the DAV:ordering-type property of collections. However, it is anticipated that widely-deployed applications will use hard-coded values for frequently-used ordering semantics rather than
在集合的DAV:ordering type属性中公布的站点上可能存在拒绝服务的风险。然而，预计广泛部署的应用程序将使用硬编码值来实现频繁使用的排序语义，而不是
looking up the semantics at the location specified by DAV:ordering-type. This risk will be further reduced if clients observe the recommendation of Section 5.1 that requests not be sent to the URI in DAV:ordering-type.
在DAV:ordering-type指定的位置查找语义。如果客户遵守第5.1节中的建议，即请求不发送到DAV:ordering type中的URI，则此风险将进一步降低。
This specification follows the practices of [RFC2518] by encoding all human-readable content using [XML] and in the treatment of names. Consequently, this specification complies with the IETF Character Set Policy [RFC2277].
本规范遵循[RFC2518]的做法，使用[XML]对所有人类可读内容进行编码，并对名称进行处理。因此，本规范符合IETF字符集策略[RFC2277]。
WebDAV applications MUST support the character set tagging, character set encoding, and the language tagging functionality of the XML specification. This constraint ensures that the human-readable content of this specification complies with [RFC2277].
WebDAV应用程序必须支持XML规范的字符集标记、字符集编码和语言标记功能。该约束确保本规范的人类可读内容符合[RFC2277]。
As in [RFC2518], names in this specification fall into three categories: names of protocol elements such as methods and headers, names of XML elements, and names of properties. The naming of protocol elements follows the precedent of HTTP using English names encoded in USASCII for methods and headers. The names of XML elements used in this specification are English names encoded in UTF-8.
与[RFC2518]一样，本规范中的名称分为三类：协议元素（如方法和头）的名称、XML元素的名称和属性的名称。协议元素的命名遵循HTTP使用USASCII编码的英文名称作为方法和头的先例。本规范中使用的XML元素名称是以UTF-8编码的英文名称。
For error reporting, [RFC2518] follows the convention of HTTP/1.1 status codes, including with each status code a short, English description of the code (e.g., 423 Locked). Internationalized applications will ignore this message, and display an appropriate message in the user's language and character set.
对于错误报告，[RFC2518]遵循HTTP/1.1状态代码的约定，包括每个状态代码的简短英文描述（例如，423锁定）。国际化应用程序将忽略此消息，并以用户的语言和字符集显示适当的消息。
This specification introduces no new strings that are displayed to users as part of normal, error-free operation of the protocol.
本规范不引入作为协议正常、无错误操作的一部分向用户显示的新字符串。
For the rationale of these decisions and advice for application implementers, see [RFC2518].
有关这些决策的基本原理和对应用程序实施者的建议，请参见[RFC2518]。
This document uses the namespaces defined by [RFC2518] for properties and XML elements. All other IANA considerations mentioned in [RFC2518] also apply to this document.
本文档使用[RFC2518]为属性和XML元素定义的名称空间。[RFC2518]中提到的所有其他IANA注意事项也适用于本文件。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
This document has benefited from significant contributions from Geoff Clemm, Jason Crawford, Jim Davis, Chuck Fay and Judith Slein.
本文件得益于Geoff Clemm、Jason Crawford、Jim Davis、Chuck Fay和Judith Slein的重要贡献。
This document has benefited from thoughtful discussion by Jim Amsden, Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen, Bruce Cragun, Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, Lisa Dusseault, Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, Daniel LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John Stracke, John Tigue, John Turner, Kevin Wiggen, and others.
本文件得益于吉姆·阿姆斯登、史蒂夫·卡特、泰森·奇哈亚、肯·科尔、埃利斯·科恩、布鲁斯·克拉贡、斯宾塞·道金斯、马克·戴、拉吉夫·杜莱佩、大卫·杜兰德、丽莎·杜肖奥、罗伊·菲尔丁、亚龙·戈兰、弗雷德·希特、亚历克斯·霍普曼、马库斯·贾格尔、克里斯·卡勒、马诺·卡西切努拉、罗伊特·哈雷、丹尼尔·拉利伯特、，Steve Martin、Larry Masinter、Jeff McAffer、Surendra Koduru Reddy、Max Rible、Sam Ruby、Bradley中士、Nick Shelness、John Stracke、John Tigue、John Turner、Kevin Wiggen和其他人。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277]Alvestrand，H.，“IETF字符集和语言政策”，BCP 18，RFC 2277，1998年1月。
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2396]Berners Lee，T.，Fielding，R.和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999.
[RFC2518]Goland，Y.，Whitehead，E.，Faizi，A.，Carter，S.和D.Jensen，“分布式创作的HTTP扩展——WEBDAV”，RFC25181999年2月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J. Whitehead, "Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)", RFC 3253, March 2002.
[RFC3253]Clemm，G.，Amsden，J.，Ellison，T.，Kaler，C.和J.Whitehead，“WebDAV的版本控制扩展（Web分布式创作和版本控制）”，RFC 3253，2002年3月。
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>.
[XML]Bray，T.，Paoli，J.，Sperberg McQueen，C.和E.Maler，“可扩展标记语言（XML）1.0（第二版）”，W3C REC XML，2000年10月<http://www.w3.org/TR/2000/REC-xml-20001006>.
<!ELEMENT orderpatch (ordering-type?, order-member*) >
<!ELEMENT order-member (segment, position) >
<!ELEMENT ordering-type (href) >
<!ELEMENT position (first | last | before | after)>
<!ELEMENT first EMPTY >
<!ELEMENT last EMPTY >
<!ELEMENT before segment >
<!ELEMENT after segment >
<!ELEMENT segment (#PCDATA)>
<!ELEMENT orderpatch (ordering-type?, order-member*) >
<!ELEMENT order-member (segment, position) >
<!ELEMENT ordering-type (href) >
<!ELEMENT position (first | last | before | after)>
<!ELEMENT first EMPTY >
<!ELEMENT last EMPTY >
<!ELEMENT before segment >
<!ELEMENT after segment >
<!ELEMENT segment (#PCDATA)>
Index
指数
C Client-Maintained Ordering 4 Condition Names DAV:collection-must-be-ordered (pre) 9 DAV:initialize-collection-version-ordering-type (post) 20 DAV:initialize-ordering-type (post) 21 DAV:initialize-version-controlled-bindings-ordered (post) 20 DAV:initialize-version-history-bindings-ordered (post) 20 DAV:ordered-collections-supported (pre) 7 DAV:ordering-modified (post) 13 DAV:ordering-type-set (post) 7, 13 DAV:position-set (post) 9 DAV:segment-must-identify-member (pre) 9 DAV:update-version-controlled-collection-members-ordered (post) 21 DAV:update-version-ordering-type (post) 21
C客户端维护的排序4个条件名称DAV:必须对集合进行排序（前）9 DAV:初始化集合版本排序类型（后）20 DAV:初始化排序类型（后）21 DAV:初始化受版本控制的已排序绑定（后）20 DAV:初始化已排序的版本历史绑定（后）20 DAV:支持的已排序集合（前）7 DAV:订购修改（post）13 DAV:订购类型集（post）7，13 DAV:位置集（post）9 DAV:段必须标识成员（前）9 DAV:更新版本受控集合成员订购（post）21 DAV:更新版本订购类型（post）21
D DAV header compliance class 'ordered-collections' 21 DAV:collection-must-be-ordered precondition 9 DAV:custom ordering type 6 DAV:initialize-collection-version-ordering-type postcondition 20 DAV:initialize-ordering-type postcondition 21 DAV:initialize-version-controlled-bindings-ordered postcondition 20 DAV:initialize-version-history-bindings-ordered postcondition 20 DAV:ordered-collections-supported precondition 7 DAV:ordering-modified postcondition 13 DAV:ordering-type property 6 DAV:ordering-type-set postcondition 7, 13 DAV:position-set postcondition 9 DAV:segment-must-identify-member precondition 9 DAV:unordered ordering type 6
D DAV标头符合性类“已订购的集合”21 DAV:必须订购集合前提条件9 DAV:自定义订购类型6 DAV:初始化集合版本订购类型后条件20 DAV:初始化订购类型后条件21 DAV:初始化版本控制的绑定后条件20DAV:初始化版本历史绑定已排序后条件20 DAV:已排序集合支持的先决条件7 DAV:排序修改后条件13 DAV:排序类型属性6 DAV:排序类型集后条件7，13 DAV:位置集后条件9 DAV:段必须标识成员先决条件9 DAV:无序排序类型6
DAV:update-version-controlled-collection-members-ordered postcondition 21 DAV:update-version-ordering-type postcondition 21
DAV:更新版本受控集合成员在条件21后订购DAV:更新版本订购类型在条件21后订购
H Headers Ordering-Type 7 Position 9
H集管订购类型7位置9
M Methods ORDERPATCH 11
M方法ORDERPATCH 11
O Ordered Collection 4 Ordering Semantics 5 Ordering-Type header 7 ORDERPATCH method 11
O有序集合4有序语义5有序类型标题7有序补丁方法11
P Position header 9 Properties DAV:ordering-type 6
P位置标题9属性DAV：订购类型6
S Server-Maintained Ordering 5
S服务器维持订购5
U Unordered Collection 4
U无序收藏4
Authors' Addresses
作者地址
Jim Whitehead UC Santa Cruz, Dept. of Computer Science 1156 High Street Santa Cruz, CA 95064 US
吉姆·怀特黑德加州大学圣克鲁斯分校，计算机科学系，美国加利福尼亚州圣克鲁斯高街1156号，邮编95064
EMail: ejw@cse.ucsc.edu
EMail: ejw@cse.ucsc.edu
Julian F. Reschke, Ed. greenbytes GmbH Salzmannstrasse 152 Muenster, NW 48159 Germany
Julian F.Reschke，Ed.greenbytes GmbH Salzmannstrase 152 Muenster，西北48159德国
Phone: +49 251 2807760
Fax: +49 251 2807761
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/
Phone: +49 251 2807760
Fax: +49 251 2807761
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。