RFC 6578 - Collection Synchronization for Web Distributed Authoring and Versioning (WebDAV) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6578
タイトル : RFC 6578 - Web分散オーサリングとバージョン管理（WebDAV）のコレクション同期
翻訳編集 : 自動生成

[要約] RFC 6578は、WebDAVのためのコレクション同期に関する規格であり、WebDAVクライアントとサーバー間のコレクションの同期を可能にする。目的は、WebDAVの利用者が複数のデバイスやクライアント間でコレクションを同期し、一貫性を保つことである。

Internet Engineering Task Force (IETF)                          C. Daboo
Request for Comments: 6578                                    Apple Inc.
Category: Standards Track                                    A. Quillaud
ISSN: 2070-1721                                                   Oracle
                                                              March 2012

Collection Synchronization for Web Distributed Authoring and Versioning (WebDAV)

Web分散オーサリングとバージョン管理（WebDAV）のコレクション同期

Abstract

概要

This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) that allows efficient synchronization of the contents of a WebDAV collection.

この仕様は、WebDAVコレクションのコンテンツの効率的な同期を可能にするWeb分散オーサリングおよびバージョン管理（WebDAV）の拡張を定義します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6578.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6578で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部の著作権を管理する人は、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
   3.  WebDAV Synchronization . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  DAV:sync-collection Report . . . . . . . . . . . . . . . .  6
     3.3.  Depth Behavior . . . . . . . . . . . . . . . . . . . . . .  8
     3.4.  Types of Changes Reported on Initial Synchronization . . .  9
     3.5.  Types of Changes Reported on Subsequent
           Synchronizations . . . . . . . . . . . . . . . . . . . . . 10
       3.5.1.  Changed Member . . . . . . . . . . . . . . . . . . . . 10
       3.5.2.  Removed Member . . . . . . . . . . . . . . . . . . . . 10
     3.6.  Truncation of Results  . . . . . . . . . . . . . . . . . . 11
     3.7.  Limiting Results . . . . . . . . . . . . . . . . . . . . . 12
     3.8.  Example: Initial DAV:sync-collection Report  . . . . . . . 12
     3.9.  Example: DAV:sync-collection Report with Token . . . . . . 14
     3.10. Example: Initial DAV:sync-collection Report with
           Truncation . . . . . . . . . . . . . . . . . . . . . . . . 16
     3.11. Example: Initial DAV:sync-collection Report with Limit . . 17
     3.12. Example: DAV:sync-collection Report with Unsupported
           Limit  . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     3.13. Example: DAV:sync-level Set to Infinite, Initial
           DAV:sync-collection Report . . . . . . . . . . . . . . . . 19
   4.  DAV:sync-token Property  . . . . . . . . . . . . . . . . . . . 22
   5.  DAV:sync-token Use with If Header  . . . . . . . . . . . . . . 22
     5.1.  Example: If Precondition with PUT  . . . . . . . . . . . . 22
     5.2.  Example: If Precondition with MKCOL  . . . . . . . . . . . 23
   6.  XML Element Definitions  . . . . . . . . . . . . . . . . . . . 24
     6.1.  DAV:sync-collection XML Element  . . . . . . . . . . . . . 24
     6.2.  DAV:sync-token XML Element . . . . . . . . . . . . . . . . 24
     6.3.  DAV:sync-level XML Element . . . . . . . . . . . . . . . . 24
     6.4.  DAV:multistatus XML Element  . . . . . . . . . . . . . . . 25
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 25
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 25
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 26
   Appendix A.  Backwards-Compatible Handling of Depth  . . . . . . . 27
   Appendix B.  Example of a Client Synchronization Approach  . . . . 27

1. Introduction

1. はじめに

WebDAV [RFC4918] defines the concept of 'collections', which are hierarchical groupings of WebDAV resources on an HTTP [RFC2616] server. Collections can be of arbitrary size and depth (i.e., collections within collections). WebDAV clients that cache resource content need a way to synchronize that data with the server (i.e., detect what has changed and update their cache). Currently, this can be done using a WebDAV PROPFIND request on a collection to list all members of a collection along with their DAV:getetag property values, which allows the client to determine which were changed, added, or deleted. However, this does not scale well to large collections, as the XML response to the PROPFIND request will grow with the collection size.

WebDAV [RFC4918]は、「コレクション」の概念を定義しています。これは、HTTP [RFC2616]サーバー上のWebDAVリソースを階層的にグループ化したものです。コレクションは、任意のサイズと深度にすることができます（つまり、コレクション内のコレクション）。リソースコンテンツをキャッシュするWebDAVクライアントは、そのデータをサーバーと同期する（つまり、何が変更されたかを検出してキャッシュを更新する）方法が必要です。現在、これはコレクションのWebDAV PROPFINDリクエストを使用して行うことができ、DAV：getetagプロパティ値とともにコレクションのすべてのメンバーをリストします。これにより、クライアントは変更、追加、または削除されたものを判別できます。ただし、PROPFIND要求へのXML応答はコレクションのサイズに応じて大きくなるため、これは大規模なコレクションにうまく拡張できません。

This specification defines a new WebDAV report that results in the server returning to the client only information about those member URLs that were added or deleted, or whose mapped resources were changed, since a previous execution of the report on the collection.

この仕様は新しいWebDAVレポートを定義し、コレクションでの前回のレポートの実行以降に、追加または削除されたメンバーURL、またはマップされたリソースが変更されたメンバーURLに関する情報のみをサーバーに返します。

Additionally, a new property is added to collection resources that is used to convey a "synchronization token" that is guaranteed to change when the collection's member URLs or their mapped resources have changed.

さらに、コレクションのメンバーURLまたはマップされたリソースが変更されたときに変更されることが保証されている「同期トークン」を伝達するために使用される新しいプロパティがコレクションリソースに追加されます。

2. Conventions Used in This Document

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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

This document uses XML DTD fragments ([W3C.REC-xml-20081126], Section 3.2) as a purely notational convention. WebDAV request and response bodies cannot be validated by a DTD due to the specific extensibility rules defined in Section 17 of [RFC4918] and due to the fact that all XML elements defined by this specification use the XML namespace name "DAV:". In particular:

このドキュメントでは、純粋な表記規則としてXML DTDフラグメント（[W3C.REC-xml-20081126]、セクション3.2）を使用します。 [RFC4918]のセクション17で定義されている特定の拡張性ルールと、この仕様で定義されているすべてのXML要素がXML名前空間名「DAV：」を使用しているため、WebDAVリクエストとレスポンスの本文はDTDで検証できません。特に：

1. Element names use the "DAV:" namespace.

1. 要素名は「DAV：」名前空間を使用します。

2. Element ordering is irrelevant unless explicitly stated otherwise.

2. 特に明記されていない限り、要素の順序は関係ありません。

3. Extension elements (elements not already defined as valid child elements) may be added anywhere, except when explicitly stated otherwise.

3. 特に明記されていない限り、拡張要素（有効な子要素としてまだ定義されていない要素）はどこにでも追加できます。

4. Extension attributes (attributes not already defined as valid for this element) may be added anywhere, except when explicitly stated otherwise.

4. 特に明記されていない限り、拡張属性（この要素に対して有効であるとまだ定義されていない属性）はどこにでも追加できます。

When an XML element type in the "DAV:" namespace is referenced in this document outside of the context of an XML fragment, the string "DAV:" will be prefixed to the element type.

「DAV：」名前空間のXML要素タイプがこのドキュメントでXMLフラグメントのコンテキスト外で参照されている場合、「DAV：」という文字列が要素タイプの前に付加されます。

This document inherits, and sometimes extends, DTD productions from Section 14 of [RFC4918].

このドキュメントは、[RFC4918]のセクション14のDTDプロダクションを継承し、場合によっては拡張します。

3. WebDAV Synchronization

3. WebDAV同期

3.1. Overview

3.1. 概観

One way to synchronize data between two entities is to use some form of synchronization token. The token defines the state of the data being synchronized at a particular point in time. It can then be used to determine what has changed between one point in time and another.

2つのエンティティ間でデータを同期する1つの方法は、なんらかの形式の同期トークンを使用することです。トークンは、特定の時点で同期されるデータの状態を定義します。次に、ある時点と別の時点との間で何が変化したかを判別するために使用できます。

This specification defines a new WebDAV report that is used to enable client-server collection synchronization based on such a token.

この仕様では、このようなトークンに基づいてクライアント/サーバーコレクションの同期を有効にするために使用される新しいWebDAVレポートを定義しています。

In order to synchronize the contents of a collection between a server and client, the server provides the client with a synchronization token each time the synchronization report is executed. That token represents the state of the data being synchronized at that point in time. The client can then present that same token back to the server at some later time, and the server will return only those items that are new, have changed, or were deleted since that token was generated. The server also returns a new token representing the new state at the time the report was run.

