Network Working Group C. Daboo Internet-Draft Apple Updates: 4871 (if approved) B. Desruisseaux Intended status: Standards Track Oracle Expires: September 9, 2010 March 8, 2010 Internet Calendar Scheduling Protocol (iSchedule) draft-desruisseaux-ischedule-01 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 to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 9, 2010. Copyright Notice Copyright (c) 2010 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 Daboo & Desruisseaux Expires September 9, 2010 [Page 1]
Internet-Draft iSchedule March 2010 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Notational Conventions . . . . . . . . . . . . . . . . . . 5 2. iSchedule Model . . . . . . . . . . . . . . . . . . . . . . . 6 3. iSchedule Intermediaries . . . . . . . . . . . . . . . . . . . 7 4. iSchedule Receiver Discovery . . . . . . . . . . . . . . . . . 7 4.1. iSchedule SRV Service Types . . . . . . . . . . . . . . . 7 4.2. iSchedule Receiver Request-URI . . . . . . . . . . . . . . 8 4.3. Resolving Calendar User Addresses . . . . . . . . . . . . 8 4.4. Using the SRV Record Result . . . . . . . . . . . . . . . 9 5. iSchedule Receiver Capabilities . . . . . . . . . . . . . . . 9 5.1. Example: Querying iSchedule Receiver Capabilities . . . . 9 6. Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. POST Method . . . . . . . . . . . . . . . . . . . . . . . 11 6.1.1. Schedule Response . . . . . . . . . . . . . . . . . . 12 6.1.2. Status Codes for use with the POST method . . . . . . 13 7. iSchedule Domain-Level Authentication . . . . . . . . . . . . 13 7.1. Signature Content . . . . . . . . . . . . . . . . . . . . 13 7.2. Canonicalization . . . . . . . . . . . . . . . . . . . . . 14 7.2.1. The "simple-http" Header Canonicalization Algorithm . 14 7.2.2. The "simple-http" Body Canonicalization Algorithm . . 14 7.3. Key Management . . . . . . . . . . . . . . . . . . . . . . 14 7.4. Delegation of Signing Authority . . . . . . . . . . . . . 15 7.4.1. Publication of Procuration Record . . . . . . . . . . 15 7.4.2. Procuration Lookup Procedure . . . . . . . . . . . . . 15 8. HTTP Headers . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. DKIM-Signature Request Header . . . . . . . . . . . . . . 16 8.2. iSchedule-Version General Header . . . . . . . . . . . . . 16 8.3. iSchedule-Via General Header . . . . . . . . . . . . . . . 16 8.4. Originator Request Header . . . . . . . . . . . . . . . . 17 8.5. Recipient Request Header . . . . . . . . . . . . . . . . . 17 9. XML Element Definitions . . . . . . . . . . . . . . . . . . . 17 9.1. schedule-response XML Element . . . . . . . . . . . . . . 17 9.1.1. response XML Element . . . . . . . . . . . . . . . . . 18 9.1.1.1. recipient XML Element . . . . . . . . . . . . . . 18 9.1.1.2. request-status XML Element . . . . . . . . . . . . 18 9.1.1.3. calendar-data XML Element . . . . . . . . . . . . 19 Daboo & Desruisseaux Expires September 9, 2010 [Page 2]
Internet-Draft iSchedule March 2010 9.1.1.4. error XML Element . . . . . . . . . . . . . . . . 19 9.1.1.5. responsedescription XML Element . . . . . . . . . 19 9.2. query-result XML Element . . . . . . . . . . . . . . . . . 20 9.2.1. capability-set XML Element . . . . . . . . . . . . . . 20 9.2.1.1. supported-version-set XML Element . . . . . . . . 21 9.2.1.2. supported-scheduling-message-set XML Element . . . 21 9.2.1.3. supported-calendar-data-type XML Element . . . . . 23 9.2.1.4. supported-attachment-values XML Element . . . . . 23 9.2.1.5. supported-recipient-uri-scheme-set XML Element . . 24 9.2.1.6. max-content-length XML Element . . . . . . . . . . 25 9.2.1.7. min-date-time XML Element . . . . . . . . . . . . 25 9.2.1.8. max-date-time XML Element . . . . . . . . . . . . 26 9.2.1.9. max-instances XML Element . . . . . . . . . . . . 26 9.2.1.10. max-recipients XML Element . . . . . . . . . . . . 27 9.2.1.11. administrator XML Element . . . . . . . . . . . . 27 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 10.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 28 10.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 28 10.3. DNS Considerations . . . . . . . . . . . . . . . . . . . . 28 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 11.1. Namespace Registration . . . . . . . . . . . . . . . . . . 28 11.1.1. iSchedule Namespace Registration . . . . . . . . . . . 28 11.2. HTTP Headers Registration . . . . . . . . . . . . . . . . 28 11.2.1. DKIM-Signature Request Header Registration . . . . . . 28 11.2.2. iSchedule-Version General Header Registration . . . . 29 11.2.3. iSchedule-Via General Header Registration . . . . . . 29 11.2.4. Originator Request Header Registration . . . . . . . . 29 11.2.5. Recipient Request Header Registration . . . . . . . . 30 11.3. Well-Known URI Registration . . . . . . . . . . . . . . . 30 11.3.1. iSchedule Well-Known URI Registration . . . . . . . . 30 11.4. DKIM Parameters Registration . . . . . . . . . . . . . . . 30 11.4.1. DKIM-Signature Canonicalization Algorithm Registration . . . . . . . . . . . . . . . . . . . . . 30 11.4.2. DKIM Service Type Registration . . . . . . . . . . . . 31 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 13.1. Normative References . . . . . . . . . . . . . . . . . . . 31 13.2. Informative References . . . . . . . . . . . . . . . . . . 33 Appendix A. Example Scheduling Transactions . . . . . . . . . . . 34 A.1. Example: Simple Meeting Invitation . . . . . . . . . . . . 34 A.2. Example: Search for Busy Time Information . . . . . . . . 36 A.3. Example: Simple Task Assignment . . . . . . . . . . . . . 38 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 40 Appendix C. Change Log (to be removed by RFC Editor prior to publication) . . . . . . . . . . . . . . . . . . . . 40 C.1. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 41 Daboo & Desruisseaux Expires September 9, 2010 [Page 3]
Internet-Draft iSchedule March 2010 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 [RFC4871] to provide end-to-end domain-level authentication based on message content and 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) [I-D.ietf-calsify-rfc2447bis], 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 wish 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 September 9, 2010 [Page 4]
Internet-Draft iSchedule March 2010 occurs on the client instead and requires user intervention, which yield the following consequences: 1. The processing of incoming scheduling messages and the corresponding updates to the calendar only occurs when the client is active. As such, 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 [RFC4871]. 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. 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]. Daboo & Desruisseaux Expires September 9, 2010 [Page 5]
Internet-Draft iSchedule March 2010 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. 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: +----------+ +----------+ +----------+ +----------+ | Calendar | | Calendar | iSchedule | Calendar | | Calendar | | User |-->| Service |----------->| Service |-->| Store | | Agent | | | | | | | +----------+ +----------+ +----------+ +----------+ iSchedule iSchedule Sender Receiver When an iSchedule Sender has a scheduling message to transmit, it determines the iSchedule Receivers to which to delivers the message to and sends the appropriate iSchedule requests. The responsability of an iSchedule Sender is to transfer scheduling messages to one or more iSchedule Receivers, or report its failure to do so. The means by which a Calendar 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], [I-D.desruisseaux-caldav-sched] 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. Daboo & Desruisseaux Expires September 9, 2010 [Page 6]
Internet-Draft iSchedule March 2010 3. iSchedule Intermediaries From the end-to-end view, an iSchedule request is sent to an iSchedule Receiver and a response is returned to the iSchedule Sender. In practice, this may not always be the case. An iSchedule request may travel through several iSchedule intermediaries. iSchedule intermediaries can be used for different purposes, namely: o Dispatch iSchedule request to the appropriate iSchedule Receivers for each specified Recipient; Users of the same domain could actually be hosted on different iSchedule Receivers. o Dispatch iSchedule request to the appropriate iSchedule Receivers according to the calendar component type specified in the requests. Different iSchedule Receivers could be responsible of handling, VEVENT, VTODO, VJOURNAL and VFREEBUSY requests. o Scan iSchedule requests, particularly attachments, for virus. iSchedule intermediaries are REQUIRED to identify their hostname and the version number of the preceding server from which the request or response arrived. iSchedule intermediaries append this information to the "iSchedule-Via" general header, in sequential order, as the request travels between Sender and Receiver. For example, an iSchedule request might be submitted to an iSchedule Receiver with the following "iSchedule-Via" header: iSchedule-Via: 1.0 ischedule.example.com:443 (VendorX/2.0), 1.0 cal.internal.example.com:80 (VendorZ/4.3) 4. iSchedule Receiver Discovery This section describes how an iSchedule Sender can discover the host name, the port as well as the Request-URI to use to submit a request to an iSchedule Receiver. 4.1. iSchedule SRV Service Types This specification adds two SRV service labels for use with iSchedule: Daboo & Desruisseaux Expires September 9, 2010 [Page 7]
Internet-Draft iSchedule March 2010 Identifies an iSchedule Receiver that uses HTTP without transport layer security ([RFC2818]). ischedules: Identifies an iSchedule Receiver that uses HTTP with transport layer security ([RFC2818]). Example: service record for server without transport layer security _ischedule._tcp.example.com. IN SRV 0 1 80 ischedule.example.com. Example: service record for server with transport layer security _ischedules._tcp.example.com. IN SRV 0 1 443 ischedule.example.com. 4.2. iSchedule Receiver Request-URI This specification registers a well-known URI [I-D.nottingham-site-meta] 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. 4.3. Resolving Calendar User Addresses To deliver a scheduling message via the iSchedule protocol, an iSchedule Sender needs to determine what iSchedule Receiver it needs to deliver a scheduling message to for a particular Recipient. Each Recipient's calendar user address is specified in the Recipient request header. 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. To get the SRV record name to query for a given mailto URI, the "domain" portion of the mailto URI MUST be extracted and appended to the service label "_ischedule._tcp." or "_ischedules._tcp.". Example: Calendar User Address: mailto:cyrus@example.com Query SRV Record Names: _ischedules._tcp.example.com _ischedule._tcp.example.com Daboo & Desruisseaux Expires September 9, 2010 [Page 8]
Internet-Draft iSchedule March 2010 In cases where the "domain" portion of the mailto URI contains one or more levels of sub-domain, clients 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 querying 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.4. Using the SRV Record Result As defined in [RFC2782] the result of an SRV record lookup will be a target host name and a port. An iSchedule Sender uses these to contact the iSchedule Receiver. iSchedule Senders MUST honor the full behavior of SRV records as defined by [RFC2782], in particular the TTL, Priority and Weight options in the record, as well as handling multiple records being returned. Since an iSchedule server is an HTTP server, an iSchedule client needs to supply a Request-URI in the HTTP request it makes to the server, in addition to the host name and port information. When SRV records are being used there is no way to specify the Request-URI in the SRV record. As a result clients MUST use "/" as the Request-URI for the iSchedule server identified by an SRV record. 5. iSchedule Receiver Capabilities iSchedule Receivers supporting the features described in this document MUST allow iSchedule Sender to query their capabilities by accepting GET requests targeted at the Request-URI "/.well-known/ ischedule?query=capabilities". The response body for a successful GET request targeted at this URI MUST be an XML document with 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]). 5.1. Example: Querying iSchedule Receiver Capabilities >> Request << GET /.well-known/ischedule?query=capabilities HTTP/1.1 Host: cal.example.com Daboo & Desruisseaux Expires September 9, 2010 [Page 9]
Internet-Draft iSchedule March 2010 >> 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 ETag: "afasdf-132afds" <?xml version="1.0" encoding="utf-8" ?> <query-result xmlns="urn:ietf:params:xml:ns:ischedule"> <capability-set> <supported-version-set> <version>1.0</version> </supported-version-set> <supported-scheduling-message-set> <comp name="VEVENT"> <method name="REQUEST"/> <method name="ADD"/> <method name="REPLY"/> <method name="CANCEL"/> </comp> <comp name="VTODO"/> <comp name="VFREEBUSY"/> </supported-scheduling-message-set> <supported-calendar-data-type> <calendar-data-type content-type="text/calendar" version="2.0"/> </supported-calendar-data-type> <supported-attachment-values> <inline-attachment/> <external-attachment/> </supported-attachment-values> <supported-recipient-uri-scheme-set> <scheme>mailto</scheme> </supported-recipient-uri-scheme-set> <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> </capability-set> </query-result> Daboo & Desruisseaux Expires September 9, 2010 [Page 10]
Internet-Draft iSchedule March 2010 6. Scheduling This section defines how an iSchedule Sender can use the HTTP POST method to submit a scheduling message to an iSchedule Receiver. 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 or free-busy message (e.g., an iCalendar object that follows the iTIP semantic). A submitted scheduling message will be delivered to the calendar user addresses specified in the Recipient request header. A submitted free-busy message will be immediately executed and a free-busy response returned. Every POST request MUST include the iSchedule-Version request header. Every POST request MUST include a single Originator 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 ORGANIZER property or one of the specified ATTENDEE property depending on the specify METHOD property value as summarized in the following table: +----------------+----------------------------------+ | Method | Originator Requirement | +----------------+----------------------------------+ | PUBLISH | None | | REQUEST | MUST match ORGANIZER or ATTENDEE | | REPLY | MUST match ATTENDEE | | ADD | MUST match ORGANIZER | | CANCEL | MUST match ORGANIZER | | REFRESH | None | | COUNTER | MUST match ATTENDEE | | DECLINECOUNTER | MUST match ORGANIZER | +----------------+----------------------------------+ Every POST request MUST include one or more Recipient 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. Daboo & Desruisseaux Expires September 9, 2010 [Page 11]
Internet-Draft iSchedule March 2010 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 a schedule-response XML 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. TODO: Define the response body for a failed request. (supported-calendar-data-type): The resource submitted in the POST request MUST be a supported media type (i.e. text/calendar) for scheduling or free-busy messages; (valid-calendar-data): The resource submitted in the POST request MUST be valid data for the media type being specified (i.e. valid iCalendar object); (valid-scheduling-message): The resource submitted in the POST request MUST obey all restrictions specified for the POST request (e.g., the scheduling message follows the restrictions of iTIP); (originator-specified): The POST request MUST include a valid Originator request header specifying the calendar user address of the originator of the scheduling message. (recipient-specified): The POST request MUST include one or more valid Recipient request headers specifying the calendar user address of users to whom the scheduling message will be delivered. (originator-reply): The calendar user identified by the Originator request header in the POST request MUST have previously received the scheduling message that is being replied to when the scheduling message is an incoming scheduling message; Daboo & Desruisseaux Expires September 9, 2010 [Page 12]
Internet-Draft iSchedule March 2010 (max-content-length): The request body submitted in the POST request MUST have an octet size less than or equal to the value of the max-content-length capability of the iSchedule Receiver. 6.1.2. Status Codes for use with the POST method 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. 200 (OK) - The command succeeded. 400 (Bad Request) - The Sender has provided an invalid scheduling message. 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. 7. iSchedule Domain-Level Authentication iSchedule uses and extends the mechanism defined by DomainKeys Identified Mail (DKIM) [RFC4871]. DKIM defines a domain-level digital signature authentication framework for email, using public- key cryptography, with the domain name service (DNS) as its key server technology. The following sections describes 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 Host o Originator o Recipient Daboo & Desruisseaux Expires September 9, 2010 [Page 13]
Internet-Draft iSchedule March 2010 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 Connection o Keep-Alive o Proxy-Authenticate o Proxy-Authorization o TE o Trailers o Transfer-Encoding o Upgrade 7.2. Canonicalization Transformations can be applied to the message body during transit in order to safely transfer it between the iSchedule Sender and the iSchedule Receiver. Notably, one or more transfer-codings may be applied to an entity. To avoid breaking the DKIM signature of a message, the signer/ verifier MUST compute the hash of a message body against the entity- body, that is, with no transfer-encoding applied to the message body. 7.2.1. The "simple-http" Header Canonicalization Algorithm TODO. 7.2.2. The "simple-http" Body Canonicalization Algorithm TODO. 7.3. Key Management DKIM allows an Administrative Management Domain (ADMD) to constrain the use of a key to specific service types. By default, keys are not constrained to specific service types. As such, the same key could be used to sign email and calendar messages. This specification defines a new service type "calendar" to constrain the use of a key to calendaring and scheduling services: Daboo & Desruisseaux Expires September 9, 2010 [Page 14]
Internet-Draft iSchedule March 2010 +-----------+-------------------------------------------------------+ | Service | Description | | Type | | +-----------+-------------------------------------------------------+ | calendar | calendaring and scheduling service (not necessarily | | | limited to iSchedule) | +-----------+-------------------------------------------------------+ 7.4. Delegation of Signing Authority An Administrative Management Domain (ADMD) MAY delegate signing authority to other ADMD by publishing a Procuration record. The DNS is proposed as the initial mechanism for Procuration records. 7.4.1. Publication of Procuration Record Signing Procuration records are published using the DNS TXT resource record type. _procuration._domainkey.aaa.example TXT "v=1.0 d=bbb.example" TODO: Detailed record syntax specification. Clarify how an ADMD can delegate signing authority to multiple ADMD. 7.4.2. Procuration Lookup Procedure If the Signing Domain IDentifier (SDID) contained in the "d=" tag of DKIM-Signature request header specifies a different domain than the value of the Originator request header, the iSchedule Receiver MUST provide a way to verify whether the owner of the domain of the Originator authorize the domain specified in the SDID to sign on its behalf. The iSchedule Receiver MAY query DNS for a TXT record corresponding to the Originator's domain prefixed by "_procuration._domainkey." (note the trailing dot). If the result of this query is a NOERROR response (rcode=0 in [RFC1035]) with an answer that is a single record that is a valid Procuration record, use that record, and the algorithm terminates. If the result of the query is NXDOMAIN or NOERROR with zero records, there is no Procuration record. If the result of the query contains more than one record, or a record that is not a valid Procuration record, the Procuration result is undefined. If a query results in a "SERVFAIL" error response (rcode=2 in [RFC1035]), the algorithm terminates without returning a result; Daboo & Desruisseaux Expires September 9, 2010 [Page 15]
Internet-Draft iSchedule March 2010 possible actions include queuing the message or returning an iSchedule error indicating a temporary failure. 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 ) 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="RFC4871"/> 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. 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-Via General Header The iSchedule-Via general header field MUST be used by iSchedule intermediaries to indicate the intermediate protocols and recipients between the iSchedule Sender and the iSchedule Receiver on requests. Daboo & Desruisseaux Expires September 9, 2010 [Page 16]
Internet-Draft iSchedule March 2010 iSchedule-Via = "iSchedule-Via" ":" OWS iSchedule-Via-v iSchedule-Via-v = iSchedule-Via-elem *( OWS "," OWS iSchedule-Via-elem ) iSchedule-Via-elem = ( received-protocol received-by [ comment ] ) ; received-protocol as defined in [RFC2616] ; received-by as defined in [RFC2616] ; comment as defined in [RFC2616] 8.4. 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.5. 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 TODO: Re-write XML element definitions using the RELAX NG Compact Syntax [RELAX-NG]. 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. Daboo & Desruisseaux Expires September 9, 2010 [Page 17]
Internet-Draft iSchedule March 2010 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. Definition: <!ELEMENT response (recipient, request-status, calendar-data?, error?, responsedescription?)> 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 Daboo & Desruisseaux Expires September 9, 2010 [Page 18]
Internet-Draft iSchedule March 2010 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 seach for busy time information. 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. responsedescription XML Element Name: responsedescription Daboo & Desruisseaux Expires September 9, 2010 [Page 19]
Internet-Draft iSchedule March 2010 Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Contains information about a status response Description: See Section 6.1.1. Definition: <!ELEMENT responsedescription (#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. Definition: <!ELEMENT query-result (capability-set)> 9.2.1. capability-set XML Element Name: capability-set Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Contains iSchedule Receiver capabilities. Description: The capability-set element contains capabilities of the iSchedule Receiver. Definition: Daboo & Desruisseaux Expires September 9, 2010 [Page 20]
Internet-Draft iSchedule March 2010 <!ELEMENT capability-set (supported-version-set, supported-scheduling-message-set, supported-calendar-data-type, supported-attachment-values, supported-recipient-uri-scheme-set, max-content-length, min-date-time, max-date-time, max-instances, max-recipients, administrator) > 9.2.1.1. supported-version-set XML Element Name: supported-version-set 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. Definition: <!ELEMENT supported-version-set (version)+> 9.2.1.1.1. version XML Element Name: version Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Specifies an iSchedule version. Definition: <!ELEMENT version (#PCDATA)> <!-- PCDATA value: version number --> 9.2.1.2. supported-scheduling-message-set XML Element Daboo & Desruisseaux Expires September 9, 2010 [Page 21]
Internet-Draft iSchedule March 2010 Name: supported-scheduling-message-set Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Identifies the type of supported scheduling messages. Description: An iSchedule Receiver could advertise that it only provides support for event and free-busy scheduling messages, and not for to-do scheduling messages, with this capabilities. Definition: <!ELEMENT supported-scheduling-message-set (comp)+> 9.2.1.2.1. comp XML Element Name: comp Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Identifies a calendar component type. Description: Definition: <!ELEMENT comp (method)*> <!ATTLIST comp name CDATA #REQUIRED> <!-- name value: a calendar component name --> 9.2.1.2.1.1. method XML Element Name: method Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Specifies an iCalendar method type. Description: Definition: <!ELEMENT method EMPTY> Daboo & Desruisseaux Expires September 9, 2010 [Page 22]
Internet-Draft iSchedule March 2010 <!ATTLIST method name CDATA #REQUIRED> <!-- name value: a method type --> 9.2.1.3. supported-calendar-data-type XML Element Name: supported-calendar-data-type Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Description: Definition: <!ELEMENT supported-calendar-data-type (calendar-data-type)+> 9.2.1.3.1. calendar-data-type XML Element Name: calendar-data-type Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Specified a supported media type for scheduling messages. Description: 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.4. supported-attachment-values XML Element Name: supported-attachment-values Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Identifies the attachment values supported. Daboo & Desruisseaux Expires September 9, 2010 [Page 23]
Internet-Draft iSchedule March 2010 Description: Definition: <!ELEMENT supported-attachment-values (inline-attachment?, external-attachment?)> 9.2.1.4.1. inline-attachment XML Element Name: inline-attachment Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Specifies inline attachment as a supported attachment value. Description: Definition: <!ELEMENT inline-attachment EMPTY> 9.2.1.4.2. external-attachment XML Element Name: external-attachment Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Specifies external attachment as a supported attachment value. Description: Definition: <!ELEMENT external-attachment EMPTY> 9.2.1.5. supported-recipient-uri-scheme-set XML Element Name: supported-recipient-uri-scheme-set Namespace: urn:ietf:params:xml:ns:ischedule Daboo & Desruisseaux Expires September 9, 2010 [Page 24]
Internet-Draft iSchedule March 2010 Purpose: Identifies the supported URI schemes supported in the Recipient HTTP request header. Description: Definition: <!ELEMENT supported-recipient-uri-scheme-set (scheme+)> 9.2.1.5.1. scheme XML Element Name: scheme Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Specifies a supported URI scheme. Description: Definition: <!ELEMENT scheme (#PCDATA)> <!-- PCDATA value: URI scheme (e.g., mailto) --> 9.2.1.6. max-content-length XML Element Name: max-content-length Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Specifies the maximum size allowed for a scheduling message in octets. Description: Definition: <!ELEMENT max-content-length (#PCDATA)> <!-- PCDATA value: a numeric value (positive integer) --> 9.2.1.7. min-date-time XML Element Daboo & Desruisseaux Expires September 9, 2010 [Page 25]
Internet-Draft iSchedule March 2010 Name: min-date-time Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Specifies a DATE-TIME value indicating the earliest date and time in UTC that the server is willing to accept for any DATE or DATE-TIME value in a scheduling message. Description: 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: Specifies a DATE-TIME value indicating the latest date and time in UTC that the server is willing to accept for any DATE or DATE-TIME value in a scheduling message. Description: 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: Specifies the maximum number of recurrence instances allowed in a scheduling message. Description: Daboo & Desruisseaux Expires September 9, 2010 [Page 26]
Internet-Draft iSchedule March 2010 Definition: <!ELEMENT max-instances (#PCDATA)> <!-- PCDATA value: a numeric value (positive integer) --> 9.2.1.10. max-recipients XML Element Name: max-recipients Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Specifies the maximum number of recipients allowed for a scheduling message. Description: 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. Description: 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 Daboo & Desruisseaux Expires September 9, 2010 [Page 27]
Internet-Draft iSchedule March 2010 [RFC4871] 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) [RFC4871]. DKIM defines a domain-level 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]. 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. 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 Daboo & Desruisseaux Expires September 9, 2010 [Page 28]
Internet-Draft iSchedule March 2010 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-Via General Header Registration Header field name: iSchedule-Via Applicable protocol: http Status: standard Author/Change controller: IETF Specification document(s): this specification Related information: none 11.2.4. Originator Request Header Registration Header field name: Originator Applicable protocol: http Status: standard Author/Change controller: IETF Specification document(s): this specification Daboo & Desruisseaux Expires September 9, 2010 [Page 29]
Internet-Draft iSchedule March 2010 Related information: none 11.2.5. 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 [I-D.nottingham-site-meta]. 11.3.1. iSchedule Well-Known URI Registration URI suffix: ischedule Change controller: IETF. Specification document(s): this specification Related information: none 11.4. DKIM Parameters Registration 11.4.1. DKIM-Signature Canonicalization Algorithm Registration This specification registers new canonicalization algorithms for the header and body of HTTP requests as per [RFC4871]. The following value should be added to the DKIM-Signature Canonicalization Header registery established in Section 7.3 of [RFC4871]: +-------------+-----------+ | Type | Reference | +-------------+-----------+ | simple-http | RFC XXXX | +-------------+-----------+ Daboo & Desruisseaux Expires September 9, 2010 [Page 30]
Internet-Draft iSchedule March 2010 The following value should be added to the DKIM-Signature Canonicalization Body registery established in Section 7.3 of [RFC4871]: +-------------+-----------+ | Type | Reference | +-------------+-----------+ | simple-http | RFC XXXX | +-------------+-----------+ 11.4.2. DKIM Service Type Registration This specification registers a new DKIM service type to specify that a given selector MUST only be used to verify messages of calendar services (not necessarily limited to iSchedule). The following value should be added to the DKIM Service Type Registry established in Section 7.7 of [RFC4871]: +----------+-----------+ | Type | Reference | +----------+-----------+ | calendar | RFC XXXX | +----------+-----------+ 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, Simon Pilette, Arnaud Quillaud, Simon Vaillancourt, and Wilfredo Sanchez Vega. The authors would also like to thank 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 [I-D.nottingham-site-meta] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known URIs", draft-nottingham-site-meta-05 (work in progress), December 2009. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. Daboo & Desruisseaux Expires September 9, 2010 [Page 31]
Internet-Draft iSchedule March 2010 [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. [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. 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. [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007. [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. Daboo & Desruisseaux Expires September 9, 2010 [Page 32]
Internet-Draft iSchedule March 2010 [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. [W3C.REC-xml-20081126] Maler, E., Yergeau, F., Sperberg- McQueen, C., Paoli, J., and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml- 20081126, November 2008, <http:// www.w3.org/TR/2008/ REC-xml-20081126>. 13.2. Informative References [I-D.desruisseaux-caldav-sched] Daboo, C. and B. Desruisseaux, "CalDAV Scheduling Extensions to WebDAV", draft-desruisseaux-caldav-sched-08 (work in progress), August 2009. [I-D.ietf-calsify-rfc2447bis] Melnikov, A., "iCalendar Message- Based Interoperability Protocol (iMIP)", draft-ietf-calsify-rfc2447bis-08 (work in progress), January 2010. [RELAX-NG] Clark, J., "RELAX NG Compact Syntax", December 2001, <http:// www.oasis-open.org/committees/ relax-ng/compact-20021121.html>. [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. Daboo & Desruisseaux Expires September 9, 2010 [Page 33]
Internet-Draft iSchedule March 2010 [RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys Identified Mail (DKIM) Service Overview", RFC 5585, July 2009. 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 September 9, 2010 [Page 34]
Internet-Draft iSchedule March 2010 >> Request << POST /.well-known/ischedule HTTP/1.1 DKIM-Signature: a=rsa-sha256; d=example.com; s=jupiter; c=simple-http; q=dns/txt; t=1268069852; x=1283918400; h=Originator:Recipient:Host:Content-Type; bh=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx; b=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx Host: cal.example.org iSchedule-Version: 1.0 Originator: mailto:bernard@example.com Recipient: mailto:cyrus@example.org 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 September 9, 2010 [Page 35]
Internet-Draft iSchedule March 2010 >> 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 iSchedule-Version: 1.0 <?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> <responsedescription>Delivered to recipient</responsedescription> </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 user mailto:cyrus@example.org, over the time range specified by the scheduling message sent in the request. The response includes VFREEBUSY components with the busy time of the requested calendar user. Daboo & Desruisseaux Expires September 9, 2010 [Page 36]
Internet-Draft iSchedule March 2010 >> Request << POST /.well-known/ischedule HTTP/1.1 DKIM-Signature: a=rsa-sha256; d=example.com; s=jupiter; c=simple-http; q=dns/txt; t=1268069852; x=1283918400; h=Originator:Recipient:Host:Content-Type; bh=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx; b=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx Host: cal.example.org iSchedule-Version: 1.0 Originator: mailto:bernard@example.com Recipient: mailto:cyrus@example.org 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 END:VFREEBUSY END:VCALENDAR Daboo & Desruisseaux Expires September 9, 2010 [Page 37]
Internet-Draft iSchedule March 2010 >> 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 iSchedule-Version: 1.0 <?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> </schedule-response> A.3. Example: Simple Task Assignment 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. The response indicates that delivery of the scheduling message was successful. Daboo & Desruisseaux Expires September 9, 2010 [Page 38]
Internet-Draft iSchedule March 2010 >> Request << POST /.well-known/ischedule HTTP/1.1 DKIM-Signature: a=rsa-sha256; d=example.com; s=jupiter; c=simple-http; q=dns/txt; t=1268069852; x=1283918400; h=Originator:Recipient:Host:Content-Type; bh=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx; b=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx Host: cal.example.org iSchedule-Version: 1.0 Originator: mailto:bernard@example.com Recipient: mailto:cyrus@example.org 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 September 9, 2010 [Page 39]
Internet-Draft iSchedule March 2010 >> 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 iSchedule-Version: 1.0 <?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> <responsedescription>Delivered to recipient</responsedescription> </response> </schedule-response> Appendix B. Open Issues 1. As specified in Section 3.6 of DKIM, parameters to the key lookup algorithm are the type of the lookup (the "q=" tag), the domain of the signer (the "d=" tag of the DKIM-Signature header field), and the selector (the "s=" tag). Is the use of the "s=" and "d=" tags sufficient to allow "email" and "calendar" DKIM keys to be managed separately, or should a new tag be introduced to override the default DNS name to look for (e.g., "n=_calendardomainkey", to override "_domainkey")? 2. Should we forbid the "DKIM-Signature" header to be listed in the HTTP "Trailer" header? Else, should we require a "DKIM- Signature-Header" header that would specify the algorithm (a= tag) up front (along with s= and d= tags to match the proper DKIM-Signature if multiple values are provided) when the "DKIM- Signature" header is listed in the "Trailer" header? Knowning the algorithm up front would avoid going through the data twice. "Trailer: Content-MD5" doesn't have this issue since the algorithm is implicit. 3. Should the "Host" and "Recipient" request header really be REQUIRED to be signed? Should we required the actual Request-URI to be signed as well? Appendix C. Change Log (to be removed by RFC Editor prior to publication) Daboo & Desruisseaux Expires September 9, 2010 [Page 40]
Internet-Draft iSchedule March 2010 C.1. 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/ 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 September 9, 2010 [Page 41]
