idnits 2.17.1 draft-ietf-calsch-irip-03.txt: 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 37) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([ICAL], [RFC-2045], [RFC-2046], [RFC-2047], [RFC-2048], [RFC-2049], [ITIP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** 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 306: '... room. It MUST be unique within...' RFC 2119 keyword, line 365: '...sted in the table above. A command MAY...' RFC 2119 keyword, line 368: '...rminating MUST be l024 characte...' RFC 2119 keyword, line 376: '...A response MAY include an [ICAL] object. Whether an [ICAL] object is...' RFC 2119 keyword, line 380: '...Arguments MUST NOT be present unless t...' (15 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Mansour/Courtemanche/O'Leary 37 Expires August 1999 others, and derivative works that comment on or otherwise explain it or assist in its implmentation MAY be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself MAY NOT be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process MUST be followed, or as required to translate it into languages other than English. -- 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 (April 16, 1999) is 9113 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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? 'ITIP' on line 1802 looks like a reference -- Missing reference section? 'ICAL' on line 1798 looks like a reference -- Missing reference section? 'RFC-2045' on line 1829 looks like a reference -- Missing reference section? 'RFC-2046' on line 1833 looks like a reference -- Missing reference section? 'RFC-2047' on line 1836 looks like a reference -- Missing reference section? 'RFC-2048' on line 1840 looks like a reference -- Missing reference section? 'RFC-2049' on line 35 looks like a reference -- Missing reference section? 'IMIP' on line 1807 looks like a reference -- Missing reference section? 'RFC2396' on line 1847 looks like a reference -- Missing reference section? 'ICAL OBJECT' on line 372 looks like a reference -- Missing reference section? 'SASL' on line 1861 looks like a reference -- Missing reference section? 'ID-UTF8' on line 1811 looks like a reference -- Missing reference section? 'RFC-822' on line 1816 looks like a reference -- Missing reference section? 'RFC-1847' on line 1819 looks like a reference -- Missing reference section? 'RFC-2112' on line 1823 looks like a reference -- Missing reference section? 'RFC-2015' on line 1826 looks like a reference -- Missing reference section? 'RFC-2222' on line 1844 looks like a reference -- Missing reference section? 'RFC-2445' on line 1850 looks like a reference -- Missing reference section? 'RFC-2446' on line 1853 looks like a reference -- Missing reference section? 'RFC-2447' on line 1856 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 24 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Andre Courtemanche, CS&T 3 Internet Draft IRIP Steve Mansour, Netscape 4 Pete O'Leary, Amplitude 5 Expires 6 months after: April 16, 1999 7 ICalendar Real-time Interoperability Protocol (iRIP) 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document specifies a binding from the iCalendar Transport- 32 independent Interoperability Protocol [ITIP] to a real-time transport. 33 Calendaring entries defined by the iCalendar Object Model [ICAL] are 34 composed using constructs from [RFC-2045], [RFC-2046], [RFC-2047], 35 [RFC-2048] and [RFC-2049]. 37 This document is based on discussions within the Internet Engineering 38 Task Force (IETF) Calendaring and Scheduling (CALSCH) working group. 39 More information about the IETF CALSCH working group activities can be 40 found on the IMC website at http://www.imc.org, the IETF website at 41 http://www.ietf.org/html.charters/calsch-charter.html. Refer to the 42 references within this document for further information on how to 43 access these various documents. 45 Distribution of this document is unlimited. Comments and suggestions 46 for improvement should be sent to the authors. 48 Mansour/Courtemanche/O'Leary 1 Expires August 1999 49 Table Of Contents 50 1 Introduction 3 51 1.1Related Memos 3 52 1.2Formatting Conventions 3 53 2 Architecture 4 54 2.1Protocol States 5 55 2.2Calendar Address 6 56 2.3Bounded Latency 7 57 3 Protocol 7 58 3.1Commands 7 59 3.1.1ABORT 8 60 3.1.2AUTHENTICATE 9 61 3.1.3CAPABILITY 12 62 3.1.4CONTINUE 13 63 3.1.5DEQUEUE 14 64 3.1.6DISCONNECT 15 65 3.1.7RECIPIENT 15 66 3.1.8SENDATA 17 67 3.1.9SWITCH 19 68 3.2Fanout and Queued Transactions 19 69 3.3Bi-Directional Queue Operation 20 70 3.4Reply Codes 20 71 4 Implementation Considerations 23 72 5 Security Considerations 23 73 5.1Security Threats and Recommendations 23 74 5.1.1Authentication Hacking 23 75 5.1.2Spoofing 23 76 5.1.3Eavesdropping 24 77 5.1.4Connection Flooding 24 78 5.2Security Interoperability Issues 24 79 6 Examples 24 80 6.1Unauthenticated Freebusy Request 24 81 6.2Busy Time Request 25 82 6.3Using Switch 28 83 6.4Fanout Requests 29 84 6.4.1Successful Fanout Request 29 85 6.4.2Referral On Fanout 30 86 6.5Queued Requests 31 87 6.5.1Meeting Invitation 32 88 7 Acknowledgments 33 89 8 Bibliography 33 90 9 Open Issues 34 91 10 Author's Address 34 92 11 Full Copyright Statement 36 94 Mansour/Courtemanche/O'Leary 2 Expires August 1999 95 1 Introduction 97 This binding document provides the transport specific information 98 necessary to convey iCalendar Transport-independent Interoperability 99 Protocol [ITIP] messages over a real-time transport. 101 1.1 Related Memos 103 Implementers will need to be familiar with several other memos that, 104 along with this memo, form a framework for Internet calendaring and 105 scheduling standards. 107 This document specifies a real-time binding for [ITIP]. 109 - [ICAL] specifies a core specification of objects, data types, 110 properties and property parameters; 111 - [ITIP] specifies an interoperability protocol for scheduling 112 between different implementations; 113 - [IMIP] specifies a messaging-based protocol binding for [ITIP]. 115 This document does not attempt to repeat the specification of concepts 116 or definitions from these other memos. Where possible, references are 117 made to the memo that provides for the specification of these concepts 118 or definitions. 120 1.2 Formatting Conventions 122 The mechanisms defined in this memo are defined in propose. In order 123 to refer to elements of the calendaring and scheduling model, core 124 object or interoperability protocol defined in [ICAL] and [ITIP] some 125 formatting conventions have been used. 127 Calendaring and scheduling roles defined by [ITIP] are referred to in 128 quoted-strings of text with the first character of each word in upper 129 case. For example, "Organizer" refers to a role of a "Calendar User" 130 within the scheduling protocol defined by [ITIP]. 132 Calendar components defined by [ICAL] are referred to with 133 capitalized, quoted-strings of text. All calendar components start 134 with the letter "V". For example, "VEVENT" refers to the event 135 calendar component, "VTODO" refers to the to-do calendar component and 136 "VJOURNAL" refers to the daily journal calendar component. 138 Scheduling methods defined by [ITIP] are referred to with capitalized, 139 quoted-strings of text. For example, "REQUEST" refers to the method 140 for requesting a scheduling calendar component be created or modified, 141 "REPLY" refers to the method a recipient of a request uses to update 142 their status with the "Organizer" of the calendar component. 144 Properties defined by [ICAL] are referred to with capitalized, quoted- 145 strings of text, followed by the word "property". For example, 147 Mansour/Courtemanche/O'Leary 3 Expires August 1999 148 "ATTENDEE" property refers to the iCalendar property used to convey 149 the calendar address of a calendar user. 151 Property parameters defined by [ICAL] are referred to with lower case, 152 quoted-strings of text, followed by the word "parameter". For example, 153 "VALUE" parameter refers to the iCalendar property parameter used to 154 override the default data type for a property value. 156 2 Architecture 158 iRIP enables real-time interoperability between scheduling systems 159 using the iCalendar [ICAL] format for information exchange. iRIP is 160 designed primarily to allow Calendar Services (CS) to forward real- 161 time requests on behalf of Calendar User Agents (CUA) and receive real- 162 time responses. The goal of iRIP is to allow two or more CS's to 163 establish connections with each other. However, the design of iRIP 164 does not preclude its use from CUA directly to CS. iRIP allows a CS to 165 initiate a session and perform operations on behalf of multiple CUA's 166 without the need to reauthenticate the session for each CUA. 168 The sections and examples below refer to a "user", a "sender", and a 169 "receiver". For purposes of this document these terms are defined as 170 follows: 172 user - the Calendar User that initiates a request. 173 sender - the agent used to contact a receiving device, send 174 commands, and receive replies. 175 receiver - the agent that accepts commands and sends replies. 177 The sender and receiver can take on varying roles of a Calendar User 178 Agent (CUA) and Calendar Store (CS). 180 iRIP allows two CS's to establish different levels of trust. When an 181 iRIP connection is first established, the sender CS authenticates as 182 the iRIP server acting as a proxy for the originator of each ITIP 183 message being sent to the receiver. 185 Mansour/Courtemanche/O'Leary 4 Expires August 1999 186 2.1 Protocol States1 188 The iRIP state diagram is shown below. The states are shown in the 189 boxes. State names are written with the first letter capitalized. The 190 commands used to switch between states are shown next to an arrow 191 connecting the states. The commands are listed in all capital letters. 192 A condition that causes a state to change is shown in lower case 193 letters. 195 CAPABILITY 196 or SWITCH 197 +----+ 198 V | 199 +-------------+ DISCONNECT +---------------+ 200 | |---------------->| Terminated |<-----------------+ 201 | Connected | +---------------+ | 202 | |<---+ A | 203 +-------------+ | | | 204 | | | | 205 |AUTHENTICATE | AUTHENTICATE |DISCONNECT | 206 | | or CAPABILITY | | 207 | SWITCH| +----+ | | 208 | | V | | | 209 | +----------------------------------+ | 210 +--->| | ABORT +--------+ A 211 | Authenticated |<-------| Idle | | 212 +--->| |<--+ +--------+ | 213 | +----------------------------------+ | | A | 214 | | | complete| | | | 215 |ABORT |RECEIVE DEQUEUE| or| CONT| |latency | 216 | | | ABORT| INUE| |reply | 217 | V V | | |from | 218 +-------------+ +---------------+ | |server | 219 | | SENDATA | |<----+ | | 220 | Send |---------------->| Receive | | | 221 | | | |--------+ | 222 +-------------+ +---------------+ | 223 A | | DISCONNECT | DISCONNECT | 224 +----+ +---------------->-----------+-------------------------+ 225 RECIPIENT 227 An iRIP session begins when a TCP/IP connection is made on port 5228. 228 The protocol begins in the Connected state. Once connected, the sender 229 can issue the CAPABILITY which leaves the protocol in the Connected 230 state. The sender can also issue the SWITCH command requesting the 231 receiver to switch roles with the sender. Whether the receiver accepts 232 or declines the request, the protocol remains in the Connected state. 233 The DISCONNECT command terminates the connection. The AUTHENTICATE 234 command, when successful, begins the Authenticated state. From the 235 Authenticated state, the sender can: 237 1. begin sending an ITIP message to the receiver by issuing the 239 Mansour/Courtemanche/O'Leary 5 Expires August 1999 240 RECIPIENT command, 241 2. re-authenticate as a different calendar using the AUTHENTICATE 242 command, 243 3. request a queued ITIP message for the authenticated calendar using 244 the DEQUEUE command, 245 4. execute the CAPABILITY command, 246 5. disconnect 248 In order to send an ITIP message to other calendars, the sender begins 249 by issuing the RECIPIENT command causing the protocol to enter the 250 Send state. The sender repeats the RECIPIENT command as many times as 251 needed to indicate all the target calendars. When all recipients have 252 been specified, the sender issues the SENDATA command and supplies the 253 [ITIP] message. This causes the protocol to enter the Receive state 254 where the sender waits for a response from the receiver. If the 255 receiver's response indicates that the request has been completed the 256 protocol returns to the Authenticated state. If the receiver indicates 257 that the request could not be completed in the time specified by the 258 sender the protocol enters the Idle state. At this point the sender 259 must decide how to proceed. If the sender issues the CONTINUE command, 260 the command in progress continues and the session returns to the 261 Receive state. If the sender issues the ABORT command the command is 262 aborted and the session is returned to the Authenticated state. 264 The sender may decide to abort sending the ITIP message while it 265 issues the RECIPIENT commands (perhaps because a RECIPIENT does not 266 exist). If the sender issues the ABORT command after one or more 267 RECIPIENT commands, the protocol returns to the Authenticated state. 269 A sender can abort an operation in progress while it is in the Receive 270 state by sending an ABORT command to the receiver. 272 >From the Authenticated state, a sender can also issue the DEQUEUE 273 command causing the protocol to request the receiver to return a 274 single queued ITIP message. Issuing the DEQUEUE command changes the 275 protocol to the Receive state. The receiver replies with a single 276 queued [ITIP] request or a status code to indicate that there are no 277 more queued requests for the authenticated user. 279 Though the DISCONNECT command should only be issued from the 280 Authenticated or Connected states, implementations should be prepared 281 to handle a DISCONNECT at any point in this state diagram. 283 2.2 Calendar Address 285 Calendar addresses, or CALUIDs, are URIs that are modeled after 286 [RFC2396]. iRIP CALIDs use the following form of URI. 288 [://[:]/] 290 where: 292 Mansour/Courtemanche/O'Leary 6 Expires August 1999 293 must be "irip" 295 is address of the computer on which the iRIP server is 296 running. This is also called the Calendar Store ID or 297 CSID. 299 is optional. Its default value is 5228. 301 is an identifier that uniquely identifies the 302 calendar on a particular calendar store. There is no 303 implied structure in a relativeCALUID, it is an arbitrary 304 string of 7-bit ASCII characters. It may refer to the 305 calendar of a user or of a resource such as a conference 306 room. It MUST be unique within the calendar store. It is 307 recommended that the relativeCALUID be globally unique. 309 If the CSID is present the CALID is said to be "qualified". Qualified 310 CALIDs are necessary when the CSID portion of a calendar address is 311 different from the Calendar Store on which the calendar user is 312 currently authenticated. 314 Examples: 316 irip://calendar.example.com/user1 317 user1 318 irip://calendar.example.com/conferenceRoomA 319 irip://calendar.example.com/89798-098-zytytasd 321 For the iRIP server on calendar.example.com, the first two addresses 322 refer to the same calendar. 324 2.3 Bounded Latency 326 iRIP is designed so that the sender can either obtain an immediate 327 response from a request or discover within a specified amount of time 328 that the request has not yet completed. The sender can initiate 329 commands with an optional latency time specified. When the sender 330 specifies the latency time and the receiver cannot complete the 331 operation within the specified amount of time, the receiver return an 332 appropriate response code to the sender. The sender then issues either 333 a CONTINUE or ABORT command. The ABORT command immediately terminates 334 the command in progress. The CONTINUE command instructs the receiver 335 to continue processing the command. The ABORT command causes the 336 receiver to discard the current command and return to the 337 Authenticated state. 339 Mansour/Courtemanche/O'Leary 7 Expires August 1999 340 3 Protocol 342 3.1 Commands 344 iRIP commands are summarized in the table below and described in 345 detail in the following sections. 347 +=================================================+ 348 | Command Issued from State | 349 +=================================================+ 350 | ABORT Idle, Send, Receive | 351 | AUTHENTICATE Connected, Authenticated | 352 | CAPABILITY Connected, Authenticated, Send | 353 | CONTINUE Idle | 354 | DEQUEUE Authenticated | 355 | DISCONNECT Connected, Authenticated | 356 | SENDATA Send | 357 | RECIPIENT Authenticated, Send | 358 | SWITCH Connected, Authenticated | 359 +=================================================+ 361 Commands have the general form: 363 [arguments...] 365 where is a command listed in the table above. A command MAY 366 have arguments. Arguments are defined in the detailed command 367 definitions below. The length of a command and its arguments, and the 368 terminating MUST be l024 characters or less. 370 Responses to commands have the following general form: 372 [ICAL OBJECT] 373 . 374 [arguments...] 376 A response MAY include an [ICAL] object. Whether an [ICAL] object is 377 present or not, the sequence . followed by a reply code is 378 mandatory. The reply code may have associated arguments. These 379 arguments are defined in the command descriptions for each command. 380 Arguments MUST NOT be present unless they are specifically called for 381 by the particular reply code.. The length of the reply code, any 382 arguments, and the terminating MUST be l024 characters or less. 384 In the examples below, lines preceded with "S:" refer to the sender 385 and lines preceded with "R:" refer to the receiver. Lines in which the 386 first non-whitespace character is a "#" are editorial comments and are 387 not part of the protocol. 389 3.1.1 ABORT 391 Mansour/Courtemanche/O'Leary 8 Expires August 1999 392 Arguments: none 394 Data: none 396 Result: 2.0 - success 397 2.2 - no command in progress 399 The ABORT command is issued by the sender to stop a command whose 400 latency time has been exceeded. When the latency time is specified on 401 the SENDATA command, the receiver must issue a reply to the sender 402 within the specified time. The reply may be a reply code indicating 403 that the server has not yet processed the request. The sender must 404 then tell the server whether to continue or abort. 406 The Sender can issue the ABORT command at any time after the SENDATA 407 command has been completed but before the sender receives a reply. 409 Example: 411 ... 412 S: RECIPIENT irip://cal.example.com/abc 413 R: 2.0 irip://cal.example.com/abc 414 S: RECIPIENT def 415 R: 2.0 416 S: SENDATA 10 417 R: 2.0.1 418 S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 419 S: Content-Transfer-Encoding: quoted-printable 420 S: 421 S: BEGIN:VCALENDAR 422 S: ... 423 S: END:VCALENDAR 424 S: . 425 # 10 seconds elapse... 426 R: . 427 R: 2.0.2 irip://cal.example.com/abc 428 R: 2.0.2 irip://cal.example.com/def 429 S: ABORT 430 R: 2.0.3 431 S: 433 The Receiver will issue the 8.2 reply code if it receives an ABORT 434 when the SENDATA or DEQUEUE command is not in progress. This could 435 happen if the Sender issues an ABORT command at a point in time after 436 the Receiver has completed the operation and issued the reply code but 437 before the Sender has actually received the reply code. For example: 439 S: SENDATA 10 440 S: 441 S: . 442 # 10 seconds elapse... 443 S: ABORT 445 Mansour/Courtemanche/O'Leary 9 Expires August 1999 446 R: 2.0 447 R: 8.2 449 In this case, the reply code 2.0 is in response to the [ICAL] object 450 and the reply code 8.2 is in response to the ABORT command. 452 3.1.2 AUTHENTICATE 454 Arguments: [] 456 Data: continuation data may be requested 458 Result: 2.0 - Authenticate completed, now in authenticated state 459 6.0 - Failed authentication 460 6.1 - authenticate failure: unsupported authentication 461 mechanism, credentials rejected 462 6.2 - Sender aborted authentication, authentication 463 exchange cancelled 464 6.3 - Unsupported Authentication Mechanism 465 9.1 - Unexpected command. 467 The AUTHENTICATE command is used by the client to identify the user to 468 the server. iRIP uses the [SASL] specification for authentication. 469 This allows iRIP users to choose from a variety of authentication 470 mechanisms. The only iRIP commands which can be issued before 471 authentication occurs are AUTHENTICATE, CAPABILITY, SWITCH and 472 DISCONNECT. 474 The AUTHENTICATE command initiates the authentication protocol 475 exchange. 477 is a registered SASL authentication mechanism. 478 (Refer to [SASL] for information on obtaining a list of currently 479 registered mechanisms.) is an optional parameter which 480 can be used for mechanisms which require an initial Sender response. 482 If the mechanism is not supported by the Receiver it must indicate 483 this with a "." CRLF and the reply code 6.1 indicating that the 484 authentication mechanism is not supported. Supported authentication 485 mechanisms can be discovered using the CAPABILITY command. 487 If the mechanism is supported an authentication protocol exchange 488 takes place, in the form of a series of Receiver challenges and Sender 489 responses. The Receiver terminates the exchange with the 490 . sequence followed by a reply code. Successful 491 authentication is indicated with the reply code 2.0, and unsuccessful 492 authentication is indicated with the reply code 6.0. If the 493 authentication was successful, but the authorization identity was not 494 accepted the status code 6.3 is used. Upon successful authentication 495 the protocol enters the Authenticated state, otherwise it remains in 496 the Connected state. 498 Mansour/Courtemanche/O'Leary 10 Expires August 1999 499 In the authentication protocol exchange both Receiver challenges and 500 Sender responses consist of the authentication mechanism data 501 transformed into BASE64 and followed by a CRLF. If the Sender wishes 502 to cancel an authentication exchange, it issues the . 503 sequence. Upon receipt of such an answer, the Receiver MUST indicate 504 the end of the exchange the . sequence followed by reply 505 code 6.2 indicating that the exchange was aborted. 507 If a security layer was negotiated it comes into effect for the 508 Receiver starting with the first octet transmitted after the CRLF 509 which follows the 2.0 reply code, and for the Sender starting with the 510 first octet after the CRLF that concludes the authentication exchange 511 for the client. Data is transmitted as described in [SASL]. 513 The service name specified by this protocol's profile of SASL is 514 "irip". 516 The following examples illustrate the various possiblities for an 517 authentication protocol exchange using Kerberos Version 4. 519 Successful authentication: 521 S: AUTHENTICATE KERBEROS_V4 522 R: AmFYig== 523 S: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 524 R: or//EoAADZI= 525 S: DiAF5A4gA+oOIALuBkAAmw== 526 R: . 527 R: 2.0 529 Failed authorization: 531 S: AUTHENTICATE KERBEROS_V4 532 R: AmFYig== 533 S: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 534 R: or//EoAADZI= 535 S: DiAF5A4gA+oOIALuBkAAmw== 536 R: . 537 R: 6.3 539 Failed authentication: 541 S: AUTHENTICATE KERBEROS_V4 542 R: AmFYig== 543 S: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 544 R: . 545 R: 6.0 547 Sender aborted authentication: 549 S: AUTHENTICATE KERBEROS_V4 551 Mansour/Courtemanche/O'Leary 11 Expires August 1999 552 R: AmFYig== 553 S: . 554 R: . 555 R: 6.2 557 Unsupported mechanism: 559 S: AUTHENTICATE Experimental_Auth 560 R: . 561 R: 6.1 563 3.1.2.1 Authentication with Proxy Access 565 Some [SASL] mechanisms allow the Sender to transmit an authorization 566 identity which is different from the authentication identity. iRIP 567 depends upon this ability in that it is servers who authenticate to 568 each other in order to process requests for users. The user which the 569 Sender is representing is transmitted as the authorization identity 570 during the [SASL] exchange. This identity takes the form of a CALID. 572 The authorization identity is used to administer the [ITIP] security 573 paradigm. Thus in an iRIP session REQUESTs may be issued for events of 574 which the authorized CALID is the Organizer, RESPONSEs or COUNTERs may 575 be issued for events which the authorized caladdress is Attending, 576 etc. 578 3.1.2.2 Selection of an Authentication Mechanism 580 The authentication mechanisms which a Receiver supports may be 581 discovered through use of the CAPABILITY. From the supplied list the 582 Sender may choose its preferred mechanism. 584 Not all mechanisms will be supported on all servers. There is no 585 minimum level of security which an iRIP compliant server is required 586 to support. This may result in iRIP servers which are unable to talk 587 to each other through lack of a common mechanism. This issue is 588 covered in more detail in the Security Considerations section of this 589 document. 591 3.1.3 CAPABILITY 593 Arguments: none 595 Data: Server capability information as described below 597 Result: 2.0 - authenticate completed, now in authenticated state 599 The CAPABILITY command tells the server to return a list of 600 capabilities it supports. The server must return a CAPABILITY 602 Mansour/Courtemanche/O'Leary 12 Expires August 1999 603 response with "iRIPrev1" as one of the listed capabilities. The 604 CAPABILITY command can be issued in any connection state. The response 605 may differ depending on the current state of the connection. The 606 responses may also differ depending upon the authenticated user. 608 Sender implementations SHOULD NOT require any capability name beyond 609 those defined in this specification, and MUST tolerate any unknown 610 capability names. This command may return different results in the 611 Connected states versus the Authenticated state. It may also return 612 different results depending on the authenticated calendar user. 614 The format of the capabilities response is a series of lines with the 615 form [=]. Each name-value pair is delimited by a 616 character sequence. Each line, including the terminating MUST 617 be 1024 characters or less. The sequence . followed by a 618 reply code terminates the response. 620 The table below summarizes the information available in response to a 621 CAPABILITY command. 623 Capability Occurs Description 624 --------------------- ------- ---------------------------------- 625 iRIPrev1 1 Revision of iRIP, must be 626 "iRIPrev1" 628 AUTH 0+ Authentication mechanism(s) 629 supported 631 MAXICALOBJECTSIZE 0 or 1 An integer value that specifies 632 the largest ICAL object (byte count) 633 the server will accept. Objects larger 634 than this will be rejected. 636 MAXDATE 0 or 1 The datetime value beyond which 637 the server cannot accept. 639 MINDATE 0 or 1 The datetime value prior to which 640 the server cannot accept. 642 Examples: 644 When executed from the Connected state the following occur: 646 S: CAPABILITY 647 R: iRIPrev1 648 R: AUTH=KERBEROS_V4 649 R: AUTH=PLAIN 650 R: . 651 R: 2.0 653 When executed from the Authenticated state the following occur: 655 Mansour/Courtemanche/O'Leary 13 Expires August 1999 656 S: CAPABILITY 657 R: CAPABILITY iRIPrev1 658 R: AUTH=KERBEROS_V4 659 R: AUTH=PLAIN 660 R: MAXICALOBJECTSIZE=50000 661 R: . 662 R: 2.0 664 3.1.4 CONTINUE 666 Arguments: [latencyTime] 667 Data: noneResult: results from the command in progress 668 2.0.2 reply pending. 669 9.1 unexpected command 671 The CONTINUE command is issued by the sender to allow an SENDATA 672 request to continue being processed. When the latency time is 673 specified on the SENDATA command, the Receiver must issue a reply to 674 the Sender within the specified time. The reply could be a reply code 675 indicating that the server has not yet processed the request. The 676 Sender must then tell the server whether to continue or abort the 677 command in progress. 679 The CONTINUE has the following form: 681 CONTINUE [latencyTime] 683 If the optional latencyTime is present, it is a positive integer that 684 specifies the maximum number of seconds the client will wait for the 685 next response. If it is omitted, the receiver waits an indefinite 686 period of time for the response. 688 In this example, the sender requests a response from the server every 689 10 seconds. 691 ... 692 S: RECIPIENT irip://A.example.com/sman 693 R: 2.0 694 S: SENDATA 10 695 R: 2.0.1 696 S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 697 S: Content-Transfer-Encoding: 7bit 698 S: 699 S: BEGIN:VCALENDAR 700 # etc... 701 S: END:VCALENDAR 702 S: . 704 # after 10 seconds... 706 Mansour/Courtemanche/O'Leary 14 Expires August 1999 707 R: . 708 R: 2.0.2 Reply Pending 709 S: CONTINUE 10 711 # less than 10 seconds elapse... 713 R: 2.0.11 irip://A.example.com/sman 714 R: Content-Type:text/calendar; method=REPLY; charset=US-ASCII 715 R: Content-Transfer-Encoding: 7bit 716 R: 717 R: BEGIN:VCALENDAR 718 # etc... 719 R: END:VCALENDAR 720 R: . 722 3.1.5 DEQUEUE 724 Arguments: caluid [latencyTime] 726 Data: a single queued itip message on success. 728 Result: 2.0 success 729 2.0.2 reply pending. 730 2.0.8 no more messages 731 3.8 no authority to perform this operation 732 9.1 unexpected command 734 The DEQUEUE command requests the Receiver to send a single queued 735 message to the Sender. This differs from using the SWITCH command in 736 several ways: 738 - the SWITCH command results in the Connected state after the 739 Sender and Receiver roles are reversed. This means that both the 740 Sender and Receiver must be prepared to handle the AUTHENTICATE 741 command. Using the DEQUEUE command, queued commands can be collected 742 by the original Sender without it having to handle the AUTHENTICATE 743 command. 744 - Only one message is transferred per DEQUEUE command. 745 - The single and implicit receiver of a DEQUEUE message is the 746 currently authenticated Sender. 748 If the Receiver has a queued message for the CALID and the 749 authenticated user is allowed to access the queue, it will be sent as 750 the reply to the DEQUEUE message. The message is followed by a 751 (required) . and a (required) response code. 753 Example: 755 S: DEQUEUE irip://cal.example.com/sman 756 R: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 757 R: Content-Transfer-Encoding: 7bit 759 Mansour/Courtemanche/O'Leary 15 Expires August 1999 760 R: 761 R: BEGIN:VCALENDAR 762 # etc... 763 R: END:VCALENDAR 764 R: . 765 R: 2.0 irip://cal.example.com/sman 766 S: DEQUEUE irip://cal.example.com/sman 767 R: . 768 R: 2.0.8 irip://cal.example.com/sman 770 3.1.6 DISCONNECT 772 Arguments: none 774 Data: none 776 Result: 2.0 - success 778 The DISCONNECT command signals the end of communication between the 779 Sender and Receiver. It SHOULD be issued only from the Authenticated 780 or Connected states. However, receiver implementations MUST be 781 prepared to handle a DISCONNECT at any point in this state diagram. 783 Example: 785 S: DISCONNECT 786 R: 2.0 788 3.1.7 RECIPIENT 790 Arguments: caluid [latencyTime] 792 Data: none 794 Result: 2.0 - Found the calendar 796 2.0.4 - caluid is not on this irip server but an 797 attempt will be made to deliver the 798 request or reply to the Calendar anyway. 799 A trust relationship exists with IRIP 800 server for caluid. 802 2.0.5 - just like 2.0.4 except that the message 803 MUST be queued. That is, it will not be 804 possible for this request to be 805 processed in real-time. 807 2.0.6 - The specified is not here but 808 an attempt will be made to deliver the 809 request or reply to anyway. 811 Mansour/Courtemanche/O'Leary 16 Expires August 1999 812 There is not a trust relationship 813 between the IRIP server and the IRIP 814 server for the target calendar. 816 3.8 - the authenticated iRIP session does not 817 have authority to perform [iTIP] 818 activities on . 820 5.3 - IRIP services for the specified calid 821 are not supported. 823 9.1 - Unexpected command 825 10.1 826 - is not supported by this iRIP 827 service but can be found . 828 Note that need not be of the 829 IRIP scheme. 831 The RECIPIENT command is used to identify a recipient of the iCalendar 832 Object. Use multiple RECIPIENT commands to specify multiple 833 recipients. 835 A reply code will be returned for each calendar address supplied. A 836 response code for each calendar address will also be returned after 837 the SENDATA command completes. 839 A reply code of 2.0 indicates that the calendar address is available 840 for [ITIP] messages. If the receiver does not accept [ITIP] messages 841 for the specified calendar address, it responds with [ITIP] reply code 842 5.3 to indicate that the calendar address is unknown. If the receiver 843 has a referral calendar address it responds with reply code 10.1 and 844 supplies the new calendar address. In either case, the iRIP server 845 does not deliver the [ITIP] message when the reply code is 5.3 or 846 10.1. 848 After the ITIP message has been sent, a reply code will be returned 849 for each of the recipients. 851 3.1.7.1 Fanout Issues On RECIPIENT 853 A receiver may be implemented such that it will fanout requests to 854 other iRIP servers. That is, a sender connects to iRIP receiver at 855 A.example.com and specifies a RECIPIENT calendar address on 856 B.example1.com. If the iRIP server at A.example.com handles getting 857 the request to the receiver at B.example1.com it supports fanout. 859 iRIP iRIP 860 Sender ----------- [A.example.com] ------------- [B.example.com] 862 An iRIP server implementation can implement fanout in different ways. 864 Mansour/Courtemanche/O'Leary 17 Expires August 1999 865 One way involves verifying remote recipient calendars in real-time. 866 Another way saves up all remote recipient calendars and simply 867 attempts to access them later. The advantage of verifying remote 868 calendars in real-time is that the sender is notified immediately, via 869 the reply code, whether or not the recipient calendar exists and is 870 accessible. For example, suppose that the iRIP server on A.example.com 871 just received the following command from Sender: 873 RECIPIENT irip://b.example.com/sam 875 If A.example.com immediately contacts B.example.com and issues a 876 RECIPIENT irip://b.example.com/sman and returns the reply back to 877 Sender, the sender will have an authoritative reply code (2.0 - 878 success, 3.7 - invalid calendar, or 10.1 - referral). On the other 879 hand, if A.example.com simply collects all the remote calendar 880 addresses and attempt to access them later in the transaction the 881 reply will be 2.0.4 (will attempt). The disadvantage of this approach 882 is that the sender does not know the status of the target calendar 883 during the RECIPIENT negotiation. 885 3.1.8 SENDATA 887 Arguments: [latencyTime] 889 Data: MIME encapsulated iCalendar object 891 Result: 2.0.1 - Begin sending the MIME encapsulated iCalendar 892 Object 893 9.1 - Unexpected command 895 After sending the iCalendar object a result is returned for each 896 recipient. These results can be the following: 898 2.0 - Success. [ITIP] message delivered. 899 2.0.2 - A timeout has occurred. 900 2.0.3 - In response to the client issuing an 901 ABORT 902 2.0.7 - The message has been queued for 903 delivery. 904 2.0.11 - Success. [ITIP] message delivered and a 905 response follows. 907 8.0 A failure has occurred in the receiver that 908 prevents the operation from succeeding. 910 8.1 Sent when a session cannot be established because 911 the iRIP Receiver is too busy. 913 8.2 Used to signal that an ICAL object has exceeded the 914 server's size limit. 916 Mansour/Courtemanche/O'Leary 18 Expires August 1999 917 9.0 An unrecongnized command (METHOD) was received. 919 9.1 A command was issued in a manner inconsistent with 920 the state diagram. For example, issuing the SENDATA 921 command without having specified a RECIPIENT will 922 cause this error. 924 10.2 The server is shutting down. 926 10.4 The operation has not be performed because it would 927 cause the resources (memory, disk, CPU, etc) to 928 exceed the allocated quota 930 The SENDATA command is used to specify the iCalendar Object that is to 931 be delivered to one or more recipients specified in the RECIPIENT 932 command. The format of the command sequence is: 934 S: SENDATA [latencyTime] 935 R: 2.0.1 936 S: 937 S: . 938 R: 940 # if the reply code above is 2.0.11 the following will also be sent: 942 R: 943 R: . 945 The optional latencyTime value specifies the maximum number of seconds 946 the sender will wait for a reply. If it is not present, the client 947 places no time limit on the server for a reply. A reply code of 2.0.1 948 indicates that the [ITIP] message data can be sent. The data must be 949 broken into lines that are 1024 characters (including the ending 950 or less. When the entire message has been sent, the sender 951 terminates sending data with the special sequence .. The 952 receiver reply MAY contain an [ITIP] message. The reply MUST contain 953 the special sequence . followed by a reply code for each 954 RECIPIENT. 956 The command sequence for an iRIP server that does not include an 957 [ITIP] message in the reply might appear as follows: 959 S: RECIPIENT irip://cal.example.com/johndoe 960 R: 2.0 961 S: RECIPIENT irip://cal.othersystem.com/xyz 962 R: 2.0.5 963 S: SENDATA 964 R: 2.0.1 965 # lots of data 966 S: . 967 R: . 968 R: 2.0 irip://cal.example.com/johndoe 970 Mansour/Courtemanche/O'Leary 19 Expires August 1999 971 R: 2.0.7 irip://cal.othersystem.com/xyz 973 If the reply code is 2.0.11, an [ITIP] message reply will follow. This 974 message will be terminated by the . sequence. iRIP servers 975 are not required to send [ITIP] messages in the reply to [ITIP] 976 requests delivered via the SENDATA command. However, the protocol 977 allows for high performance servers to do so. iRIP senders MUST accept 978 the [ITIP] message if the receiver includes it the reply. 980 3.1.9 SWITCH 982 Arguments: none 984 Data: none 986 Result: 2.0 Sender and receiver have switched roles. 987 The connection is switched to the 988 Connected State. 990 3.14 Unsupported command. That is, the 991 receiver refuses to switch roles. 993 The SWITCH command is used to allow the Sender and Receiver to change 994 roles. After a switch command is executed and the new Sender 995 authenticates, all queued commands that the new Sender has queued for 996 the new Receiver will be delivered. 998 The SWITCH command is useful in environments where the firewall of a 999 Sender would not allow the Receiver to initiate a connection. The 1000 SWITCH command is issued by the Sender to give the Receiver the 1001 opportunity to take the role of the Sender. The Sender must be in the 1002 authenticated state before the SWITCH command can be used. 1004 The Receiver must respond in one of the following fashions: 1006 - send an OK reply and take on the role of Sender 1007 - send a error reply indicating refusal and retain the role of 1008 Receiver 1010 If program-A is currently the Sender and sends the SWITCH command and 1011 receives an OK reply then program-A becomes the Receiver. The IRIP 1012 connection returns to the Connected state. Program-A is then in its 1013 initial state and sends a service ready response code of 2.0. 1015 If program-B is currently the Receiver and sends an OK reply in 1016 response to a SWITCH command then program-B becomes the Sender. 1017 Program-B is then in the initial state (connected) as if it had just 1018 connected to Program-A, and expects to receive a response code of 2.0. 1020 3.2 Fanout and Queued Transactions 1022 Mansour/Courtemanche/O'Leary 20 Expires August 1999 1023 An iRIP server must be able to fanout requests targeted at other iRIP 1024 servers. An iRIP server may queue information targeted at other iRIP 1025 servers. There are several reasons for queing requests. One reason is 1026 that firewall issues may prevent one server from contacting another. 1028 iRIP servers can establish trust relationships between each other. A 1029 trusted relationship means: 1031 - one server must authenticate with the other 1032 - authenticated calendars on one server are trusted and treated as 1033 authenticated on the other. 1035 The trusted relationship need not be bi-directional. That is, the fact 1036 that iRIP server A trusts iRIP server B does not necessarily mean that 1037 B trusts A. 1039 A trusted relationship between two iRIP servers means that one server 1040 can queue transactions for the other server and deliver them some time 1041 later. If iRIP server B trusts A, then A can queue requests for B. If 1042 A does not trust B then B cannot accumulate requests for A. [Editors 1043 Note: do we really want to impose this restriction?] 1045 Certain requests may need to be delivered and replied to in real-time. 1046 In fact, a requester may wish to cancel the request if the reply 1047 cannot be delivered in real-time. In iRIP the reply code to the 1048 RECIPIENT command indicates whether or not a reply will be made in 1049 real-time (barring connection and hardware failures). This allows the 1050 sender to abort the request if necessary. 1052 3.3 Bi-Directional Queue Operation 1054 It is possible that firewall configurations may not allow a connection 1055 between two iRIP servers in either direction. That is, in the diagram 1056 below, suppose there are two users, sender1 and sender2, who wish to 1057 exchange [ITIP] messages. Their calendar addresses are 1058 irip://B.foo.com/sender1 and irip://D.bar.com/sender2. The firewall 1059 in front of B.foo.com prevents incoming external connections on the 1060 iRIP server port. However, it allows outbound external connections on 1061 the iRIP server port to happen. Similarly, the firewall in front of 1062 D.bar.com also prevents inbound connections on the iRIP server port, 1063 but allows outbound connections. To allow sender1 and sender2 to 1064 exchange iRIP messages an intermediate iRIP server, C.foobar.com, is 1065 used to queue messages for both of their calendars. A trust 1066 relationship between the intermediate iRIP server and the endpoint 1067 servers (B.foo.com and D.bar.com) is desirable but not required. 1068 [Editors note: is desired but not required OK with everyone?] 1070 iRIP +-----------+ +-----------+ iRIP 1071 sender1 --------| B.foo.com |--#--+--#--| D.bar.com |------- sender2 1072 +-----------+ | +-----------+ 1073 | 1074 +----------------+ 1076 Mansour/Courtemanche/O'Leary 21 Expires August 1999 1077 | C.foobar.com | 1078 +----------------+ 1079 3.4 Reply Codes 1081 iRIP error codes follow the format defined for Status Replies in 1082 [ITIP]. All Status Replies as defined in [ITIP] are valid error codes 1083 when returned by an iRIP command. 1085 In addition to those defined in [ITIP], iRIP defines the following 1086 error codes: 1088 REPLY 1089 CODE DESCRIPTION MEANING 1090 ------ ---------------------- -------------------------------------- 1091 2.0 STATOK Operation was successfully performed. 1093 2.0.1 START-SENDATA Start ICAL input; end with 1094 . 1096 2.0.11 OK-DATAFOLLOWS The request was processed 1097 successfully. Reply data follows on 1098 the next line and terminates with 1099 . 1101 2.0.2 REPLY-PENDING A timeout has occurred. The server is 1102 still working on the reply. Use 1103 CONTINUE to continue waiting for the 1104 reply or ABORT to terminate the 1105 command. 1107 2.0.3 ABORTED In response to the client issuing an 1108 ABORT command, this reply code 1109 indicates that any command currently 1110 underway was successsfully aborted. 1112 2.0.4 WILL-ATTEMPT The specified Calendar is not here 1113 but an attempt will be made to deliver 1114 the request or reply to the Calendar 1115 anyway. There is a trust relationship 1116 between this iRIP server and the 1117 iRIP server for the target calendar. 1119 2.0.5 TRUSTED-WILL-QUEUE The specified Calendar cannot be 1120 contacted directly and a trust 1121 relationship exists between this 1122 server and the server on which the 1123 Calendar exists. The request or reply 1124 will be queued and delivered to the 1125 target calendar when its iRIP server 1126 contacts this server and issues the 1127 SWITCH command. 1129 Mansour/Courtemanche/O'Leary 22 Expires August 1999 1130 2.0.6 WILL-ATTEMPT The specified Calendar is not here 1131 but an attempt will be made to deliver 1132 the request or reply to the Calendar 1133 anyway. There is not a trust 1134 relationship between the iRIP server 1135 and the iRIP server for the target 1136 calendar. 1138 2.0.7 QUEUED The message has been queued for 1139 delivery. 1141 2.0.8 QUEUE-EMPTY There are no more queued messages. 1143 2.2 NO COMMAND IN PROGRESS An ABORT or CONTINUE was received when 1144 no command was in progress 1146 6.1 AUTHENTICATE FAILURE Unsupported authentication mechanism, 1147 credentials rejected 1149 6.2 AUTHENTICATION ABORTED Sender aborted authentication, 1150 authentication exchange cancelled 1152 8.0 GENERAL FAILURE A failure has occurred in the Receiver 1153 that prevents the operation from 1154 succeeding. 1156 8.1 SERVER TOO BUSY Sent when a session cannot be 1157 established because the iRIP 1158 Receiver is too busy. 1160 8.2 ICAL OBJECT TOO BIG Used to signal that an ICAL object has 1161 exceeded the server's size limit. 1163 8.3 DATE TOO LARGE A DATETIME value was too far in the 1164 future to be represented on this 1165 Calendar. 1167 8.4 DATE TOO SMALL A DATETIME value was too far in the 1168 past to be represented on this 1169 Calendar. 1171 9.0 INVALID iRIP COMMAND An unrecongnized command was received. 1173 9.1 UNEXPECTED COMMAND A command was issued in a manner 1174 inconsistent with the state diagram. 1175 For example, issuing the SENDATA 1176 command without having specified any 1177 RECIPIENTs will cause this error. 1179 10.1 REFERRAL Accompanied by an alternate address. 1180 The RECIPIENT specified should be 1181 contacted at the given alternate 1183 Mansour/Courtemanche/O'Leary 23 Expires August 1999 1184 address. The referral address MUST 1185 follow the reply code. 1187 10.2 SERVER SHUT DOWN The server is shutting down. 1189 10.3 SERVER STOPPING FLOOD 2 1191 10.4 EXCEEDED QUOTAS The operation has not be performed 1192 because it would cause the resources 1193 (memory, disk, CPU, etc) to exceed the 1194 allocated quota 1196 10.5 QUEUED TOO LONG The ITIP message has been queued too 1197 long. Delivery has been aborted. 1199 4 Implementation Considerations 1201 It is strongly recommended that when an iRIP implementation encounters 1202 an error requiring the communication channel between the Sender and 1203 Receiver to be dropped that the DISCONNECT command be issued rather 1204 than simply breaking the communication channel. 1206 5 Security Considerations 1208 The security of iRIP with [SASL] support is highly dependent on the 1209 mechanism used to authenticate the client and whether or not the 1210 security layer is further negotiated. Without a robust security layer, 1211 iRIP transactions are subject to eavesdropping and the integrity of 1212 iRIP transactions may be compromised. Since iRIP is designed 1213 specifically for real time transactions, it is recommended that 1214 implementations use the highest degree of authentication and 1215 transmission security possible. 1217 5.1 Security Threats and Recommendations 1218 In addition to the security risks detailed in [ITIP], the following 1219 sections discuss security risks in using iRIP as the transport 1220 binding. 1222 5.1.1 Authentication Hacking 1224 Once authenticated, senders can re-authenticate from the Authenticated 1225 state. It is possible that, once authenticated, a sender could take 1226 advantage of this capability and repeatedly attempt to guess at 1227 calendar user credentials. It is recommended that implementations 1228 disconnect after a failed authentication attempt from the 1229 Authenticated state. 1231 Mansour/Courtemanche/O'Leary 24 Expires August 1999 1232 5.1.2 Spoofing 1234 The [ITIP] paradigm allows any modifications to data by its Organizer, 1235 which maps to the [SASL] authorization identity. This means that 1236 authorizing with appropriate identities over iRIP will allow read and 1237 write access to any item in the Receiver's database. There are 1238 several ways to limit this security risk. 1240 The choice of accepted authentication mechanisms can reduce the 1241 security risk. The ANONYMOUS mechanism allows a greater level of 1242 interoperability, in that any Sender can connect anonymously, but 1243 greatly increases the security risk for the same reason. 1245 The method in which authorizations are accepted can also be modified 1246 to improve security. Some hosts may be trusted to authorize as any 1247 caladdress, while others may be only be trusted to authorize as users 1248 in their domain. 1250 [ITIP] data is transmitted in MIME containers, which provide a 1251 facility for digitally signing their data. A sender may use this 1252 scheme in order to provide a final security fallback. 1254 Finally, some implementations may decide to queue incoming iRIP 1255 commands for approval by the owner of the calendar, although this is 1256 certainly the least reliable of these security mechanisms. 1258 5.1.3 Eavesdropping 1260 The use of SASL in iRIP allows the negotiation of an encrypted 1261 security layer, which greatly reduces the chances that a connection 1262 will be subject to eavesdropping. 1264 However, if another iRIP server is being used to relay iRIP data this 1265 relay server is privy to whatever information is being transmitted. 1266 For this reason it may be desirable to use MIME's encryption facility 1267 to protect the data. 1269 5.1.4 Connection Flooding 1271 Servers should be configurable to timeout unused connections. 1273 5.2 Security Interoperability Issues 1275 * minimum SASL mechanism 1276 [ed note: tbd Paul Hill to supply ] 1277 * add a failure case under 6.3 1279 6 Examples 1281 6.1 Unauthenticated Freebusy Request 1283 Mansour/Courtemanche/O'Leary 25 Expires August 1999 1284 This examples shows an anonymous request for the freebusy time of 1285 irip://cal.example.com/sman. Note that once xyz is authenticated on 1286 the IRIP server either the fully qualified IRIP CALID or the relative 1287 CALID can be used to reference a Calendar. That is, 1288 "irip://cal.example.com/xyz" and "xyz" refer to the same calendar and 1289 can be used interchangeably. 1291 R: 1292 S: 1293 R: 2.0 1294 S: AUTHENTICATE ANONYMOUS 1295 R: 2.0 1296 S: RECIPIENT:irip://b.foo.bar/sman 1297 R: 2.0 1298 S: SENDATA 1299 R: 2.0.1 1300 S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 1301 S: Content-Transfer-Encoding: 7bit 1302 S: 1303 S: BEGIN:VCALENDAR 1304 S: PRODID:-//ACME/DesktopCalendar//EN 1305 S: METHOD:REQUEST 1306 S: VERSION:2.0 1307 S: BEGIN:VFREEBUSY 1308 S: ORGANIZER: irip://b.foo.bar/xyz 1309 S: ATTENDEE: irip://b.foo.bar/sman 1310 S: DTSTAMP:19971113T190000Z 1311 S: DTSTART:19971115T160000Z 1312 S: DTEND:19971116T040000Z 1313 S: UID:www.example.com-873970198738777@host.com 1314 S: END:VFREEBUSY 1315 S: END:VCALENDAR 1316 S: . 1318 # server looks up the freebusy time and builds a reply> 1320 R: 2.0.11 irip://cal.example.com/sman 1321 R: Content-Type:text/calendar; method=REPLY; charset=US-ASCII 1322 R: Content-Transfer-Encoding: 7bit 1323 R: 1324 R: BEGIN:VCALENDAR 1325 R: PRODID:-//EXAMPLE/DesktopCalendar//EN 1326 R: METHOD:REPLY 1327 R: VERSION:2.0 1328 R: BEGIN:VFREEBUSY 1329 R: ORGANIZER:irip://cal.example.com/xyz 1330 R: ATTENDEE:irip://cal.example.com/sman 1331 R: DTSTAMP:19971113T190005Z 1332 R: DTSTART:19971115T160000Z 1333 R: DTEND:19971116T040000Z 1334 R: UID:www.example.com-873970198738777@host.com 1336 Mansour/Courtemanche/O'Leary 26 Expires August 1999 1337 R: FREEBUSY:19971115T230000Z/PT1H,19971115T210000Z/PT30M 1338 R: END:VFREEBUSY 1339 R: END:VCALENDAR 1340 R: . 1341 S: DISCONNECT 1342 R: 2.0 1343 R: 1344 S: 1346 6.2 Busy Time Request 1348 In this example, the sender sends a Freebusy request to the iRIP 1349 server at B.foo.com for several calendars. Some of the calendars are 1350 on other calendar stores. The sender needs the information immediately 1351 and will abort any attempt to queue requests. 1353 R: 1354 S: 1355 R: 2.0 1356 S: AUTHENTICATE KERBEROS_V4 93407205 1358 # more authentication information 1360 R: 2.0 1361 S: RECIPIENT:irip://B.foo.com/bill 1362 R: 2.0 1363 S: RECIPIENT:irip://C.foobar.com/cathy 1364 R: 2.0.4 1365 S: RECIPIENT:irip://D.bar.com/david 1366 R: 2.0.5 1367 S: RECIPIENT:irip://E.barfoo.com/eddie 1368 R: 2.0.6 1370 # the sender does not want this ITIP message to be queued request. 1371 # So, the current operation will be canceled. The operation will be 1372 # tried again with attendees that can be serviced in real-time. 1374 S: ABORT 1375 R: 2.0.3 1376 S: RECIPIENT:irip://B.foo.com/bill 1377 R: 2.0 1378 S: RECIPIENT:irip://C.foobar.com/cathy 1379 R: 2.0.4 1380 S: RECIPIENT:irip://E.barfoo.com/eddie 1381 R: 2.0.6 1382 S: SENDATA 1383 R: 2.0.1 1384 S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 1385 S: Content-Transfer-Encoding: 7bit 1386 S: 1387 S: BEGIN:VCALENDAR 1388 S: PRODID:-//ACME/DesktopCalendar//EN 1390 Mansour/Courtemanche/O'Leary 27 Expires August 1999 1391 S: METHOD:REQUEST 1392 S: VERSION:2.0 1393 S: BEGIN:VFREEBUSY 1394 S: ORGANIZER:irip://B.foo.com/bill 1395 S: ATTENDEE:irip://B.foo.com/bill 1396 S: ATTENDEE:irip://C.foobar.com/cathy 1397 S: ATTENDEE:irip://D.bar.com/david 1398 S: ATTENDEE:irip://E.barfoo.com/eddie 1399 S: DTSTAMP:19971113T190000Z 1400 S: DTSTART:19971115T160000Z 1401 S: DTEND:19971116T040000Z 1402 S: UID:www.example.com-873970198738777@host.com 1403 S: END:VFREEBUSY 1404 S: END:VCALENDAR 1405 S: . 1407 # server looks up the freebusy time for irip://B.foo.com/bill, 1408 # requests and receives the freebusy time for 1409 # irip://C.foobar.com/cathy and irip://E.barfoo.com/eddie. Then it 1410 # builds a reply 1412 R: 2.0.11 irip://B.foo.com/bill 1413 R: Content-Type:text/calendar; method=REPLY; charset=US-ASCII 1414 R: Content-Transfer-Encoding: 7bit 1415 R: 1416 R: BEGIN:VCALENDAR 1417 R: PRODID:-//EXAMPLE/DesktopCalendar//EN 1418 R: METHOD:REPLY 1419 R: VERSION:2.0 1420 R: BEGIN:VFREEBUSY 1421 S: ORGANIZER:irip://B.foo.com/bill 1422 R: ATTENDEE:irip://B.foo.com/bill 1423 R: DTSTAMP:19971113T190005Z 1424 R: DTSTART:19971115T160000Z 1425 R: DTEND:19971116T040000Z 1426 R: UID:www.example.com-873970198738777@host.com 1427 R: FREEBUSY:19971115T200000Z/PT1H,19971116T030000Z/PT30M 1428 R: END:VFREEBUSY 1429 R: END:VCALENDAR 1430 R: . 1431 R: 2.0.11 irip://C.foobar.com/cathy 1432 R: Content-Type:text/calendar; method=REPLY; charset=US-ASCII 1433 R: Content-Transfer-Encoding: 7bit 1434 R: 1435 R: BEGIN:VCALENDAR 1436 R: PRODID:-//EXAMPLE/DesktopCalendar//EN 1437 R: METHOD:REPLY 1438 R: VERSION:2.0 1439 R: BEGIN:VFREEBUSY 1440 S: ORGANIZER:irip://B.foo.com/bill 1441 R: ATTENDEE:irip://C.foobar.com/cathy 1442 R: DTSTAMP:19971113T190005Z 1444 Mansour/Courtemanche/O'Leary 28 Expires August 1999 1445 R: DTSTART:19971115T160000Z 1446 R: DTEND:19971116T040000Z 1447 R: UID:www.example.com-873970198738777@host.com 1448 R: FREEBUSY:19971115T230000Z/PT1H,19971116T020000Z/PT30M 1449 R: END:VFREEBUSY 1450 R: END:VCALENDAR 1451 R: . 1452 R: 2.0.11 irip://E.barfoo.com/eddie 1453 R: Content-Type:text/calendar; method=REPLY; charset=US-ASCII 1454 R: Content-Transfer-Encoding: 7bit 1455 R: 1456 R: BEGIN:VCALENDAR 1457 R: PRODID:-//EXAMPLE/DesktopCalendar//EN 1458 R: METHOD:REPLY 1459 R: VERSION:2.0 1460 R: BEGIN:VFREEBUSY 1461 S: ORGANIZER:irip://B.foo.com/bill 1462 R: ATTENDEE:irip://E.barfoo.com/eddie 1463 R: DTSTAMP:19971113T190005Z 1464 R: DTSTART:19971115T160000Z 1465 R: DTEND:19971116T040000Z 1466 R: UID:www.example.com-873970198738777@host.com 1467 R: FREEBUSY:19971115T230000Z/PT1H,19971116T020000Z/PT30M 1468 R: END:VFREEBUSY 1469 R: END:VCALENDAR 1470 R: . 1471 S: DISCONNECT 1472 R: 2.0 1473 R: 1474 S: 1476 6.3 Using Switch 1478 This session demonstrates how a poll can be accomplished using the 1479 SWITCH command. In this case, the receiver (A.example.com) becomes 1480 the sender after issuing the switch command. 1482 # receiver is currently A.example.com, the sender is B.xyz.com 1483 R: 1484 S: 1485 R: 2.0 1486 S: AUTHENTICATE KERBEROS_V4 1487 # more authentication... 1488 R: 2.0 1489 S: SWITCH 1490 R: 2.0 1492 # The connection state has returned to the Connected state. 1493 A.example.com 1494 # must now Authenticate with B.xyz.com 1496 Mansour/Courtemanche/O'Leary 29 Expires August 1999 1497 S: 2.0 1498 R: AUTHENTICATE KERBEROS_V4 1499 # more authentication... 1500 R: 2.0 1502 # Now that the switch has occurred, A.example.com is the sender and 1503 # B.xyz.com is the receiver. At this point, A.example.com sends all 1504 # queued commands for recipients on B.xyz.com 1506 S: RECIPIENT:irip://B.xyz.com/sman 1507 R: 2.0 1508 S: SENDATA 1509 R: 2.0.1 1510 S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 1511 S: Content-Transfer-Encoding: 7bit 1512 S: 1513 S: BEGIN:VCALENDAR 1514 S: PRODID:-//ACME/DesktopCalendar//EN 1515 S: METHOD:REQUEST 1516 S: VERSION:2.0 1517 S: BEGIN:VFREEBUSY 1518 S: ORGANIZER:irip://A.example.com/billybob 1519 S: ATTENDEE:irip://B.xyz.com/sman 1520 S: DTSTAMP:19981113T190000Z 1521 S: DTSTART:19981115T160000Z 1522 S: DTEND:19981116T160000Z 1523 S: UID:123456abcdef.1234.2314 1524 S: END:VFREEBUSY 1525 S: END:VCALENDAR 1526 S: . 1528 # server looks up the freebusy time and builds a reply 1530 R: 2.0.11 irip://B.xyz.com/sman 1531 R: Content-Type:text/calendar; method=REPLY; charset=US-ASCII 1532 R: Content-Transfer-Encoding: 7bit 1533 R: 1534 R: BEGIN:VCALENDAR 1535 R: PRODID:-//EXAMPLE/DesktopCalendar//EN 1536 R: METHOD:REPLY 1537 R: VERSION:2.0 1538 R: BEGIN:VFREEBUSY 1539 R: ORGANIZER:irip://cal.example.com/xyz 1540 R: ATTENDEE:irip://cal.example.com/sman 1541 R: DTSTAMP:19981113T190005Z 1542 R: DTSTART:19981115T160000Z 1543 R: DTEND:19981116T160000Z 1544 R: UID:123456abcdef.1234.2314 1545 R: FREEBUSY:19981115T230000Z/PT1H,19981115T210000Z/PT30M 1546 R: END:VFREEBUSY 1547 R: END:VCALENDAR 1548 R: . 1550 Mansour/Courtemanche/O'Leary 30 Expires August 1999 1551 # A.example.com has no more queued ITIP messages for B.xyz.com. 1552 # So, it disconnects... 1554 S: DISCONNECT 1555 R: 2.0 1556 R: 1557 S: 1559 6.4 Fanout Requests 1561 6.4.1 Successful Fanout Request 1563 In the diagram below, sender has authenticated to the iRIP server 1564 B.foo.com and is attempting to deliver a request to calendars on 1565 B.foo.com and C.foobar.com. The iRIP server on B.foo.com supports 1566 fanout. It verifies remote calendars during the RECIPIENT negotiation 1567 with sender. 1569 +-----------+ +-----------+ 1570 sender ---------| B.foo.com |---------| D.bar.com | 1571 +-----------+ +-----------+ 1573 Connection between S and B.foo.com 1574 S = sender 1575 R = B.foo.com 1576 ----------------------------------- 1577 R: 1578 S: < connect to B.foo.com port 5228> 1579 R: 2.0 1580 S: AUTHENTICATE KERBEROS_V4 93407205 1581 # more authentication information 1582 R: 2.0 1583 S: RECIPIENT:irip://B.foo.com/bill 1584 R: 2.0 1585 S: RECIPIENT:irip://D.bar.com/david 1587 Connection B.foo.com to D.bar.com 1589 S = B.foo.com 1590 R = D.bar.com 1591 ---------------------------------- 1592 R: 1593 S: 1594 R: 2.0 1595 S: 1597 R: 2.0 1598 S: RECIPIENT:irip://D.bar.com/david 1599 R: 2.0 1600 R: 2.0 1602 Mansour/Courtemanche/O'Leary 31 Expires August 1999 1603 S: SENDATA 1604 R: 2.0.1 1605 S: 1606 S: . S: SENDATA 1607 R: 2.0.1 1608 S: 1609 S: . 1610 R: . 1611 R: 2.0 irip://D.bar.com/david 1612 R: . 1613 R: 2.0 irip://B.foo.com/bill 1614 R: 2.0 irip://D.bar.com/david 1615 S: DISCONNECT 1616 R: 2.0 1618 6.4.2 Referral On Fanout 1620 This example is just like the one above except that in this case the 1621 remote calendar no longer exists and a referral is returned. The 1622 sender cancels the transaction in the RECIPIENT phase (using ABORT) 1623 and starts a new transaction that uses the referral address. 1625 +-----------+ +-----------+ 1626 sender ---------| B.foo.com |----+----| D.bar.com | 1627 +-----------+ | +-----------+ 1628 | 1629 | +-----------+ 1630 +----| E.xyz.com | 1631 +-----------+ 1633 Connection between S and B.foo.com 1634 S = sender 1635 R = B.foo.com 1636 ==================================== 1637 S: < connect to B.foo.com port 5228> 1638 R: 2.0 1639 S: AUTHENTICATE KERBEROS_V4 93407205 1640 S: 1641 R: 2.0 1642 S: RECIPIENT:irip://B.foo.com/bill 1643 R: 2.0 1644 S: RECIPIENT:irip://D.bar.com/david 1646 Connection B.foo.com to D.bar.com 1648 S = B.foo.com 1649 R = D.bar.com 1650 =================================== 1652 R: 1654 Mansour/Courtemanche/O'Leary 32 Expires August 1999 1655 S: 1656 R: 2.0 1657 S: 1659 R: 2.0 1660 S: RECIPIENT:irip://D.bar.com/david 1661 R: 10.1 irip://E.xyz.com/david99 1662 R: 10.1 irip://E.xyz.com/david99 1663 S: ABORT 1664 R: 2.0.3 1665 S: RECIPIENT:irip://B.foo.com/bill 1666 R: 2.0 1667 S: RECIPIENT irip://E.xyz.com/david99 1669 Connection B.foo.com to E.xyz.com 1670 S = B.foo.com 1671 R = E.xyz.com 1672 =================================== 1673 S: 1674 R: 2.0 1675 S: 1677 R: 2.0 1678 S: RECIPIENT irip://E.xyz.com/david99 1679 R: 2.0 1680 R: 2.0 1681 S: SENDATA 1682 R: 2.0.1 1683 S: 1684 S: . S: SENDATA 1685 R: 2.0.1 1686 S: 1687 S: . 1688 R: . 1689 R: 2.0 irip://E.xyz.com/david99 1690 R: . 1691 R: 2.0 irip://B.foo.com/bill 1692 R: 2.0 irip://E.xyz.com/david99 1693 S: DISCONNECT 1694 R: 2.0 1696 6.5 Queued Requests 1698 In the diagram below, sender S has authenticated to the iRIP server 1699 B.foo.com. C.foobar.com, D.bar.com, and E.barfoo.com all have iRIP 1700 servers. The iRIP server on B.foo.com has a trusted relationship with 1701 iRIP servers on both C.foobar.com and D.bar.com. A firewall is in 1702 place that prohibits iRIP server B.foo.com from initiating a 1703 connection to the iRIP server on D.bar.com. However, iRIP server 1704 D.bar.com can connect to iRIP server B.foo.com. 1706 Mansour/Courtemanche/O'Leary 33 Expires August 1999 1707 +--------------+ 1708 +------| C.foobar.com | 1709 | +--------------+ 1710 | 1711 +-----------+ | +-----------+ 1712 S ---------| B.foo.com |------#--| D.bar.com | 1713 +-----------+ | +-----------+ 1714 | 1715 | +--------------+ 1716 +------| E.barfoo.com | 1717 +--------------+ 1719 6.5.1 Meeting Invitation 1721 In this example, S sends an event request to the iRIP server on B for 1722 calendars on B, C, D, and E. Note that C's address moved from foo.com 1723 to foobar.com and is reported to the sender during the RECIPIENT 1724 negotiation. 1726 R: 1727 S: 1728 R: 2.0 1729 S: AUTHENTICATE KERBEROS_V4 93407205 1730 S: 1731 R: 2.0 1732 S: RECIPIENT irip://B.foo.com/bill 1733 R: 2.0 1734 S: RECIPIENT irip://C.foobar.com/cathy 1735 R: 10.1 irip://C.foobar.com/cathy 1736 S: RECIPIENT irip://C.foobar.com/cathy 1737 R: 2.0.4 1738 S: RECIPIENT irip://D.bar.com/david 1739 R: 2.0.5 1740 S: RECIPIENT irip://E.barfoo.com/eddie 1741 R: 2.0.6 1742 S: SENDATA 16 1743 R: 2.0.1 1744 S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 1745 S: Content-Transfer-Encoding: 7bit 1746 S: 1747 S: BEGIN:VCALENDAR 1748 S: PRODID:-//ACME/DesktopCalendar//EN 1749 S: METHOD:REQUEST 1750 S: VERSION:2.0 1751 S: BEGIN:VEVENT 1752 S: ORGANIZER:irip://B.foo.com/bill 1753 S: ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:irip://B.foo.com/bill 1754 S: ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:irip://C.foobar.com/cathy 1755 S: ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:irip://D.bar.com/david 1756 S: ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:irip://E.barfoo.com/eddie 1757 S: DTSTAMP:19981011T190000Z 1758 S: DTSTART:19981101T200000Z 1760 Mansour/Courtemanche/O'Leary 34 Expires August 1999 1761 S: DTEND:19981101T2100000Z 1762 S: SUMMARY:Conference 1763 S: UID:calsrv.example.com-873970198738777@example.com 1764 S: SEQUENCE:0 1765 S: STATUS:CONFIRMED 1766 S: END:VEVENT 1767 S: END:VCALENDAR 1768 S: . 1769 R: . 1770 R: 2.0 irip://B.foo.com/bill 1771 R: 2.0 irip://C.foobar.com/cathy 1772 R: 2.0.7 irip://D.bar.com/david 1773 R: 2.0 irip://E.barfoo.com/eddie 1774 S: DISCONNECT 1775 R: 2.0 1776 R: 1777 S: 1779 The invitation is written to the calendar B.foo.com/bill. iRIP server 1780 B.foo.com authenticates to C.foobar.com and sends the event request, 1781 which is successfully written to C.foobar.com/cathy. The iRIP server 1782 on B.foo.com cannot contact D.bar.com, but a trust relationship exists 1783 between them and the request is queued for delivery. This request will 1784 be delivered the next time the iRIP server on D.bar.com connects to 1785 the iRIP server on B.foo.com and issues a SWITCH command. The iRIP 1786 server on B.foo.com connects to the iRIP server on E.barfoo.com and 1787 authenticates as anonymous since it has no trust relationship with 1788 E.barfoo.com. If the anonymous authentication is successful, the event 1789 request is delivered to E.barfoo.com/eddie. 1791 7 Acknowledgments 1792 The following have participated in the drafting and discussion of this 1793 memo: 1795 Frank Dawson, Bruce Kahn, Doug Royer, Mugino Saeki 1797 8 Bibliography 1798 [ICAL] F. Dawson, D. Stenerson, "Internet Calendaring and Scheduling 1799 Core Object Specification - iCalendar", RFC-2445, November 1998, 1800 http://www.imc.org/rfc2445. 1802 [ITIP] S. Silverberg, S. Mansour, F. Dawson, R. Hopson, "iCalendar 1803 Transport-Independent Interoperability Protocol (iTIP) : Scheduling 1804 Events, Busy Time, To-dos and Journal Entries", RFC-2446, November 1805 1998, http://www.imc.org/rfc2446. 1807 [IMIP] F. Dawson, S. Mansour, S. Silverberg, "iCalendar Message-based 1808 Interoperability Protocol (iMIP), ", RFC-2447, November 1998, 1809 http://www.imc.org/rfc2447. 1811 [ID-UTF8] 3"UTF-8, a transformation format of ISO 10646. F. Yergeau.", 1813 Mansour/Courtemanche/O'Leary 35 Expires August 1999 1814 RFC 2299, January 1998 1816 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 1817 Messages", STD 11, RFC 822, August 1982. 1819 [RFC-1847]. J. Galvin, S. Murphy, S. Crocker & N. Freed, "Security 1820 Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1821 1847, October 1995. 1823 [RFC-2112] Levinson, E., "The MIME Multipart/Related Content-type," 1824 RFC 2112, March 1997. 1826 [RFC-2015] M. Elkins, "MIME Security with Pretty Good Privacy (PGP)," 1827 RFC 2015, October 1996. 1829 [RFC-2045] Freed, N., Borenstein, N., " Multipurpose Internet Mail 1830 Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC 1831 2045, November 1996. 1833 [RFC-2046] Freed, N., Borenstein, N., " Multipurpose Internet Mail 1834 Extensions (MIME) - Part Two: Media Types", RFC 2046, November 1996. 1836 [RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) - 1837 Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 1838 November 1996. 1840 [RFC-2048] Freed, N., J. Klensin, J. Postel, "Multipurpose Internet 1841 Mail Extensions (MIME) - Part Four: Registration Procedures", RFC 1842 2048, January 1997. 1844 [RFC-2222] J. Meyers, Simple Authentication and Security Layer 1845 (SASL)", RFC 2222, October 1997. 1847 [RFC2396] Berners-Lee, Fielding, Masinter, "Uniform Resource 1848 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 1850 [RFC-2445] Dawson, Stenerson, "Internet Calendaring and Scheduling 1851 Core Object Specification (iCalendar)", RFC 2445, November 1998 1853 [RFC-2446] Silverberg, Mansour, Dawson, Hopson, "iCalendar Transport- 1854 Independent Interoperability Protocol (iTIP)", RFC 2446, November 1998 1856 [RFC-2447] Dawson, Mansour, Silverberg, "iCalendar Message-Based 1857 Interoperability Protocol (iMIP)", RFC 2445, November 1998 1859 9 Open Issues 1861 Registration of the [SASL] profile for iRIP with the IANA. 1862 Port Number registration 1864 10 Author's Address 1866 Mansour/Courtemanche/O'Leary 36 Expires August 1999 1867 The following address information is provided in a vCard v2.1, 1868 Electronic Business Card, format. 1870 BEGIN:VCARD 1871 VERSION:2.1 1872 FN:Steve Mansour 1873 ORG:Netscape Communications Corporation 1874 ADR;WORK;POSTAL;PARCEL:;;501 East Middlefield Road;Mountain 1875 View;CA;94043;USA 1876 TEL;WORK;MSG:+1-650-937-2378 1877 TEL;WORK;FAX:+1-650-937-2103 1878 EMAIL;INTERNET:sman@netscape.com 1879 END:VCARD 1881 BEGIN:VCARD 1882 FN:Andre Courtemanche 1883 ORG:CS&T 1884 ADR;WORK;POSTAL;PARCEL:;;3333 Graham Boulevard;Montreal;QC;H3R 1885 3L5;Canada 1886 TEL;WORK;MSG:+1-514-733-8500 1887 TEL;WORK;FAX:+1-514-733-8788 1888 EMAIL;INTERNET:andre@cst.ca 1889 END:VCARD 1891 BEGIN:VCARD 1892 FN:Pete O'Leary 1893 ORG:Amplitude 1894 ADR;WORK;POSTAL;PARCEL:;; 1895 TEL;WORK;MSG:+1-415-659-3511 1896 TEL;WORK;FAX:+1-415-659-0006 1897 EMAIL;INTERNET:pete@amplitude.com 1898 END:VCARD 1900 The iCalendar object is a result of the work of the Internet 1901 Engineering Task Force Calendaring and scheduling Working Group. The 1902 co-chair of that working group is: 1904 BEGIN:VCARD 1905 FN:Pat Egen 1906 ORG:Egen Consulting 1907 ADR;WORK;POSTAL;PARCEL:;;803 Creek Overlook;Chattanooga;TN;37415 1908 TEL;WORK;MSG:+1-423.875.2652 1909 TEL;WORK;FAX:+1-423.875.2017 1910 EMAIL;INTERNET:pregen@engenconsulting.com 1911 END:VCARD 1913 11 Full Copyright Statement 1915 Copyright (C) The Internet Society, January 2, 1999. All Rights 1916 Reserved. 1918 This document and translations of it MAY be copied and furnished to 1920 Mansour/Courtemanche/O'Leary 37 Expires August 1999 1921 others, and derivative works that comment on or otherwise explain it 1922 or assist in its implmentation MAY be prepared, copied, published and 1923 distributed, in whole or in part, without restriction of any kind, 1924 provided that the above copyright notice and this paragraph are 1925 included on all such copies and derivative works. However, this 1926 document itself MAY NOT be modified in any way, such as by removing 1927 the copyright notice or references to the Internet Society or other 1928 Internet organizations, except as needed for the purpose of developing 1929 Internet standards in which case the procedures for copyrights defined 1930 in the Internet Standards process MUST be followed, or as required to 1931 translate it into languages other than English. 1933 The limited permissions granted above are perpetual and will not be 1934 revoked by the Internet Society or its successors or assigns. 1936 This document and the information contained herein is provided on an 1937 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1938 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1939 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 1940 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1941 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.