サーバーとクライアント間でコレクションのコンテンツを同期するために、サーバーは、同期レポートが実行されるたびにクライアントに同期トークンを提供します。そのトークンは、その時点で同期されているデータの状態を表します。その後、クライアントは同じトークンを後でサーバーに提示でき、サーバーは、そのトークンが生成されてから新しい、変更された、または削除されたアイテムのみを返します。サーバーは、レポートが実行されたときの新しい状態を表す新しいトークンも返します。

Typically, the first time a client connects to the server it will need to be informed of the entire state of the collection (i.e., a full list of all member URLs that are currently in the collection). That is done by the client sending an empty token value to the server. This indicates to the server that a full listing is required.

通常、クライアントが初めてサーバーに接続するときに、コレクションの状態全体（つまり、現在コレクション内にあるすべてのメンバーURLの完全なリスト）を通知する必要があります。これは、クライアントが空のトークン値をサーバーに送信することによって行われます。これは、完全なリストが必要であることをサーバーに示します。

As an alternative, the client might choose to do its first synchronization using some other mechanism on the collection (e.g., some other form of batch resource information retrieval such as PROPFIND, SEARCH [RFC5323], or specialized REPORTs such as those defined in CalDAV [RFC4791] and CardDAV [RFC6352]) and ask for the DAV:sync-token property to be returned. This property (defined in Section 4) contains the same token that can be used later to issue a DAV:sync-collection report.

別の方法として、クライアントは、コレクションの他の何らかのメカニズム（たとえば、PROPFIND、SEARCH [RFC5323]などのその他の形式のバッチリソース情報取得、またはCalDAVで定義されているものなどの特殊なレポート）を使用して最初の同期を実行することを選択できます。 RFC4791]およびCardDAV [RFC6352]）を使用して、DAV：sync-tokenプロパティが返されるように要求します。このプロパティ（セクション4で定義）には、後でDAV：sync-collectionレポートを発行するために使用できる同じトークンが含まれています。

In some cases, a server might only wish to maintain a limited amount of history about changes to a collection. In that situation, it will return an error to the client when the client presents a token that is "out of date". At that point, the client has to fall back to synchronizing the entire collection by re-running the report request using an empty token value.

場合によっては、サーバーは、コレクションの変更に関する限られた量の履歴のみを保持したい場合があります。その場合、クライアントが「古い」トークンを提示すると、クライアントにエラーが返されます。その時点で、クライアントは空のトークン値を使用してレポートリクエストを再実行することにより、コレクション全体の同期にフォールバックする必要があります。

Typically, a client will use the synchronization report to retrieve the list of changes and will follow that with requests to retrieve the content of changed resources. It is possible that additional changes to the collection could occur between the time of the synchronization report and resource content retrieval, which could result in an inconsistent view of the collection. When clients use this method of synchronization, they need to be aware that such additional changes could occur and track them, e.g., by differences between the ETag values returned in the synchronization report and those returned when actually fetching resource content, by using conditional requests as described in Section 5, or by repeating the synchronization process until no changes are returned.

通常、クライアントは同期レポートを使用して変更のリストを取得し、それに続いて変更されたリソースのコンテンツを取得するリクエストを行います。同期レポートの時間とリソースコンテンツの取得の間にコレクションに追加の変更が発生し、コレクションのビューに一貫性がなくなる可能性があります。クライアントがこの同期方法を使用する場合は、条件付き要求を使用して、同期レポートで返されるETag値と実際にリソースコンテンツをフェッチしたときに返されるETag値の違いなどによって、このような追加の変更が発生し、それらを追跡できることを認識しておく必要があります。セクション5で説明するか、変更が返されなくなるまで同期プロセスを繰り返します。

3.2. DAV:sync-collection Report

3.2. DAV：sync-collectionレポート

If the DAV:sync-collection report is implemented by a WebDAV server, then the server MUST list the report in the "DAV:supported-report-set" property on any collection that supports synchronization.

DAV：sync-collectionレポートがWebDAVサーバーによって実装されている場合、サーバーは、同期をサポートするすべてのコレクションの "DAV：supported-report-set"プロパティにレポートをリストする必要があります。

To implement the behavior for this report, a server needs to keep track of changes to any member URLs and their mapped resources in a collection (as defined in Section 3 of [RFC4918]). This includes noting the addition of new member URLs, the changes to the mapped resources of existing member URLs, and the removal of member URLs. The server will track each change and provide a synchronization "token" to the client that describes the state of the server at a specific point in time. This "token" is returned as part of the response to the "sync-collection" report. Clients include the last token they got from the server in the next "sync-collection" report that they execute, and the server provides the changes from the previous state (represented by the token) to the current state (represented by the new token returned).

このレポートの動作を実装するには、サーバーはコレクション内のメンバーURLとそのマップされたリソースへの変更を追跡する必要があります（[RFC4918]のセクション3で定義）。これには、新しいメンバーURLの追加、既存のメンバーURLのマップされたリソースへの変更、およびメンバーURLの削除に注意することが含まれます。サーバーは各変更を追跡し、特定の時点でのサーバーの状態を説明する同期「トークン」をクライアントに提供します。この「トークン」は、「sync-collection」レポートへの応答の一部として返されます。クライアントは、サーバーから取得した最後のトークンを、クライアントが実行する次の「同期コレクション」レポートに含めます。サーバーは、以前の状態（トークンで表される）から現在の状態（返される新しいトークンで表される）への変更を提供します）。

The synchronization token itself MUST be treated as an "opaque" string by the client, i.e., the actual string data has no specific meaning or syntax. However, the token MUST be a valid URI to allow its use in an If precondition request header (see Section 5). For example, a simple implementation of such a token could be a numeric counter that counts each change as it occurs and relates that change to the specific object that changed. The numeric value could be appended to a "base" URI to form the valid sync-token.

同期トークン自体は、クライアントによって「不透明な」文字列として扱われる必要があります。つまり、実際の文字列データには特定の意味や構文はありません。ただし、トークンは、If前提条件要求ヘッダーで使用できるようにする有効なURIである必要があります（セクション5を参照）。たとえば、そのようなトークンの単純な実装は、発生するたびに各変更をカウントし、その変更を、変更された特定のオブジェクトに関連付ける数値カウンターにすることができます。数値を「ベース」URIに追加して、有効な同期トークンを形成できます。

Marshalling:

マーシャリング：

The request-URI MUST identify a collection. The request body MUST be a DAV:sync-collection XML element (see Section 6.1), which MUST contain one DAV:sync-token XML element, one DAV:sync-level element, and one DAV:prop XML element, and MAY contain a DAV:limit XML element.

request-URIはコレクションを識別しなければなりません（MUST）。リクエストの本文はDAV：sync-collection XML要素である必要があり（セクション6.1を参照）、DAV：sync-token XML要素、DAV：sync-level要素、DAV：prop XML要素を1つずつ含める必要があり、 DAV：limit XML要素。

This report is only defined when the Depth header has value "0"; other values result in a 400 (Bad Request) error response. Note that [RFC3253], Section 3.6, states that if the Depth header is not present, it defaults to a value of "0".

このレポートは、Depthヘッダーの値が「0」の場合にのみ定義されます。他の値は、400（Bad Request）エラー応答になります。 [RFC3253]のセクション3.6では、Depthヘッダーが存在しない場合、デフォルトで値「0」が指定されることに注意してください。

The response body for a successful request MUST be a DAV:multistatus XML element, which MUST contain one DAV:sync-token element in addition to one DAV:response element for each member URL that was added, has had its mapped resource changed, or was deleted since the last synchronization operation as specified by the DAV:sync-token provided in the request. A given member URL MUST appear only once in the response. In the case where multiple member URLs of the request-URI are mapped to the same resource, if the resource is changed, each member URL MUST be returned in the response.

成功した要求の応答本文は、DAV：multistatus XML要素である必要があります。これには、追加された各メンバーURLの1つのDAV：response要素に加えて1つのDAV：sync-token要素が含まれている必要があり、マップされたリソースが変更されている、またはリクエストで提供されたDAV：sync-tokenで指定された最後の同期操作以降に削除されました。特定のメンバーURLは、応答で1回だけ出現する必要があります。 request-URIの複数のメンバーURLが同じリソースにマップされている場合、リソースが変更されると、各メンバーURLが応答で返されなければなりません（MUST）。

The content of each DAV:response element differs depending on how the member was altered:

各DAV：response要素の内容は、メンバーの変更方法によって異なります。

For members that have changed (i.e., are new or have had their mapped resource modified), the DAV:response MUST contain at least one DAV:propstat element and MUST NOT contain any DAV:status element.

変更された（つまり、新しい、またはマップされたリソースが変更された）メンバーの場合、DAV：responseには少なくとも1つのDAV：propstat要素を含める必要があり、DAV：status要素を含めてはなりません（MUST NOT）。

For members that have been removed, the DAV:response MUST contain one DAV:status with a value set to '404 Not Found' and MUST NOT contain any DAV:propstat element.

削除されたメンバーの場合、DAV：responseには、値が「404 Not Found」に設定された1つのDAV：statusが含まれている必要があり、DAV：propstat要素が含まれていてはなりません。

