[要約] RFC 3648は、WebDAVの順序付けされたコレクションプロトコルに関する仕様です。このRFCの目的は、WebDAVを使用して順序付けされたコレクションを作成、編集、管理するための手法を提供することです。
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.
Copyright（c）The Internet Society（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.
このドキュメントでは、WebDAV分散オーサリングプロトコル[RFC2518]の拡張セットについて説明しているため、それ自体がHTTP/1.1プロトコルの拡張であるため、プロトコル要素を説明するためにここで使用される増強されたBNFは、HTTPのセクション2.1で説明されているとまったく同じです。[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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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：Ordering-Typeの詳細については、セクション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]で定義されている「Precondition」、「Pustcondition」、「Protected Property」という用語を使用します。サーバーは、このドキュメントのセクション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.
コレクションが注文された場合、その内部メンバーのurisのそれぞれが注文に正確に1回表示される必要があり、注文にはコレクションの内部メンバーではない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.
任意のコレクションに添付できる注文は1つだけです。これらのリソースを参照し、各コレクションに異なる注文を添付する複数のコレクションを作成することにより、同じリソースの複数の注文を実現できます。
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プロパティは、コレクションが注文されるかどうかを示し、もしそうなら、順序付けのセマンティクスを一意に識別します。また、人間および/または機械可読形式のセマンティクスの説明を指し示す場合があります。少なくとも、これにより、メンバーをコレクションに追加する人間のユーザーが注文のどこに配置するかを理解することができます。このプロパティは、プロップパッチを使用して設定することはできません。その値は、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によって特定されます。次の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：カスタム：Value 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：UNORDERED：VALUE 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.
注文とアウェアのサーバーと対話する順序認識クライアント（たとえば、[RFC2518]に従ってのみ実装されているもの）は、コレクションにDAV：Ordering-Typeプロパティを持っていない場合、コレクションが順序付けられていないと仮定する必要があります。
<!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.
注文されたコレクションの場合、クライアントは順序型ヘッダーのURIを使用した順序付けのセマンティクスを特定する必要がありますが、クライアントは単にヘッダー値をDAVに設定することができます。注文は宣伝されていません。注文セマンティクスを識別するURIに値を設定すると、人間のユーザーまたはソフトウェアパッケージが新しいコレクションメンバーをインテリジェントに注文に挿入するために必要な情報が提供されます。注文型ヘッダーのURIは、注文のセマンティクスの定義を含むリソースを指している場合がありますが、クライアントはサーバーの負担を避けるためにそのリソースにアクセスしてはなりません。DAVの値：注文型ヘッダーでは、クライアントがコレクションを注文しないことを望んでいることを示しています。注文タイプのヘッダーが存在しない場合、コレクションは順序付けられません。
Additional Marshalling:
追加のマーシャリング：
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：カスタム」はコレクションを注文することを示しますが、注文のセマンティクスは宣伝されていません。他の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：oldered」でない限り、コレクションは注文する必要があります。
>> Request:
>>リクエスト：
MKCOL /theNorth/ HTTP/1.1 Host: example.org Ordering-Type: http://example.org/orderings/compass.html
mkcol/thenorth/http/1.1 host：emple.org ordering-type：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：Ordering-Typeプロパティには、その値http://example.org/orderings/compass.htmlとしてのOrdering-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が最初にあることを指定できます。注文。
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 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))
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：Segment-Must-Identify-Member）：参照されたセグメントは、影響を受けるリソースとは異なるリソースを識別する必要があります。
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
>> 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で新しいリソースが作成されました。この例の位置ヘッダーにより、サーバーは、要件の直後に/〜lein/dav/collectionの順序付けに位置を設定しました。html。
>> 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
>> Response:
>>応答：
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>
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).
次の一連のリクエストは、サーバーが移動操作をどのように実装するかとは無関係に、その位置を保存しながらコレクションメンバーの名前を変更します。1。DEPT 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：順序型プロパティが存在し、「dav：ordered」（したがってコレクションが順序付けられている場合）に等しくない場合、現在の位置（「最初」または「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.
サーバーは、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.
注文要求が失敗した場合、リクエストの前のサーバー状態を復元する必要があります。
Additional Marshalling:
追加のマーシャリング：
The request body MUST be DAV:orderpatch element.
リクエスト本文は、DAV：OrderPatch要素でなければなりません。
<!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 >
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の順序は、注文メンバーの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-Response XML要素でなければなりません。このドキュメントは、OrderPatch応答本体の要素を定義していませんが、DAV：OrderPatch-Response要素は、OrderPatch応答ボディの要素を定義する将来の拡張機能間の相互運用性を確保するために定義されています。
<!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：Orderメンバーが満たされなかった場合）。
Preconditions:
前提条件：
(DAV:collection-must-be-ordered): see Section 6.1.
（DAV：コレクションマスト命令）：セクション6.1を参照してください。
(DAV:segment-must-identify-member): see Section 6.1.
（DAV：Segment-Must-Identify-Member）：セクション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：注文修正）：リクエスト本体にDAV：注文メンバーの要素が含まれていた場合、リクエストは、DAV：Order-の指示に基づいて、リクエスト-URIによって識別されたコレクション内の内部メンバーURIの順序を設定している必要があります。メンバー要素。
Consider an ordered collection /coll-1, with bindings ordered as follows:
次のように注文されたバインディングを使用して、注文されたコレクション /COLL-1を検討してください。
three.html four.html one.html two.html
3.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
<?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>
>> 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:
この例では、リクエストが処理された後、コレクションの注文セマンティクスはURI http：// example.org/inorder.ordによって識別されます。コレクションのDAV：Ordering-Typeプロパティの価値は、このURIに設定されています。このリクエストには、新しい注文セマンティクスに準拠するために、コレクションの内部メンバーURIの位置を変更するための指示も含まれています。DAV：注文メンバーの要素は、リクエストに表示される順序で処理する必要があるため、2.htmlは注文の開始に移動され、1つは注文の開始に移動されます。次に、3つのhtmlが注文の終了に移動され、最後に4.htmlが注文の終了に移動されます。リクエストが処理された後、コレクションの注文は次のとおりです。
one.html two.html three.html four.html
One.html Two.html 3.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
<?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
<?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.
<？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禁止</d：status> <d：ressionedescription> <d：error> <d：segment-must-didify-member/>> </d：エラー>pangnirtung.imgはコレクションメンバーではありません。</d：responsedescription> </d：response> </d：multistatus>この例では、クライアントはコレクション/Coll-1/の内部メンバーではないURIの後にiqaluit.mapを配置しようとしました。サーバーは、403（禁止）ステータスコードでこのクライアントエラーに応答し、前提条件が失敗したことを示しています。OrderPatchはAtomic Methodであるため、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,
深さを持つプロパンドへの応答：無限大量、さまざまなコレクションのメンバーがインターリーブされる可能性があります。つまり、サーバーは幅広いトラバーサルを行う必要はありません。唯一の要件は、注文されたコレクションのメンバーがそのコレクションで定義された順序に表示されることです。したがって、次の図に示されている階層については、コレクション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.
サーバーが順序で応答要素を返すことは許容されます。この応答では、B、C、およびDが正しい順序で表示され、他のコレクションのメンバーによって区切られています。クライアントは、一連の深さを使用できます。1つのプロセスリクエストを使用して、処理の深さの複雑さを回避できます。深さfirstトラバーサルに基づく無限の応答です。
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
<?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
<?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: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：順序付けタイプのプロパティ）とコレクションメンバーの順序付けの両方が、コレクションの状態の一部と見なされます。したがって、両方ともチェックインまたはバージョン制御時に記録する必要があり、両方ともチェックアウト、アンチェックアウト、または更新時に復元する必要があります（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：バージョン制御されたバインディング要素は、チェックイン注文コレクションで定義された順序付けに表示する必要があります。
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：初期化-Version-Controlled-Bindings-Ordered）：Request-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）：Request-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：Iniveryize-Version-History-Bindings-Ordered）：リクエストがDAVを使用してコレクションバージョンに適用されている場合：「DAV：UNORDERED」以外の注文タイプの場合、新しいワーキングコレクションのバインディングは注文する必要があります。コレクションバージョンの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：Iniveryize-Ordering-Type）：リクエストがコレクションバージョンに適用された場合、DAV：新しい作業コレクションのOrdering-Typeプロパティは、コレクションバージョンのDAV：Ordering-Typeプロパティから初期化する必要があります。
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：Update-Version-Controlled-Collection-Members-Ordered）：リクエストがDAVを変更した場合：バージョン制御コレクションとDAVのチェックインバージョン：チェックインバージョンのOrdering-Typeは順序ではありません（「DAV：UNORDERED」）、バージョン制御メンバーは、チェックインバージョンの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：Update-Version-Ordering-Type）：リクエストがDAV：バージョン制御コレクションのチェックインバージョンを変更した場合、DAV：Ordering-Typeプロパティは、チェックインバージョンのプロパティから更新する必要があります。
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]のオプションの拡張機能を定義します。Optionsリクエストへの応答で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.
オプションリクエストに応答する場合、コレクションまたはnullリソースのみが、DAVヘッダーの値に順序付けられた収集を含めることができます。順序付けられた収集を含めることにより、リソースは、その内部メンバーの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]では、Live Properties DAV：サポートされたメソッドセット（セクション3.1.3）およびDAV：サポートライブプロパティセット（セクション3.1.4）を導入します。サーバーは、RFC 3253で定義されているように、これらのプロパティをサポートする必要があります。
>> Request:
>>リクエスト：
OPTIONS /somecollection/ HTTP/1.1 Host: example.org
Options/SomeCollection/HTTP/1.1 HOST：emple.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許可：オプション、取得、ヘッド、ポスト、プット、削除、トレース、コピー、移動許可：mkcol、propfind、proppatch、lock、llock、odderpatch dav：1、2、Ordered-collections
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]で定義されているように、リソース /ソメコレクション /がレベル1およびレベル2に準拠していることを示しています。さらに、 / somecollection /サポート注文。Allowヘッダーは、OrderPatchリクエストを /SomeCollection /に送信できることを示します。
>> 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>
>> 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>
<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 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プロパティで宣伝されているサイトでサービスの拒否のリスクがあるかもしれません。ただし、DAV：Ordering-Typeで指定された場所でセマンティクスを調べるのではなく、広く展開されたアプリケーションが頻繁に使用される注文セマンティクスにハードコーディング値を使用することが予想されます。クライアントがDAVのURIに送信されないセクション5.1の推奨事項をクライアントが観察した場合、このリスクはさらに減少します：Ordering-Type。
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要素の名前、プロパティの名前の3つのカテゴリに分類されます。プロトコル要素の命名は、メソッドとヘッダーのために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]は、各ステータスコードを含む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.
この文書は、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.
この文書は、ジム・アムスデン、スティーブ・カーター、タイソン・チハヤ、ケン・コーア、エリス・コーエン、ブルース・クラグン、スペンサー・ドーキンス、マーク・デイ、ラジブ・デュレペット、デビッド・デュランド、リサ・デュッセー、ロイ・フィールディング、ヤロン・ゴーランド、フレッド・ヒット、フリーアレックス・ホップマン、マーカス・ジェイガー、クリス・カラー、マノジ・カシチャニュラ、ロヒト・カレ、ダニエル・ラリベルテ、スティーブ・マーティン、ラリー・マシンダー、ジェフ・マカファー、スレンドラ・コドゥル・レディ、マックス・リブル、サム・ルービー、ブラッドリー・セルゲアン、ニック・シェルネス、ジョン・ストラッケ、ジョン・ティゲ、ジョンターナー、ケビン・ウィッゲンなど。
[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。and L. Masinter、「Uniform Resource Identiers（URI）：Generic Syntax」、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」、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners-Lee、 "Hypertext Transfer Protocol-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。and E. Maler、「拡張可能なマークアップ言語（XML）1.0（2番目のED）」、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)>
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：コレクションマスト順序（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：注文コレクションがサポートする（pre）7 dav：注文修飾（Post）13 Dav：注文-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
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 DAV:update-version-controlled-collection-members-ordered postcondition 21 DAV:update-version-ordering-type postcondition 21
D DAVヘッダーコンプライアンスクラス「注文コレクション」21 DAV：コレクションマスト命令の前提条件9 DAV：カスタム注文タイプ6 DAV：初期化 - コレクションバージョン順序型ポストコンディション20DAV：Initialize-version-controlled-bindings-ordered postcondition 20 dav：initialize-version-history-history-bindings-mind edupedition 20 dav：順序付けされた共同体がサポートする前提条件7 dav：注文修飾ポストコンディション13 Dav：注文タイプのプロパティ6 Dav 6 Dav 6 Dav 6 Dav：Order-Type-Set Postcondition 7、13 Dav：Position-Set Postcondition 9 Dav：Segment-Must-Identify-Member Precondition 9 Dav：Unodered Ordering Type 6 Dav：Update-Version-versolled-Collection-Members-Members-Ordered Pustcontition 21 Dav Dav：update-version-ordering-type postcondition 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 Undored Collection 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
Julian F. Reschke, Ed. greenbytes GmbH Salzmannstrasse 152 Muenster, NW 48159 Germany
ジュリアン・F・レシュケ編Greenbytes Gmbh Salzmannstrasse 152 Muenster、NW 48159ドイツ
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.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。