idnits 2.17.1 draft-mrose-simple-exchange-01.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 10 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 697 has weird spacing: '...ication htt...' == Line 699 has weird spacing: '...tegrity htt...' == Line 701 has weird spacing: '...privacy htt...' == Line 704 has weird spacing: '... all htt...' -- 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 (December 2001) is 8166 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) == Outdated reference: A later version (-03) exists of draft-ietf-impp-cpim-02 -- Possible downref: Normative reference to a draft: ref. '1' ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '2') -- Possible downref: Normative reference to a draft: ref. '3' ** Obsolete normative reference: RFC 2543 (ref. '4') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) ** Obsolete normative reference: RFC 2327 (ref. '6') (Obsoleted by RFC 4566) == Outdated reference: A later version (-07) exists of draft-ietf-midcom-framework-06 ** Downref: Normative reference to an Informational draft: draft-ietf-midcom-framework (ref. '7') == Outdated reference: A later version (-08) exists of draft-ietf-impp-cpim-msgfmt-04 ** Obsolete normative reference: RFC 2396 (ref. '9') (Obsoleted by RFC 3986) Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Rose 3 Internet-Draft Dover Beach Consulting, Inc. 4 Expires: June 1, 2002 December 2001 6 IM Simple Exchange (IMSX) 7 draft-mrose-simple-exchange-01 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on June 1, 2002. 32 Copyright Notice 34 Copyright (C) The Internet Society (2001). All Rights Reserved. 36 Abstract 38 The Common Presence and Instant Messaging profile (CPIM) is a set of 39 syntax and semantics for instant messaging (IM) and online presence 40 services, independent of the underlying transfer infrastructure. The 41 Session Initiation Protocol (SIP) negotiates session information for 42 media streams. This memo defines a BEEP profile, IMSX, for 43 exchanging CPIM messages after SIP has performed signalling. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. IM Simple Exchange . . . . . . . . . . . . . . . . . . . . . 4 49 2.1 The Session Model . . . . . . . . . . . . . . . . . . . . . 4 50 2.2 SDP Announcements for IMSX . . . . . . . . . . . . . . . . . 6 51 2.3 SIP Interactions for IMSX . . . . . . . . . . . . . . . . . 7 52 2.4 BEEP Interactions for IMSX . . . . . . . . . . . . . . . . . 7 53 2.5 Putting It All Together . . . . . . . . . . . . . . . . . . 8 54 3. The IMSX Profile for BEEP . . . . . . . . . . . . . . . . . 13 55 3.1 Use of XML and MIME . . . . . . . . . . . . . . . . . . . . 13 56 3.2 Profile Identification and Initialization . . . . . . . . . 14 57 3.3 Message Syntax . . . . . . . . . . . . . . . . . . . . . . . 15 58 3.4 Message Semantics . . . . . . . . . . . . . . . . . . . . . 15 59 3.4.1 The Message Element . . . . . . . . . . . . . . . . . . . . 15 60 3.4.2 The Response Element . . . . . . . . . . . . . . . . . . . . 16 61 4. Initial Registrations . . . . . . . . . . . . . . . . . . . 17 62 4.1 Registration: The IMSX Profile . . . . . . . . . . . . . . . 17 63 4.2 Registration: The System (Well-Known) TCP port number for 64 IMSX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 65 4.3 Registration: The IMSX/TCP "proto" for SDP . . . . . . . . . 18 66 4.4 Registration: The tuning "att-field" for SDP . . . . . . . . 18 67 5. The IMSX DTD . . . . . . . . . . . . . . . . . . . . . . . . 19 68 6. Security Considerations . . . . . . . . . . . . . . . . . . 21 69 References . . . . . . . . . . . . . . . . . . . . . . . . . 22 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . 23 71 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 72 B. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25 73 C. Revision History . . . . . . . . . . . . . . . . . . . . . . 26 74 C.1 Changes from draft-mrose-simple-exchange-00 . . . . . . . . 26 75 Full Copyright Statement . . . . . . . . . . . . . . . . . . 27 77 1. Introduction 79 The Common Presence and Instant Messaging profile [1] (CPIM) is a set 80 of syntax and semantics for instant messaging (IM) and online 81 presence services, independent of the underlying transfer 82 infrastructure. CPIM is consistent with the requirements specified 83 in RFC2779 [2], using a minimalist approach to allow the 84 interoperation of a wide range of IM and presence systems. 86 To support a "paging" model for IM, SIMPLE [3] defines an extension 87 to the Session Initiation Protocol [4] (SIP). SIP negotiates session 88 information for media streams. Using the SIMPLE extension, the IM 89 content is piggyback'd in the SIP traffic, thereby eliminating the 90 need for a separate stream for IM traffic. 92 A "session" model for IM is also possible, wherein SIP performs the 93 signalling necessary to negotiate the establishment of a media 94 stream, which is realized by a second protocol. This memo defines an 95 "IM session" protocol for that purpose, termed the IM Simple Exchange 96 (IMSX). IMSX is realized as a BEEP profile [5]. 98 This memo is written with the expectation that the reader is familiar 99 with the concepts presented in the CPIM, SIP, and BEEP 100 specifications. 102 2. IM Simple Exchange 104 2.1 The Session Model 106 In the "session" model, an IM application determines that it wishes 107 to communicate with another IM application. These applications, 108 termed the initiating and responding applications (respectively), are 109 conceptually identified using the IM URI, as specified in Section 5.1 110 of [1]. 112 The initiating application determines that it will use IMSX to 113 communicate with the responding application, so it uses the SIP URI 114 for this purpose. For example, if the IM application uses IMSX to 115 communicate with an IM application identified as 116 "im:barney@rubble.com" , the URI "sip:barney@rubble.com" is utilized 117 for this purpose. 119 The initiating application ensures that it is running a BEEP entity 120 that implements the IMSX profile, and determines the transport 121 information associated with the BEEP entity (typically IP address and 122 TCP port number). Then it constructs an announcement using the 123 Session Description Protocol [6] (SDP), and sends the announcement in 124 a SIP INVITE. The initiating application then waits for a response. 126 Ultimately, the responding application receives the invitation. The 127 responding application determines if it wishes to communicate with 128 the initiating application. If the invitation is declined, this is 129 indicated a failure response code (from the 4xx, 5xx or 6xx series) 130 and no further actions are taken by the responding application. 132 Otherwise, the responding application ensures that it is running a 133 BEEP entity that implements the IMSX profile, determines the 134 transport information associated with the BEEP entity (typically IP 135 address and TCP port number), and then sends its own announcement 136 with a 200 response code. 138 Ultimately, the initiating application receives the response and 139 acknowledges it with a SIP ACK message. If the response indicates 140 failure, no further actions are taken by the initiating application. 142 Otherwise, the initiating application activates its BEEP entity, and, 143 using the transport information in the response, establishes a BEEP 144 session. If successful, the initiating application tunes the session 145 as appropriate, and starts the IMSX profile. 147 As with any model based on dynamic rendezvous, it is critically 148 important that each application faithfully record the appropriate 149 transport information in the corresponding SDP announcement. 151 Note that with the introduction of middleboxes [7], such as firewalls 152 and network address translators, it may be necessary to rewrite the 153 transport information in order to account for administratively- 154 mandated media gateways or address translation. Accordingly, SIP 155 user agents are responsible for either directly rewriting the 156 transport information, or, sending the SDP announcement through the 157 appropriate intermediaries that will transparently rewrite the 158 transport information. In a phrase, "res ipsa loquitur". 160 2.2 SDP Announcements for IMSX 162 Consider this SDP announcement: 164 v=0 165 o=fred 2890844526 0 IN IP4 1.2.3.4 166 s=example imsx session 167 c=IN IP4 1.2.3.4 168 t=0 0 169 m=message 1024 IMSX/TCP cpim 170 a=tuning:privacy 172 Readers familiar with SDP will note only two new parameters, the use 173 of "IMSX/TCP" as a media protocol, and the use of "tuning" as an 174 attribute. 176 For readers less familiar with SDP, let's examine all the information 177 conveyed by this announcement: 179 v=0 => The announcement conforms to version "0" of SDP. 181 o=fred => The originator of the session. 183 o= ... 2890844526 ... IN IP4 1.2.3.4 => The unique identification 184 of the session. 186 o= ... 0 ... => The instance-identifier for the session. 188 s=example imsx session => The textual name of the session. 190 c=IN IP4 1.2.3.4 / m= ... 1024 .../TCP => The transport information 191 associated with the application's BEEP entity. 193 t=0 0 => The (unbounded) start and stop times of the session. 195 m=message ... cpim => The media type being advertised (in this case 196 "message/cpim" [8]). 198 m=message ... IMSX/TCP ... => The protocol used to realize the 199 media stream (cf., Section 4.3). 201 a=tuning:privacy => The BEEP session must be tuned for privacy before 202 starting the IMSX profile (cf., Section 4.4). 204 2.3 SIP Interactions for IMSX 206 The mechanisms defined in [4] are used directly, no changes to the 207 SIP interaction model is required for IMSX. 209 2.4 BEEP Interactions for IMSX 211 Although the SDP announcement indicates what the desired tuning for 212 the BEEP session, the "greetings" exchanged by the BEEP peers 213 indicate which tuning profiles are available: 215 a=tuning:privacy: If tuning for privacy is requested, then the 216 initiating application examines the profiles advertised in the 217 responding application's greeting to see which is most 218 appropriate. This may be either: 220 * a transport security profile; or, 222 * a user authentication profile that also supports transport 223 privacy. 225 a=tuning:integrity: If tuning for message integrity is requested, 226 then the initiating application examines the profiles advertised 227 in the responding application's greeting to see which is most 228 appropriate, i.e., a user authentication profile that also 229 supports message integrity. 231 a=tuning:authentication: If tuning for user authentication is 232 requested, then the initiating application examines the profiles 233 advertised in the responding application's greeting to see which 234 is most appropriate. 236 a=tuning:all: If tuning for user authentication, message integrity, 237 and privacy is requested, then the initiating application examines 238 the profiles advertised in the responding application's greeting 239 to see which are most appropriate. These may be either: 241 * a transport security profile supporting bi-directional 242 certification; 244 * a user authentication profile that also supports transport 245 privacy; or, 247 * a transport security profile followed by a user authentication 248 profile. 250 2.5 Putting It All Together 252 In the examples which follow, the following notation is used: "I" 253 refers to the BEEP peer that initiates a connection, whilst "L" 254 refers to the BEEP peer that listens for connections; similarly, "C" 255 refers to the BEEP peer that begins an exchange, whilst "S" refers to 256 the BEEP peer that responds. 258 The IM application known as "im:fred@example.com" determines that it 259 wishes to communicate with the IM application known as 260 "im:barney@example.com". 262 The initiating application ensures that it is running a BEEP entity 263 that implements the IMSX profile, and determines that its BEEP entity 264 is using IP address "1.2.3.4" and TCP port "1024". It then sends a 265 session invitation to the "sip.rubble.com" proxy. 267 The invitation looks something like this: 269 INVITE sip:barney@rubble.com SIP/2.0 270 Via: SIP/2.0/UDP 1.2.3.4 271 From: Fred ;tag=5567 272 To: Barney 273 Call-ID: 283e0@1.2.3.4 274 CSeq: 98770 INVITE 275 Content-Type: application/sdp 276 Content-Length: 166 278 v=0 279 o=fred 2890844526 0 IN IP4 1.2.3.4 280 s=example imsx session 281 c=IN IP4 1.2.3.4 282 t=0 0 283 m=message 1024 IMSX/TCP cpim 284 a=tuning:none 286 The initiating application then waits for a response. 288 The "sip.rubble.com" proxy forwards the session invitation to the 289 responding application. The responding application ensures that it 290 is running a BEEP entity that implements the IMSX profile, and 291 determines that its BEEP entity is using IP address "5.6.7.8" and TCP 292 port "65535". It then sends its response, which looks something like 293 this, back to the SIP proxy: 295 SIP/2.0 200 OK 296 Via: SIP/2.0/UDP sip.rubble.com 297 Via: SIP/2.0/UDP 1.2.3.4 298 From: Fred ;tag=5567 299 To: Barney ;tag=998a87 300 Call-ID: 283e0@1.2.3.4 301 CSeq: 98770 INVITE 302 Content-Type: application/sdp 303 Content-Length: 166 305 v=0 306 o=fred 2890844526 0 IN IP4 5.6.7.8 307 s=example imsx session 308 c=IN IP4 5.6.7.8 309 t=0 0 310 m=message 65535 IMSX/TCP cpim 311 a=tuning:privacy 313 The responding application then waits for an incoming BEEP session. 315 Ultimately, the initiating application receives the response to the 316 session invitation. The initiating application acknowledges the 317 response, and then establishes a BEEP session using TCP from port 318 "1024" on IP address "1.2.3.4" to port "65535" on IP address 319 "5.6.7.8". 321 The BEEP peers begin with the traditional exchange of greetings (in 322 resplendent native costume): 324 L: 325 I: 326 L: RPY 0 0 . 0 285 327 L: Content-Type: application/beep+xml 328 L: 329 L: 330 L: 331 L: 332 L: 333 L: 334 L: 335 L: END 336 I: RPY 0 0 . 0 52 337 I: Content-Type: application/beep+xml 338 I: 339 I: 340 I: END 342 Because the responding application's response indicated that tuning 343 for privacy is necessary, the initiating application starts a 344 transport security profile: 346 I: MSG 0 1 . 52 158 347 I: Content-Type: application/beep+xml 348 I: 349 I: 350 I: 351 I: ]]> 352 I: 353 I: 354 I: END 355 L: RPY 0 1 . 285 121 356 L: Content-Type: application/beep+xml 357 L: 358 L: 359 L: ]]> 360 L: 361 L: END 363 ... successful transport security negotiation ... 365 L: RPY 0 0 . 0 238 366 L: Content-Type: application/beep+xml 367 L: 368 L: 369 L: 370 L: 371 L: 372 L: 373 L: END 374 I: RPY 0 0 . 0 52 375 I: Content-Type: application/beep+xml 376 I: 377 I: 378 I: END 380 With the session tuned, the initiating application starts the IMSX 381 profile for BEEP: 383 I: MSG 0 1 . 52 176 384 I: Content-Type: application/beep+xml 385 I: 386 I: 387 I: 388 I: 389 I: END 390 L: RPY 0 1 . 238 138 391 L: Content-Type: application/beep+xml 392 L: 393 L: 394 L: END 396 3. The IMSX Profile for BEEP 398 Section 4.1 contains the BEEP profile registration for IMSX. 400 3.1 Use of XML and MIME 402 Each BEEP payload exchanged via IMSX consists of an XML document and 403 possibly an arbitrary MIME content. 405 If only an XML document is sent in the BEEP payload, then the mapping 406 to a BEEP payload is straight-forward, e.g., 408 S: RPY 1 0 . 0 81 409 S: Content-Type: application/beep+xml 410 S: 411 S: 412 S: END 414 Otherwise, if an arbitrary MIME content is present, it is indicated 415 by a URI-reference [9] in the XML control document. The URI- 416 reference may contain an absolute-URI (and possibly a fragment- 417 identifier), or it may be a relative-URI consisting only of a 418 fragment-identifier. Arbitrary MIME content is included in the BEEP 419 payload by using a "multipart/related" [10], identified using a "cid" 420 URL [11], and the XML control document occurs as the start of the 421 "multipart/related", e.g., 423 C: MSG 1 0 . 0 1234 424 C: Content-Type: multipart/related; boundary='boundary'; 425 C: start='<1@example.com>'; 426 C: type='application/beep+xml' 427 C: 428 C: --boundary 429 C: Content-Type: application/beep+xml 430 C: Content-ID: <1@example.com> 431 C: 432 C: 435 C: --boundary 436 C: Content-Type: message/cpim 437 C: Content-Transfer-Encoding: binary 438 C: Content-ID: <2@example.com> 439 C: 440 C: ... 441 C: --boundary-- 442 C: END 444 Because BEEP provides an 8bit-wide path, a "transformative" Content- 445 Transfer-Encoding (e.g., "base64" or "quoted-printable") should not 446 be used. Further, note that MIME [12] requires that the value of the 447 "Content-ID" header be globally unique. However, the value of the 448 "Content-ID" header is referenced only from within the "multipart/ 449 related" itself (i.e., from the multipart's "start" attribute, or 450 from a "cid" URL contained within the multipart). 452 If the arbitrary MIME content is itself an XML document, it may be 453 contained within the control document directly as a "data-content" 454 element, and identified using a URI-reference consisting of only a 455 fragment-identifier, e.g., 457 C: MSG 1 0 . 0 1234 458 C: Content-Type: application/beep+xml 459 C: 460 C: 463 C: 464 C: ... 465 C: 466 C: 467 C: END 469 3.2 Profile Identification and Initialization 471 The IMSX is identified as: 473 http://iana.org/beep/transient/simple/imsx 475 in the BEEP "profile" element during channel creation. 477 No elements are required to be exchanged during channel creation; 478 however, the initiator may choose to piggyback its first operation, 479 e.g., 481 482 483 ... ]]> 484 485 487 Note that Section 2.3.1.2 of [5] limits the amount of piggyback'd 488 data to 4K octets. 490 3.3 Message Syntax 492 Sections 6 and 7 of [1] define the abstract syntax for CPIM 493 messaging. Accordingly, Section 5 defines the IMSX payloads that are 494 CPIM-conformant. 496 3.4 Message Semantics 498 Section 2.4 of [1] defines the abstract semantics for the 499 communications between an application and the IM service. In 500 contrast, IMSX is concerned with the semantics for the communications 501 between two IM applications. Accordingly, the remainder of this 502 section, while similar in nature to CPIM's behavior, deals solely 503 with IM exchanges between end-users. 505 3.4.1 The Message Element 507 The "message" element has a "source" attribute, a "destination" 508 attribute, a "content" attribute, and, optionally, a "data-content" 509 element: 511 o the "source" attribute refers to the application sending the 512 message, and contains an IM URI; 514 o the "destination" attribute refers to the application receiving 515 the message, and also contains an IM URI; and, 517 o the "content" attribute is a URI-reference that specifies the 518 contents of the data (cf., Section 3.1). 520 Note that the "message" element does not contain SIP URIs -- the 521 messages exchanged are independent of the fact that SIP is used to 522 negotiate the establishment of an IMSX media stream. 524 When an application receives the "message" element: 526 1. It verifies that it corresponds to the identity specified in the 527 "destination" attribute, if not, it returns a "response" element 528 with the "status" attribute set to "failure", and performs no 529 further processing for that element. 531 2. Otherwise, it returns a "response" element with the "status" 532 attribute set to "success", and performs any further processing 533 in an application-specific manner. 535 3.4.2 The Response Element 537 The "response" element has a "status" attribute, an optional 538 "xml:lang" attribute, and may contain arbitrary textual content: 540 o the "status" element is either "success", "failure", or 541 "indeterminant"; and, 543 o the "xml:lang" attribute, if present, specifies the language that 544 the element's content is written in; and, 546 o the textual content is a diagnostic (possibly multiline) which is 547 meaningful to implementers, perhaps administrators, and possibly 548 even users. 550 4. Initial Registrations 552 4.1 Registration: The IMSX Profile 554 Profile Identification: http://iana.org/beep/transient/simple/imsx 556 Messages exchanged during Channel Creation: message, response 558 Messages starting one-to-one exchanges: message 560 Messages in positive replies: response 562 Messages in negative replies: none 564 Messages in one-to-many exchanges: none 566 Message Syntax: cf., Section 5 568 Message Semantics: cf., Section 3.4 570 Contact Information: cf., the "Authors' Addresses" section of this 571 memo 573 4.2 Registration: The System (Well-Known) TCP port number for IMSX 575 Protocol Number: TCP 577 Message Formats, Types, Opcodes, and Sequences: Section 5 579 Functions: Section 3.4 581 Use of Broadcast/Multicast: none 583 Proposed Name: IM Simple Exchange 585 Short name: imsx 587 Contact Information: cf., the "Authors' Addresses" section of this 588 memo 590 4.3 Registration: The IMSX/TCP "proto" for SDP 592 SDP Parameter Type: proto 594 Registered Name: IMSX/TCP 596 Long-Form Name: The IMSX profile for BEEP running over TCP 598 Description: cf., this memo 600 Contact Information: cf., the "Authors' Addresses" section of this 601 memo 603 4.4 Registration: The tuning "att-field" for SDP 605 SDP Parameter Type: att-field 607 Registered Name: tuning 609 Long-Form Name: Tuning parameters for media streams implemented over 610 BEEP 612 Type of Attribute: Media level 614 Possible Values of Attribute: "none", "authentication", "integrity", 615 "privacy", or "all". 617 Description: cf., Section 2.4 619 Contact Information: cf., the "Authors' Addresses" section of this 620 memo 622 5. The IMSX DTD 624 633 637 638 %IMCOMMON; 640 648 649 651 654 655 660 662 663 666 667 672 6. Security Considerations 674 Consult [1]'s Section 4 for a discussion of CPIM-specific security 675 issues. In particular, note that If authentication or 676 confidentiality of individial instant messages is desired, the 677 "message/cpim" format [8] is designed for this purpose. 679 Consult [2]'s Section 5 for a discussion of IM-specific security 680 issues. 682 Consult [4]'s Section 13 for a discussion of SIP-specific security 683 issues. 685 Consult [6]'s Section 7 for a discussion of SDP-specific security 686 issues. 688 Consult [5]'s Section 9 for a discussion of BEEP-specific security 689 issues. 691 Although use of the tuning attribute in the SDP announcement is a 692 policy matter, at a minimum, all IMSX implementations must provide 693 the following tuning profiles: 695 tuning value profile 696 -------------- ------------------------------------ 697 authentication http://iana.org/beep/SASL/DIGEST-MD5 699 integrity http://iana.org/beep/SASL/DIGEST-MD5 701 privacy http://iana.org/beep/TLS using the 702 TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher 704 all http://iana.org/beep/TLS using the 705 TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher 706 and client-side certificates 708 References 710 [1] Crocker, D., "Common Presence and Instant Messaging (CPIM)", 711 draft-ietf-impp-cpim-02 (work in progress), November 2001. 713 [2] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 714 Presence Protocol Requirements", RFC 2779, February 2000. 716 [3] Rosenberg, J., "SIP Extensions for Instant Messaging", draft- 717 ietf-simple-im-01 (work in progress), July 2001. 719 [4] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, 720 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 722 [5] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 723 3080, March 2001. 725 [6] Handley, M. and V. Jacobson, "SDP: Session Description 726 Protocol", RFC 2327, April 1998. 728 [7] Rosenberg, J., Srisuresh, P., Molitor, A., Rayhan, A. and J. 729 Kuthan, "Middlebox Communication Architecture and framework", 730 draft-ietf-midcom-framework-06 (work in progress), December 731 2001. 733 [8] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging 734 Message Format", draft-ietf-impp-cpim-msgfmt-04 (work in 735 progress), November 2001. 737 [9] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 738 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 739 1998. 741 [10] Levinson, E., "The MIME Multipart/Related Content-type", RFC 742 2387, August 1998. 744 [11] Levinson, E., "Content-ID and Message-ID Uniform Resource 745 Locators", RFC 2392, August 1998. 747 [12] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 748 Extensions (MIME) Part One: Format of Internet Message Bodies", 749 RFC 2045, November 1996. 751 Author's Address 753 Marshall T. Rose 754 Dover Beach Consulting, Inc. 755 POB 255268 756 Sacramento, CA 95865-5268 757 US 759 Phone: +1 916 483 8878 760 EMail: mrose@dbc.mtview.ca.us 762 Appendix A. Acknowledgements 764 The author gratefully acknowledge the contributions of: Rohan Mahy, 765 Eamon O'Tuathail, and Jon Peterson. 767 Appendix B. IANA Considerations 769 If the IESG approves this memo for publication, then the IANA 770 registers the profile specified in Section 4.1, and selects an IANA- 771 specific URI, e.g., 773 http://iana.org/beep/imsx 775 The IANA registers "imsx" as a TCP port number, as specified in 776 Section 4.2. 778 The IANA registers "IMSX/TCP" as a SDP "proto", as specified in 779 Section 4.3. 781 The IANA registers "tuning" as a SDP "att-field", as specified in 782 Section 4.4. 784 Appendix C. Revision History 786 Note to RFC editor: please remove this entire appendix, and the 787 corresponding entries in the table of contents, prior to publication. 789 C.1 Changes from draft-mrose-simple-exchange-00 791 o Clarified text regarding middleboxes and proxies. 793 o Added definition of "I:", "L:", "C:", and "S:". 795 o Added reminder text that "Content-ID:" headers are referenced only 796 within the multipart. 798 Full Copyright Statement 800 Copyright (C) The Internet Society (2001). All Rights Reserved. 802 This document and translations of it may be copied and furnished to 803 others, and derivative works that comment on or otherwise explain it 804 or assist in its implementation may be prepared, copied, published 805 and distributed, in whole or in part, without restriction of any 806 kind, provided that the above copyright notice and this paragraph are 807 included on all such copies and derivative works. However, this 808 document itself may not be modified in any way, such as by removing 809 the copyright notice or references to the Internet Society or other 810 Internet organizations, except as needed for the purpose of 811 developing Internet standards in which case the procedures for 812 copyrights defined in the Internet Standards process must be 813 followed, or as required to translate it into languages other than 814 English. 816 The limited permissions granted above are perpetual and will not be 817 revoked by the Internet Society or its successors or assigns. 819 This document and the information contained herein is provided on an 820 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 821 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 822 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 823 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 824 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 826 Acknowledgement 828 Funding for the RFC Editor function is currently provided by the 829 Internet Society.