idnits 2.17.1 draft-mrose-impp-common-00.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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** 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 177: '...e the local-part MUST be interpreted a...' RFC 2119 keyword, line 194: '...ing, a DNS lookup MUST be performed to...' RFC 2119 keyword, line 195: '... resolve the domain[5]. The names MUST be fully-qualified domain...' RFC 2119 keyword, line 203: '...ound for a given domain, a sender MUST...' RFC 2119 keyword, line 236: '...ions, the client MUST be able to try e...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 21, 2000) is 8647 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) -- Looks like a reference, but probably isn't: 'RFC-1766' on line 633 -- Looks like a reference, but probably isn't: 'RFC-2396' on line 642 ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 2778 (ref. '2') ** Obsolete normative reference: RFC 822 (ref. '3') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2440 (ref. '7') (Obsoleted by RFC 4880) ** Obsolete normative reference: RFC 2632 (ref. '8') (Obsoleted by RFC 3850) Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D.H. Crocker 3 Internet-Draft Brandenburg Consulting 4 Expires: February 19, 2001 A. Diacakis 5 F. Mazzoldi 6 Network Projects Inc. 7 C. Huitema 8 Microsoft Corporation 9 G. Klyne 10 Content Technologies Limited 11 M.T. Rose 12 Invisible Worlds, Inc. 13 J. Rosenberg 14 R. Sparks 15 dynamicsoft 16 H. Sugano 17 Fujitsu Laboratories Ltd. 18 August 21, 2000 20 A Common Profile for Instant Messaging (CPIM) 21 draft-mrose-impp-common-00 23 Status of this Memo 25 This document is an Internet-Draft and is in full conformance with 26 all provisions of Section 10 of RFC2026. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other documents 35 at any time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on February 19, 2001. 46 Copyright Notice 48 Copyright (C) The Internet Society (2000). All Rights Reserved. 50 Abstract 51 This memo describes a common set of Instant Messaging formats and 52 services, independent of underlying IM infrastructure. The profile 53 meets the requirements specified in RFC 2779 using a minimalist 54 approach allowing interoperation of a wide range of IM systems. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2 A Note on The Examples . . . . . . . . . . . . . . . . . . 3 61 2. Abstract Messaging Service . . . . . . . . . . . . . . . . 4 62 2.1 Overview of the Messaging Service . . . . . . . . . . . . 4 63 2.2 Addressing of INSTANT INBOXes . . . . . . . . . . . . . . 5 64 2.2.1 Address Resolution . . . . . . . . . . . . . . . . . . . . 5 65 2.2.1.1 Domain Name Lookup . . . . . . . . . . . . . . . . . . . . 5 66 2.2.1.2 Processing SRV RRs . . . . . . . . . . . . . . . . . . . . 6 67 2.2.1.3 Processing Multiple Addresses . . . . . . . . . . . . . . 6 68 2.3 Format of Instant Messages . . . . . . . . . . . . . . . . 7 69 2.4 The Messaging Service . . . . . . . . . . . . . . . . . . 8 70 2.4.1 The Message Operation . . . . . . . . . . . . . . . . . . 8 71 3. Abstract Presence Service . . . . . . . . . . . . . . . . 10 72 3.1 Overview of the Presence Service . . . . . . . . . . . . . 10 73 3.2 Addressing of PRESENTITIES . . . . . . . . . . . . . . . . 13 74 3.3 Format of Presence Information . . . . . . . . . . . . . . 14 75 3.4 The Presence Service . . . . . . . . . . . . . . . . . . . 15 76 3.4.1 The Subscribe Operation . . . . . . . . . . . . . . . . . 15 77 3.4.2 The Notify Operation . . . . . . . . . . . . . . . . . . . 17 78 3.4.3 The Unsubscribe Operation . . . . . . . . . . . . . . . . 18 79 4. Security Considerations . . . . . . . . . . . . . . . . . 19 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . 20 81 5.1 The IM URI Scheme . . . . . . . . . . . . . . . . . . . . 20 82 5.2 The PRES URI Scheme . . . . . . . . . . . . . . . . . . . 20 83 6. The Common Service DTD . . . . . . . . . . . . . . . . . . 21 84 7. The Messaging Service DTD . . . . . . . . . . . . . . . . 23 85 8. The Presence Service DTD . . . . . . . . . . . . . . . . . 24 86 References . . . . . . . . . . . . . . . . . . . . . . . . 26 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 26 88 A. Issues of Interest . . . . . . . . . . . . . . . . . . . . 29 89 A.1 Address Mapping . . . . . . . . . . . . . . . . . . . . . 29 90 A.1.1 Source-Route Mapping . . . . . . . . . . . . . . . . . . . 29 91 Full Copyright Statement . . . . . . . . . . . . . . . . . 30 93 1. Introduction 95 To achieve interoperation of IM systems that are compliant with RFC 96 2779[1], there must be a common agreement on both Instant Messaging 97 and Presence services. This memo defines such an agreement according 98 to the philosophy that there must be no loss of information between 99 IM systems that are minimally conformant to RFC2779. 101 This memo focuses on interoperation. Accordingly only those aspects 102 of IM that require interoperation are discussed. For example, the 103 "open instant inbox" operation is not applicable as this operation 104 occurs within a single IM system and not across systems. 106 Service behavior is described abstractly in terms of operations 107 invoked between the consumer and provider of a service. Accordingly, 108 each IM service must specify how this behavior is mapped onto its 109 own protocol interactions. The choice of strategy is a local matter, 110 providing that there is a clear relation between the abstract 111 behavior of the service (as specified in this memo) and how it is 112 faithfully realized by a particular IM service. 114 The parameters for each operation are defined using an abstract 115 syntax. Although the syntax specifies the range of possible data 116 values, each IM service must specify how well-formed instances of 117 the abstract representation are encoded as a concrete series of bits. 119 For example, one strategy might transmit presence information as 120 key/value pairs, another might use a compact binary representation, 121 and a third might use nested containers. The choice of strategy is a 122 local matter, providing that there is a clear relation between the 123 abstract syntax (as specified in this memo) and how it is faithfully 124 encoded by an particular IM service. 126 1.1 Terminology 128 This memos makes use of the vocabulary defined in RFC 2778[2]. Terms 129 such as as CLOSED, INSTANT INBOX, INSTANT MESSAGE, OPEN, PRESENCE 130 SERVICE, PRESENTITY, SUBSCRIPTION, and WATCHER are used in the same 131 meaning as defined therein. 133 1.2 A Note on The Examples 135 In the examples which follow, this memo uses time-sequence diagrams 136 annotated with XML fragments to illustrate operations and their 137 parameters. The use of XML is an artifact of this memo's 138 presentation style and does not imply any requirement for the use of 139 XML in an IM system. 141 2. Abstract Messaging Service 143 2.1 Overview of the Messaging Service 145 When an application wants to send a message to an INSTANT INBOX, it 146 invokes the message operation, e.g., 148 +-------+ +-------+ 149 | | | | 150 | appl. | -- message ------> | IM | 151 | | | svc. | 152 +-------+ +-------+ 154 157 ... 158 Content-Type: text/plain; charset="us-ascii" 160 Yabba, dabba, doo! 162 The service immediately responds by invoking the response operation 163 containing the same transaction-identifier, e.g., 165 +-------+ +-------+ 166 | | | | 167 | appl. | <----- response -- | IM | 168 | | | svc. | 169 +-------+ +-------+ 171 173 2.2 Addressing of INSTANT INBOXes 175 An INSTANT INBOX is specified using the IM URI (Section 5.1) scheme. 176 Briefly, the "addr-spec" syntax of RFC 822[3] (i.e., "local@domain") 177 is used, where the local-part MUST be interpreted and assigned 178 semantics only by the host specified in the domain part of the 179 address. 181 2.2.1 Address Resolution 183 A client determines the address of an appropriate host running a 184 server by resolving a destination domain name to either an 185 intermediate relay host or a final target host. 187 Only resolvable, fully-qualified, domain names (FQDNs) are permitted 188 when domain names are used in the messaging service (i.e., domain 189 names that can be resolved to SRV[4] or A RRs). 191 2.2.1.1 Domain Name Lookup 193 A client lexically identifies a domain to which instant messages 194 will be delivered for processing, a DNS lookup MUST be performed to 195 resolve the domain[5]. The names MUST be fully-qualified domain 196 names (FQDNs) -- mechanisms for inferring FQDNs from partial names 197 or local aliases are a local matter. 199 The lookup first attempts to locate SRV RRs associated with the 200 domain. If a CNAME RR is found instead, the resulting domain is 201 processed as if it were the initial domain. 203 If one or more SRV RRs are found for a given domain, a sender MUST 204 NOT utilize any A RRs associated with that domain unless they are 205 located using the SRV RRs; otherwise, if no SRV RRs are found, but 206 an A RR is found, then the A RR is treated as if it was associated 207 with an implicit SRV RR, with a preference of 0, pointing to that 208 host. 210 2.2.1.2 Processing SRV RRs 212 To process an IM URI, a lookup is performed for SRVs for the target 213 domain and a desired IM transport protocol. 215 For example, if the destination INSTANT INBOX is 216 "im:fred@example.com", and the sender wishes to use an IM transport 217 protocol called "SIP", then a SRV lookup is performed for: 219 _im._sip.example.com. 221 The returned RRs, if any, specify the next-hop server. 223 The choice of IM transport protocol is a local configuration option 224 for each system. 226 Using this mechanism, seamless routing of IM traffic is possible, 227 regardless of whether a gateway is necessary for interoperation. To 228 achieve this transparency, a seperate RR for a gateway must be 229 present for each transport protocol and domain pair that it serves. 231 2.2.1.3 Processing Multiple Addresses 233 When the lookup succeeds, the mapping can result in a list of 234 alternative delivery addresses rather than a single address, because 235 of multiple SRV records, multihoming, or both. For reliable 236 operations, the client MUST be able to try each of the relevant 237 addresses in this list in order, until a delivery attempt succeeds. 238 However, there MAY also be a configurable limit on the number of 239 alternate addresses that can be tried. In any case, the client 240 SHOULD try at least two addresses. Two types of information are used 241 to rank the host addresses: multiple SRV records, and multihomed 242 hosts. 244 Multiple SRV records contain a preference indication that MUST be 245 used in sorting. Lower numbers are preferrable to higher ones. If 246 there are multiple destinations with the same preference, and there 247 is no clear reason to favor one (e.g., by recognition of an 248 easily-reached address), then the sender MUST randomize them to 249 spread the load across multiple servers for a specific destination. 251 The destination host (perhaps taken from the preferred SRV record) 252 may be multihomed, in which case the resolver will return a list of 253 alternative IP addresses. It is the responsibility of the resolver 254 to have ordered this list by decreasing preference if necessary, and 255 the sender MUST try them in the order presented. 257 2.3 Format of Instant Messages 259 An INSTANT MESSAGE comprises a MIME[6] content. 261 Note that the IETF provides numerous technologies that allow 262 end-users to exchange authenticated and private messages formatted 263 as MIME objects, c.f., PGP-MIME[7] and S/MIME[8]. 265 2.4 The Messaging Service 267 Section 6 and Section 7 define the abstract syntax of the operations 268 invoked with the service. 270 Note that the transaction-identifier parameters used with the 271 service are potentially long-lived. Accordingly, the values of 272 transaction-identifiers should appear to be unpredictable. 274 2.4.1 The Message Operation 276 When an application wants to send an INSTANT MESSAGE, it invokes the 277 message operation. 279 The message operation has these parameters: 281 o the source parameter specifies the INSTANT INBOX on whose behalf 282 this message is sent (using an IM URI); 284 o the destination parameter specifies the INSTANT INBOX that the 285 message should be delivered to (using an IM URI); 287 o the transID parameter specifies the transaction-identifier 288 associated with this operation; and, 290 o the message to be sent. 292 When the service is informed of the message operation, it performs 293 these steps: 295 1. If the source or destination does not refer to a valid INSTANT 296 INBOX, a response operation having status "failure" is invoked. 298 2. If access control does not permit the application to request 299 this operation, a response operation having status "failure" is 300 invoked. 302 3. Otherwise: 304 1. If the service is able to successfully deliver the message, 305 a response operation having status "success" is invoked. 307 2. If the service is unable to successfully deliver the 308 message, a response operation having status "failure" is 309 invoked. 311 3. If the service must delegate responsibility for delivery, 312 and if the delegation will not result in a future 313 authoritative indication to the service, a response 314 operation having status "indeterminant" is invoked. 316 4. If the service must delegate responsibility for delivery, 317 and if the delegation will result in a future authoritative 318 indication to the service, then a response operation is 319 invoked immediately after the indication is received. 321 When the service invokes the response operation, the transID 322 parameter is identical to the value found in the message operation 323 invoked by the application. 325 3. Abstract Presence Service 327 3.1 Overview of the Presence Service 329 When an application wants to (periodically) receive the presence 330 information associated with a PRESENTITY, it invokes the subscribe 331 operation, e.g., 333 +-------+ +-------+ 334 | | | | 335 | appl. | -- subscribe ----> | pres. | 336 | | | svc. | 337 +-------+ +-------+ 339 343 The service immediately responds by invoking the response operation 344 containing the same transaction-identifier, e.g., 346 +-------+ +-------+ 347 | | | | 348 | appl. | <----- response -- | pres. | 349 | | | svc. | 350 +-------+ +-------+ 352 354 A WATCHER may have at most one subscription for a PRESENTITY. 356 If the response operation indicates success, then for up to the 357 specified duration, the service invokes the notify operation 358 whenever there are any changes to the PRESENTITY's presence 359 information, e.g., 361 +-------+ +-------+ 362 | | | | 363 | appl. | <------- notify -- | pres. | 364 | | | svc. | 365 +-------+ +-------+ 367 370 371 373 374 376 If the duration parameter is zero-valued, exactly one notify 377 operation is invoked, achieving a one time poll of the presence 378 information. Regardless, there is no application response to the 379 notify operation (i.e., the application does not invoke a response 380 operation when a notify operation occurs). 382 The application may prematurely cancel a subscription by invoking 383 the unsubscribe operation, e.g., 385 +-------+ +-------+ 386 | | | | 387 | appl. | -- unsubscribe --> | pres. | 388 | | | svc. | 389 +-------+ +-------+ 391 395 The service immediately responds by invoking the response operation 396 containing the same transaction-identifier, e.g., 398 +-------+ +-------+ 399 | | | | 400 | appl. | <----- response -- | pres. | 401 | | | svc. | 402 +-------+ +-------+ 404 406 3.2 Addressing of PRESENTITIES 408 A PRESENTITY is specified using the PRES URI (Section 5.2) scheme. 409 Briefly, the "addr-spec" syntax of RFC 822[3] (i.e., "local@domain") 410 is used, where the local-part MUST be interpreted and assigned 411 semantics only by the host specified in the domain part of the 412 address. 414 To resolve addresses associated with the Presence service, the 415 mechanism defined in Section 2.2.1 is used, except that the 416 processing of a PRES URI is performed by looking up SRV RRs for a 417 desired presence transport protocol. 419 For example, if the destination PRESENTITY is 420 "pres:fred@example.com", and the sender wishes to use a presence 421 transport protocol called "PEPP", then a SRV lookup is performed for: 423 _pres._pepp.example.com. 425 3.3 Format of Presence Information 427 Section 8 defines the abstract syntax for presence information using 428 an XML DTD. Note that this memo does not require that XML be used 429 between the application and the service. Accordingly, each IM system 430 must define how well-formed presence information is encoded in 431 transit. 433 Each PRESENTITY's presence information contains an "entityInfo" 434 attribute, and contains one or more "tuple" elements: 436 o the "entityInfo" attribute specifies arbitrary information about 437 the PRESENTITY (using a URI); and, 439 o each "tuple" element specifies information associated with the 440 PRESENTITY. 442 Each "tuple" element has a "destination" attribute, a "status" 443 attribute, and contains arbitrary content: 445 o the "destination" attribute specifies a URI; 447 o the "status" attribute is either OPEN or CLOSED; and, 449 o the content of the "tuple" element contains arbitrary information 450 about the tuple. 452 3.4 The Presence Service 454 Section 6 and Section 8 define the abstract syntax of the operations 455 invoked with the service. 457 An implementation of the service must maintain information about 458 both presence information and in-progress operations in persistent 459 storage. 461 Note that the transaction-identifier parameter used with the service 462 is potentially long-lived. Accordingly, the values generated for 463 this parameter should appear to be unpredictable. 465 3.4.1 The Subscribe Operation 467 When an application wants to (periodically) receive the presence 468 information associated with an PRESENTITY, it invokes the subscribe 469 operation. 471 The subscribe operation has these parameters: 473 o the watcher parameter specifies the WATCHER associated with the 474 subscription; 476 o the target parameter specifies the PRESENTITY associated with the 477 presence information; 479 o the duration parameter specifies the maximum number of seconds 480 that the SUBSCRIPTION should be active; and, 482 o the transID parameter specifies the transaction-identifier 483 associated with this operation. 485 When the service is informed of the subscribe operation, it performs 486 these steps: 488 1. If the watcher or target parameter does not refer to a valid 489 PRESENTITY, a response operation having status "failure" is 490 invoked. 492 2. If access control does not permit the application to request 493 this operation, a response operation having status "failure" is 494 invoked. 496 3. If the duration parameter is non-zero, and if the watcher and 497 target parameters refer to an in-progress subscribe operation 498 for the application, a response operation having status 499 "failure" is invoked. 501 4. Otherwise: 503 1. A response operation having status "success" is immediately 504 invoked. (If the service chooses a different duration for 505 the subscription then it conveys this information in the 506 response operation.) 508 2. A notify operation, corresponding to the target's presence 509 information, is immediately invoked for the watcher. 511 3. For up to the amount of time indicated by the duration 512 parameter, if the target's presence information changes, and 513 if access control allows, a notify operation is invoked for 514 the watcher. 516 Note that if the duration parameter is zero-valued, then the 517 subscribe operation is making a one-time poll of the presence 518 information. Accordingly, Step 4.3 above does not occur. 520 When the service invokes a response operation as a result of this 521 processing, the transID parameter is identical to the value found in 522 the subscribe operation invoked by the application. 524 3.4.2 The Notify Operation 526 The service invokes the notify operation whenever the presence 527 information associated with a PRESENTITY changes and there are 528 subscribers to that information. 530 The notify operation has these parameters: 532 o the watcher parameter specifies the WATCHER associated with the 533 subscription; 535 o the target parameter specifies the PRESENTITY associated with the 536 presence information; 538 o the transID parameter specifies the transaction-identifier 539 associated with this operation; and, 541 o the presence information for the PRESENTITY. 543 There is no application response to the notify operation. 545 3.4.3 The Unsubscribe Operation 547 When an application wants to terminate a subscription, it invokes 548 the unsubscribe operation. 550 The unsubscribe operations has these parameters: 552 o the watcher parameter specifies the WATCHER associated with the 553 subscription; 555 o the target parameter specifies the PRESENTITY associated with the 556 presence information; and, 558 o the transID parameter specifies the transaction-identifier 559 associated with a subscription. 561 When the service is informed of the unsubscribe operation, it 562 performs these steps: 564 1. If the wather and target parameters do not refer to an 565 in-progress subscribe operation for the application, a response 566 operation having status "failure" is invoked. 568 2. Otherwise, the in-progress subscribe operation for the 569 application is terminated, and a response operation having 570 status "success" is invoked by the service. 572 Note that following a successful unsubscribe operation, the WATCHER 573 may receive further notifications. Although the service will no 574 longer invoke the notify operation after successfully processing a 575 unsubscribe operation, earlier notify operations may still be in 576 progress. 578 4. Security Considerations 580 This memo makes no specific requirements on security procedures for 581 interoperation between IM systems. Accordingly, trust between 582 interconnected IM systems is determined in a bilateral matter. 584 However, this memo does require that each IM system control access 585 to its Instant Messaging and Presence services. Consult both RFC 586 2778 and RFC2779 for a discussion of security considerations for for 587 IM systems. 589 5. IANA Considerations 591 The IANA assigns the "im" and "pres" URL schemes. 593 5.1 The IM URI Scheme 595 The Instant Messaging (IM) URI scheme designates an Internet 596 resource, namely an INSTANT INBOX. 598 The syntax of an IM URL has the form: 600 "im:" addr-spec 602 where "addr-spec" is defined in RFC 822. 604 5.2 The PRES URI Scheme 606 The Presence (PRES) URI scheme designates an Internet resource, 607 namely a PRESENTITY or WATCHER. 609 The syntax of a PRES URL has the form: 611 "pres:" addr-spec 613 where "addr-spec" is defined in RFC 822. 615 6. The Common Service DTD 617 627 645 646 647 648 650 654 655 662 7. The Messaging Service DTD 664 674 676 %IMCOMMON; 678 686 688 692 693 698 8. The Presence Service DTD 700 710 712 %IMCOMMON; 714 722 724 728 729 732 733 737 741 742 748 752 753 758 762 763 768 References 770 [1] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 771 Presence Protocol Requirements", RFC 2779, February 2000. 773 [2] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 774 Instant Messaging", RFC 2778, February 2000. 776 [3] Crocker, D., "Standard for the format of ARPA Internet text 777 messages", RFC 822, STD 11, Aug 1982. 779 [4] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 780 specifying the location of services (DNS SRV)", RFC 2782, 781 February 2000. 783 [5] Mockapetris, P.V., "Domain names - concepts and facilities", 784 RFC 1034, STD 13, Nov 1987. 786 [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 787 Extensions (MIME) Part One: Format of Internet Message Bodies", 788 RFC 2045, November 1996. 790 [7] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP 791 Message Format", RFC 2440, November 1998. 793 [8] Ramsdell, B., "S/MIME Version 3 Certificate Handling", RFC 794 2632, June 1999. 796 [9] Allocchio, C., "GSTN Address Element Extensions in E-mail 797 Services", RFC 2846, June 2000. 799 Authors' Addresses 801 David H. Crocker 802 Brandenburg Consulting 803 675 Spruce Drive 804 Sunnyvale, CA 94086 805 US 807 Phone: +1 408 246 8253 808 EMail: dcrocker@brandenburg.com 809 URI: http://www.brandenburg.com/ 810 Athanassios Diacakis 811 Network Projects Inc. 812 4516 Henry Street 813 Suite 113 814 Pittsburgh, PA 15213 815 US 817 Phone: +1 412 681 6950 x202 818 EMail: thanos@networkprojects.com 820 Florencio Mazzoldi 821 Network Projects Inc. 822 4516 Henry Street 823 Suite 113 824 Pittsburgh, PA 15213 825 US 827 Phone: +1 412 681 6950 828 EMail: flo@networkprojects.com 830 Christian Huitema 831 Microsoft Corporation 832 One Microsoft Way 833 Redmond, WA 98052-6399 834 US 836 EMail: huitema@microsoft.com 838 Graham Klyne 839 Content Technologies Limited 840 1220 Parkview 841 Arlington Business Park 842 Theale, Reading RG7 4SA 843 UK 845 Phone: +44 118 930 1300 846 EMail: gk@acm.org 847 Marshall T. Rose 848 Invisible Worlds, Inc. 849 1179 North McDowell Boulevard 850 Petaluma, CA 94954-6559 851 US 853 Phone: +1 707 789 3700 854 EMail: mrose@invisible.net 855 URI: http://invisible.net/ 857 Jonathan Rosenberg 858 dynamicsoft 859 200 Executive Drive 860 Suite 120 861 West Orange, NJ 07052 862 US 864 EMail: jdrosen@dynamicsoft.com 866 Robert Sparks 867 dynamicsoft 868 200 Executive Drive 869 Suite 120 870 West Orange, NJ 07052 871 US 873 EMail: rsparks@dynamicsoft.com 875 Hiroyasu Sugano 876 Fujitsu Laboratories Ltd. 877 64 Nishiwaki, Ohkubo-cho 878 Akashi 674-8555 879 JP 881 EMail: suga@flab.fujitsu.co.jp 883 Appendix A. Issues of Interest 885 This appendix briefly discusses issues that may be of interest when 886 designing an interoperation gateway. 888 A.1 Address Mapping 890 When mapping the service described in this memo, mappings which 891 place special information into the IM address local part SHOULD use 892 the meta-syntax defined in RFC 2486[9]. 894 A.1.1 Source-Route Mapping 896 The easiest mapping technique is a form of source-routing and 897 usually is the least friendly to humans having to type the string. 899 The transformation places the entire, original address string into 900 the IM address local part and names the gateway in the domain part. 902 For example, if the destination INSTANT INBOX is 903 "pepp://example.com/fred", then, after performing the necessary 904 character conversions, the resulting mapping is: 906 im:pepp=example.com/fred@relay-domain 908 where "relay-domain" is derived from local configuration information. 910 Experience shows that it is vastly preferrable to hide this mapping 911 from end-users -- if possible, the mapping should be performed 912 automatically by the underlying software. 914 Full Copyright Statement 916 Copyright (C) The Internet Society (2000). All Rights Reserved. 918 This document and translations of it may be copied and furnished to 919 others, and derivative works that comment on or otherwise explain it 920 or assist in its implementation may be prepared, copied, published 921 and distributed, in whole or in part, without restriction of any 922 kind, provided that the above copyright notice and this paragraph 923 are included on all such copies and derivative works. However, this 924 document itself may not be modified in any way, such as by removing 925 the copyright notice or references to the Internet Society or other 926 Internet organizations, except as needed for the purpose of 927 developing Internet standards in which case the procedures for 928 copyrights defined in the Internet Standards process must be 929 followed, or as required to translate it into languages other than 930 English. 932 The limited permissions granted above are perpetual and will not be 933 revoked by the Internet Society or its successors or assigns. 935 This document and the information contained herein is provided on an 936 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 937 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 938 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 939 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 940 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 942 Acknowledgement 944 Funding for the RFC editor function is currently provided by the 945 Internet Society.