idnits 2.17.1 draft-ietf-calsch-cih-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2.0 Overview of CIH' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 4.0 Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 127: '...tempted, email communication SHOULD be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 49 has weird spacing: '...oposing an ev...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 208 looks like a reference -- Missing reference section? '2' on line 212 looks like a reference -- Missing reference section? '3' on line 216 looks like a reference -- Missing reference section? '4' on line 219 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft 2/6/97 2 draft-ietf-calsch-cih-00.txt Expires 6 months from above date 4 Calendaring Interoperability over HTTP (CIH) 6 Abstract 8 Calendaring Interoperability over HTTP (CIH) is a technique 9 for exchanging calendaring information between scheduling 10 systems using the Hypertext Transfer Protocol (HTTP). This 11 allows users to schedule meetings with anyone else, no 12 matter what scheduling software they use. 14 This document is a tentative exploration of whether CIH is 15 feasible and what the pros and cons are relative to a brand 16 new protocol like the Calendaring Interoperability Protocol 17 (CIP). The primary benefit of CIH over CIP and motivation 18 for this project is that we avoid implementing a whole new 19 protocol, such as writing and debugging the protocol, 20 convincing vendors to write new code to support it, and then 21 convincing users to deploy it. 23 Table of Contents 25 Abstract ..................................................1 26 Table of Contents .........................................1 27 1.0 Introduction ..........................................1 28 2.0 Overview of CIH .......................................2 29 2.1 Performing Basic CIH Operations ......................2 30 2.2 Mapping an Attendee Address to a URL for CIH .........3 31 3.0 Pros and Cons of CIH (vs CIP) .........................3 32 3.1 Performance Concerns .................................3 33 4.0 Security Considerations ...............................4 34 5.0 References ............................................4 35 6.0 Open Issues ...........................................4 36 7.0 To Be Done ............................................5 37 8.0 Author's Address ......................................5 39 1.0 Introduction 41 The Internet Calendaring and Scheduling Core Object 42 Specification (iCalendar) [1] describes a way to represent 43 calendaring and scheduling objects and verbs as MIME 44 objects. This includes distributing and responding to events 45 and todos and sending free time queries and responses. One 46 of the most interesting parts of iCalendar(and probably one 47 of the best) is that these objects can include a Profile 48 property that indicates what action should be performed 49 (proposing an event, cancelling one, changing one, 50 responding to one, etc.). This allows the objects to be sent 51 around by email and transferred into scheduling systems, 52 either manually or by integrating the scheduling systems 53 with the email system. 55 1 56 Internet-Draft 2/6/97 57 draft-calsch-cih-00.txt Expires 6 months from above date 59 However, there are many times when email is not an ideal 60 transport for calendaring and scheduling. For instance, 61 email delivery can be slow and sometimes unreliable. 62 Gateways can mangle messages. Users can fail to check their 63 email for long periods of time. Most email systems will 64 require manual effort to transfer scheduling info from email 65 to the scheduling system and back. Many scheduling 66 operations can and should be performed better with a direct, 67 real-time connection between scheduling systems. 69 For these reasons, a protocol that allows iCalendar objects 70 to be exchanged in real time would be ideal. A simple 71 protocol will do. We're just exchanging MIME objects. The 72 details of the object format and the actions implied by the 73 objects (date syntax, attendee list, etc.) are considered in 74 the iCalendar spec. 76 Several protocols have been suggested to address this 77 problem. The CIP (Calendaring Interoperability Protocol) [2] 78 is a simple protocol with a few verbs that correspond to the 79 operations necessary to accomplish calendaring 80 interoperability. HTTP is also being considered for this 81 role and that is the focus of this document. 83 This document provides a tentative exploration of whether 84 Calendaring Interoperability over HTTP (CIH) is feasible and 85 what the pros and cons are relative to a brand new protocol 86 like the CIP. 88 2.0 Overview of CIH 90 CIH uses the overall architecture of CIP, but reimplements 91 it using a subset of the HTTP 1.1 protocol specification 92 [3]. CIH servers are HTTP servers and therefore must meet 93 all requirements for HTTP servers laid out in the HTTP 1.1 94 specification. CIH is merely a convention which describes 95 how certain HTTP commands should be handled when certain 96 MIME content types are used. 98 2.1 Performing Basic CIH Operations 100 All CIH operations are performed by using the HTTP POST 101 command to send MIME objects from the client to a specified 102 URL on the server and receive MIME objects in the response. 103 The MIME objects in question are those described by the 104 iCalendar spec and their semantics and syntax are described 105 thoroughly in that document. 107 HTTP is used in this context mostly as a real-time transfer 108 mechanism for MIME objects. Since its capabilities are a 109 superset of those provided by SMTP email, this does not 110 require significant changes to the iCalendar spec. 112 2 113 Internet-Draft 2/6/97 114 draft-calsch-cih-00.txt Expires 6 months from above date 116 2.2 Mapping an Attendee Address to a URL for CIH 118 The default value of an attendee as defined in iCalendar is 119 an RFC 822 address (that is, user@hostname). While iCalendar 120 allows the value to have other data types, such as URL, it 121 is desirable to have an easy way to map a single RFC 822 122 address into a URL that can be used for CIH. For the address 123 hanna@world.std.com, the CIH URL is 124 http://cih.world.std.com/hanna. The algorithm is to prepend 125 cih. to the host name and use the user name as an abs_path. 126 If this generates an invalid URL or an error occurs when CIH 127 communications are attempted, email communication SHOULD be 128 used. 130 A few notes here. First, this does not mean that all URLs 131 that support CIH must have this form. It just provides a 132 convenient method for mapping an RFC 822 address into an 133 HTTP URL for use with CIH. Second, if a better scheme 134 emerges for server location (SLP or whatever), we can 135 support that and provide backward compatibility with this 136 scheme via redirects. 138 3.0 Pros and Cons of CIH (vs CIP) 140 The primary benefit of CIH over CIP and the motivation for 141 this project is that we avoid implementing a whole new 142 protocol, such as writing and debugging the protocol, 143 convincing vendors to write new code to support it, and then 144 convincing users to deploy it. There are three phases to 145 this benefit: definition, implementation, and deployment. 147 Some would argue that defining CIH will be easier than 148 defining a whole new protocol. This is not clear, as there 149 is also a counter-argument that HTTP is so complicated that 150 defining CIH will be quite a task. 152 For vendors with lots of HTTP experience and code, 153 deployment of CIH will be easier than CIP. For vendors 154 without much HTTP experience, CIH will be more complex than 155 CIP and probably take more time to implement, even if HTTP 156 code can be licensed and integrated into their products. 158 For deployment, the balance is clearly in favor of CIH. 159 Users and administrators are already familiar with HTTP and 160 a great deal of infrastructure has been built up to support 161 HTTP already. Problems may arise, however, if CIH uses a 162 subset of HTTP or takes advantage of obscure or cutting-edge 163 features of HTTP that aren't widely implemented. These is 164 also a risk of customer backlash against using HTTP for a 165 purpose different from its original intent. 167 3.1 Performance Concerns 169 3 170 Internet-Draft 2/6/97 171 draft-calsch-cih-00.txt Expires 6 months from above date 173 Concerns have been raised that CIH will be substantially 174 slower than CIP. This section provides some of the arguments 175 pro and con. 177 While HTTP 1.0 is a connectionless protocol, HTTP 1.1 uses 178 persistent connections by default. This avoids the overhead 179 associated with bringing up and shutting down TCP 180 connections all the time. 182 Although HTTP 1.1 uses persistent connections, it is still a 183 stateless protocol in that each request is considered 184 without regard to the requests that preceded it (unless 185 cookies are used). The stateful nature of CIP can allow it 186 to optimize some operations by establishing a state once and 187 then performing several commands. However, it is not clear 188 that this will provide substantial performance improvements. 189 In the area of authentication and encryption, SSL avoids 190 reauthentication with every request. 192 Several HTTP features, such as compression via content 193 codings may provide sophisticated methods of boosting 194 throughput and therefore performance over CIP. 196 4.0 Security Considerations 198 Since calendaring interoperability may involve the exchange 199 of sensitive information, any calendaring interoperability 200 mechanism must provide for encryption and authentication. 201 Several techniques such as SSL and HTTP Access Authorization 202 are available for use with HTTP as described in [3] and [4]. 203 Without such techniques, CIH clients and servers are wide 204 open to forged or snooped meeting proposals or responses. 206 5.0 References 208 [1] F. Dawson, D. Stenerson, _Internet Calendaring and 209 Scheduling Core Object Specification_, Internet Draft, 210 draft-ietf-calsch-ical-00.txt, February 1997. 212 [2] A. Ganguly, S. Hanna, P. O'Leary, B. Spencer, 213 _Calendaring Interoperability Protocol_, Internet Draft, 214 draft-ietf-calsch-cip-00.txt, November 1996. 216 [3] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. 217 Berners-Lee, _Hypertext Transfer Protocol_, RFC 2068. 219 [4] A. Frier, P. Karlton, P. Kocher, _The SSL Protocol 220 Version 3.0_, Internet Draft, draft-ietf-tls-ssl-version3- 221 00.txt, November 1996. 223 6.0 Open Issues 225 Define iCalendar objects to be used in CIH responses (other 226 than FREE-BUSY/REPLY). This will have the benefit of 228 4 229 Internet-Draft 2/6/97 230 draft-calsch-cih-00.txt Expires 6 months from above date 232 allowing responses (i.e. operation confirmations) by email 233 if that's desired. 235 Should have a non-destructive way to confirm that a given 236 URL supports CIH before you start PUTting things to it. 237 Otherwise, you might just be dumping things in a directory 238 on an HTTP server. Perhaps a GET that is expected to return 239 a certain value. 241 7.0 To Be Done 243 Add examples and lots more detail. 245 8.0 Author's Address 247 Steve Hanna 248 On Technology Corporation 249 hanna@world.std.com 250 (617) 251 692-3153 253 Anik Ganguly 254 OnTime 255 Campbell Services Inc. 257 http://www.ontime.com