idnits 2.17.1 draft-desruisseaux-ischedule-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 RFC6376, 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 -- The document date (May 2, 2013) is 4012 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 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 2 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: 6376 (if approved) B. Desruisseaux 5 Intended status: Standards Track Oracle 6 Expires: November 3, 2013 May 2, 2013 8 Internet Calendar Scheduling Protocol (iSchedule) 9 draft-desruisseaux-ischedule-05 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 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). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on November 3, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 1.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 5 55 1.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . 6 56 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 57 1.4. Notational Conventions . . . . . . . . . . . . . . . . . . 7 58 2. iSchedule Model . . . . . . . . . . . . . . . . . . . . . . . 7 59 3. iSchedule Overview . . . . . . . . . . . . . . . . . . . . . . 8 60 3.1. iSchedule Sender Actions . . . . . . . . . . . . . . . . . 8 61 3.2. iSchedule Receiver Actions . . . . . . . . . . . . . . . . 9 62 4. iSchedule Receiver Discovery . . . . . . . . . . . . . . . . . 10 63 4.1. Resolving Calendar User Addresses . . . . . . . . . . . . 10 64 4.2. iSchedule SRV Service Type . . . . . . . . . . . . . . . . 11 65 4.3. iSchedule Service TXT Records . . . . . . . . . . . . . . 11 66 4.4. iSchedule Receiver Request-URI . . . . . . . . . . . . . . 12 67 5. iSchedule Receiver Capabilities . . . . . . . . . . . . . . . 12 68 5.1. Example: Querying iSchedule Receiver Capabilities . . . . 13 69 6. Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 6.1. POST Method . . . . . . . . . . . . . . . . . . . . . . . 14 71 6.1.1. Schedule Response . . . . . . . . . . . . . . . . . . 16 72 6.1.2. Failed Schedule Response . . . . . . . . . . . . . . . 16 73 7. iSchedule Domain-Level Authentication . . . . . . . . . . . . 19 74 7.1. Signature Content . . . . . . . . . . . . . . . . . . . . 19 75 7.2. Canonicalization . . . . . . . . . . . . . . . . . . . . . 21 76 7.2.1. The "ischedule-relaxed" Header Canonicalization 77 Algorithm . . . . . . . . . . . . . . . . . . . . . . 21 78 7.3. Key Management . . . . . . . . . . . . . . . . . . . . . . 22 79 7.3.1. DNS-based Public Key Management . . . . . . . . . . . 22 80 7.3.2. HTTP-based Public Key Management . . . . . . . . . . . 22 81 7.3.2.1. SRV Service Type . . . . . . . . . . . . . . . . . 23 82 7.3.2.2. Well-known Request-URI . . . . . . . . . . . . . . 23 83 7.3.2.3. Example Lookup Procedure . . . . . . . . . . . . . 24 84 7.3.3. Private Exchange Public Key Management . . . . . . . . 24 85 7.4. Verification Requirements . . . . . . . . . . . . . . . . 25 86 7.5. Authorized Third-Party Signatures . . . . . . . . . . . . 25 87 8. HTTP Headers . . . . . . . . . . . . . . . . . . . . . . . . . 25 88 8.1. DKIM-Signature Request Header . . . . . . . . . . . . . . 26 89 8.2. iSchedule-Version General Header . . . . . . . . . . . . . 26 90 8.3. iSchedule-Capabilities Response Header . . . . . . . . . . 26 91 8.4. iSchedule-Message-ID Request Header . . . . . . . . . . . 26 92 8.5. Originator Request Header . . . . . . . . . . . . . . . . 27 93 8.6. Recipient Request Header . . . . . . . . . . . . . . . . . 27 94 9. XML Element Definitions . . . . . . . . . . . . . . . . . . . 27 95 9.1. schedule-response XML Element . . . . . . . . . . . . . . 27 96 9.1.1. response XML Element . . . . . . . . . . . . . . . . . 27 97 9.1.1.1. recipient XML Element . . . . . . . . . . . . . . 28 98 9.1.1.2. request-status XML Element . . . . . . . . . . . . 28 99 9.1.1.3. calendar-data XML Element . . . . . . . . . . . . 28 100 9.1.1.4. error XML Element . . . . . . . . . . . . . . . . 29 101 9.1.1.5. response-description XML Element . . . . . . . . . 29 102 9.2. query-result XML Element . . . . . . . . . . . . . . . . . 29 103 9.2.1. capabilities XML Element . . . . . . . . . . . . . . . 30 104 9.2.1.1. serial-number XML Element . . . . . . . . . . . . 30 105 9.2.1.2. versions XML Element . . . . . . . . . . . . . . . 31 106 9.2.1.3. scheduling-messages XML Element . . . . . . . . . 31 107 9.2.1.4. calendar-data-types XML Element . . . . . . . . . 32 108 9.2.1.5. attachments XML Element . . . . . . . . . . . . . 33 109 9.2.1.6. max-content-length XML Element . . . . . . . . . . 34 110 9.2.1.7. min-date-time XML Element . . . . . . . . . . . . 35 111 9.2.1.8. max-date-time XML Element . . . . . . . . . . . . 35 112 9.2.1.9. max-instances XML Element . . . . . . . . . . . . 35 113 9.2.1.10. max-recipients XML Element . . . . . . . . . . . . 36 114 9.2.1.11. administrator XML Element . . . . . . . . . . . . 36 115 10. Security Considerations . . . . . . . . . . . . . . . . . . . 36 116 10.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 36 117 10.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 36 118 10.3. DNS Considerations . . . . . . . . . . . . . . . . . . . . 37 119 10.4. Attachment Considerations . . . . . . . . . . . . . . . . 37 120 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 121 11.1. Namespace Registration . . . . . . . . . . . . . . . . . . 37 122 11.1.1. iSchedule Namespace Registration . . . . . . . . . . . 37 123 11.2. HTTP Headers Registration . . . . . . . . . . . . . . . . 38 124 11.2.1. DKIM-Signature Request Header Registration . . . . . . 38 125 11.2.2. iSchedule-Version General Header Registration . . . . 38 126 11.2.3. iSchedule-Capabilities Response Header Registration . 38 127 11.2.4. iSchedule-Message-ID Request Header Registration . . . 39 128 11.2.5. Originator Request Header Registration . . . . . . . . 39 129 11.2.6. Recipient Request Header Registration . . . . . . . . 39 130 11.3. Well-Known URI Registration . . . . . . . . . . . . . . . 39 131 11.3.1. iSchedule Well-Known URI Registration . . . . . . . . 40 132 11.3.2. DKIM Well-Known URI Registration . . . . . . . . . . . 40 133 11.4. DKIM Parameters Registration . . . . . . . . . . . . . . . 40 134 11.4.1. DKIM-Signature Query Method Registry . . . . . . . . . 40 135 11.4.2. DKIM Service Type Registration . . . . . . . . . . . . 40 136 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 137 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 138 13.1. Normative References . . . . . . . . . . . . . . . . . . . 41 139 13.2. Informative References . . . . . . . . . . . . . . . . . . 43 140 Appendix A. Example Scheduling Transactions . . . . . . . . . . . 43 141 A.1. Example: Simple Meeting Invitation . . . . . . . . . . . . 43 142 A.2. Example: Search for Busy Time Information . . . . . . . . 45 143 A.3. Example: Failed Request . . . . . . . . . . . . . . . . . 47 144 Appendix B. Change Log (to be removed by RFC Editor prior to 145 publication) . . . . . . . . . . . . . . . . . . . . 49 146 B.1. Changes in -05 . . . . . . . . . . . . . . . . . . . . . . 49 147 B.2. Changes in -04 . . . . . . . . . . . . . . . . . . . . . . 49 148 B.3. Changes in -03 . . . . . . . . . . . . . . . . . . . . . . 49 149 B.4. Changes in -02 . . . . . . . . . . . . . . . . . . . . . . 50 150 B.5. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 50 152 1. Introduction 154 This binding document provides the transport specific information 155 necessary to convey iCalendar Transport-independent Interoperability 156 Protocol (iTIP) [RFC5546] messages over the Hypertext Transfer 157 Protocol (HTTP) [RFC2616]. 159 The Internet Calendar Scheduling Protocol (iSchedule) enables 160 interoperability between different calendaring and scheduling 161 systems. Calendaring and scheduling systems that provide support for 162 iSchedule allow their users to perform scheduling transactions such 163 as schedule, reschedule, respond to scheduling request or cancel 164 scheduled calendar components, as well as search for busy time 165 information with users of other calendaring and scheduling systems on 166 the Internet. 168 iSchedule leverages the DomainKeys Identified Mail (DKIM) service 169 [RFC6376] to provide end-to-end domain-level authentication based on 170 message content that is transparent to end users. 172 Discussion of this Internet-Draft is taking place on the mailing list 173 . 175 1.1. Motivations 177 The iCalendar Message-Based Interoperability Protocol (iMIP) 178 [RFC6047], has proven to be insufficient to allow users to seamlessly 179 perform the same scheduling operations with users of other 180 calendaring and scheduling systems on the Internet as with users of 181 their own system. This section clarifies the motivations for a 182 binding from the iCalendar Transport-independent Interoperability 183 Protocol (iTIP) [RFC5546] to a transport that allows synchronous end- 184 to-end connectivity. 186 A binding to an email-based transport is clearly inadequate to search 187 for busy time information since users need and expect to get an 188 immediate response. As such, some calendaring and scheduling systems 189 allow users to publish their free busy information in a resource 190 accessible to others on the Internet. In the absence of a 191 standardized mechanism to locate the resource that provides the free 192 busy information of a user, one thus needs to know the location of 193 this resource in addition to the calendar user address of the users 194 one wishes to schedule with. 196 With an email-based transport, the transparent processing of incoming 197 scheduling messages on the server is only possible when the 198 calendaring and scheduling system is integrated with the email 199 system. Commonly, the processing of incoming scheduling messages 200 occurs on the client and requires user intervention, which yields the 201 following consequences: 203 1. The processing of incoming scheduling messages and the 204 corresponding updates to the calendar only occur when the client 205 is active. As a result, free busy information may be inaccurate 206 (e.g., user still appears busy when the organizer actually 207 rescheduled or canceled the meeting). 209 2. Calendaring and scheduling systems generally restrain the number 210 of updates sent to users to reduce the number of messages that 211 will clutter their email inbox. As a result, attendees rarely 212 obtain up to date participation status of other attendees. 214 3. The client becomes responsible for verification of the 215 authenticity and integrity of the scheduling message. 217 1.2. Related Memos 219 Implementers will need to be familiar with other documents that, 220 along with this document, form a framework for Internet calendaring 221 and scheduling standards. 223 This document specifies a binding from iTIP to HTTP. 225 o iCalendar [RFC5545] specifies a core specification of objects, 226 data types, properties and property parameters; 228 o iTIP [RFC5546] specifies an interoperability protocol for 229 scheduling between different implementations. 231 Furthermore, implementers will need to be familiar with the 232 DomainKeys Identified Mail (DKIM) service defined in [RFC6376]. An 233 overview of DKIM can be found in [RFC5585]. 235 This document does not attempt to repeat the specification of 236 concepts or definitions from these other documents. Where possible, 237 references are made to the document that provides the specification 238 of these concepts or definitions. 240 1.3. Terminology 242 This specification reuses much of the same terminology as iCalendar 243 [RFC5545], iTIP [RFC5546], HTTP [RFC2616], and DKIM [RFC6376]. 244 Additional terms used by this specification are: 246 Scheduling message: An iCalendar [RFC5545] object conforming to the 247 requirements of iTIP [RFC5546]. 249 Originator: The calendar user who is sending a scheduling message to 250 one or more other calendar users. 252 Recipient: A calendar user to whom a scheduling message is being 253 sent. 255 iSchedule Sender: The iSchedule service responsible for sending 256 scheduling messages. 258 iSchedule Receiver: The iSchedule service responsible for receiving 259 scheduling messages. 261 1.4. Notational Conventions 263 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 264 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 265 document are to be interpreted as described in [RFC2119]. 267 The Augmented BNF (ABNF) syntax used by this document to describe 268 protocol elements is defined in [RFC5234]. 270 Definitions of XML elements in this document use XML element type 271 declarations (as found in XML Document Type Declarations), described 272 in Section 3.2 of [W3C.REC-xml-20081126]. 274 The namespace "urn:ietf:params:xml:ns:ischedule" is reserved for the 275 XML elements defined in this specification, or in other Standards 276 Track IETF RFCs written to extend iSchedule. It MUST NOT be used for 277 proprietary extensions. When XML element types in this namespace are 278 referenced in this document outside of the context of an XML 279 fragment, the string "IS:" will be prefixed to the element type 280 names. 282 Note that the XML declarations used in this document are incomplete, 283 in that they do not include namespace information. Thus, the reader 284 MUST NOT use these declarations as the only way to validate iSchedule 285 XML element types. 287 2. iSchedule Model 289 The iSchedule design can be pictured as: 291 +----------+ +-----------+ +-----------+ +----------+ 292 | Calendar | | Calendar | | Calendar | | Calendar | 293 | Store | | Service | iSchedule | Service | | Store | 294 | or |-->|===========|----------->|===========|-->| or | 295 | User | | iSchedule | | iSchedule | | User | 296 | Agent | | Sender | | Receiver | | Agent | 297 +----------+ +-----------+ +-----------+ +----------+ 298 | | 299 <--------------------------> 300 DKIM Signature/Verification 302 When an iSchedule Sender has a scheduling message to transmit, it 303 determines the iSchedule Receivers to which to deliver the message 304 and sends the appropriate iSchedule message. The iSchedule Receiver 305 verifies the authenticity and content of the iSchedule message and 306 delivers it to the Calendar Service. 308 The means by which a Calendar Store or User Agent instructs a 309 Calendar Service, acting as an iSchedule Sender, to transmit 310 scheduling messages is outside the scope of this document. A 311 Calendar Service could provide support for a standard calendar access 312 protocol, such as CalDAV [RFC4791], [RFC6638] or any other protocol, 313 to allow a Calendar User Agent to perform scheduling operations with 314 users of other Calendar Services. 316 Likewise, the actual processing of scheduling messages received by a 317 Calendar Service, acting as an iSchedule Receiver, is also outside 318 the scope of this document. Some Calendar Service implementations 319 may decide to process some or all received scheduling messages, while 320 other implementations may decide to leave that work to Calendar User 321 Agent implementations. 323 3. iSchedule Overview 325 This section provides an overview of the various steps involved for 326 iSchedule Senders and Receivers to transmit scheduling messages 327 between Calendar Services. It references later sections describing 328 the precise details of each step. 330 3.1. iSchedule Sender Actions 332 A Calendar Service will generate an iTIP [RFC5546] scheduling message 333 for transmission. It will additionally provide details of the 334 Originator and Recipients. The Calendar Service will "submit" the 335 scheduling message and details to the iSchedule Sender, through a 336 process that is outside the scope of this document. 338 The iSchedule Sender MUST verify the authenticity of the Originator 339 and the Originator's authorization to send the scheduling message. 340 In particular the "ORGANIZER" iCalendar property value MUST match the 341 Originator calendar user address. The process by which this 342 authentication and authorization is done is outside the scope of this 343 document. 345 For each Recipient, the iSchedule Sender will attempt to lookup a 346 matching iSchedule Receiver to which the iSchedule message can be 347 sent, following the rules in Section 4. After determining the 348 iSchedule Receiver to use, the iSchedule Sender MUST check the 349 capabilities of the iSchedule Receiver to ensure it will be able to 350 accept the scheduling message that needs to be sent, as per 351 Section 5. 353 The iSchedule Sender MUST group together Recipients for whom the 354 iSchedule Receiver is the same, so that a single scheduling message 355 is sent for multiple Recipients, within the limits of the IS:max- 356 recipients (Section 9.2.1.10) value specified in the iSchedule 357 Receiver's capabilities. 359 For each group of Recipients handled by the same iSchedule Receiver, 360 the iSchedule Sender will construct an HTTP request, as per 361 Section 6, with the body of the HTTP request containing the iSchedule 362 message. Note, in the case of a "VFREEBUSY" iSchedule message, the 363 iSchedule Sender MUST ensure that iCalendar "ATTENDEE" properties in 364 the iSchedule message match one-for-one with the Recipients listed in 365 the HTTP request header. 367 After constructing the HTTP request, the iSchedule Sender MUST 368 generate a DKIM signature for the request and include a "DKIM- 369 Signature" (Section 8.1) request header, as per Section 7. 371 The iSchedule Sender then sends the HTTP request to the iSchedule 372 Receiver handling the Recipient group, and receives the HTTP 373 response, which will be an XML document with either an IS:schedule- 374 response or IS:error element as the root element. 376 The iSchedule Sender aggregates the results for each Recipient group 377 receiving an iSchedule message, and returns the resulting status 378 information for each Recipient to the Calendar Service that generated 379 the schedule message. The process by which this is done is outside 380 the scope of this document. 382 3.2. iSchedule Receiver Actions 384 iSchedule Receivers MUST provide a capabilities document to Senders, 385 as per Section 5. 387 Upon receipt of an iSchedule HTTP request, the iSchedule Receiver 388 verifies the message as per Section 7.4. 390 Once the authenticity of the message is confirmed, the iSchedule 391 Receiver delivers the scheduling message to the indicated recipients, 392 collects and aggregates the delivery status for each recipient, and 393 returns the result in the HTTP response body. 395 In the event of a processing error related to the overall request, 396 iSchedule Receivers MUST return an error response as per 397 Section 6.1.2. 399 4. iSchedule Receiver Discovery 401 This section describes how an iSchedule Sender can discover the host 402 name, port, and the path to use to submit an HTTP request to an 403 iSchedule Receiver. 405 For each Recipient to whom a scheduling message is being sent, the 406 iSchedule Sender will "resolve" the associated calendar user address 407 into a domain name, as per Section 4.1. 409 The iSchedule Sender then uses the extracted domain name to issue a 410 DNS SRV query for the iSchedule service (Section 4.2) expected to be 411 hosted at the domain. 413 The result of an SRV record lookup will be a target host name and a 414 port, as per [RFC2782]. An iSchedule Sender uses these to contact 415 the iSchedule Receiver. iSchedule Senders MUST honor the full 416 behavior of SRV records, in particular the TTL, Priority and Weight 417 options in the record, as well as handling multiple records being 418 returned, as per [RFC2782]. 420 Since an iSchedule Receiver is an HTTP server, an iSchedule Sender 421 needs to supply a Request-URI in the HTTP request it makes to the 422 iSchedule Receiver, in addition to the host name and port 423 information. iSchedule Senders MUST use the path specified in any TXT 424 records accompanying the SRV record (as per Section 4.3), or in the 425 absence of a matching TXT record, MUST use the .well-known URI (as 426 per Section 4.4). 428 4.1. Resolving Calendar User Addresses 430 To deliver a scheduling message via the iSchedule protocol, an 431 iSchedule Sender needs to determine which iSchedule Receiver to use 432 for a particular recipient. Each recipient's calendar user address 433 is specified in one or more Recipient request headers. 435 A calendar user address as defined by iCalendar is simply a URI. 436 This is typically a mailto URI, but could potentially be any URI 437 type. However, only URIs containing a "host" element can be used to 438 extract the necessary information to locate an iSchedule Receiver. 440 To get the SRV record name to query for a given mailto URI, the 441 "domain" portion of the mailto URI is extracted and appended to the 442 service label "_ischedules._tcp.". 444 Example: 446 Calendar User Address: mailto:cyrus@example.com 448 Query SRV Record Name: _ischedules._tcp.example.com 450 In cases where the "domain" portion of the mailto URI contains one or 451 more levels of sub-domain, iSchedule Senders MAY choose to remove 452 successive levels of "sub-domain" if queries for that sub-domain fail 453 to return any SRV records. For example, a mailto URI with the full 454 domain "host.calendar.example.com" would first trigger a query using 455 the domain "host.calendar.example.com", then if that failed, the 456 domain "calendar.example.com" would be tried, then if that failed the 457 domain "example.com" would be tried. 459 4.2. iSchedule SRV Service Type 461 This specification adds an SRV service label for use with iSchedule: 463 ischedules: Identifies an iSchedule Receiver that uses HTTP with 464 transport layer security ([RFC2818]). 466 Example: service record for iSchedule Receiver with transport layer 467 security 469 _ischedules._tcp.example.com. IN SRV 0 1 443 ischedule.example.com. 471 4.3. iSchedule Service TXT Records 473 When SRV RRs are used to advertise iSchedule services, it is also 474 convenient to be able to specify a "context path" in the DNS to be 475 retrieved at the same time. To enable that, this specification uses 476 a TXT RR that follows the syntax defined in Section 6 of [RFC6763] 477 and defines a "path" key for use in that record. The value of the 478 key MUST be the actual "context path" to the corresponding service on 479 the iSchedule Receiver. 481 A site might provide TXT records in addition to SRV records for the 482 service. When present, iSchedule Senders MUST use the "path" value 483 as the "context path" for the service in HTTP requests. When not 484 present, iSchedule Senders use the ".well-known" URI approach 485 described next. 487 Example: text record for service with TLS 489 _ischedules._tcp TXT path=/ischedule 491 4.4. iSchedule Receiver Request-URI 493 This specification registers a well-known URI [RFC5785] for the 494 iSchedule service, namely, "ischedule" (see Section 11.3.1). 495 iSchedule Receivers MUST support requests targeted at this well-known 496 URI. iSchedule Senders MUST handle HTTP redirects on this well-known 497 URI. 499 5. iSchedule Receiver Capabilities 501 iSchedule Receivers supporting the features described in this 502 document MUST allow iSchedule Senders to query their capabilities by 503 accepting GET requests targeted at the Request-URI found during 504 discovery (Section 4). The response body for a successful GET 505 request targeted at this URI MUST be an XML document with IS:query- 506 result as its root element. 508 Informative rationale: The GET method was favored over the POST 509 method to allow iSchedule Senders to query capabilities with 510 "conditional GET" requests (see Section 9.3 of [RFC2616]). 512 iSchedule Receivers SHOULD use normal HTTP expiration mechanisms (as 513 per Section 13.1.3 of [RFC2616]) to ensure caches do not cache the 514 capabilities response for too long. iSchedule Senders SHOULD use 515 normal HTTP conditional GET requests when re-checking capabilities to 516 avoid re-transferring already cached data. 518 iSchedule Senders SHOULD use the information in the capabilities to 519 determine whether the iSchedule Receiver supports a version of the 520 protocol that the iSchedule Sender can use, and if not, not issue any 521 iSchedule requests with scheduling messages to the iSchedule 522 Receiver. iSchedule Senders SHOULD verify that the scheduling message 523 to be sent to the iSchedule Receiver is in line with the restrictions 524 on scheduling messages indicated by the capabilities before sending 525 the scheduling message. 527 5.1. Example: Querying iSchedule Receiver Capabilities 529 >> Request << 531 GET /.well-known/ischedule?action=capabilities HTTP/1.1 532 Host: cal.example.com 534 >> Response << 536 HTTP/1.1 200 OK 537 Date: Mon, 15 Dec 2008 09:32:12 GMT 538 Content-Type: application/xml; charset=utf-8 539 Content-Length: xxxx 540 iSchedule-Version: 1.0 541 iSchedule-Capabilities: 123 542 ETag: "afasdf-132afds" 544 545 546 547 123 548 549 1.0 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 571 572 573 574 576 577 102400 578 19910101T000000Z 579 20381231T000000Z 580 150 581 250 582 mailto:ischedule-admin@example.com< 583 /administrator> 584 585 587 6. Scheduling 589 This section defines how an iSchedule Sender can use the HTTP POST 590 method to submit a scheduling message to an iSchedule Receiver. 591 Note, this describes the HTTP request prior to generating a DKIM 592 signature as per Section 7. 594 6.1. POST Method 596 The POST method submits a scheduling message to one or more 597 Recipients by targeting the request at the Request-URI of an 598 iSchedule Receiver. The request body of a POST method MUST contain a 599 scheduling message (i.e., an iCalendar object that follows the iTIP 600 semantic). 602 The submitted scheduling message will be delivered to the Recipients, 603 with status information about per-recipient delivery returned in the 604 HTTP response. However, when the scheduling message is a request for 605 free-busy time, the iSchedule Receiver will immediately execute the 606 free-busy request for the Recipients and return per-recipient 607 iCalendar data in the response for successful free-busy queries. 609 Every POST request MUST include the "iSchedule-Version" 610 (Section 11.2.2) general header. 612 Every POST request SHOULD include the "iSchedule-Message-ID" 613 (Section 11.2.4) request header. 615 Every POST request MUST include the "Cache-Control" HTTP general 616 header containing the cache-directives "no-cache" and "no-transform" 617 to prevent intermediary caches from caching or transforming 618 responses. 620 Every POST request MUST include a single "Originator" 621 (Section 11.2.5) request header that specifies the calendar user 622 address of the Originator of the scheduling message. The value of 623 the "Originator" request header MUST match the value of the 624 "ORGANIZER" iCalendar property or one of the specified "ATTENDEE" 625 iCalendar properties in the scheduling message, depending on the 626 specified "METHOD" iCalendar property value as summarized in the 627 following table: 629 +----------------+-----------------------------------+ 630 | Method | Originator Requirement | 631 +----------------+-----------------------------------+ 632 | PUBLISH | MUST match ORGANIZER | 633 | REQUEST | MUST match ORGANIZER (see Note 1) | 634 | REPLY | MUST match ATTENDEE | 635 | ADD | MUST match ORGANIZER | 636 | CANCEL | MUST match ORGANIZER | 637 | REFRESH | MUST match ATTENDEE | 638 | COUNTER | MUST match ATTENDEE | 639 | DECLINECOUNTER | MUST match ORGANIZER | 640 +----------------+-----------------------------------+ 642 Table 1 644 Note 1: iTIP does allow an Attendee to forward a "METHOD:REQUEST" 645 scheduling message to another attendee. However, due to complexity 646 of managing the authorization of such requests, this specification 647 does not allow scheduling message forwarding. 649 Every POST request MUST include one or more "Recipient" 650 (Section 11.2.6) request headers. The value of this header is a list 651 of one or more calendar user addresses and corresponds to the set of 652 calendar users who will have the scheduling message delivered to 653 them. The value of the "Recipient" request header MUST match the 654 value of the "ORGANIZER" iCalendar property or one of the specified 655 "ATTENDEE" iCalendar properties in the scheduling message, depending 656 on the specified "METHOD" iCalendar property value as summarized in 657 the following table: 659 +----------------+----------------------------------+ 660 | Method | Recipient Requirement | 661 +----------------+----------------------------------+ 662 | PUBLISH | None (see Note 1) | 663 | REQUEST | MUST match ATTENDEE (see Note 1) | 664 | REPLY | MUST match ORGANIZER | 665 | ADD | MUST match ATTENDEE (see Note 1) | 666 | CANCEL | MUST match ATTENDEE (see Note 1) | 667 | REFRESH | MUST match ORGANIZER | 668 | COUNTER | MUST match ORGANIZER | 669 | DECLINECOUNTER | MUST match ATTENDEE | 670 +----------------+----------------------------------+ 671 Table 2 673 Note 1: iTIP does allow an Organizer to send scheduling message to 674 calendar users who are not listed as Attendees, e.g., to inform other 675 calendar users of an event taking place. However, due to complexity 676 of managing the authorization of such requests, this specification 677 does not allow such scheduling messages. 679 The Content-Type general header MUST include the type parameters 680 "component" and "method" defined in [RFC5545]. The value of the 681 "component" MUST correspond to the iCalendar component type (e.g., 682 "VEVENT") specified in the scheduling message. The value of the 683 "method" parameter MUST be the same as the value of the "METHOD" 684 iCalendar property in the scheduling message. 686 6.1.1. Schedule Response 688 A POST request may deliver a scheduling message to one or more 689 calendar users specified in the Recipient request header. Since the 690 behavior of each recipient may vary, it is useful to get response 691 status information for each recipient in the overall POST response. 692 This specification defines a new XML response to convey multiple 693 recipient status. 695 A response to a POST method that indicates status for one or more 696 recipients MUST be an XML document with IS:schedule-response as its 697 root element. This MUST contain one or more response elements for 698 each recipient, with each of those containing elements that indicate 699 which recipient they correspond to, the scheduling status of the 700 request for that recipient, any error codes and an optional 701 description. 703 In the case of a free-busy request, the response elements can also 704 contain calendar-data elements which contain free busy information 705 (e.g., an iCalendar VFREEBUSY component) indicating the busy state of 706 the corresponding recipient, assuming that the free-busy request for 707 that recipient succeeded. 709 Every POST response MUST include the "Cache-Control" HTTP general 710 header containing the cache-directives "no-cache" and "no-transform" 711 to prevent intermediary caches from caching or transforming 712 responses. 714 6.1.2. Failed Schedule Response 716 When there is an overall, as opposed to per-recipient, failure of the 717 POST request, the iSchedule Receiver SHOULD return an XML document 718 with IS:error as its root element. The child elements of the IS: 720 error element are used to indicate an error code and description, 721 primarily meant for service administrators. 723 The following XML elements are error codes which can be used within 724 an IS:error element to represent errors: 726 IS:version-not-supported: The POST request was either missing an 727 "iSchedule-Version" header, or had an "iSchedule-Version" header 728 value for a version not supported by the iSchedule Receiver, as 729 advertised in the IS:versions capability. 731 IS:invalid-calendar-data-type: The resource submitted in the POST 732 request was not a supported media type (i.e. text/calendar) for 733 scheduling or free-busy messages; 735 IS:invalid-calendar-data: The resource submitted in the POST 736 request was not valid data for the media type being specified; 738 IS:invalid-scheduling-message: The resource submitted in the POST 739 request did not obey all restrictions specified for the POST 740 request, violating the IS:scheduling-message capability element, 741 or the requirements of iTIP; 743 IS:verification-failed: The POST request failed DKIM verification; 745 IS:originator-missing: The POST request did not include an 746 "Originator" request header specifying the calendar user address 747 of the Originator of the scheduling message. 749 IS:too-many-originators: The POST request contained more than one 750 "Originator" request header. 752 IS:originator-invalid: The "Originator" header in the POST request 753 did not include a valid calendar user address for the Originator 754 of the scheduling message. 756 IS:originator-denied: The calendar user identified by the 757 "Originator" header in the POST request is not allowed to use this 758 service. 760 IS:recipient-missing: The POST request did not include one or more 761 valid "Recipient" request headers specifying the calendar user 762 address of users to whom the scheduling message will be delivered. 764 IS:recipient-mismatch: The POST request did not include 765 "Recipient" request header values which exactly match the list of 766 "ATTENDEE" property values in a "VFREEBUSY" request. 768 IS:max-recipients: The POST request had too many calendar user 769 addresses specified in "Recipient" request headers, violating the 770 IS:max-recipients capability. 772 IS:attachment-type-not-supported: The scheduling message submitted 773 in the POST request had iCalendar data with "ATTACH" properties 774 whose value type is not supported, violating the IS:attachments 775 capability. 777 IS:max-content-length: The scheduling message submitted in the 778 POST request had iCalendar data violating the IS:max-content- 779 length capability. 781 IS:min-date-time: The scheduling message submitted in the POST 782 request had iCalendar data violating the IS:min-date-time 783 capability. 785 IS:max-date-time: The scheduling message submitted in the POST 786 request had iCalendar data violating the IS:max-date-time 787 capability. 789 IS:max-instances: The scheduling message submitted in the POST 790 request had iCalendar data violating the IS:max-instances 791 capability. 793 The following are examples of response codes one would expect to be 794 used for this method. Note, however, that unless explicitly 795 prohibited any 2/3/4/5xx series response code may be used in a 796 response. Typically a 403 response code would be used when an XML 797 document with an IS:error element as its root is also returned. 799 200 (OK) - The command succeeded. 801 400 (Bad Request) - The Sender has provided an invalid scheduling 802 message, or invalid iSchedule request headers. 804 403 (Forbidden) - The Sender cannot submit a scheduling message to 805 the specified Request-URI. 807 404 (Not Found) - The URL in the Request-URI was not present. 809 507 (Insufficient Storage) - The server did not have sufficient 810 space to record the scheduling message. 812 7. iSchedule Domain-Level Authentication 814 iSchedule uses and extends the mechanism defined by DomainKeys 815 Identified Mail (DKIM) [RFC6376]. DKIM defines a domain-level 816 digital signature authentication framework for email, using public- 817 key cryptography, with the domain name service (DNS) as one possible 818 key server technology. 820 This specification extends the applicability of DKIM to the HTTP 821 protocol, with a specific "profile" for use with iSchedule messages. 822 Additionally, DKIM support is REQUIRED for all iSchedule requests, 823 and iSchedule Receivers MUST reject any messages which cannot be 824 verified according to the requirements of DKIM. This is a much 825 stronger requirement than the email use of DKIM, which has to deal 826 with legacy systems. 828 iSchedule Senders MUST only send iSchedule messages for Originators 829 whose authenticity they have verified. iSchedule Receivers that 830 verify a DKIM signature on an iSchedule request can assume that the 831 iSchedule Sender is not only taking responsibility for sending the 832 message, but has also verified the authenticity of the Originator. 833 As such, iSchedule Receivers can reliably use the Originator 834 information to perform their own authorization based on that value. 835 e.g., the Calendar Service to which an iSchedule Receiver delivers a 836 scheduling message, can apply "filtering" rules to such messages 837 based on the guarantee that the Originator calendar user address has 838 been verified at both the iSchedule Sender and Receiver ends. 840 This specification uses the syntactic elements of DKIM [RFC6376], but 841 modified for use with HTTP. Where definitions of syntactic elements 842 of DKIM [RFC6376] are applicable to HTTP, they will be used by 843 reference. In cases where the HTTP definition is different, the same 844 ABNF rule name will be used, but the value modified as appropriate. 846 The following sections describe how the DomainKeys Identified Mail 847 (DKIM) service can fit into a scheduling service. 849 7.1. Signature Content 851 The following HTTP headers MUST be included in the signature of a 852 message: 854 o Content-Type 856 o iSchedule-Version 858 o Originator 859 o Recipient 861 The iSchedule Receiver MUST verify that the above HTTP headers are 862 included in the signature. 864 iSchedule Senders and Receivers might use HTTP authentication 865 [RFC2617] in requests, though the process through which credentials 866 are managed are out of scope for this document. If HTTP 867 authentication is used, then the "Authorization" HTTP request header 868 MUST be included in the signature of the message. 870 The following HTTP headers, if present, SHOULD be included in the 871 signature of a message: 873 o iSchedule-Message-ID 875 o User-Agent 877 To allow iSchedule messages to transit via HTTP intermediaries, hop- 878 by-hop headers, such as the following HTTP/1.1 headers MUST NOT be 879 included in the signature of a message: 881 o Cache-Control 883 o Connection 885 o Host 887 o Keep-Alive 889 o Proxy-Authenticate 891 o Proxy-Authorization 893 o TE 895 o Trailer 897 o Transfer-Encoding 899 o Upgrade 901 The "Content-Length" header MUST NOT be signed, since the DKIM 902 signature is generated prior to transfer encoding, and the header 903 value represents the length after any transfer encodings have been 904 applied. 906 iSchedule Senders MAY include an "x=" DKIM signature tag in the 907 "DKIM-Signature" header to indicate an expiration time for the 908 signature. When doing so, the "x=" value SHOULD be set to at least 1 909 minute ahead of the "t=" DKIM signature tag value, to account for 910 processing time between the iSchedule Sender and Receiver. 912 7.2. Canonicalization 914 iSchedule Senders and Receivers MUST use the "simple" body 915 canonicalization algorithm defined in Section 3.4.3 of DKIM [RFC6376] 916 to canonicalize the HTTP request message body used for the body hash 917 computation. The iSchedule Sender MUST calculate the body hash prior 918 to any HTTP transfer encodings being applied to the request message 919 body. The iSchedule Receiver MUST calculate the body hash after any 920 HTTP transfer encoding have been removed from the request message 921 body. 923 iSchedule Senders and Receivers MUST use the new "ischedule-relaxed" 924 header canonicalization algorithm defined below to canonicalize the 925 HTTP request headers used for the signature computation. 927 7.2.1. The "ischedule-relaxed" Header Canonicalization Algorithm 929 The "ischedule-relaxed" header canonicalization algorithm is used to 930 canonicalize HTTP header fields where multiple headers fields with 931 the same name might be combined by an HTTP intermediary. The 932 following steps MUST be applied in order: 934 1. Convert all header field names (not the header field values) to 935 lowercase. For example, convert "SUBJect: AbC" to "subject: 936 AbC". 938 2. Unfold all header field continuation lines; in particular, lines 939 with terminators embedded in continued header field values (that 940 is, CRLF sequences followed by LWS) MUST be interpreted without 941 the CRLF. Implementations MUST NOT remove the CRLF at the end of 942 the header field value. 944 3. Combine multiple header fields with the same field name into one 945 one header field value; specifically, append each subsequent 946 field value to the combined field value in order, separated by a 947 comma. For example, combine 948 "recipient:mailto:cyrus@example.com,mailto:mike@example.com" and 949 "recipient:mailto:ken@example.org" into "recipient:mailto:cyrus@ 950 example.com,mailto:mike@example.com,mailto:ken@example.org" 952 4. Convert all sequences of one or more LWS characters to a single 953 SP character. LWS characters here include those before and after 954 a line folding boundary. 956 5. Delete all WS characters at the end of each unfolded header field 957 value. 959 6. Delete any LWS characters remaining before and after the colon 960 separating the header field name from the header field value. 961 The colon separator MUST be retained. 963 7. Delete any LWS characters remaining before and after any commas 964 in the header field value. 966 Since this canonicalization algorithm "collapses" multiple HTTP 967 header fields into a single header field, the h= tag used in the 968 "DKIM-Signature" request header MUST contain only a single value for 969 each different header field name being signed. 971 7.3. Key Management 973 7.3.1. DNS-based Public Key Management 975 Section 3.6.2 of DKIM [RFC6376] defines a DNS-based key-binding for 976 public key retrieval. iSchedule Senders and Receivers MUST support 977 this method of public key retrieval. To allow public keys to be 978 restricted to just an iSchedule service, this specification defines a 979 new service type "ischedule" to constrain the use of a key to 980 iSchedule: 982 ABNF: 984 key-s-tag-type /= "ischedule" 986 7.3.2. HTTP-based Public Key Management 988 This specification defines a new HTTP-based public key management 989 method for use with DKIM [RFC6376]. The "DKIM-Signature" header "q" 990 tag value associated with this method is "http/well-known": 992 ABNF: 994 sig-q-tag-method /= "http/well-known" 996 Key lookup first involves retrieving an SRV record that will provide 997 the HTTP server host name and port to use for actual key retrieval. 998 Then the key retrieval is done via an HTTP GET request on a .well- 999 known resource. This new key management approach off-loads the key 1000 handling from DNS to an HTTP server, only requiring the DNS 1001 administrator to provide the SRV records for authorized HTTP key 1002 management servers. 1004 7.3.2.1. SRV Service Type 1006 This specification adds one SRV service label for use with HTTP key 1007 management: 1009 domainkey_lookup: Identifies an HTTP server from which public keys 1010 for DKIM signatures can be retrieved. The HTTP server MUST 1011 support transport layer security ([RFC2818]). 1013 The iSchedule Receiver determines the appropriate SRV name using the 1014 "d=" DKIM signature tag value in the "DKIM-signature" header being 1015 verified: 1017 _domainkey_lookup._tcp.{d}. 1019 ; {d} is the d= value from the "DKIM-Signature" header. 1021 7.3.2.2. Well-known Request-URI 1023 This specification registers a well-known URI [RFC5785] for the DKIM 1024 HTTP-based public key management information, "domainkey" (see 1025 Section 11.3.2). To retrieve information about the public key used 1026 to sign an iSchedule message, the iSchedule Sender constructs a URI 1027 of the form: 1029 https://{srv-host}:{srv-port}/.well-known/domainkey/{d}/{s} 1031 ; {srv-host} is the host name from the _domainkey_lookup SRV record 1032 ; {srv-port} is the port number from the _domainkey_lookup SRV record 1033 ; {d} is the d= value from the "DKIM-Signature" header. 1034 ; {s} is the s= value from the "DKIM-Signature" header. 1036 Documents retrieved from the well-known URI MUST be text documents 1037 with a media-type of "text/plain". The format of the text document 1038 is: 1040 key-doc = 1*(tag-list CRLF) 1041 ; tag-list is defined in Section 3.2 of 1043 where tag-list is the unstructured textual form defined in Section 1044 3.6.1. of [RFC6376] - i.e., the same data that would be placed in a 1045 DNS TXT record for DNS-based public key management. Note that this 1046 allows information for multiple keys to be returned for each {domain- 1047 name}, {selector} pair. iSchedule Receivers must use HTTP+TLS 1048 (https:) to retrieve the public key information document, and follow 1049 the certificate-verification process specified in [RFC6125]. 1051 7.3.2.3. Example Lookup Procedure 1053 Given the following (partial) DKIM-Signature header, the steps below 1054 describe how a public key is retrieved from the HTTP pubic key 1055 management system. 1057 DKIM-Signature:q=http/well-known;d=cal.example.com;s=isched; ... 1059 1. The iSchedule Receiver first does an SRV record lookup for 1060 "_domainkey_lookup._tcp.cal.example.com", and gets back the 1061 following example record: 1063 _domainkey_lookup._tcp.cal.example.com. IN SRV 0 1 443 is.example.com. 1065 2. the iSchedule Receiver then makes an HTTP request: 1067 https://is.example.com:443/.well-known/domainkey/cal.example.com/isched 1069 3. It parses the returned document to determine the appropriate 1070 public key to use to verify the DKIM signature. 1072 7.3.3. Private Exchange Public Key Management 1074 This specification defines a new public key management method for use 1075 with DKIM [RFC6376]. This method is used to indicate that the 1076 associated public key has been transferred to the recipient through 1077 some (unspecified, secure) private exchange. The "DKIM-Signature" 1078 header "q" tag value associated with this method is "private- 1079 exchange": 1081 ABNF: 1083 sig-q-tag-method /= "private-exchange" 1085 This method is useful, for example, in situations where an "internal" 1086 deployment of iSchedule is being used to connect different calendar 1087 systems within an organization. It avoids the need to setup other 1088 public key discovery mechanisms when a simple, secure public key 1089 exchange can be accomplished between the system administrators. 1091 7.4. Verification Requirements 1093 iSchedule Receivers MUST verify the follow details: 1095 The HTTP request contains an "iSchedule-Version" header that 1096 matches a version of the iSchedule protocol that the iSchedule 1097 Receiver supports. 1099 Only one Originator HTTP request header is present in the request 1100 and it matches the appropriate iCalendar property as per Table 1. 1102 One or more Recipient HTTP request headers are present in the 1103 request and they match the appropriate iCalendar properties as per 1104 Table 2. 1106 The "DKIM-Signature" header contains valid information and the 1107 signature and body hash values can be verified correctly. Note, 1108 for the t= value in the "DKIM-Signature", iSchedule Receivers 1109 SHOULD accept values that are no more than 5 minutes in the 1110 future, to account for possible clock skew between iSchedule 1111 Sender and Receiver. 1113 If the signature cannot be verified, the iSchedule Receiver MUST 1114 reject the iSchedule message outright. 1116 If the signature is valid, then iSchedule Receivers have a guarantee 1117 that the iSchedule Sender has verified the authenticity of the 1118 Originator and determined they are authorized to send the enclosed 1119 iTIP message. This allows iSchedule Receivers to use the Originator 1120 calendar user address value for access control purposes. 1122 7.5. Authorized Third-Party Signatures 1124 The third-party signature authorization protocol defined in [RFC6541] 1125 MAY be used by iSchedule Senders and Receivers. 1127 8. HTTP Headers 1129 This section defines the syntax and semantics of additional HTTP/1.1 1130 header fields. 1132 The header's syntax uses the optional whitespace (OWS) rule defined 1133 as follows: 1135 OWS = *( [ CRLF ] WSP ) 1137 8.1. DKIM-Signature Request Header 1139 The "DKIM-Signature" request header MUST be specified by the 1140 iSchedule Sender on all scheduling requests to specify all of the 1141 signature and key-fetching data. 1143 DKIM-Signature = "DKIM-Signature" ":" OWS DKIM-Signature-v 1144 DKIM-Signature-v = tag-list 1145 ; tag-list is defined in Section 3.2 of 1147 8.2. iSchedule-Version General Header 1149 The "iSchedule-Version" general header field MUST be specified by the 1150 iSchedule Sender on requests, and by the iSchedule Receiver on 1151 responses. It SHOULD be included in a response to any "OPTIONS *" 1152 HTTP request targeting the iSchedule Receiver, or any "OPTIONS" 1153 request on a resource supporting the iSchedule behaviors described in 1154 this specification (e.g., the .well-known resource or any resource 1155 that .well-known redirects to). 1157 iSchedule-Version = "iSchedule-Version" ":" OWS 1158 iSchedule-Version-v 1159 iSchedule-Version-v = iSchedule-Version-elem 1160 *( OWS "," OWS iSchedule-Version-elem ) 1161 iSchedule-Version-elem = 1*DIGIT "." 1*DIGIT 1163 8.3. iSchedule-Capabilities Response Header 1165 The "iSchedule-Capabilities" response header field MUST be specified 1166 by the iSchedule Receiver on all responses. iSchedule Senders SHOULD 1167 cache this value and use it to detect a change in the iSchedule 1168 Receiver capabilities that cause the iSchedule Sender to reload 1169 capabilities. The value of this header is maintained by the 1170 iSchedule Receiver as described in Section 9.2.1.1. 1172 iSchedule-Capabilities = "iSchedule-Capabilities" ":" OWS 1*DIGIT 1174 8.4. iSchedule-Message-ID Request Header 1176 The "iSchedule-Message-ID" request header field SHOULD be specified 1177 by the iSchedule Sender on requests. This header provides a unique 1178 identifier that refers to the specific iSchedule request in which it 1179 is included. The uniqueness of this identifier is guaranteed by the 1180 iSchedule Sender that generates it. This identifier is intended to 1181 be machine readable and not necessarily meaningful to humans. 1183 iSchedule-Message-ID = "iSchedule-Message-ID" ":" OWS token 1185 8.5. Originator Request Header 1187 The "Originator" request header value is a URI which specifies the 1188 calendar user address of the originator of the scheduling message. 1189 Note that the absoluteURI rule is defined in [RFC3986]. 1191 Originator = "Originator" ":" OWS Originator-v 1192 Originator-v = absoluteURI 1194 8.6. Recipient Request Header 1196 The "Recipient" request header value is a URI which specifies the 1197 calendar user address of the recipients to which the POST method 1198 should deliver the submitted scheduling message. Note that the 1199 absoluteURI rule is defined in [RFC3986]. 1201 Recipient = "Recipient" ":" OWS Recipient-v 1202 Recipient-v = Recipient-elem *( OWS "," OWS Recipient-elem ) 1203 Recipient-elem = absoluteURI 1205 9. XML Element Definitions 1207 9.1. schedule-response XML Element 1209 Name: schedule-response 1211 Namespace: urn:ietf:params:xml:ns:ischedule 1213 Purpose: Contains the set of responses for a POST method request. 1215 Description: See Section 6.1.1. 1217 Definition: 1219 1221 9.1.1. response XML Element 1223 Name: response 1225 Namespace: urn:ietf:params:xml:ns:ischedule 1227 Purpose: Contains a single response for a POST method request. 1229 Description: See Section 6.1.1. 1231 Definition: 1233 1239 9.1.1.1. recipient XML Element 1241 Name: recipient 1243 Namespace: urn:ietf:params:xml:ns:ischedule 1245 Purpose: The calendar user address (recipient header value) that the 1246 enclosing response for a POST method request is for. 1248 Description: See Section 6.1.1. 1250 Definition: 1252 1254 9.1.1.2. request-status XML Element 1256 Name: request-status 1258 Namespace: urn:ietf:params:xml:ns:ischedule 1260 Purpose: The iTIP REQUEST-STATUS property value for this response. 1262 Description: See Section 6.1.1. 1264 Definition: 1266 1268 9.1.1.3. calendar-data XML Element 1270 Name: calendar-data 1272 Namespace: urn:ietf:params:xml:ns:ischedule 1274 Purpose: An iCalendar object in a response to a search for busy time 1275 information. 1277 Description: See Section 6.1.1. 1279 Definition: 1281 1283 9.1.1.4. error XML Element 1285 Name: error 1287 Namespace: urn:ietf:params:xml:ns:ischedule 1289 Purpose: Error responses sometimes need more information to indicate 1290 what went wrong. 1292 Description: See Section 6.1.1. 1294 Definition: 1296 1298 9.1.1.5. response-description XML Element 1300 Name: response-description 1302 Namespace: urn:ietf:params:xml:ns:ischedule 1304 Purpose: Contains information about a status response 1306 Description: See Section 6.1.1. 1308 Definition: 1310 1312 9.2. query-result XML Element 1314 Name: query-result 1316 Namespace: urn:ietf:params:xml:ns:ischedule 1318 Purpose: Contains result of a query request. 1320 Description: A generic container for the result of a query request, 1321 such as a query of the capabilities of an iSchedule Receiver. 1323 Definition: 1325 1327 9.2.1. capabilities XML Element 1329 Name: capabilities 1331 Namespace: urn:ietf:params:xml:ns:ischedule 1333 Purpose: Contains iSchedule Receiver capabilities. 1335 Description: The capabilities element contains capabilities of the 1336 iSchedule Receiver. 1338 Definition: 1340 1353 9.2.1.1. serial-number XML Element 1355 Name: serial-number 1357 Namespace: urn:ietf:params:xml:ns:ischedule 1359 Purpose: Identifies the version of the capabilities information. 1361 Description: This is a numeric value maintained by the iSchedule 1362 Receiver. The value is incremented by the iSchedule Receiver each 1363 time there has been a substantive change to the capabilities that 1364 would require an iSchedule Sender to reload the capabilities to 1365 adjust its behavior. The value of this element MUST be returned 1366 by the iSchedule Receiver in all HTTP requests via the "iSchedule- 1367 Capabilities" response header (Section 8.3). This allows 1368 iSchedule Senders to detect changes to the iSchedule Receiver's 1369 capabilities during the normal course of making requests, without 1370 the need to poll the iSchedule Receiver for such changes. 1372 Definition: 1374 1375 1377 9.2.1.2. versions XML Element 1379 Name: versions 1381 Namespace: urn:ietf:params:xml:ns:ischedule 1383 Purpose: Identifies the iSchedule versions supported by the 1384 iSchedule Receiver. 1386 Description: An iSchedule Receiver MAY advertise support for 1387 multiple versions of the iSchedule protocol. iSchedule Senders 1388 check this value to ensure they can send iSchedule messages with a 1389 matching version. 1391 Definition: 1393 1395 9.2.1.2.1. version XML Element 1397 Name: version 1399 Namespace: urn:ietf:params:xml:ns:ischedule 1401 Purpose: Identifies an iSchedule protocol version. 1403 Definition: 1405 1406 1408 9.2.1.3. scheduling-messages XML Element 1410 Name: scheduling-messages 1412 Namespace: urn:ietf:params:xml:ns:ischedule 1414 Purpose: Identifies the type of supported scheduling messages. 1416 Description: An iSchedule Receiver advertises which iCalendar 1417 component types it will accept for iTIP messages sent to it. In 1418 addition, for each component, it can specify the allowed iTIP 1419 "METHOD" property values. 1421 Definition: 1423 1425 9.2.1.3.1. component XML Element 1427 Name: component 1429 Namespace: urn:ietf:params:xml:ns:ischedule 1431 Purpose: Identifies a calendar component type. 1433 Description: Used to specify a supported iCalendar component type 1434 for scheduling messages. If a IS:method child element is not 1435 present, then any iTIP "METHOD" property value can be used in iTIP 1436 messages sent to the iSchedule Receiver. If one or more IS:method 1437 elements are present, then those indicate the allowed set of iTIP 1438 "METHOD" property values. 1440 Definition: 1442 1444 1445 1447 9.2.1.3.1.1. method XML Element 1449 Name: method 1451 Namespace: urn:ietf:params:xml:ns:ischedule 1453 Purpose: Identifies an iCalendar method type. 1455 Description: See IS:component. 1457 Definition: 1459 1461 1462 1464 9.2.1.4. calendar-data-types XML Element 1465 Name: calendar-data-types 1467 Namespace: urn:ietf:params:xml:ns:ischedule 1469 Purpose: Identifies what formats of iCalendar data are acceptable. 1471 Definition: 1473 1475 9.2.1.4.1. calendar-data-type XML Element 1477 Name: calendar-data-type 1479 Namespace: urn:ietf:params:xml:ns:ischedule 1481 Purpose: Identifies a supported media type and version for iTIP 1482 messages. 1484 Definition: 1486 1488 1490 1491 1493 9.2.1.5. attachments XML Element 1495 Name: attachments 1497 Namespace: urn:ietf:params:xml:ns:ischedule 1499 Purpose: Identifies the attachment values supported. 1501 Description: iSchedule Receivers might restrict what form of 1502 attachments are allowed in iTIP messages that are sent to it, for 1503 performance, or security reasons. In iCalendar data, attachments 1504 can either be specified using "inline" data in the form of a 1505 base64 encoded property value, or "external" data in the form of a 1506 URI property value. With this capability, an iSchedule Receiver 1507 can specify which of "inline" or "external" values it will accept 1508 in iTIP messages. See Section 10.4 for additional details. 1510 Definition: 1512 1514 9.2.1.5.1. inline XML Element 1516 Name: inline 1518 Namespace: urn:ietf:params:xml:ns:ischedule 1520 Purpose: Identifies "inline" attachments as a supported attachment 1521 value. 1523 Definition: 1525 1527 9.2.1.5.2. external XML Element 1529 Name: external 1531 Namespace: urn:ietf:params:xml:ns:ischedule 1533 Purpose: Identifies "external" attachments as a supported attachment 1534 value. 1536 Definition: 1538 1540 9.2.1.6. max-content-length XML Element 1542 Name: max-content-length 1544 Namespace: urn:ietf:params:xml:ns:ischedule 1546 Purpose: Identifies the maximum size allowed for a scheduling 1547 message in octets. 1549 Definition: 1551 1552 1554 9.2.1.7. min-date-time XML Element 1556 Name: min-date-time 1558 Namespace: urn:ietf:params:xml:ns:ischedule 1560 Purpose: A DATE-TIME value indicating the earliest date and time in 1561 UTC that the iSchedule Receiver is willing to accept for any DATE 1562 or DATE-TIME value in a scheduling message. 1564 Definition: 1566 1567 1569 9.2.1.8. max-date-time XML Element 1571 Name: max-date-time 1573 Namespace: urn:ietf:params:xml:ns:ischedule 1575 Purpose: A DATE-TIME value indicating the latest date and time in 1576 UTC that the iSchedule Receiver is willing to accept for any DATE 1577 or DATE-TIME value in a scheduling message. 1579 Definition: 1581 1582 1584 9.2.1.9. max-instances XML Element 1586 Name: max-instances 1588 Namespace: urn:ietf:params:xml:ns:ischedule 1590 Purpose: The maximum number of recurrence instances allowed in a 1591 scheduling message. 1593 Definition: 1595 1596 1598 9.2.1.10. max-recipients XML Element 1600 Name: max-recipients 1602 Namespace: urn:ietf:params:xml:ns:ischedule 1604 Purpose: The maximum number of recipients allowed for a scheduling 1605 message. 1607 Definition: 1609 1610 1612 9.2.1.11. administrator XML Element 1614 Name: administrator 1616 Namespace: urn:ietf:params:xml:ns:ischedule 1618 Purpose: Provides contact information for the administrator of the 1619 iSchedule Receiver. 1621 Definition: 1623 1624 1626 10. Security Considerations 1628 The process of scheduling involves the sending and receiving of 1629 scheduling messages. As a result, the security problems related to 1630 messaging in general are relevant here. In particular the 1631 authenticity of the scheduling messages needs to be verified. 1633 Potential attacks described in the security considerations of DKIM 1634 [RFC6376] are also applicable to iSchedule. 1636 10.1. Privacy 1638 iSchedule Senders and iSchedule Receivers MUST use an HTTP connection 1639 protected with TLS [RFC5246] as defined in [RFC2818] for all 1640 transactions. 1642 10.2. Authentication 1644 iSchedule uses and extends the mechanism defined by DomainKeys 1645 Identified Mail (DKIM) [RFC6376]. DKIM defines a domain-level 1646 digital signature authentication framework for email, using public- 1647 key cryptography, with the domain name service as its key server 1648 technology. 1650 10.3. DNS Considerations 1652 DNS security issues are addressed by DNSSEC [RFC4033]. 1654 10.4. Attachment Considerations 1656 iCalendar data can include "inline" attachment data in the form of a 1657 base64-encoded "ATTACH" property value. iSchedule Receivers MUST take 1658 care when allowing "inline" attachments in scheduling messages as 1659 such data might contain malicious content, and SHOULD use some form 1660 of content scanner on the attachment data to verify its safety (e.g., 1661 a content scanner used for email messages). In addition, "inline" 1662 attachment data is likely to be much larger than the actual calendar- 1663 related data in a scheduling message, and thus could adversely affect 1664 the performance of an iSchedule Receiver processing it. If an 1665 iSchedule Receiver allows "inline" attachment data, it MUST apply a 1666 limit on the size of acceptable scheduling messages to prevent 1667 possible denial-of-service attacks using large "inline" attachment 1668 data. In general, it is best for iSchedule Receivers to simply 1669 disable the ability for scheduling messages to contain "inline" 1670 attachment data, and instead rely solely on "external" attachments in 1671 the form of URI attachment values. 1673 11. IANA Considerations 1675 11.1. Namespace Registration 1677 This specification registers a new URN to identify a new XML 1678 namespace as per [RFC3688]. 1680 11.1.1. iSchedule Namespace Registration 1682 Registration request for the iSchedule namespace: 1684 URI: urn:ietf:params:xml:ns:ischedule 1686 Registrant Contact: See the "Authors' Addresses" section of this 1687 document. 1689 XML: None. Namespace URIs do not represent an XML specification. 1691 11.2. HTTP Headers Registration 1693 This specification registers new headers for use with HTTP as per 1694 [RFC3864]. 1696 11.2.1. DKIM-Signature Request Header Registration 1698 Header field name: DKIM-Signature 1700 Applicable protocol: http 1702 Status: standard 1704 Author/Change controller: IETF 1706 Specification document(s): this specification 1708 Related information: none 1710 11.2.2. iSchedule-Version General Header Registration 1712 Header field name: iSchedule-Version 1714 Applicable protocol: http 1716 Status: standard 1718 Author/Change controller: IETF 1720 Specification document(s): this specification 1722 Related information: none 1724 11.2.3. iSchedule-Capabilities Response Header Registration 1726 Header field name: iSchedule-Capabilities 1728 Applicable protocol: http 1730 Status: standard 1732 Author/Change controller: IETF 1734 Specification document(s): this specification 1736 Related information: none 1738 11.2.4. iSchedule-Message-ID Request Header Registration 1740 Header field name: iSchedule-Message-ID 1742 Applicable protocol: http 1744 Status: standard 1746 Author/Change controller: IETF 1748 Specification document(s): this specification 1750 Related information: none 1752 11.2.5. Originator Request Header Registration 1754 Header field name: Originator 1756 Applicable protocol: http 1758 Status: standard 1760 Author/Change controller: IETF 1762 Specification document(s): this specification 1764 Related information: none 1766 11.2.6. Recipient Request Header Registration 1768 Header field name: Recipient 1770 Applicable protocol: http 1772 Status: standard 1774 Author/Change controller: IETF 1776 Specification document(s): this specification 1778 Related information: none 1780 11.3. Well-Known URI Registration 1782 This specification registers a new well-known URI as per [RFC5785]. 1784 11.3.1. iSchedule Well-Known URI Registration 1786 URI suffix: ischedule 1788 Change controller: IETF. 1790 Specification document(s): this specification 1792 Related information: none 1794 11.3.2. DKIM Well-Known URI Registration 1796 URI suffix: domainkey 1798 Change controller: IETF. 1800 Specification document(s): this specification 1802 Related information: none 1804 11.4. DKIM Parameters Registration 1806 11.4.1. DKIM-Signature Query Method Registry 1808 This specification registers two new query mechanisms that can be 1809 used in DKIM-Signature fields. The following values should be added 1810 to the DKIM-Signature Query Method Registry established in Section 1811 7.3 of [RFC6376]: 1813 +------------------+------------+--------------------------+--------+ 1814 | Type | Option | Reference | Status | 1815 +------------------+------------+--------------------------+--------+ 1816 | http | well-known | (this document | active | 1817 | | | Section 7.3.2) | | 1818 | private-exchange | | (this document | active | 1819 | | | Section 7.3.3) | | 1820 +------------------+------------+--------------------------+--------+ 1822 11.4.2. DKIM Service Type Registration 1824 This specification registers a new DKIM service type to specify that 1825 a given public key MUST only be used to verify messages of iSchedule 1826 services. The following value should be added to the DKIM Service 1827 Type Registry established in Section 7.8 of [RFC6376]: 1829 +-----------+-------------------------------+--------+ 1830 | Type | Reference | Status | 1831 +-----------+-------------------------------+--------+ 1832 | ischedule | (this document Section 7.3.1) | active | 1833 +-----------+-------------------------------+--------+ 1835 12. Acknowledgments 1837 The authors would like to thank the following individuals for 1838 contributing their ideas and support for writing this specification: 1839 Mattias Amnefelt, Mike Douglass, Tomas Hnetila, Ciny Joy, Barry 1840 Leiba, Ken Murchison, Simon Pilette, Arnaud Quillaud, Simon 1841 Vaillancourt, and Wilfredo Sanchez Vega. 1843 The authors would also like to thank CalConnect, The Calendaring and 1844 Scheduling Consortium, for advice with this specification, and for 1845 organizing interoperability testing events to help refine it. 1847 13. References 1849 13.1. Normative References 1851 [RFC2119] Bradner, S., "Key words for use in RFCs to 1852 Indicate Requirement Levels", BCP 14, 1853 RFC 2119, March 1997. 1855 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, 1856 H., Masinter, L., Leach, P., and T. Berners- 1857 Lee, "Hypertext Transfer Protocol -- 1858 HTTP/1.1", RFC 2616, June 1999. 1860 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., 1861 Lawrence, S., Leach, P., Luotonen, A., and L. 1862 Stewart, "HTTP Authentication: Basic and 1863 Digest Access Authentication", RFC 2617, 1864 June 1999. 1866 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A 1867 DNS RR for specifying the location of 1868 services (DNS SRV)", RFC 2782, February 2000. 1870 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1871 May 2000. 1873 [RFC3688] Mealling, M., "The IETF XML Registry", 1874 BCP 81, RFC 3688, January 2004. 1876 [RFC3986] Berners-Lee, T., Fielding, R., and L. 1878 Masinter, "Uniform Resource Identifier (URI): 1879 Generic Syntax", STD 66, RFC 3986, 1880 January 2005. 1882 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, 1883 D., and S. Rose, "DNS Security Introduction 1884 and Requirements", RFC 4033, March 2005. 1886 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF 1887 for Syntax Specifications: ABNF", STD 68, 1888 RFC 5234, January 2008. 1890 [RFC5246] Dierks, T. and E. Rescorla, "The Transport 1891 Layer Security (TLS) Protocol Version 1.2", 1892 RFC 5246, August 2008. 1894 [RFC5545] Desruisseaux, B., "Internet Calendaring and 1895 Scheduling Core Object Specification 1896 (iCalendar)", RFC 5545, September 2009. 1898 [RFC5546] Daboo, C., "iCalendar Transport-Independent 1899 Interoperability Protocol (iTIP)", RFC 5546, 1900 December 2009. 1902 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining 1903 Well-Known Uniform Resource Identifiers 1904 (URIs)", RFC 5785, April 2010. 1906 [RFC6125] Saint-Andre, P. and J. Hodges, 1907 "Representation and Verification of Domain- 1908 Based Application Service Identity within 1909 Internet Public Key Infrastructure Using 1910 X.509 (PKIX) Certificates in the Context of 1911 Transport Layer Security (TLS)", RFC 6125, 1912 March 2011. 1914 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, 1915 "DomainKeys Identified Mail (DKIM) 1916 Signatures", RFC 6376, September 2011. 1918 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based 1919 Service Discovery", RFC 6763, February 2013. 1921 [W3C.REC-xml-20081126] Yergeau, F., Paoli, J., Sperberg-McQueen, C., 1922 Maler, E., and T. Bray, "Extensible Markup 1923 Language (XML) 1.0 (Fifth Edition)", World 1924 Wide Web Consortium Recommendation REC-xml- 1925 20081126, November 2008, 1926 . 1928 13.2. Informative References 1930 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, 1931 "Registration Procedures for Message Header 1932 Fields", BCP 90, RFC 3864, September 2004. 1934 [RFC4791] Daboo, C., Desruisseaux, B., and L. 1935 Dusseault, "Calendaring Extensions to WebDAV 1936 (CalDAV)", RFC 4791, March 2007. 1938 [RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, 1939 "DomainKeys Identified Mail (DKIM) Service 1940 Overview", RFC 5585, July 2009. 1942 [RFC6047] Melnikov, A., "iCalendar Message-Based 1943 Interoperability Protocol (iMIP)", RFC 6047, 1944 December 2010. 1946 [RFC6541] Kucherawy, M., "DomainKeys Identified Mail 1947 (DKIM) Authorized Third-Party Signatures", 1948 RFC 6541, February 2012. 1950 [RFC6638] Daboo, C. and B. Desruisseaux, "Scheduling 1951 Extensions to CalDAV", RFC 6638, June 2012. 1953 Appendix A. Example Scheduling Transactions 1955 This section describes some example scheduling transactions that give 1956 a general idea of how scheduling is carried out between an iSchedule 1957 Sender and an iSchedule Receiver. 1959 A.1. Example: Simple Meeting Invitation 1961 In the following example, the iSchedule Sender requests the iSchedule 1962 Receiver to deliver a meeting invitation (scheduling REQUEST) to the 1963 calendar user mailto:cyrus@example.org. The response indicates that 1964 delivery of the scheduling message was successful. 1966 >> Request << 1968 POST /.well-known/ischedule HTTP/1.1 1969 DKIM-Signature: a=rsa-sha256; d=example.com; s=jupiter; 1970 c=ischedule-relaxed/simple; q=dns/txt:http/well-known; 1971 t=1268069852; x=1283918400; 1972 h=Originator:Recipient:Content-Type: 1973 iSchedule-Version:iSchedule-Message-ID; 1974 bh=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx; 1975 b=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx 1976 Host: cal.example.org 1977 iSchedule-Version: 1.0 1978 iSchedule-Message-ID: 798F00BB-5B45-4634-B083-0D0CD3A2BB39 1979 Originator: mailto:bernard@example.com 1980 Recipient: mailto:cyrus@example.org 1981 Cache-Control: no-cache, no-transform 1982 Content-Type: text/calendar; component=VEVENT; method=REQUEST 1983 Content-Length: xxxx 1985 BEGIN:VCALENDAR 1986 VERSION:2.0 1987 PRODID:-//Example Corp.//EN 1988 METHOD:REQUEST 1989 BEGIN:VEVENT 1990 DTSTAMP:20040901T200200Z 1991 ORGANIZER:mailto:bernard@example.com 1992 DTSTART:20040902T130000Z 1993 DTEND:20040902T140000Z 1994 SUMMARY:Design meeting 1995 UID:34222-232@example.com 1996 ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR;CUTYPE=IND 1997 IVIDUAL;CN=Bernard Desruisseaux:mailto:bernard@ 1998 example.com 1999 ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE 2000 Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Cyrus Daboo: 2001 mailto:cyrus@example.org 2002 END:VEVENT 2003 END:VCALENDAR 2004 >> Response << 2006 HTTP/1.1 200 OK 2007 Date: Thu, 02 Sep 2004 16:53:32 GMT 2008 Content-Type: application/xml; charset=utf-8 2009 Content-Length: xxxx 2010 Cache-Control: no-cache, no-transform 2011 iSchedule-Version: 1.0 2012 iSchedule-Capabilities: 123 2014 2015 2016 2017 mailto:cyrus@example.org 2018 2.0;Success 2019 Delivered to recipient< 2020 /response-description> 2021 2022 2024 A.2. Example: Search for Busy Time Information 2026 In the following example, the iSchedule Sender requests the iSchedule 2027 Receiver to determine the busy information of the calendar users 2028 mailto:cyrus@example.org and mailto:mike@example.org, over the time 2029 range specified by the scheduling message sent in the request. The 2030 response includes VFREEBUSY components with the busy time for one 2031 calendar user, and an error for the other calendar user. 2033 >> Request << 2035 POST /.well-known/ischedule HTTP/1.1 2036 DKIM-Signature: a=rsa-sha256; d=example.com; s=jupiter; 2037 c=ischedule-relaxed/simple; q=dns/txt:http/well-known; 2038 t=1268069852; x=1283918400; 2039 h=Originator:Recipient:Content-Type: 2040 iSchedule-Version:iSchedule-Message-ID; 2041 bh=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx; 2042 b=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx 2043 Host: cal.example.org 2044 iSchedule-Version: 1.0 2045 iSchedule-Message-ID: A98ADF24-9490-4F01-81C8-FE924F86A9FD 2046 Originator: mailto:bernard@example.com 2047 Recipient: mailto:cyrus@example.org 2048 Recipient: mailto:mike@example.org 2049 Cache-Control: no-cache, no-transform 2050 Content-Type: text/calendar; component=VFREEBUSY; method=REQUEST 2051 Content-Length: xxxx 2053 BEGIN:VCALENDAR 2054 VERSION:2.0 2055 PRODID:-//Example Corp.//EN 2056 METHOD:REQUEST 2057 BEGIN:VFREEBUSY 2058 DTSTAMP:20040901T200200Z 2059 ORGANIZER:mailto:bernard@example.com 2060 DTSTART:20040902T000000Z 2061 DTEND:20040903T000000Z 2062 UID:34222-232@example.com 2063 ATTENDEE;CN=Cyrus Daboo:mailto:cyrus@example.org 2064 ATTENDEE;CN=Mike Douglass:mailto:mike@example.org 2065 END:VFREEBUSY 2066 END:VCALENDAR 2067 >> Response << 2069 HTTP/1.1 200 OK 2070 Date: Thu, 02 Sep 2004 16:53:32 GMT 2071 Content-Type: application/xml; charset=utf-8 2072 Content-Length: xxxx 2073 Cache-Control: no-cache, no-transform 2074 iSchedule-Version: 1.0 2075 iSchedule-Capabilities: 123 2077 2078 2079 2080 mailto:cyrus@example.org 2081 2.0;Success 2082 BEGIN:VCALENDAR 2083 VERSION:2.0 2084 PRODID:-//Example Corp.//EN 2085 METHOD:REPLY 2086 BEGIN:VFREEBUSY 2087 DTSTAMP:20040901T200200Z 2088 ORGANIZER:mailto:bernard@example.com 2089 DTSTART:20040902T000000Z 2090 DTEND:20040903T000000Z 2091 UID:34222-232@example.com 2092 ATTENDEE;CN=Cyrus Daboo:mailto:cyrus@example.org 2093 FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:20040902T000000Z/ 2094 20040902T090000Z,20040902T170000Z/20040903T000000Z 2095 FREEBUSY;FBTYPE=BUSY:20040902T120000Z/20040902T130000Z 2096 END:VFREEBUSY 2097 END:VCALENDAR 2098 2099 2100 2101 mailto:mike@example.org 2102 5.3;No scheduling support for user< 2103 /request-status> 2104 Unknown calendar user< 2105 /response-description> 2106 2107 2109 A.3. Example: Failed Request 2111 In the following example, the iSchedule Sender requests the iSchedule 2112 Sender to deliver a task assignment (scheduling REQUEST) to the 2113 calendar user mailto:cyrus@example.org. For some reason the 2114 verification of the request fails as is indicated by the error 2115 response. 2117 >> Request << 2119 POST /.well-known/ischedule HTTP/1.1 2120 DKIM-Signature: a=rsa-sha256; d=example.com; s=jupiter; 2121 c=ischedule-relaxed/simple; q=dns/txt:http/well-known; 2122 t=1268069852; x=1283918400; 2123 h=Originator:Recipient:Content-Type: 2124 iSchedule-Version:iSchedule-Message-ID; 2125 bh=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx; 2126 b=XXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxxXXXxxx 2127 Host: cal.example.org 2128 iSchedule-Version: 1.0 2129 Originator: mailto:bernard@example.com 2130 Recipient: mailto:cyrus@example.org 2131 Cache-Control: no-cache, no-transform 2132 Content-Type: text/calendar; component=VTODO; method=REQUEST 2133 Content-Length: xxxx 2135 BEGIN:VCALENDAR 2136 VERSION:2.0 2137 PRODID:-//Example Corp.//CalDAV Client//EN 2138 METHOD:REQUEST 2139 BEGIN:VTODO 2140 DTSTAMP:20040901T200200Z 2141 ORGANIZER:mailto:bernard@example.com 2142 DUE:20070505 2143 SUMMARY:Review Internet-Draft 2144 UID:34222-456@example.com 2145 ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE 2146 Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Cyrus Daboo: 2147 mailto:cyrus@example.org 2148 END:VEVENT 2149 END:VCALENDAR 2150 >> Response << 2152 HTTP/1.1 403 FORBIDDEN 2153 Date: Thu, 02 Sep 2004 16:53:32 GMT 2154 Content-Type: application/xml; charset=utf-8 2155 Content-Length: xxxx 2156 iSchedule-Version: 1.0 2157 iSchedule-Capabilities: 123 2159 2160 2161 2162 Unable to verify request< 2163 /response-description> 2164 2166 Appendix B. Change Log (to be removed by RFC Editor prior to 2167 publication) 2169 B.1. Changes in -05 2171 a. Fixed missing Recipient header in example. 2172 b. Added statements about what happens when a signature is or is not 2173 valid. 2174 c. Removed _ischedule SRV record type as we only support HTTPS. 2175 d. Removed text about adding an extra Recipient header as we no 2176 longer need that. 2178 B.2. Changes in -04 2180 a. Added some addition error codes to match MUST requirements. 2181 b. Free busy example now shows a failed calendar user response. 2182 c. Fixed capabilities response example to add method elements for 2183 VTODO and VFREEBUSY. 2184 d. More details added to XML element definitions. 2186 B.3. Changes in -03 2188 a. Removed http= tag from DKIM header. 2189 b. Updated lists of must and must not sign headers. 2190 c. Stated that Recipient list must match ATTENDEE list for VFREEBUSY 2191 requests. 2192 d. Recommend 5 minute skew for t=. 2193 e. Added serial-number to capabilities and iSchedule-Capabilities 2194 response header. 2196 f. Added "ischedule-relaxed" header canonicalization. 2197 g. Fixed examples. 2199 B.4. Changes in -02 2201 a. Major structural changes as well as addition of new sections, 2202 including an Overview. 2203 b. Changed capabilities XML schema. 2204 c. XML error elements are now named for the actual error as opposed 2205 to WebDAV style pre-conditions. 2206 d. Removed intermediary support and iSchedule-Via header. 2207 e. Added TXT path= lookup to accompany SRV lookup. 2208 f. Added http/well-known public key lookup mechanism. 2209 g. Added iSchedule-Message-ID header. 2210 h. Provided suggested values for t= and x= to cope with clock skew 2211 and processing time issues. 2212 i. Indicated that iSchedule-Version header can be returned in 2213 OPTIONS responses. 2214 j. Clarified that Attendee list for VFREEBUSY has to be the same as 2215 the Recipient list. 2217 B.5. Changes in -01 2219 a. Introduced use of DKIM for calendaring and scheduling services. 2220 b. The XML elements "supported-calendar-data" and "calendar-data" 2221 were renamed to "supported-calendar-data-type" and "calendar- 2222 data-type" respectively to avoid confusion with the "calendar- 2223 data" XML element being used in the "response" XML element. 2224 c. The "recipient" XML element was redefined to accept (#PCDATA) 2225 instead of an "href" XML element. 2226 d. The grammar of new HTTP headers is now using the ABNF syntax 2227 defined in [RFC5234]. 2228 e. Fixed various typos. 2230 Authors' Addresses 2232 Cyrus Daboo 2233 Apple Inc. 2234 1 Infinite Loop 2235 Cupertino, CA 95014 2236 USA 2238 EMail: cyrus@daboo.name 2239 URI: http://www.apple.com/ 2240 Bernard Desruisseaux 2241 Oracle Corporation 2242 600 Blvd. de Maisonneuve West 2243 Suite 1900 2244 Montreal, QC H3A 3J2 2245 CANADA 2247 EMail: bernard.desruisseaux@oracle.com 2248 URI: http://www.oracle.com/