For members that are collections and are unable to support the DAV:sync-collection report, the DAV:response MUST contain one DAV:status with a value set to '403 Forbidden', a DAV:error containing DAV:supported-report or DAV:sync-traversal-supported (see Section 3.3 for which is appropriate) and MUST NOT contain any DAV:propstat element.

コレクションであり、DAV：sync-collectionレポートをサポートできないメンバーの場合、DAV：responseには、値が「403 Forbidden」に設定された1つのDAV：status、DAV：supported-reportまたはDAVを含むDAV：errorが含まれている必要があります。：sync-traversal-supported（適切なセクション3.3を参照）。DAV：propstat要素を含めることはできません。

The conditions under which each type of change can occur are further described in Section 3.5.

各タイプの変更が発生する条件については、セクション3.5で詳しく説明します。

Preconditions:

前提条件：

(DAV:valid-sync-token): The DAV:sync-token element value MUST be a valid token previously returned by the server for the collection targeted by the request-URI. Servers might need to invalidate tokens previously returned to clients. Doing so will cause the clients to fall back to doing full synchronization using the report, though that will not require clients to download resources that are already cached and have not changed. Even so, servers MUST limit themselves to invalidating tokens only when absolutely necessary. Specific reasons include:

（DAV：valid-sync-token）：DAV：sync-token要素の値は、リクエストURIの対象となるコレクションに対して、サーバーによって以前に返された有効なトークンである必要があります。サーバーは、以前にクライアントに返されたトークンを無効にする必要がある場合があります。これにより、クライアントはレポートを使用した完全同期にフォールバックしますが、既にキャッシュされていて変更されていないリソースをクライアントがダウンロードする必要はありません。それでも、サーバーは絶対に必要な場合にのみトークンを無効化するように制限する必要があります。具体的な理由は次のとおりです。

* Servers might be unable to maintain all of the change data for a collection due to storage or performance reasons, e.g., servers might only be able to maintain up to 3 weeks worth of changes to a collection, or only up to 10,000 total changes, or not wish to maintain changes for a deleted collection.

* ストレージまたはパフォーマンス上の理由により、サーバーはコレクションのすべての変更データを維持できない場合があります。たとえば、サーバーは、コレクションに対して最大3週間の変更、または合計で最大10,000の変更のみを維持できる場合があります。削除されたコレクションの変更を維持したくない。

* Change to server implementation: servers might be upgraded to a new implementation that tracks the history in a different manner, and thus previous synchronization history is no longer valid.

* サーバー実装の変更：サーバーは、別の方法で履歴を追跡する新しい実装にアップグレードされる可能性があるため、以前の同期履歴は無効になります。

Postconditions:

事後条件：

(DAV:number-of-matches-within-limits): The number of changes reported in the response must fall within the client-specified limit. This condition might be triggered if a client requests a limit on the number of responses (as per Section 3.7), but the server is unable to truncate the result set at or below that limit.

（DAV：number-of-matches-with-limits）：応答で報告される変更の数は、クライアント指定の制限内に収まる必要があります。この条件は、クライアントが応答数の制限を要求した場合（セクション3.7による）にトリガーされる可能性がありますが、サーバーはその制限以下の結果セットを切り捨てることができません。

3.3. Depth Behavior

3.3. 深度動作

Servers MUST support only Depth:0 behavior with the DAV:sync-collection report, i.e., the report targets only the collection being synchronized in a single request. However, clients do need to "scope" the synchronization to different levels within that collection -- specifically, immediate children (level "1") and all children at any depth (level "infinite"). To specify which level to use, clients MUST include a DAV:sync-level XML element in the request.

サーバーは、DAV：sync-collectionレポートでDepth：0動作のみをサポートする必要があります。つまり、レポートは、単一の要求で同期されているコレクションのみをターゲットにします。ただし、クライアントは、そのコレクション内のさまざまなレベル（具体的には、直接の子（レベル "1"）および任意の深さのすべての子（レベル "無限"））に同期を "スコープ"する必要があります。使用するレベルを指定するには、クライアントはリクエストにDAV：sync-level XML要素を含める必要があります。

o When the client specifies the DAV:sync-level XML element with a value of "1", only appropriate internal member URLs (immediate children) of the collection specified as the request-URI are reported.

o クライアントがDAV：sync-level XML要素に値「1」を指定すると、request-URIとして指定されたコレクションの適切な内部メンバーURL（直接の子）のみが報告されます。

o When the client specifies the DAV:sync-level XML element with a value of "infinite", all appropriate member URLs of the collection specified as the request-URI are reported, provided child collections themselves also support the DAV:sync-collection report.

o 子コレクション自体がDAV：sync-collectionレポートもサポートしている場合、クライアントがDAV：sync-level XML要素に値 "infinite"を指定すると、要求URIとして指定されたコレクションの適切なすべてのメンバーURLが報告されます。

o DAV:sync-token values returned by the server are not specific to the value of the DAV:sync-level XML element used in the request. As such, clients MAY use a DAV:sync-token value from a request with one DAV:sync-level XML element value for a similar request with a different DAV:sync-level XML element value; however, the utility of this is limited.

o サーバーから返されるDAV：sync-tokenの値は、リクエストで使用されるDAV：sync-level XML要素の値に固有のものではありません。そのため、クライアントは、DAV：sync-level XML要素の値が異なる同様のリクエストに対して、DAV：sync-levelの1つのXML要素値を持つリクエストからのDAV：sync-token値を使用できます。ただし、このユーティリティの使用は制限されています。

Note that when a server supports a DAV:sync-level XML element with a value of "infinite", it might not be possible to synchronize some child collections within the collection targeted by the report. When this occurs, the server MUST include a DAV:response element for the child collection with status 403 (Forbidden). The 403 response MUST be sent once, when the collection is first reported to the client. In addition, the server MUST include a DAV:error element in the DAV:response element, indicating one of two possible causes for this:

サーバーが「無限」の値を持つDAV：sync-level XML要素をサポートする場合、レポートのターゲットとなるコレクション内の一部の子コレクションを同期できない可能性があることに注意してください。これが発生した場合、サーバーは、ステータス403（禁止）の子コレクションのDAV：response要素を含める必要があります。コレクションが最初にクライアントに報告されるときに、403応答を1回送信する必要があります。さらに、サーバーはDAV：response要素にDAV：error要素を含めなければなりません。これは、これについて2つの考えられる原因の1つを示します。

The DAV:sync-collection report is not supported at all on the child collection. The DAV:error element MUST contain the DAV:supported-report element.

DAV：sync-collectionレポートは、子コレクションではまったくサポートされていません。 DAV：error要素には、DAV：supported-report要素が含まれている必要があります。

The server is unwilling to report results for the child collection when a DAV:sync-collection report with the DAV:sync-level XML element set to "infinite" is executed on a parent resource. This might happen when, for example, the synchronization state of the collection resource is controlled by another subsystem. In such cases clients can perform the DAV:sync-collection report directly on the child collection instead. The DAV:error element MUST contain the DAV:sync-traversal-supported element.

DAV：sync-level XML要素が「無限」に設定されたDAV：sync-collectionレポートが親リソースで実行されると、サーバーは子コレクションの結果を報告しません。これは、たとえば、収集リソースの同期状態が別のサブシステムによって制御されている場合に発生する可能性があります。そのような場合、クライアントは代わりに子コレクションで直接DAV：sync-collectionレポートを実行できます。 DAV：error要素には、DAV：sync-traversal-supported要素が含まれている必要があります。

3.4. Types of Changes Reported on Initial Synchronization

3.4. 初期同期で報告される変更のタイプ

When the DAV:sync-collection request contains an empty DAV:sync-token element, the server MUST return all member URLs of the collection (taking account of the DAV:sync-level XML element value as per Section 3.3, and optional truncation of the result set as per Section 3.6) and it MUST NOT return any removed member URLs. All types of member (collection or non-collection) MUST be reported.

DAV：sync-collectionリクエストに空のDAV：sync-token要素が含まれている場合、サーバーはコレクションのすべてのメンバーURLを返す必要があります（セクション3.3のDAV：sync-level XML要素の値を考慮し、オプションでセクション3.6の結果セット）、削除されたメンバーURLを返してはなりません。すべてのタイプのメンバー（コレクションまたは非コレクション）を報告する必要があります。

3.5. Types of Changes Reported on Subsequent Synchronizations

3.5. 後続の同期で報告される変更のタイプ

When the DAV:sync-collection request contains a valid value for the DAV:sync-token element, two types of member URL state changes can be returned (changed or removed). This section defines what triggers each of these to be returned. It also clarifies the case where a member URL might have undergone multiple changes between two synchronization report requests. In all cases, the DAV:sync-level XML element value (as per Section 3.3) and optional truncation of the result set (as per Section 3.6) are taken into account by the server.

