Network Working Group C. Daboo Internet-Draft Apple Intended status: Standards Track B. Desruisseaux Expires: May 19, 2010 Oracle November 15, 2009 Internet Calendar Scheduling Protocol (iSchedule) draft-desruisseaux-ischedule-00 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 May 19, 2010. Copyright Notice Copyright (c) 2009 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 May 19, 2010 [Page 1] Internet-Draft iSchedule November 2009 (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 . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . 11 6.1.2. Status Codes for use with the POST method . . . . . . 12 6.1.3. Example: Simple meeting invitation . . . . . . . . . . 13 6.1.4. Example: Search for Busy Time Information . . . . . . 15 6.1.5. Example: Simple Task Assignment . . . . . . . . . . . 17 7. HTTP Headers . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. iSchedule-Version General Header . . . . . . . . . . . . . 18 7.2. iSchedule-Via General Header . . . . . . . . . . . . . . . 18 7.3. Originator Request Header . . . . . . . . . . . . . . . . 19 7.4. Recipient Request Header . . . . . . . . . . . . . . . . . 19 8. XML Element Definitions . . . . . . . . . . . . . . . . . . . 19 8.1. schedule-response XML Element . . . . . . . . . . . . . . 19 8.1.1. response XML Element . . . . . . . . . . . . . . . . . 20 8.1.1.1. recipient XML Element . . . . . . . . . . . . . . 20 8.1.1.2. request-status XML Element . . . . . . . . . . . . 20 8.1.1.3. calendar-data XML Element . . . . . . . . . . . . 21 8.1.1.4. error XML Element . . . . . . . . . . . . . . . . 21 8.1.1.5. responsedescription XML Element . . . . . . . . . 21 8.2. query-result XML Element . . . . . . . . . . . . . . . . . 22 8.2.1. capability-set XML Element . . . . . . . . . . . . . . 22 8.2.1.1. supported-version-set XML Element . . . . . . . . 23 8.2.1.2. supported-scheduling-message-set XML Element . . . 23 8.2.1.3. supported-calendar-data XML Element . . . . . . . 24 Daboo & Desruisseaux Expires May 19, 2010 [Page 2] Internet-Draft iSchedule November 2009 8.2.1.4. supported-attachment-values XML Element . . . . . 25 8.2.1.5. supported-recipient-uri-scheme-set XML Element . . 26 8.2.1.6. max-content-length XML Element . . . . . . . . . . 27 8.2.1.7. min-date-time XML Element . . . . . . . . . . . . 27 8.2.1.8. max-date-time XML Element . . . . . . . . . . . . 28 8.2.1.9. max-instances XML Element . . . . . . . . . . . . 28 8.2.1.10. max-recipients XML Element . . . . . . . . . . . . 28 8.2.1.11. administrator XML Element . . . . . . . . . . . . 29 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 9.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 29 9.3. Authorization . . . . . . . . . . . . . . . . . . . . . . 30 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 10.1. Namespace Registration . . . . . . . . . . . . . . . . . . 30 10.1.1. iSchedule Namespace Registration . . . . . . . . . . . 30 10.2. HTTP Headers Registration . . . . . . . . . . . . . . . . 30 10.2.1. iSchedule-Version General Header Registration . . . . 30 10.2.2. iSchedule-Via General Header Registration . . . . . . 31 10.2.3. Originator Request Header Registration . . . . . . . . 31 10.2.4. Recipient Request Header Registration . . . . . . . . 31 10.3. Well-Known URI Registration . . . . . . . . . . . . . . . 31 10.3.1. iSchedule Well-Known URI Registration . . . . . . . . 32 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 12.1. Normative References . . . . . . . . . . . . . . . . . . . 32 12.2. Informative References . . . . . . . . . . . . . . . . . . 33 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 34 Daboo & Desruisseaux Expires May 19, 2010 [Page 3] Internet-Draft iSchedule November 2009 1. Introduction This binding document provides the transport specific information necessary to convey iCalendar Transport-independent Interoperability Protocol (iTIP) [I-D.ietf-calsify-2446bis] 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 allows 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. Discussion of this Internet-Draft is taking place on the mailing list . 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 than with users of their own system. This section clarifies the motivations for a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) [I-D.ietf-calsify-2446bis] 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 occurs on the client instead and requires user intervention, which yield the following consequences: Daboo & Desruisseaux Expires May 19, 2010 [Page 4] Internet-Draft iSchedule November 2009 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 to verify 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 [I-D.ietf-calsify-2446bis] specifies an interoperability protocol for scheduling between different implementations. 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 used by this document to describe protocol elements is described in Section 2.1 of [RFC2616]. Because this augmented BNF uses the basic production rules provided in Section 2.2 of [RFC2616], those rules apply to this document as well. 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]. Daboo & Desruisseaux Expires May 19, 2010 [Page 5] Internet-Draft iSchedule November 2009 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 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. 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 Daboo & Desruisseaux Expires May 19, 2010 [Page 6] Internet-Draft iSchedule November 2009 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 service types for use with SRV records: ischedule: 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 Daboo & Desruisseaux Expires May 19, 2010 [Page 7] Internet-Draft iSchedule November 2009 _ischedule._tcp SRV 0 1 80 ischedule.example.com. Example: service record for server with transport layer security _ischedules._tcp SRV 0 1 443 ischedule.example.com. 4.2. iSchedule Receiver Request-URI This specification registers a well-known URI for the iSchedule service, namely, "ischedule" (see Section 10.3.1). iSchedule Receivers MUST support requests targeted at this well-known URI. iSchedule Sender MUST handle HTTP redirects on the 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 map a mailto URI to an SRV record name to query, the "domain" portion of the URI is extracted and appended to the service identifier "_ischedule._tcp." or "_ischedules._tcp." to form the record name. Example: Calendar User Address: mailto:cyrus@example.com Query SRV Record Names: _ischedules._tcp.example.com _ischedule._tcp.example.com 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. Daboo & Desruisseaux Expires May 19, 2010 [Page 8] Internet-Draft iSchedule November 2009 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. 5.1. Example: Querying iSchedule Receiver Capabilities >> Request << GET /.well-known/ischedule?query=capabilities HTTP/1.1 Host: cal.example.com Daboo & Desruisseaux Expires May 19, 2010 [Page 9] Internet-Draft iSchedule November 2009 >> 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" 1 mailto 102400 19910101T000000Z 20381231T000000Z 150 250 mailto:ischedule-admin@example.com Daboo & Desruisseaux Expires May 19, 2010 [Page 10] Internet-Draft iSchedule November 2009 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. 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. 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 Daboo & Desruisseaux Expires May 19, 2010 [Page 11] Internet-Draft iSchedule November 2009 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): 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 a single calendar user address of the currently authenticated user; (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; (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. Daboo & Desruisseaux Expires May 19, 2010 [Page 12] Internet-Draft iSchedule November 2009 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. 6.1.3. Example: Simple meeting invitation >> Request << POST /.well-known/ischedule HTTP/1.1 Host: cal.example.org iSchedule-Version: 1.0 Originator: mailto:bernard@example.com Recipient: mailto:cyrus@example.org Content-Type: text/calendar 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 May 19, 2010 [Page 13] Internet-Draft iSchedule November 2009 >> 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 mailto:cyrus@example.org 2.0;Success Delivered to recipient scheduling inbox In this 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 May 19, 2010 [Page 14] Internet-Draft iSchedule November 2009 6.1.4. Example: Search for Busy Time Information >> Request << POST /.well-known/ischedule HTTP/1.1 Host: cal.example.org iSchedule-Version: 1.0 Originator: mailto:bernard@example.com Recipient: mailto:cyrus@example.org Content-Type: text/calendar 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 May 19, 2010 [Page 15] Internet-Draft iSchedule November 2009 >> 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 mailto:cyrus@example.org 2.0;Success 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 In this 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 May 19, 2010 [Page 16] Internet-Draft iSchedule November 2009 6.1.5. Example: Simple Task Assignment >> Request << POST /.well-known/ischedule HTTP/1.1 Host: cal.example.org iSchedule-Version: 1.0 Originator: mailto:bernard@example.com Recipient: mailto:cyrus@example.org Content-Type: text/calendar 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 May 19, 2010 [Page 17] Internet-Draft iSchedule November 2009 >> 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 mailto:cyrus@example.org 2.0;Success Delivered to recipient scheduling inbox In this 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. 7. HTTP Headers 7.1. iSchedule-Version General Header iSchedule-Version = "iSchedule-Version" ":" 1*DIGIT "." 1*DIGIT The iSchedule-Version general header field MUST be specified by the iSchedule Sender on requests, and by the iSchedule Receiver on responses. TODO: Consider whether the iSchedule-Version should be returned on a per recipient basis in the response body. 7.2. iSchedule-Via General Header iSchedule-Via = "iSchedule-Via" ":" 1#( received-protocol received-by [ comment ] ) ; received-protocol as defined in [RFC2616] ; received-by as defined in [RFC2616] ; comment as defined in [RFC2616] Daboo & Desruisseaux Expires May 19, 2010 [Page 18] Internet-Draft iSchedule November 2009 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. TODO: Consider whether the iSchedule-Via should be returned on a per recipient basis in the response body. 7.3. Originator Request Header Originator = "Originator" ":" absoluteURI ; absoluteURI as defined in [RFC3986] 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 production is defined in RFC3986 [RFC3986]. 7.4. Recipient Request Header Recipient = "Recipient" ":" 1#absoluteURI ; absoluteURI as defined in [RFC3986] 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 production is defined in RFC3986 [RFC3986] 8. XML Element Definitions 8.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: Daboo & Desruisseaux Expires May 19, 2010 [Page 19] Internet-Draft iSchedule November 2009 8.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: 8.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: 8.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. Daboo & Desruisseaux Expires May 19, 2010 [Page 20] Internet-Draft iSchedule November 2009 Definition: 8.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: 8.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: 8.1.1.5. responsedescription XML Element Name: responsedescription Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Contains information about a status response Daboo & Desruisseaux Expires May 19, 2010 [Page 21] Internet-Draft iSchedule November 2009 Description: See Section 6.1.1. Definition: 8.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: 8.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 May 19, 2010 [Page 22] Internet-Draft iSchedule November 2009 8.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: 8.2.1.1.1. version XML Element Name: version Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Specifies an iSchedule version. Definition: 8.2.1.2. supported-scheduling-message-set XML Element 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: Daboo & Desruisseaux Expires May 19, 2010 [Page 23] Internet-Draft iSchedule November 2009 8.2.1.2.1. comp XML Element Name: comp Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Identifies a calendar component type. Description: Definition: 8.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: 8.2.1.3. supported-calendar-data XML Element Name: supported-calendar-data Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Contains Description: Daboo & Desruisseaux Expires May 19, 2010 [Page 24] Internet-Draft iSchedule November 2009 Definition: 8.2.1.3.1. calendar-data XML Element Name: calendar-data Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Specified a supported media type for scheduling messages. Description: Definition: 8.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. Description: Definition: 8.2.1.4.1. inline-attachment XML Element Name: inline-attachment Daboo & Desruisseaux Expires May 19, 2010 [Page 25] Internet-Draft iSchedule November 2009 Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Specifies inline attachment as a supported attachment value. Description: Definition: 8.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: 8.2.1.5. supported-recipient-uri-scheme-set XML Element Name: supported-recipient-uri-scheme-set Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Identifies the supported URI schemes supported in the Recipient HTTP request header. Description: Definition: Daboo & Desruisseaux Expires May 19, 2010 [Page 26] Internet-Draft iSchedule November 2009 8.2.1.5.1. scheme XML Element Name: scheme Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Specifies a supported URI scheme. Description: Definition: 8.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: 8.2.1.7. min-date-time XML Element 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: Daboo & Desruisseaux Expires May 19, 2010 [Page 27] Internet-Draft iSchedule November 2009 Definition: 8.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: 8.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: Definition: 8.2.1.10. max-recipients XML Element Name: max-recipients Daboo & Desruisseaux Expires May 19, 2010 [Page 28] Internet-Draft iSchedule November 2009 Namespace: urn:ietf:params:xml:ns:ischedule Purpose: Specifies the maximum number of recipients allowed for a scheduling message. Description: Definition: 8.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: 9. 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. 9.1. Privacy iSchedule Senders and iSchedule Receivers MUST use an HTTP connection protected with TLS as defined in [RFC2818] for all scheduling transactions. 9.2. Authentication Mutual authentication is done with TLS [RFC5246] using certificates exchanged between both the iSchedule Sender and the iSchedule Receiver. Daboo & Desruisseaux Expires May 19, 2010 [Page 29] Internet-Draft iSchedule November 2009 9.3. Authorization Once an iSchedule Sender has been successfully authenticated, the iSchedule Receiver MUST verify that the iSchedule Sender has the authority to send a scheduling message on behalf of the Originator. TODO: Clarify how verification must be done. Should trusted iSchedule Sender be identified as such in DNS (e.g., by storing their certificate in the DNS (see [RFC4398])) Should the iSchedule Receiver contact the iSchedule Receiver of the domain of the iSchedule Sender to find out whether it should be trusted or not? 10. IANA Considerations 10.1. Namespace Registration This specification registers a new URN to identify a new XML namespace as per [RFC3688]. 10.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. 10.2. HTTP Headers Registration This specification registers three new headers for use with HTTP as per [RFC3864]. 10.2.1. 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 Daboo & Desruisseaux Expires May 19, 2010 [Page 30] Internet-Draft iSchedule November 2009 10.2.2. 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 10.2.3. 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 10.2.4. 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 10.3. Well-Known URI Registration This specification registers a new well-known URI as per [I-D.nottingham-site-meta]. Daboo & Desruisseaux Expires May 19, 2010 [Page 31] Internet-Draft iSchedule November 2009 10.3.1. iSchedule Well-Known URI Registration URI suffix: ischedule Change controller: IETF. Specification document(s): this specification Related information: none 11. 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, 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. 12. References 12.1. Normative 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-2446bis] Daboo, C., "iCalendar Transport- Independent Interoperability Protocol (iTIP)", draft-ietf-calsify-2446bis-10 (work in progress), October 2009. [I-D.nottingham-site-meta] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known URIs", draft-nottingham-site-meta-03 (work in progress), September 2009. [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., Daboo & Desruisseaux Expires May 19, 2010 [Page 32] Internet-Draft iSchedule November 2009 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. [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. [W3C.REC-xml-20081126] Yergeau, F., Maler, E., Paoli, J., Sperberg-McQueen, C., and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml- 20081126, November 2008, . 12.2. Informative References [I-D.faltstrom-uri] Faltstrom, P. and O. Kolkman, "The Uniform Resource Identifier (URI) DNS Resource Record", draft-faltstrom-uri-04 (work in progress), May 2009. Daboo & Desruisseaux Expires May 19, 2010 [Page 33] Internet-Draft iSchedule November 2009 [I-D.ietf-calsify-rfc2447bis] Melnikov, A., "iCalendar Message- Based Interoperability Protocol (iMIP)", draft-ietf-calsify-rfc2447bis-07 (work in progress), October 2009. [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004. [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name System (DNS)", RFC 4398, March 2006. [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, March 2007. Appendix A. Open Issues 1. Should we consider [I-D.faltstrom-uri] as another approach to discover iSchedule Receiver? 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 May 19, 2010 [Page 34]