[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05

Network Working Group                                           C. Daboo
Internet-Draft                                                     Apple
Updates: 6376 (if approved)                              B. Desruisseaux
Intended status: Standards Track                                  Oracle
Expires: April 25, 2013                                 October 22, 2012


           Internet Calendar Scheduling Protocol (iSchedule)
                    draft-desruisseaux-ischedule-02

Abstract

   This document defines the Internet Calendar Scheduling Protocol
   (iSchedule), which is a binding from the iCalendar Transport-
   independent Interoperability Protocol (iTIP) to the Hypertext
   Transfer Protocol (HTTP) to enable interoperability between
   calendaring and scheduling systems over the Internet.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 25, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as



Daboo & Desruisseaux     Expires April 25, 2013                 [Page 1]


Internet-Draft                  iSchedule                   October 2012


   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Motivations  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Related Memos  . . . . . . . . . . . . . . . . . . . . . .  5
     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
     1.4.  Notational Conventions . . . . . . . . . . . . . . . . . .  6
   2.  iSchedule Model  . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  iSchedule Overview . . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  iSchedule Sender Actions . . . . . . . . . . . . . . . . .  7
     3.2.  iSchedule Receiver Actions . . . . . . . . . . . . . . . .  8
   4.  iSchedule Receiver Discovery . . . . . . . . . . . . . . . . .  9
     4.1.  Resolving Calendar User Addresses  . . . . . . . . . . . .  9
     4.2.  iSchedule SRV Service Types  . . . . . . . . . . . . . . . 10
     4.3.  iSchedule Service TXT Records  . . . . . . . . . . . . . . 11
     4.4.  iSchedule Receiver Request-URI . . . . . . . . . . . . . . 11
   5.  iSchedule Receiver Capabilities  . . . . . . . . . . . . . . . 11
     5.1.  Example: Querying iSchedule Receiver Capabilities  . . . . 12
   6.  Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.1.  POST Method  . . . . . . . . . . . . . . . . . . . . . . . 14
       6.1.1.  Schedule Response  . . . . . . . . . . . . . . . . . . 16
       6.1.2.  Failed Schedule Response . . . . . . . . . . . . . . . 16
   7.  iSchedule Domain-Level Authentication  . . . . . . . . . . . . 18
     7.1.  Signature Content  . . . . . . . . . . . . . . . . . . . . 19
     7.2.  Canonicalization . . . . . . . . . . . . . . . . . . . . . 20
     7.3.  Key Management . . . . . . . . . . . . . . . . . . . . . . 21
       7.3.1.  DNS-based Public Key Management  . . . . . . . . . . . 21
       7.3.2.  HTTP-based Public Key Management . . . . . . . . . . . 21
         7.3.2.1.  SRV Service Type . . . . . . . . . . . . . . . . . 22
         7.3.2.2.  Well-known Request-URI . . . . . . . . . . . . . . 22
         7.3.2.3.  Example Lookup Procedure . . . . . . . . . . . . . 23
       7.3.3.  Private Exchange Public Key Management . . . . . . . . 23
     7.4.  Verification Requirements  . . . . . . . . . . . . . . . . 23
     7.5.  Authorized Third-Party Signatures  . . . . . . . . . . . . 24
   8.  HTTP Headers . . . . . . . . . . . . . . . . . . . . . . . . . 24
     8.1.  DKIM-Signature Request Header  . . . . . . . . . . . . . . 24
     8.2.  iSchedule-Version General Header . . . . . . . . . . . . . 24
     8.3.  iSchedule-Message-ID Request Header  . . . . . . . . . . . 25
     8.4.  Originator Request Header  . . . . . . . . . . . . . . . . 25
     8.5.  Recipient Request Header . . . . . . . . . . . . . . . . . 25
   9.  XML Element Definitions  . . . . . . . . . . . . . . . . . . . 25
     9.1.  schedule-response XML Element  . . . . . . . . . . . . . . 25
       9.1.1.  response XML Element . . . . . . . . . . . . . . . . . 26
         9.1.1.1.  recipient XML Element  . . . . . . . . . . . . . . 26
         9.1.1.2.  request-status XML Element . . . . . . . . . . . . 26
         9.1.1.3.  calendar-data XML Element  . . . . . . . . . . . . 27



Daboo & Desruisseaux     Expires April 25, 2013                 [Page 2]


Internet-Draft                  iSchedule                   October 2012


         9.1.1.4.  error XML Element  . . . . . . . . . . . . . . . . 27
         9.1.1.5.  response-description XML Element . . . . . . . . . 27
     9.2.  query-result XML Element . . . . . . . . . . . . . . . . . 28
       9.2.1.  capabilities XML Element . . . . . . . . . . . . . . . 28
         9.2.1.1.  versions XML Element . . . . . . . . . . . . . . . 29
         9.2.1.2.  scheduling-messages XML Element  . . . . . . . . . 29
         9.2.1.3.  calendar-data-types XML Element  . . . . . . . . . 31
         9.2.1.4.  attachments XML Element  . . . . . . . . . . . . . 31
         9.2.1.5.  max-content-length XML Element . . . . . . . . . . 32
         9.2.1.6.  min-date-time XML Element  . . . . . . . . . . . . 33
         9.2.1.7.  max-date-time XML Element  . . . . . . . . . . . . 33
         9.2.1.8.  max-instances XML Element  . . . . . . . . . . . . 33
         9.2.1.9.  max-recipients XML Element . . . . . . . . . . . . 34
         9.2.1.10. administrator XML Element  . . . . . . . . . . . . 34
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 34
     10.1. Privacy  . . . . . . . . . . . . . . . . . . . . . . . . . 35
     10.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 35
     10.3. DNS Considerations . . . . . . . . . . . . . . . . . . . . 35
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 35
     11.1. Namespace Registration . . . . . . . . . . . . . . . . . . 35
       11.1.1. iSchedule Namespace Registration . . . . . . . . . . . 35
     11.2. HTTP Headers Registration  . . . . . . . . . . . . . . . . 35
       11.2.1. DKIM-Signature Request Header Registration . . . . . . 35
       11.2.2. iSchedule-Version General Header Registration  . . . . 36
       11.2.3. iSchedule-Message-ID Request Header Registration . . . 36
       11.2.4. Originator Request Header Registration . . . . . . . . 36
       11.2.5. Recipient Request Header Registration  . . . . . . . . 37
     11.3. Well-Known URI Registration  . . . . . . . . . . . . . . . 37
       11.3.1. iSchedule Well-Known URI Registration  . . . . . . . . 37
       11.3.2. DKIM Well-Known URI Registration . . . . . . . . . . . 37
     11.4. DKIM Parameters Registration . . . . . . . . . . . . . . . 37
       11.4.1. DKIM-Signature Query Method Registry . . . . . . . . . 37
       11.4.2. DKIM Service Type Registration . . . . . . . . . . . . 38
   12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 38
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 38
     13.2. Informative References . . . . . . . . . . . . . . . . . . 40
   Appendix A.  Example Scheduling Transactions . . . . . . . . . . . 40
     A.1.  Example: Simple Meeting Invitation . . . . . . . . . . . . 41
     A.2.  Example: Search for Busy Time Information  . . . . . . . . 42
     A.3.  Example: Failed Request  . . . . . . . . . . . . . . . . . 44
   Appendix B.  Change Log (to be removed by RFC Editor prior to
                publication)  . . . . . . . . . . . . . . . . . . . . 46
     B.1.  Changes in -02 . . . . . . . . . . . . . . . . . . . . . . 46
     B.2.  Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 46






Daboo & Desruisseaux     Expires April 25, 2013                 [Page 3]


Internet-Draft                  iSchedule                   October 2012


1.  Introduction

   This binding document provides the transport specific information
   necessary to convey iCalendar Transport-independent Interoperability
   Protocol (iTIP) [RFC5546] messages over the Hypertext Transfer
   Protocol (HTTP) [RFC2616].

   The Internet Calendar Scheduling Protocol (iSchedule) enables
   interoperability between different calendaring and scheduling
   systems.  Calendaring and scheduling systems that provide support for
   iSchedule allow their users to perform scheduling transactions such
   as schedule, reschedule, respond to scheduling request or cancel
   scheduled calendar components, as well as search for busy time
   information with users of other calendaring and scheduling systems on
   the Internet.

   iSchedule leverages the DomainKeys Identified Mail (DKIM) service
   [RFC6376] to provide end-to-end domain-level authentication based on
   message content that is transparent to end users.

   Discussion of this Internet-Draft is taking place on the mailing list
   <https://www.ietf.org/mailman/listinfo/ischedule>.

1.1.  Motivations

   The iCalendar Message-Based Interoperability Protocol (iMIP)
   [RFC6047], has proven to be insufficient to allow users to seamlessly
   perform the same scheduling operations with users of other
   calendaring and scheduling systems on the Internet as with users of
   their own system.  This section clarifies the motivations for a
   binding from the iCalendar Transport-independent Interoperability
   Protocol (iTIP) [RFC5546] to a transport that allows synchronous end-
   to-end connectivity.

   A binding to an email-based transport is clearly inadequate to search
   for busy time information since users need and expect to get an
   immediate response.  As such, some calendaring and scheduling systems
   allow users to publish their free busy information in a resource
   accessible to others on the Internet.  In the absence of a
   standardized mechanism to locate the resource that provides the free
   busy information of a user, one thus needs to know the location of
   this resource in addition to the calendar user address of the users
   one wishes to schedule with.

   With an email-based transport, the transparent processing of incoming
   scheduling messages on the server is only possible when the
   calendaring and scheduling system is integrated with the email
   system.  Commonly, the processing of incoming scheduling messages



Daboo & Desruisseaux     Expires April 25, 2013                 [Page 4]


Internet-Draft                  iSchedule                   October 2012


   occurs on the client and requires user intervention, which yields the
   following consequences:

   1.  The processing of incoming scheduling messages and the
       corresponding updates to the calendar only occur when the client
       is active.  As a result, free busy information may be inaccurate
       (e.g., user still appears busy when the organizer actually
       rescheduled or canceled the meeting).

   2.  Calendaring and scheduling systems generally restrain the number
       of updates sent to users to reduce the number of messages that
       will clutter their email inbox.  As a result, attendees rarely
       obtain up to date participation status of other attendees.

   3.  The client becomes responsible for verification of the
       authenticity and integrity of the scheduling message.

1.2.  Related Memos

   Implementers will need to be familiar with other documents that,
   along with this document, form a framework for Internet calendaring
   and scheduling standards.

   This document specifies a binding from iTIP to HTTP.

   o  iCalendar [RFC5545] specifies a core specification of objects,
      data types, properties and property parameters;

   o  iTIP [RFC5546] specifies an interoperability protocol for
      scheduling between different implementations.

   Furthermore, implementers will need to be familiar with the
   DomainKeys Identified Mail (DKIM) service defined in [RFC6376].  An
   overview of DKIM can be found in [RFC5585].

   This document does not attempt to repeat the specification of
   concepts or definitions from these other documents.  Where possible,
   references are made to the document that provides the specification
   of these concepts or definitions.

1.3.  Terminology

   This specification reuses much of the same terminology as iCalendar
   [RFC5545], iTIP [RFC5546], HTTP [RFC2616], and DKIM [RFC6376].
   Additional terms used by this specification are:






Daboo & Desruisseaux     Expires April 25, 2013                 [Page 5]


Internet-Draft                  iSchedule                   October 2012


   Scheduling message:  An iCalendar [RFC5545] object conforming to the
      requirements of iTIP [RFC5546].

   Originator:  The calendar user who is sending a scheduling message to
      one or more other calendar users.

   Recipient:  A calendar user to whom a sending a scheduling message is
      being sent.

   iSchedule Sender:  The iSchedule service responsible for sending
      scheduling messages.

   iSchedule Receiver:  The iSchedule service responsible for receiving
      scheduling messages.

1.4.  Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   The Augmented BNF (ABNF) syntax used by this document to describe
   protocol elements is defined in [RFC5234].

   Definitions of XML elements in this document use XML element type
   declarations (as found in XML Document Type Declarations), described
   in Section 3.2 of [W3C.REC-xml-20081126].

   The namespace "urn:ietf:params:xml:ns:ischedule" is reserved for the
   XML elements defined in this specification, or in other Standards
   Track IETF RFCs written to extend iSchedule.  It MUST NOT be used for
   proprietary extensions.  When XML element types in this namespace are
   referenced in this document outside of the context of an XML
   fragment, the string "IS:" will be prefixed to the element type
   names.

   Note that the XML declarations used in this document are incomplete,
   in that they do not include namespace information.  Thus, the reader
   MUST NOT use these declarations as the only way to validate iSchedule
   XML element types.

2.  iSchedule Model

   The iSchedule design can be pictured as:







Daboo & Desruisseaux     Expires April 25, 2013                 [Page 6]


Internet-Draft                  iSchedule                   October 2012


   +----------+   +-----------+            +-----------+   +----------+
   | Calendar |   | Calendar  |            | Calendar  |   | Calendar |
   | Store    |   | Service   | iSchedule  | Service   |   | Store    |
   |  or      |-->|===========|----------->|===========|-->|  or      |
   | User     |   | iSchedule |            | iSchedule |   | User     |
   | Agent    |   | Sender    |            | Receiver  |   | Agent    |
   +----------+   +-----------+            +-----------+   +----------+
                       |                          |
                       <-------------------------->
                        DKIM Signature/Verification

   When an iSchedule Sender has a scheduling message to transmit, it
   determines the iSchedule Receivers to which to deliver the message
   and sends the appropriate iSchedule message.  The iSchedule Receiver
   verifies the authenticity and content of the iSchedule message and
   delivers it to the Calendar Service.

   The means by which a Calendar Store or User Agent instructs a
   Calendar Service, acting as an iSchedule Sender, to transmit
   scheduling messages is outside the scope of this document.  A
   Calendar Service could provide support for a standard calendar access
   protocol, such as CalDAV [RFC4791], [RFC6638] or any other protocol,
   to allow a Calendar User Agent to perform scheduling operations with
   users of other Calendar Services.

   Likewise, the actual processing of scheduling messages received by a
   Calendar Service, acting as an iSchedule Receiver, is also outside
   the scope of this document.  Some Calendar Service implementations
   may decide to process some or all received scheduling messages, while
   other implementations may decide to leave that work to Calendar User
   Agent implementations.

3.  iSchedule Overview

   This section provides an overview of the various steps involved for
   iSchedule Senders and Receivers to transmit scheduling messages
   between Calendar Services.  It references later sections describing
   the precise details of each step.

3.1.  iSchedule Sender Actions

   A Calendar Service will generate an iTIP [RFC5546] scheduling message
   for transmission.  It will additionally provide details of the
   Originator and Recipients.  The Calendar Service will "submit" the
   scheduling message and details to the iSchedule Sender, through a
   process that is outside the scope of this document.

   The iSchedule Sender MUST verify the authenticity of the Originator



Daboo & Desruisseaux     Expires April 25, 2013                 [Page 7]


Internet-Draft                  iSchedule                   October 2012


   and the Originator's authorization to send the scheduling message.
   In particular the "ORGANIZER" iCalendar property value MUST match the
   Originator calendar user address.  The process by which this
   authentication and authorization is done is outside the scope of this
   document.

   For each Recipient, the iSchedule Sender will attempt to lookup a
   matching iSchedule Receiver to which the iSchedule message can be
   sent, following the rules in Section 4.  After determining the
   iSchedule Receiver to use, the iSchedule Sender MUST check the
   capabilities of the iSchedule Receiver to ensure it will be able to
   accept the scheduling message that needs to be sent, as per
   Section 5.

   The iSchedule Sender MUST group together Recipients for whom the
   iSchedule Receiver is the same, so that a single scheduling message
   is sent for multiple Recipients, within the limits of the IS:max-
   recipients (Section 9.2.1.9) value specified in the iSchedule
   Receiver's capabilities.

   For each group of Recipients handled by the same iSchedule Receiver,
   the iSchedule Sender will construct an HTTP request, as per
   Section 6, with the body of the HTTP request containing the iSchedule
   message.  Note, in the case of a "VFREEBUSY" iSchedule message, the
   sender MUST ensure that iCalendar "ATTENDEE" properties in the
   iSchedule message match one-for-one with the Recipients listed in the
   HTTP request header.

   After constructing the HTTP request, the iSchedule Sender MUST
   generate a DKIM signature for the request and include a "DKIM-
   Signature" (Section 8.1) request header, as per Section 7.

   The iSchedule Sender then sends the HTTP request to the iSchedule
   Receiver handling the Recipient group, and receives the HTTP
   response, which will be an XML document with either an IS:schedule-
   response or IS:error element as the root element.

   The iSchedule Sender aggregates the results for each Recipient group
   receiving an iSchedule message, and returns the resulting status
   information for each Recipient to the Calendar Service that generated
   the schedule message.  The process by which this is done is outside
   the scope of this document.

3.2.  iSchedule Receiver Actions

   iSchedule Receivers MUST provide a capabilities document to Senders,
   as per Section 5.




Daboo & Desruisseaux     Expires April 25, 2013                 [Page 8]


Internet-Draft                  iSchedule                   October 2012


   Upon receipt of an iSchedule HTTP request, the iSchedule Receiver
   verifies the message as per Section 7.4.

   Once the authenticity of the message is confirmed, the iSchedule
   Receiver deliverers the scheduling message to the indicated
   recipients, collects and aggregates the delivery status for each
   recipient, and returns the result in the HTTP response body.

   In the event of a processing error related to the overal request,
   iSchedule Receivers MUST return an error response as per
   Section 6.1.2.

4.  iSchedule Receiver Discovery

   This section describes how an iSchedule Sender can discover the host
   name, port, and the path to use to submit an HTTP request to an
   iSchedule Receiver.

   For each Recipient to whom a scheduling message is being sent, the
   iSchedule Sender will "resolve" the associated calendar user address
   into a domain name, as per Section 4.1.

   The iSchedule Sender then uses the extracted domain name to issue a
   DNS SRV query for the iSchedule service (Section 4.2) expected to be
   hosted at the domain.

   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.  Clients
   MUST use the path specified in any TXT records accompanying the SRV
   record (as per Section 4.3), or in the absence of a matching TXT
   record, MUST use the .well-known URI (as per Section 4.4).

4.1.  Resolving Calendar User Addresses

   To deliver a scheduling message via the iSchedule protocol, an
   iSchedule Sender needs to determine which iSchedule Receiver 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.




Daboo & Desruisseaux     Expires April 25, 2013                 [Page 9]


Internet-Draft                  iSchedule                   October 2012


   A calendar user address as defined by iCalendar is simply a URI.
   This is typically a mailto URI, but could potentially be any URI
   type.  However, only URIs containing a "host" element can be used to
   extract the necessary information to locate an iSchedule server.

   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

   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 query using the
   domain "host.calendar.example.com", then if that failed, the domain
   "calendar.example.com" would be tried, then if that failed the domain
   "example.com" would be tried.

4.2.  iSchedule SRV Service Types

   This specification adds two SRV service labels for use with
   iSchedule:

   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

   _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.








Daboo & Desruisseaux     Expires April 25, 2013                [Page 10]


Internet-Draft                  iSchedule                   October 2012


4.3.  iSchedule Service TXT Records

   When SRV RRs are used to advertise iSchedule services, it is also
   convenient to be able to specify a "context path" in the DNS to be
   retrieved at the same time.  To enable that, this specification uses
   a TXT RR that follows the syntax defined in Section 6 of and defines
   a "path" key for use in that record.  The value of the key MUST be
   the actual "context path" to the corresponding service on the server.

   A site might provide TXT records in addition to SRV records for the
   service.  When present, clients MUST use the "path" value as the
   "context path" for the service in HTTP requests.  When not present,
   clients use the ".well-known" URI approach described next.

   Example: text record for service with TLS

   _ischedules._tcp    TXT path=/ischedule

4.4.  iSchedule Receiver Request-URI

   This specification registers a well-known URI [RFC5785] for the
   iSchedule service, namely, "ischedule" (see Section 11.3.1).
   iSchedule Receivers MUST support requests targeted at this well-known
   URI. iSchedule Senders MUST handle HTTP redirects on this well-known
   URI.

5.  iSchedule Receiver Capabilities

   iSchedule Receivers supporting the features described in this
   document MUST allow iSchedule Senders to query their capabilities by
   accepting GET requests targeted at the Request-URI found during
   discovery (Section 4).  The response body for a successful GET
   request targeted at this URI MUST be an XML document with IS:query-
   result as its root element.

      Informative rationale: The GET method was favored over the POST
      method to allow iSchedule Senders to query capabilities with
      "conditional GET" requests (see Section 9.3 of [RFC2616]).

   iSchedule Receivers SHOULD include an "Expires" entity-header field
   in the response to a capabilities request, and iSchedule Senders MUST
   use the header value for caching the capabilities information.  In
   the absence of an "Expires" header, iSchedule Senders MAY cache the
   results of a capabilities query for at most 1 day. iSchedule Senders
   SHOULD use normal HTTP conditional GET requests when re-checking
   capabilities to avoid re-transferring already cached data.

   iSchedule Senders SHOULD use the information in the capabilities to



Daboo & Desruisseaux     Expires April 25, 2013                [Page 11]


Internet-Draft                  iSchedule                   October 2012


   determine whether the iSchedule Receiver supports a version of the
   protocol that the iSchedule Sender can use, and if not, not issue any
   iSchedule requests with scheduling messages to the iSchedule
   Receiver. iSchedule Senders SHOULD verify that the scheduling message
   to be sent to the iSchedule Receiver matches is in line with the
   restrictions on scheduling messages indicated by the capabilities
   before sending the scheduling message.

5.1.  Example: Querying iSchedule Receiver Capabilities

   >> Request <<

   GET /.well-known/ischedule?action=capabilities HTTP/1.1
   Host: cal.example.com





































Daboo & Desruisseaux     Expires April 25, 2013                [Page 12]


Internet-Draft                  iSchedule                   October 2012


   >> 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">
     <capabilities>
       <versions>
         <version>1.0</version>
       </versions>
       <scheduling-messages>
         <component name="VEVENT">
           <method name="REQUEST"/>
           <method name="ADD"/>
           <method name="REPLY"/>
           <method name="CANCEL"/>
         </component>
         <component name="VTODO"/>
         <component name="VFREEBUSY"/>
       </scheduling-messages>
       <calendar-data-types>
         <calendar-data-type
          content-type="text/calendar" version="2.0"/>
       </calendar-data-types>
       <attachments>
         <inline/>
         <external/>
       </attachments>
       <max-content-length>102400</max-content-length>
       <min-date-time>19910101T000000Z</min-date-time>
       <max-date-time>20381231T000000Z</max-date-time>
       <max-instances>150</max-instances>
       <max-recipients>250</max-recipients>
       <administrator>mailto:ischedule-admin@example.com<
       /administrator>
     </capabilities>
   </query-result>

6.  Scheduling

   This section defines how an iSchedule Sender can use the HTTP POST
   method to submit a scheduling message to an iSchedule Receiver.
   Note, this describes the HTTP request prior to generating a DKIM



Daboo & Desruisseaux     Expires April 25, 2013                [Page 13]


Internet-Draft                  iSchedule                   October 2012


   signature as per Section 7.

6.1.  POST Method

   The POST method submits a scheduling message to one or more
   Recipients by targeting the request at the Request-URI of an
   iSchedule Receiver.  The request body of an POST method MUST contain
   a scheduling message (i.e., an iCalendar object that follows the iTIP
   semantic).

   The submitted scheduling message will be delivered to the Recipients,
   with status information about per-recipient delivery returned in the
   HTTP response.  However, when the scheduling message contains is a
   request for free-busy time, the iSchedule Receiver will immediately
   execute the free-busy request for the Recipients and return per-
   recipient iCalendar data in the response for successful free-busy
   queries.

   Every POST request MUST include the "iSchedule-Version"
   (Section 11.2.2) general header.

   Every POST request SHOULD include the "iSchedule-Message-ID"
   (Section 11.2.3) request header.

   Every POST request MUST include the "Cache-Control" HTTP general
   header containing the cache-directive "no-cache" and "no-transform"
   to prevent intermediary caches from caching or transforming
   responses.

   Every POST request MUST include a single "Originator"
   (Section 11.2.4) 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" iCalendar property or one of the specified "ATTENDEE"
   iCalendar properties in the scheduling message, depending on the
   specified "METHOD" iCalendar property value as summarized in the
   following table:














Daboo & Desruisseaux     Expires April 25, 2013                [Page 14]


Internet-Draft                  iSchedule                   October 2012


          +----------------+-----------------------------------+
          | Method         | Originator Requirement            |
          +----------------+-----------------------------------+
          | PUBLISH        | MUST match ORGANIZER              |
          | REQUEST        | MUST match ORGANIZER (see Note 1) |
          | REPLY          | MUST match ATTENDEE               |
          | ADD            | MUST match ORGANIZER              |
          | CANCEL         | MUST match ORGANIZER              |
          | REFRESH        | MUST match ATTENDEE               |
          | COUNTER        | MUST match ATTENDEE               |
          | DECLINECOUNTER | MUST match ORGANIZER              |
          +----------------+-----------------------------------+

                                  Table 1

   Note 1: iTIP does allow an Attendee to forward a "METHOD:REQUEST"
   scheduling message to another attendee.  However, due to complexity
   of managing the authorization of such requests, this specification
   does not allow scheduling message forwarding.

   Every POST request MUST include one or more "Recipient"
   (Section 11.2.5) request headers.  The value of this header is a list
   of one or more calendar user addresses and corresponds to the set of
   calendar users who will have the scheduling message delivered to
   them.  The value of the "Recipient" request header MUST match the
   value of the "ORGANIZER" iCalendar property or one of the specified
   "ATTENDEE" iCalendar properties in the scheduling message, depending
   on the specified "METHOD" iCalendar property value as summarized in
   the following table:

           +----------------+----------------------------------+
           | Method         | Recipient Requirement            |
           +----------------+----------------------------------+
           | PUBLISH        | None (see Note 1)                |
           | REQUEST        | MUST match ATTENDEE (see Note 1) |
           | REPLY          | MUST match ORGANIZER             |
           | ADD            | MUST match ATTENDEE (see Note 1) |
           | CANCEL         | MUST match ATTENDEE (see Note 1) |
           | REFRESH        | MUST match ORGANIZER             |
           | COUNTER        | MUST match ORGANIZER             |
           | DECLINECOUNTER | MUST match ATTENDEE              |
           +----------------+----------------------------------+

                                  Table 2

   Note 1: iTIP does allow an Organizer to send scheduling message to
   calendar users who are not listed as Attendees, e.g., to inform other
   calendar users of an event taking place.  However, due to complexity



Daboo & Desruisseaux     Expires April 25, 2013                [Page 15]


Internet-Draft                  iSchedule                   October 2012


   of managing the authorization of such requests, this specification
   does not allow such scheduling messages.

   The Content-Type general header MUST include the type parameters
   "component" and "method" defined in [RFC5545].  The value of the
   "component" MUST correspond to the iCalendar component type (e.g.,
   "VEVENT") specified in the scheduling message.  The value of the
   "method" parameter MUST be the same as the value of the "METHOD"
   iCalendar property in the scheduling message.

6.1.1.  Schedule Response

   A POST request may deliver a scheduling message to one or more
   calendar users specified in the Recipient request header.  Since the
   behavior of each recipient may vary, it is useful to get response
   status information for each recipient in the overall POST response.
   This specification defines a new XML response to convey multiple
   recipient status.

   A response to a POST method that indicates status for one or more
   recipients MUST be 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.

   Every POST response MUST include the "Cache-Control" HTTP general
   header containing the cache-directive "no-cache" and "no-transform"
   to prevent intermediary caches from caching or transforming
   responses.

6.1.2.  Failed Schedule Response

   When there is an overall, as opposed to per-recipient, failure of the
   POST request, the server SHOULD return an XML document containing IS:
   error element as its root element.  The child elements of the IS:
   error element are used to indicate an error code and description,
   primarily meant for service administrators.

   The following XML elements are error codes which can be used within
   an IS:error element to represent errors:




Daboo & Desruisseaux     Expires April 25, 2013                [Page 16]


Internet-Draft                  iSchedule                   October 2012


      IS:version-not-supported: The POST request was either missing an
      "iSchedule-Version" header, or had an "iSchedule-Version" header
      value for a version not supported by the iSchedule Receiver, as
      advertised in the IS:versions capability.

      IS:invalid-calendar-data-type: The resource submitted in the POST
      request was not a supported media type (i.e. text/calendar) for
      scheduling or free-busy messages;

      IS:invalid-calendar-data: The resource submitted in the POST
      request was not valid data for the media type being specified;

      IS:invalid-scheduling-message: The resource submitted in the POST
      request did not obey all restrictions specified for the POST
      request, violating the IS:scheduling-message capability element,
      or the requirements of iTIP;

      IS:verification-failed: The POST request failed DKIM verification;

      IS:originator-missing: The POST request did not include an
      "Originator" request header specifying the calendar user address
      of the Originator of the scheduling message.

      IS:originator-invalid: The "Originator" header in the POST request
      did not include a valid calendar user address for the Originator
      of the scheduling message.

      IS:originator-denied: The calendar user identified by the
      "Originator" header in the POST request is not allowed to use this
      service.

      IS:recipient-missing: The POST request did not include one or more
      valid "Recipient" request headers specifying the calendar user
      address of users to whom the scheduling message will be delivered.

      IS:max-recipients: The POST request had too many calendar user
      addresses specified in "Recipient" request headers, violating the
      IS:max-recipients capability.

      IS:attachment-type-not-supported: The scheduling message submitted
      in the POST request had iCalendar data with "ATTACH" properties
      whose value type is not supported, violating the IS:attachments
      capability.

      IS:max-content-length: The scheduling message submitted in the
      POST request had iCalendar data violating the IS:min-data-time
      capability.




Daboo & Desruisseaux     Expires April 25, 2013                [Page 17]


Internet-Draft                  iSchedule                   October 2012


      IS:min-date-time: The scheduling message submitted in the POST
      request had iCalendar data violating the IS:min-data-time
      capability.

      IS:max-date-time: The scheduling message submitted in the POST
      request had iCalendar data violating the IS:max-date-time
      capability.

      IS:max-instances: The scheduling message submitted in the POST
      request had iCalendar data violating the IS:max-instances
      capability.

   The following are examples of response codes one would expect to be
   used for this method.  Note, however, that unless explicitly
   prohibited any 2/3/4/5xx series response code may be used in a
   response.  Typically a 403 response code would be used when an XML
   document with an IS:error element as its root is also returned.

      200 (OK) - The command succeeded.

      400 (Bad Request) - The Sender has provided an invalid scheduling
      message, or invalid iSchedule request headers.

      403 (Forbidden) - The Sender cannot submit a scheduling message to
      the specified Request-URI.

      404 (Not Found) - The URL in the Request-URI was not present.

      507 (Insufficient Storage) - The server did not have sufficient
      space to record the scheduling message.

7.  iSchedule Domain-Level Authentication

   iSchedule uses and extends the mechanism defined by DomainKeys
   Identified Mail (DKIM) [RFC6376].  DKIM defines a domain-level
   digital signature authentication framework for email, using public-
   key cryptography, with the domain name service (DNS) as one possible
   key server technology.

   This specification extends the applicability of DKIM to the HTTP
   protocol, with a specific "profile" for use with iSchedule messages.
   Additionally, DKIM support is REQUIRED for all iSchedule requests,
   and iSchedule receivers MUST reject any messages which cannot be
   verified according to the requirements of DKIM.  This is a much
   stronger requirement than the email use of DKIM, which has to deal
   with legacy systems.

   iSchedule senders MUST only send iSchedule messages for Originators



Daboo & Desruisseaux     Expires April 25, 2013                [Page 18]


Internet-Draft                  iSchedule                   October 2012


   whose authenticity has been verified by the sender. iSchedule
   receivers that verify a DKIM signature on an iSchedule request can
   assume that the iSchedule sender is not only taking responsibility
   for sending the message, but has also verified the authenticity of
   the Originator.  As such, iSchedule receivers can reliably use the
   Originator information to perform their own authorization based on
   that value. e.g., the Calendar Service to which an iScheduler
   receiver delivers a scheduling message, can apply "filtering" rules
   to such messages based on the guarantee that the Originator calendar
   user address has been verified at both the sender and receiver ends.

   This specification uses the syntactic elements of DKIM [RFC6376], but
   modified for use with HTTP.  Where definitions of syntactic elements
   of DKIM [RFC6376] are applicable to HTTP, they will be used by
   reference.  In cases where the HTTP definition is different, the same
   ABNF rule name will be used, but the value modified as appropriate.

   The following sections 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  iSchedule-Version

   o  Originator

   o  Recipient

   The iSchedule sender MUST include an extra "Recipient" header field
   name in the "DKIM-Signature" header's "h" tag to ensure that no
   additional "Recipient" headers can be added to the request, as per
   Section 5.4.2 of DKIM [RFC6376].  The iSchedule receiver MUST verify
   that the above HTTP headers are included in the signature, and that
   the correct number of "Recipient" headers have been signed.

   iScheduler senders and receivers might use HTTP authentication
   [RFC2617] in requests, though the process through which credentials
   are managed are out of scope for this document.  If HTTP
   authentication is used, then the "Authorization" HTTP request header
   MUST be included in the signature of the message.




Daboo & Desruisseaux     Expires April 25, 2013                [Page 19]


Internet-Draft                  iSchedule                   October 2012


   The following HTTP headers, if present, SHOULD be included in the
   signature of a message:

   o  iSchedule-Message-ID

   o  User-Agent

   To allow iSchedule messages to transit via HTTP intermediaries, hop-
   by-hop headers, such as the following HTTP/1.1 headers MUST NOT be
   included in the signature of a message:

   o  Cache-Control

   o  Connection

   o  Host

   o  Keep-Alive

   o  Proxy-Authenticate

   o  Proxy-Authorization

   o  TE

   o  Trailer

   o  Transfer-Encoding

   o  Upgrade

   The "Content-Length" header MUST NOT be signed, since the DKIM
   signature is generated prior to transfer encoding, and the header
   value represents the length after any transfer encodings have been
   applied.

   iScheduler Senders MAY include an "x=" DKIM signature tag in the
   "DKSIM-Signature" header to indicate an expiration time for the
   signature.  When doing so, the "x=" value SHOULD be set to at least 1
   minute ahead of the "t=" DKIM signature tag value, to account for
   processing time between the sender and receiver.

7.2.  Canonicalization

   iSchedule senders and receivers MUST use the "relaxed" header
   canonicalization algorithm defined in Section 3.4.2 of DKIM [RFC6376]
   to canonicalize the HTTP request headers used for the signature
   computation.



Daboo & Desruisseaux     Expires April 25, 2013                [Page 20]


Internet-Draft                  iSchedule                   October 2012


   iSchedule senders and receivers MUST use the "simple" body
   canonicalization algorithm defined in Section 3.4.3 of DKIM [RFC6376]
   to canonicalize the HTTP request message body used for the body hash
   computation.  The iSchedule sender MUST calculate the body hash prior
   to any HTTP transfer encodings being applied to the request message
   body.  The iSchedule receiver MUST calculate the body hash after any
   HTTP transfer encoding has been removed from the request message
   body.

7.3.  Key Management

7.3.1.  DNS-based Public Key Management

   Section 3.6.2 of DKIM [RFC6376] defines a DNS-based key-binding for
   public key retrieval. iSchedule Senders and Receivers MUST support
   this method of public key retrieval.  To allow public keys to be
   restricted to just an iSchedule service, this specification defines a
   new service type "ischedule" to constrain the use of a key to
   iSchedule:

      ABNF:



   key-s-tag-type /= "ischedule"

7.3.2.  HTTP-based Public Key Management

   This specification defines a new HTTP-based public key management
   method for use with DKIM [RFC6376].  The "DKIM-Signature" header "q"
   tag value associated with this method is "http/well-known":

      ABNF:



   sig-q-tag-method /= "http/well-known"

   Key lookup first involves retrieving an SRV record that will provide
   the HTTP server host name and port to use for actual key retrieval.
   Then the key retrieval is done via an HTTP request on a .well-known
   resource.  This new key management approach off-loads the key
   handling from DNS to an HTTP server, only requiring the DNS
   administrator to provide the SRV records for authorized HTTP key
   management servers.






Daboo & Desruisseaux     Expires April 25, 2013                [Page 21]


Internet-Draft                  iSchedule                   October 2012


7.3.2.1.  SRV Service Type

   This specification adds one SRV service label for use with HTTP key
   management:

   domainkey_lookup:  Identifies an HTTP server from which public keys
      for DKIM signatures can be retrieved.  The HTTP server MUST
      support transport layer security ([RFC2818]).

   The iScheduler Receiver determines the appropriate SRV name using the
   "d=" DKIM signature tag value in the "DKIM-signature" header being
   verified:

   _domainkey_lookup._tcp.{d}.

   ; {d} is the d= value from the "DKIM-Signature" header.

7.3.2.2.  Well-known Request-URI

   This specification registers a well-known URI [RFC5785] for the DKIM
   HTTP-based public key management information, "domainkey" (see
   Section 11.3.2).  To retrieve information about the public key used
   to sign an iSchedule message, the iSchedule Sender constructs a URI
   of the form:

   https://{srv-host}:{srv-port}/.well-known/domainkey/{d}/{s}

   ; {srv-host} is the host name from the _domainkey_lookup SRV record
   ; {srv-port} is the port number from the _domainkey_lookup SRV record
   ; {d} is the d= value from the "DKIM-Signature" header.
   ; {s} is the s= value from the "DKIM-Signature" header.

   Documents retrieved from the well-known URI MUST be text documents
   with a media-type of "text/plain".  The format of the text document
   is:

   key-doc = 1*(tag-list CRLF)
   ; tag-list is defined in Section 3.2 of <xref target="RFC6376"/>

   where tag-list is the unstructured textual form defined in Section
   3.6.1. of [RFC6376] - i.e., the same data that would be placed in a
   DNS TXT record for DNS-based public key management.  Note that this
   allows information for multiple keys to be returned for each {domain-
   name}, {selector} pair. iSchedule Receivers must use HTTP+TLS
   (https:) to retrieve the public key information document, and follow
   the certificate-verification process specified in [RFC6125].





Daboo & Desruisseaux     Expires April 25, 2013                [Page 22]


Internet-Draft                  iSchedule                   October 2012


7.3.2.3.  Example Lookup Procedure

   Given the following (partial) DKIM-Signature header, the steps below
   describe how a public key is retrieved from the HTTP pubic key
   management system.

   DKIM-Signature:q=http/well-known;d=cal.example.com;s=isched; ...

   1.  The iSchedule Receiver first does an SRV record lookup for
       "_domainkey_lookup._tcp.calendar.example.com", and gets back the
       following example record:

  _domainkey_lookup._tcp.cal.example.com. IN SRV 0 1 443 is.example.com.

   2.  the iSchedule Receiver then makes an HTTP request:

 https://is.example.com:443/.well-known/domainkey/cal.example.com/isched

   3.  It parses the returned document to determine the appropriate
       public key to use to verify the DKIM signature.

7.3.3.  Private Exchange Public Key Management

   This specification defines a new public key management method for use
   with DKIM [RFC6376].  This method is used to indicate that the
   associated public key has been transferred to the recipient through
   some (unspecified, secure) private exchange.  The "DKIM-Signature"
   header "q" tag value associated with this method is "private-
   exchange":

      ABNF:



   sig-q-tag-method /= "private-exchange"

   This method is useful, for example, in situations where an "internal"
   deployment of iSchedule is being used to connect different calendar
   systems within an organization.  It avoids the need to setup other
   public key discovery mechanisms when a simple, secure public key
   exchange can be accomplished between the system administrators.

7.4.  Verification Requirements

   iSchedule Receivers MUST verify the follow details:

      The HTTP request contains an "iSchedule-Version" header that
      matches a version of the iSchedule protocol that the receiver



Daboo & Desruisseaux     Expires April 25, 2013                [Page 23]


Internet-Draft                  iSchedule                   October 2012


      supports.

      Only one Originator HTTP request header is present in the request
      and it matches the appropriate iCalendar property as per Table 1.

      One or more Recipient HTTP request headers are present in the
      request and they match the appropriate iCalendar properties as per
      Table 2.

      The "DKIM-Signature" header contains valid information and the
      signature and body hash values can be verified correctly.  Note,
      for the t= value in the "DKIM-Signature", receivers SHOULD accept
      values that are no more than 5 minutes in the future, to account
      for possible clock skew between sender and receiver.

7.5.  Authorized Third-Party Signatures

   The third-party signature authorization protocol defined in [RFC6541]
   MAY be used by iSchedule Senders and Receivers.

8.  HTTP Headers

   This section defines the syntax and semantics of additional HTTP/1.1
   header fields.

   The header's syntax uses the optional whitespace (OWS) rule defined
   as follows:

      OWS = *( [ CRLF ] WSP )

8.1.  DKIM-Signature Request Header

   The "DKIM-Signature" request header MUST be specified by the
   iSchedule Sender on all scheduling requests to specify all of the
   signature and key-fetching data.

      DKIM-Signature   = "DKIM-Signature" ":" OWS DKIM-Signature-v
      DKIM-Signature-v = tag-list
      ; tag-list is defined in Section 3.2 of <xref target="RFC6376"/>

8.2.  iSchedule-Version General Header

   The "iSchedule-Version" general header field MUST be specified by the
   iSchedule Sender on requests, and by the iSchedule Receiver on
   responses.  It SHOULD be included in a response to any "OPTIONS *"
   HTTP request targeting the iScheduler Receiver, or any "OPTIONS"
   request on a resource supporting the iSchedule behaviors described in
   this specification (e.g., the .well-known resource or any resource



Daboo & Desruisseaux     Expires April 25, 2013                [Page 24]


Internet-Draft                  iSchedule                   October 2012


   that .well-known redirects to).

      iSchedule-Version      = "iSchedule-Version" ":" OWS
                               iSchedule-Version-v
      iSchedule-Version-v    = iSchedule-Version-elem
                               *( OWS "," OWS iSchedule-Version-elem )
      iSchedule-Version-elem =  1*DIGIT "." 1*DIGIT

8.3.  iSchedule-Message-ID Request Header

   The "iSchedule-Message-ID" request header field SHOULD be specified
   by the iSchedule Sender on requests.  This header provides a unique
   identifier that refers to the specific iSchedule request in which it
   is included.  The uniqueness of this identifier is guaranteed by the
   iSchedule Sender that generates it.  This identifier is intended to
   be machine readable and not necessarily meaningful to humans.

      iSchedule-Message-ID   = "iSchedule-Message-ID" ":" OWS token

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

9.1.  schedule-response XML Element

   Name:  schedule-response







Daboo & Desruisseaux     Expires April 25, 2013                [Page 25]


Internet-Draft                  iSchedule                   October 2012


   Namespace:  urn:ietf:params:xml:ns:ischedule

   Purpose:  Contains the set of responses for a POST method request.

   Description:  See Section 6.1.1.

   Definition:

   <!ELEMENT schedule-response (response*)>

9.1.1.  response XML Element

   Name:  response

   Namespace:  urn:ietf:params:xml:ns:ischedule

   Purpose:  Contains a single response for a POST method request.

   Description:  See Section 6.1.1.

   Definition:

   <!ELEMENT response (recipient,
                      request-status,
                      calendar-data?,
                      error?,
                      response-description?)>

9.1.1.1.  recipient XML Element

   Name:  recipient

   Namespace:  urn:ietf:params:xml:ns:ischedule

   Purpose:  The calendar user address (recipient header value) that the
      enclosing response for a POST method request is for.

   Description:  See Section 6.1.1.

   Definition:

   <!ELEMENT recipient (#PCDATA)>

9.1.1.2.  request-status XML Element







Daboo & Desruisseaux     Expires April 25, 2013                [Page 26]


Internet-Draft                  iSchedule                   October 2012


   Name:  request-status

   Namespace:  urn:ietf:params:xml:ns:ischedule

   Purpose:  The iTIP REQUEST-STATUS property value for this response.

   Description:  See Section 6.1.1.

   Definition:

   <!ELEMENT request-status (#PCDATA)>

9.1.1.3.  calendar-data XML Element

   Name:  calendar-data

   Namespace:  urn:ietf:params:xml:ns:ischedule

   Purpose:  An iCalendar object in a response to a search for busy time
      information.

   Description:  See Section 6.1.1.

   Definition:

   <!ELEMENT calendar-data (#PCDATA)>

9.1.1.4.  error XML Element

   Name:  error

   Namespace:  urn:ietf:params:xml:ns:ischedule

   Purpose:  Error responses sometimes need more information to indicate
      what went wrong.

   Description:  See Section 6.1.1.

   Definition:

   <!ELEMENT error ANY>

9.1.1.5.  response-description XML Element








Daboo & Desruisseaux     Expires April 25, 2013                [Page 27]


Internet-Draft                  iSchedule                   October 2012


   Name:  response-description

   Namespace:  urn:ietf:params:xml:ns:ischedule

   Purpose:  Contains information about a status response

   Description:  See Section 6.1.1.

   Definition:

   <!ELEMENT response-description (#PCDATA)>

9.2.  query-result XML Element

   Name:  query-result

   Namespace:  urn:ietf:params:xml:ns:ischedule

   Purpose:  Contains result of a query request.

   Description:  A generic container for the result of a query request,
      such as a query of the capabilities of an iSchedule Receiver.

   Definition:

   <!ELEMENT query-result (capabilities)>

9.2.1.  capabilities XML Element

   Name:  capabilities

   Namespace:  urn:ietf:params:xml:ns:ischedule

   Purpose:  Contains iSchedule Receiver capabilities.

   Description:  The capabilities element contains capabilities of the
      iSchedule Receiver.

   Definition:












Daboo & Desruisseaux     Expires April 25, 2013                [Page 28]


Internet-Draft                  iSchedule                   October 2012


   <!ELEMENT capabilities (versions,
                           scheduling-messages,
                           calendar-data-types,
                           attachments,
                           max-content-length,
                           min-date-time,
                           max-date-time,
                           max-instances,
                           max-recipients,
                           administrator) >

9.2.1.1.  versions XML Element

   Name:  versions

   Namespace:  urn:ietf:params:xml:ns:ischedule

   Purpose:  Identifies the iSchedule versions supported by the
      iSchedule Receiver.

   Description:  An iSchedule Receiver MAY advertise support for
      multiple versions of the iSchedule protocol.

   Definition:

   <!ELEMENT versions (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.  scheduling-messages XML Element

   Name:  scheduling-messages

   Namespace:  urn:ietf:params:xml:ns:ischedule






Daboo & Desruisseaux     Expires April 25, 2013                [Page 29]


Internet-Draft                  iSchedule                   October 2012


   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 scheduling-messages (component)+>

9.2.1.2.1.  component XML Element

   Name:  component

   Namespace:  urn:ietf:params:xml:ns:ischedule

   Purpose:  Identifies a calendar component type.

   Description:

   Definition:

   <!ELEMENT component (method)*>

   <!ATTLIST component 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>

   <!ATTLIST method name CDATA #REQUIRED>
   <!-- name value: a method type -->








Daboo & Desruisseaux     Expires April 25, 2013                [Page 30]


Internet-Draft                  iSchedule                   October 2012


9.2.1.3.  calendar-data-types XML Element

   Name:  calendar-data-types

   Namespace:  urn:ietf:params:xml:ns:ischedule

   Purpose:

   Description:

   Definition:

   <!ELEMENT calendar-data-types (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.  attachments XML Element

   Name:  attachments

   Namespace:  urn:ietf:params:xml:ns:ischedule

   Purpose:  Identifies the attachment values supported.

   Description:

   Definition:

   <!ELEMENT attachments (inline?, external?)>





Daboo & Desruisseaux     Expires April 25, 2013                [Page 31]


Internet-Draft                  iSchedule                   October 2012


9.2.1.4.1.  inline XML Element

   Name:  inline

   Namespace:  urn:ietf:params:xml:ns:ischedule

   Purpose:  Specifies inline attachment as a supported attachment
      value.

   Description:

   Definition:

   <!ELEMENT inline EMPTY>

9.2.1.4.2.  external XML Element

   Name:  external

   Namespace:  urn:ietf:params:xml:ns:ischedule

   Purpose:  Specifies external attachment as a supported attachment
      value.

   Description:

   Definition:

   <!ELEMENT external EMPTY>

9.2.1.5.  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) -->






Daboo & Desruisseaux     Expires April 25, 2013                [Page 32]


Internet-Draft                  iSchedule                   October 2012


9.2.1.6.  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:

   Definition:

   <!ELEMENT min-date-time (#PCDATA)>
   <!-- PCDATA value: an iCalendar format DATE-TIME value in UTC -->

9.2.1.7.  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.8.  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 April 25, 2013                [Page 33]


Internet-Draft                  iSchedule                   October 2012


   Definition:

   <!ELEMENT max-instances (#PCDATA)>
   <!-- PCDATA value: a numeric value (positive integer) -->

9.2.1.9.  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.10.  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
   [RFC6376] are also applicable to iSchedule.





Daboo & Desruisseaux     Expires April 25, 2013                [Page 34]


Internet-Draft                  iSchedule                   October 2012


10.1.  Privacy

   iSchedule Senders and iSchedule Receivers MUST use an HTTP connection
   protected with TLS [RFC5246] as defined in [RFC2818] for all
   transactions.

10.2.  Authentication

   iSchedule uses and extends the mechanism defined by DomainKeys
   Identified Mail (DKIM) [RFC6376].  DKIM defines a domain-level
   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

   Status: standard



Daboo & Desruisseaux     Expires April 25, 2013                [Page 35]


Internet-Draft                  iSchedule                   October 2012


   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-Message-ID Request Header Registration

   Header field name: iSchedule-Message-ID

   Applicable protocol: http

   Status: standard

   Author/Change controller: IETF

   Specification document(s): this specification

   Related information: none

11.2.4.  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




Daboo & Desruisseaux     Expires April 25, 2013                [Page 36]


Internet-Draft                  iSchedule                   October 2012


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 [RFC5785].

11.3.1.  iSchedule Well-Known URI Registration

   URI suffix: ischedule

   Change controller: IETF.

   Specification document(s): this specification

   Related information: none

11.3.2.  DKIM Well-Known URI Registration

   URI suffix: domainkey

   Change controller: IETF.

   Specification document(s): this specification

   Related information: none

11.4.  DKIM Parameters Registration

11.4.1.  DKIM-Signature Query Method Registry

   This specification registers two new query mechanisms that can be
   used in DKIM-Signature fields.  The following values should be added
   to the DKIM-Signature Query Method Registry established in Section
   7.3 of [RFC6376]:





Daboo & Desruisseaux     Expires April 25, 2013                [Page 37]


Internet-Draft                  iSchedule                   October 2012


   +------------------+------------+--------------------------+--------+
   | Type             | Option     | Reference                | Status |
   +------------------+------------+--------------------------+--------+
   | http             | well-known | (this document           | active |
   |                  |            | Section 7.3.2)           |        |
   | private-exchange |            | (this document           | active |
   |                  |            | Section 7.3.3)           |        |
   +------------------+------------+--------------------------+--------+

11.4.2.  DKIM Service Type Registration

   This specification registers a new DKIM service type to specify that
   a given public key MUST only be used to verify messages of iSchedule
   services.  The following value should be added to the DKIM Service
   Type Registry established in Section 7.8 of [RFC6376]:

          +-----------+-------------------------------+--------+
          | Type      | Reference                     | Status |
          +-----------+-------------------------------+--------+
          | ischedule | (this document Section 7.3.1) | active |
          +-----------+-------------------------------+--------+

12.  Acknowledgments

   The authors would like to thank the following individuals for
   contributing their ideas and support for writing this specification:
   Mattias Amnefelt, Mike Douglass, Tomas Hnetila, Ciny Joy, Barry
   Leiba, Ken Murchison, Simon Pilette, Arnaud Quillaud, Simon
   Vaillancourt, and Wilfredo Sanchez Vega.

   The authors would also like to thank CalConnect, The Calendaring and
   Scheduling Consortium, for advice with this specification, and for
   organizing interoperability testing events to help refine it.

13.  References

13.1.  Normative References

   [RFC2119]               Bradner, S., "Key words for use in RFCs to
                           Indicate Requirement Levels", BCP 14,
                           RFC 2119, March 1997.

   [RFC2616]               Fielding, R., Gettys, J., Mogul, J., Frystyk,
                           H., Masinter, L., Leach, P., and T. Berners-
                           Lee, "Hypertext Transfer Protocol --
                           HTTP/1.1", RFC 2616, June 1999.

   [RFC2617]               Franks, J., Hallam-Baker, P., Hostetler, J.,



Daboo & Desruisseaux     Expires April 25, 2013                [Page 38]


Internet-Draft                  iSchedule                   October 2012


                           Lawrence, S., Leach, P., Luotonen, A., and L.
                           Stewart, "HTTP Authentication: Basic and
                           Digest Access Authentication", RFC 2617,
                           June 1999.

   [RFC2782]               Gulbrandsen, A., Vixie, P., and L. Esibov, "A
                           DNS RR for specifying the location of
                           services (DNS SRV)", RFC 2782, February 2000.

   [RFC2818]               Rescorla, E., "HTTP Over TLS", RFC 2818,
                           May 2000.

   [RFC3688]               Mealling, M., "The IETF XML Registry",
                           BCP 81, RFC 3688, January 2004.

   [RFC3986]               Berners-Lee, T., Fielding, R., and L.
                           Masinter, "Uniform Resource Identifier (URI):
                           Generic Syntax", STD 66, RFC 3986,
                           January 2005.

   [RFC4033]               Arends, R., Austein, R., Larson, M., Massey,
                           D., and S. Rose, "DNS Security Introduction
                           and Requirements", RFC 4033, March 2005.

   [RFC5234]               Crocker, D. and P. Overell, "Augmented BNF
                           for Syntax Specifications: ABNF", STD 68,
                           RFC 5234, January 2008.

   [RFC5246]               Dierks, T. and E. Rescorla, "The Transport
                           Layer Security (TLS) Protocol Version 1.2",
                           RFC 5246, August 2008.

   [RFC5545]               Desruisseaux, B., "Internet Calendaring and
                           Scheduling Core Object Specification
                           (iCalendar)", RFC 5545, September 2009.

   [RFC5546]               Daboo, C., "iCalendar Transport-Independent
                           Interoperability Protocol (iTIP)", RFC 5546,
                           December 2009.

   [RFC5785]               Nottingham, M. and E. Hammer-Lahav, "Defining
                           Well-Known Uniform Resource Identifiers
                           (URIs)", RFC 5785, April 2010.

   [RFC6125]               Saint-Andre, P. and J. Hodges,
                           "Representation and Verification of Domain-
                           Based Application Service Identity within
                           Internet Public Key Infrastructure Using



Daboo & Desruisseaux     Expires April 25, 2013                [Page 39]


Internet-Draft                  iSchedule                   October 2012


                           X.509 (PKIX) Certificates in the Context of
                           Transport Layer Security (TLS)", RFC 6125,
                           March 2011.

   [RFC6376]               Crocker, D., Hansen, T., and M. Kucherawy,
                           "DomainKeys Identified Mail (DKIM)
                           Signatures", RFC 6376, September 2011.

   [W3C.REC-xml-20081126]  Yergeau, F., Paoli, J., Sperberg-McQueen, C.,
                           Maler, E., and T. Bray, "Extensible Markup
                           Language (XML) 1.0 (Fifth Edition)", World
                           Wide Web Consortium Recommendation REC-xml-
                           20081126, November 2008,
                           <http://www.w3.org/TR/2008/REC-xml-20081126>.

13.2.  Informative References

   [RFC3864]               Klyne, G., Nottingham, M., and J. Mogul,
                           "Registration Procedures for Message Header
                           Fields", BCP 90, RFC 3864, September 2004.

   [RFC4791]               Daboo, C., Desruisseaux, B., and L.
                           Dusseault, "Calendaring Extensions to WebDAV
                           (CalDAV)", RFC 4791, March 2007.

   [RFC5585]               Hansen, T., Crocker, D., and P. Hallam-Baker,
                           "DomainKeys Identified Mail (DKIM) Service
                           Overview", RFC 5585, July 2009.

   [RFC6047]               Melnikov, A., "iCalendar Message-Based
                           Interoperability Protocol (iMIP)", RFC 6047,
                           December 2010.

   [RFC6541]               Kucherawy, M., "DomainKeys Identified Mail
                           (DKIM) Authorized Third-Party Signatures",
                           RFC 6541, February 2012.

   [RFC6638]               Daboo, C. and B. Desruisseaux, "Scheduling
                           Extensions to CalDAV", RFC 6638, June 2012.

Appendix A.  Example Scheduling Transactions

   This section describes some example scheduling transactions that give
   a general idea of how scheduling is carried out between an iSchedule
   Sender and an iSchedule Receiver.






Daboo & Desruisseaux     Expires April 25, 2013                [Page 40]


Internet-Draft                  iSchedule                   October 2012


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.

   >> Request <<

   POST /.well-known/ischedule HTTP/1.1
   DKIM-Signature: a=rsa-sha256; d=example.com; s=jupiter;
    c=relaxed/simple; q=dns/txt:http/well-known;
    t=1268069852; x=1283918400;
    h=Originator:Recipient:Recipient:Host:Content-Type:
    iSchedule-Version:iSchedule-Message-ID;
    bh=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx;
    b=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx
   Host: cal.example.org
   iSchedule-Version: 1.0
   iSchedule-Message-ID: 798F00BB-5B45-4634-B083-0D0CD3A2BB39
   Originator: mailto:bernard@example.com
   Recipient: mailto:cyrus@example.org
   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 April 25, 2013                [Page 41]


Internet-Draft                  iSchedule                   October 2012


   >> 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>
     <response-description>Delivered to recipient</response-description>
   </response>
 </schedule-response>


A.2.  Example: Search for Busy Time Information

   In the following example, the iSchedule Sender requests the iSchedule
   Receiver to determine the busy information of the calendar 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 April 25, 2013                [Page 42]


Internet-Draft                  iSchedule                   October 2012


   >> Request <<

   POST /.well-known/ischedule HTTP/1.1
   DKIM-Signature: a=rsa-sha256; d=example.com; s=jupiter;
    c=relaxed/simple; q=dns/txt:http/well-known;
    t=1268069852; x=1283918400;
    h=Originator:Recipient:Recipient:Host:Content-Type:
    iSchedule-Version:iSchedule-Message-ID;
    bh=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx;
    b=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx
   Host: cal.example.org
   iSchedule-Version: 1.0
   iSchedule-Message-ID: A98ADF24-9490-4F01-81C8-FE924F86A9FD
   Originator: mailto:bernard@example.com
   Recipient: mailto:cyrus@example.org
   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 April 25, 2013                [Page 43]


Internet-Draft                  iSchedule                   October 2012


   >> 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: Failed Request

   In the following example, the iSchedule Sender requests the iSchedule
   Sender to deliver a task assignment (scheduling REQUEST) to the
   calendar user mailto:cyrus@example.org.  For some reason the
   verification of the request fails as is indicated by the error
   response.










Daboo & Desruisseaux     Expires April 25, 2013                [Page 44]


Internet-Draft                  iSchedule                   October 2012


   >> Request <<

   POST /.well-known/ischedule HTTP/1.1
   DKIM-Signature: a=rsa-sha256; d=example.com; s=jupiter;
    c=relaxed/simple; q=dns/txt:http/well-known;
    t=1268069852; x=1283918400;
    h=Originator:Recipient:Recipient:Host:Content-Type:
    iSchedule-Version:iSchedule-Message-ID;
    bh=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx;
    b=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx
   Host: cal.example.org
   iSchedule-Version: 1.0
   Originator: mailto:bernard@example.com
   Recipient: mailto:cyrus@example.org
   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


   >> Response <<

 HTTP/1.1 403 FORBIDDEN
 Date: Thu, 02 Sep 2004 16:53:32 GMT
 Content-Type: application/xml; charset=utf-8
 Content-Length: xxxx
 iSchedule-Version: 1.0

 <?xml version="1.0" encoding="utf-8" ?>
 <error xmlns="urn:ietf:params:xml:ns:ischedule">
   <verification-failed />
   <response-description>Unable to verify request</response-description>
 </error>




Daboo & Desruisseaux     Expires April 25, 2013                [Page 45]


Internet-Draft                  iSchedule                   October 2012


Appendix B.  Change Log (to be removed by RFC Editor prior to
             publication)

B.1.  Changes in -02

   a.  Major structural changes as well as addition of new sections,
       including an Overview.
   b.  Changed capabilities XML schema.
   c.  XML error elements are now named for the actual error as opposed
       to WebDAV style pre-conditions.
   d.  Removed intermediary support and iSchedule-Via header.
   e.  Added TXT path= lookup to accompany SRV lookup.
   f.  Added http/well-known public key lookup mechanism.
   g.  Added iSchedule-Message-ID header.
   h.  Provided suggested values for t= and x= to cope with clock skew
       and processing time issues.
   i.  Indicated that iSchedule-Version header can be returned in
       OPTIONS responses.
   j.  Clarified that Attendee list for VFREEBUSY has to be the same as
       the Recipient list.

B.2.  Changes in -01

   a.  Introduced use of DKIM for calendaring and scheduling services.
   b.  The XML elements "supported-calendar-data" and "calendar-data"
       were renamed to "supported-calendar-data-type" and "calendar-
       data-type" respectively to avoid confusion with the "calendar-
       data" XML element being used in the "response" XML element.
   c.  The "recipient" XML element was redefined to accept (#PCDATA)
       instead of an "href" XML element.
   d.  The grammar of new HTTP headers is now using the ABNF syntax
       defined in [RFC5234].
   e.  Fixed various typos.

Authors' Addresses

   Cyrus Daboo
   Apple Inc.
   1 Infinite Loop
   Cupertino, CA  95014
   USA

   EMail: cyrus@daboo.name
   URI:   http://www.apple.com/







Daboo & Desruisseaux     Expires April 25, 2013                [Page 46]


Internet-Draft                  iSchedule                   October 2012


   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 April 25, 2013                [Page 47]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/