DAV：sync-collectionリクエストにDAV：sync-token要素の有効な値が含まれている場合、2種類のメンバーURL状態の変更が返されます（変更または削除）。このセクションでは、これらのそれぞれが返されるトリガーを定義します。また、メンバーURLが2つの同期レポート要求間で複数の変更を受けた可能性があるケースも明らかにします。すべての場合において、DAV：sync-level XML要素の値（セクション3.3による）とオプションの結果セットの切り捨て（セクション3.6による）は、サーバーによって考慮されます。

3.5.1. Changed Member

3.5.1. 変更されたメンバー

A member URL MUST be reported as changed if it has been newly mapped as a member of the target collection since the request sync-token was generated (e.g., when a new resource has been created as a child of the collection). For example, this includes member URLs that have been newly mapped as the result of a COPY, MOVE, BIND [RFC5842], or REBIND [RFC5842] request. All types of member URL (collection or non-collection) MUST be reported.

リクエストのsync-tokenが生成されてからターゲットコレクションのメンバーとして新しくマップされた場合（たとえば、新しいリソースがコレクションの子として作成された場合）、メンバーURLは変更されたものとして報告する必要があります。たとえば、これには、COPY、MOVE、BIND [RFC5842]、またはREBIND [RFC5842]要求の結果として新たにマッピングされたメンバーURLが含まれます。すべてのタイプのメンバーURL（コレクションまたは非コレクション）を報告する必要があります。

In the case where a mapping between a member URL and the target collection was removed, then a new mapping with the same URI was created, the member URL MUST be reported as changed and MUST NOT be reported as removed.

メンバーURLとターゲットコレクション間のマッピングが削除され、同じURIで新しいマッピングが作成された場合、メンバーURLは変更されたものとして報告されなければならず、削除されたものとして報告されてはいけません（MUST NOT）。

A member URL MUST be reported as changed if its mapped resource's entity tag value (defined in Section 3.11 of [RFC2616]) has changed since the request sync-token was generated.

メンバーのURLは、マップされたリソースのエンティティタグ値（[RFC2616]のセクション3.11で定義）が、リクエストの同期トークンが生成されてから変更されている場合、変更されたものとして報告する必要があります。

A member URL MAY be reported as changed if the user issuing the request was granted access to this member URL, due to access control changes.

アクセス制御の変更により、リクエストを発行したユーザーがこのメンバーURLへのアクセスを許可された場合、メンバーURLは変更されたと報告される場合があります。

Collection member URLs MUST be returned as changed if they are mapped to an underlying resource (i.e., entity body) and if the entity tag associated with that resource changes. There is no guarantee that changes to members of a collection will result in a change in any entity tag of that collection, so clients cannot rely on a series of reports using the DAV:sync-level XML element value set to "1" at multiple levels to track all changes within a collection. Instead, a DAV:sync-level XML element with a value of "infinite" has to be used.

コレクションメンバーのURLは、基になるリソース（エンティティボディなど）にマップされている場合、およびそのリソースに関連付けられているエンティティタグが変更されている場合、変更されたものとして返される必要があります。コレクションのメンバーを変更すると、そのコレクションのエンティティタグが変更されるという保証はありません。そのため、クライアントは、DAV：syncレベルのXML要素の値を複数に「1」に設定して使用する一連のレポートに依存できません。コレクション内のすべての変更を追跡するレベル。代わりに、値が「無限」のDAV：syncレベルのXML要素を使用する必要があります。

3.5.2. Removed Member

3.5.2. 削除されたメンバー

A member MUST be reported as removed if its mapping under the target collection has been removed since the request sync-token was generated, and it has not been remapped since it was removed. For example, this includes members that have been unmapped as the result of a MOVE, UNBIND [RFC5842], or REBIND [RFC5842] operation. This also includes collection members that have been removed, including ones that themselves do not support the DAV:sync-collection report.

リクエストのsync-tokenが生成されてからターゲットコレクションでのマッピングが削除され、メンバーが削除されてから再マッピングされていない場合、メンバーは削除されたと報告する必要があります。たとえば、これには、MOVE、UNBIND [RFC5842]、またはREBIND [RFC5842]操作の結果としてマップ解除されたメンバーが含まれます。これには、削除されたコレクションメンバーも含まれます。これには、DAV：sync-collectionレポートをサポートしていないメンバーも含まれます。

If a member was added (and its mapped resource possibly modified), then removed between two synchronization report requests, it MUST be reported as removed. This ensures that a client that adds a member is informed of the removal of the member, if the removal occurs before the client has had a chance to execute a synchronization report.

メンバーが追加された場合（およびそのマップされたリソースが変更された可能性がある場合）、2つの同期レポート要求の間に削除された場合は、削除されたものとして報告する必要があります。これにより、クライアントが同期レポートを実行する前に削除が行われた場合に、メンバーを追加したクライアントにメンバーの削除が通知されます。

A member MAY be reported as removed if the user issuing the request no longer has access to this member, due to access control changes.

アクセス制御の変更により、リクエストを発行したユーザーがこのメンバーにアクセスできなくなった場合、メンバーは削除されたと報告される場合があります。

For a report with the DAV:sync-level XML element value set to "infinite", where a collection is removed, the server MUST NOT report the removal of any members of the removed collection. Clients MUST assume that if a collection is reported as being removed, then all members of that collection have also been removed.

DAV：sync-level XML要素の値が「無限」に設定されたレポートの場合、コレクションは削除されますが、サーバーは削除されたコレクションのメンバーの削除を報告してはなりません（MUST NOT）。クライアントは、コレクションが削除されたと報告された場合、そのコレクションのすべてのメンバーも削除されたと想定する必要があります。

3.6. Truncation of Results

3.6. 結果の切り捨て

A server MAY limit the number of member URLs in a response, for example, to limit the amount of work expended in processing a request, or as the result of an explicit limit set by the client. If the result set is truncated, the response MUST use status code 207 (Multi-Status), return a DAV:multistatus response body, and indicate a status of 507 (Insufficient Storage) for the request-URI. That DAV:response element SHOULD include a DAV:error element with the DAV:number-of-matches-within-limits precondition, as defined in [RFC3744] (Section 9.2). DAV:response elements for all the changes being reported are also included.

サーバーは、応答のメンバーURLの数を制限してもよい（MAY）、たとえば、要求の処理に費やされた作業の量を制限したり、クライアントによって明示的に設定された制限の結果として。結果セットが切り捨てられた場合、応答はステータスコード207（マルチステータス）を使用し、DAV：multistatusレスポンスボディを返し、リクエストURIに対してステータス507（ストレージ不足）を示す必要があります。そのDAV：response要素は、[RFC3744]（セクション9.2）で定義されているように、DAV：number-of-matches-within-limits前提条件を持つDAV：error要素を含める必要があります（SHOULD）。レポートされるすべての変更のDAV：response要素も含まれます。

When truncation occurs, the DAV:sync-token value returned in the response MUST represent the correct state for the partial set of changes returned. That allows the client to use the returned DAV:sync-token to fetch the next set of changes. In this way, the client can effectively "page" through the entire set of changes in a consistent manner.

切り捨てが発生した場合、応答で返されるDAV：sync-token値は、返される変更の部分的なセットの正しい状態を表す必要があります。これにより、クライアントは返されたDAV：sync-tokenを使用して、次の変更セットをフェッチできます。このように、クライアントは一貫した方法で一連の変更全体を効果的に「ページング」できます。

Clients MUST handle the 507 status on the request-URI in the response to the report.

クライアントは、レポートへの応答でrequest-URIの507ステータスを処理する必要があります。

For example, consider a server that records changes using a strictly increasing integer to represent a "revision number" and uses that quantity as the DAV:sync-token value (appropriately encoded as a URI). Assume the last DAV:sync-token used by the client was

たとえば、「改訂番号」を表すために厳密に増加する整数を使用して変更を記録し、その数量をDAV：sync-token値（URIとして適切にエンコード）として使用するサーバーを考えてみます。クライアントが最後に使用したDAV：sync-tokenが

"http://example.com/sync/10", and since then 15 additional changes to different resources have occurred. If the client executes a DAV:sync-collection request with a DAV:sync-token of "http://example.com/sync/10", without a limit, the server would return 15 DAV:response elements and a DAV:sync-token with value "http://example.com/sync/25". But if the server chooses to limit responses to at most 10 changes, then it would return only 10 DAV:response elements and a DAV:sync-token with value "http://example.com/sync/20", together with an additional DAV:response element for the request-URI with a status code of 507. Subsequently, the client can reissue the request with the DAV:sync-token value returned from the server and fetch the remaining 5 changes.

「http://example.com/sync/10」以降、さまざまなリソースに対して15の追加の変更が行われました。クライアントがDAV：sync-tokenを "http://example.com/sync/10"に制限なしでDAV：sync-collectionリクエストを実行すると、サーバーは15のDAV：response要素とDAVを返します。値「http://example.com/sync/25」の同期トークン。ただし、サーバーが最大10件の変更に応答を制限することを選択した場合、サーバーは、10個のDAV：response要素と、値 "http://example.com/sync/20"のDAV：sync-tokenを返します。ステータスコード507のrequest-URIの追加のDAV：response要素。その後、クライアントはサーバーから返されたDAV：sync-token値を使用して要求を再発行し、残りの5つの変更をフェッチできます。

