Internet DRAFT - draft-desruisseaux-ischedule
draft-desruisseaux-ischedule
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]
