idnits 2.17.1 draft-ietf-calsch-cip-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-25) 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 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 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 1 longer page, the longest (page 1) being 1044 lines 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. ** There is 1 instance of too long lines in the document, the longest one being 7 characters in excess of 72. ** There are 24 instances of lines with control characters 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 118: '... responsibilities. First, it MUST have...' RFC 2119 keyword, line 120: '...ion). Second, it SHOULD have several u...' RFC 2119 keyword, line 122: '...t to that CIP server. Third, it SHOULD...' RFC 2119 keyword, line 128: '...rtain responsibilities. First, it MUST...' RFC 2119 keyword, line 131: '...it MAY attempt the connection later us...' (21 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 31 has weird spacing: '...tandard mecha...' -- 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 822 (ref. '2') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2052 (ref. '3') (Obsoleted by RFC 2782) Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft: draft-ietf-calsch-cip-00.txt 11/26/96 2 ----------------------------------------------------------------------- 3 Calendaring Interoperability 4 Protocol 6 Status of this Memo 8 This document is an Internet-Draft. Internet-Drafts are working 9 documents of the Internet Engineering Task Force (IETF) , its 10 areas, and its working groups. Note that other groups may also 11 distribute working documents as Internet-Drafts. 13 Internet-Drafts are draft documents valid for a maximum of six 14 months and may be updated, replaced, or obsoleted by other 15 documents at any time. It is inappropriate to use Internet-Drafts 16 as reference material or to cite them other than as "work in 17 progress." 19 To learn the current status of any Internet-Draft, please check the 20 "lid-abstracts.txt" listing contained in the Internet-Drafts Shadow 21 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe) , 22 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 23 ftp.isi.edu (US West Coast). 25 This draft expires 6 months from the date indicated in the upper 26 right corner of this page. 28 Abstract 30 The Calendaring Interoperability Protocol (CIP) provides a 31 standard mechanism for exchanging events and other 32 information between scheduling systems. This allows users to 33 schedule meetings with anyone else, no matter what scheduling 34 software they use. 36 CIP is one of three standards under development by the 37 Calendaring and Scheduling Working Group of the IETF. The 38 other two are the Core Object Specification (COS), a standard 39 data format for representing scheduled events, and the 40 Calendaring Access Protocol (CAP), a standard mechanism that 41 scheduling user agents may use to access user calendars 42 (analogous to POP). 44 Table of Contents 46 Status of this Memo 1 47 Abstract 1 48 Table of Contents 1 49 1.0 Protocol Overview 2 50 1.1 Design Goals 3 51 ----------------------------------------------------------------------- 52 Page: 1 54 Internet-Draft: draft-ietf-calsch-cip-00.txt 11/26/96 55 ----------------------------------------------------------------------- 56 1.2 Terminology 4 57 1.3 Event Object Format 4 58 1.4 Commands and Responses 5 59 1.5 Server Identifiers 7 60 1.6 User Identifiers 7 61 1.7 Event Identifiers 8 62 1.8 Event Versioning 8 63 1.9 Contacting Servers 9 64 2.0 Protocol Commands 9 65 2.1 AUTHENTICATE Command 9 66 2.2 SENDEVENT Command 10 67 2.3 RSVP Command 11 68 2.4 FREEBUSY Command 12 69 3.0 Example Session 13 70 4.0 Formal Grammar 16 71 5.0 Security Considerations 16 72 6.0 References 16 73 7.0 Open Issues 17 74 8.0 Author's Addresses 18 76 1.0 Protocol Overview 78 The Calendaring Interoperability Protocol (CIP) provides a 79 standard mechanism for exchanging events and other 80 information between scheduling systems. This allows users to 81 schedule meetings with anyone else, no matter what scheduling 82 software they use. 84 There are many kinds of scheduling systems, ranging from a 85 centralized database serving thousands of users to a single-user 86 Personal Information Manager (PIM) or a handheld device. All 87 of these systems should be able to use CIP successfully. 89 Here is a simple example with many details omitted: 91 Tom Jones of Jumbo Corp. wants to invite Mary Weaver of Tiny, 92 Inc. to a meeting. He uses his scheduling software to create a 93 meeting and adds Mary to the list of guests, using her CIP user id 94 (probably the same as her email address, say mary@tiny.com). 95 Tom's scheduling system opens a session with the CIP server for 96 tiny.com and sends the event. Mary's scheduling system delivers 97 the event to her and she accepts the invitation. Mary's scheduling 98 system contacts the CIP server for jumbo.com and sends a 99 response indicating that she plans to attend. Tom's scheduling 100 system communicates this to him. 102 Several key concepts are illustrated by this example. CIP is used 103 only for interoperability between the scheduling systems, not for 104 ----------------------------------------------------------------------- 105 Page: 2 107 Internet-Draft: draft-ietf-calsch-cip-00.txt 11/26/96 108 ----------------------------------------------------------------------- 109 calendar access when Tom or Mary are accessing their personal 110 calendars. Each scheduling system functions both as a client and 111 as a server. As a server, it has a server id that is a domain name 112 (but not necessarily the DNS host name of the server). Each user 113 has a user id that is often the same as their email address. Users 114 send and receive invitations with their normal scheduling 115 software. Their scheduling system is responsible for 116 communicating with other scheduling systems. 118 Each CIP server has certain responsibilities. First, it MUST have 119 a unique server identifier (described in more detail in a later 120 section). Second, it SHOULD have several user identifiers that 121 include that server identifier. All CIP traffic destined for those 122 user identifiers will be sent to that CIP server. Third, it SHOULD 123 be available to CIP traffic most of the time. CIP depends on 124 establishing a TCP connection to the CIP server. If this 125 connection cannot be made, CIP traffic will be halted. Fourth, it 126 SHOULD have several. 128 Each CIP client has certain responsibilities. First, it MUST 129 contact CIP servers and conduct the CIP session according to the 130 protocol described here. Second, if it cannot contact a CIP server, 131 it MAY attempt the connection later using an exponential 132 backoff algorithm. 134 All characters sent as part of the CIP protocol are members of the 135 character set ISO 8859-1. The COS makes provisions for using 136 other character sets for event properties, such as event 137 descriptions, and 138 encoding them so they can be transmitted using ISO 8859-1. 139 Therefore, the only items that are substantially affected by this 140 character set restriction are those that appear outside of the COS: 141 the server 142 identifier and user identifier. 144 1.1 Design Goals 146 The primary goal of CIP is quite simple: to allow people to 147 schedule events with each other without worrying about 148 incompatibilities between their scheduling systems. All other 149 goals are secondary to that one. 151 CIP is designed to be simple. With only four commands and a 152 very simple syntax, it should be easy to implement. Most of the 153 effort will be in parsing and generating the COS format for 154 representing events. 156 CIP is designed to be secure. The AUTHENTICATE command 157 ----------------------------------------------------------------------- 158 Page: 3 160 Internet-Draft: draft-ietf-calsch-cip-00.txt 11/26/96 161 ----------------------------------------------------------------------- 162 allows for mutual authentication between client and server and 163 encryption of the subsequent protocol exchanges. 165 CIP is designed to be international. With the exception of server 166 and user identifiers (which are restricted by older RFCs), all data 167 items are contained within the COS and can therefore be 168 expressed with almost any character set. 170 1.2 Terminology 172 This document uses the following terms: 174 event: An event is a data item that refers to a specific date 175 and/or time. For the purposes of this document, the term 176 event also refers to todos. 177 user: For the purposes of this specification, a user is a 178 person, location, or resource whose calendar is managed by a 179 scheduling system. 180 scheduling system: A scheduling system is a software 181 program that manages the scheduling of events. There are 182 many types of scheduling systems, from a centralized 183 database serving thousands of users to a single-user Personal 184 Information Manager (PIM) or a handheld device. All of 185 them should be able to function as CIP servers or clients. 186 CIP client: A CIP client is a scheduling system using CIP to 187 send commands to a CIP server. 188 CIP server: A CIP server is a scheduling system that accepts 189 commands from CIP clients. 191 1.3 Event Object Format 193 CIP relies on the existence of a text-based representation of 194 calendar information, which is not described in this document. 195 The examples below employ vCalendar, a calendar information 196 format authored by the Versit consortium (see [1]). 198 CIP does depend on certain information being present in the data 199 being transported. Some properties that are defined as "optional" 200 in the specification of vCalendar are mandatory when transported 201 via CIP: 203 ATTENDEE - CIP uses this property to determine the intended 204 recipient of SENDEVENT 205 ATTENDEE; ROLE = OWNER: this property MUST be present 206 so that event recipients can locate the originator before using the 207 RSVP command. The user's address given in the OWNER 208 attendee MUST be the calendar host name that attendees can 209 RSVP to. 210 ----------------------------------------------------------------------- 211 Page: 4 213 Internet-Draft: draft-ietf-calsch-cip-00.txt 11/26/96 214 ----------------------------------------------------------------------- 215 SEQUENCE - CIP uses this property for event versioning, as 216 described below. 217 UID - CIP relies on this property to locate events when an RSVP 218 command is issued The originator of the meeting generates the 219 UID and MUST send it along with the first SENDEVENT 220 command. The UID also MUST be sent along with the RSVP 221 command. 223 1.4 Commands and Responses 225 The CIP session begins when the client initiates a connection 226 with a CIP server on port IANA registered port xxx. The server 227 responds to the client connection with the following statement 228 containing the name of the protocol - "CIP" - a version number 229 and the DNS name of the server: 231 S: OK CIP 1.0 hostname 233 The version number given is comprised of two numeric values 234 delimited by a period ".". The first number given is the "major" 235 revision number and the second is the "minor" revision number. 236 If the client initiating the protocol session receives a major 237 revision number other than what it expects, the client should 238 close the current session immediately. Major revisions of CIP are 239 not guaranteed to be compatible with any other revision. A client 240 which encounters a minor revision number from the server which 241 is lower than that supported by the client may choose to either 242 close the connection or initiate commands defined in the lower- 243 numbered version of CIP only. Higher-numbered minor revisions 244 are not a problem for the client, the server must support all 245 commands and responses defined by the lower revision. 247 The client drives the session by sending commands to the server. 248 All commands are terminated with a carriage return and line feed 249 pair (CRLF). No command is considered complete by the server 250 until the CRLF is received. Certain command require sending 251 additional data after to command itself has been sent. All such 252 commands finish with a plus character "+" as the last character 253 on the line before the CRLF. This convention makes it easy for 254 implementers to determine when additional data is to be 255 received. The server should send a single "+" character on a line 256 followed by CRLF before it returns any data back to the client. 258 Data is sent one line at a time, each line followed by CRLF. The 259 end of the data is marked by a single period character "." on a 260 line followed by a CRLF. If a single period on a line must be sent 261 as part of the data, two periods can be sent in a row. 263 ----------------------------------------------------------------------- 264 Page: 5 266 Internet-Draft: draft-ietf-calsch-cip-00.txt 11/26/96 267 ----------------------------------------------------------------------- 268 The client must wait for the last command issued to complete, as 269 described below, before issuing a new command. 271 There are two types of responses which may be given by the 272 server after the client has initiated a command: informational 273 responses and command completion responses. 275 Informational responses are of the form: 277 "*" information_code information 279 All informational responses begin with "*" as the first character 280 on the line, followed by an information code. The server may 281 send as many informational responses as necessary. The exact 282 content of the informational response depends on the command 283 currently in progress. See the description of the various command 284 below for more information. 286 Command completion responses are of the form: 288 [OK | NO] result_code text_information 290 The first part of the command completion response indicates the 291 overall result of the command: 293 OK - The command completed successfully. 294 NO - The command failed and no action was taken. 296 Note: These result codes are intended to convey the overall 297 results of the command and are the only part of the command 298 completion response which a client must rely on. The remainder 299 of the command completion response is for informational 300 purposes only! 302 The result_code is a three-digit numerical value which gives 303 additional information about why a command completed the way 304 that it did. 306 The text_information part of the response can consist of any 307 information that the server wants to send. This should be a 308 human-readable description of the command result; the client 309 may elect to display this information to the user in some way. 311 Result Codes: 313 000 No additional information given. 314 001 Command was invalid or parameters are bad: given 315 along with NO response 316 ----------------------------------------------------------------------- 317 Page: 6 319 Internet-Draft: draft-ietf-calsch-cip-00.txt 11/26/96 320 ----------------------------------------------------------------------- 321 002 Operation not allowed - access control. 322 003 Command completed partially - see specific command 323 for more details 325 Other result codes are defined below under their respective 326 commands. 328 1.5 Server Identifiers 330 Each CIP server is identified by a server identifier, which is a 331 domain name (as defined by RFC 1034 [4]). This name may be 332 used to contact the CIP server, as described in section 1.9, 333 Contacting Servers. Each server identifier MUST be used by only 334 one server. 336 If a server changes its server identifier, it is a good idea to have a 337 transition period during which both the old and the new server 338 identifiers are supported. Before the old server identifier is 339 retired, all events whose event identifier includes the old server 340 identifier SHOULD be cancelled and sent out with an event 341 identifier that includes the new server identifier. 343 1.6 User Identifiers 345 Each CIP user is identified by a user identifier of the form local- 346 user-id@server-id. Server-id is a server identifier, as described in 347 section 1.4. Local-user-id is a local identifier specific to that 348 server. 350 The syntax for user identifiers is very similar to the email address 351 syntax defined in RFC 822 [2], but somewhat simplified. For 352 many users, their CIP user identifier will be the same as their 353 Internet email address, which will be very convenient. Of course, 354 they are used quite differently. Instead of using SMTP to send 355 email, scheduling systems will use CIP to send and manage 356 events. 358 If a user changes their user identifier (either the local-user-id or 359 the server-id), their old server SHOULD reserve the old local- 360 user-id for a period of time and provide REDIRECT 361 informational responses whenever it receives a SENDEVENT or 362 FREEBUSY command that refers to the old user identifier. This 363 will allow CIP clients to update their databases. 365 CIP does not provide any inherent support for groups. A 366 scheduling system can provide a user identifier that refers to a 367 group, but CIP doesn't provide any special support for it. If 368 scheduling systems do provide such support, they SHOULD 369 ----------------------------------------------------------------------- 370 Page: 7 372 Internet-Draft: draft-ietf-calsch-cip-00.txt 11/26/96 373 ----------------------------------------------------------------------- 374 avoid loops. If a user identifier on their system is mapped to a 375 user identifier on another system, which is mapped back to the 376 original user identifier on their system, a loop is formed. There 377 are more complicated versions, too. 379 1.7 Event Identifiers 381 In order to manage events easily, each event that is sent or 382 referred to with CIP has a unique event identifier of the form 383 local-event-id@server-id. Server-id is the server identifier of the 384 CIP server that owns the event. Local-event-id is a local identifier 385 assigned by that server. 387 Each event sent and referred to with CIP MUST have one and 388 only one event identifier. This event identifier SHOULD NOT 389 change, even if the event changes (including changes to event 390 title, owner, and even event cancellation.). It is permissible for a 391 CIP server to cancel one event and create a new one with a 392 different event identifier. This may be useful if, for instance, an 393 event should now be owned by a different server. As far as CIP is 394 concerned, this is really a different event and all CIP clients will 395 regard it as such. 397 A single event identifier SHOULD NOT be used for different 398 events, even if one event is cancelled and another created. 399 Otherwise, CIP clients may become confused about which event 400 is which. 402 Event identifiers are used in several places. In the SENDEVENT 403 command, they are stored in the UID property within the 404 vCalendar representation of the event. In the RESPOND 405 command, one of the parameters is the event identifier of the 406 event being responded to. 408 1.8 Event Versioning 410 In order to manage multiple versions of events, each CIP server 411 must assign an event version to each event it owns. This version 412 number is a monotonically increasing positive integer, starting at 413 1 when the event is created. Whenever the server changes an 414 event, it increments the event's version. CIP clients and servers 415 SHOULD use the event version to check version compatibility, as 416 described in the descriptions of the SENDEVENT and 417 RESPOND commands. 419 If the version reaches 2^31 (two to the thirty-first power), the 420 event SHOULD be cancelled and a new event created. This 421 avoids problems caused by wraparound. Of course, this should be 422 ----------------------------------------------------------------------- 423 Page: 8 425 Internet-Draft: draft-ietf-calsch-cip-00.txt 11/26/96 426 ----------------------------------------------------------------------- 427 very rare. 429 1.9 Contacting Servers 431 In order to establish a connection with a CIP server, a CIP client 432 must map a server identifier to an IP address. Instead of 433 performing a simple DNS host name resolution, a CIP client 434 MUST use the technique described in RFC 2052 (DNS SRV) [3] 435 to locate a server with service equal to CIP, protocol equal to 436 TCP, and name equal to the server identifier. If no SRV record is 437 found, this technique backs off to a simple DNS host name 438 resolution of the server identifier. Once an IP address has been 439 found, a TCP connection MUST be opened to a port number that 440 will be assigned later by the IANA. This mapping process MUST 441 be followed every time a CIP client tries to connect to a CIP 442 server. 444 The primary advantage of this technique is that it allows server 445 identifiers to be quite simple and allows a user's CIP user 446 identifier to often be the same as their email address. This means 447 the user has one less item to remember and write down on their 448 business cards. 450 2.0 Protocol Commands 452 In the following command descriptions, "C:" indicates a 453 command line initiated by the client. "S:" indicates a response 454 from the server. 456 2.1 AUTHENTICATE Command 458 C: AUTHENTICATE authenticate_code authenticate_data 460 C: AUTHENTICATE LOGIN identity password 462 The AUTHENTICATE command can be used by the protocol 463 client to establish it's identity for purposes of access control. It is 464 not required for a client to login or otherwise authenticate itself 465 in order to initiate commands. Servers should enforce whatever 466 access control policies are appropriate for their application. Note 467 that the use of the term "client" here is not meant to imply that 468 the protocol client is associated with a particular user: the client 469 may, in fact, be a server. 471 The AUTHENTICATE command takes a code as its first 472 parameter which indicates the type of authentication mechanism 473 to use. The simplest AUTHENTICATE code is LOGIN which 474 takes a user name and plain-text password as its parameters 475 ----------------------------------------------------------------------- 476 Page: 9 478 Internet-Draft: draft-ietf-calsch-cip-00.txt 11/26/96 479 ----------------------------------------------------------------------- 480 followed by CRLF. Additional AUTHENTICATE codes are 481 specified in xxx. 483 Responses: 485 Command completion response of OK or NO only. For security 486 purposes, it is not a good idea for the server to return any 487 additional information for a failed login. 489 Example: 491 C: AUTHENTICATE LOGIN fredsbaking.com fromblotz 492 S: OK 000 Login complete. 494 C: AUTHENTICATE LOGIN clearblue.com foobatz 495 S: NO 000 Access denied. 497 2.2 SENDEVENT Command 499 C: SENDEVENT "+" CRLF 500 C: event_information 501 C: "." CRLF 503 The SENDEVENT command is used by the client to pass a new 504 event to the server. The client sends the command, followed by a 505 "+" and CRLF. The client then sends the event data, one line at a 506 time, ending with a single period character on a line. The server 507 then replies with 0 or more informational responses followed by 508 the command completion response. 510 Responses: 512 NOTFOUND - This informational response should be followed 513 by a user name. The given user was not found on the current 514 server and the SENDEVENT request could not be completed. 516 TENTATIVE - This informational response should be followed 517 by a user name. The event has been stored for the given user but 518 they have not yet indicated whether they plan to attend the event. 519 See the RSVP command below for a description of how a user 520 would respond to the event. 522 PERMDENIED - This response is given with a user name when 523 the SENDEVENT failed due to access control restrictions 524 imposed by an attendee. 526 REDIRECT - This informational response informs the client that 527 a user identifier has changed. It only applies to user identifiers 528 ----------------------------------------------------------------------- 529 Page: 10 531 Internet-Draft: draft-ietf-calsch-cip-00.txt 11/26/96 532 ----------------------------------------------------------------------- 533 that are listed as an ATTENDEE in the event and whose server 534 identifier maps to this CIP server. This response is equivalent to 535 the NOTFOUND response, but provides more information. The 536 client SHOULD resend the event to the new user identifier. The 537 client MAY update its database to always use the new user 538 identifier instead of the old. 540 * REDIRECT USER old-id IS NOW new-id CRLF 542 Completion Codes: 544 003 Not all attendees received the event 546 Example: 548 C: SENDEVENT + 549 C: DTSTART: 19961231T2000-0500 550 C: DTEND: 19970101T0600-0500 551 C: DESCRIPTION: New year's eve party in New York. The Big 552 2000! 553 C: ATTENDEE; ROLE=OWNER: Pete O'Leary 554 555 C: ATTENDEE: Bill Clinton 556 C: ATTENDEE: Jen Yip 557 C: SEQUENCE: 1 558 C: UID: 23454321abcdabcd@clearblue.com 559 C: . 560 S: * NOTFOUND 561 S: NO 000 Not all users are present on this server. 563 2.3 RSVP Command 565 C: RSVP "+" CRLF 566 C: event_information 567 C: "." CRLF 569 The RSVP command is used by the client to update the status of 570 an event. The command is normally used by the recipient (via 571 SENDEVENT) of an event to indicate to the event's originator 572 whether the recipient plans to attend the event in question. 574 The client sends the command, followed by a "+" and CRLF. The 575 client then sends the event data, one line at a time, ending with a 576 single period character on a line. The server then replies with 0 577 or more informational responses followed by the command 578 completion response. 580 The client is not required to send all of the information which 581 ----------------------------------------------------------------------- 582 Page: 11 584 Internet-Draft: draft-ietf-calsch-cip-00.txt 11/26/96 585 ----------------------------------------------------------------------- 586 constitutes a full event, only the information to be updated in the 587 original event. The server may choose to ignore any information 588 in the event which cannot be modified by the client, based on 589 access control restrictions. 591 Responses: 593 CONFIRMED - Can be sent by the server to indicate that other 594 attendees have confirmed the meeting it was last updated or 595 received by the attendee performing the RSVP. 597 REDIRECT - This informational response informs the client that 598 an event identifier has changed. It only applies to the event id 599 listed in the RSVP command. This response is equivalent to the 600 NOTFOUND response, but provides more information. The 601 client MAY resend the RSVP to the new event identifier. The 602 client MAY update its database to always use the new event 603 identifier instead of the old. 605 * REDIRECT EVENT old-id IS NOW new-id CRLF 607 Example: 609 C: RSVP + 610 C: DTSTART: 19961231T2000-0500 611 C: DTEND: 19970101T0600-0500 612 C: DESCRIPTION: New year's eve party in New York. The Big 613 2000!> 614 C: ATTENDEE; STATUS=ACCEPTED: Jen Yip 615 616 C: . 617 S: OK 000 RSVP accepted. 619 2.4 FREEBUSY Command 621 C: FREEBUSY "+" CRLF 622 C: CRLF 623 C: "." CRLF 624 S: "+" CRLF 625 S: CRLF 626 S: "." CRLF 628 The FREEBUSY command requests that the server gather free or 629 busy time information according to the request information 630 submitted by the client. The client sends the command, followed 631 by a "+" and CRLF. The client then sends the request data, one 632 line at a time, ending with a single period character on a line. 633 The server then replies with the response data, then 0 or more 634 ----------------------------------------------------------------------- 635 Page: 12 637 Internet-Draft: draft-ietf-calsch-cip-00.txt 11/26/96 638 ----------------------------------------------------------------------- 639 informational responses followed by the command completion 640 response. The server may choose to send informational responses 641 and a completion response only if the free/busy request cannot be 642 completed for any reason. The client can distinguish between the 643 different responses based on the first character on the line 644 received: "+" for data, "*" for informational responses. 646 Response: 648 NOTFOUND - This informational response should be followed 649 by a user name. The given user was not found on the current 650 server and no free/busy information for the user was returned. 652 REDIRECT - This informational response informs the client that 653 a user identifier has changed. It only applies to user identifiers 654 that are listed in the free_busy_request and whose server 655 identifier maps to this CIP server. This response is equivalent to 656 the NOTFOUND response, but provides more information. The 657 client MAY resend the FREEBUSY request to the new user 658 identifier. The client MAY update its database to always use the 659 new user identifier instead of the old. 661 * REDIRECT USER old-id IS NOW new-id CRLF 663 Example: 665 C: FREEBUSY + 666 S: + 667 C: fill in example here 669 3.0 Example Session 671 Scenario: 672 A group meeting is setup in C&S system A that contains one 673 attendee, Bob, in system B. System A is represented by a CIP 674 server at a.com and system B is represented by a CIP server at 675 b.com. 677 CIP server a.com does a DNS lookup to find the IP address of 678 b.com and opens a TCP connection on port CIP_PORT 680 S: OK CIP 1.0 b.com 681 C: AUTHENTICATE LOGIN a.com PASSWORD_A 682 S: OK 000 LOGIN COMPLETED 683 C: SENDEVENT+ 684 C: UID: unique identifier for event 685 C: SEQUENCE: 1 686 C: DTSTART: start date and time 687 ----------------------------------------------------------------------- 688 Page: 13 690 Internet-Draft: draft-ietf-calsch-cip-00.txt 11/26/96 691 ----------------------------------------------------------------------- 692 C: DTEND: end date and time 693 C: DESCRIPTION: Project X review meeting 694 C: ATTENDEE; ROLE=OWNER: Pete O'Leary 695 696 C: ATTENDEE: Alex SystemA 697 C: ATTENDEE: Bob SystemB 698 C: . 699 S: OK 000 SENDEVENT COMPLETED 701 CSIP server a.com closes connection 703 Scenario: 704 Bob on system B accepts the meeting invitation. 706 CIP server b.com does a DNS lookup to find the IP address of 707 a.com and opens a TCP connection on port CIP_PORT 709 S: OK CIP 1.0 a.com 710 C: AUTHENTICATE LOGIN b.com PASSWORD_B 711 S: OK 000 LOGIN COMPLETED 712 C: RSVP+ 713 C: UID unique identifier of event 714 C: SEQUENCE: 1 715 C: RESPONSE-SEQUENCE: 1 716 C: ATTENDEE: Bob SystemB 717 C: STATUS: CONFIRMED 718 C: . 719 S: OK 000 RSVP COMPLETED 721 CIP server b.com closes connection 723 The scenario is a simple meeting between two people. Bill 724 schedules it from 725 his PC client. To test out some error handling, it fails the first 726 time 727 under anonymous authentication. 729 Client (bill's PC): 731 Connects to abc.com 733 C: SENDEVENT + 734 C: CATEGORIES: Meeting 735 C: DTSTART: 19961126T1530-0500 736 C: DTEND: 19961126T1630-0500 737 C: SUBJECT: Important Meeting 738 C: DESCRIPTION: We need to talk about important stuff. 739 C: CLASS: Private 740 ----------------------------------------------------------------------- 741 Page: 14 743 Internet-Draft: draft-ietf-calsch-cip-00.txt 11/26/96 744 ----------------------------------------------------------------------- 745 C: UID: 0289AF8G7DD@abc.com 746 C: SEQUENCE: 1 747 C: 748 ATTENDEE;ROLE=OWNER;STATUS=CONFIRMED:bill@ab 749 c.com 750 C: 751 ATTENDEE;ROLE=ATTENDEE;STATUS=TENTATIVE:mary 752 @xyz.com 753 C: . 754 S: * PERMDENIED bill@abc.com 755 S: * NOTFOUND mary@xyz.com 756 S: NO 000 Quite a bummer, this failed altogether. 758 C: AUTHENTICATE LOGIN bill aardvark 759 S: OK 000 760 C: SENDEVENT + 761 C: CATEGORIES: Meeting 762 C: DTSTART: 19961126T1530-0500 763 C: DTEND: 19961126T1630-0500 764 C: SUBJECT: Important Meeting 765 C: DESCRIPTION: We need to talk about important stuff. 766 C: CLASS: Private 767 C: UID: 0289AF8G7DD@abc.com 768 C: SEQUENCE: 1 769 C: 770 ATTENDEE;ROLE=OWNER;STATUS=CONFIRMED:bill@ab 771 c.com 772 C: 773 ATTENDEE;ROLE=ATTENDEE;STATUS=TENTATIVE:mary 774 @xyz.com 775 C: . 776 S: * NOTFOUND mary@xyz.com 777 S: OK 000 Things came out better this time 779 Disconnect from abc.com 780 Connect to xyz.com 782 C: SENDEVENT + 783 C: UID: 0289AF8G7DD@abc.com 784 C: SEQUENCE: 1 785 C: CATEGORIES: Meeting 786 C: DTSTART: 19961126T1530-0500 787 C: DTEND: 19961126T1630-0500 788 C: SUBJECT: Important Meeting 789 C: DESCRIPTION: We need to talk about important stuff. 790 C: CLASS: Private 791 C: 792 ATTENDEE;ROLE=OWNER;STATUS=CONFIRMED:bill@ab 793 ----------------------------------------------------------------------- 794 Page: 15 796 Internet-Draft: draft-ietf-calsch-cip-00.txt 11/26/96 797 ----------------------------------------------------------------------- 798 c.com 799 C: 800 ATTENDEE;ROLE=ATTENDEE;STATUS=TENTATIVE:mary 801 @xyz.com 802 C: . 803 S: * TENTATIVE mary@xyz.com 804 S: * NOTFOUND bill@abc.com 805 S: OK 000 Stored something anyway. 807 Now, from Mary's PC. Somehow, she's seen the event... 809 Mary connects to abc.com. 811 C: RSVP + 812 C: UID: 0289AF8G7DD@abc.com 813 C: SEQUENCE: 1 814 C: 815 ATTENDEE;ROLE=ATTENDEE;STATUS=CONFIRMED:mar 816 y@xyz.com 817 S: * CONFIRMED mary@xyz.com 818 S: * CONFIRMED bill@abc.com 819 S: OK 000 Stored all we could. 821 Mary disconnects. Note that this did not require authentication. 823 4.0 Formal Grammar 825 Insert lots of BNF here. 827 5.0 Security Considerations 829 CIP protocol transactions, including event data, are sent in the 830 clear over the network unless encryption is negotiated using the 831 AUTHENTICATE command. 833 A server response for a command that fails due to insufficient 834 permissions should not detail why the permissions are 835 insufficient. 837 Additional security considerations are discussed in the section 838 discussing the AUTHENTICATE command. 840 The LOGIN authentication mechanism described in this 841 document sends a plaintext password. In the absence of 842 transport-level encryption, this creates to possibility that the 843 password can be intercepted enroute. 845 6.0 References 846 ----------------------------------------------------------------------- 847 Page: 16 849 Internet-Draft: draft-ietf-calsch-cip-00.txt 11/26/96 850 ----------------------------------------------------------------------- 852 [1] versit Consortium, "Electronic Calendaring and Scheduling 853 (vCalendar) Specification", 03/29/1996, http://www.versit.com/ 855 [2] D. Crocker, "Standard for the format of ARPA Internet text 856 messages", 08/13/1982, http://ds.internic.net/rfc/rfc822.txt 858 [3] A. Gulbrandsen, P. Vixie, "A DNS RR for specifying the 859 location of services (DNS SRV)", 10/31/1996, 860 http://ds.internic.net/rfc/rfc2052.txt 862 [4] P. Mockapetris, "Domain names - concepts and facilities", 863 11/01/1987, http://ds.internic.net/rfc/rfc1034.txt 865 7.0 Open Issues 867 Should have a section on Requirements that defines the meanings 868 of MUST, MUST NOT, SHOULD, and SHOULD NOT. 870 Should move description of C: and S: to a section early on. At the 871 moment, they appear before they're explained. 873 Should talk about gateways. 875 Need to make sure that AUTHENTICATE allows both client and 876 server to establish the identity of the other. 878 Should give more info about loops and how to avoid them. 880 Should update numeric result codes so they're more consistent. 882 Can one event go by several ids? 884 Should use references throughout. 886 If we add the SELECT SERVER command, add a comment to 887 the Server Identifiers section that tells people to use it and says 888 they should provides redirects there when a server identifier 889 changes. 891 Need to coordinate with e-mail (MIME) based calendar 892 interoperability protocol. Need to coordinate with Common 893 Object Specification. 895 Should talk about email delivery as an alternative transmission 896 mode. 898 Should provide some examples of how a couple of different kinds 899 ----------------------------------------------------------------------- 900 Page: 17 902 Internet-Draft: draft-ietf-calsch-cip-00.txt 11/26/96 903 ----------------------------------------------------------------------- 904 of scheduling systems would implement this (perhaps in a 905 separate section). Maybe we should just implement it to provide a 906 good example! 908 Should say that each event is owned by a single server. 910 8.0 Author's Addresses 912 Anik Ganguly 913 Campbell Services Inc. 914 anik@ontime.com 915 (810) 559-5955 x4646 917 Steve Hanna 918 On Technology Corporation 919 hanna@world.std.com 920 (617) 692-3153 922 Peter O'Leary 923 Clear Blue Network Systems, Inc. 924 poleary@clearblue.com 925 (415) 323-3380 927 Bill Spencer 928 Phase2 Software Corporation 929 bill@p2software.com 930 (508) 481-8496 x41 932 ------------------------------------------------------------------------------- 933 Page: 18