3.7. Limiting Results

3.7. 結果を制限する

A client can limit the number of results returned by the server through use of the DAV:limit element ([RFC5323], Section 5.17) in the request body. This is useful when clients have limited space or bandwidth for the results. If a server is unable to truncate the result at or below the requested number, then it MUST fail the request with a DAV:number-of-matches-within-limits postcondition error. When the results can be correctly limited by the server, the server MUST follow the rules above for indicating a result set truncation to the client.

クライアントは、リクエストの本文でDAV：limit要素（[RFC5323]、セクション5.17）を使用して、サーバーから返される結果の数を制限できます。これは、クライアントが結果のスペースまたは帯域幅を制限している場合に役立ちます。サーバーが要求された数以下の結果を切り捨てることができない場合、DAV：number-of-matches-within-limits事後条件エラーで要求を失敗させる必要があります。サーバーが結果を正しく制限できる場合、サーバーは、クライアントに結果セットの切り捨てを示すための上記のルールに従う必要があります。

3.8. Example: Initial DAV:sync-collection Report

3.8. 例：初期DAV：sync-collectionレポート

In this example, the client is making its first synchronization request to the server, so the DAV:sync-token element in the request is empty. It also asks for the DAV:getetag property and for a proprietary property. The server responds with the items currently in the targeted collection. The current synchronization token is also returned.

この例では、クライアントがサーバーに対して最初の同期要求を行っているため、要求のDAV：sync-token要素は空です。また、DAV：getetagプロパティと独自のプロパティも要求します。サーバーは、現在ターゲットコレクションにあるアイテムで応答します。現在の同期トークンも返されます。

   >> Request <<

   REPORT /home/cyrusdaboo/ HTTP/1.1
   Host: webdav.example.com
   Depth: 0
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <D:sync-collection xmlns:D="DAV:">
     <D:sync-token/>
     <D:sync-level>1</D:sync-level>

     <D:prop xmlns:R="urn:ns.example.com:boxschema">
       <D:getetag/>
       <R:bigbox/>
     </D:prop>
   </D:sync-collection>

   >> Response <<

   HTTP/1.1 207 Multi-Status
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <D:multistatus xmlns:D="DAV:">
     <D:response>
       <D:href
   >http://webdav.example.com/home/cyrusdaboo/test.doc</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"00001-abcd1"</D:getetag>
           <R:bigbox xmlns:R="urn:ns.example.com:boxschema">
             <R:BoxType>Box type A</R:BoxType>
           </R:bigbox>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
     </D:response>
     <D:response>
       <D:href
   >http://webdav.example.com/home/cyrusdaboo/vcard.vcf</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"00002-abcd1"</D:getetag>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
       <D:propstat>
         <D:prop>
           <R:bigbox xmlns:R="urn:ns.example.com:boxschema"/>
         </D:prop>
         <D:status>HTTP/1.1 404 Not Found</D:status>
       </D:propstat>
     </D:response>
     <D:response>
       <D:href
   >http://webdav.example.com/home/cyrusdaboo/calendar.ics</D:href>

       <D:propstat>
         <D:prop>
           <D:getetag>"00003-abcd1"</D:getetag>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
       <D:propstat>
         <D:prop>
           <R:bigbox xmlns:R="urn:ns.example.com:boxschema"/>
         </D:prop>
         <D:status>HTTP/1.1 404 Not Found</D:status>
       </D:propstat>
     </D:response>
     <D:sync-token>http://example.com/ns/sync/1234</D:sync-token>
   </D:multistatus>

3.9. Example: DAV:sync-collection Report with Token

3.9. 例：トークンを使用したDAV：sync-collectionレポート

In this example, the client is making a synchronization request to the server and is using the DAV:sync-token element returned from the last report it ran on this collection. The server responds, listing the items that have been added, changed, or removed. The (new) current synchronization token is also returned.

この例では、クライアントはサーバーに同期要求を行い、このコレクションで実行した最後のレポートから返されたDAV：sync-token要素を使用しています。サーバーは応答し、追加、変更、または削除されたアイテムをリストします。（新しい）現在の同期トークンも返されます。

   >> Request <<

   REPORT /home/cyrusdaboo/ HTTP/1.1
   Host: webdav.example.com
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <D:sync-collection xmlns:D="DAV:">
     <D:sync-token>http://example.com/ns/sync/1234</D:sync-token>
     <D:sync-level>1</D:sync-level>
     <D:prop xmlns:R="urn:ns.example.com:boxschema">
       <D:getetag/>
       <R:bigbox/>
     </D:prop>
   </D:sync-collection>

   >> Response <<

   HTTP/1.1 207 Multi-Status
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <D:multistatus xmlns:D="DAV:">
     <D:response>
       <D:href
   >http://webdav.example.com/home/cyrusdaboo/file.xml</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"00004-abcd1"</D:getetag>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
       <D:propstat>
         <D:prop>
           <R:bigbox xmlns:R="urn:ns.example.com:boxschema"/>
         </D:prop>
         <D:status>HTTP/1.1 404 Not Found</D:status>
       </D:propstat>
     </D:response>
     <D:response>
       <D:href
   >http://webdav.example.com/home/cyrusdaboo/vcard.vcf</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"00002-abcd2"</D:getetag>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
       <D:propstat>
         <D:prop>
           <R:bigbox xmlns:R="urn:ns.example.com:boxschema"/>
         </D:prop>
         <D:status>HTTP/1.1 404 Not Found</D:status>
       </D:propstat>
     </D:response>
     <D:response>
       <D:href
   >http://webdav.example.com/home/cyrusdaboo/test.doc</D:href>
       <D:status>HTTP/1.1 404 Not Found</D:status>
     </D:response>
     <D:sync-token>http://example.com/ns/sync/1238</D:sync-token>
   </D:multistatus>

3.10. Example: Initial DAV:sync-collection Report with Truncation

3.10. 例：切り捨てを含む初期DAV：sync-collectionレポート

In this example, the client is making its first synchronization request to the server, so the DAV:sync-token element in the request is empty. It also asks for the DAV:getetag property. The server responds with the items currently in the targeted collection but truncated at two items. The synchronization token for the truncated result set is returned.

この例では、クライアントがサーバーに対して最初の同期要求を行っているため、要求のDAV：sync-token要素は空です。また、DAV：getetagプロパティも要求します。サーバーは、対象のコレクションに現在あるが2つの項目で切り捨てられた項目で応答します。切り捨てられた結果セットの同期トークンが返されます。

   >> Request <<

   REPORT /home/cyrusdaboo/ HTTP/1.1
   Host: webdav.example.com
   Depth: 0
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <D:sync-collection xmlns:D="DAV:">
     <D:sync-token/>
     <D:sync-level>1</D:sync-level>
     <D:prop>
       <D:getetag/>
     </D:prop>
   </D:sync-collection>

   >> Response <<

   HTTP/1.1 207 Multi-Status
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <D:multistatus xmlns:D="DAV:">
     <D:response>
       <D:href
   >http://webdav.example.com/home/cyrusdaboo/test.doc</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"00001-abcd1"</D:getetag>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
     </D:response>
     <D:response>

       <D:href
   >http://webdav.example.com/home/cyrusdaboo/vcard.vcf</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"00002-abcd1"</D:getetag>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
     </D:response>
     <D:response>
       <D:href
   >http://webdav.example.com/home/cyrusdaboo/</D:href>
       <D:status>HTTP/1.1 507 Insufficient Storage</D:status>
       <D:error><D:number-of-matches-within-limits/></D:error>
     </D:response>
     <D:sync-token>http://example.com/ns/sync/1233</D:sync-token>
   </D:multistatus>

3.11. Example: Initial DAV:sync-collection Report with Limit

3.11. 例：制限付きの初期DAV：sync-collectionレポート

In this example, the client is making its first synchronization request to the server, so the DAV:sync-token element in the request is empty. It requests a limit of 1 for the responses returned by the server. It also asks for the DAV:getetag property. The server responds with the items currently in the targeted collection, but truncated at one item. The synchronization token for the truncated result set is returned.

