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
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
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.
この文書自体がHTTP / 1.1プロトコルの拡張であり、オーサリングプロトコル[RFC2518]分散のWebDAVへの拡張のセットを記述するのでHTTPのセクション2.1に記載されているように、拡張BNFは、プロトコル要素を記述するためにここで使用される正確に同じです[RFC2616]。この増補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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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の断片を使用しています。 WebDAVの要求と応答体が原因[RFC2518]のセクション23で定義された特定の拡張ルールに起因し、この仕様で定義されたすべてのXML要素は、XML名前空間名「DAV：」を使用しているという事実に検証することはできません。特に：
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]でということになります。用語リソースの定義は、ユニフォームリソース識別子（URI）、およびユニフォームリソースロケータ（URL）は、[RFC2396]に提供されます。
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で指定された構造に特異的に言及します。順序型：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 internal members. The server MUST add an internal member URI to the ordering when it is added to the collection.
コレクションを注文された場合、その内部のメンバーURIのそれぞれは、正確に一度の順序で現れなければならない、と順序は、コレクションの内部メンバーではない任意のURIを含んではいけません。サーバーは順序でこれらの制約を強制する責任です。サーバーは、それがコレクションから削除された順序から内部メンバーURIを削除する必要があります。内部メンバーを削除すると、残りの内部メンバーの順序に影響してはいけません。サーバーは、それがコレクションに追加された順序に内部メンバー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：発注型プロパティには、コレクションは注文して、そうならば、一意の順序のセマンティクスを識別しているかどうかを示します。それはまた、ヒトおよび/または機械可読形式で意味の説明を指すことがあります。最低でも、これはコレクションにメンバーを追加し、人間のユーザーがどこの順序でそれらを配置するために理解することができます。このプロパティは、PROPPATCHを使用して設定することはできません。その値のみMKCOL要求に注文-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で識別されます。以下の2つのURIは、事前定義されています。
DAV:custom: The value DAV:custom indicates that the collection is ordered, but the semantics governing the ordering are not being advertised.
DAV：カスタム：値DAV：カスタムコレクションが順序付けられていることを示しているが、順序を管理する意味が宣伝されていません。
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：順不同：値DAV：順不同のコレクションを注文されていないことを示しています。つまり、クライアントは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を持っていない場合、発注非対応サーバとの対話の順序を意識したクライアントは、（例えば、[RFC2518]に従ってのみ実装されている1）コレクションは順不同であることを前提とすべきです。
<!ELEMENT ordering-type (href) >
<！ELEMENT順序型（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要求で（以下に定義）は、新しい注文-Typeヘッダを使用して順序のセマンティクスを指定するかもしれません。
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.
順序付けされ、コレクションのために、クライアントは単にヘッダの値を設定するかもしれないが、注文-TypeヘッダにおけるURIと秩序の意味を特定すべきであるクライアントは、DAVする：カスタムコレクションを命じていることを示しているが、の意味すること順序は宣伝されていません。発注セマンティクスを識別するURIに値を設定すると、人間のユーザまたはソフトウェアパッケージをインテリジェントに順序付けに新しいコレクションのメンバーを挿入するために必要な情報を提供します。注文-Typeヘッダ内のURIは、秩序の意味の定義が含まれているリソースを指すことがありますが、クライアントがそのサーバーに過度な負担をかける避けるために、そのリソースにアクセスすべきではありません。 DAVの値：注文-Typeヘッダに順不同では、クライアントは、コレクションを順不同になりたいと思っていることを示しています。注文-Typeヘッダが存在しない場合、コレクションは順不同になります。
Additional Marshalling:
追加のマーシャリング：
Ordering-Type = "Ordering-Type" ":" absoluteURI ; absoluteURI: see RFC2396, section 3
注文-TYPE = "注文型" "：" absoluteURIで。 absoluteURIで：RFC2396、セクション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：順不同」は「：カスタムDAVは、」コレクションを注文することを示しているが、順序のセマンティクスが宣伝されていないコレクションは一方で、発注されていないことを示しています。その他の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：注文型セット）：注文-Typeヘッダが存在した場合、要求は、DAVを持つ新しいコレクション・リソースを作成しておく必要があり：発注型は注文型要求ヘッダに応じて設定されます。発注のタイプは「：順不同DAV」でない限り、コレクションは注文する必要があります。
>> Request:
>>リクエスト：
MKCOL /theNorth/ HTTP/1.1 Host: example.org Ordering-Type: http://example.org/orderings/compass.html
MKCOL / theNorth / HTTP / 1.1ホスト：example.org注文-タイプ：http://example.org/orderings/compass.html
>> Response:
>>回答：
HTTP/1.1 201 Created
作成されたHTTP / 1.1 201
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：発注型プロパティは、その値http://example.org/orderings/compass.htmlとして注文-TypeヘッダからURIを持っています。この場合、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で）クライアント維持順序でコレクションに追加されると、順序内の位置は、新しい位置のヘッダで設定することができます。ポジションヘッダーは、すぐにコレクションの順序でいくつかの他の内部メンバー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.
要求がコレクションに新しい内部メンバーURIを追加している場合は、O、サーバは、発注の最後に新しいメンバーを追加しなければなりません。
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 new member" to apply). Future revisions of this specification may specify this behaviour more precisely based on future implementation experience.
実装者への注意：この仕様は同じ親コレクション内MOVE操作の特定の実装を強制しません。そのため、サーバは、（コレクション・メンバーの位置を維持する）、簡単な名前変更操作として、または「削除」と（適用する「新しいメンバーを追加する」の意味を引き起こす）「追加」のシーケンスとしてこれを実装することのいずれか。この仕様の今後の改正は、将来の実装経験に基づいて、より正確には、この動作を指定することもできます。
Additional Marshalling:
追加のマーシャリング：
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.
「最後は」新しいメンバーは、コレクションの順序で最終的な位置に配置されていることを示しながら、「最初の」キーワードは、新しいメンバーは、コレクションの順序で開始位置に配置されていることを示しています。 「前」のキーワードは、新しいメンバーが直前のセグメントで識別部材の位置にコレクションの順序付けに追加されたことを示しています。同様に、「後」のキーワードは、新しいメンバーがすぐにセグメント内で識別部材の位置を、次のコレクションの順序付けに追加されたことを示しています。
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ホスト：example.org先：http://example.org/~slein/dav/spec08.htmlポジション：requirements.html後
>> Response:
>>回答：
HTTP/1.1 201 Created
作成されたHTTP / 1.1 201
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で新しいリソースを作成しました。この例では、位置ヘッダは、サーバがすぐに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ホスト：example.org先：http://example.org/~user/dav/draft-webdav-prot-08.txtポジション：最初の
>> Response:
>>回答：
HTTP/1.1 409 Conflict Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 409競合のContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXXX
<?xml version="1.0" encoding="utf-8" ?> <D:error xmlns:D="DAV:"> <D:collection-must-be-ordered/> </D:error>
<？xml version = "1.0" エンコード= "UTF-8"？> <D：エラーのxmlns：D = "DAV："> <D：コレクション - - - 注文する必要があります/> </ D：エラー>
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.
/〜ユーザー/ DAV /コレクションが順序付けられていないコレクションですので、この場合、サーバは409（競合）ステータスコードを返しました。したがって、サーバは、位置ヘッダを満たすことができませんでした。
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).
DAVを取得する深さ1 1. PROPFINDコレクション、：発注-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場合：注文型性が存在しないに等しい「DAV：順不同」（コレクションが発注されるこのような場合）、及び設定位置（例えば、「第一」または「Xの後に」のような）現在の位置を決定します従ってヘッダ。
3. Perform the MOVE operation, optionally supplying the Position header computed in the previous step.
3.必要に応じて前のステップで計算された位置のヘッダを供給、MOVE動作を実行します。
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.
サーバーは、彼らが注文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.
orderpatch要素：リクエストボディは、DAVでなければなりません。
<!ELEMENT orderpatch (ordering-type?, order-member*) >
<！ELEMENTのorderpatch（注文型?,ため-メンバー*）>
<!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順メンバー（セグメント、位置）> <ELEMENT位置（最初|最後|前|後）！> <！ELEMENT最後EMPTY> <！ELEMENT <！ELEMENTセグメント（#PCDATA）> <！最初の空の要素>セグメントの後にセグメントの前に> <！ELEMENT>
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：注文型要素：注文型性は、DAVに応じて変更されます。
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.
Request-URIによって識別されるコレクション内の内部のメンバーURIの順序は順序メンバーのXML要素の指示に基づいて変更されます。具体的には、彼らは要求に表示されるためです。注文部材の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応答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.
ordering-：いずれかのリクエストURI（場合DAVの応答要素：複数の変更は、単一ORDERPATCH要求で要求することができるので、サーバはDAVを含む、（[RFC2518]で定義された）207（マルチステータス）応答を返さなければなりませんタイプは変更できない）または個々の測位要求がDAVとして発現した場合、収集部材のURIが（再配置する：オーダー部材が満たされなかった）何らかの問題が発生した場合。
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：注文型セット）：リクエストボディがDAV含まれている場合：要求で指定された値にコレクションの順序型性：注文型要素を、要求がDAVを設定しておく必要があります。
(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：順序付け修飾）：リクエストボディ含まDAV場合：順部材要素は、要求がDAVの指示に基づいて、リクエストURIによって識別されるコレクション内の内部メンバーURIの順序を設定しておく必要があります。order-メンバー要素。
Consider an ordered collection /coll-1, with bindings ordered as follows:
次のように命じたバインディングで、順序付きコレクション/ collの-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 /コル-1 / HTTP / 1.1ホスト：example.orgのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：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： "DAV：" D => <D：発注型> <D：のhref> http://example.org/inorder.ord </ D： HREF> </ D：注文型> <D：順部材> <D：セグメント> two.html </ D：セグメント> <D：ポジション> <D：第一/> </ D：位置> </ D：注文部材> <D：順部材> <D：セグメント> one.html </ D：セグメント> <D：ポジション> <D：第一/> </ D：位置> </ D：order-メンバー>
<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：順部材> <D：セグメント> three.html </ D：セグメント> <D：ポジション> <D：最後の/> </ D：位置> </ D：順部材> <D：順序-member> <D：セグメント> four.html </ D：セグメント> <D：ポジション> <D：最後の/> </ D：位置> </ D：順メンバー> </ D：orderpatch>
>> Response:
>>回答：
HTTP/1.1 200 OK
HTTP / 1.1 200 OK
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:
// example.org/inorder.ord：要求が処理された後に、この例では、コレクションの順序のセマンティクスは、URIはhttpによって識別されます。コレクションのDAVの値：発注型プロパティは、このURIに設定されています。リクエストはまた、新しい秩序のセマンティクスに準拠する順序でコレクションの内部メンバーURIの位置を変更する手順が含まれています。 DAVのよう：オーダー・メンバー要素は、それらが要求に現れる順序で処理される必要がある、two.htmlは順序の先頭に移動され、その後、one.htmlは順序の先頭に移動されます。その後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:
メンバーと/コレクション/ collの-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 /コル-1 / HTTP / 1.1ホスト：www.nunanet.comのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：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：順部材> <D：セグメント> nunavut.desc </ D：セグメント> <D：ポジション> < D：後> <D：セグメント> nunavut.map </ D：セグメント> </ D：位置> </ D：順部材> <D：順部材> <D：> </ D後セグメント> iqaluit.map </ D：セグメント> <D：ポジション> <D：後> <D：セグメント> pangnirtung.img </ D：セグメント> </ D：後> </ D：位置> </ D：順序-member> </ D：orderpatch>
>> Response:
>>回答：
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxx
HTTP / 1.1 207マルチステータスのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：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：応答> <D：HREF> http://www.nunanet.com/coll-1/iqaluit.map </ D：HREF> <D：ステータス> HTTP / 1.1 403禁止</ D：状態> <D：responsedescription> <D：エラー> <D：セグメントは-識別する必要があり、部材/> </ D：エラー> pangnirtung.imgは、コレクションのメンバーではありません。 </ D：responsedescription> </ D：レスポンス> </ 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.
この例では、クライアントはコレクション/ collの-1 /内部のメンバーではないURIの後iqaluit.map位置しようとしました。サーバが失敗した前提条件のDAVを示し、403（禁止）ステータスコードでこのクライアントエラーに応答：セグメント-識別する必要があり、部材。 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を受けて：無限大、異なるコレクションのメンバーは、インターリーブすることができます。これは、サーバは、幅優先トラバースを行うために必要とされていないです。唯一の要件は、任意の順序付きコレクションのメンバーは、そのコレクションのために定義された順序で表示されていることです。したがって、収集Aは順序B C Dとの順序付けられた集合であり、以下の図に示す階層のために、
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.
（Cは順不同である場合）、サーバは同様の順序A B C E F G H D又は「B E C H G F D」の応答要素を返すことが許容されるであろう。この応答では、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
ホスト：example.org奥行：1のContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：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：のxmlns小道具：J = "http://example.org/jsprops/"> <D：発注型/> <D：resourcetypeの/> <J：緯度/> </ D：プロップ> </ D：PROPFIND>
>> Response:
>>回答：
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
HTTP / 1.1 207マルチステータスのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：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：レスポンス> <D：HREF> HTTP ：//example.org/MyColl/ </ D：のhref> <D：propstat> <D：小道具> <D：発注型> <D：のhref> DAV：カスタム</ D：HREF> </ D：順序型> <D：resourcetypeの> <D：コレクション/> </ D：resourcetypeの> </ D：小道具> <D：状態> HTTP / 1.1 200 OK </ D：状態>
</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：プロペラ> <J：緯度/> </ D：プロペラ> <D：ステータス> HTTP / 1.1 404見つかりません</ D：状態> </ D：propstat > </ D：レスポンス> <D：レスポンス> <D：HREF> http://example.org/MyColl/lakehazen.html </ D：HREF> <D：propstat> <D：プロペラ> <D：resourcetypeの/> <J：緯度> 82N </ J：緯度> </ D：プロペラ> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> <D：propstat> <D：小道具> <D：発注型/> </ D：小道具> <D：状態> HTTP / 1.1 404見つかりませんでした。</ D：状態> </ D：propstat> </ D：レスポンス> <D：応答> <D：HREF> http://example.org/MyColl/siorapaluk.html </ D：HREF> <D：propstat> <D：プロペラ> <D：resourcetypeの/> <J：緯度> 78N </ J：緯度> </ D：プロペラ> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> <D：propstat> <D：プロペラ> <D：発注型/> </ D：小道具> <D：状態> HTTP / 1.1 404が見つかりません</ D：状態> </ D：propstat> </ D：レスポンス> <D：応答> <D：HREF> http://example.org /MyColl/iqaluit.html </ D：HREF> <D：propstat> <D：プロペラ> <D：resourcetypeの/> <J：緯度> 62N </ J：緯度> </ D：小道具>
<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：ステータス> HTTP / 1.1 200 OK </ D：状態> </ D：propstat> <D：propstat> <D：プロペラ> <D：発注型/> </ D：プロペラ> <D：状態> HTTP / 1.1 404見つかりません</ D：状態> </ D：propstat> </ D：レスポンス> <D：レスポンス> <D：HREF> http://example.org/MyColl/newyork.html </ D：HREF> <D：propstat> <D：プロペラ> <D：resourcetypeの/> <J：緯度> 45N </ J：緯度> </ D：プロペラ> <D：ステータス> HTTP / 1.1 200 OK </ D：状態> <D：propstat> <D：小道具> <D：発注型/> </ D：小道具> <D：が見つかりませんでした状態> HTTP / 1.1 404 </ D：状態> </ D：propstat > </ D：propstat> </ D：レスポンス> </ 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）と収集の状態の一部となるために、コレクションのメンバーの順序この仕様は、発注タイプの両方を考慮します。したがって、両方のは、チェックインまたはバージョン管理に記録されなければならない、との両方が（RFC 3253との互換性のため、バージョン管理メンバーの唯一の順序を維持する必要がある）CHECKOUT、UNCHECKOUT又は更新時に復元しなければなりません。
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：バージョン管理された結合要素がチェックインされた順序付きコレクション用に定義された順序で現れなければなりません。
The DAV:ordering-type property records the DAV:ordering-type property of the checked-in ordered collection.
DAV：発注型プロパティはDAVを記録：チェックインされたの順序型のプロパティには、コレクションを命じました。
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：初期化・コレクション - バージョン発注型）：リクエストURLが両方注文し、バージョン管理のコレクションを、特定された場合、DAV：新しいコレクションのバージョンの順序型のプロパティは、コレクションのDAVのコピーでなければなりません：発注型プロパティ。
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：初期化-バージョン履歴バインディングは秩序）：以外の順序型「DAV：順不同」要求がDAVのコレクションのバージョンに適用されている場合は、新しい作業コレクション内のバインディングは応じて注文する必要がありますコレクションのバージョンのDAVへ：バージョン管理された結合セットプロパティ。
(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に応じて注文する必要があります：バージョン管理された結合セットプロパティ。非バージョン管理のメンバーの順序は、サーバ定義です。
(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.
セクション9.1との15 [RFC2518]リソースがサポートするプロトコルWeb分散オーサリングのどの部分を示す、OPTIONSへの応答におけるDAVヘッダに準拠クラスの使用を記載しています。この仕様は、[RFC2518]にOPTIONAL拡張を定義します。これは、OPTIONS要求への応答でDAVヘッダーで使用するために、注文・コレクションと呼ばれる新しいコンプライアンスクラスを定義します。コレクションのリソースがサポート発注を行う場合は、OPTIONS要求への応答は、それがサポートするものとして、新しいORDERPATCH方法を列挙することによって、それがないことを示してもよいし、DAVヘッダに新しい注文・コレクションコンプライアンスクラスを一覧表示すること。
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.
OPTIONS要求に応答するとき、のみコレクションまたはヌルリソースは、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.
サポートされている法セット（セクション3.1.3）とDAV：サポートされているライブ・プロパティ・セット（セクション3.1.4）また、RFC 3253 [RFC3253]は、ライブプロパティDAVを導入します。 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ホスト：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 OKが許可：OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE、COPYは、MOVEは許可：MKCOL、PROPFIND、PROPPATCH、LOCKを、UNLOCK、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ヘッダーは[RFC2518]で定義されるように、リソース/ somecollection /、レベル1とレベル2に準拠していることを示しています。また、/ somecollectionは/順序付けをサポートしています。許可ヘッダーはORDERPATCH要求が/ somecollection /に提出することができることを示しています。
>> Request: PROPFIND /somecollection HTTP/1.1 Depth: 0 Content-Type: text/xml; charset="utf-8" Content-Length: xxx
>>リクエスト：PROPFIND / somecollection HTTP / 1.1深さ：0のContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：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" エンコード= "UTF-8"？> <PROPFINDのxmlns = "DAV："> <小道具> <サポート・ライブ・プロパティ・セット/> <サポート-法-設定/> </小道具> </ PROPFIND>
>> Response: HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxx
>>回答：HTTP / 1.1 207マルチステータスのContent-Type：text / xmlで、 charset = "UTF-8" をコンテンツの長さ：XXX
<?xml version="1.0" encoding="utf-8" ?> <multistatus xmlns="DAV:"> <response> <href>http://example.org/somecollection</href> <propstat> <prop>
<？xml version = "1.0" エンコード= "UTF-8"？> <multistatusのxmlns = "DAV："> <レスポンス> <HREF> http://example.org/somecollection </ HREF> <propstat> <プロプ>
<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>
<サポート・ライブプロパティ設定> <サポート・ライブ・プロパティ> <小道具> <順序型/> </小道具> </サポート・ライブプロパティ> <！ - ...他のライブのプロパティは簡潔にするため省略... - > </サポート・ライブプロパティ設定> <サポート・メソッド設定> <サポート・メソッド名=「COPY」/> <サポート・メソッド名=「DELETE」/> <サポート・メソッド名=> / /> <支持されたメソッド名= "HEAD" /> <支持されたメソッド名= "LOCK" /> <支持されたメソッド名= "MKCOL" /> <支持されたメソッド名= "MOVE" を "GET" <支持されたメソッド名= "OPTIONS" /> <支持されたメソッド名= "ORDERPATCH" /> <支持されたメソッド名= "POST" /> <支持されたメソッド名= "PROPFIND" /> <支持されたメソッド名= "PROPPATCH" /> <支持されたメソッド名= "PUT" /> <支持されたメソッド名= "TRACE" /> <支持されたメソッド名= "アンロック" /> </サポート法セット> </小道具> <状態> HTTP / 1.1 200 OK </ステータス> </ propstat> </レスポンス> </ 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 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に宣伝されているサイトでのサービス拒否のいくつかのリスクがあるかもしれません。順序型：しかし、広く展開されたアプリケーションではなくDAVで指定された場所にある意味を調べるよりも、使用頻度の高い発注のセマンティクスのためにハードコードされた値を使用することが予想されます。順序型：クライアントはDAVにURIに送信されなかった要求セクション5.1の勧告を観察する場合には、このリスクをさらに低減することになります。
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].
この仕様は、[XML]を使用して、すべての人間が読めるコンテンツを符号化し、名前の治療に[RFC2518]の慣行に従います。したがって、この仕様は、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要素の名前、およびプロパティの名前。プロトコル要素の命名方法およびヘッダのUSASCIIでエンコード英語名を使用してHTTPの先例に従います。本明細書中で使用される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]は、各ステータスコードとコード（例えば、423ロック）の短い、英語の記述を含む、HTTP / 1.1のステータスコードの慣例に従います。国際化アプリケーションでは、このメッセージを無視し、ユーザーの言語と文字セットで適切なメッセージを表示します。
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.
この文書は、プロパティおよびXML要素の[RFC2518]で定義された名前空間を使用します。 [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.
この文書では、ジェフClemm、ジェイソン・クロフォード、ジム・デイビス、チャック・フェイとジュディス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.
この文書は、ジム・Amsden、スティーブ・カーター、タイソン千早、ケン・コアー、エリス・コーエン、ブルースCragun、スペンサードーキンス、マーク・デイ、ラジブDulepet、デビッド・デュラン、リサDusseault、ロイ・フィールディング、ヤロンGoland、フレッドHITTで思慮深い議論から恩恵を受けていますアレックスHopmann、マーカス・イェーガー、クリスKaler、ManojさんKasichainula、ロフィット・クヘア、ダニエル・リベルテ、スティーブ・マーティン、ラリーMasinter、ジェフMcAffer氏、スレンドラKoduruレディ、マックスRible、サムルビー、ブラッドリー軍曹、ニックShelness、ジョンStracke、ジョンTigue、ジョンターナー、ケビン・Wiggen、などがあります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]バーナーズ=リー、T.、フィールディング、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.、ホワイトヘッド、E.、フェッチ、A.、カーター、S.、およびD.ジェンセン、 "分散オーサリングのHTTP拡張 - WEBDAV"、RFC 2518、1999年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.、Frystyk、H.、Masinter、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.、エリソン、T.、Kaler、C.およびJ.ホワイトヘッド "の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]ブレイ、T.、パオリ、J.、Sperberg-マックィーン、C.およびE. MALER、 "拡張マークアップ言語（XML）1.0（第2版）"、W3C REC-xmlの、2000年10月、<HTTP：/ /www.w3.org/TR/2000/REC-xml-20001006>。
Appendix A. Extensions to the WebDAV Document Type Definition
WebDAVの文書型定義の付録A.拡張機能
<!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（注文型?,ため-メンバー*）> <ELEMENT発注型（HREF）> <！ELEMENT位置（最初の<ELEMENT順メンバー（セグメント、位置）！> |！最後|前|後）> <！ELEMENT最初EMPTY> <！ELEMENT最後EMPTY> <！ELEMENTセグメントの前に> <！ELEMENTセグメントの後に> <！ELEMENTセグメント（#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：初期化-version制御バインディング秩序（ポスト）20 DAV：初期化、バージョン履歴バインディング秩序（ポスト）20 DAV：順序付けられたコレクション・サポート（PRE）7 DAV：順序付け修飾（ポスト）13 DAV：発注型セット（支柱）7、13 DAV：位置セット（ポスト）9 DAV：セグメント・識別しなければならない部材（PRE）9 DAV：更新バージョン制御されたコレクションのメンバーが順序付け（ポスト）21 DAV ：更新バージョンの順序型（ポスト）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：事後20 DAV-バージョン制御バインディング順を初期化：初期化、バージョン履歴バインディング秩序事後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注文-Typeヘッダ7 ORDERPATCH方法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
ジム・ホワイトヘッドUCサンタクルス、コンピュータサイエンス学科1156ハイストリートサンタクルーズ、カリフォルニア州95064米国
EMail: ejw@cse.ucsc.edu
メールアドレス：ejw@cse.ucsc.edu
Julian F. Reschke, Ed. greenbytes GmbH Salzmannstrasse 152 Muenster, NW 48159 Germany
ジュリアン・F. Reschke、エド。 greenbytes社Salzmannstrasse 152ミュンスター、NW 48159ドイツ
Phone: +49 251 2807760 Fax: +49 251 2807761 EMail: julian.reschke@greenbytes.de URI: http://greenbytes.de/tech/webdav/
電話：+49 251 2807760ファックス：+49 251 2807761 Eメール：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 Editor機能のための基金は現在、インターネット協会によって提供されます。