Network Working Group C. Daboo Internet-Draft Apple Updates: 6376 (if approved) B. Desruisseaux Intended status: Standards Track Oracle Expires: November 3, 2013 May 2, 2013 Internet Calendar Scheduling Protocol (iSchedule) draft-desruisseaux-ischedule-05 Abstract This document defines the Internet Calendar Scheduling Protocol (iSchedule), which is a binding from the iCalendar Transport- independent Interoperability Protocol (iTIP) to the Hypertext Transfer Protocol (HTTP) to enable interoperability between calendaring and scheduling systems over the Internet. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 3, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Daboo & Desruisseaux Expires November 3, 2013 [Page 1]
Internet-Draft iSchedule May 2013 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Notational Conventions . . . . . . . . . . . . . . . . . . 7 2. iSchedule Model . . . . . . . . . . . . . . . . . . . . . . . 7 3. iSchedule Overview . . . . . . . . . . . . . . . . . . . . . . 8 3.1. iSchedule Sender Actions . . . . . . . . . . . . . . . . . 8 3.2. iSchedule Receiver Actions . . . . . . . . . . . . . . . . 9 4. iSchedule Receiver Discovery . . . . . . . . . . . . . . . . . 10 4.1. Resolving Calendar User Addresses . . . . . . . . . . . . 10 4.2. iSchedule SRV Service Type . . . . . . . . . . . . . . . . 11 4.3. iSchedule Service TXT Records . . . . . . . . . . . . . . 11 4.4. iSchedule Receiver Request-URI . . . . . . . . . . . . . . 12 5. iSchedule Receiver Capabilities . . . . . . . . . . . . . . . 12 5.1. Example: Querying iSchedule Receiver Capabilities . . . . 13 6. Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. POST Method . . . . . . . . . . . . . . . . . . . . . . . 14 6.1.1. Schedule Response . . . . . . . . . . . . . . . . . . 16 6.1.2. Failed Schedule Response . . . . . . . . . . . . . . . 16 7. iSchedule Domain-Level Authentication . . . . . . . . . . . . 19 7.1. Signature Content . . . . . . . . . . . . . . . . . . . . 19 7.2. Canonicalization . . . . . . . . . . . . . . . . . . . . . 21 7.2.1. The "ischedule-relaxed" Header Canonicalization Algorithm . . . . . . . . . . . . . . . . . . . . . . 21 7.3. Key Management . . . . . . . . . . . . . . . . . . . . . . 22 7.3.1. DNS-based Public Key Management . . . . . . . . . . . 22 7.3.2. HTTP-based Public Key Management . . . . . . . . . . . 22 7.3.2.1. SRV Service Type . . . . . . . . . . . . . . . . . 23 7.3.2.2. Well-known Request-URI . . . . . . . . . . . . . . 23 7.3.2.3. Example Lookup Procedure . . . . . . . . . . . . . 24 7.3.3. Private Exchange Public Key Management . . . . . . . . 24 7.4. Verification Requirements . . . . . . . . . . . . . . . . 25 7.5. Authorized Third-Party Signatures . . . . . . . . . . . . 25 8. HTTP Headers . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.1. DKIM-Signature Request Header . . . . . . . . . . . . . . 26 8.2. iSchedule-Version General Header . . . . . . . . . . . . . 26 8.3. iSchedule-Capabilities Response Header . . . . . . . . . . 26 8.4. iSchedule-Message-ID Request Header . . . . . . . . . . . 26 8.5. Originator Request Header . . . . . . . . . . . . . . . . 27 8.6. Recipient Request Header . . . . . . . . . . . . . . . . . 27 9. XML Element Definitions . . . . . . . . . . . . . . . . . . . 27 9.1. schedule-response XML Element . . . . . . . . . . . . . . 27 9.1.1. response XML Element . . . . . . . . . . . . . . . . . 27 Daboo & Desruisseaux Expires November 3, 2013 [Page 2]
Internet-Draft iSchedule May 2013 9.1.1.1. recipient XML Element . . . . . . . . . . . . . . 28 9.1.1.2. request-status XML Element . . . . . . . . . . . . 28 9.1.1.3. calendar-data XML Element . . . . . . . . . . . . 28 9.1.1.4. error XML Element . . . . . . . . . . . . . . . . 29 9.1.1.5. response-description XML Element . . . . . . . . . 29 9.2. query-result XML Element . . . . . . . . . . . . . . . . . 29 9.2.1. capabilities XML Element . . . . . . . . . . . . . . . 30 9.2.1.1. serial-number XML Element . . . . . . . . . . . . 30 9.2.1.2. versions XML Element . . . . . . . . . . . . . . . 31 9.2.1.3. scheduling-messages XML Element . . . . . . . . . 31 9.2.1.4. calendar-data-types XML Element . . . . . . . . . 32 9.2.1.5. attachments XML Element . . . . . . . . . . . . . 33 9.2.1.6. max-content-length XML Element . . . . . . . . . . 34 9.2.1.7. min-date-time XML Element . . . . . . . . . . . . 35 9.2.1.8. max-date-time XML Element . . . . . . . . . . . . 35 9.2.1.9. max-instances XML Element . . . . . . . . . . . . 35 9.2.1.10. max-recipients XML Element . . . . . . . . . . . . 36 9.2.1.11. administrator XML Element . . . . . . . . . . . . 36 10. Security Considerations . . . . . . . . . . . . . . . . . . . 36 10.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 36 10.3. DNS Considerations . . . . . . . . . . . . . . . . . . . . 37 10.4. Attachment Considerations . . . . . . . . . . . . . . . . 37 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 11.1. Namespace Registration . . . . . . . . . . . . . . . . . . 37 11.1.1. iSchedule Namespace Registration . . . . . . . . . . . 37 11.2. HTTP Headers Registration . . . . . . . . . . . . . . . . 38 11.2.1. DKIM-Signature Request Header Registration . . . . . . 38 11.2.2. iSchedule-Version General Header Registration . . . . 38 11.2.3. iSchedule-Capabilities Response Header Registration . 38 11.2.4. iSchedule-Message-ID Request Header Registration . . . 39 11.2.5. Originator Request Header Registration . . . . . . . . 39 11.2.6. Recipient Request Header Registration . . . . . . . . 39 11.3. Well-Known URI Registration . . . . . . . . . . . . . . . 39 11.3.1. iSchedule Well-Known URI Registration . . . . . . . . 40 11.3.2. DKIM Well-Known URI Registration . . . . . . . . . . . 40 11.4. DKIM Parameters Registration . . . . . . . . . . . . . . . 40 11.4.1. DKIM-Signature Query Method Registry . . . . . . . . . 40 11.4.2. DKIM Service Type Registration . . . . . . . . . . . . 40 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 13.1. Normative References . . . . . . . . . . . . . . . . . . . 41 13.2. Informative References . . . . . . . . . . . . . . . . . . 43 Appendix A. Example Scheduling Transactions . . . . . . . . . . . 43 A.1. Example: Simple Meeting Invitation . . . . . . . . . . . . 43 A.2. Example: Search for Busy Time Information . . . . . . . . 45 A.3. Example: Failed Request . . . . . . . . . . . . . . . . . 47 Appendix B. Change Log (to be removed by RFC Editor prior to Daboo & Desruisseaux Expires November 3, 2013 [Page 3]
Internet-Draft iSchedule May 2013 publication) . . . . . . . . . . . . . . . . . . . . 49 B.1. Changes in -05 . . . . . . . . . . . . . . . . . . . . . . 49 B.2. Changes in -04 . . . . . . . . . . . . . . . . . . . . . . 49 B.3. Changes in -03 . . . . . . . . . . . . . . . . . . . . . . 49 B.4. Changes in -02 . . . . . . . . . . . . . . . . . . . . . . 50 B.5. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 50 Daboo & Desruisseaux Expires November 3, 2013 [Page 4]
Internet-Draft iSchedule May 2013 1. Introduction This binding document provides the transport specific information necessary to convey iCalendar Transport-independent Interoperability Protocol (iTIP) [RFC5546] messages over the Hypertext Transfer Protocol (HTTP) [RFC2616]. The Internet Calendar Scheduling Protocol (iSchedule) enables interoperability between different calendaring and scheduling systems. Calendaring and scheduling systems that provide support for iSchedule allow their users to perform scheduling transactions such as schedule, reschedule, respond to scheduling request or cancel scheduled calendar components, as well as search for busy time information with users of other calendaring and scheduling systems on the Internet. iSchedule leverages the DomainKeys Identified Mail (DKIM) service [RFC6376] to provide end-to-end domain-level authentication based on message content that is transparent to end users. Discussion of this Internet-Draft is taking place on the mailing list <https://www.ietf.org/mailman/listinfo/ischedule>. 1.1. Motivations The iCalendar Message-Based Interoperability Protocol (iMIP) [RFC6047], has proven to be insufficient to allow users to seamlessly perform the same scheduling operations with users of other calendaring and scheduling systems on the Internet as with users of their own system. This section clarifies the motivations for a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) [RFC5546] to a transport that allows synchronous end- to-end connectivity. A binding to an email-based transport is clearly inadequate to search for busy time information since users need and expect to get an immediate response. As such, some calendaring and scheduling systems allow users to publish their free busy information in a resource accessible to others on the Internet. In the absence of a standardized mechanism to locate the resource that provides the free busy information of a user, one thus needs to know the location of this resource in addition to the calendar user address of the users one wishes to schedule with. With an email-based transport, the transparent processing of incoming scheduling messages on the server is only possible when the calendaring and scheduling system is integrated with the email system. Commonly, the processing of incoming scheduling messages Daboo & Desruisseaux Expires November 3, 2013 [Page 5]
Internet-Draft iSchedule May 2013 occurs on the client and requires user intervention, which yields the following consequences: 1. The processing of incoming scheduling messages and the corresponding updates to the calendar only occur when the client is active. As a result, free busy information may be inaccurate (e.g., user still appears busy when the organizer actually rescheduled or canceled the meeting). 2. Calendaring and scheduling systems generally restrain the number of updates sent to users to reduce the number of messages that will clutter their email inbox. As a result, attendees rarely obtain up to date participation status of other attendees. 3. The client becomes responsible for verification of the authenticity and integrity of the scheduling message. 1.2. Related Memos Implementers will need to be familiar with other documents that, along with this document, form a framework for Internet calendaring and scheduling standards. This document specifies a binding from iTIP to HTTP. o iCalendar [RFC5545] specifies a core specification of objects, data types, properties and property parameters; o iTIP [RFC5546] specifies an interoperability protocol for scheduling between different implementations. Furthermore, implementers will need to be familiar with the DomainKeys Identified Mail (DKIM) service defined in [RFC6376]. An overview of DKIM can be found in [RFC5585]. This document does not attempt to repeat the specification of concepts or definitions from these other documents. Where possible, references are made to the document that provides the specification of these concepts or definitions. 1.3. Terminology This specification reuses much of the same terminology as iCalendar [RFC5545], iTIP [RFC5546], HTTP [RFC2616], and DKIM [RFC6376]. Additional terms used by this specification are: Daboo & Desruisseaux Expires November 3, 2013 [Page 6]
Internet-Draft iSchedule May 2013 Scheduling message: An iCalendar [RFC5545] object conforming to the requirements of iTIP [RFC5546]. Originator: The calendar user who is sending a scheduling message to one or more other calendar users. Recipient: A calendar user to whom a scheduling message is being sent. iSchedule Sender: The iSchedule service responsible for sending scheduling messages. iSchedule Receiver: The iSchedule service responsible for receiving scheduling messages. 1.4. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The Augmented BNF (ABNF) syntax used by this document to describe protocol elements is defined in [RFC5234]. Definitions of XML elements in this document use XML element type declarations (as found in XML Document Type Declarations), described in Section 3.2 of [W3C.REC-xml-20081126]. The namespace "urn:ietf:params:xml:ns:ischedule" is reserved for the XML elements defined in this specification, or in other Standards Track IETF RFCs written to extend iSchedule. It MUST NOT be used for proprietary extensions. When XML element types in this namespace are referenced in this document outside of the context of an XML fragment, the string "IS:" will be prefixed to the element type names. Note that the XML declarations used in this document are incomplete, in that they do not include namespace information. Thus, the reader MUST NOT use these declarations as the only way to validate iSchedule XML element types. 2. iSchedule Model The iSchedule design can be pictured as: Daboo & Desruisseaux Expires November 3, 2013 [Page 7]
Internet-Draft iSchedule May 2013 +----------+ +-----------+ +-----------+ +----------+ | Calendar | | Calendar | | Calendar | | Calendar | | Store | | Service | iSchedule | Service | | Store | | or |-->|===========|----------->|===========|-->| or | | User | | iSchedule | | iSchedule | | User | | Agent | | Sender | | Receiver | | Agent | +----------+ +-----------+ +-----------+ +----------+ | | <--------------------------> DKIM Signature/Verification When an iSchedule Sender has a scheduling message to transmit, it determines the iSchedule Receivers to which to deliver the message and sends the appropriate iSchedule message. The iSchedule Receiver verifies the authenticity and content of the iSchedule message and delivers it to the Calendar Service. The means by which a Calendar Store or User Agent instructs a Calendar Service, acting as an iSchedule Sender, to transmit scheduling messages is outside the scope of this document. A Calendar Service could provide support for a standard calendar access protocol, such as CalDAV [RFC4791], [RFC6638] or any other protocol, to allow a Calendar User Agent to perform scheduling operations with users of other Calendar Services. Likewise, the actual processing of scheduling messages received by a Calendar Service, acting as an iSchedule Receiver, is also outside the scope of this document. Some Calendar Service implementations may decide to process some or all received scheduling messages, while other implementations may decide to leave that work to Calendar User Agent implementations. 3. iSchedule Overview This section provides an overview of the various steps involved for iSchedule Senders and Receivers to transmit scheduling messages between Calendar Services. It references later sections describing the precise details of each step. 3.1. iSchedule Sender Actions A Calendar Service will generate an iTIP [RFC5546] scheduling message for transmission. It will additionally provide details of the Originator and Recipients. The Calendar Service will "submit" the scheduling message and details to the iSchedule Sender, through a process that is outside the scope of this document. The iSchedule Sender MUST verify the authenticity of the Originator Daboo & Desruisseaux Expires November 3, 2013 [Page 8]
Internet-Draft iSchedule May 2013 and the Originator's authorization to send the scheduling message. In particular the "ORGANIZER" iCalendar property value MUST match the Originator calendar user address. The process by which this authentication and authorization is done is outside the scope of this document. For each Recipient, the iSchedule Sender will attempt to lookup a matching iSchedule Receiver to which the iSchedule message can be sent, following the rules in Section 4. After determining the iSchedule Receiver to use, the iSchedule Sender MUST check the capabilities of the iSchedule Receiver to ensure it will be able to accept the scheduling message that needs to be sent, as per Section 5. The iSchedule Sender MUST group together Recipients for whom the iSchedule Receiver is the same, so that a single scheduling message is sent for multiple Recipients, within the limits of the IS:max- recipients (Section 9.2.1.10) value specified in the iSchedule Receiver's capabilities. For each group of Recipients handled by the same iSchedule Receiver, the iSchedule Sender will construct an HTTP request, as per Section 6, with the body of the HTTP request containing the iSchedule message. Note, in the case of a "VFREEBUSY" iSchedule message, the iSchedule Sender MUST ensure that iCalendar "ATTENDEE" properties in the iSchedule message match one-for-one with the Recipients listed in the HTTP request header. After constructing the HTTP request, the iSchedule Sender MUST generate a DKIM signature for the request and include a "DKIM- Signature" (Section 8.1) request header, as per Section 7. The iSchedule Sender then sends the HTTP request to the iSchedule Receiver handling the Recipient group, and receives the HTTP response, which will be an XML document with either an IS:schedule- response or IS:error element as the root element. The iSchedule Sender aggregates the results for each Recipient group receiving an iSchedule message, and returns the resulting status information for each Recipient to the Calendar Service that generated the schedule message. The process by which this is done is outside the scope of this document. 3.2. iSchedule Receiver Actions iSchedule Receivers MUST provide a capabilities document to Senders, as per Section 5. Daboo & Desruisseaux Expires November 3, 2013 [Page 9]
Internet-Draft iSchedule May 2013 Upon receipt of an iSchedule HTTP request, the iSchedule Receiver verifies the message as per Section 7.4. Once the authenticity of the message is confirmed, the iSchedule Receiver delivers the scheduling message to the indicated recipients, collects and aggregates the delivery status for each recipient, and returns the result in the HTTP response body. In the event of a processing error related to the overall request, iSchedule Receivers MUST return an error response as per Section 6.1.2. 4. iSchedule Receiver Discovery This section describes how an iSchedule Sender can discover the host name, port, and the path to use to submit an HTTP request to an iSchedule Receiver. For each Recipient to whom a scheduling message is being sent, the iSchedule Sender will "resolve" the associated calendar user address into a domain name, as per Section 4.1. The iSchedule Sender then uses the extracted domain name to issue a DNS SRV query for the iSchedule service (Section 4.2) expected to be hosted at the domain. The result of an SRV record lookup will be a target host name and a port, as per [RFC2782]. An iSchedule Sender uses these to contact the iSchedule Receiver. iSchedule Senders MUST honor the full behavior of SRV records, in particular the TTL, Priority and Weight options in the record, as well as handling multiple records being returned, as per [RFC2782]. Since an iSchedule Receiver is an HTTP server, an iSchedule Sender needs to supply a Request-URI in the HTTP request it makes to the iSchedule Receiver, in addition to the host name and port information. iSchedule Senders MUST use the path specified in any TXT records accompanying the SRV record (as per Section 4.3), or in the absence of a matching TXT record, MUST use the .well-known URI (as per Section 4.4). 4.1. Resolving Calendar User Addresses To deliver a scheduling message via the iSchedule protocol, an iSchedule Sender needs to determine which iSchedule Receiver to use for a particular recipient. Each recipient's calendar user address is specified in one or more Recipient request headers. Daboo & Desruisseaux Expires November 3, 2013 [Page 10]
Internet-Draft iSchedule May 2013 A calendar user address as defined by iCalendar is simply a URI. This is typically a mailto URI, but could potentially be any URI type. However, only URIs containing a "host" element can be used to extract the necessary information to locate an iSchedule Receiver. To get the SRV record name to query for a given mailto URI, the "domain" portion of the mailto URI is extracted and appended to the service label "_ischedules._tcp.". Example: Calendar User Address: mailto:cyrus@example.com Query SRV Record Name: _ischedules._tcp.example.com In cases where the "domain" portion of the mailto URI contains one or more levels of sub-domain, iSchedule Senders MAY choose to remove successive levels of "sub-domain" if queries for that sub-domain fail to return any SRV records. For example, a mailto URI with the full domain "host.calendar.example.com" would first trigger a query using the domain "host.calendar.example.com", then if that failed, the domain "calendar.example.com" would be tried, then if that failed the domain "example.com" would be tried. 4.2. iSchedule SRV Service Type This specification adds an SRV service label for use with iSchedule: ischedules: Identifies an iSchedule Receiver that uses HTTP with transport layer security ([RFC2818]). Example: service record for iSchedule Receiver with transport layer security _ischedules._tcp.example.com. IN SRV 0 1 443 ischedule.example.com. 4.3. iSchedule Service TXT Records When SRV RRs are used to advertise iSchedule services, it is also convenient to be able to specify a "context path" in the DNS to be retrieved at the same time. To enable that, this specification uses a TXT RR that follows the syntax defined in Section 6 of [RFC6763] and defines a "path" key for use in that record. The value of the key MUST be the actual "context path" to the corresponding service on the iSchedule Receiver. A site might provide TXT records in addition to SRV records for the service. When present, iSchedule Senders MUST use the "path" value Daboo & Desruisseaux Expires November 3, 2013 [Page 11]
Internet-Draft iSchedule May 2013 as the "context path" for the service in HTTP requests. When not present, iSchedule Senders use the ".well-known" URI approach described next. Example: text record for service with TLS _ischedules._tcp TXT path=/ischedule 4.4. iSchedule Receiver Request-URI This specification registers a well-known URI [RFC5785] for the iSchedule service, namely, "ischedule" (see Section 11.3.1). iSchedule Receivers MUST support requests targeted at this well-known URI. iSchedule Senders MUST handle HTTP redirects on this well-known URI. 5. iSchedule Receiver Capabilities iSchedule Receivers supporting the features described in this document MUST allow iSchedule Senders to query their capabilities by accepting GET requests targeted at the Request-URI found during discovery (Section 4). The response body for a successful GET request targeted at this URI MUST be an XML document with IS:query- result as its root element. Informative rationale: The GET method was favored over the POST method to allow iSchedule Senders to query capabilities with "conditional GET" requests (see Section 9.3 of [RFC2616]). iSchedule Receivers SHOULD use normal HTTP expiration mechanisms (as per Section 13.1.3 of [RFC2616]) to ensure caches do not cache the capabilities response for too long. iSchedule Senders SHOULD use normal HTTP conditional GET requests when re-checking capabilities to avoid re-transferring already cached data. iSchedule Senders SHOULD use the information in the capabilities to determine whether the iSchedule Receiver supports a version of the protocol that the iSchedule Sender can use, and if not, not issue any iSchedule requests with scheduling messages to the iSchedule Receiver. iSchedule Senders SHOULD verify that the scheduling message to be sent to the iSchedule Receiver is in line with the restrictions on scheduling messages indicated by the capabilities before sending the scheduling message. Daboo & Desruisseaux Expires November 3, 2013 [Page 12]
Internet-Draft iSchedule May 2013 5.1. Example: Querying iSchedule Receiver Capabilities >> Request << GET /.well-known/ischedule?action=capabilities HTTP/1.1 Host: cal.example.com >> Response << HTTP/1.1 200 OK Date: Mon, 15 Dec 2008 09:32:12 GMT Content-Type: application/xml; charset=utf-8 Content-Length: xxxx iSchedule-Version: 1.0 iSchedule-Capabilities: 123 ETag: "afasdf-132afds" <?xml version="1.0" encoding="utf-8" ?> <query-result xmlns="urn:ietf:params:xml:ns:ischedule"> <capabilities> <serial-number>123</serial-number> <versions> <version>1.0</version> </versions> <scheduling-messages> <component name="VEVENT"> <method name="REQUEST"/> <method name="ADD"/> <method name="REPLY"/> <method name="CANCEL"/> </component> <component name="VTODO"> <method name="REQUEST"/> <method name="ADD"/> <method name="REPLY"/> <method name="CANCEL"/> </component> <component name="VFREEBUSY"> <method name="REQUEST"/> </component> </scheduling-messages> <calendar-data-types> <calendar-data-type content-type="text/calendar" version="2.0"/> </calendar-data-types> <attachments> <inline/> <external/> Daboo & Desruisseaux Expires November 3, 2013 [Page 13]
Internet-Draft iSchedule May 2013 </attachments> <max-content-length>102400</max-content-length> <min-date-time>19910101T000000Z</min-date-time> <max-date-time>20381231T000000Z</max-date-time> <max-instances>150</max-instances> <max-recipients>250</max-recipients> <administrator>mailto:ischedule-admin@example.com< /administrator> </capabilities> </query-result> 6. Scheduling This section defines how an iSchedule Sender can use the HTTP POST method to submit a scheduling message to an iSchedule Receiver. Note, this describes the HTTP request prior to generating a DKIM signature as per Section 7. 6.1. POST Method The POST method submits a scheduling message to one or more Recipients by targeting the request at the Request-URI of an iSchedule Receiver. The request body of a POST method MUST contain a scheduling message (i.e., an iCalendar object that follows the iTIP semantic). The submitted scheduling message will be delivered to the Recipients, with status information about per-recipient delivery returned in the HTTP response. However, when the scheduling message is a request for free-busy time, the iSchedule Receiver will immediately execute the free-busy request for the Recipients and return per-recipient iCalendar data in the response for successful free-busy queries. Every POST request MUST include the "iSchedule-Version" (Section 11.2.2) general header. Every POST request SHOULD include the "iSchedule-Message-ID" (Section 11.2.4) request header. Every POST request MUST include the "Cache-Control" HTTP general header containing the cache-directives "no-cache" and "no-transform" to prevent intermediary caches from caching or transforming responses. Every POST request MUST include a single "Originator" (Section 11.2.5) request header that specifies the calendar user address of the Originator of the scheduling message. The value of the "Originator" request header MUST match the value of the Daboo & Desruisseaux Expires November 3, 2013 [Page 14]
Internet-Draft iSchedule May 2013 "ORGANIZER" iCalendar property or one of the specified "ATTENDEE" iCalendar properties in the scheduling message, depending on the specified "METHOD" iCalendar property value as summarized in the following table: +----------------+-----------------------------------+ | Method | Originator Requirement | +----------------+-----------------------------------+ | PUBLISH | MUST match ORGANIZER | | REQUEST | MUST match ORGANIZER (see Note 1) | | REPLY | MUST match ATTENDEE | | ADD | MUST match ORGANIZER | | CANCEL | MUST match ORGANIZER | | REFRESH | MUST match ATTENDEE | | COUNTER | MUST match ATTENDEE | | DECLINECOUNTER | MUST match ORGANIZER | +----------------+-----------------------------------+ Table 1 Note 1: iTIP does allow an Attendee to forward a "METHOD:REQUEST" scheduling message to another attendee. However, due to complexity of managing the authorization of such requests, this specification does not allow scheduling message forwarding. Every POST request MUST include one or more "Recipient" (Section 11.2.6) request headers. The value of this header is a list of one or more calendar user addresses and corresponds to the set of calendar users who will have the scheduling message delivered to them. The value of the "Recipient" request header MUST match the value of the "ORGANIZER" iCalendar property or one of the specified "ATTENDEE" iCalendar properties in the scheduling message, depending on the specified "METHOD" iCalendar property value as summarized in the following table: +----------------+----------------------------------+ | Method | Recipient Requirement | +----------------+----------------------------------+ | PUBLISH | None (see Note 1) | | REQUEST | MUST match ATTENDEE (see Note 1) | | REPLY | MUST match ORGANIZER | | ADD | MUST match ATTENDEE (see Note 1) | | CANCEL | MUST match ATTENDEE (see Note 1) | | REFRESH | MUST match ORGANIZER | | COUNTER | MUST match ORGANIZER | | DECLINECOUNTER | MUST match ATTENDEE | +----------------+----------------------------------+ Daboo & Desruisseaux Expires November 3, 2013 [Page 15]
Internet-Draft iSchedule May 2013 Table 2 Note 1: iTIP does allow an Organizer to send scheduling message to calendar users who are not listed as Attendees, e.g., to inform other calendar users of an event taking place. However, due to complexity of managing the authorization of such requests, this specification does not allow such scheduling messages. The Content-Type general header MUST include the type parameters "component" and "method" defined in [RFC5545]. The value of the "component" MUST correspond to the iCalendar component type (e.g., "VEVENT") specified in the scheduling message. The value of the "method" parameter MUST be the same as the value of the "METHOD" iCalendar property in the scheduling message. 6.1.1. Schedule Response A POST request may deliver a scheduling message to one or more calendar users specified in the Recipient request header. Since the behavior of each recipient may vary, it is useful to get response status information for each recipient in the overall POST response. This specification defines a new XML response to convey multiple recipient status. A response to a POST method that indicates status for one or more recipients MUST be an XML document with IS:schedule-response as its root element. This MUST contain one or more response elements for each recipient, with each of those containing elements that indicate which recipient they correspond to, the scheduling status of the request for that recipient, any error codes and an optional description. In the case of a free-busy request, the response elements can also contain calendar-data elements which contain free busy information (e.g., an iCalendar VFREEBUSY component) indicating the busy state of the corresponding recipient, assuming that the free-busy request for that recipient succeeded. Every POST response MUST include the "Cache-Control" HTTP general header containing the cache-directives "no-cache" and "no-transform" to prevent intermediary caches from caching or transforming responses. 6.1.2. Failed Schedule Response When there is an overall, as opposed to per-recipient, failure of the POST request, the iSchedule Receiver SHOULD return an XML document with IS:error as its root element. The child elements of the IS: Daboo & Desruisseaux Expires November 3, 2013 [Page 16]
Internet-Draft iSchedule May 2013 error element are used to indicate an error code and description, primarily meant for service administrators. The following XML elements are error codes which can be used within an IS:error element to represent errors: IS:version-not-supported: The POST request was either missing an "iSchedule-Version" header, or had an "iSchedule-Version" header value for a version not supported by the iSchedule Receiver, as advertised in the IS:versions capability. IS:invalid-calendar-data-type: The resource submitted in the POST request was not a supported media type (i.e. text/calendar) for scheduling or free-busy messages; IS:invalid-calendar-data: The resource submitted in the POST request was not valid data for the media type being specified; IS:invalid-scheduling-message: The resource submitted in the POST request did not obey all restrictions specified for the POST request, violating the IS:scheduling-message capability element, or the requirements of iTIP; IS:verification-failed: The POST request failed DKIM verification; IS:originator-missing: The POST request did not include an "Originator" request header specifying the calendar user address of the Originator of the scheduling message. IS:too-many-originators: The POST request contained more than one "Originator" request header. IS:originator-invalid: The "Originator" header in the POST request did not include a valid calendar user address for the Originator of the scheduling message. IS:originator-denied: The calendar user identified by the "Originator" header in the POST request is not allowed to use this service. IS:recipient-missing: The POST request did not include one or more valid "Recipient" request headers specifying the calendar user address of users to whom the scheduling message will be delivered. IS:recipient-mismatch: The POST request did not include "Recipient" request header values which exactly match the list of "ATTENDEE" property values in a "VFREEBUSY" request. Daboo & Desruisseaux Expires November 3, 2013 [Page 17]
Internet-Draft iSchedule May 2013 IS:max-recipients: The POST request had too many calendar user addresses specified in "Recipient" request headers, violating the IS:max-recipients capability. IS:attachment-type-not-supported: The scheduling message submitted in the POST request had iCalendar data with "ATTACH" properties whose value type is not supported, violating the IS:attachments capability. IS:max-content-length: The scheduling message submitted in the POST request had iCalendar data violating the IS:max-content- length capability. IS:min-date-time: The scheduling message submitted in the POST request had iCalendar data violating the IS:min-date-time capability. IS:max-date-time: The scheduling message submitted in the POST request had iCalendar data violating the IS:max-date-time capability. IS:max-instances: The scheduling message submitted in the POST request had iCalendar data violating the IS:max-instances capability. The following are examples of response codes one would expect to be used for this method. Note, however, that unless explicitly prohibited any 2/3/4/5xx series response code may be used in a response. Typically a 403 response code would be used when an XML document with an IS:error element as its root is also returned. 200 (OK) - The command succeeded. 400 (Bad Request) - The Sender has provided an invalid scheduling message, or invalid iSchedule request headers. 403 (Forbidden) - The Sender cannot submit a scheduling message to the specified Request-URI. 404 (Not Found) - The URL in the Request-URI was not present. 507 (Insufficient Storage) - The server did not have sufficient space to record the scheduling message. Daboo & Desruisseaux Expires November 3, 2013 [Page 18]
Internet-Draft iSchedule May 2013 7. iSchedule Domain-Level Authentication iSchedule uses and extends the mechanism defined by DomainKeys Identified Mail (DKIM) [RFC6376]. DKIM defines a domain-level digital signature authentication framework for email, using public- key cryptography, with the domain name service (DNS) as one possible key server technology. This specification extends the applicability of DKIM to the HTTP protocol, with a specific "profile" for use with iSchedule messages. Additionally, DKIM support is REQUIRED for all iSchedule requests, and iSchedule Receivers MUST reject any messages which cannot be verified according to the requirements of DKIM. This is a much stronger requirement than the email use of DKIM, which has to deal with legacy systems. iSchedule Senders MUST only send iSchedule messages for Originators whose authenticity they have verified. iSchedule Receivers that verify a DKIM signature on an iSchedule request can assume that the iSchedule Sender is not only taking responsibility for sending the message, but has also verified the authenticity of the Originator. As such, iSchedule Receivers can reliably use the Originator information to perform their own authorization based on that value. e.g., the Calendar Service to which an iSchedule Receiver delivers a scheduling message, can apply "filtering" rules to such messages based on the guarantee that the Originator calendar user address has been verified at both the iSchedule Sender and Receiver ends. This specification uses the syntactic elements of DKIM [RFC6376], but modified for use with HTTP. Where definitions of syntactic elements of DKIM [RFC6376] are applicable to HTTP, they will be used by reference. In cases where the HTTP definition is different, the same ABNF rule name will be used, but the value modified as appropriate. The following sections describe how the DomainKeys Identified Mail (DKIM) service can fit into a scheduling service. 7.1. Signature Content The following HTTP headers MUST be included in the signature of a message: o Content-Type o iSchedule-Version o Originator Daboo & Desruisseaux Expires November 3, 2013 [Page 19]
Internet-Draft iSchedule May 2013 o Recipient The iSchedule Receiver MUST verify that the above HTTP headers are included in the signature. iSchedule Senders and Receivers might use HTTP authentication [RFC2617] in requests, though the process through which credentials are managed are out of scope for this document. If HTTP authentication is used, then the "Authorization" HTTP request header MUST be included in the signature of the message. The following HTTP headers, if present, SHOULD be included in the signature of a message: o iSchedule-Message-ID o User-Agent To allow iSchedule messages to transit via HTTP intermediaries, hop- by-hop headers, such as the following HTTP/1.1 headers MUST NOT be included in the signature of a message: o Cache-Control o Connection o Host o Keep-Alive o Proxy-Authenticate o Proxy-Authorization o TE o Trailer o Transfer-Encoding o Upgrade The "Content-Length" header MUST NOT be signed, since the DKIM signature is generated prior to transfer encoding, and the header value represents the length after any transfer encodings have been applied. iSchedule Senders MAY include an "x=" DKIM signature tag in the Daboo & Desruisseaux Expires November 3, 2013 [Page 20]
Internet-Draft iSchedule May 2013 "DKIM-Signature" header to indicate an expiration time for the signature. When doing so, the "x=" value SHOULD be set to at least 1 minute ahead of the "t=" DKIM signature tag value, to account for processing time between the iSchedule Sender and Receiver. 7.2. Canonicalization iSchedule Senders and Receivers MUST use the "simple" body canonicalization algorithm defined in Section 3.4.3 of DKIM [RFC6376] to canonicalize the HTTP request message body used for the body hash computation. The iSchedule Sender MUST calculate the body hash prior to any HTTP transfer encodings being applied to the request message body. The iSchedule Receiver MUST calculate the body hash after any HTTP transfer encoding have been removed from the request message body. iSchedule Senders and Receivers MUST use the new "ischedule-relaxed" header canonicalization algorithm defined below to canonicalize the HTTP request headers used for the signature computation. 7.2.1. The "ischedule-relaxed" Header Canonicalization Algorithm The "ischedule-relaxed" header canonicalization algorithm is used to canonicalize HTTP header fields where multiple headers fields with the same name might be combined by an HTTP intermediary. The following steps MUST be applied in order: 1. Convert all header field names (not the header field values) to lowercase. For example, convert "SUBJect: AbC" to "subject: AbC". 2. Unfold all header field continuation lines; in particular, lines with terminators embedded in continued header field values (that is, CRLF sequences followed by LWS) MUST be interpreted without the CRLF. Implementations MUST NOT remove the CRLF at the end of the header field value. 3. Combine multiple header fields with the same field name into one one header field value; specifically, append each subsequent field value to the combined field value in order, separated by a comma. For example, combine "recipient:mailto:cyrus@example.com,mailto:mike@example.com" and "recipient:mailto:ken@example.org" into "recipient:mailto:cyrus@ example.com,mailto:mike@example.com,mailto:ken@example.org" 4. Convert all sequences of one or more LWS characters to a single SP character. LWS characters here include those before and after a line folding boundary. Daboo & Desruisseaux Expires November 3, 2013 [Page 21]
Internet-Draft iSchedule May 2013 5. Delete all WS characters at the end of each unfolded header field value. 6. Delete any LWS characters remaining before and after the colon separating the header field name from the header field value. The colon separator MUST be retained. 7. Delete any LWS characters remaining before and after any commas in the header field value. Since this canonicalization algorithm "collapses" multiple HTTP header fields into a single header field, the h= tag used in the "DKIM-Signature" request header MUST contain only a single value for each different header field name being signed. 7.3. Key Management 7.3.1. DNS-based Public Key Management Section 3.6.2 of DKIM [RFC6376] defines a DNS-based key-binding for public key retrieval. iSchedule Senders and Receivers MUST support this method of public key retrieval. To allow public keys to be restricted to just an iSchedule service, this specification defines a new service type "ischedule" to constrain the use of a key to iSchedule: ABNF: key-s-tag-type /= "ischedule" 7.3.2. HTTP-based Public Key Management This specification defines a new HTTP-based public key management method for use with DKIM [RFC6376]. The "DKIM-Signature" header "q" tag value associated with this method is "http/well-known": ABNF: sig-q-tag-method /= "http/well-known" Key lookup first involves retrieving an SRV record that will provide the HTTP server host name and port to use for actual key retrieval. Then the key retrieval is done via an HTTP GET request on a .well- known resource. This new key management approach off-loads the key Daboo & Desruisseaux Expires November 3, 2013 [Page 22]
Internet-Draft iSchedule May 2013 handling from DNS to an HTTP server, only requiring the DNS administrator to provide the SRV records for authorized HTTP key management servers. 7.3.2.1. SRV Service Type This specification adds one SRV service label for use with HTTP key management: domainkey_lookup: Identifies an HTTP server from which public keys for DKIM signatures can be retrieved. The HTTP server MUST support transport layer security ([RFC2818]). The iSchedule Receiver determines the appropriate SRV name using the "d=" DKIM signature tag value in the "DKIM-signature" header being verified: _domainkey_lookup._tcp.{d}. ; {d} is the d= value from the "DKIM-Signature" header. 7.3.2.2. Well-known Request-URI This specification registers a well-known URI [RFC5785] for the DKIM HTTP-based public key management information, "domainkey" (see Section 11.3.2). To retrieve information about the public key used to sign an iSchedule message, the iSchedule Sender constructs a URI of the form: https://{srv-host}:{srv-port}/.well-known/domainkey/{d}/{s} ; {srv-host} is the host name from the _domainkey_lookup SRV record ; {srv-port} is the port number from the _domainkey_lookup SRV record ; {d} is the d= value from the "DKIM-Signature" header. ; {s} is the s= value from the "DKIM-Signature" header. Documents retrieved from the well-known URI MUST be text documents with a media-type of "text/plain". The format of the text document is: key-doc = 1*(tag-list CRLF) ; tag-list is defined in Section 3.2 of <xref target="RFC6376"/> where tag-list is the unstructured textual form defined in Section 3.6.1. of [RFC6376] - i.e., the same data that would be placed in a DNS TXT record for DNS-based public key management. Note that this allows information for multiple keys to be returned for each {domain- name}, {selector} pair. iSchedule Receivers must use HTTP+TLS Daboo & Desruisseaux Expires November 3, 2013 [Page 23]
Internet-Draft iSchedule May 2013 (https:) to retrieve the public key information document, and follow the certificate-verification process specified in [RFC6125]. 7.3.2.3. Example Lookup Procedure Given the following (partial) DKIM-Signature header, the steps below describe how a public key is retrieved from the HTTP pubic key management system. DKIM-Signature:q=http/well-known;d=cal.example.com;s=isched; ... 1. The iSchedule Receiver first does an SRV record lookup for "_domainkey_lookup._tcp.cal.example.com", and gets back the following example record: _domainkey_lookup._tcp.cal.example.com. IN SRV 0 1 443 is.example.com. 2. the iSchedule Receiver then makes an HTTP request: https://is.example.com:443/.well-known/domainkey/cal.example.com/isched 3. It parses the returned document to determine the appropriate public key to use to verify the DKIM signature. 7.3.3. Private Exchange Public Key Management This specification defines a new public key management method for use with DKIM [RFC6376]. This method is used to indicate that the associated public key has been transferred to the recipient through some (unspecified, secure) private exchange. The "DKIM-Signature" header "q" tag value associated with this method is "private- exchange": ABNF: sig-q-tag-method /= "private-exchange" This method is useful, for example, in situations where an "internal" deployment of iSchedule is being used to connect different calendar systems within an organization. It avoids the need to setup other public key discovery mechanisms when a simple, secure public key exchange can be accomplished between the system administrators. Daboo & Desruisseaux Expires November 3, 2013 [Page 24]
Internet-Draft iSchedule May 2013 7.4. Verification Requirements iSchedule Receivers MUST verify the follow details: The HTTP request contains an "iSchedule-Version" header that matches a version of the iSchedule protocol that the iSchedule Receiver supports. Only one Originator HTTP request header is present in the request and it matches the appropriate iCalendar property as per Table 1. One or more Recipient HTTP request headers are present in the request and they match the appropriate iCalendar properties as per Table 2. The "DKIM-Signature" header contains valid information and the signature and body hash values can be verified correctly. Note, for the t= value in the "DKIM-Signature", iSchedule Receivers SHOULD accept values that are no more than 5 minutes in the future, to account for possible clock skew between iSchedule Sender and Receiver. If the signature cannot be verified, the iSchedule Receiver MUST reject the iSchedule message outright. If the signature is valid, then iSchedule Receivers have a guarantee that the iSchedule Sender has verified the authenticity of the Originator and determined they are authorized to send the enclosed iTIP message. This allows iSchedule Receivers to use the Originator calendar user address value for access control purposes. 7.5. Authorized Third-Party Signatures The third-party signature authorization protocol defined in [RFC6541] MAY be used by iSchedule Senders and Receivers. 8. HTTP Headers This section defines the syntax and semantics of additional HTTP/1.1 header fields. The header's syntax uses the optional whitespace (OWS) rule defined as follows: OWS = *( [ CRLF ] WSP ) Daboo & Desruisseaux Expires November 3, 2013 [Page 25]
Internet-Draft iSchedule May 2013 8.1. DKIM-Signature Request Header The "DKIM-Signature" request header MUST be specified by the iSchedule Sender on all scheduling requests to specify all of the signature and key-fetching data. DKIM-Signature = "DKIM-Signature" ":" OWS DKIM-Signature-v DKIM-Signature-v = tag-list ; tag-list is defined in Section 3.2 of <xref target="RFC6376"/> 8.2. iSchedule-Version General Header The "iSchedule-Version" general header field MUST be specified by the iSchedule Sender on requests, and by the iSchedule Receiver on responses. It SHOULD be included in a response to any "OPTIONS *" HTTP request targeting the iSchedule Receiver, or any "OPTIONS" request on a resource supporting the iSchedule behaviors described in this specification (e.g., the .well-known resource or any resource that .well-known redirects to). iSchedule-Version = "iSchedule-Version" ":" OWS iSchedule-Version-v iSchedule-Version-v = iSchedule-Version-elem *( OWS "," OWS iSchedule-Version-elem ) iSchedule-Version-elem = 1*DIGIT "." 1*DIGIT 8.3. iSchedule-Capabilities Response Header The "iSchedule-Capabilities" response header field MUST be specified by the iSchedule Receiver on all responses. iSchedule Senders SHOULD cache this value and use it to detect a change in the iSchedule Receiver capabilities that cause the iSchedule Sender to reload capabilities. The value of this header is maintained by the iSchedule Receiver as described in Section 9.2.1.1. iSchedule-Capabilities = "iSchedule-Capabilities" ":" OWS 1*DIGIT 8.4. iSchedule-Message-ID Request Header The "iSchedule-Message-ID" request header field SHOULD be specified by the iSchedule Sender on requests. This header provides a unique identifier that refers to the specific iSchedule request in which it is included. The uniqueness of this identifier is guaranteed by the iSchedule Sender that generates it. This identifier is intended to be machine readable and not necessarily meaningful to humans. iSchedule-Message-ID = "iSchedule-Message-ID" ":" OWS token Daboo & Desruisseaux Expires November 3, 2013 [Page 26]
Internet-Draft iSchedule May 2013 8.5. Originator Request Header The "Originator" request header value is a URI which specifies the calendar user address of the originator of the scheduling message. Note that the absoluteURI rule is defined in [RFC3986]. Originator = "Originator" ":" OWS Originator-v Originator-v = absoluteURI 8.6. Recipient Request Header The "Recipient" request header value is a URI which specifies the calendar user address of the recipients to which the POST method should deliver the submitted scheduling message. Note that the absoluteURI rule is defined in [RFC3986]. Recipient = "Recipient" ":" OWS Recipient-v Recipient-v = Recipient-elem *( OWS "," OWS Recipient-elem ) Recipient-elem = absoluteURI 9. XML Element Definitions 9.1. schedule-response XML Element Name: schedule-response Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Contains the set of responses for a POST method request. Description: See Section 6.1.1. Definition: <!ELEMENT schedule-response (response*)> 9.1.1. response XML Element Name: response Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Contains a single response for a POST method request. Description: See Section 6.1.1. Daboo & Desruisseaux Expires November 3, 2013 [Page 27]
Internet-Draft iSchedule May 2013 Definition: <!ELEMENT response (recipient, request-status, calendar-data?, error?, response-description?)> 9.1.1.1. recipient XML Element Name: recipient Namespace: urn:ietf:params:xml:ns:ischedule Purpose: The calendar user address (recipient header value) that the enclosing response for a POST method request is for. Description: See Section 6.1.1. Definition: <!ELEMENT recipient (#PCDATA)> 9.1.1.2. request-status XML Element Name: request-status Namespace: urn:ietf:params:xml:ns:ischedule Purpose: The iTIP REQUEST-STATUS property value for this response. Description: See Section 6.1.1. Definition: <!ELEMENT request-status (#PCDATA)> 9.1.1.3. calendar-data XML Element Name: calendar-data Namespace: urn:ietf:params:xml:ns:ischedule Purpose: An iCalendar object in a response to a search for busy time information. Daboo & Desruisseaux Expires November 3, 2013 [Page 28]
Internet-Draft iSchedule May 2013 Description: See Section 6.1.1. Definition: <!ELEMENT calendar-data (#PCDATA)> 9.1.1.4. error XML Element Name: error Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Error responses sometimes need more information to indicate what went wrong. Description: See Section 6.1.1. Definition: <!ELEMENT error ANY> 9.1.1.5. response-description XML Element Name: response-description Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Contains information about a status response Description: See Section 6.1.1. Definition: <!ELEMENT response-description (#PCDATA)> 9.2. query-result XML Element Name: query-result Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Contains result of a query request. Description: A generic container for the result of a query request, such as a query of the capabilities of an iSchedule Receiver. Daboo & Desruisseaux Expires November 3, 2013 [Page 29]
Internet-Draft iSchedule May 2013 Definition: <!ELEMENT query-result (capabilities)> 9.2.1. capabilities XML Element Name: capabilities Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Contains iSchedule Receiver capabilities. Description: The capabilities element contains capabilities of the iSchedule Receiver. Definition: <!ELEMENT capabilities ( serial-number, versions, scheduling-messages, calendar-data-types, attachments, max-content-length, min-date-time, max-date-time, max-instances, max-recipients, administrator) > 9.2.1.1. serial-number XML Element Name: serial-number Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Identifies the version of the capabilities information. Description: This is a numeric value maintained by the iSchedule Receiver. The value is incremented by the iSchedule Receiver each time there has been a substantive change to the capabilities that would require an iSchedule Sender to reload the capabilities to adjust its behavior. The value of this element MUST be returned by the iSchedule Receiver in all HTTP requests via the "iSchedule- Capabilities" response header (Section 8.3). This allows iSchedule Senders to detect changes to the iSchedule Receiver's capabilities during the normal course of making requests, without the need to poll the iSchedule Receiver for such changes. Daboo & Desruisseaux Expires November 3, 2013 [Page 30]
Internet-Draft iSchedule May 2013 Definition: <!ELEMENT serial-number (#PCDATA)> <!-- PCDATA value: a numeric value (positive integer) --> 9.2.1.2. versions XML Element Name: versions Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Identifies the iSchedule versions supported by the iSchedule Receiver. Description: An iSchedule Receiver MAY advertise support for multiple versions of the iSchedule protocol. iSchedule Senders check this value to ensure they can send iSchedule messages with a matching version. Definition: <!ELEMENT versions (version)+> 9.2.1.2.1. version XML Element Name: version Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Identifies an iSchedule protocol version. Definition: <!ELEMENT version (#PCDATA)> <!-- PCDATA value: version number --> 9.2.1.3. scheduling-messages XML Element Name: scheduling-messages Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Identifies the type of supported scheduling messages. Description: An iSchedule Receiver advertises which iCalendar component types it will accept for iTIP messages sent to it. In addition, for each component, it can specify the allowed iTIP "METHOD" property values. Daboo & Desruisseaux Expires November 3, 2013 [Page 31]
Internet-Draft iSchedule May 2013 Definition: <!ELEMENT scheduling-messages (component)+> 9.2.1.3.1. component XML Element Name: component Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Identifies a calendar component type. Description: Used to specify a supported iCalendar component type for scheduling messages. If a IS:method child element is not present, then any iTIP "METHOD" property value can be used in iTIP messages sent to the iSchedule Receiver. If one or more IS:method elements are present, then those indicate the allowed set of iTIP "METHOD" property values. Definition: <!ELEMENT component (method)*> <!ATTLIST component name CDATA #REQUIRED> <!-- name value: a calendar component name --> 9.2.1.3.1.1. method XML Element Name: method Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Identifies an iCalendar method type. Description: See IS:component. Definition: <!ELEMENT method EMPTY> <!ATTLIST method name CDATA #REQUIRED> <!-- name value: a method type --> 9.2.1.4. calendar-data-types XML Element Daboo & Desruisseaux Expires November 3, 2013 [Page 32]
Internet-Draft iSchedule May 2013 Name: calendar-data-types Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Identifies what formats of iCalendar data are acceptable. Definition: <!ELEMENT calendar-data-types (calendar-data-type)+> 9.2.1.4.1. calendar-data-type XML Element Name: calendar-data-type Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Identifies a supported media type and version for iTIP messages. Definition: <!ELEMENT calendar-data-type EMPTY> <!ATTLIST calendar-data-type content-type CDATA "text/calendar" version CDATA "2.0"> <!-- content-type value: a MIME media type --> <!-- version value: a version string --> 9.2.1.5. attachments XML Element Name: attachments Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Identifies the attachment values supported. Description: iSchedule Receivers might restrict what form of attachments are allowed in iTIP messages that are sent to it, for performance, or security reasons. In iCalendar data, attachments can either be specified using "inline" data in the form of a base64 encoded property value, or "external" data in the form of a URI property value. With this capability, an iSchedule Receiver can specify which of "inline" or "external" values it will accept in iTIP messages. See Section 10.4 for additional details. Daboo & Desruisseaux Expires November 3, 2013 [Page 33]
Internet-Draft iSchedule May 2013 Definition: <!ELEMENT attachments (inline?, external?)> 9.2.1.5.1. inline XML Element Name: inline Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Identifies "inline" attachments as a supported attachment value. Definition: <!ELEMENT inline EMPTY> 9.2.1.5.2. external XML Element Name: external Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Identifies "external" attachments as a supported attachment value. Definition: <!ELEMENT external EMPTY> 9.2.1.6. max-content-length XML Element Name: max-content-length Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Identifies the maximum size allowed for a scheduling message in octets. Definition: <!ELEMENT max-content-length (#PCDATA)> <!-- PCDATA value: a numeric value (positive integer) --> Daboo & Desruisseaux Expires November 3, 2013 [Page 34]
Internet-Draft iSchedule May 2013 9.2.1.7. min-date-time XML Element Name: min-date-time Namespace: urn:ietf:params:xml:ns:ischedule Purpose: A DATE-TIME value indicating the earliest date and time in UTC that the iSchedule Receiver is willing to accept for any DATE or DATE-TIME value in a scheduling message. Definition: <!ELEMENT min-date-time (#PCDATA)> <!-- PCDATA value: an iCalendar format DATE-TIME value in UTC --> 9.2.1.8. max-date-time XML Element Name: max-date-time Namespace: urn:ietf:params:xml:ns:ischedule Purpose: A DATE-TIME value indicating the latest date and time in UTC that the iSchedule Receiver is willing to accept for any DATE or DATE-TIME value in a scheduling message. Definition: <!ELEMENT max-date-time (#PCDATA)> <!-- PCDATA value: an iCalendar format DATE-TIME value in UTC --> 9.2.1.9. max-instances XML Element Name: max-instances Namespace: urn:ietf:params:xml:ns:ischedule Purpose: The maximum number of recurrence instances allowed in a scheduling message. Definition: <!ELEMENT max-instances (#PCDATA)> <!-- PCDATA value: a numeric value (positive integer) --> Daboo & Desruisseaux Expires November 3, 2013 [Page 35]
Internet-Draft iSchedule May 2013 9.2.1.10. max-recipients XML Element Name: max-recipients Namespace: urn:ietf:params:xml:ns:ischedule Purpose: The maximum number of recipients allowed for a scheduling message. Definition: <!ELEMENT max-recipients (#PCDATA)> <!-- PCDATA value: a numeric value (positive integer) --> 9.2.1.11. administrator XML Element Name: administrator Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Provides contact information for the administrator of the iSchedule Receiver. Definition: <!ELEMENT administrator (#PCDATA)> <!-- PCDATA value: URI to contact administrator --> 10. Security Considerations The process of scheduling involves the sending and receiving of scheduling messages. As a result, the security problems related to messaging in general are relevant here. In particular the authenticity of the scheduling messages needs to be verified. Potential attacks described in the security considerations of DKIM [RFC6376] are also applicable to iSchedule. 10.1. Privacy iSchedule Senders and iSchedule Receivers MUST use an HTTP connection protected with TLS [RFC5246] as defined in [RFC2818] for all transactions. 10.2. Authentication iSchedule uses and extends the mechanism defined by DomainKeys Identified Mail (DKIM) [RFC6376]. DKIM defines a domain-level Daboo & Desruisseaux Expires November 3, 2013 [Page 36]
Internet-Draft iSchedule May 2013 digital signature authentication framework for email, using public- key cryptography, with the domain name service as its key server technology. 10.3. DNS Considerations DNS security issues are addressed by DNSSEC [RFC4033]. 10.4. Attachment Considerations iCalendar data can include "inline" attachment data in the form of a base64-encoded "ATTACH" property value. iSchedule Receivers MUST take care when allowing "inline" attachments in scheduling messages as such data might contain malicious content, and SHOULD use some form of content scanner on the attachment data to verify its safety (e.g., a content scanner used for email messages). In addition, "inline" attachment data is likely to be much larger than the actual calendar- related data in a scheduling message, and thus could adversely affect the performance of an iSchedule Receiver processing it. If an iSchedule Receiver allows "inline" attachment data, it MUST apply a limit on the size of acceptable scheduling messages to prevent possible denial-of-service attacks using large "inline" attachment data. In general, it is best for iSchedule Receivers to simply disable the ability for scheduling messages to contain "inline" attachment data, and instead rely solely on "external" attachments in the form of URI attachment values. 11. IANA Considerations 11.1. Namespace Registration This specification registers a new URN to identify a new XML namespace as per [RFC3688]. 11.1.1. iSchedule Namespace Registration Registration request for the iSchedule namespace: URI: urn:ietf:params:xml:ns:ischedule Registrant Contact: See the "Authors' Addresses" section of this document. XML: None. Namespace URIs do not represent an XML specification. Daboo & Desruisseaux Expires November 3, 2013 [Page 37]
Internet-Draft iSchedule May 2013 11.2. HTTP Headers Registration This specification registers new headers for use with HTTP as per [RFC3864]. 11.2.1. DKIM-Signature Request Header Registration Header field name: DKIM-Signature Applicable protocol: http Status: standard Author/Change controller: IETF Specification document(s): this specification Related information: none 11.2.2. iSchedule-Version General Header Registration Header field name: iSchedule-Version Applicable protocol: http Status: standard Author/Change controller: IETF Specification document(s): this specification Related information: none 11.2.3. iSchedule-Capabilities Response Header Registration Header field name: iSchedule-Capabilities Applicable protocol: http Status: standard Author/Change controller: IETF Specification document(s): this specification Related information: none Daboo & Desruisseaux Expires November 3, 2013 [Page 38]
Internet-Draft iSchedule May 2013 11.2.4. iSchedule-Message-ID Request Header Registration Header field name: iSchedule-Message-ID Applicable protocol: http Status: standard Author/Change controller: IETF Specification document(s): this specification Related information: none 11.2.5. Originator Request Header Registration Header field name: Originator Applicable protocol: http Status: standard Author/Change controller: IETF Specification document(s): this specification Related information: none 11.2.6. Recipient Request Header Registration Header field name: Recipient Applicable protocol: http Status: standard Author/Change controller: IETF Specification document(s): this specification Related information: none 11.3. Well-Known URI Registration This specification registers a new well-known URI as per [RFC5785]. Daboo & Desruisseaux Expires November 3, 2013 [Page 39]
Internet-Draft iSchedule May 2013 11.3.1. iSchedule Well-Known URI Registration URI suffix: ischedule Change controller: IETF. Specification document(s): this specification Related information: none 11.3.2. DKIM Well-Known URI Registration URI suffix: domainkey Change controller: IETF. Specification document(s): this specification Related information: none 11.4. DKIM Parameters Registration 11.4.1. DKIM-Signature Query Method Registry This specification registers two new query mechanisms that can be used in DKIM-Signature fields. The following values should be added to the DKIM-Signature Query Method Registry established in Section 7.3 of [RFC6376]: +------------------+------------+--------------------------+--------+ | Type | Option | Reference | Status | +------------------+------------+--------------------------+--------+ | http | well-known | (this document | active | | | | Section 7.3.2) | | | private-exchange | | (this document | active | | | | Section 7.3.3) | | +------------------+------------+--------------------------+--------+ 11.4.2. DKIM Service Type Registration This specification registers a new DKIM service type to specify that a given public key MUST only be used to verify messages of iSchedule services. The following value should be added to the DKIM Service Type Registry established in Section 7.8 of [RFC6376]: Daboo & Desruisseaux Expires November 3, 2013 [Page 40]
Internet-Draft iSchedule May 2013 +-----------+-------------------------------+--------+ | Type | Reference | Status | +-----------+-------------------------------+--------+ | ischedule | (this document Section 7.3.1) | active | +-----------+-------------------------------+--------+ 12. Acknowledgments The authors would like to thank the following individuals for contributing their ideas and support for writing this specification: Mattias Amnefelt, Mike Douglass, Tomas Hnetila, Ciny Joy, Barry Leiba, Ken Murchison, Simon Pilette, Arnaud Quillaud, Simon Vaillancourt, and Wilfredo Sanchez Vega. The authors would also like to thank CalConnect, The Calendaring and Scheduling Consortium, for advice with this specification, and for organizing interoperability testing events to help refine it. 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners- Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC3986] Berners-Lee, T., Fielding, R., and L. Daboo & Desruisseaux Expires November 3, 2013 [Page 41]
Internet-Draft iSchedule May 2013 Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, September 2009. [RFC5546] Daboo, C., "iCalendar Transport-Independent Interoperability Protocol (iTIP)", RFC 5546, December 2009. [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010. [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain- Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011. [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011. [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013. [W3C.REC-xml-20081126] Yergeau, F., Paoli, J., Sperberg-McQueen, C., Maler, E., and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml- 20081126, November 2008, Daboo & Desruisseaux Expires November 3, 2013 [Page 42]
Internet-Draft iSchedule May 2013 <http://www.w3.org/TR/2008/REC-xml-20081126>. 13.2. Informative References [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004. [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, March 2007. [RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys Identified Mail (DKIM) Service Overview", RFC 5585, July 2009. [RFC6047] Melnikov, A., "iCalendar Message-Based Interoperability Protocol (iMIP)", RFC 6047, December 2010. [RFC6541] Kucherawy, M., "DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures", RFC 6541, February 2012. [RFC6638] Daboo, C. and B. Desruisseaux, "Scheduling Extensions to CalDAV", RFC 6638, June 2012. Appendix A. Example Scheduling Transactions This section describes some example scheduling transactions that give a general idea of how scheduling is carried out between an iSchedule Sender and an iSchedule Receiver. A.1. Example: Simple Meeting Invitation In the following example, the iSchedule Sender requests the iSchedule Receiver to deliver a meeting invitation (scheduling REQUEST) to the calendar user mailto:cyrus@example.org. The response indicates that delivery of the scheduling message was successful. Daboo & Desruisseaux Expires November 3, 2013 [Page 43]
Internet-Draft iSchedule May 2013 >> Request << POST /.well-known/ischedule HTTP/1.1 DKIM-Signature: a=rsa-sha256; d=example.com; s=jupiter; c=ischedule-relaxed/simple; q=dns/txt:http/well-known; t=1268069852; x=1283918400; h=Originator:Recipient:Content-Type: iSchedule-Version:iSchedule-Message-ID; bh=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx; b=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx Host: cal.example.org iSchedule-Version: 1.0 iSchedule-Message-ID: 798F00BB-5B45-4634-B083-0D0CD3A2BB39 Originator: mailto:bernard@example.com Recipient: mailto:cyrus@example.org Cache-Control: no-cache, no-transform Content-Type: text/calendar; component=VEVENT; method=REQUEST Content-Length: xxxx BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//EN METHOD:REQUEST BEGIN:VEVENT DTSTAMP:20040901T200200Z ORGANIZER:mailto:bernard@example.com DTSTART:20040902T130000Z DTEND:20040902T140000Z SUMMARY:Design meeting UID:34222-232@example.com ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR;CUTYPE=IND IVIDUAL;CN=Bernard Desruisseaux:mailto:bernard@ example.com ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Cyrus Daboo: mailto:cyrus@example.org END:VEVENT END:VCALENDAR Daboo & Desruisseaux Expires November 3, 2013 [Page 44]
Internet-Draft iSchedule May 2013 >> Response << HTTP/1.1 200 OK Date: Thu, 02 Sep 2004 16:53:32 GMT Content-Type: application/xml; charset=utf-8 Content-Length: xxxx Cache-Control: no-cache, no-transform iSchedule-Version: 1.0 iSchedule-Capabilities: 123 <?xml version="1.0" encoding="utf-8" ?> <schedule-response xmlns="urn:ietf:params:xml:ns:ischedule"> <response> <recipient>mailto:cyrus@example.org</recipient> <request-status>2.0;Success</request-status> <response-description>Delivered to recipient< /response-description> </response> </schedule-response> A.2. Example: Search for Busy Time Information In the following example, the iSchedule Sender requests the iSchedule Receiver to determine the busy information of the calendar users mailto:cyrus@example.org and mailto:mike@example.org, over the time range specified by the scheduling message sent in the request. The response includes VFREEBUSY components with the busy time for one calendar user, and an error for the other calendar user. Daboo & Desruisseaux Expires November 3, 2013 [Page 45]
Internet-Draft iSchedule May 2013 >> Request << POST /.well-known/ischedule HTTP/1.1 DKIM-Signature: a=rsa-sha256; d=example.com; s=jupiter; c=ischedule-relaxed/simple; q=dns/txt:http/well-known; t=1268069852; x=1283918400; h=Originator:Recipient:Content-Type: iSchedule-Version:iSchedule-Message-ID; bh=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx; b=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx Host: cal.example.org iSchedule-Version: 1.0 iSchedule-Message-ID: A98ADF24-9490-4F01-81C8-FE924F86A9FD Originator: mailto:bernard@example.com Recipient: mailto:cyrus@example.org Recipient: mailto:mike@example.org Cache-Control: no-cache, no-transform Content-Type: text/calendar; component=VFREEBUSY; method=REQUEST Content-Length: xxxx BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//EN METHOD:REQUEST BEGIN:VFREEBUSY DTSTAMP:20040901T200200Z ORGANIZER:mailto:bernard@example.com DTSTART:20040902T000000Z DTEND:20040903T000000Z UID:34222-232@example.com ATTENDEE;CN=Cyrus Daboo:mailto:cyrus@example.org ATTENDEE;CN=Mike Douglass:mailto:mike@example.org END:VFREEBUSY END:VCALENDAR Daboo & Desruisseaux Expires November 3, 2013 [Page 46]
Internet-Draft iSchedule May 2013 >> Response << HTTP/1.1 200 OK Date: Thu, 02 Sep 2004 16:53:32 GMT Content-Type: application/xml; charset=utf-8 Content-Length: xxxx Cache-Control: no-cache, no-transform iSchedule-Version: 1.0 iSchedule-Capabilities: 123 <?xml version="1.0" encoding="utf-8" ?> <schedule-response xmlns="urn:ietf:params:xml:ns:ischedule"> <response> <recipient>mailto:cyrus@example.org</recipient> <request-status>2.0;Success</request-status> <calendar-data>BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//EN METHOD:REPLY BEGIN:VFREEBUSY DTSTAMP:20040901T200200Z ORGANIZER:mailto:bernard@example.com DTSTART:20040902T000000Z DTEND:20040903T000000Z UID:34222-232@example.com ATTENDEE;CN=Cyrus Daboo:mailto:cyrus@example.org FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:20040902T000000Z/ 20040902T090000Z,20040902T170000Z/20040903T000000Z FREEBUSY;FBTYPE=BUSY:20040902T120000Z/20040902T130000Z END:VFREEBUSY END:VCALENDAR </calendar-data> </response> <response> <recipient>mailto:mike@example.org</recipient> <request-status>5.3;No scheduling support for user< /request-status> <response-description>Unknown calendar user< /response-description> </response> </schedule-response> A.3. Example: Failed Request In the following example, the iSchedule Sender requests the iSchedule Sender to deliver a task assignment (scheduling REQUEST) to the calendar user mailto:cyrus@example.org. For some reason the Daboo & Desruisseaux Expires November 3, 2013 [Page 47]
Internet-Draft iSchedule May 2013 verification of the request fails as is indicated by the error response. >> Request << POST /.well-known/ischedule HTTP/1.1 DKIM-Signature: a=rsa-sha256; d=example.com; s=jupiter; c=ischedule-relaxed/simple; q=dns/txt:http/well-known; t=1268069852; x=1283918400; h=Originator:Recipient:Content-Type: iSchedule-Version:iSchedule-Message-ID; bh=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx; b=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx Host: cal.example.org iSchedule-Version: 1.0 Originator: mailto:bernard@example.com Recipient: mailto:cyrus@example.org Cache-Control: no-cache, no-transform Content-Type: text/calendar; component=VTODO; method=REQUEST Content-Length: xxxx BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Client//EN METHOD:REQUEST BEGIN:VTODO DTSTAMP:20040901T200200Z ORGANIZER:mailto:bernard@example.com DUE:20070505 SUMMARY:Review Internet-Draft UID:34222-456@example.com ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Cyrus Daboo: mailto:cyrus@example.org END:VEVENT END:VCALENDAR Daboo & Desruisseaux Expires November 3, 2013 [Page 48]
Internet-Draft iSchedule May 2013 >> Response << HTTP/1.1 403 FORBIDDEN Date: Thu, 02 Sep 2004 16:53:32 GMT Content-Type: application/xml; charset=utf-8 Content-Length: xxxx iSchedule-Version: 1.0 iSchedule-Capabilities: 123 <?xml version="1.0" encoding="utf-8" ?> <error xmlns="urn:ietf:params:xml:ns:ischedule"> <verification-failed /> <response-description>Unable to verify request< /response-description> </error> Appendix B. Change Log (to be removed by RFC Editor prior to publication) B.1. Changes in -05 a. Fixed missing Recipient header in example. b. Added statements about what happens when a signature is or is not valid. c. Removed _ischedule SRV record type as we only support HTTPS. d. Removed text about adding an extra Recipient header as we no longer need that. B.2. Changes in -04 a. Added some addition error codes to match MUST requirements. b. Free busy example now shows a failed calendar user response. c. Fixed capabilities response example to add method elements for VTODO and VFREEBUSY. d. More details added to XML element definitions. B.3. Changes in -03 a. Removed http= tag from DKIM header. b. Updated lists of must and must not sign headers. c. Stated that Recipient list must match ATTENDEE list for VFREEBUSY requests. d. Recommend 5 minute skew for t=. e. Added serial-number to capabilities and iSchedule-Capabilities response header. Daboo & Desruisseaux Expires November 3, 2013 [Page 49]
Internet-Draft iSchedule May 2013 f. Added "ischedule-relaxed" header canonicalization. g. Fixed examples. B.4. Changes in -02 a. Major structural changes as well as addition of new sections, including an Overview. b. Changed capabilities XML schema. c. XML error elements are now named for the actual error as opposed to WebDAV style pre-conditions. d. Removed intermediary support and iSchedule-Via header. e. Added TXT path= lookup to accompany SRV lookup. f. Added http/well-known public key lookup mechanism. g. Added iSchedule-Message-ID header. h. Provided suggested values for t= and x= to cope with clock skew and processing time issues. i. Indicated that iSchedule-Version header can be returned in OPTIONS responses. j. Clarified that Attendee list for VFREEBUSY has to be the same as the Recipient list. B.5. Changes in -01 a. Introduced use of DKIM for calendaring and scheduling services. b. The XML elements "supported-calendar-data" and "calendar-data" were renamed to "supported-calendar-data-type" and "calendar- data-type" respectively to avoid confusion with the "calendar- data" XML element being used in the "response" XML element. c. The "recipient" XML element was redefined to accept (#PCDATA) instead of an "href" XML element. d. The grammar of new HTTP headers is now using the ABNF syntax defined in [RFC5234]. e. Fixed various typos. Authors' Addresses Cyrus Daboo Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA EMail: cyrus@daboo.name URI: http://www.apple.com/ Daboo & Desruisseaux Expires November 3, 2013 [Page 50]
Internet-Draft iSchedule May 2013 Bernard Desruisseaux Oracle Corporation 600 Blvd. de Maisonneuve West Suite 1900 Montreal, QC H3A 3J2 CANADA EMail: bernard.desruisseaux@oracle.com URI: http://www.oracle.com/ Daboo & Desruisseaux Expires November 3, 2013 [Page 51]