この例では、クライアントがサーバーに対して最初の同期要求を行っているため、要求のDAV：sync-token要素は空です。サーバーから返される応答に1の制限を要求します。また、DAV：getetagプロパティも要求します。サーバーは、現在ターゲットのコレクションにあるアイテムで応答しますが、1つのアイテムで切り捨てられます。切り捨てられた結果セットの同期トークンが返されます。

   >> Request <<

   REPORT /home/cyrusdaboo/ HTTP/1.1
   Host: webdav.example.com
   Depth: 0
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <D:sync-collection xmlns:D="DAV:">
     <D:sync-token/>
     <D:sync-level>1</D:sync-level>
     <D:limit>
       <D:nresults>1</D:nresults>
     </D:limit>
     <D:prop>
       <D:getetag/>
     </D:prop>
   </D:sync-collection>

   >> Response <<

   HTTP/1.1 207 Multi-Status
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <D:multistatus xmlns:D="DAV:">
     <D:response>
       <D:href
   >http://webdav.example.com/home/cyrusdaboo/test.doc</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"00001-abcd1"</D:getetag>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
     </D:response>
     <D:response>
       <D:href
   >http://webdav.example.com/home/cyrusdaboo/</D:href>
       <D:status>HTTP/1.1 507 Insufficient Storage</D:status>
       <D:error><D:number-of-matches-within-limits/></D:error>
     </D:response>
     <D:sync-token>http://example.com/ns/sync/1232</D:sync-token>
   </D:multistatus>

3.12. Example: DAV:sync-collection Report with Unsupported Limit

3.12. 例：サポートされていない制限があるDAV：sync-collectionレポート

In this example, the client is making a synchronization request to the server with a valid DAV:sync-token element value. It requests a limit of 100 for the responses returned by the server. It also asks for the DAV:getetag property. The server is unable to limit the results to the maximum specified by the client, so it responds with a 507 status code and appropriate postcondition error code.

この例では、クライアントは有効なDAV：sync-token要素の値を使用してサーバーに同期要求を行っています。サーバーから返される応答に100の制限を要求します。また、DAV：getetagプロパティも要求します。サーバーは結果をクライアントが指定した最大数に制限できないため、507ステータスコードと適切な事後条件エラーコードで応答します。

   >> Request <<

   REPORT /home/cyrusdaboo/ HTTP/1.1
   Host: webdav.example.com
   Depth: 0
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <D:sync-collection xmlns:D="DAV:">
     <D:sync-token>http://example.com/ns/sync/1232</D:sync-token>
     <D:sync-level>1</D:sync-level>
     <D:limit>
       <D:nresults>100</D:nresults>
     </D:limit>
     <D:prop>
       <D:getetag/>
     </D:prop>
   </D:sync-collection>

   >> Response <<

   HTTP/1.1 507 Insufficient Storage
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <D:error xmlns:D="DAV:">
     <D:number-of-matches-within-limits/>
   </D:error>

3.13. Example: DAV:sync-level Set to Infinite, Initial DAV:sync-collection Report

3.13. 例：DAV：sync-levelを無限に設定、初期DAV：sync-collectionレポート

In this example, the client is making its first synchronization request to the server, so the DAV:sync-token element in the request is empty, and it is using DAV:sync-level set to "infinite". It also asks for the DAV:getetag property and for a proprietary property. The server responds with the items currently in the targeted collection. The current synchronization token is also returned.

この例では、クライアントがサーバーに対して最初の同期要求を行っているため、要求のDAV：sync-token要素は空であり、DAV：sync-levelを "infinite"に設定して使用しています。また、DAV：getetagプロパティと独自のプロパティも要求します。サーバーは、現在ターゲットコレクションにあるアイテムで応答します。現在の同期トークンも返されます。

The collection /home/cyrusdaboo/collection1/ exists and has one child resource that is also reported. The collection /home/cyrusdaboo/ collection2/ exists but has no child resources. The collection /home/cyrusdaboo/shared/ is returned with a 403 status indicating that a collection exists, but it is unable to report on changes within it in the scope of the current DAV:sync-level "infinite" report. Instead, the client can try a DAV:sync-collection report directly on the collection URI.

コレクション/ home / cyrusdaboo / collection1 /が存在し、1つの子リソースも報告されます。コレクション/ home / cyrusdaboo / collection2 /は存在しますが、子リソースはありません。コレクション/ home / cyrusdaboo / shared /は、コレクションが存在することを示す403ステータスで返されますが、現在のDAV：syncレベルの「無限」レポートのスコープ内のコレクション内の変更についてレポートすることはできません。代わりに、クライアントはコレクションURIでDAV：sync-collectionレポートを直接試すことができます。

   >> Request <<

   REPORT /home/cyrusdaboo/ HTTP/1.1
   Host: webdav.example.com
   Depth: 0
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <D:sync-collection xmlns:D="DAV:">
     <D:sync-token/>
     <D:sync-level>infinite</D:sync-level>
     <D:prop xmlns:R="urn:ns.example.com:boxschema">
       <D:getetag/>
       <R:bigbox/>
     </D:prop>
   </D:sync-collection>

   >> Response <<

   HTTP/1.1 207 Multi-Status
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <D:multistatus xmlns:D="DAV:">
     <D:response>
       <D:href>/home/cyrusdaboo/collection1/</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"00001-abcd1"</D:getetag>
           <R:bigbox xmlns:R="urn:ns.example.com:boxschema">
             <R:BoxType>Box type A</R:BoxType>
           </R:bigbox>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
     </D:response>
     <D:response>
       <D:href>/home/cyrusdaboo/collection1/test.doc</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"00001-abcd1"</D:getetag>
           <R:bigbox xmlns:R="urn:ns.example.com:boxschema">
             <R:BoxType>Box type A</R:BoxType>

           </R:bigbox>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
     </D:response>
     <D:response>
       <D:href>/home/cyrusdaboo/collection2/</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag/>
         </D:prop>
         <D:status>HTTP/1.1 404 Not Found</D:status>
       </D:propstat>
       <D:propstat>
         <D:prop>
           <R:bigbox xmlns:R="urn:ns.example.com:boxschema"/>
         </D:prop>
         <D:status>HTTP/1.1 404 Not Found</D:status>
       </D:propstat>
     </D:response>
     <D:response>
       <D:href>/home/cyrusdaboo/calendar.ics</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"00003-abcd1"</D:getetag>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
       <D:propstat>
         <D:prop>
           <R:bigbox xmlns:R="urn:ns.example.com:boxschema"/>
         </D:prop>
         <D:status>HTTP/1.1 404 Not Found</D:status>
       </D:propstat>
     </D:response>
     <D:response>
       <D:href>/home/cyrusdaboo/shared/</D:href>
       <D:status>HTTP/1.1 403 Forbidden</D:status>
       <D:error><D:sync-traversal-supported/></D:error>
     </D:response>
     <D:sync-token>http://example.com/ns/sync/1234</D:sync-token>
   </D:multistatus>

4. DAV:sync-token Property

4. DAV：sync-tokenプロパティ

Name: sync-token

名前：同期トークン

Namespace: DAV:

名前空間：DAV：

Purpose: Contains the value of the synchronization token as it would be returned by a DAV:sync-collection report.

目的：DAV：sync-collectionレポートによって返される同期トークンの値を含みます。

Value: Any valid URI.

値：任意の有効なURI。

Protected: MUST be protected because this value is created and controlled by the server.

保護：この値はサーバーによって作成および制御されるため、保護する必要があります。

COPY/MOVE behavior: This property value is dependent on the final state of the destination resource, not the value of the property on the source resource.

コピー/移動の動作：このプロパティ値は、ソースリソースのプロパティの値ではなく、宛先リソースの最終状態に依存します。

Description: The DAV:sync-token property MUST be defined on all resources that support the DAV:sync-collection report. It contains the value of the synchronization token as it would be returned by a DAV:sync-collection report on that resource at the same point in time. It SHOULD NOT be returned by a PROPFIND DAV:allprop request (as defined in Section 14.2 of [RFC4918]).

説明：DAV：sync-collectionレポートをサポートするすべてのリソースでDAV：sync-tokenプロパティを定義する必要があります。同期トークンの値が含まれます。これは、そのリソースのDAV：sync-collectionレポートによって同時に返されるためです。 PROPFIND DAV：allpropリクエスト（[RFC4918]のセクション14.2で定義）によって返されるべきではない（SHOULD NOT）。

Definition:

定義：

   <!ELEMENT sync-token #PCDATA>

   <!-- Text MUST be a valid URI -->

5. DAV:sync-token Use with If Header

5. DAV：syncトークンとIfヘッダーの使用

WebDAV provides an If precondition header that allows for "state tokens" to be used as preconditions on HTTP requests (as defined in Section 10.4 of [RFC4918]). This specification allows the DAV:sync-token value to be used as one such token in an If header. By using this, clients can ensure requests only complete when there have been no changes to the content of a collection, by virtue of an unchanged DAV:sync-token value. Servers MUST support use of DAV:sync-token values in If request headers.

WebDAVは、HTTPリクエストの前提条件として「状態トークン」を使用できるようにするIf前提条件ヘッダーを提供します（[RFC4918]のセクション10.4で定義）。この仕様では、DAV：sync-token値をそのようなトークンとしてIfヘッダーで使用できます。これを使用することで、クライアントは、変更されていないDAV：sync-token値により、コレクションのコンテンツに変更がなかった場合にのみリクエストが完了するようにすることができます。サーバーは、IfリクエストヘッダーでのDAV：sync-token値の使用をサポートする必要があります。

5.1. Example: If Precondition with PUT

5.1. 例：PUTの前提条件

