idnits 2.17.1 draft-ietf-calsch-crisp-01.txt: -(18): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding ** The Abstract section seems to be numbered -(53): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(55): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(64): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(65): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(78): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(114): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(174): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 9 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([CAP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2001) is 8288 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) == Outdated reference: A later version (-13) exists of draft-ietf-calsch-cap-05 -- Possible downref: Normative reference to a draft: ref. 'CAP' Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Stracke 3 INTERNET DRAFT eCal 4 draft-ietf-calsch-crisp-01.txt August 2001 5 Expires: February 2002 7 CAP Realtime iTIP-based Scheduling Profile (CRISP) 9 1. Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. Internet-Drafts are draft documents valid for a maximum of 18 six months and may be updated, replaced, or obsoleted by other docu� 19 ments at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Distribution of this document is unlimited. Please send comments to 29 francis@ecal.com or to the ietf-calendar@imc.org discussion list 30 (subscription address ietf-calendar-request@imc.org; "SUBSCRIBE" or 31 "UNSUBSCRIBE" in the body). 33 2. Copyright Notice 35 Copyright (C) The Internet Society (2000). All Rights Reserved. 37 3. Abstract 39 This document sets forth a restricted profile of [CAP], one which 40 supports no operations beyond the scheduling functionality of [iTIP]. 41 The motivation is to permit use of CAP's real-time iTIP functionality 42 without exposing the calendar access functionality (which may require 43 stricter security controls than iTIP). 45 CRISP August 2001 47 4. Introduction 49 [iTIP] defines a scheduling protocol based on exchanging specially 50 formatted [iCalendar] messages. iTIP is defined to be independent of 51 transport protocol. At present, there is one standard binding of 52 iTIP to a transport protocol, [iMIP], which carries iTIP messages in 53 email. This is a useful base level capability (email can reach vir� 54 tually any user on the Net), but can involve considerable latencies. 55 A real-time binding for iTIP would be useful; it would permit appli� 56 cation developers to give users better feedback on the progress of 57 the iTIP operations. 59 Since CAP includes full iTIP functionality, one option would be to 60 permit full access to CAP; to schedule an event with a remote user, 61 one would then make a CAP connection to their CS. The problem is 62 that such a connection may be considered a security risk in some 63 organizations; even though the CS has ACLs to prevent the client from 64 performing non-iTIP operations, it would be better if the client sim� 65 ply could not attempt such operations. (It's as if mail administra� 66 tors were told that an SMTP server outside the firewall had to 67 include IMAP functionality as well.) Thus, this document defines 68 CRISP, a profile of CAP, a subset which does not support non-iTIP 69 operations. 71 This document does not specify the relationship between a CRISP 72 server and a (full-powered) CAP server. They may be implemented 73 together, with the CRISP server being nothing more than the CAP 74 server responding in CRISP mode (e.g., based on source IP address); 75 the CRISP server may act as a proxy for the CAP server (see Firewall 76 Application, below); the two servers may feed into the same database, 77 but not know about each other; or there may be no CAP server, only 78 the CRISP server, used for interdomain scheduling, but not for calen� 79 dar access. Or, of course, there may be other modes of operation. 80 These are implementation details, which do not need to be included in 81 a protocol spec. 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC 2119. 87 Note that CRISP is a replacement for the former proposal known as 88 iRIP (no reference is available, because the Internet-Draft has long 89 since expired), which was abandoned when it was realized that the 90 functionality of CAP was a superset of the functionality of iRIP. 92 CRISP August 2001 94 5. Profile Definition 96 A CRISP server is a CAP server with the following capabilities: 98 * ITIPVERSION=1.0 99 * CAPVERSION=1.0 100 * CAR=NONE 101 * QUERYLEVEL=NONE 103 In addition, various AUTH capabilities are expected. Anonymous 104 authentication SHOULD be supported, since the point of CRISP is to 105 permit iTIP communication across security domains. However, other 106 authentication mechanisms may make sense in some cases; for example, 107 if CRISP is being used for scheduling between cooperating companies 108 (that is, in an extranet), then one company's CRISP server might be 109 able to authenticate users from the other company. 111 Other capabilities which apply to iTIP operations MAY be specified; 112 e.g., MAXDATE and MAXICALOBJECTSIZE. 114 Note that NONE is not a legal value for CAR or QUERYLEVEL in the cur� 115 rent draft of CAP. This will have to be resolved. 117 A CRISP server MUST NOT accept any iCalendar component which is not a 118 valid iTIP component. 120 In effect, the statement that a server is CRISP is a statement about 121 the server's current advertised capabilities. It is conceivable that 122 a CAP server might be CRISP under some conditions and not others. 123 For example, the server might offer a CRISP capability set on initial 124 connection, but upgrade to full CAP if the client uses STARTTLS and 125 provides an appropriate certificate. It's not clear, though, whether 126 there's any good way to advertise this fact. For the rest of this 127 document, we will assume that a CRISP server is always CRISP. 129 6. Possible Firewall Application 131 This section is non-normative. 133 Clearly, it would be undesirable for an organization with a CAP 134 server to have a CRISP server implemented completely separately, but 135 having access to the same database. Such duplication would increase 136 development costs, maintenance costs, and security exposure. On the 137 other hand, it would be possible to build a CRISP server which han� 138 dles all operations by proxying them to the CAP server. Such a proxy 139 could be placed within the "no-man's-land" common in firewalls; the 140 firewall would permit CAP connections from the outside to the proxy, 142 CRISP August 2001 144 and from the proxy to the internal CAP server. The proxy would 145 review all incoming iCalendar components and validate that they were 146 legitimate iTIP operations; no non-iTIP components would be forwarded 147 to the CAP server. Similarly, if necessary, the proxy might censor 148 the iTIP replies coming from the CAP server. 150 Naturally, this is not the only approach possible; this section is 151 merely illustrative. The CRISP client does not know or care how the 152 CRISP server gets at the underlying calendar store. 154 7. Security Considerations 156 CRISP is a subset of [CAP], and accordingly inherits all of CAP's 157 security analysis. However, new analysis does need to be done for 158 the subset, especially since the whole point of the subset is to 159 address security concerns. 161 8. Author's Address: 163 John Stracke 164 Chief Scientist 165 eCal Corp. 166 Email: francis@ecal.com 168 9. References 170 [iTIP] Silverberg, Mansour, Dawson, Hopson, "iCalendar Transport- 171 Independent Interoperability Protocol (iTIP)", RFC 2446, November 172 1998 174 [iMIP] Dawson, Mansour, Silverberg, "iCalendar Message-Based Interop� 175 erability Protocol (iMIP)", RFC 2445, November 1998 177 [CAP] Mansour, Dawson, Royer, Taler, Hill, "Calendar Access Protocol 178 (CAP)", draft-ietf-calsch-cap-05.txt, July 2001. Work in progress. 180 [iCAL] Dawson, Stenerson, "Internet Calendaring and Scheduling Core 181 Object Specification (iCalendar)", RFC 2445, November 1998