idnits 2.17.1 draft-desruisseaux-ischedule-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4871, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4871, updated by this document, for RFC5378 checks: 2006-02-03) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2010) is 5162 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 4871 (Obsoleted by RFC 6376) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-12) exists of draft-desruisseaux-caldav-sched-08 == Outdated reference: A later version (-11) exists of draft-ietf-calsify-rfc2447bis-08 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Daboo 3 Internet-Draft Apple 4 Updates: 4871 (if approved) B. Desruisseaux 5 Intended status: Standards Track Oracle 6 Expires: September 9, 2010 March 8, 2010 8 Internet Calendar Scheduling Protocol (iSchedule) 9 draft-desruisseaux-ischedule-01 11 Abstract 13 This document defines the Internet Calendar Scheduling Protocol 14 (iSchedule), which is a binding from the iCalendar Transport- 15 independent Interoperability Protocol (iTIP) to the Hypertext 16 Transfer Protocol (HTTP) to enable interoperability between 17 calendaring and scheduling systems over the Internet. 19 Status of This Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on September 9, 2010. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . 5 62 1.3. Notational Conventions . . . . . . . . . . . . . . . . . . 5 63 2. iSchedule Model . . . . . . . . . . . . . . . . . . . . . . . 6 64 3. iSchedule Intermediaries . . . . . . . . . . . . . . . . . . . 7 65 4. iSchedule Receiver Discovery . . . . . . . . . . . . . . . . . 7 66 4.1. iSchedule SRV Service Types . . . . . . . . . . . . . . . 7 67 4.2. iSchedule Receiver Request-URI . . . . . . . . . . . . . . 8 68 4.3. Resolving Calendar User Addresses . . . . . . . . . . . . 8 69 4.4. Using the SRV Record Result . . . . . . . . . . . . . . . 9 70 5. iSchedule Receiver Capabilities . . . . . . . . . . . . . . . 9 71 5.1. Example: Querying iSchedule Receiver Capabilities . . . . 9 72 6. Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 6.1. POST Method . . . . . . . . . . . . . . . . . . . . . . . 11 74 6.1.1. Schedule Response . . . . . . . . . . . . . . . . . . 12 75 6.1.2. Status Codes for use with the POST method . . . . . . 13 76 7. iSchedule Domain-Level Authentication . . . . . . . . . . . . 13 77 7.1. Signature Content . . . . . . . . . . . . . . . . . . . . 13 78 7.2. Canonicalization . . . . . . . . . . . . . . . . . . . . . 14 79 7.2.1. The "simple-http" Header Canonicalization Algorithm . 14 80 7.2.2. The "simple-http" Body Canonicalization Algorithm . . 14 81 7.3. Key Management . . . . . . . . . . . . . . . . . . . . . . 14 82 7.4. Delegation of Signing Authority . . . . . . . . . . . . . 15 83 7.4.1. Publication of Procuration Record . . . . . . . . . . 15 84 7.4.2. Procuration Lookup Procedure . . . . . . . . . . . . . 15 85 8. HTTP Headers . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 8.1. DKIM-Signature Request Header . . . . . . . . . . . . . . 16 87 8.2. iSchedule-Version General Header . . . . . . . . . . . . . 16 88 8.3. iSchedule-Via General Header . . . . . . . . . . . . . . . 16 89 8.4. Originator Request Header . . . . . . . . . . . . . . . . 17 90 8.5. Recipient Request Header . . . . . . . . . . . . . . . . . 17 91 9. XML Element Definitions . . . . . . . . . . . . . . . . . . . 17 92 9.1. schedule-response XML Element . . . . . . . . . . . . . . 17 93 9.1.1. response XML Element . . . . . . . . . . . . . . . . . 18 94 9.1.1.1. recipient XML Element . . . . . . . . . . . . . . 18 95 9.1.1.2. request-status XML Element . . . . . . . . . . . . 18 96 9.1.1.3. calendar-data XML Element . . . . . . . . . . . . 19 97 9.1.1.4. error XML Element . . . . . . . . . . . . . . . . 19 98 9.1.1.5. responsedescription XML Element . . . . . . . . . 19 99 9.2. query-result XML Element . . . . . . . . . . . . . . . . . 20 100 9.2.1. capability-set XML Element . . . . . . . . . . . . . . 20 101 9.2.1.1. supported-version-set XML Element . . . . . . . . 21 102 9.2.1.2. supported-scheduling-message-set XML Element . . . 21 103 9.2.1.3. supported-calendar-data-type XML Element . . . . . 23 104 9.2.1.4. supported-attachment-values XML Element . . . . . 23 105 9.2.1.5. supported-recipient-uri-scheme-set XML Element . . 24 106 9.2.1.6. max-content-length XML Element . . . . . . . . . . 25 107 9.2.1.7. min-date-time XML Element . . . . . . . . . . . . 25 108 9.2.1.8. max-date-time XML Element . . . . . . . . . . . . 26 109 9.2.1.9. max-instances XML Element . . . . . . . . . . . . 26 110 9.2.1.10. max-recipients XML Element . . . . . . . . . . . . 27 111 9.2.1.11. administrator XML Element . . . . . . . . . . . . 27 112 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 113 10.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 28 114 10.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 28 115 10.3. DNS Considerations . . . . . . . . . . . . . . . . . . . . 28 116 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 117 11.1. Namespace Registration . . . . . . . . . . . . . . . . . . 28 118 11.1.1. iSchedule Namespace Registration . . . . . . . . . . . 28 119 11.2. HTTP Headers Registration . . . . . . . . . . . . . . . . 28 120 11.2.1. DKIM-Signature Request Header Registration . . . . . . 28 121 11.2.2. iSchedule-Version General Header Registration . . . . 29 122 11.2.3. iSchedule-Via General Header Registration . . . . . . 29 123 11.2.4. Originator Request Header Registration . . . . . . . . 29 124 11.2.5. Recipient Request Header Registration . . . . . . . . 30 125 11.3. Well-Known URI Registration . . . . . . . . . . . . . . . 30 126 11.3.1. iSchedule Well-Known URI Registration . . . . . . . . 30 127 11.4. DKIM Parameters Registration . . . . . . . . . . . . . . . 30 128 11.4.1. DKIM-Signature Canonicalization Algorithm 129 Registration . . . . . . . . . . . . . . . . . . . . . 30 130 11.4.2. DKIM Service Type Registration . . . . . . . . . . . . 31 131 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 132 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 133 13.1. Normative References . . . . . . . . . . . . . . . . . . . 31 134 13.2. Informative References . . . . . . . . . . . . . . . . . . 33 135 Appendix A. Example Scheduling Transactions . . . . . . . . . . . 34 136 A.1. Example: Simple Meeting Invitation . . . . . . . . . . . . 34 137 A.2. Example: Search for Busy Time Information . . . . . . . . 36 138 A.3. Example: Simple Task Assignment . . . . . . . . . . . . . 38 139 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 40 140 Appendix C. Change Log (to be removed by RFC Editor prior to 141 publication) . . . . . . . . . . . . . . . . . . . . 40 142 C.1. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 41 144 1. Introduction 146 This binding document provides the transport specific information 147 necessary to convey iCalendar Transport-independent Interoperability 148 Protocol (iTIP) [RFC5546] messages over the Hypertext Transfer 149 Protocol (HTTP) [RFC2616]. 151 The Internet Calendar Scheduling Protocol (iSchedule) enables 152 interoperability between different calendaring and scheduling 153 systems. Calendaring and scheduling systems that provide support for 154 iSchedule allow their users to perform scheduling transactions such 155 as schedule, reschedule, respond to scheduling request or cancel 156 scheduled calendar components, as well as search for busy time 157 information with users of other calendaring and scheduling systems on 158 the Internet. 160 iSchedule leverages the DomainKeys Identified Mail (DKIM) service 161 [RFC4871] to provide end-to-end domain-level authentication based on 162 message content and transparent to end users. 164 Discussion of this Internet-Draft is taking place on the mailing list 165 . 167 1.1. Motivations 169 The iCalendar Message-Based Interoperability Protocol (iMIP) 170 [I-D.ietf-calsify-rfc2447bis], has proven to be insufficient to allow 171 users to seamlessly perform the same scheduling operations with users 172 of other calendaring and scheduling systems on the Internet as with 173 users of their own system. This section clarifies the motivations 174 for a binding from the iCalendar Transport-independent 175 Interoperability Protocol (iTIP) [RFC5546] to a transport that allows 176 synchronous end-to-end connectivity. 178 A binding to an email-based transport is clearly inadequate to search 179 for busy time information since users need and expect to get an 180 immediate response. As such, some calendaring and scheduling systems 181 allow users to publish their free busy information in a resource 182 accessible to others on the Internet. In the absence of a 183 standardized mechanism to locate the resource that provides the free 184 busy information of a user, one thus needs to know the location of 185 this resource in addition to the calendar user address of the users 186 one wish to schedule with. 188 With an email-based transport, the transparent processing of incoming 189 scheduling messages on the server is only possible when the 190 calendaring and scheduling system is integrated with the email 191 system. Commonly, the processing of incoming scheduling messages 192 occurs on the client instead and requires user intervention, which 193 yield the following consequences: 195 1. The processing of incoming scheduling messages and the 196 corresponding updates to the calendar only occurs when the client 197 is active. As such, free busy information may be inaccurate 198 (e.g., user still appears busy when the organizer actually 199 rescheduled or canceled the meeting). 201 2. Calendaring and scheduling systems generally restrain the number 202 of updates sent to users to reduce the number of messages that 203 will clutter their email inbox. As a result, attendees rarely 204 obtain up to date participation status of other attendees. 206 3. The client becomes responsible for verification of the 207 authenticity and integrity of the scheduling message. 209 1.2. Related Memos 211 Implementers will need to be familiar with other documents that, 212 along with this document, form a framework for Internet calendaring 213 and scheduling standards. 215 This document specifies a binding from iTIP to HTTP. 217 o iCalendar [RFC5545] specifies a core specification of objects, 218 data types, properties and property parameters; 220 o iTIP [RFC5546] specifies an interoperability protocol for 221 scheduling between different implementations. 223 Furthermore, implementers will need to be familiar with the 224 DomainKeys Identified Mail (DKIM) service defined in [RFC4871]. An 225 overview of DKIM can be found in [RFC5585]. 227 This document does not attempt to repeat the specification of 228 concepts or definitions from these other documents. Where possible, 229 references are made to the document that provides the specification 230 of these concepts or definitions. 232 1.3. Notational Conventions 234 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 235 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 236 document are to be interpreted as described in [RFC2119]. 238 The Augmented BNF (ABNF) syntax used by this document to describe 239 protocol elements is defined in [RFC5234]. 241 Definitions of XML elements in this document use XML element type 242 declarations (as found in XML Document Type Declarations), described 243 in Section 3.2 of [W3C.REC-xml-20081126]. 245 The namespace "urn:ietf:params:xml:ns:ischedule" is reserved for the 246 XML elements defined in this specification, or in other Standards 247 Track IETF RFCs written to extend iSchedule. It MUST NOT be used for 248 proprietary extensions. 250 Note that the XML declarations used in this document are incomplete, 251 in that they do not include namespace information. Thus, the reader 252 MUST NOT use these declarations as the only way to validate iSchedule 253 XML element types. 255 2. iSchedule Model 257 The iSchedule design can be pictured as: 259 +----------+ +----------+ +----------+ +----------+ 260 | Calendar | | Calendar | iSchedule | Calendar | | Calendar | 261 | User |-->| Service |----------->| Service |-->| Store | 262 | Agent | | | | | | | 263 +----------+ +----------+ +----------+ +----------+ 264 iSchedule iSchedule 265 Sender Receiver 267 When an iSchedule Sender has a scheduling message to transmit, it 268 determines the iSchedule Receivers to which to delivers the message 269 to and sends the appropriate iSchedule requests. The responsability 270 of an iSchedule Sender is to transfer scheduling messages to one or 271 more iSchedule Receivers, or report its failure to do so. 273 The means by which a Calendar User Agent instructs a Calendar 274 Service, acting as an iSchedule Sender, to transmit scheduling 275 messages is outside the scope of this document. A Calendar Service 276 could provide support for a standard calendar access protocol, such 277 as CalDAV [RFC4791], [I-D.desruisseaux-caldav-sched] or any other 278 protocol, to allow a Calendar User Agent to perform scheduling 279 operations with users of other Calendar Services. 281 Likewise, the actual processing of scheduling messages received by a 282 Calendar Service, acting as an iSchedule Receiver, is also outside 283 the scope of this document. Some Calendar Service implementations 284 may decide to process some or all received scheduling messages, while 285 other implementations may decide to leave that work to Calendar User 286 Agent implementations. 288 3. iSchedule Intermediaries 290 From the end-to-end view, an iSchedule request is sent to an 291 iSchedule Receiver and a response is returned to the iSchedule 292 Sender. In practice, this may not always be the case. An iSchedule 293 request may travel through several iSchedule intermediaries. 295 iSchedule intermediaries can be used for different purposes, namely: 297 o Dispatch iSchedule request to the appropriate iSchedule Receivers 298 for each specified Recipient; Users of the same domain could 299 actually be hosted on different iSchedule Receivers. 301 o Dispatch iSchedule request to the appropriate iSchedule Receivers 302 according to the calendar component type specified in the 303 requests. Different iSchedule Receivers could be responsible of 304 handling, VEVENT, VTODO, VJOURNAL and VFREEBUSY requests. 306 o Scan iSchedule requests, particularly attachments, for virus. 308 iSchedule intermediaries are REQUIRED to identify their hostname and 309 the version number of the preceding server from which the request or 310 response arrived. iSchedule intermediaries append this information to 311 the "iSchedule-Via" general header, in sequential order, as the 312 request travels between Sender and Receiver. 314 For example, an iSchedule request might be submitted to an iSchedule 315 Receiver with the following "iSchedule-Via" header: 317 iSchedule-Via: 1.0 ischedule.example.com:443 (VendorX/2.0), 318 1.0 cal.internal.example.com:80 (VendorZ/4.3) 320 4. iSchedule Receiver Discovery 322 This section describes how an iSchedule Sender can discover the host 323 name, the port as well as the Request-URI to use to submit a request 324 to an iSchedule Receiver. 326 4.1. iSchedule SRV Service Types 328 This specification adds two SRV service labels for use with 329 iSchedule: 331 Identifies an iSchedule Receiver that uses HTTP without transport 332 layer security ([RFC2818]). 334 ischedules: Identifies an iSchedule Receiver that uses HTTP with 335 transport layer security ([RFC2818]). 337 Example: service record for server without transport layer security 339 _ischedule._tcp.example.com. IN SRV 0 1 80 ischedule.example.com. 341 Example: service record for server with transport layer security 343 _ischedules._tcp.example.com. IN SRV 0 1 443 ischedule.example.com. 345 4.2. iSchedule Receiver Request-URI 347 This specification registers a well-known URI 348 [I-D.nottingham-site-meta] for the iSchedule service, namely, 349 "ischedule" (see Section 11.3.1). iSchedule Receivers MUST support 350 requests targeted at this well-known URI. iSchedule Senders MUST 351 handle HTTP redirects on this well-known URI. 353 4.3. Resolving Calendar User Addresses 355 To deliver a scheduling message via the iSchedule protocol, an 356 iSchedule Sender needs to determine what iSchedule Receiver it needs 357 to deliver a scheduling message to for a particular Recipient. Each 358 Recipient's calendar user address is specified in the Recipient 359 request header. 361 A calendar user address as defined by iCalendar is simply a URI. 362 This is typically a mailto URI, but could potentially be any URI 363 type. 365 To get the SRV record name to query for a given mailto URI, the 366 "domain" portion of the mailto URI MUST be extracted and appended to 367 the service label "_ischedule._tcp." or "_ischedules._tcp.". 369 Example: 371 Calendar User Address: mailto:cyrus@example.com 373 Query SRV Record Names: _ischedules._tcp.example.com 374 _ischedule._tcp.example.com 376 In cases where the "domain" portion of the mailto URI contains one or 377 more levels of sub-domain, clients MAY choose to remove successive 378 levels of "sub-domain" if queries for that sub-domain fail to return 379 any SRV records. For example, a mailto URI with the full domain 380 "host.calendar.example.com" would first trigger a querying using the 381 domain "host.calendar.example.com", then if that failed, the domain 382 "calendar.example.com" would be tried, then if that failed the domain 383 "example.com" would be tried. 385 4.4. Using the SRV Record Result 387 As defined in [RFC2782] the result of an SRV record lookup will be a 388 target host name and a port. An iSchedule Sender uses these to 389 contact the iSchedule Receiver. iSchedule Senders MUST honor the full 390 behavior of SRV records as defined by [RFC2782], in particular the 391 TTL, Priority and Weight options in the record, as well as handling 392 multiple records being returned. 394 Since an iSchedule server is an HTTP server, an iSchedule client 395 needs to supply a Request-URI in the HTTP request it makes to the 396 server, in addition to the host name and port information. When SRV 397 records are being used there is no way to specify the Request-URI in 398 the SRV record. As a result clients MUST use "/" as the Request-URI 399 for the iSchedule server identified by an SRV record. 401 5. iSchedule Receiver Capabilities 403 iSchedule Receivers supporting the features described in this 404 document MUST allow iSchedule Sender to query their capabilities by 405 accepting GET requests targeted at the Request-URI "/.well-known/ 406 ischedule?query=capabilities". The response body for a successful 407 GET request targeted at this URI MUST be an XML document with query- 408 result as its root element. 410 Informative rationale: The GET method was favored over the POST 411 method to allow iSchedule Senders to query capabilities with 412 "conditional GET" requests (see Section 9.3 of [RFC2616]). 414 5.1. Example: Querying iSchedule Receiver Capabilities 416 >> Request << 418 GET /.well-known/ischedule?query=capabilities HTTP/1.1 419 Host: cal.example.com 420 >> Response << 422 HTTP/1.1 200 OK 423 Date: Mon, 15 Dec 2008 09:32:12 GMT 424 Content-Type: application/xml; charset=utf-8 425 Content-Length: xxxx 426 iSchedule-Version: 1.0 427 ETag: "afasdf-132afds" 429 430 431 432 433 1.0 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 mailto 454 455 102400 456 19910101T000000Z 457 20381231T000000Z 458 150 459 250 460 mailto:ischedule-admin@example.com 461 462 464 6. Scheduling 466 This section defines how an iSchedule Sender can use the HTTP POST 467 method to submit a scheduling message to an iSchedule Receiver. 469 6.1. POST Method 471 The POST method submits a scheduling message to one or more 472 recipients by targeting the request at the Request-URI of an 473 iSchedule Receiver. The request body of a POST method MUST contain a 474 scheduling message or free-busy message (e.g., an iCalendar object 475 that follows the iTIP semantic). 477 A submitted scheduling message will be delivered to the calendar user 478 addresses specified in the Recipient request header. A submitted 479 free-busy message will be immediately executed and a free-busy 480 response returned. 482 Every POST request MUST include the iSchedule-Version request header. 484 Every POST request MUST include a single Originator request header 485 that specifies the calendar user address of the originator of the 486 scheduling message. The value of the Originator request header MUST 487 match the value of the ORGANIZER property or one of the specified 488 ATTENDEE property depending on the specify METHOD property value as 489 summarized in the following table: 491 +----------------+----------------------------------+ 492 | Method | Originator Requirement | 493 +----------------+----------------------------------+ 494 | PUBLISH | None | 495 | REQUEST | MUST match ORGANIZER or ATTENDEE | 496 | REPLY | MUST match ATTENDEE | 497 | ADD | MUST match ORGANIZER | 498 | CANCEL | MUST match ORGANIZER | 499 | REFRESH | None | 500 | COUNTER | MUST match ATTENDEE | 501 | DECLINECOUNTER | MUST match ORGANIZER | 502 +----------------+----------------------------------+ 504 Every POST request MUST include one or more Recipient request 505 headers. The value of this header is a list of one or more calendar 506 user addresses and corresponds to the set of calendar users who will 507 have the scheduling message delivered to them. 509 6.1.1. Schedule Response 511 A POST request may deliver a scheduling message to one or more 512 calendar users specified in the Recipient request header. Since the 513 behavior of each recipient may vary, it is useful to get response 514 status information for each recipient in the overall POST response. 515 This specification defines a new XML response to convey multiple 516 recipient status. 518 A response to a POST method that indicates status for one or more 519 recipients MUST be a schedule-response XML element. This MUST 520 contain one or more response elements for each recipient, with each 521 of those containing elements that indicate which recipient they 522 correspond to, the scheduling status of the request for that 523 recipient, any error codes and an optional description. 525 In the case of a free-busy request, the response elements can also 526 contain calendar-data elements which contain free busy information 527 (e.g., an iCalendar VFREEBUSY component) indicating the busy state of 528 the corresponding recipient, assuming that the free-busy request for 529 that recipient succeeded. 531 TODO: Define the response body for a failed request. 533 (supported-calendar-data-type): The resource submitted in the POST 534 request MUST be a supported media type (i.e. text/calendar) for 535 scheduling or free-busy messages; 537 (valid-calendar-data): The resource submitted in the POST request 538 MUST be valid data for the media type being specified (i.e. valid 539 iCalendar object); 541 (valid-scheduling-message): The resource submitted in the POST 542 request MUST obey all restrictions specified for the POST request 543 (e.g., the scheduling message follows the restrictions of iTIP); 545 (originator-specified): The POST request MUST include a valid 546 Originator request header specifying the calendar user address of 547 the originator of the scheduling message. 549 (recipient-specified): The POST request MUST include one or more 550 valid Recipient request headers specifying the calendar user 551 address of users to whom the scheduling message will be delivered. 553 (originator-reply): The calendar user identified by the Originator 554 request header in the POST request MUST have previously received 555 the scheduling message that is being replied to when the 556 scheduling message is an incoming scheduling message; 557 (max-content-length): The request body submitted in the POST 558 request MUST have an octet size less than or equal to the value of 559 the max-content-length capability of the iSchedule Receiver. 561 6.1.2. Status Codes for use with the POST method 563 The following are examples of response codes one would expect to be 564 used for this method. Note, however, that unless explicitly 565 prohibited any 2/3/4/5xx series response code may be used in a 566 response. 568 200 (OK) - The command succeeded. 570 400 (Bad Request) - The Sender has provided an invalid scheduling 571 message. 573 403 (Forbidden) - The Sender cannot submit a scheduling message to 574 the specified Request-URI. 576 404 (Not Found) - The URL in the Request-URI was not present. 578 507 (Insufficient Storage) - The server did not have sufficient 579 space to record the scheduling message. 581 7. iSchedule Domain-Level Authentication 583 iSchedule uses and extends the mechanism defined by DomainKeys 584 Identified Mail (DKIM) [RFC4871]. DKIM defines a domain-level 585 digital signature authentication framework for email, using public- 586 key cryptography, with the domain name service (DNS) as its key 587 server technology. 589 The following sections describes how the DomainKeys Identified Mail 590 (DKIM) service can fit into a scheduling service. 592 7.1. Signature Content 594 The following HTTP headers MUST be included in the signature of a 595 message: 597 o Content-Type 599 o Host 601 o Originator 603 o Recipient 604 To allow iSchedule messages to transit via HTTP intermediaries, hop- 605 by-hop headers, such as the following HTTP/1.1 headers MUST NOT be 606 included in the signature of a message: 608 o Connection 610 o Keep-Alive 612 o Proxy-Authenticate 614 o Proxy-Authorization 616 o TE 618 o Trailers 620 o Transfer-Encoding 622 o Upgrade 624 7.2. Canonicalization 626 Transformations can be applied to the message body during transit in 627 order to safely transfer it between the iSchedule Sender and the 628 iSchedule Receiver. Notably, one or more transfer-codings may be 629 applied to an entity. 631 To avoid breaking the DKIM signature of a message, the signer/ 632 verifier MUST compute the hash of a message body against the entity- 633 body, that is, with no transfer-encoding applied to the message body. 635 7.2.1. The "simple-http" Header Canonicalization Algorithm 637 TODO. 639 7.2.2. The "simple-http" Body Canonicalization Algorithm 641 TODO. 643 7.3. Key Management 645 DKIM allows an Administrative Management Domain (ADMD) to constrain 646 the use of a key to specific service types. By default, keys are not 647 constrained to specific service types. As such, the same key could 648 be used to sign email and calendar messages. 650 This specification defines a new service type "calendar" to constrain 651 the use of a key to calendaring and scheduling services: 653 +-----------+-------------------------------------------------------+ 654 | Service | Description | 655 | Type | | 656 +-----------+-------------------------------------------------------+ 657 | calendar | calendaring and scheduling service (not necessarily | 658 | | limited to iSchedule) | 659 +-----------+-------------------------------------------------------+ 661 7.4. Delegation of Signing Authority 663 An Administrative Management Domain (ADMD) MAY delegate signing 664 authority to other ADMD by publishing a Procuration record. The DNS 665 is proposed as the initial mechanism for Procuration records. 667 7.4.1. Publication of Procuration Record 669 Signing Procuration records are published using the DNS TXT resource 670 record type. 672 _procuration._domainkey.aaa.example TXT "v=1.0 d=bbb.example" 674 TODO: Detailed record syntax specification. Clarify how an ADMD can 675 delegate signing authority to multiple ADMD. 677 7.4.2. Procuration Lookup Procedure 679 If the Signing Domain IDentifier (SDID) contained in the "d=" tag of 680 DKIM-Signature request header specifies a different domain than the 681 value of the Originator request header, the iSchedule Receiver MUST 682 provide a way to verify whether the owner of the domain of the 683 Originator authorize the domain specified in the SDID to sign on its 684 behalf. 686 The iSchedule Receiver MAY query DNS for a TXT record corresponding 687 to the Originator's domain prefixed by "_procuration._domainkey." 688 (note the trailing dot). 690 If the result of this query is a NOERROR response (rcode=0 in 691 [RFC1035]) with an answer that is a single record that is a valid 692 Procuration record, use that record, and the algorithm terminates. 694 If the result of the query is NXDOMAIN or NOERROR with zero records, 695 there is no Procuration record. If the result of the query contains 696 more than one record, or a record that is not a valid Procuration 697 record, the Procuration result is undefined. 699 If a query results in a "SERVFAIL" error response (rcode=2 in 700 [RFC1035]), the algorithm terminates without returning a result; 701 possible actions include queuing the message or returning an 702 iSchedule error indicating a temporary failure. 704 8. HTTP Headers 706 This section defines the syntax and semantics of additional HTTP/1.1 707 header fields. 709 The header's syntax uses the optional whitespace (OWS) rule defined 710 as follows: 712 OWS = *( [ CRLF ] WSP ) 714 8.1. DKIM-Signature Request Header 716 The DKIM-Signature request header MUST be specified by the iSchedule 717 Sender on all scheduling requests to specify all of the signature and 718 key-fetching data. 720 DKIM-Signature = "DKIM-Signature" ":" OWS DKIM-Signature-v 721 DKIM-Signature-v = tag-list 722 ; tag-list is defined in Section 3.2 of 724 8.2. iSchedule-Version General Header 726 The iSchedule-Version general header field MUST be specified by the 727 iSchedule Sender on requests, and by the iSchedule Receiver on 728 responses. 730 iSchedule-Version = "iSchedule-Version" ":" OWS 731 iSchedule-Version-v 732 iSchedule-Version-v = iSchedule-Version-elem 733 *( OWS "," OWS iSchedule-Version-elem ) 734 iSchedule-Version-elem = 1*DIGIT "." 1*DIGIT 736 8.3. iSchedule-Via General Header 738 The iSchedule-Via general header field MUST be used by iSchedule 739 intermediaries to indicate the intermediate protocols and recipients 740 between the iSchedule Sender and the iSchedule Receiver on requests. 742 iSchedule-Via = "iSchedule-Via" ":" OWS iSchedule-Via-v 743 iSchedule-Via-v = iSchedule-Via-elem 744 *( OWS "," OWS iSchedule-Via-elem ) 745 iSchedule-Via-elem = ( received-protocol received-by [ comment ] ) 747 ; received-protocol as defined in [RFC2616] 748 ; received-by as defined in [RFC2616] 749 ; comment as defined in [RFC2616] 751 8.4. Originator Request Header 753 The Originator request header value is a URI which specifies the 754 calendar user address of the originator of the scheduling message. 755 Note that the absoluteURI rule is defined in [RFC3986]. 757 Originator = "Originator" ":" OWS Originator-v 758 Originator-v = absoluteURI 760 8.5. Recipient Request Header 762 The Recipient request header value is a URI which specifies the 763 calendar user address of the recipients to which the POST method 764 should deliver the submitted scheduling message. Note that the 765 absoluteURI rule is defined in [RFC3986]. 767 Recipient = "Recipient" ":" OWS Recipient-v 768 Recipient-v = Recipient-elem *( OWS "," OWS Recipient-elem ) 769 Recipient-elem = absoluteURI 771 9. XML Element Definitions 773 TODO: Re-write XML element definitions using the RELAX NG Compact 774 Syntax [RELAX-NG]. 776 9.1. schedule-response XML Element 778 Name: schedule-response 780 Namespace: urn:ietf:params:xml:ns:ischedule 782 Purpose: Contains the set of responses for a POST method request. 784 Description: See Section 6.1.1. 786 Definition: 788 790 9.1.1. response XML Element 792 Name: response 794 Namespace: urn:ietf:params:xml:ns:ischedule 796 Purpose: Contains a single response for a POST method request. 798 Description: See Section 6.1.1. 800 Definition: 802 808 9.1.1.1. recipient XML Element 810 Name: recipient 812 Namespace: urn:ietf:params:xml:ns:ischedule 814 Purpose: The calendar user address (recipient header value) that the 815 enclosing response for a POST method request is for. 817 Description: See Section 6.1.1. 819 Definition: 821 823 9.1.1.2. request-status XML Element 825 Name: request-status 827 Namespace: urn:ietf:params:xml:ns:ischedule 828 Purpose: The iTIP REQUEST-STATUS property value for this response. 830 Description: See Section 6.1.1. 832 Definition: 834 836 9.1.1.3. calendar-data XML Element 838 Name: calendar-data 840 Namespace: urn:ietf:params:xml:ns:ischedule 842 Purpose: An iCalendar object in a response to a seach for busy time 843 information. 845 Description: See Section 6.1.1. 847 Definition: 849 851 9.1.1.4. error XML Element 853 Name: error 855 Namespace: urn:ietf:params:xml:ns:ischedule 857 Purpose: Error responses sometimes need more information to indicate 858 what went wrong. 860 Description: See Section 6.1.1. 862 Definition: 864 866 9.1.1.5. responsedescription XML Element 868 Name: responsedescription 869 Namespace: urn:ietf:params:xml:ns:ischedule 871 Purpose: Contains information about a status response 873 Description: See Section 6.1.1. 875 Definition: 877 879 9.2. query-result XML Element 881 Name: query-result 883 Namespace: urn:ietf:params:xml:ns:ischedule 885 Purpose: Contains result of a query request. 887 Description: A generic container for the result of a query request, 888 such as a query of the capabilities of an iSchedule Receiver. 890 Definition: 892 894 9.2.1. capability-set XML Element 896 Name: capability-set 898 Namespace: urn:ietf:params:xml:ns:ischedule 900 Purpose: Contains iSchedule Receiver capabilities. 902 Description: The capability-set element contains capabilities of the 903 iSchedule Receiver. 905 Definition: 907 919 9.2.1.1. supported-version-set XML Element 921 Name: supported-version-set 923 Namespace: urn:ietf:params:xml:ns:ischedule 925 Purpose: Identifies the iSchedule versions supported by the 926 iSchedule Receiver. 928 Description: An iSchedule Receiver MAY advertise support for 929 multiple versions of the iSchedule protocol. 931 Definition: 933 935 9.2.1.1.1. version XML Element 937 Name: version 939 Namespace: urn:ietf:params:xml:ns:ischedule 941 Purpose: Specifies an iSchedule version. 943 Definition: 945 946 948 9.2.1.2. supported-scheduling-message-set XML Element 949 Name: supported-scheduling-message-set 951 Namespace: urn:ietf:params:xml:ns:ischedule 953 Purpose: Identifies the type of supported scheduling messages. 955 Description: An iSchedule Receiver could advertise that it only 956 provides support for event and free-busy scheduling messages, and 957 not for to-do scheduling messages, with this capabilities. 959 Definition: 961 963 9.2.1.2.1. comp XML Element 965 Name: comp 967 Namespace: urn:ietf:params:xml:ns:ischedule 969 Purpose: Identifies a calendar component type. 971 Description: 973 Definition: 975 977 978 980 9.2.1.2.1.1. method XML Element 982 Name: method 984 Namespace: urn:ietf:params:xml:ns:ischedule 986 Purpose: Specifies an iCalendar method type. 988 Description: 990 Definition: 992 993 994 996 9.2.1.3. supported-calendar-data-type XML Element 998 Name: supported-calendar-data-type 1000 Namespace: urn:ietf:params:xml:ns:ischedule 1002 Purpose: 1004 Description: 1006 Definition: 1008 1010 9.2.1.3.1. calendar-data-type XML Element 1012 Name: calendar-data-type 1014 Namespace: urn:ietf:params:xml:ns:ischedule 1016 Purpose: Specified a supported media type for scheduling messages. 1018 Description: 1020 Definition: 1022 1024 1026 1027 1029 9.2.1.4. supported-attachment-values XML Element 1031 Name: supported-attachment-values 1033 Namespace: urn:ietf:params:xml:ns:ischedule 1035 Purpose: Identifies the attachment values supported. 1037 Description: 1039 Definition: 1041 1044 9.2.1.4.1. inline-attachment XML Element 1046 Name: inline-attachment 1048 Namespace: urn:ietf:params:xml:ns:ischedule 1050 Purpose: Specifies inline attachment as a supported attachment 1051 value. 1053 Description: 1055 Definition: 1057 1059 9.2.1.4.2. external-attachment XML Element 1061 Name: external-attachment 1063 Namespace: urn:ietf:params:xml:ns:ischedule 1065 Purpose: Specifies external attachment as a supported attachment 1066 value. 1068 Description: 1070 Definition: 1072 1074 9.2.1.5. supported-recipient-uri-scheme-set XML Element 1076 Name: supported-recipient-uri-scheme-set 1078 Namespace: urn:ietf:params:xml:ns:ischedule 1079 Purpose: Identifies the supported URI schemes supported in the 1080 Recipient HTTP request header. 1082 Description: 1084 Definition: 1086 1088 9.2.1.5.1. scheme XML Element 1090 Name: scheme 1092 Namespace: urn:ietf:params:xml:ns:ischedule 1094 Purpose: Specifies a supported URI scheme. 1096 Description: 1098 Definition: 1100 1101 1103 9.2.1.6. max-content-length XML Element 1105 Name: max-content-length 1107 Namespace: urn:ietf:params:xml:ns:ischedule 1109 Purpose: Specifies the maximum size allowed for a scheduling message 1110 in octets. 1112 Description: 1114 Definition: 1116 1117 1119 9.2.1.7. min-date-time XML Element 1120 Name: min-date-time 1122 Namespace: urn:ietf:params:xml:ns:ischedule 1124 Purpose: Specifies a DATE-TIME value indicating the earliest date 1125 and time in UTC that the server is willing to accept for any DATE 1126 or DATE-TIME value in a scheduling message. 1128 Description: 1130 Definition: 1132 1133 1135 9.2.1.8. max-date-time XML Element 1137 Name: max-date-time 1139 Namespace: urn:ietf:params:xml:ns:ischedule 1141 Purpose: Specifies a DATE-TIME value indicating the latest date and 1142 time in UTC that the server is willing to accept for any DATE or 1143 DATE-TIME value in a scheduling message. 1145 Description: 1147 Definition: 1149 1150 1152 9.2.1.9. max-instances XML Element 1154 Name: max-instances 1156 Namespace: urn:ietf:params:xml:ns:ischedule 1158 Purpose: Specifies the maximum number of recurrence instances 1159 allowed in a scheduling message. 1161 Description: 1163 Definition: 1165 1166 1168 9.2.1.10. max-recipients XML Element 1170 Name: max-recipients 1172 Namespace: urn:ietf:params:xml:ns:ischedule 1174 Purpose: Specifies the maximum number of recipients allowed for a 1175 scheduling message. 1177 Description: 1179 Definition: 1181 1182 1184 9.2.1.11. administrator XML Element 1186 Name: administrator 1188 Namespace: urn:ietf:params:xml:ns:ischedule 1190 Purpose: Provides contact information for the administrator of the 1191 iSchedule Receiver. 1193 Description: 1195 Definition: 1197 1198 1200 10. Security Considerations 1202 The process of scheduling involves the sending and receiving of 1203 scheduling messages. As a result, the security problems related to 1204 messaging in general are relevant here. In particular the 1205 authenticity of the scheduling messages needs to be verified. 1207 Potential attacks described in the security considerations of DKIM 1209 [RFC4871] are also applicable to iSchedule. 1211 10.1. Privacy 1213 iSchedule Senders and iSchedule Receivers MUST use an HTTP connection 1214 protected with TLS [RFC5246] as defined in [RFC2818] for all 1215 transactions. 1217 10.2. Authentication 1219 iSchedule uses and extends the mechanism defined by DomainKeys 1220 Identified Mail (DKIM) [RFC4871]. DKIM defines a domain-level 1221 digital signature authentication framework for email, using public- 1222 key cryptography, with the domain name service as its key server 1223 technology. 1225 10.3. DNS Considerations 1227 DNS security issues are addressed by DNSSEC [RFC4033]. 1229 11. IANA Considerations 1231 11.1. Namespace Registration 1233 This specification registers a new URN to identify a new XML 1234 namespace as per [RFC3688]. 1236 11.1.1. iSchedule Namespace Registration 1238 Registration request for the iSchedule namespace: 1240 URI: urn:ietf:params:xml:ns:ischedule 1242 Registrant Contact: See the "Authors' Addresses" section of this 1243 document. 1245 XML: None. Namespace URIs do not represent an XML specification. 1247 11.2. HTTP Headers Registration 1249 This specification registers new headers for use with HTTP as per 1250 [RFC3864]. 1252 11.2.1. DKIM-Signature Request Header Registration 1254 Header field name: DKIM-Signature 1256 Applicable protocol: http 1257 Status: standard 1259 Author/Change controller: IETF 1261 Specification document(s): this specification 1263 Related information: none 1265 11.2.2. iSchedule-Version General Header Registration 1267 Header field name: iSchedule-Version 1269 Applicable protocol: http 1271 Status: standard 1273 Author/Change controller: IETF 1275 Specification document(s): this specification 1277 Related information: none 1279 11.2.3. iSchedule-Via General Header Registration 1281 Header field name: iSchedule-Via 1283 Applicable protocol: http 1285 Status: standard 1287 Author/Change controller: IETF 1289 Specification document(s): this specification 1291 Related information: none 1293 11.2.4. Originator Request Header Registration 1295 Header field name: Originator 1297 Applicable protocol: http 1299 Status: standard 1301 Author/Change controller: IETF 1303 Specification document(s): this specification 1304 Related information: none 1306 11.2.5. Recipient Request Header Registration 1308 Header field name: Recipient 1310 Applicable protocol: http 1312 Status: standard 1314 Author/Change controller: IETF 1316 Specification document(s): this specification 1318 Related information: none 1320 11.3. Well-Known URI Registration 1322 This specification registers a new well-known URI as per 1323 [I-D.nottingham-site-meta]. 1325 11.3.1. iSchedule Well-Known URI Registration 1327 URI suffix: ischedule 1329 Change controller: IETF. 1331 Specification document(s): this specification 1333 Related information: none 1335 11.4. DKIM Parameters Registration 1337 11.4.1. DKIM-Signature Canonicalization Algorithm Registration 1339 This specification registers new canonicalization algorithms for the 1340 header and body of HTTP requests as per [RFC4871]. 1342 The following value should be added to the DKIM-Signature 1343 Canonicalization Header registery established in Section 7.3 of 1344 [RFC4871]: 1346 +-------------+-----------+ 1347 | Type | Reference | 1348 +-------------+-----------+ 1349 | simple-http | RFC XXXX | 1350 +-------------+-----------+ 1352 The following value should be added to the DKIM-Signature 1353 Canonicalization Body registery established in Section 7.3 of 1354 [RFC4871]: 1356 +-------------+-----------+ 1357 | Type | Reference | 1358 +-------------+-----------+ 1359 | simple-http | RFC XXXX | 1360 +-------------+-----------+ 1362 11.4.2. DKIM Service Type Registration 1364 This specification registers a new DKIM service type to specify that 1365 a given selector MUST only be used to verify messages of calendar 1366 services (not necessarily limited to iSchedule). The following value 1367 should be added to the DKIM Service Type Registry established in 1368 Section 7.7 of [RFC4871]: 1370 +----------+-----------+ 1371 | Type | Reference | 1372 +----------+-----------+ 1373 | calendar | RFC XXXX | 1374 +----------+-----------+ 1376 12. Acknowledgments 1378 The authors would like to thank the following individuals for 1379 contributing their ideas and support for writing this specification: 1380 Mattias Amnefelt, Mike Douglass, Tomas Hnetila, Ciny Joy, Barry 1381 Leiba, Simon Pilette, Arnaud Quillaud, Simon Vaillancourt, and 1382 Wilfredo Sanchez Vega. 1384 The authors would also like to thank the Calendaring and Scheduling 1385 Consortium for advice with this specification, and for organizing 1386 interoperability testing events to help refine it. 1388 13. References 1390 13.1. Normative References 1392 [I-D.nottingham-site-meta] Nottingham, M. and E. Hammer-Lahav, 1393 "Defining Well-Known URIs", 1394 draft-nottingham-site-meta-05 (work 1395 in progress), December 2009. 1397 [RFC1035] Mockapetris, P., "Domain names - 1398 implementation and specification", 1399 STD 13, RFC 1035, November 1987. 1401 [RFC2119] Bradner, S., "Key words for use in 1402 RFCs to Indicate Requirement 1403 Levels", BCP 14, RFC 2119, 1404 March 1997. 1406 [RFC2616] Fielding, R., Gettys, J., Mogul, J., 1407 Frystyk, H., Masinter, L., Leach, 1408 P., and T. Berners-Lee, "Hypertext 1409 Transfer Protocol -- HTTP/1.1", 1410 RFC 2616, June 1999. 1412 [RFC2782] Gulbrandsen, A., Vixie, P., and L. 1413 Esibov, "A DNS RR for specifying the 1414 location of services (DNS SRV)", 1415 RFC 2782, February 2000. 1417 [RFC2818] Rescorla, E., "HTTP Over TLS", 1418 RFC 2818, May 2000. 1420 [RFC3688] Mealling, M., "The IETF XML 1421 Registry", BCP 81, RFC 3688, 1422 January 2004. 1424 [RFC3986] Berners-Lee, T., Fielding, R., and 1425 L. Masinter, "Uniform Resource 1426 Identifier (URI): Generic Syntax", 1427 STD 66, RFC 3986, January 2005. 1429 [RFC4033] Arends, R., Austein, R., Larson, M., 1430 Massey, D., and S. Rose, "DNS 1431 Security Introduction and 1432 Requirements", RFC 4033, March 2005. 1434 [RFC4871] Allman, E., Callas, J., Delany, M., 1435 Libbey, M., Fenton, J., and M. 1436 Thomas, "DomainKeys Identified Mail 1437 (DKIM) Signatures", RFC 4871, 1438 May 2007. 1440 [RFC5234] Crocker, D. and P. Overell, 1441 "Augmented BNF for Syntax 1442 Specifications: ABNF", STD 68, 1443 RFC 5234, January 2008. 1445 [RFC5246] Dierks, T. and E. Rescorla, "The 1446 Transport Layer Security (TLS) 1447 Protocol Version 1.2", RFC 5246, 1448 August 2008. 1450 [RFC5545] Desruisseaux, B., "Internet 1451 Calendaring and Scheduling Core 1452 Object Specification (iCalendar)", 1453 RFC 5545, September 2009. 1455 [RFC5546] Daboo, C., "iCalendar Transport- 1456 Independent Interoperability 1457 Protocol (iTIP)", RFC 5546, 1458 December 2009. 1460 [W3C.REC-xml-20081126] Maler, E., Yergeau, F., Sperberg- 1461 McQueen, C., Paoli, J., and T. Bray, 1462 "Extensible Markup Language (XML) 1463 1.0 (Fifth Edition)", World Wide Web 1464 Consortium Recommendation REC-xml- 1465 20081126, November 2008, . 1469 13.2. Informative References 1471 [I-D.desruisseaux-caldav-sched] Daboo, C. and B. Desruisseaux, 1472 "CalDAV Scheduling Extensions to 1473 WebDAV", 1474 draft-desruisseaux-caldav-sched-08 1475 (work in progress), August 2009. 1477 [I-D.ietf-calsify-rfc2447bis] Melnikov, A., "iCalendar Message- 1478 Based Interoperability Protocol 1479 (iMIP)", 1480 draft-ietf-calsify-rfc2447bis-08 1481 (work in progress), January 2010. 1483 [RELAX-NG] Clark, J., "RELAX NG Compact 1484 Syntax", December 2001, . 1488 [RFC3864] Klyne, G., Nottingham, M., and J. 1489 Mogul, "Registration Procedures for 1490 Message Header Fields", BCP 90, 1491 RFC 3864, September 2004. 1493 [RFC4791] Daboo, C., Desruisseaux, B., and L. 1494 Dusseault, "Calendaring Extensions 1495 to WebDAV (CalDAV)", RFC 4791, 1496 March 2007. 1498 [RFC5585] Hansen, T., Crocker, D., and P. 1499 Hallam-Baker, "DomainKeys Identified 1500 Mail (DKIM) Service Overview", 1501 RFC 5585, July 2009. 1503 Appendix A. Example Scheduling Transactions 1505 This section describes some example scheduling transactions that give 1506 a general idea of how scheduling is carried out between an iSchedule 1507 Sender and an iSchedule Receiver. 1509 A.1. Example: Simple Meeting Invitation 1511 In the following example, the iSchedule Sender requests the iSchedule 1512 Receiver to deliver a meeting invitation (scheduling REQUEST) to the 1513 calendar user mailto:cyrus@example.org. The response indicates that 1514 delivery of the scheduling message was successful. 1516 >> Request << 1518 POST /.well-known/ischedule HTTP/1.1 1519 DKIM-Signature: a=rsa-sha256; d=example.com; s=jupiter; 1520 c=simple-http; q=dns/txt; t=1268069852; x=1283918400; 1521 h=Originator:Recipient:Host:Content-Type; 1522 bh=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx; 1523 b=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx 1524 Host: cal.example.org 1525 iSchedule-Version: 1.0 1526 Originator: mailto:bernard@example.com 1527 Recipient: mailto:cyrus@example.org 1528 Content-Type: text/calendar; component=VEVENT; method=REQUEST 1529 Content-Length: xxxx 1531 BEGIN:VCALENDAR 1532 VERSION:2.0 1533 PRODID:-//Example Corp.//EN 1534 METHOD:REQUEST 1535 BEGIN:VEVENT 1536 DTSTAMP:20040901T200200Z 1537 ORGANIZER:mailto:bernard@example.com 1538 DTSTART:20040902T130000Z 1539 DTEND:20040902T140000Z 1540 SUMMARY:Design meeting 1541 UID:34222-232@example.com 1542 ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR;CUTYPE=IND 1543 IVIDUAL;CN=Bernard Desruisseaux:mailto:bernard@ 1544 example.com 1545 ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE 1546 Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Cyrus Daboo: 1547 mailto:cyrus@example.org 1548 END:VEVENT 1549 END:VCALENDAR 1550 >> Response << 1552 HTTP/1.1 200 OK 1553 Date: Thu, 02 Sep 2004 16:53:32 GMT 1554 Content-Type: application/xml; charset=utf-8 1555 Content-Length: xxxx 1556 iSchedule-Version: 1.0 1558 1559 1560 1561 mailto:cyrus@example.org 1562 2.0;Success 1563 Delivered to recipient 1564 1565 1567 A.2. Example: Search for Busy Time Information 1569 In the following example, the iSchedule Sender requests the iSchedule 1570 Receiver to determine the busy information of the calendar user 1571 mailto:cyrus@example.org, over the time range specified by the 1572 scheduling message sent in the request. The response includes 1573 VFREEBUSY components with the busy time of the requested calendar 1574 user. 1576 >> Request << 1578 POST /.well-known/ischedule HTTP/1.1 1579 DKIM-Signature: a=rsa-sha256; d=example.com; s=jupiter; 1580 c=simple-http; q=dns/txt; t=1268069852; x=1283918400; 1581 h=Originator:Recipient:Host:Content-Type; 1582 bh=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx; 1583 b=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx 1584 Host: cal.example.org 1585 iSchedule-Version: 1.0 1586 Originator: mailto:bernard@example.com 1587 Recipient: mailto:cyrus@example.org 1588 Content-Type: text/calendar; component=VFREEBUSY; method=REQUEST 1589 Content-Length: xxxx 1591 BEGIN:VCALENDAR 1592 VERSION:2.0 1593 PRODID:-//Example Corp.//EN 1594 METHOD:REQUEST 1595 BEGIN:VFREEBUSY 1596 DTSTAMP:20040901T200200Z 1597 ORGANIZER:mailto:bernard@example.com 1598 DTSTART:20040902T000000Z 1599 DTEND:20040903T000000Z 1600 UID:34222-232@example.com 1601 ATTENDEE;CN=Cyrus Daboo:mailto:cyrus@example.org 1602 END:VFREEBUSY 1603 END:VCALENDAR 1604 >> Response << 1606 HTTP/1.1 200 OK 1607 Date: Thu, 02 Sep 2004 16:53:32 GMT 1608 Content-Type: application/xml; charset=utf-8 1609 Content-Length: xxxx 1610 iSchedule-Version: 1.0 1612 1613 1614 1615 mailto:cyrus@example.org 1616 2.0;Success 1617 BEGIN:VCALENDAR 1618 VERSION:2.0 1619 PRODID:-//Example Corp.//EN 1620 METHOD:REPLY 1621 BEGIN:VFREEBUSY 1622 DTSTAMP:20040901T200200Z 1623 ORGANIZER:mailto:bernard@example.com 1624 DTSTART:20040902T000000Z 1625 DTEND:20040903T000000Z 1626 UID:34222-232@example.com 1627 ATTENDEE;CN=Cyrus Daboo:mailto:cyrus@example.org 1628 FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:20040902T000000Z/ 1629 20040902T090000Z,20040902T170000Z/20040903T000000Z 1630 FREEBUSY;FBTYPE=BUSY:20040902T120000Z/20040902T130000Z 1631 END:VFREEBUSY 1632 END:VCALENDAR 1633 1634 1635 1637 A.3. Example: Simple Task Assignment 1639 In the following example, the iSchedule Sender requests the iSchedule 1640 Sender to deliver a task assignment (scheduling REQUEST) to the 1641 calendar user mailto:cyrus@example.org. The response indicates that 1642 delivery of the scheduling message was successful. 1644 >> Request << 1646 POST /.well-known/ischedule HTTP/1.1 1647 DKIM-Signature: a=rsa-sha256; d=example.com; s=jupiter; 1648 c=simple-http; q=dns/txt; t=1268069852; x=1283918400; 1649 h=Originator:Recipient:Host:Content-Type; 1650 bh=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx; 1651 b=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx 1652 Host: cal.example.org 1653 iSchedule-Version: 1.0 1654 Originator: mailto:bernard@example.com 1655 Recipient: mailto:cyrus@example.org 1656 Content-Type: text/calendar; component=VTODO; method=REQUEST 1657 Content-Length: xxxx 1659 BEGIN:VCALENDAR 1660 VERSION:2.0 1661 PRODID:-//Example Corp.//CalDAV Client//EN 1662 METHOD:REQUEST 1663 BEGIN:VTODO 1664 DTSTAMP:20040901T200200Z 1665 ORGANIZER:mailto:bernard@example.com 1666 DUE:20070505 1667 SUMMARY:Review Internet-Draft 1668 UID:34222-456@example.com 1669 ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE 1670 Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Cyrus Daboo: 1671 mailto:cyrus@example.org 1672 END:VEVENT 1673 END:VCALENDAR 1674 >> Response << 1676 HTTP/1.1 200 OK 1677 Date: Thu, 02 Sep 2004 16:53:32 GMT 1678 Content-Type: application/xml; charset=utf-8 1679 Content-Length: xxxx 1680 iSchedule-Version: 1.0 1682 1683 1684 1685 mailto:cyrus@example.org 1686 2.0;Success 1687 Delivered to recipient 1688 1689 1691 Appendix B. Open Issues 1693 1. As specified in Section 3.6 of DKIM, parameters to the key lookup 1694 algorithm are the type of the lookup (the "q=" tag), the domain 1695 of the signer (the "d=" tag of the DKIM-Signature header field), 1696 and the selector (the "s=" tag). Is the use of the "s=" and "d=" 1697 tags sufficient to allow "email" and "calendar" DKIM keys to be 1698 managed separately, or should a new tag be introduced to override 1699 the default DNS name to look for (e.g., "n=_calendardomainkey", 1700 to override "_domainkey")? 1701 2. Should we forbid the "DKIM-Signature" header to be listed in the 1702 HTTP "Trailer" header? Else, should we require a "DKIM- 1703 Signature-Header" header that would specify the algorithm (a= 1704 tag) up front (along with s= and d= tags to match the proper 1705 DKIM-Signature if multiple values are provided) when the "DKIM- 1706 Signature" header is listed in the "Trailer" header? Knowning 1707 the algorithm up front would avoid going through the data twice. 1708 "Trailer: Content-MD5" doesn't have this issue since the 1709 algorithm is implicit. 1710 3. Should the "Host" and "Recipient" request header really be 1711 REQUIRED to be signed? Should we required the actual Request-URI 1712 to be signed as well? 1714 Appendix C. Change Log (to be removed by RFC Editor prior to 1715 publication) 1717 C.1. Changes in -01 1719 a. Introduced use of DKIM for calendaring and scheduling services. 1720 b. The XML elements "supported-calendar-data" and "calendar-data" 1721 were renamed to "supported-calendar-data-type" and "calendar- 1722 data-type" respectively to avoid confusion with the "calendar- 1723 data" XML element being used in the "response" XML element. 1724 c. The "recipient" XML element was redefined to accept (#PCDATA) 1725 instead of an "href" XML element. 1726 d. The grammar of new HTTP headers is now using the ABNF syntax 1727 defined in [RFC5234]. 1728 e. Fixed various typos. 1730 Authors' Addresses 1732 Cyrus Daboo 1733 Apple Inc. 1734 1 Infinite Loop 1735 Cupertino, CA 95014 1736 USA 1738 EMail: cyrus@daboo.name 1739 URI: http://www.apple.com/ 1741 Bernard Desruisseaux 1742 Oracle Corporation 1743 600 Blvd. de Maisonneuve West 1744 Suite 1900 1745 Montreal, QC H3A 3J2 1746 CANADA 1748 EMail: bernard.desruisseaux@oracle.com 1749 URI: http://www.oracle.com/