In this example, the client has already used the DAV:sync-collection report to synchronize the collection /home/cyrusdaboo/collection/. Now it wants to add a new resource to the collection, but only if there have been no other changes since the last synchronization.

この例では、クライアントはすでにDAV：sync-collectionレポートを使用して、コレクション/ home / cyrusdaboo / collection /を同期しています。ここで、コレクションに新しいリソースを追加する必要がありますが、最後の同期以降に他の変更がない場合のみです。

Note that because the DAV:sync-token is defined on the collection and not on the resource targeted by the request, the If header value needs to use the "Resource_Tag" construct for the header syntax to correctly identify that the supplied state token refers to the collection resource.

DAV：sync-tokenは、リクエストのターゲットとなるリソースではなくコレクションで定義されているため、Ifヘッダー値は、ヘッダー構文の「Resource_Tag」コンストラクトを使用して、提供された状態トークンが参照することを正しく識別する必要があることに注意してください。コレクションリソース。

   >> Request <<

   PUT /home/cyrusdaboo/collection/newresource.txt HTTP/1.1
   Host: webdav.example.com
   If: </home/cyrusdaboo/collection/>
     (<http://example.com/ns/sync/12345>)
   Content-Type: text/plain; charset="utf-8"
   Content-Length: xxxx

Some content here...

ここにいくつかのコンテンツ...

   >> Response <<

HTTP/1.1 201 Created

HTTP / 1.1 201作成

5.2. Example: If Precondition with MKCOL

5.2. 例：MKCOLの前提条件

In this example, the client has already used the DAV:sync-collection report to synchronize the collection /home/cyrusdaboo/collection/. Now, it wants to add a new collection to the collection, but only if there have been no other changes since the last synchronization. Note that because the DAV:sync-token is defined on the collection and not on the resource targeted by the request, the If header value needs to use the "Resource_Tag" construct for the header syntax to correctly identify that the supplied state token refers to the collection resource. In this case, the request fails as another change has occurred to the collection corresponding to the supplied DAV:sync-token.

この例では、クライアントはすでにDAV：sync-collectionレポートを使用して、コレクション/ home / cyrusdaboo / collection /を同期しています。ここで、新しいコレクションをコレクションに追加しようとしていますが、最後の同期以降に他の変更がない場合のみです。 DAV：sync-tokenは、リクエストのターゲットとなるリソースではなくコレクションで定義されているため、Ifヘッダー値は、ヘッダー構文の「Resource_Tag」コンストラクトを使用して、提供された状態トークンが参照することを正しく識別する必要があることに注意してください。コレクションリソース。この場合、提供されたDAV：sync-tokenに対応するコレクションに別の変更が発生したため、要求は失敗します。

   >> Request <<

   MKCOL /home/cyrusdaboo/collection/child/ HTTP/1.1
   Host: webdav.example.com
   If: </home/cyrusdaboo/collection/>
     (<http://example.com/ns/sync/12346>)

   >> Response <<

HTTP/1.1 412 Precondition Failed

HTTP / 1.1 412前提条件が失敗しました

6. XML Element Definitions

6. XML要素の定義

6.1. DAV:sync-collection XML Element

6.1. DAV：sync-collection XML要素

Name: sync-collection

名前：sync-collection

Namespace: DAV:

名前空間：DAV：

Purpose: WebDAV report used to synchronize data between client and server.

目的：クライアントとサーバー間でデータを同期するために使用されるWebDAVレポート。

Description: See Section 3.

説明：セクション3を参照してください。

   <!ELEMENT sync-collection (sync-token, sync-level, limit?, prop)>

   <!-- DAV:limit defined in RFC 5323, Section 5.17 -->
   <!-- DAV:prop defined in RFC 4918, Section 14.18 -->

6.2. DAV:sync-token XML Element

6.2. だＶ：ｓｙんｃーとけんＸＭＬえぇめんｔ

Name: sync-token

名前：同期トークン

Namespace: DAV:

名前空間：DAV：

Purpose: The synchronization token provided by the server and returned by the client.

目的：サーバーから提供され、クライアントから返される同期トークン。

Description: See Section 3.

説明：セクション3を参照してください。

   <!ELEMENT sync-token CDATA>

   <!-- Text MUST be a URI -->

6.3. DAV:sync-level XML Element

6.3. DAV：同期レベルのXML要素

Name: sync-level

名前：同期レベル

Namespace: DAV:

名前空間：DAV：

Purpose: Indicates the "scope" of the synchronization report request.

目的：同期レポート要求の「範囲」を示します。

Description: See Section 3.3.

説明：セクション3.3を参照してください。

   <!ELEMENT sync-level CDATA>

   <!-- Text MUST be either "1" or "infinite" -->

6.4. DAV:multistatus XML Element

6.4. Dav：マルチステートXML要素

Name: multistatus

名前：multistatus

Namespace: DAV:

名前空間：DAV：

Purpose: Extends the DAV:multistatus element to include synchronization details.

目的：DAV：multistatus要素を拡張して、同期の詳細を含めます。

Description: See Section 3.

説明：セクション3を参照してください。

   <!ELEMENT multistatus (response*, responsedescription?,
                          sync-token?) >

   <!-- DAV:multistatus originally defined in RFC 4918, Section 14.16
        but overridden here to add the DAV:sync-token element -->
   <!-- DAV:response defined in RFC 4918, Section 14.24 -->
   <!-- DAV:responsedescription defined in RFC 4918, Section 14.25 -->

7. Security Considerations

7. セキュリティに関する考慮事項

This extension does not introduce any new security concerns beyond those already described in HTTP and WebDAV.

この拡張機能は、HTTPおよびWebDAVですでに説明されているものを超える新しいセキュリティ上の懸念をもたらしません。

8. Acknowledgments

8. 謝辞

The following individuals contributed their ideas and support for writing this specification: Bernard Desruisseaux, Werner Donne, Mike Douglass, Ciny Joy, Andrew McMillan, Julian Reschke, and Wilfredo Sanchez. We would like to thank the Calendaring and Scheduling Consortium for facilitating interoperability testing for early implementations of this specification.

次の個人がこの仕様を書くためのアイデアとサポートを提供しました：Bernard Desruisseaux、Werner Donne、Mike Douglass、Ciny Joy、Andrew McMillan、Julian Reschke、およびWilfredo Sanchez。この仕様の初期実装の相互運用性テストを容易にしてくれたCalendaring and Scheduling Consortiumに感謝します。

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

[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月。

[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。、および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、「Versioning Extensions to WebDAV（Web Distributed Authoring and Versioning）」、RFC 3253、2002年3月。

[RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol", RFC 3744, May 2004.

[RFC3744] Clemm、G.、Reschke、J.、Sedlar、E。、およびJ. Whitehead、「Web Distributed Authoring and Versioning（WebDAV）Access Control Protocol」、RFC 3744、2004年5月。

[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.

[RFC4918] Dusseault、L。、「Web Distributed Authoring and Versioning（WebDAV）のHTTP拡張機能」、RFC 4918、2007年6月。

[RFC5323] Reschke, J., Reddy, S., Davis, J., and A. Babich, "Web Distributed Authoring and Versioning (WebDAV) SEARCH", RFC 5323, November 2008.

[RFC5323] Reschke、J.、Reddy、S.、Davis、J。、およびA. Babich、「Web Distributed Authoring and Versioning（WebDAV）SEARCH」、RFC 5323、2008年11月。

[W3C.REC-xml-20081126] Sperberg-McQueen, C., Yergeau, F., Paoli, J., Maler, E., and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126>.

[W3C.REC-xml-20081126] Sperberg-McQueen、C.、Yergeau、F.、Paoli、J.、Maler、E。、およびT. Bray、「Extensible Markup Language（XML）1.0（Fifth Edition）」、 World Wide Web Consortium Recommendation REC-xml-20081126、2008年11月、<http://www.w3.org/TR/2008/REC-xml-20081126>。

9.2. Informative References

9.2. 参考引用

[RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, March 2007.

[RFC4791] Daboo、C.、Desruisseaux、B。、およびL. Dusseault、「Calendaring Extensions to WebDAV（CalDAV）」、RFC 4791、2007年3月。

[RFC5842] Clemm, G., Crawford, J., Reschke, J., and J. Whitehead, "Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)", RFC 5842, April 2010.

[RFC5842] Clemm、G.、Crawford、J.、Reschke、J。、およびJ. Whitehead、「Binding Extensions to Web Distributed Authoring and Versioning（WebDAV）」、RFC 5842、2010年4月。

[RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)", RFC 6352, August 2011.

[RFC6352] Daboo、C。、「CardDAV：vCard Extensions to Web Distributed Authoring and Versioning（WebDAV）」、RFC 6352、2011年8月。

Appendix A. Backwards-Compatible Handling of Depth

付録A.下位互換性のある深さの処理

In prior draft versions of this specification, the Depth request header was used instead of the DAV:sync-level element to indicate the "scope" of the synchronization request. Servers that wish to be backwards compatible with clients conforming to the older specification should do the following: if a DAV:sync-level element is not present in the request body, use the Depth header value as the equivalent value for the missing DAV:sync-level element.

この仕様の以前のドラフトバージョンでは、同期リクエストの「スコープ」を示すために、DAV：sync-level要素の代わりに深度リクエストヘッダーが使用されていました。古い仕様に準拠するクライアントとの下位互換性を希望するサーバーは、次のことを行う必要があります。DAV：sync-level要素がリクエストの本文に存在しない場合は、Depthヘッダー値を欠落しているDAV：syncの同等の値として使用しますレベル要素。

Appendix B. Example of a Client Synchronization Approach

付録B.クライアント同期アプローチの例

This appendix gives an example of how a client might accomplish collection synchronization using the WebDAV sync report defined in this specification. Note that this is provided purely as an example, and is not meant to be treated as a normative "algorithm" for client synchronization.

この付録では、クライアントがこの仕様で定義されているWebDAV同期レポートを使用してコレクション同期を実行する方法の例を示します。これは純粋に例として提供されており、クライアント同期の規範的な「アルゴリズム」として扱われることを意図していないことに注意してください。

This example assumes a WebDAV client interacting with a WebDAV server supporting the sync report. The client keeps a local cache of resources in a targeted collection, "/collection/". Local changes are assumed to not occur. The client is only tracking changes to the immediate children of the collection resource.

この例では、同期レポートをサポートするWebDAVサーバーと対話するWebDAVクライアントを想定しています。クライアントは、ターゲットのコレクション「/ collection /」にリソースのローカルキャッシュを保持します。ローカル変更は発生しないと想定されています。クライアントは、コレクションリソースの直接の子に対する変更のみを追跡します。

      ** Initial State **

The client starts out with an empty local cache.

クライアントは、空のローカルキャッシュから開始します。

The client starts out with no DAV:sync-token stored for "/collection/".

クライアントは、 "/ collection /"に保存されているDAV：sync-tokenなしで開始します。

      ** Initial Synchronization **

The client issues a sync report request to the server with an empty DAV:sync-token element, and DAV:sync-level set to "1". The request asks for the server to return the DAV:getetag WebDAV property for each resource it reports.

クライアントは、DAV：sync-token要素が空で、DAV：sync-levelが "1"に設定されているサーバーに同期レポート要求を発行します。リクエストは、サーバーが報告する各リソースのDAV：getetag WebDAVプロパティを返すようサーバーに要求します。

The server returns a response containing the list of current resources (with their associated DAV:getetag properties) as well as a new DAV:sync-token value.

サーバーは、現在のリソース（および関連するDAV：getetagプロパティ）のリストと新しいDAV：sync-token値を含む応答を返します。

The client associates the new DAV:sync-token value with the collection.

クライアントは、新しいDAV：sync-token値をコレクションに関連付けます。

For each reported resource, the client creates a set of (resource path, DAV:getetag) tuples.

レポートされたリソースごとに、クライアントは（リソースパス、DAV：getetag）タプルのセットを作成します。

For each tuple, the client issues an HTTP GET request to the server to retrieve its content, and updates the (resource path, DAV:getetag) entry in its local cache for that resource with the ETag response header value returned in the GET request.

タプルごとに、クライアントはHTTP GET要求をサーバーに発行してそのコンテンツを取得し、GET要求で返されたETag応答ヘッダー値でそのリソースのローカルキャッシュ内の（リソースパス、DAV：getetag）エントリを更新します。

      ** Routine Synchronization **

The client issues a sync report request to the server with the DAV:sync-token set to the current cached value from the last sync, and DAV:sync-level set to "1". The request asks for the server to return the DAV:getetag WebDAV property for each resource it reports.

クライアントは、DAV：sync-tokenを最後の同期の現在のキャッシュ値に設定し、DAV：sync-levelを "1"に設定して、サーバーに同期レポート要求を発行します。リクエストは、サーバーが報告する各リソースのDAV：getetag WebDAVプロパティを返すようサーバーに要求します。

The server returns a response containing the list of changes as well as a new DAV:sync-token value.

サーバーは、変更のリストと新しいDAV：sync-token値を含む応答を返します。

The client associates the new DAV:sync-token value with the collection.

クライアントは、新しいDAV：sync-token値をコレクションに関連付けます。

* Process Removed Resources *

* 削除されたリソースの処理*

For each resource reported with a 404 response status, the client removes the corresponding resource from its local cache.

404応答ステータスで報告された各リソースについて、クライアントは対応するリソースをローカルキャッシュから削除します。

* Process Resources *

* プロセスリソース*

For each remaining reported resource, the client creates a new set of (resource path, DAV:getetag) tuples.

報告された残りの各リソースについて、クライアントは（リソースパス、DAV：getetag）タプルの新しいセットを作成します。

The client then determines which resources are in the new set but not in the current cache, and which resources are in the new set and the current cache but have a different DAV:getetag value. For each of those, the client issues an HTTP GET request to the server to retrieve the resource content, and updates the (resource path, DAV:getetag) entry in its local cache for that resource with the ETag response header value returned in the GET request.

次に、クライアントは、どのリソースが新しいセットにあるが現在のキャッシュにはないか、どのリソースが新しいセットと現在のキャッシュにあるが異なるDAV：getetag値を持つかを決定します。これらのそれぞれについて、クライアントはHTTP GETリクエストをサーバーに発行してリソースコンテンツを取得し、GETで返されたETag応答ヘッダー値でそのリソースのローカルキャッシュ内の（リソースパス、DAV：getetag）エントリを更新しますリクエスト。

Authors' Addresses

著者のアドレス

Cyrus Daboo Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA

Cyrus Daboo Apple Inc.1 Infinite Loop Cupertino、CA 95014 USA

   EMail: cyrus@daboo.name
   URI:   http://www.apple.com/

Arnaud Quillaud Oracle Corporation 180, Avenue de l'Europe Saint Ismier cedex 38334 France

Arnaud Quillaud Oracle Corporation 180、Avenue de l'Europe Saint Ismier cedex 38334 France

   EMail: arnaud.quillaud@oracle.com
   URI:   http://www.oracle.com/

RFC 6578 - Collection Synchronization for Web Distributed Authoring and Versioning (WebDAV) 日本語訳

1. Introduction

1. はじめに

2. Conventions Used in This Document

2. このドキュメントで使用される規則

3. WebDAV Synchronization

3. WebDAV同期

3.1. Overview

3.1. 概観

3.2. DAV:sync-collection Report

3.2. DAV：sync-collectionレポート

3.3. Depth Behavior

3.3. 深度動作

3.4. Types of Changes Reported on Initial Synchronization

3.4. 初期同期で報告される変更のタイプ

3.5. Types of Changes Reported on Subsequent Synchronizations

3.5. 後続の同期で報告される変更のタイプ

3.5.1. Changed Member

3.5.1. 変更されたメンバー

3.5.2. Removed Member

3.5.2. 削除されたメンバー

3.6. Truncation of Results

3.6. 結果の切り捨て

3.7. Limiting Results

3.7. 結果を制限する

3.8. Example: Initial DAV:sync-collection Report

3.8. 例：初期DAV：sync-collectionレポート

3.9. Example: DAV:sync-collection Report with Token

3.9. 例：トークンを使用したDAV：sync-collectionレポート

3.10. Example: Initial DAV:sync-collection Report with Truncation

3.10. 例：切り捨てを含む初期DAV：sync-collectionレポート

3.11. Example: Initial DAV:sync-collection Report with Limit

3.11. 例：制限付きの初期DAV：sync-collectionレポート

3.12. Example: DAV:sync-collection Report with Unsupported Limit

3.12. 例：サポートされていない制限があるDAV：sync-collectionレポート

4. DAV:sync-token Property

4. DAV：sync-tokenプロパティ

5. DAV:sync-token Use with If Header

5. DAV：syncトークンとIfヘッダーの使用

5.1. Example: If Precondition with PUT

5.1. 例：PUTの前提条件

5.2. Example: If Precondition with MKCOL

5.2. 例：MKCOLの前提条件

6. XML Element Definitions

6. XML要素の定義

6.1. DAV:sync-collection XML Element

6.1. DAV：sync-collection XML要素

6.2. DAV:sync-token XML Element

6.2. だＶ：ｓｙんｃーとけん ＸＭＬ えぇめんｔ

6.3. DAV:sync-level XML Element

6.3. DAV：同期レベルのXML要素

6.4. DAV:multistatus XML Element

6.4. Dav：マルチステートXML要素

7. Security Considerations

7. セキュリティに関する考慮事項

8. Acknowledgments

8. 謝辞

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

9.2. Informative References

9.2. 参考引用

Appendix A. Backwards-Compatible Handling of Depth

付録A.下位互換性のある深さの処理

Appendix B. Example of a Client Synchronization Approach

付録B.クライアント同期アプローチの例

6.2. だＶ：ｓｙんｃーとけんＸＭＬえぇめんｔ