Movatterモバイル変換

[0]ホーム
URL:

Agenda

Daboo, et al. Informational [Page 9] RFC 8607 CalDAV-Managed Attachments June 2019 >> 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:VCALENDAR3.5. Updating Attachments 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. 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: A. The Request-URI will include an "action" query parameter with the value "attachment-update" (see Section 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). C. The body of the request contains the updated data for the attachment.Daboo, et al. Informational [Page 10] RFC 8607 CalDAV-Managed Attachments June 2019 D. The client MUST include a valid Content-Type header field describing the media type of the attachment (as required by 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. 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. 2. When the server receives the POST request, it does the following: A. Validates that the "managed-id" query parameter is valid for the calendar object resource. B. Updates the content of the attachment resource corresponding to that "managed-id" value with the supplied attachment data. 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. 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 calendarDaboo, et al. Informational [Page 11] RFC 8607 CalDAV-Managed Attachments June 2019 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. 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). 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. >> 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

Agenda

Discuss attachment draft

Daboo, et al. Informational [Page 12] RFC 8607 CalDAV-Managed Attachments June 2019 >> 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:VCALENDAR3.6. Removing Attachments via POST 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: A. The Request-URI will include an "action" query parameter with the value "attachment-remove" (see Section 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). 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). D. The body of the request will be empty.Daboo, et al. Informational [Page 13] RFC 8607 CalDAV-Managed Attachments June 2019 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. 2. When the server receives the POST request, it does the following: A. Validates that any recurrence instances referred to via the "rid" query parameter are valid for the calendar object resource being targeted. B. Validates that the "managed-id" query parameter is valid for the calendar object resource and specific instances being targeted. 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. 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. 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. 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.Daboo, et al. Informational [Page 14] RFC 8607 CalDAV-Managed Attachments June 2019 >> 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: 03.7. Adding Existing Managed Attachments via PUT 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). 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. These PUT requests are subject to the preconditions listed in Section 3.11.3.8. Updating Attachments via PUT 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.3.9. Removing Attachments via PUT 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.3.10. Retrieving Attachments 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).Daboo, et al. Informational [Page 15] RFC 8607 CalDAV-Managed Attachments June 20193.11. Error Handling This specification creates additional preconditions for the POST method. 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-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: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-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-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. 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): (CALDAV:max-resource-size) (from Section 5.3.2.1 of [RFC4791]) (DAV:quota-not-exceeded) (from Section 6 of [RFC4331]) (DAV:sufficient-disk-space) (from Section 6 of [RFC4331])Daboo, et al. Informational [Page 16] RFC 8607 CalDAV-Managed Attachments June 2019 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: (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). 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. 2. The appropriate XML element MUST be returned as the child of a top-level DAV:error element in the response body.3.12. Additional Considerations3.12.1. Quotas 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.3.12.2. Access Control 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). 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. 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.Daboo, et al. Informational [Page 17] RFC 8607 CalDAV-Managed Attachments June 20193.12.3. Redirects 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.3.12.4. Processing Time 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.3.12.5. Automatic Cleanup by Servers 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.3.12.6. Sending Scheduling Messages with Attachments 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].3.12.7. Migrating Calendar Data 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).Daboo, et al. Informational [Page 18] RFC 8607 CalDAV-Managed Attachments June 20194. Modifications to iCalendar Syntax4.1. SIZE Property Parameter Parameter Name: 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 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. Example: ATTACH;SIZE=1234:https://attachments.example.com/abcd.txt4.2. FILENAME Property Parameter Parameter Name: FILENAME Purpose: To specify the filename of a managed attachment. Format Definition: This property parameter is defined by the following notation: 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.Daboo, et al. Informational [Page 19] RFC 8607 CalDAV-Managed Attachments June 2019 Example: ATTACH;FILENAME=agenda.html: https://attachments.example.com/rt452S4.3. MANAGED-ID Property Parameter Parameter Name: MANAGED-ID Purpose: To uniquely identify a managed attachment. Format Definition: This property parameter is defined by the following notation: 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. Example: ATTACH;MANAGED-ID=aUNhbGVuZGFy: https://attachments.example.com/abcd.txt5. Additional Message Header Fields5.1. Cal-Managed-ID Response Header Field The Cal-Managed-ID response header field provides the value of the "MANAGED-ID" property parameter corresponding to a newly added "ATTACH" property. ABNF: Cal-Managed-ID = "Cal-Managed-ID" ":" paramtext ; "paramtext" is defined in Section 3.1 of [RFC5545] Example: Cal-Managed-ID:aUNhbGVuZGFyDaboo, et al. Informational [Page 20] RFC 8607 CalDAV-Managed Attachments June 2019 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. 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.6. Additional WebDAV Properties6.1. CALDAV:managed-attachments-server-URL Property Name: 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. 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. 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. 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. 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.Daboo, et al. Informational [Page 21] RFC 8607 CalDAV-Managed Attachments June 2019 In the absence of this property, the client can consider the attachment URI as its actual URL. Definition: Example:https://attachstore.example.com6.2. CALDAV:max-attachment-size Property Name: 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. allprop behavior: This property SHOULD NOT be returned by a PROPFIND DAV:allprop request. 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.Daboo, et al. Informational [Page 22] RFC 8607 CalDAV-Managed Attachments June 2019 Definition: Example:1024000006.3. CALDAV:max-attachments-per-resource Property Name: 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. allprop behavior: This property SHOULD NOT be returned by a PROPFIND DAV:allprop request. 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. Definition: Daboo, et al. Informational [Page 23] RFC 8607 CalDAV-Managed Attachments June 2019 Example:127. Security Considerations 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. 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.8. IANA Considerations8.1. Parameter Registrations This specification defines the following new iCalendar property parameters to be added to the "Parameters" registry defined in Section 8.2.4 of [RFC5545]: +------------+---------+-----------------------+ | 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 | +------------+---------+-----------------------+Daboo, et al. Informational [Page 24] RFC 8607 CalDAV-Managed Attachments June 20198.2. Message Header Field Registrations The message header fields below should be added to the "Permanent Message Header Field Names" registry (see [RFC3864]).8.2.1. Cal-Managed-ID Header field name: Cal-Managed-ID Protocol: http Status: standard Author/Change controller: IETF Reference: this specification (Section 5.1) Related information: none9. References9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,. [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,. [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004,. [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,. [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, DOI 10.17487/RFC4791, March 2007,.Daboo, et al. Informational [Page 25] RFC 8607 CalDAV-Managed Attachments June 2019 [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, DOI 10.17487/RFC4918, June 2007,. [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008,. [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, DOI 10.17487/RFC5545, September 2009,. [RFC6266] Reschke, J., "Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)", RFC 6266, DOI 10.17487/RFC6266, June 2011,. [RFC6638] Daboo, C. and B. Desruisseaux, "Scheduling Extensions to CalDAV", RFC 6638, DOI 10.17487/RFC6638, June 2012,. [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,. [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,. [RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240, DOI 10.17487/RFC7240, June 2014,. [RFC7538] Reschke, J., "The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)", RFC 7538, DOI 10.17487/RFC7538, April 2015,. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,.Daboo, et al. Informational [Page 26] RFC 8607 CalDAV-Managed Attachments June 20199.2. Informative References [RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023, October 2007,. [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent Interoperability Protocol (iTIP)", RFC 5546, DOI 10.17487/RFC5546, December 2009,. [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, RFC 7320, DOI 10.17487/RFC7320, July 2014,. [RFC8144] Murchison, K., "Use of the Prefer Header Field in Web Distributed Authoring and Versioning (WebDAV)", RFC 8144, DOI 10.17487/RFC8144, April 2017,.Daboo, et al. Informational [Page 27] RFC 8607 CalDAV-Managed Attachments June 2019Appendix A. Example Involving Recurring Events 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]). >> 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=representationDaboo, et al. Informational [Page 28] RFC 8607 CalDAV-Managed Attachments June 2019 >> 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:VCALENDARDaboo, et al. Informational [Page 29] RFC 8607 CalDAV-Managed Attachments June 2019 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. >> 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 >> Request Body<<

Agenda

As usual

Daboo, et al. Informational [Page 30] RFC 8607 CalDAV-Managed Attachments June 2019 >> 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:VCALENDARDaboo, et al. Informational [Page 31] RFC 8607 CalDAV-Managed Attachments June 2019 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. >> 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 >> Request Body<<

Agenda

Something different, for a change

[8]ページ先頭
©2009-2025 Movatter.jp