[要約] RFC 8607は、CalDAVプロトコルによるカレンダーの拡張であり、管理された添付ファイルをサポートします。その目的は、カレンダーアイテムに関連する添付ファイルの管理と操作を容易にすることです。
Internet Engineering Task Force (IETF) C. Daboo
Request for Comments: 8607 Apple
Category: Informational A. Quillaud
ISSN: 2070-1721 Oracle
K. Murchison, Ed.
FastMail
June 2019
Calendaring Extensions to WebDAV (CalDAV): Managed Attachments
WebDAVのカレンダー拡張（CalDAV）：管理された添付ファイル
Abstract
概要
This specification adds an extension to the Calendaring Extensions to WebDAV (CalDAV) to allow attachments associated with iCalendar data to be stored and managed on the server.
この仕様では、iCalendarデータに関連付けられた添付ファイルをサーバーに保存および管理できるようにするために、Calendaring Extensions to WebDAV（CalDAV）に拡張機能を追加しています。
This specification documents existing code deployed by multiple vendors. It is published as an Informational specification rather than Standards Track due to its noncompliance with multiple best current practices of HTTP.
この仕様は、複数のベンダーによって展開された既存のコードを文書化しています。現在のHTTPの複数のベストプラクティスに準拠していないため、標準トラックではなく情報仕様として公開されています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8607.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8607で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Rationale for Informational Status . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Discovering Support for Managed Attachments . . . . . . . 5
3.3. POST Request for Managing Attachments . . . . . . . . . . 6
3.3.1. action Query Parameter . . . . . . . . . . . . . . . 6
3.3.2. rid Query Parameter . . . . . . . . . . . . . . . . . 6
3.3.3. managed-id Query Parameter . . . . . . . . . . . . . 7
3.4. Adding Attachments . . . . . . . . . . . . . . . . . . . 7
3.5. Updating Attachments . . . . . . . . . . . . . . . . . . 10
3.6. Removing Attachments via POST . . . . . . . . . . . . . . 13
3.7. Adding Existing Managed Attachments via PUT . . . . . . . 15
3.8. Updating Attachments via PUT . . . . . . . . . . . . . . 15
3.9. Removing Attachments via PUT . . . . . . . . . . . . . . 15
3.10. Retrieving Attachments . . . . . . . . . . . . . . . . . 15
3.11. Error Handling . . . . . . . . . . . . . . . . . . . . . 16
3.12. Additional Considerations . . . . . . . . . . . . . . . . 17
3.12.1. Quotas . . . . . . . . . . . . . . . . . . . . . . . 17
3.12.2. Access Control . . . . . . . . . . . . . . . . . . . 17
3.12.3. Redirects . . . . . . . . . . . . . . . . . . . . . 18
3.12.4. Processing Time . . . . . . . . . . . . . . . . . . 18
3.12.5. Automatic Cleanup by Servers . . . . . . . . . . . . 18
3.12.6. Sending Scheduling Messages with Attachments . . . . 18
3.12.7. Migrating Calendar Data . . . . . . . . . . . . . . 18
4. Modifications to iCalendar Syntax . . . . . . . . . . . . . . 19
4.1. SIZE Property Parameter . . . . . . . . . . . . . . . . . 19
4.2. FILENAME Property Parameter . . . . . . . . . . . . . . . 19
4.3. MANAGED-ID Property Parameter . . . . . . . . . . . . . . 20
5. Additional Message Header Fields . . . . . . . . . . . . . . 20
5.1. Cal-Managed-ID Response Header Field . . . . . . . . . . 20
6. Additional WebDAV Properties . . . . . . . . . . . . . . . . 21
6.1. CALDAV:managed-attachments-server-URL Property . . . . . 21
6.2. CALDAV:max-attachment-size Property . . . . . . . . . . . 22
6.3. CALDAV:max-attachments-per-resource Property . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8.1. Parameter Registrations . . . . . . . . . . . . . . . . . 24
8.2. Message Header Field Registrations . . . . . . . . . . . 25
8.2.1. Cal-Managed-ID . . . . . . . . . . . . . . . . . . . 25
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Normative References . . . . . . . . . . . . . . . . . . 25
9.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Example Involving Recurring Events . . . . . . . . . 28
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
The iCalendar [RFC5545] data format is used to represent calendar data and is used with iCalendar Transport-independent Interoperability Protocol (iTIP) [RFC5546] to handle scheduling operations between calendar users.
iCalendar [RFC5545]データ形式は、カレンダーデータを表すために使用され、iCalendarトランスポート独立相互運用プロトコル（iTIP）[RFC5546]と共に使用して、カレンダーユーザー間のスケジュール操作を処理します。
[RFC4791] defines the Calendaring Extensions to WebDAV (CalDAV), based on HTTP [RFC7230], for accessing calendar data stored on a server.
[RFC4791]は、サーバーに保存されているカレンダーデータにアクセスするための、HTTP [RFC7230]に基づくWebDAV（CalDAV）のカレンダー拡張機能を定義します。
Calendar users often want to include attachments with their calendar data events or tasks (for example, a copy of a presentation or the meeting agenda). iCalendar provides an "ATTACH" property whose value is either the inline Base64 encoded attachment data or a URL specifying the location of the attachment data.
カレンダーユーザーは、添付ファイルをカレンダーデータのイベントまたはタスク（たとえば、プレゼンテーションのコピーや会議の議題）に含めたいことがよくあります。 iCalendarは、値がインラインBase64エンコードされた添付データまたは添付データの場所を指定するURLのいずれかである「ATTACH」プロパティを提供します。
Use of inline attachment data is not ideal with CalDAV because the data would need to be uploaded to the server each time a change to the calendar data is made, even minor changes such as a change to the summary. Whilst a client could choose to use a URL value instead, the problem then becomes where and how the client discovers an appropriate URL to use and how it ensures that only those attendees listed in the event or task are able to access it.
CalDAVでは、インライン添付ファイルデータの使用は理想的ではありません。これは、カレンダーデータに変更が加えられるたびに、要約への変更などの小さな変更であっても、サーバーにデータをアップロードする必要があるためです。クライアントは代わりにURL値を使用することを選択できますが、問題は、クライアントが使用する適切なURLをどこでどのように見つけ、イベントまたはタスクにリストされている参加者だけがアクセスできるようにするかです。
This specification solves this problem by having the client send the attachment to the server, separately from the iCalendar data, and having the server add appropriate "ATTACH" properties in the iCalendar data as well as manage access privileges. The server can also provide additional information to the client about each attachment in the iCalendar data, such as the size and an identifier.
この仕様では、クライアントがiCalendarデータとは別に添付ファイルをサーバーに送信し、サーバーが適切な「ATTACH」プロパティをiCalendarデータに追加し、アクセス権を管理することで、この問題を解決しています。サーバーは、サイズや識別子など、iCalendarデータの各添付ファイルに関する追加情報をクライアントに提供することもできます。
Although this extension to CalDAV has wide deployment, its design does not comply with some of the best current practices of HTTP, namely:
CalDAVへのこの拡張は広範囲に展開されていますが、その設計はHTTPの現在のベストプラクティスの一部に準拠していません。
o All operations on attachments are modeled as HTTP POST operations, where the actual type of operation is specified using a query parameter instead of using separate HTTP POST, PUT, and DELETE methods where appropriate.
o 添付ファイルに対するすべての操作はHTTP POST操作としてモデル化され、実際の操作のタイプは、適切な場所で個別のHTTP POST、PUT、およびDELETEメソッドを使用する代わりに、クエリパラメータを使用して指定されます。
o Specific query strings are hardwired into the protocol in violation of Section 2.4 of [RFC7320].
o [RFC7320]のセクション2.4に違反して、特定のクエリ文字列がプロトコルに組み込まれています。
Additionally, this extension misuses the Content-Disposition header field [RFC6266] as a request header field to convey a filename for an attachment rather than using an existing request header field suitable for that purpose, such as "Slug" (see Section 9.7 of [RFC5023]).
さらに、この拡張機能は、Content-Dispositionヘッダーフィールド[RFC6266]をリクエストヘッダーフィールドとして誤って使用し、「Slug」などの目的に適した既存のリクエストヘッダーフィールドを使用するのではなく、添付ファイルのファイル名を伝えます（[ RFC5023]）。
Rather than creating interoperability problems with deployed code by updating the design of this extension to be compliant with best current practices and to allow this specification to be placed on the Standards Track, it was decided to simply document how existing implementations interoperate and to publish the document as Informational.
現在のベストプラクティスに準拠するようにこの拡張機能の設計を更新し、この仕様を標準トラックに配置できるようにすることにより、展開されたコードとの相互運用性の問題を作成するのではなく、既存の実装の相互運用方法を文書化し、文書を公開することを決定しました。情報として。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The notation used in this memo is the ABNF notation of [RFC5234] as used by iCalendar [RFC5545]. Any syntax elements shown below that are not explicitly defined in this specification come from iCalendar [RFC5545].
このメモで使用されている表記は、iCalendar [RFC5545]で使用されている[RFC5234]のABNF表記です。この仕様で明示的に定義されていない以下に示す構文要素は、iCalendar [RFC5545]からのものです。
There are four main operations a client needs to perform with attachments for calendar data: add, update, remove, and retrieve. The first three operations are carried out by the client issuing an HTTP POST request on the calendar object resource to which the attachment is associated and specifying the appropriate "action" query parameter (see Section 3.3). In the case of the remove
カレンダーデータの添付ファイルを使用してクライアントが実行する必要がある主な操作は、追加、更新、削除、取得の4つです。最初の3つの操作は、添付ファイルが関連付けられているカレンダーオブジェクトリソースに対してHTTP POSTリクエストを発行し、適切な「アクション」クエリパラメータを指定するクライアントによって実行されます（セクション3.3を参照）。取り外しの場合
operation, the client can alternatively directly update the calendar object resource and remove the relevant "ATTACH" properties (see Section 3.9). The retrieve operation is accomplished by simply issuing an HTTP GET request targeting the attachment URI specified by the calendar resource's "ATTACH" property (see Section 3.10).
操作の代わりに、クライアントは代わりにカレンダーオブジェクトリソースを直接更新し、関連する「ATTACH」プロパティを削除できます（セクション3.9を参照）。取得操作は、カレンダーリソースの「ATTACH」プロパティで指定された添付URIをターゲットとするHTTP GETリクエストを発行するだけで実行されます（セクション3.10を参照）。
iCalendar data stored in a CalDAV calendar object resource can contain multiple components when recurrences are involved. In such a situation, the client needs to be able to target a specific recurrence instance or multiple instances when adding or deleting attachments. As a result, the POST request needs to provide a way for the client to specify which recurrence instances should be targeted for the attachment operation. This is accomplished through use of additional query parameters on the POST Request-URI.
CalDAVカレンダーオブジェクトリソースに保存されているiCalendarデータには、繰り返しが含まれる場合に複数のコンポーネントが含まれる場合があります。このような状況では、クライアントは、添付ファイルを追加または削除するときに、特定の繰り返しインスタンスまたは複数のインスタンスをターゲットにできる必要があります。その結果、POSTリクエストは、クライアントがアタッチ操作の対象となる繰り返しインスタンスを指定する方法を提供する必要があります。これは、POST Request-URIで追加のクエリパラメータを使用することで実現されます。
A server that supports the features described in this specification is REQUIRED to support the CalDAV "calendar-access" [RFC4791] features.
この仕様で説明されている機能をサポートするサーバーは、CalDAVの "calendar-access" [RFC4791]機能をサポートするために必要です。
In addition, such a server SHOULD support the "return=representation" Prefer header field [RFC7240] preference on successful HTTP PUT and POST requests targeting existing calendar object resources by returning the new representation of that calendar resource (including its new ETag header field value) in the response.
さらに、このようなサーバーは、既存のカレンダーオブジェクトリソースをターゲットとする、成功したHTTP PUTおよびPOSTリクエストの "return = representation" Preferヘッダーフィールド[RFC7240]設定をサポートする必要があります（新しいETagヘッダーフィールド値を含む）。 ）レスポンス内。
A server supporting the features described in this specification MUST include "calendar-managed-attachments" as a token in the DAV response header field (as defined in Section 10.1 of [RFC4918]) from an OPTIONS request on a calendar home collection.
この仕様で説明されている機能をサポートするサーバーは、カレンダーホームコレクションのOPTIONSリクエストからのDAV応答ヘッダーフィールド（[RFC4918]のセクション10.1で定義されている）のトークンとして「カレンダー管理添付ファイル」を含める必要があります。
A server might choose not to support the storing of managed attachments on a per-recurrence-instance basis (i.e., they can only be added to all instances as a whole). If that is the case, the server MUST also include "calendar-managed-attachments-no-recurrence" as a token in the DAV response header field from an OPTIONS request on a calendar home collection. When that field is present, clients MUST NOT attempt any managed attachment operations that target specific recurrence instances.
サーバーは、管理された添付ファイルの保存を繰り返しインスタンスごとにサポートしないことを選択する可能性があります（つまり、それらはすべてのインスタンスに全体としてのみ追加できます）。その場合、サーバーは、カレンダーホームコレクションのOPTIONSリクエストからのDAV応答ヘッダーフィールドのトークンとして、「カレンダーマネージドアタッチメント-ノーリカーレンス」も含める必要があります。そのフィールドが存在する場合、クライアントは、特定の繰り返しインスタンスを対象とする管理された接続操作を試行してはなりません（MUST NOT）。
An HTTP POST request is used to add, update, or remove attachments. These requests are subject to the preconditions listed in Section 3.11. The Request-URI will contain various query parameters to specify the behavior.
添付ファイルを追加、更新、または削除するには、HTTP POST要求を使用します。これらのリクエストには、セクション3.11に記載されている前提条件が適用されます。 Request-URIには、動作を指定するさまざまなクエリパラメータが含まれます。
The "action" query parameter is used to identify which attachment operation the client is requesting. This parameter MUST be present once on each POST request used to manage attachments. One of these three values MUST be used:
"action"クエリパラメータは、クライアントが要求しているアタッチメント操作を識別するために使用されます。このパラメーターは、添付ファイルの管理に使用される各POST要求に1回存在する必要があります。次の3つの値のいずれかを使用する必要があります。
attachment-add: Indicates an operation that is adding an attachment to a calendar object resource. See Section 3.4 for more details.
attachment-add：添付ファイルをカレンダーオブジェクトリソースに追加する操作を示します。詳細については、セクション3.4を参照してください。
attachment-update: Indicates an operation that is updating an existing attachment on a calendar object resource. See Section 3.5 for more details.
attachment-update：カレンダーオブジェクトリソースの既存の添付ファイルを更新する操作を示します。詳細については、セクション3.5を参照してください。
attachment-remove: Indicates an operation that is removing an attachment from a calendar object resource. See Section 3.6 for more details.
attachment-remove：カレンダーオブジェクトリソースから添付ファイルを削除する操作を示します。詳細については、セクション3.6を参照してください。
Example:
例：
https://calendar.example.com/events/1.ics?action=attachment-add
The "rid" query parameter is used to identify which recurrence instances are being targeted by the client for the attachment operation. This query parameter MUST contain one or more items, separated by commas (denoted in ASCII as "0x2C"). The item values can be in one of two forms:
「rid」クエリパラメータは、クライアントが添付操作の対象とする繰り返しインスタンスを識別するために使用されます。このクエリパラメータには、カンマで区切られた1つ以上の項目を含める必要があります（ASCIIでは "0x2C"と表記）。アイテムの値は、次の2つの形式のいずれかになります。
Master instance: The value "M" (case insensitive) refers to the "master" recurrence instance, i.e., the component that does not include a "RECURRENCE-ID" property. This item MUST be present only once.
マスターインスタンス：値「M」（大文字と小文字は区別されません）は、「マスター」の繰り返しインスタンス、つまり「RECURRENCE-ID」プロパティを含まないコンポーネントを指します。このアイテムは一度だけ存在しなければなりません。
Specific instance: A specific iCalendar instance is targeted by using its "RECURRENCE-ID" value as the item value. That value MUST correspond to the "RECURRENCE-ID" value as stored in the calendar object resource (i.e., without any conversion to UTC). If multiple items of this form are used, they MUST be unique values. For example, to target a recurrence defined by property RECURRENCE-ID;TZID=America/Montreal:20111022T160000, the query parameter rid=20111022T160000 would be used.
特定のインスタンス：特定のiCalendarインスタンスは、アイテムの値として「RECURRENCE-ID」の値を使用することで対象となります。その値は、カレンダーオブジェクトリソースに格納されている（つまり、UTCに変換されていない）「RECURRENCE-ID」値に対応している必要があります。このフォームの複数のアイテムが使用される場合、それらは一意の値である必要があります。たとえば、プロパティRECURRENCE-ID; TZID = America / Montreal：20111022T160000で定義された繰り返しをターゲットにするには、クエリパラメータrid = 20111022T160000を使用します。
If the "rid" query parameter is not present, all recurrence instances in the calendar object resource are targeted.
「rid」クエリパラメータが存在しない場合、カレンダーオブジェクトリソースのすべての繰り返しインスタンスが対象になります。
The "rid" query parameter MUST NOT be present in the case of an update operation, or if the server chooses not to support per-recurrence instance managed attachments (see Section 3.2).
「rid」クエリパラメータは、更新操作の場合、またはサーバーが反復ごとのインスタンス管理の添付ファイルをサポートしないことを選択した場合（セクション3.2を参照）に存在してはなりません（MUST NOT）。
Example (targeting the master instance and a specific overridden instance):
例（マスターインスタンスと特定のオーバーライドされたインスタンスを対象とする）：
https://calendar.example.com/events/1.ics?
action=attachment-add&rid=M,20111022T160000
The "managed-id" query parameter is used to identify which "ATTACH" property is being updated or removed. The value of this query parameter MUST match the "MANAGED-ID" (Section 4.3) property parameter value on the "ATTACH" property in the calendar object resource instance(s) targeted by the request.
「managed-id」クエリパラメータは、更新または削除されている「ATTACH」プロパティを識別するために使用されます。このクエリパラメータの値は、リクエストの対象となるカレンダーオブジェクトリソースインスタンスの "ATTACH"プロパティの "MANAGED-ID"（セクション4.3）プロパティパラメータ値と一致する必要があります。
The "managed-id" query parameter MUST NOT be present in the case of an add operation.
追加操作の場合、「managed-id」クエリパラメータは存在してはなりません（MUST NOT）。
Example:
例：
https://calendar.example.com/events/1.ics?
action=attachment-update&managed-id=aUNhbGVuZGFy
To add an attachment to an existing calendar object resource, the following needs to occur:
既存のカレンダーオブジェクトリソースに添付ファイルを追加するには、次のことが必要です。
1. The client issues a POST request targeted at the calendar object resource structured as follows:
1. クライアントは、次のような構造のカレンダーオブジェクトリソースを対象としたPOSTリクエストを発行します。
A. The Request-URI will include an "action" query parameter with the value "attachment-add" (see Section 3.3.1).
A. Request-URIには、「attachment-add」という値を持つ「action」クエリパラメータが含まれます（セクション3.3.1を参照）。
B. If all recurrence instances are having an attachment added, the "rid" query parameter is not present in the Request-URI. If one or more specific recurrence instances are targeted, then the Request-URI will include a "rid" query parameter containing the list of instances (see Section 3.3.2).
B.すべての繰り返しインスタンスに添付ファイルが追加されている場合、「rid」クエリパラメータはRequest-URIに存在しません。 1つ以上の特定の繰り返しインスタンスがターゲットになっている場合、Request-URIにはインスタンスのリストを含む「rid」クエリパラメータが含まれます（セクション3.3.2を参照）。
C. The body of the request contains the data for the attachment.
C.リクエストの本文には、添付ファイルのデータが含まれています。
D. The client MUST include a valid Content-Type header field describing the media type of the attachment (as required by HTTP).
D.クライアントは、添付ファイルのメディアタイプを説明する有効なContent-Typeヘッダーフィールドを含める必要があります（HTTPでの要求に応じて）。
E. The client SHOULD include a Content-Disposition header field [RFC6266] with a "type" parameter set to "attachment", and a "filename" parameter that indicates the name of the attachment. Note that the use of Content-Disposition as a request header field is nonstandard and specific to this protocol.
E.クライアントは、「type」パラメーターが「attachment」に設定されたContent-Dispositionヘッダーフィールド[RFC6266]と、添付ファイルの名前を示す「filename」パラメーターを含める必要があります（SHOULD）。要求ヘッダーフィールドとしてのContent-Dispositionの使用は非標準であり、このプロトコルに固有であることに注意してください。
F. The client MAY include a Prefer header field [RFC7240] with the "return=representation" preference to request that the modified calendar object resource be returned as the body of a successful response to the POST request.
F.クライアントは、「return = representation」設定を含むPreferヘッダーフィールド[RFC7240]を含めて、変更されたカレンダーオブジェクトリソースをPOSTリクエストへの成功した応答の本文として返すことを要求できます。
2. When the server receives the POST request, it does the following:
2. サーバーはPOST要求を受信すると、次のことを行います。
A. Validates that any recurrence instances referred to via the "rid" query parameter are valid for the calendar object resource being targeted.
A.「rid」クエリパラメータを介して参照される繰り返しインスタンスが、対象となるカレンダーオブジェクトリソースに対して有効であることを検証します。
B. Stores the supplied attachment data into a resource and generates an appropriate URI for clients to access the resource.
B.提供された添付データをリソースに格納し、クライアントがリソースにアクセスするための適切なURIを生成します。
C. For each affected recurrence instance in the calendar object resource targeted by the request, adds an "ATTACH" property whose value is the URI of the stored attachment. The "ATTACH" property MUST contain a "MANAGED-ID" property parameter whose value is a unique identifier (within the context of the server as a whole). The "ATTACH" property SHOULD contain an "FMTTYPE" property parameter whose value matches the Content-Type header field value from the request. The "ATTACH" property SHOULD contain a "FILENAME" property parameter whose value matches the value of the Content-Disposition header field "filename" parameter value from the request, taking into account the restrictions expressed in Section 4.2. The "ATTACH" property SHOULD include a "SIZE" property parameter whose value represents the size in octets of the attachment. If a specified recurrence instance does not have a matching component in the calendar object resource, then the server MUST modify the calendar object resource to include an overridden component with the appropriate "RECURRENCE-ID" property.
C.リクエストの対象となるカレンダーオブジェクトリソースの影響を受ける繰り返しインスタンスごとに、格納されている添付ファイルのURIを値とする「ATTACH」プロパティを追加します。 "ATTACH"プロパティには、値が（サーバー全体のコンテキスト内で）一意の識別子である "MANAGED-ID"プロパティパラメータが含まれている必要があります。 "ATTACH"プロパティには、リクエストのContent-Typeヘッダーフィールド値と一致する値を持つ "FMTTYPE"プロパティパラメータを含める必要があります（SHOULD）。 「ATTACH」プロパティには、「FILENAME」プロパティパラメータが含まれている必要があり、その値は、セクション4.2で表されている制限を考慮して、リクエストのContent-Dispositionヘッダーフィールドの「filename」パラメータ値と一致します。 「ATTACH」プロパティには、値が添付ファイルのオクテット単位のサイズを表す「SIZE」プロパティパラメータを含める必要があります（SHOULD）。指定された繰り返しインスタンスのカレンダーオブジェクトリソースに一致するコンポーネントがない場合、サーバーはカレンダーオブジェクトリソースを変更して、適切な「RECURRENCE-ID」プロパティを持つオーバーライドされたコンポーネントを含める必要があります。
D. Upon successful creation of the attachment resource, and modification of the targeted calendar object resource, it MUST return an appropriate HTTP success status response and include a "Cal-Managed-ID" header field containing the "MANAGED-ID" property parameter value of the newly created "ATTACH" property. The client can use the "Cal-Managed-ID" header field value to correlate the attachment with "ATTACH" properties added to the calendar object resource. If the client included a Prefer header field with the "return=representation" preference in the request, the server SHOULD return the modified calendar object resource as the body of the response. Otherwise, the server can expect that the client will reload the calendar object resource with a subsequent GET request to refresh any local cache.
D.添付リソースの作成が成功し、対象のカレンダーオブジェクトリソースが変更されると、適切なHTTP成功ステータス応答を返し、「MANAGED-ID」プロパティパラメータ値を含む「Cal-Managed-ID」ヘッダーフィールドを含める必要があります。新しく作成された「ATTACH」プロパティの。クライアントは、「Cal-Managed-ID」ヘッダーフィールドの値を使用して、添付ファイルをカレンダーオブジェクトリソースに追加された「ATTACH」プロパティと関連付けることができます。クライアントがリクエストに「return = representation」設定を含むPreferヘッダーフィールドを含めた場合、サーバーは変更されたカレンダーオブジェクトリソースを応答の本文として返す必要があります（SHOULD）。それ以外の場合、サーバーは、クライアントがカレンダーオブジェクトリソースをリロードし、後続のGETリクエストでローカルキャッシュを更新することを期待できます。
In the following example, the client adds a new attachment to a nonrecurring event and asks the server (via the Prefer header field [RFC7240]) to return the modified version of that event in the response.
次の例では、クライアントは新しい添付ファイルを非定期的なイベントに追加し、サーバーに（Preferヘッダーフィールド[RFC7240]を介して）応答としてそのイベントの変更されたバージョンを返すように要求します。
>> Request <<
POST /events/64.ics?action=attachment-add HTTP/1.1
Host: cal.example.com
Content-Type: text/html; charset="utf-8"
Content-Disposition:attachment;filename=agenda.html
Content-Length: 59
Prefer: return=representation
<html>
<body>
<h1>Agenda</h1>
</body>
</html>
>> Response <<
HTTP/1.1 201 Created
Content-Type: text/calendar; charset="utf-8"
Content-Length: 371
Content-Location: https://cal.example.com/events/64.ics
ETag: "123456789-000-111"
Cal-Managed-ID: 97S
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Server//EN
BEGIN:VEVENT
UID:20010712T182145Z-123401@example.com
DTSTAMP:20120201T203412Z
DTSTART:20120714T170000Z
DTEND:20120715T040000Z
SUMMARY:One-off meeting
ATTACH;MANAGED-ID=97S;FMTTYPE=text/html;SIZE=59;
FILENAME=agenda.html:https://cal.example.com/attach/64/34X22R
END:VEVENT
END:VCALENDAR
When an attachment is updated, the server MUST change the associated "MANAGED-ID" property parameter and MAY change the "ATTACH" property value. With this approach, clients are able to determine when an attachment has been updated by some other client by looking for a change to either the "ATTACH" property value or the "MANAGED-ID" property parameter value.
添付ファイルが更新されると、サーバーは関連する「MANAGED-ID」プロパティパラメータを変更する必要があり、「ATTACH」プロパティ値を変更できます（MAY）。このアプローチを使用すると、クライアントは、「ATTACH」プロパティ値または「MANAGED-ID」プロパティパラメータ値のいずれかに対する変更を探すことにより、添付ファイルが他のクライアントによっていつ更新されたかを判断できます。
To change the data of an existing managed attachment in a calendar object resource, the following needs to occur:
カレンダーオブジェクトリソースの既存の管理された添付ファイルのデータを変更するには、次のことが必要です。
1. The client issues a POST request targeted at the calendar object resource structured as follows:
1. クライアントは、次のような構造のカレンダーオブジェクトリソースを対象としたPOSTリクエストを発行します。
A. The Request-URI will include an "action" query parameter with the value "attachment-update" (see Section 3.3.1).
A. Request-URIには、「attachment-update」という値を持つ「action」クエリパラメータが含まれます（セクション3.3.1を参照）。
B. The Request-URI will include a "managed-id" query parameter with the value matching that of the "MANAGED-ID" property parameter for the "ATTACH" property being updated (see Section 3.3.3).
B. Request-URIには、更新される「ATTACH」プロパティの「MANAGED-ID」プロパティパラメータと一致する値を持つ「managed-id」クエリパラメータが含まれます（セクション3.3.3を参照）。
C. The body of the request contains the updated data for the attachment.
C.リクエストの本文には、添付ファイルの更新されたデータが含まれています。
D. The client MUST include a valid Content-Type header field describing the media type of the attachment (as required by HTTP).
D.クライアントは、添付ファイルのメディアタイプを説明する有効なContent-Typeヘッダーフィールドを含める必要があります（HTTPでの要求に応じて）。
E. The client SHOULD include a Content-Disposition header field [RFC6266] with a "type" parameter set to "attachment", and a "filename" parameter that indicates the name of the attachment.
E.クライアントは、「type」パラメーターが「attachment」に設定されたContent-Dispositionヘッダーフィールド[RFC6266]と、添付ファイルの名前を示す「filename」パラメーターを含める必要があります（SHOULD）。
F. The client MAY include a Prefer header field [RFC7240] with the "return=representation" preference to request that the modified calendar object resource be returned as the body of a successful response to the POST request.
F.クライアントは、「return = representation」設定を含むPreferヘッダーフィールド[RFC7240]を含めて、変更されたカレンダーオブジェクトリソースをPOSTリクエストへの成功した応答の本文として返すことを要求できます。
2. When the server receives the POST request, it does the following:
2. サーバーはPOST要求を受信すると、次のことを行います。
A. Validates that the "managed-id" query parameter is valid for the calendar object resource.
A.「managed-id」クエリパラメータがカレンダーオブジェクトリソースに対して有効であることを検証します。
B. Updates the content of the attachment resource corresponding to that "managed-id" value with the supplied attachment data.
B.その「managed-id」値に対応する添付リソースのコンテンツを、提供された添付データで更新します。
C. For each affected recurrence instance in the calendar object resource targeted by the request, updates the "ATTACH" property whose "MANAGED-ID" property parameter value matches the "managed-id" query parameter. The "MANAGED-ID" property parameter value is changed to allow other clients to detect the update, and the property value (attachment URI) might also be changed. The "ATTACH" property SHOULD contain a "FMTTYPE" property parameter whose value matches the Content-Type header field value from the request; this could differ from the original value if the media type of the updated attachment is different. The "ATTACH" property SHOULD contain a "FILENAME" property parameter whose value matches the Content-Disposition header field "filename" parameter value from the request, taking into account the restrictions expressed in Section 4.2. The "ATTACH" property SHOULD include a "SIZE" property parameter whose value represents the size in octets of the updated attachment.
C.リクエストの対象となるカレンダーオブジェクトリソースの影響を受ける繰り返しインスタンスごとに、「MANAGED-ID」プロパティパラメータ値が「managed-id」クエリパラメータと一致する「ATTACH」プロパティを更新します。 「MANAGED-ID」プロパティパラメータ値は、他のクライアントが更新を検出できるように変更され、プロパティ値（添付URI）も変更される可能性があります。 "ATTACH"プロパティには、リクエストのContent-Typeヘッダーフィールド値と一致する値を持つ "FMTTYPE"プロパティパラメータを含める必要があります（SHOULD）。更新された添付ファイルのメディアタイプが異なる場合、これは元の値と異なる場合があります。 「ATTACH」プロパティには、「FILENAME」プロパティパラメータが含まれている必要があり、その値は、セクション4.2で表されている制限を考慮に入れて、リクエストのContent-Dispositionヘッダーフィールドの「filename」パラメータ値と一致します。 「ATTACH」プロパティには、値が更新された添付ファイルのオクテット単位のサイズを表す「SIZE」プロパティパラメータを含める必要があります（SHOULD）。
D. Upon successful update of the attachment resource, and modification of the targeted calendar object resource, it MUST return an appropriate HTTP success status response and include a "Cal-Managed-ID" header field containing the new value of the "MANAGED-ID" property parameter. The client can use the "Cal-Managed-ID" header field value to correlate the attachment with "ATTACH" properties added to the calendar object resource. If the client included a Prefer header field with the "return=representation" preference in the request, the server SHOULD return the modified calendar object resource as the body of the response. Otherwise, the server can expect that the client will reload the calendar object resource with a subsequent GET request to refresh any local cache.
D.添付リソースの更新が成功し、対象のカレンダーオブジェクトリソースが変更されると、適切なHTTP成功ステータス応答を返し、「MANAGED-ID」の新しい値を含む「Cal-Managed-ID」ヘッダーフィールドを含める必要があります。 "プロパティパラメータ。クライアントは、「Cal-Managed-ID」ヘッダーフィールドの値を使用して、添付ファイルをカレンダーオブジェクトリソースに追加された「ATTACH」プロパティと関連付けることができます。クライアントがリクエストに「return = representation」設定を含むPreferヘッダーフィールドを含めた場合、サーバーは変更されたカレンダーオブジェクトリソースを応答の本文として返す必要があります（SHOULD）。それ以外の場合、サーバーは、クライアントがカレンダーオブジェクトリソースをリロードし、後続のGETリクエストでローカルキャッシュを更新することを期待できます。
The update operation does not take a "rid" query parameter and does not add, or remove, any "ATTACH" property in the targeted calendar object resource. To link an existing attachment to a new instance, the client simply does a PUT on the calendar object resource, adding an "ATTACH" property that duplicates the existing one (see Section 3.7).
更新操作では、「rid」クエリパラメータを使用せず、ターゲットのカレンダーオブジェクトリソースの「ATTACH」プロパティを追加または削除しません。既存のアタッチメントを新しいインスタンスにリンクするには、クライアントはカレンダーオブジェクトリソースに対してPUTを実行し、既存のアタッチメントを複製する「ATTACH」プロパティを追加するだけです（セクション3.7を参照）。
In the following example, the client updates an existing attachment and asks the server (via the Prefer header field [RFC7240]) to return the updated version of that event in the response.
次の例では、クライアントは既存の添付ファイルを更新し、サーバーに（Preferヘッダーフィールド[RFC7240]を介して）応答して、そのイベントの更新されたバージョンを返すように要求します。
>> Request <<
POST /events/64.ics?action=attachment-update&managed-id=97S HTTP/1.1
Host: cal.example.com
Content-Type: text/html; charset="utf-8"
Content-Disposition:attachment;filename=agenda.html
Content-Length: 96
Prefer: return=representation
<html>
<body>
<h1>Agenda</h1>
<p>Discuss attachment draft</p>
</body>
</html>
>> Response <<
HTTP/1.1 200 OK
Content-Type: text/calendar; charset="utf-8"
Content-Length: 371
Content-Location: https://cal.example.com/events/64.ics
Cal-Managed-ID: 98S
ETag: "123456789-000-222"
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Server//EN
BEGIN:VEVENT
UID:20010712T182145Z-123401@example.com
DTSTAMP:20120201T203412Z
DTSTART:20120714T170000Z
DTEND:20120715T040000Z
SUMMARY:One-off meeting
ATTACH;MANAGED-ID=98S;FMTTYPE=text/html;SIZE=96;
FILENAME=agenda.html:https://cal.example.com/attach/64/34X22R
END:VEVENT
END:VCALENDAR
To remove an existing attachment from a calendar object, the following needs to occur:
カレンダーオブジェクトから既存の添付ファイルを削除するには、次のことが必要です。
1. The client issues a POST request targeted at the calendar object resource structured as follows:
1. クライアントは、次のような構造のカレンダーオブジェクトリソースを対象としたPOSTリクエストを発行します。
A. The Request-URI will include an "action" query parameter with the value "attachment-remove" (see Section 3.3.1).
A. Request-URIには、「attachment-remove」という値を持つ「action」クエリパラメータが含まれます（セクション3.3.1を参照）。
B. If all recurrence instances are having an attachment removed, the "rid" query parameter is not present in the Request-URI. If one or more specific recurrence instances are targeted, then the Request-URI will include a "rid" query parameter containing the list of instances (see Section 3.3.2).
B.すべての繰り返しインスタンスで添付ファイルが削除されている場合、「rid」クエリパラメータはRequest-URIに存在しません。 1つ以上の特定の繰り返しインスタンスがターゲットになっている場合、Request-URIにはインスタンスのリストを含む「rid」クエリパラメータが含まれます（セクション3.3.2を参照）。
C. The Request-URI will include a "managed-id" query parameter with the value matching that of the "MANAGED-ID" property parameter for the "ATTACH" property being removed (see Section 3.3.3).
C. Request-URIには、削除される「ATTACH」プロパティの「MANAGED-ID」プロパティパラメータと一致する値を持つ「managed-id」クエリパラメータが含まれます（セクション3.3.3を参照）。
D. The body of the request will be empty.
D.リクエストの本文は空になります。
E. The client MAY include a Prefer header field [RFC7240] with the "return=representation" preference to request that the modified calendar object resource be returned as the body of a successful response to the POST request.
E.クライアントは、「return = representation」設定を含むPreferヘッダーフィールド[RFC7240]を含めて、変更されたカレンダーオブジェクトリソースをPOSTリクエストに対する成功した応答の本文として返すことを要求できます。
2. When the server receives the POST request, it does the following:
2. サーバーはPOST要求を受信すると、次のことを行います。
A. Validates that any recurrence instances referred to via the "rid" query parameter are valid for the calendar object resource being targeted.
A.「rid」クエリパラメータを介して参照される繰り返しインスタンスが、対象となるカレンダーオブジェクトリソースに対して有効であることを検証します。
B. Validates that the "managed-id" query parameter is valid for the calendar object resource and specific instances being targeted.
B.「managed-id」クエリパラメータが、対象となるカレンダーオブジェクトリソースと特定のインスタンスに対して有効であることを検証します。
C. For each affected recurrence instance in the calendar object resource targeted by the request, removes the matching "ATTACH" property. Note that if a specified recurrence instance does not have a matching component in the calendar object resource, then the server MUST modify the calendar object resource to include an overridden component with the appropriate "RECURRENCE-ID" property and the matching "ATTACH" property removed. This latter case is actually valid only if the master component does include the referenced "ATTACH" property.
C.リクエストの対象となるカレンダーオブジェクトリソースの影響を受ける繰り返しインスタンスごとに、一致する「ATTACH」プロパティを削除します。指定した繰り返しインスタンスのカレンダーオブジェクトリソースに一致するコンポーネントがない場合、サーバーはカレンダーオブジェクトリソースを変更して、適切な「RECURRENCE-ID」プロパティと一致する「ATTACH」プロパティを削除したオーバーライドされたコンポーネントを含める必要があります。 。この後者のケースは、参照された「ATTACH」プロパティがマスターコンポーネントに含まれている場合にのみ実際に有効です。
D. If the attachment resource is no longer referenced by any instance of the calendar object resource, it can delete the attachment resource to free up storage space.
D.アタッチメントリソースがカレンダーオブジェクトリソースのどのインスタンスからも参照されなくなった場合、アタッチメントリソースを削除してストレージスペースを解放できます。
E. Upon successful removal of the attachment resource and modification of the targeted calendar object resource, it MUST return an appropriate HTTP success status response. If the client included a Prefer header field with the "return=representation" preference in the request, the server SHOULD return the modified calendar object resource as the body of the response. Otherwise, the server can expect that the client will reload the calendar object resource with a subsequent GET request to refresh any local cache.
E.添付リソースの削除とターゲットカレンダーオブジェクトリソースの変更が成功すると、適切なHTTP成功ステータス応答を返さなければなりません（MUST）。クライアントがリクエストに「return = representation」設定を含むPreferヘッダーフィールドを含めた場合、サーバーは変更されたカレンダーオブジェクトリソースを応答の本文として返す必要があります（SHOULD）。それ以外の場合、サーバーは、クライアントがカレンダーオブジェクトリソースをリロードし、後続のGETリクエストでローカルキャッシュを更新することを期待できます。
In the following example, the client deletes an existing attachment by passing its "managed-id" value in the request. The Prefer header field [RFC7240] is not set in the request so the calendar object resource data is not returned in the response.
次の例では、クライアントはリクエストで「managed-id」値を渡すことにより、既存の添付ファイルを削除します。 Preferヘッダーフィールド[RFC7240]はリクエストに設定されていないため、カレンダーオブジェクトのリソースデータはレスポンスで返されません。
>> Request <<
POST /events/64.ics?action=attachment-remove&managed-id=98S HTTP/1.1
Host: cal.example.com
Content-Length: 0
>> Response <<
HTTP/1.1 204 No Content Content-Length: 0
HTTP / 1.1 204コンテンツがありませんコンテンツの長さ：0
Clients can make use of existing managed attachments by adding the corresponding "ATTACH" property to calendar object resources (subject to the restrictions described in Section 3.12.2).
クライアントは、対応する「ATTACH」プロパティをカレンダーオブジェクトリソースに追加することにより、既存の管理された添付ファイルを利用できます（セクション3.12.2で説明されている制限に従います）。
If a managed attachment is used in more than calendar resource, servers SHOULD NOT change either the "MANAGED-ID" property parameter value or the "ATTACH" property value for these attachments; this ensures that clients do not have to download the attachment data again if they already have it cached. Additionally, servers SHOULD validate "SIZE" property parameter values and replace incorrect values with the actual sizes of existing attachments.
管理された添付ファイルがカレンダーリソース以外で使用されている場合、サーバーはこれらの添付ファイルの "MANAGED-ID"プロパティパラメータ値または "ATTACH"プロパティ値を変更してはなりません（SHOULD NOT）。これにより、既にキャッシュされている添付ファイルデータをクライアントが再度ダウンロードする必要がなくなります。さらに、サーバーは「サイズ」プロパティパラメータ値を検証し、不正な値を既存の添付ファイルの実際のサイズに置き換える必要があります（SHOULD）。
These PUT requests are subject to the preconditions listed in Section 3.11.
これらのPUTリクエストは、セクション3.11に記載されている前提条件の対象となります。
Servers MUST NOT allow clients to update attachment data directly via a PUT on the attachment URI (or via any other HTTP method that modifies content). Instead, attachments can only be updated via use of POST requests on the calendar data.
サーバーは、クライアントが添付URIのPUTを介して（またはコンテンツを変更する他のHTTPメソッドを介して）直接添付データを更新することを許可してはなりません（MUST NOT）。代わりに、添付ファイルはカレンダーデータのPOSTリクエストを使用してのみ更新できます。
Clients can remove attachments by simply rewriting the calendar object resource data to remove the appropriate "ATTACH" properties. Servers MUST NOT allow clients to delete attachments directly via a DELETE request on the attachment URI.
クライアントは、カレンダーオブジェクトのリソースデータを書き換えて適切な「ATTACH」プロパティを削除するだけで、添付ファイルを削除できます。サーバーは、クライアントが添付ファイルURIのDELETEリクエストを介して直接添付ファイルを削除することを許可してはなりません（MUST NOT）。
Clients retrieve attachments by issuing an HTTP GET request using the value of the corresponding "ATTACH" property as the Request-URI, taking into account the substitution mechanism associated with the "CALDAV:managed-attachments-server-URL" property (see Section 6.1).
クライアントは、「CALDAV：managed-attachments-server-URL」プロパティに関連付けられている置換メカニズムを考慮して、対応する「ATTACH」プロパティの値をRequest-URIとして使用し、HTTP GETリクエストを発行して添付ファイルを取得します（6.1節を参照） ）。
This specification creates additional preconditions for the POST method.
この仕様は、POSTメソッドの追加の前提条件を作成します。
The new preconditions are:
新しい前提条件は次のとおりです。
(CALDAV:max-attachment-size): The attachment submitted in the POST request MUST have an octet size less than or equal to the value of the "CALDAV:max-attachment-size" property value (Section 6.2) on the calendar collection of the target calendar resource.
（CALDAV：max-attachment-size）：POSTリクエストで送信される添付ファイルには、カレンダーコレクションの「CALDAV：max-attachment-size」プロパティ値（セクション6.2）の値以下のオクテットサイズが必要ですターゲットカレンダーリソースの。
(CALDAV:max-attachments-per-resource): The addition of the attachment submitted in the POST request MUST result in the target calendar resource having a number of managed attachments less than or equal to the value of the "CALDAV:max-attachments-per-resource" property value (Section 6.3) on the calendar collection of the target calendar resource.
（CALDAV：max-attachments-per-resource）：POSTリクエストで送信された添付ファイルを追加すると、「CALDAV：max-attachments」の値以下の管理された添付ファイルの数がターゲットカレンダーリソースに含まれる必要があります。ターゲットカレンダーリソースのカレンダーコレクションの-per-resource "プロパティ値（セクション6.3）。
(CALDAV:valid-action): The "action" query parameter in the POST request MUST contain only one of the following three values: "attachment-add", "attachment-update", or "attachment-remove".
（CALDAV：valid-action）：POSTリクエストの「action」クエリパラメータには、「attachment-add」、「attachment-update」、または「attachment-remove」の3つの値のいずれか1つのみを含める必要があります。
(CALDAV:valid-rid): The "rid" query parameter in the POST request MUST NOT be present with an "action=attachment-update" query parameter and MUST contain the value "M" and/or values corresponding to "RECURRENCE-ID" property values in the iCalendar data targeted by the request.
（CALDAV：valid-rid）：POSTリクエストの「rid」クエリパラメータは、「action = attachment-update」クエリパラメータと一緒に存在してはならず、値「M」および/または「RECURRENCE-リクエストのターゲットとなるiCalendarデータ内のID "プロパティ値。
(CALDAV:valid-managed-id): The "managed-id" query parameter in the POST request MUST NOT be present with an "action=attachment-add" query parameter and MUST contain a value corresponding to a "MANAGED-ID" property parameter value in the iCalendar data targeted by the request.
（CALDAV：valid-managed-id）：POSTリクエストの「managed-id」クエリパラメータは、「action = attachment-add」クエリパラメータとともに存在してはならず、「MANAGED-ID」に対応する値を含んでいる必要がありますリクエストのターゲットとなるiCalendarデータのプロパティパラメータ値。
A POST request to add, modify, or delete a managed attachment results in an implicit modification of the targeted calendar resource (equivalent of a PUT). As a consequence, clients should also be prepared to handle preconditions associated with this implicit PUT. This includes (but is not limited to):
管理された添付ファイルを追加、変更、または削除するPOSTリクエストは、対象のカレンダーリソースの暗黙的な変更をもたらします（PUTと同等）。その結果、クライアントはこの暗黙のPUTに関連する前提条件を処理できるように準備する必要もあります。これには以下が含まれます（ただし、これらに限定されません）。
(CALDAV:max-resource-size) (from Section 5.3.2.1 of [RFC4791])
（CALDAV：max-resource-size）（[RFC4791]のセクション5.3.2.1から）
(DAV:quota-not-exceeded) (from Section 6 of [RFC4331])
（DAV：quota-not-exceeded）（[RFC4331]のセクション6から）
(DAV:sufficient-disk-space) (from Section 6 of [RFC4331])
（DAV：sufficient-disk-space）（[RFC4331]のセクション6から）
A PUT request to add or modify an existing calendar object resource can make reference to an existing managed attachment. The following new precondition is defined:
既存のカレンダーオブジェクトリソースを追加または変更するPUTリクエストは、既存の管理された添付ファイルを参照できます。次の新しい前提条件が定義されています。
(CALDAV:valid-managed-id-parameter): a "MANAGED-ID" property parameter value in the iCalendar data in the PUT request is not valid (e.g., does not match any existing managed attachment).
（CALDAV：valid-managed-id-parameter）：PUTリクエストのiCalendarデータの「MANAGED-ID」プロパティパラメータ値が無効です（たとえば、既存の管理対象のアタッチメントと一致しません）。
If a precondition for a request is not satisfied:
リクエストの前提条件が満たされていない場合：
1. The response status of the request MUST either be 403 (Forbidden) if the request should not be repeated because it will always fail, or 409 (Conflict) if it is expected that the user might be able to resolve the conflict and resubmit the request.
1. リクエストの応答ステータスは、リクエストが常に失敗するために繰り返さない場合は403（禁止）、またはユーザーが競合を解決してリクエストを再送信できると予想される場合は409（競合）のいずれかである必要があります。
2. The appropriate XML element MUST be returned as the child of a top-level DAV:error element in the response body.
2. 適切なXML要素は、応答本文の最上位のDAV：error要素の子として返される必要があります。
The WebDAV Quotas specification [RFC4331] defines two live WebDAV properties (DAV:quota-available-bytes and DAV:quota-used-bytes) to communicate storage quota information to clients. Server implementations MAY choose to include managed attachment sizes when calculating the amount of storage used by a particular resource.
WebDAVクォータ仕様[RFC4331]は、2つのライブWebDAVプロパティ（DAV：quota-available-bytesおよびDAV：quota-used-bytes）を定義して、ストレージクォータ情報をクライアントに通知します。サーバー実装は、特定のリソースによって使用されるストレージの量を計算するときに、管理された添付ファイルのサイズを含めることを選択できます。
Access to the managed attachments referenced in a calendar object resource SHOULD be restricted to only those calendar users who have access to that calendar object either directly or indirectly (via being an attendee who would receive a scheduling message).
カレンダーオブジェクトリソースで参照される管理された添付ファイルへのアクセスは、そのカレンダーオブジェクトに直接または間接的に（スケジュールメッセージを受信する出席者として）アクセスできるカレンダーユーザーのみに制限する必要があります（SHOULD）。
When accessing a managed attachment, clients SHOULD be prepared to authenticate with the server storing the attachment resource. The credentials required to access the managed attachment store could be different from the ones used to access the CalDAV server.
管理されたアタッチメントにアクセスするとき、クライアントはアタッチメントリソースを格納するサーバーで認証する準備をする必要があります。管理された添付ファイルストアにアクセスするために必要な資格情報は、CalDAVサーバーへのアクセスに使用されるものとは異なる場合があります。
This specification only allows organizers of scheduled events to add managed attachments. Servers MUST prevent attendees of scheduled events from adding, updating, or removing managed attachments. In addition, the server MUST prevent a calendar user from reusing a managed attachment (based on its "managed-id" value), unless that user is the one who originally created the managed attachment.
この仕様では、スケジュールされたイベントの主催者のみが管理された添付ファイルを追加できます。サーバーは、スケジュールされたイベントの出席者が管理された添付ファイルを追加、更新、または削除することを防止する必要があります。さらに、サーバーは、管理対象の添付ファイルを最初に作成したユーザーでない限り、カレンダーユーザーが管理対象の添付ファイルを（「managed-id」の値に基づいて）再利用できないようにする必要があります。
For POST requests that add or update attachment data, the server MAY issue a 307 (Temporary Redirect) [RFC7231] or 308 (Permanent Redirect) [RFC7538] response to require the client to reissue the POST request using a different Request-URI. As a result, clients SHOULD use the "100-continue" expectation defined in Section 5.1.1 of [RFC7231]. Using this mechanism ensures that, if a redirect does occur, the client does not needlessly send the attachment data.
添付データを追加または更新するPOST要求の場合、サーバーは307（一時的なリダイレクト）[RFC7231]または308（永続的なリダイレクト）[RFC7538]応答を発行して、別のRequest-URIを使用してPOST要求を再発行するようクライアントに要求できます。その結果、クライアントは[RFC7231]のセクション5.1.1で定義されている「100-continue」の期待値を使用する必要があります（SHOULD）。このメカニズムを使用すると、リダイレクトが発生した場合に、クライアントが添付データを不必要に送信することがなくなります。
Clients can expect servers to take a while to respond to POST requests that include large attachment bodies. Servers SHOULD use the 102 (Processing) interim response defined in Section 10.1 of [RFC2518] to keep the client connection alive if the POST request will take significant time to complete.
クライアントは、サーバーが大きな添付ファイル本文を含むPOSTリクエストに応答するのにしばらく時間がかかることを期待できます。サーバーは、[RFC2518]のセクション10.1で定義されている102（処理中）中間応答を使用して、POSTリクエストの完了にかなりの時間がかかる場合にクライアント接続を維持する必要があります（SHOULD）。
Servers MAY automatically remove attachment data, for example, to regain the storage taken by unused attachments or as the result of a virus scanning. When doing so, they SHOULD NOT modify calendar data referencing those attachments. Instead, they SHOULD respond with 410 (Gone) to any request on the removed attachment URI.
サーバーは、たとえば、未使用の添付ファイルによって使用されたストレージを回復するために、またはウイルススキャンの結果として、添付ファイルデータを自動的に削除する場合があります。その際、それらの添付ファイルを参照するカレンダーデータは変更しないでください。代わりに、削除された添付URIに対する要求に410（存在しない）で応答する必要があります（SHOULD）。
When a managed attachment is added, updated, or removed from a calendar object resource, the server MUST ensure that a scheduling message is sent to update any attendees with the changes, as per [RFC6638].
管理された添付ファイルがカレンダーオブジェクトリソースに追加、更新、または削除されると、サーバーは、[RFC6638]に従って、変更で出席者を更新するためにスケジュールメッセージが送信されることを確認する必要があります。
When exporting calendar data from a CalDAV server supporting managed attachments, clients SHOULD remove all "MANAGED-ID" property parameters from "ATTACH" properties in the calendar data. Similarly, when importing calendar data from another source, clients SHOULD remove any "MANAGED-ID" property parameters on "ATTACH" properties (failure to do so will likely result in the server removing those properties automatically).
管理された添付ファイルをサポートするCalDAVサーバーからカレンダーデータをエクスポートする場合、クライアントは、カレンダーデータの「ATTACH」プロパティからすべての「MANAGED-ID」プロパティパラメータを削除する必要があります（SHOULD）。同様に、別のソースからカレンダーデータをインポートする場合、クライアントは「ATTACH」プロパティの「MANAGED-ID」プロパティパラメータを削除する必要があります（そうしないと、サーバーがそれらのプロパティを自動的に削除する可能性があります）。
Parameter Name: SIZE
パラメータ名：SIZE
Purpose: To specify the size of an attachment.
目的：添付ファイルのサイズを指定します。
Format Definition: This property parameter is defined by the following notation:
フォーマット定義：このプロパティパラメータは、次の表記法で定義されます。
sizeparam = "SIZE" "=" paramtext ; positive integers
sizeparam = "SIZE" "=" paramtext;正の整数
Description: This property parameter MAY be specified on "ATTACH" properties. It indicates the size in octets of the corresponding attachment data. Since iCalendar integer values are restricted to a maximum value of 2147483647, the current property parameter is defined as text to allow an extended range to be used.
説明：このプロパティパラメータは、 "ATTACH"プロパティで指定される場合があります。対応する添付データのサイズをオクテット単位で示します。 iCalendar整数値は最大値2147483647に制限されているため、現在のプロパティパラメータはテキストとして定義され、拡張された範囲を使用できます。
Example:
例：
ATTACH;SIZE=1234:https://attachments.example.com/abcd.txt
Parameter Name: FILENAME
パラメータ名：FILENAME
Purpose: To specify the filename of a managed attachment.
目的：管理された添付ファイルのファイル名を指定します。
Format Definition: This property parameter is defined by the following notation:
フォーマット定義：このプロパティパラメータは、次の表記法で定義されます。
filenameparam = "FILENAME" "=" paramtext
filenameparam = "FILENAME" "=" paramtext
Description: This property parameter MAY be specified on "ATTACH" properties corresponding to managed attachments. Its value provides information on how to construct a filename for storing the attachment data. This parameter is very similar in nature to the Content-Disposition header field "filename" parameter and exposes the same security risks. As a consequence, clients MUST follow the guidelines expressed in Section 4.3 of [RFC6266] when consuming this property parameter value. Similarly, servers MUST follow those same guidelines before storing a value.
説明：このプロパティパラメータは、管理された添付ファイルに対応する「ATTACH」プロパティで指定される場合があります。その値は、添付データを格納するためのファイル名を作成する方法に関する情報を提供します。このパラメーターは、Content-Dispositionヘッダーフィールドの "filename"パラメーターと性質が非常に似ており、同じセキュリティリスクを露呈します。結果として、このプロパティパラメータ値を使用する場合、クライアントは[RFC6266]のセクション4.3に記載されているガイドラインに従う必要があります。同様に、サーバーは値を保存する前にそれらと同じガイドラインに従う必要があります。
Example:
例：
ATTACH;FILENAME=agenda.html:
https://attachments.example.com/rt452S
Parameter Name: MANAGED-ID
パラメータ名：MANAGED-ID
Purpose: To uniquely identify a managed attachment.
目的：管理された添付ファイルを一意に識別するため。
Format Definition: This property parameter is defined by the following notation:
フォーマット定義：このプロパティパラメータは、次の表記法で定義されます。
managedidparam = "MANAGED-ID" "=" paramtext
managedidparam = "MANAGED-ID" "=" paramtext
Description: This property parameter MUST be specified on "ATTACH" properties corresponding to managed attachments. Its value is generated by the server and uniquely identifies a managed attachment within the scope of the CalDAV server. This property parameter MUST NOT be present in the case of unmanaged attachments.
説明：このプロパティパラメータは、管理された添付ファイルに対応する「ATTACH」プロパティで指定する必要があります。その値はサーバーによって生成され、CalDAVサーバーのスコープ内で管理されたアタッチメントを一意に識別します。管理されていない添付ファイルの場合、このプロパティパラメータは存在してはなりません（MUST NOT）。
Example:
例：
ATTACH;MANAGED-ID=aUNhbGVuZGFy:
https://attachments.example.com/abcd.txt
The Cal-Managed-ID response header field provides the value of the "MANAGED-ID" property parameter corresponding to a newly added "ATTACH" property.
Cal-Managed-ID応答ヘッダーフィールドは、新しく追加された「ATTACH」プロパティに対応する「MANAGED-ID」プロパティパラメータの値を提供します。
ABNF:
ABNF：
Cal-Managed-ID = "Cal-Managed-ID" ":" paramtext ; "paramtext" is defined in Section 3.1 of [RFC5545]
Cal-Managed-ID = "Cal-Managed-ID" "：" paramtext; 「paramtext」は、[RFC5545]のセクション3.1で定義されています
Example:
例：
Cal-Managed-ID:aUNhbGVuZGFy The Cal-Managed-ID header field MUST only be sent by an origin server in response to a successful POST request with an "action" query parameter set to "attachment-add" or "attachment-update". It MUST only appear once in a response and MUST NOT appear in trailers.
Cal-Managed-ID：aUNhbGVuZGFy Cal-Managed-IDヘッダーフィールドは、「attachment-add」または「attachment-update」に設定された「action」クエリパラメータを使用したPOSTリクエストの成功に応答して、オリジンサーバーからのみ送信される必要があります。 。応答に1回だけ出現する必要があり、トレーラーに出現してはなりません。
The Cal-Managed-ID header field is end to end and MUST be forwarded by intermediaries. Intermediaries MUST NOT insert, delete, or modify a Cal-Managed-ID header field.
Cal-Managed-IDヘッダーフィールドはエンドツーエンドであり、仲介者によって転送される必要があります。仲介者は、Cal-Managed-IDヘッダーフィールドを挿入、削除、または変更してはなりません。
Name: managed-attachments-server-URL
名前：managed-attachments-server-URL
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: This property specifies the server base URI to use when retrieving managed attachments.
目的：このプロパティは、管理された添付ファイルを取得するときに使用するサーバーのベースURIを指定します。
Protected: This property MUST be protected as only the server can update the value.
保護：サーバーのみが値を更新できるため、このプロパティは保護する必要があります。
COPY/MOVE behavior: This property is only defined on a calendar home collection, which cannot be moved or copied.
コピー/移動の動作：このプロパティはカレンダーのホームコレクションでのみ定義され、移動またはコピーできません。
allprop behavior: This property SHOULD NOT be returned by a PROPFIND DAV:allprop request.
allpropの動作：このプロパティは、PROPFIND DAV：allpropリクエストによって返されるべきではありません（SHOULD NOT）。
Description: This property MAY be defined on a calendar home collection. If present, it contains either a single DAV:href XML element or none at all.
説明：このプロパティは、カレンダーのホームコレクションで定義される場合があります。存在する場合、単一のDAV：href XML要素を含むか、まったく含まないかのいずれかです。
When one DAV:href element is present, its value MUST be an absolute HTTP URI containing only the scheme (i.e., "https") and authority (i.e., host and port) parts. Whenever a managed attachment is to be retrieved via an HTTP GET, the client MUST construct the actual URL of the attachment by substituting the scheme and authority parts of the attachment URI (as stored in the iCalendar "ATTACH" property) with the present WebDAV property value.
1つのDAV：href要素が存在する場合、その値は、スキーム（つまり「https」）と権限（つまりホストとポート）の部分のみを含む絶対HTTP URIでなければなりません。管理された添付ファイルがHTTP GETを介して取得されるときは常に、クライアントは添付ファイルURI（iCalendarの「ATTACH」プロパティに格納されているもの）のスキームと権限部分を現在のWebDAVプロパティで置き換えることにより、添付ファイルの実際のURLを構築する必要があります。値。
When no DAV:href element is present, the client MUST substitute the scheme and authority parts of the attachment URI with the scheme and authority part of the calendar home collection absolute URI.
DAV：href要素が存在しない場合、クライアントは添付URIのスキームと権限の部分をカレンダーホームコレクションの絶対URIのスキームと権限の部分に置き換えなければなりません（MUST）。
In the absence of this property, the client can consider the attachment URI as its actual URL.
このプロパティがない場合、クライアントは添付URIを実際のURLと見なすことができます。
Definition:
定義：
<!ELEMENT managed-attachments-server-URL (DAV:href?)>
Example:
例：
<C:managed-attachments-server-URL xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:href>https://attachstore.example.com</D:href>
</C:managed-attachments-server-URL>
Name: max-attachment-size
名前：max-attachment-size
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: This property provides a numeric value indicating the maximum attachment size, in octets, that the server is willing to accept when a managed attachment is stored on the server.
目的：このプロパティは、管理された添付ファイルがサーバーに保存されているときにサーバーが受け入れようとする最大添付ファイルサイズをオクテット単位で示す数値を提供します。
Protected: This property MUST be protected as it indicates limits provided by the server.
保護：このプロパティは、サーバーによって提供される制限を示すため、保護する必要があります。
COPY/MOVE behavior: This property value MUST be preserved in COPY and MOVE operations.
COPY / MOVE動作：このプロパティ値は、COPYおよびMOVE操作で保持する必要があります。
allprop behavior: This property SHOULD NOT be returned by a PROPFIND DAV:allprop request.
allpropの動作：このプロパティは、PROPFIND DAV：allpropリクエストによって返されるべきではありません（SHOULD NOT）。
Description: The "CALDAV:max-attachment-size" property is used to specify a numeric value that represents the maximum attachment size, in octets, that the server is willing to accept when a managed attachment is stored on the server. The property is defined on the parent collection of the calendar object resource to which the attachment is associated. Any attempt to store a managed attachment exceeding this size MUST result in an error, with the CALDAV:max-attachment-size precondition (Section 3.11) being violated. In the absence of this property, the client can assume that the server will allow storing an attachment of any reasonable size.
説明： "CALDAV：max-attachment-size"プロパティは、管理された添付ファイルがサーバーに保存されたときにサーバーが受け入れることのできる最大添付ファイルサイズをオクテットで表す数値を指定するために使用されます。プロパティは、添付ファイルが関連付けられているカレンダーオブジェクトリソースの親コレクションで定義されます。このサイズを超えるマネージドアタッチメントを保存しようとすると、CALDAV：max-attachment-size前提条件（セクション3.11）に違反して、エラーが発生する必要があります。このプロパティがない場合、クライアントはサーバーが適切なサイズの添付ファイルを保存できると想定できます。
Definition:
定義：
<!ELEMENT max-attachment-size (#PCDATA)>
<!-- PCDATA value: a numeric value (positive decimal integer) -->
Example:
例：
<C:max-attachment-size xmlns:C="urn:ietf:params:xml:ns:caldav"
>102400000</C:max-attachment-size>
Name: max-attachments-per-resource
名前：max-attachments-per-resource
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: This property provides a numeric value indicating the maximum number of managed attachments across all instances of a calendar object resource stored in a calendar collection.
目的：このプロパティは、カレンダーコレクションに格納されているカレンダーオブジェクトリソースのすべてのインスタンスにわたる管理された添付ファイルの最大数を示す数値を提供します。
Protected: This property MUST be protected as it indicates limits provided by the server.
保護：このプロパティは、サーバーによって提供される制限を示すため、保護する必要があります。
COPY/MOVE behavior: This property value MUST be preserved in COPY and MOVE operations.
COPY / MOVE動作：このプロパティ値は、COPYおよびMOVE操作で保持する必要があります。
allprop behavior: This property SHOULD NOT be returned by a PROPFIND DAV:allprop request.
allpropの動作：このプロパティは、PROPFIND DAV：allpropリクエストによって返されるべきではありません（SHOULD NOT）。
Description: The "CALDAV:max-attachments-per-resource" property is used to specify a numeric value that represents the maximum number of managed attachments across all instances of a calendar object resource stored in a calendar collection. Unmanaged attachments are not counted toward that limit. The property is defined on the parent collection of the calendar object resource to which the attachment is associated. Any attempt to add a managed attachment that would cause the calendar resource to exceed this limit MUST result in an error, with the CALDAV:max-attachments-per-resource precondition (Section 3.11) being violated. In the absence of this property, the client can assume that the server can handle any number of managed attachments per calendar resource.
説明：「CALDAV：max-attachments-per-resource」プロパティは、カレンダーコレクションに保存されているカレンダーオブジェクトリソースのすべてのインスタンスにわたる管理された添付ファイルの最大数を表す数値を指定するために使用されます。管理されていない添付ファイルは、この制限にカウントされません。プロパティは、添付ファイルが関連付けられているカレンダーオブジェクトリソースの親コレクションで定義されます。カレンダーリソースがこの制限を超える原因となる管理された添付ファイルを追加しようとすると、CALDAV：max-attachments-per-resource前提条件（セクション3.11）に違反したエラーが発生する必要があります。このプロパティがない場合、クライアントは、サーバーがカレンダーリソースごとに管理された添付ファイルをいくつでも処理できると想定できます。
Definition:
定義：
<!ELEMENT max-attachments-per-resource (#PCDATA)> <!-- PCDATA value: a numeric value (positive decimal integer) --> Example:
<！ELEMENT max-attachments-per-resource（#PCDATA）> <！-PCDATA値：数値（正の10進整数）->例：
<C:max-attachments-per-resource
xmlns:C="urn:ietf:params:xml:ns:caldav"
>12</C:max-attachments-per-resource>
The security considerations in [RFC4791] and [RFC4918] apply to this extension. Additionally, servers need to be aware that a client could attack underlying storage by POSTing extremely large attachments and could attack processing time by uploading a recurring event with a large number of overrides and then repeatedly adding, updating, and deleting attachments.
[RFC4791]と[RFC4918]のセキュリティに関する考慮事項がこの拡張機能に適用されます。さらに、サーバーは、クライアントが非常に大きな添付ファイルをPOSTすることで基礎となるストレージを攻撃し、多数のオーバーライドを含む定期的なイベントをアップロードして、添付ファイルを繰り返し追加、更新、削除することで処理時間を攻撃する可能性があることを認識する必要があります。
Malicious content could be introduced into the calendar server by way of a managed attachment, and propagated to many end users via scheduling. Servers SHOULD check managed attachments for malicious or inappropriate content. Upon detecting such content, servers SHOULD remove the attachment following the rules described in Section 3.12.5.
悪意のあるコンテンツが、管理された添付ファイルを介してカレンダーサーバーに導入され、スケジューリングを介して多くのエンドユーザーに感染する可能性があります。サーバーは、管理された添付ファイルをチェックして、悪質なコンテンツや不適切なコンテンツがないかどうかを確認する必要があります。このようなコンテンツを検出すると、サーバーはセクション3.12.5で説明されているルールに従って添付ファイルを削除する必要があります（SHOULD）。
This specification defines the following new iCalendar property parameters to be added to the "Parameters" registry defined in Section 8.2.4 of [RFC5545]:
この仕様では、[RFC5545]のセクション8.2.4で定義されている「Parameters」レジストリに追加される次の新しいiCalendarプロパティパラメータを定義しています。
+------------+---------+-----------------------+
| Parameter | Status | Reference |
+------------+---------+-----------------------+
| SIZE | Current | RFC 8607, Section 4.1 |
| FILENAME | Current | RFC 8607, Section 4.2 |
| MANAGED-ID | Current | RFC 8607, Section 4.3 |
+------------+---------+-----------------------+
The message header fields below should be added to the "Permanent Message Header Field Names" registry (see [RFC3864]).
以下のメッセージヘッダーフィールドを「Permanent Message Header Field Names」レジストリに追加する必要があります（[RFC3864]を参照）。
Header field name: Cal-Managed-ID
ヘッダーフィールド名：Cal-Managed-ID
Protocol: http
プロトコル：http
Status: standard
ステータス：標準
Author/Change controller: IETF
作成者/変更コントローラ：IETF
Reference: this specification (Section 5.1)
参照：この仕様（セクション5.1）
Related information: none
関連情報：なし
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, DOI 10.17487/RFC2518, February 1999, <https://www.rfc-editor.org/info/rfc2518>.
[RFC2518] Goland、Y.、Whitehead、E.、Faizi、A.、Carter、S。、およびD. Jensen、「分散オーサリング用のHTTP拡張機能-WEBDAV」、RFC 2518、DOI 10.17487 / RFC2518、1999年2月、 <https://www.rfc-editor.org/info/rfc2518>。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, <https://www.rfc-editor.org/info/rfc3864>.
[RFC3864] Klyne、G.、Nottingham、M。、およびJ. Mogul、「メッセージヘッダーフィールドの登録手順」、BCP 90、RFC 3864、DOI 10.17487 / RFC3864、2004年9月、<https：//www.rfc- editor.org/info/rfc3864>。
[RFC4331] Korver, B. and L. Dusseault, "Quota and Size Properties for Distributed Authoring and Versioning (DAV) Collections", RFC 4331, DOI 10.17487/RFC4331, February 2006, <https://www.rfc-editor.org/info/rfc4331>.
[RFC4331] Korver、B。およびL. Dusseault、「分散オーサリングおよびバージョン管理（DAV）コレクションのクォータおよびサイズプロパティ」、RFC 4331、DOI 10.17487 / RFC4331、2006年2月、<https：//www.rfc-editor。 org / info / rfc4331>。
[RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, DOI 10.17487/RFC4791, March 2007, <https://www.rfc-editor.org/info/rfc4791>.
[RFC4791] Daboo、C.、Desruisseaux、B。、およびL. Dusseault、「Calendaring Extensions to WebDAV（CalDAV）」、RFC 4791、DOI 10.17487 / RFC4791、2007年3月、<https：//www.rfc-editor。 org / info / rfc4791>。
[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, DOI 10.17487/RFC4918, June 2007, <https://www.rfc-editor.org/info/rfc4918>.
[RFC4918] Dusseault、L.、Ed。、「Web Distributed Authoring and Versioning（WebDAV）のHTTP拡張機能」、RFC 4918、DOI 10.17487 / RFC4918、2007年6月、<https://www.rfc-editor.org/info / rfc4918>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。
[RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, DOI 10.17487/RFC5545, September 2009, <https://www.rfc-editor.org/info/rfc5545>.
[RFC5545] Desruisseaux、B。、編、「インターネットカレンダーおよびスケジューリングコアオブジェクト仕様（iCalendar）」、RFC 5545、DOI 10.17487 / RFC5545、2009年9月、<https://www.rfc-editor.org/info/ rfc5545>。
[RFC6266] Reschke, J., "Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)", RFC 6266, DOI 10.17487/RFC6266, June 2011, <https://www.rfc-editor.org/info/rfc6266>.
[RFC6266] Reschke、J。、「ハイパーテキスト転送プロトコル（HTTP）でのContent-Dispositionヘッダーフィールドの使用」、RFC 6266、DOI 10.17487 / RFC6266、2011年6月、<https://www.rfc-editor.org / info / rfc6266>。
[RFC6638] Daboo, C. and B. Desruisseaux, "Scheduling Extensions to CalDAV", RFC 6638, DOI 10.17487/RFC6638, June 2012, <https://www.rfc-editor.org/info/rfc6638>.
[RFC6638] Daboo、C。およびB. Desruisseaux、「Scheduling Extensions to CalDAV」、RFC 6638、DOI 10.17487 / RFC6638、2012年6月、<https://www.rfc-editor.org/info/rfc6638>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<https://www.rfc-editor.org/info/ rfc7230>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<https://www.rfc-editor.org/info/rfc7231 >。
[RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240, DOI 10.17487/RFC7240, June 2014, <https://www.rfc-editor.org/info/rfc7240>.
[RFC7240] Snell、J。、「Prefer Header for HTTP」、RFC 7240、DOI 10.17487 / RFC7240、2014年6月、<https://www.rfc-editor.org/info/rfc7240>。
[RFC7538] Reschke, J., "The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)", RFC 7538, DOI 10.17487/RFC7538, April 2015, <https://www.rfc-editor.org/info/rfc7538>.
[RFC7538] Reschke、J。、「Hypertext Transfer Protocol Status Code 308（Permanent Redirect）」、RFC 7538、DOI 10.17487 / RFC7538、2015年4月、<https://www.rfc-editor.org/info/rfc7538> 。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023, October 2007, <https://www.rfc-editor.org/info/rfc5023>.
[RFC5023]グレゴリオ、J、エド。 B. de hOra編、「The Atom Publishing Protocol」、RFC 5023、DOI 10.17487 / RFC5023、2007年10月、<https://www.rfc-editor.org/info/rfc5023>。
[RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent Interoperability Protocol (iTIP)", RFC 5546, DOI 10.17487/RFC5546, December 2009, <https://www.rfc-editor.org/info/rfc5546>.
[RFC5546] Daboo、C。、編、「iCalendarトランスポート非依存相互運用プロトコル（iTIP）」、RFC 5546、DOI 10.17487 / RFC5546、2009年12月、<https://www.rfc-editor.org/info/rfc5546 >。
[RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, RFC 7320, DOI 10.17487/RFC7320, July 2014, <https://www.rfc-editor.org/info/rfc7320>.
[RFC7320]ノッティンガム、M。、「URIデザインと所有権」、BCP 190、RFC 7320、DOI 10.17487 / RFC7320、2014年7月、<https://www.rfc-editor.org/info/rfc7320>。
[RFC8144] Murchison, K., "Use of the Prefer Header Field in Web Distributed Authoring and Versioning (WebDAV)", RFC 8144, DOI 10.17487/RFC8144, April 2017, <https://www.rfc-editor.org/info/rfc8144>.
[RFC8144] Murchison、K。、「Web Distributed Authoring and Versioning（WebDAV）での優先ヘッダーフィールドの使用」、RFC 8144、DOI 10.17487 / RFC8144、2017年4月、<https://www.rfc-editor.org/ info / rfc8144>。
In the following example, the organizer of a recurring meeting makes an unsuccessful attempt to add an agenda (HTML attachment) to the corresponding calendar resource with a conditional request. Note that the client includes both the Expect and Prefer header fields in the request, thereby preventing itself from needlessly sending the attachment data and requesting that the current resource be returned in the failure response (see Section 3.2 of [RFC8144]).
次の例では、定期的な会議の開催者が、条件付き要求を使用して、対応するカレンダーリソースに議題（HTML添付ファイル）を追加しようとして失敗しました。クライアントのExpectヘッダーとPreferヘッダーの両方のフィールドがリクエストに含まれているため、クライアントが不必要に添付データを送信したり、現在のリソースを失敗のレスポンスで返すように要求したりすることができないことに注意してください（[RFC8144]のセクション3.2を参照）。
>> Request <<
POST /events/65.ics?action=attachment-add HTTP/1.1
Host: cal.example.com
Content-Type: text/html; charset="utf-8"
Content-Disposition: attachment;filename=agenda.html
Content-Length: 80
If-Match: "abcdefg-000"
Expect: 100-continue
Prefer: return=representation
>> Final Response <<
HTTP/1.1 412 Precondition Failed
Content-Type: text/calendar; charset="utf-8"
Content-Length: 929
Content-Location: https://cal.example.com/events/65.ics
ETag: "123456789-000-000"
BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Server//EN BEGIN:VTIMEZONE LAST-MODIFIED:20040110T032845Z TZID:America/Montreal BEGIN:DAYLIGHT DTSTART:20000404T020000 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 TZNAME:EDT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 END:DAYLIGHT BEGIN:STANDARD DTSTART:20001026T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 TZNAME:EST TZOFFSETFROM:-0400 TZOFFSETTO:-0500 END:STANDARD END:VTIMEZONE BEGIN:VEVENT UID:20010712T182145Z-123401@example.com DTSTAMP:20120201T203412Z DTSTART;TZID=America/Montreal:20120206T100000 DURATION:PT1H RRULE:FREQ=WEEKLY SUMMARY:Planning Meeting ORGANIZER:mailto:cyrus@example.com ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:cyrus@exampl e.com ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:arnaudq@exam ple.com ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION:mailto:mike@exa mple.com END:VEVENT END:VCALENDAR The organizer of a recurring meeting successfully adds an agenda (HTML attachment) to the corresponding calendar resource. Attendees of the meeting are granted read access to the newly created attachment resource. Their own copy of the meeting is updated to include the new "ATTACH" property pointing to the attachment resource, and they are notified of the change via their scheduling inbox.
BEGIN：VCALENDAR VERSION：2.0 PRODID：-// Example Corp.//CalDAV Server // EN BEGIN：VTIMEZONE LAST-MODIFIED：20040110T032845Z TZID：America / Montreal BEGIN：DAYLIGHT DTSTART：20000404T020000 RRULE：FREQ = YEARLY; BYDAY = 1SU; BYMONTH = 4 TZNAME：EDT TZOFFSETFROM：-0500 TZOFFSETTO：-0400 END：DAYLIGHT BEGIN：STANDARD DTSTART：20001026T020000 RRULE：FREQ = YEARLY; BYDAY = -1SU; BYMONTH = 10 TZNAME：EST TZOFFSETFROM：-0400 TZOFFSETTO：-0500 END： STANDARD END：VTIMEZONE BEGIN：VEVENT UID：20010712T182145Z-123401@example.com DTSTAMP：20120201T203412Z DTSTART; TZID = America / Montreal：20120206T100000 DURATION：PT1H RRULE：FREQ = WEEKLY SUMMARY：Planning Meeting ORGANIZER：mailtocom：exampleへのメール; CUTYPE = INDIVIDUAL; PARTSTAT = ACCEPTED：mailto：cyrus @ exampl e.com ATTENDEE; CUTYPE = INDIVIDUAL; PARTSTAT = ACDIVTED：mailto：arnaudq @ exam ple.com ATTENDEE; CUTYPE = INDIVIDUAL; PARTSTAT = NEEDS-ACTION：mailto：mike @exa mple.com END：VEVENT END：VCALENDAR定期的な会議の主催者が対応するカレンダーに議題（HTML添付ファイル）を追加しましたrリソース。会議の出席者には、新しく作成された添付リソースへの読み取りアクセスが許可されます。会議の独自のコピーが更新され、添付リソースを指す新しい「ATTACH」プロパティが含まれ、スケジュールの受信トレイを介して変更が通知されます。
>> Request <<
POST /events/65.ics?action=attachment-add HTTP/1.1
Host: cal.example.com
Content-Type: text/html; charset="utf-8"
Content-Disposition: attachment;filename=agenda.html
Content-Length: 80
If-Match: "123456789-000-000"
Expect: 100-continue
Prefer: return=representation
>> Interim Response <<
HTTP/1.1 100 Continue
HTTP / 1.1 100続行
>> Request Body <<
<html>
<body>
<h1>Agenda</h1>
<p>As usual</p>
</body>
</html>
>> Final Response <<
HTTP/1.1 201 Created
Content-Type: text/calendar; charset="utf-8"
Content-Length: 1043
Content-Location: https://cal.example.com/events/65.ics
ETag: "123456789-000-111"
Cal-Managed-ID: 97S
BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Server//EN BEGIN:VTIMEZONE LAST-MODIFIED:20040110T032845Z TZID:America/Montreal BEGIN:DAYLIGHT DTSTART:20000404T020000 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 TZNAME:EDT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 END:DAYLIGHT BEGIN:STANDARD DTSTART:20001026T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 TZNAME:EST TZOFFSETFROM:-0400 TZOFFSETTO:-0500 END:STANDARD END:VTIMEZONE BEGIN:VEVENT UID:20010712T182145Z-123401@example.com DTSTAMP:20120201T203412Z DTSTART;TZID=America/Montreal:20120206T100000 DURATION:PT1H RRULE:FREQ=WEEKLY SUMMARY:Planning Meeting ORGANIZER:mailto:cyrus@example.com ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:cyrus@exampl e.com ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:arnaudq@exam ple.com ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION:mailto:mike@exa mple.com ATTACH;MANAGED-ID=97S;FMTTYPE=text/html;SIZE=80; FILENAME=agenda.html:https://cal.example.com/attach/65/34X22R END:VEVENT END:VCALENDAR The organizer has a more specific agenda for the 20th of February meeting. It is added to that particular instance of the meeting by specifying the "rid" query parameter. Note that an overridden instance is created with the "RECURRENCE-ID" property value matching the value of the "rid" query parameter in the request. Also, note that the server takes significant time to complete the request and notifies the client accordingly.
BEGIN：VCALENDAR VERSION：2.0 PRODID：-// Example Corp.//CalDAV Server // EN BEGIN：VTIMEZONE LAST-MODIFIED：20040110T032845Z TZID：America / Montreal BEGIN：DAYLIGHT DTSTART：20000404T020000 RRULE：FREQ = YEARLY; BYDAY = 1SU; BYMONTH = 4 TZNAME：EDT TZOFFSETFROM：-0500 TZOFFSETTO：-0400 END：DAYLIGHT BEGIN：STANDARD DTSTART：20001026T020000 RRULE：FREQ = YEARLY; BYDAY = -1SU; BYMONTH = 10 TZNAME：EST TZOFFSETFROM：-0400 TZOFFSETTO：-0500 END： STANDARD END：VTIMEZONE BEGIN：VEVENT UID：20010712T182145Z-123401@example.com DTSTAMP：20120201T203412Z DTSTART; TZID = America / Montreal：20120206T100000 DURATION：PT1H RRULE：FREQ = WEEKLY SUMMARY：Planning Meeting ORGANIZER：mailtocom：exampleへのメール; CUTYPE = INDIVIDUAL; PARTSTAT = ACCEPTED：mailto：cyrus @ exampl e.com ATTENDEE; CUTYPE = INDIVIDUAL; PARTSTAT = ACDIVTED：mailto：arnaudq @ exam ple.com ATTENDEE; CUTYPE = INDIVIDUAL; PARTSTAT = NEEDS-ACTION：mailto：mike @exa mple.com ATTACH; MANAGED-ID = 97S; FMTTYPE = text / html; SIZE = 80; FILENAME = agenda.html：https：//cal.example.com/attach/65/34X22R END：VEVENT END：VCALENDAR主催者は、2月20日の会議のより具体的な議題を持っています。 「rid」クエリパラメータを指定することで、会議の特定のインスタンスに追加されます。オーバーライドされたインスタンスは、リクエストの「rid」クエリパラメータの値と一致する「RECURRENCE-ID」プロパティ値で作成されることに注意してください。また、サーバーは要求を完了するのにかなりの時間がかかり、それに応じてクライアントに通知することに注意してください。
>> Request <<
POST /events/65.ics?action=attachment-add&rid=20120220T100000 HTTP/1.1
Host: cal.example.com
Content-Type: text/html; charset="utf-8"
Content-Disposition: attachment;filename=agenda0220.html
Content-Length: 105
If-Match: "123456789-000-111"
Expect: 100-continue
Prefer: return=representation
>> Interim Response <<
HTTP/1.1 100 Continue
HTTP / 1.1 100続行
>> Request Body <<
<html>
<body>
<h1>Agenda</h1>
<p>Something different, for a change</p>
</body>
</html>
>> Interim Response <<
HTTP/1.1 102 Processing
HTTP / 1.1 102処理
>> Final Response <<
HTTP/1.1 201 Created
Content-Type: text/calendar; charset="utf-8"
Content-Length: 1661
Content-Location: https://cal.example.com/events/65.ics
ETag: "123456789-000-222"
Cal-Managed-ID: 33225
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Server//EN
BEGIN:VTIMEZONE
LAST-MODIFIED:20040110T032845Z
TZID:America/Montreal
BEGIN:DAYLIGHT
DTSTART:20000404T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20001026T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:20010712T182145Z-123401@example.com
DTSTAMP:20120201T203412Z
DTSTART;TZID=America/Montreal:20120206T100000
DURATION:PT1H
RRULE:FREQ=WEEKLY
SUMMARY:Planning Meeting
ORGANIZER:mailto:cyrus@example.com
ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:cyrus@exampl
e.com
ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:arnaudq@exam
ple.com
ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION:mailto:mike@exa
mple.com
ATTACH;MANAGED-ID=97S;FMTTYPE=text/html;SIZE=80;
FILENAME=agenda.html:https://cal.example.com/attach/65/34X22R
END:VEVENT
BEGIN:VEVENT
UID:20010712T182145Z-123401@example.com
RECURRENCE-ID;TZID=America/Montreal:20120220T100000
DTSTAMP:20120201T203412Z
DTSTART;TZID=America/Montreal:20120220T100000
DURATION:PT1H
SUMMARY:Planning Meeting
ORGANIZER:mailto:cyrus@example.com
ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:cyrus@example.
com
ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:arnaudq@exampl
e.com
ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION:mailto:mike@examp
le.com
ATTACH;MANAGED-ID=33225;FMTTYPE=text/html;SIZE=105;
FILENAME=agenda0220.html:https://cal.example.com/attach/65/FGZ225
END:VEVENT
END:VCALENDAR
Acknowledgments
謝辞
This specification came about via discussions at the Calendaring and Scheduling Consortium. Thanks in particular to Mike Douglass and Eric York.
この仕様は、Calendaring and Scheduling Consortiumでの議論を通じて生まれました。特にMike DouglassとEric Yorkに感謝します。
Authors' Addresses
著者のアドレス
Cyrus Daboo Apple Inc. 1 Infinite Loop Cupertino, CA 95014 United States of America
Cyrus Daboo Apple Inc. 1 Infinite Loop Cupertino、CA 95014アメリカ合衆国
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/
Kenneth Murchison (editor) FastMail US LLC 1429 Walnut St, Suite 1201 Philadephia, PA 19102 United States of America
ケネス・マーチソン（編集者）FastMail US LLC 1429 Walnut St、Suite 1201 Philadephia、PA 19102アメリカ合衆国
Email: murch@fastmailteam.com
URI: http://www.fastmail.com/