idnits 2.17.1 draft-ietf-impp-pres-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. ** The abstract seems to contain references ([12]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (October 27, 2002) is 7851 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 387, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 390, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 393, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 396, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 400, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 403, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 413, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 419, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 422, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 426, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-impp-srv-00 ** Obsolete normative reference: RFC 822 (ref. '3') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2822 (ref. '4') (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 2440 (ref. '7') (Obsoleted by RFC 4880) == Outdated reference: A later version (-03) exists of draft-klyne-message-rfc822-xml-00 -- Possible downref: Normative reference to a draft: ref. '8' == Outdated reference: A later version (-08) exists of draft-ietf-impp-cpim-msgfmt-05 == Outdated reference: A later version (-08) exists of draft-ietf-impp-cpim-pidf-00 ** Obsolete normative reference: RFC 2632 (ref. '11') (Obsoleted by RFC 3850) ** Downref: Normative reference to an Informational RFC: RFC 2778 (ref. '12') ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '13') Summary: 9 errors (**), 0 flaws (~~), 17 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IMPP WG D. Crocker 3 Internet-Draft Brandenburg 4 Expires: April 27, 2003 A. Diacakis 5 F. Mazzoldi 6 Net Proj 7 C. Huitema 8 Microsoft 9 G. Klyne 10 Baltimore 11 J. Rosenberg 12 R. Sparks 13 dynamicsoft 14 H. Sugano 15 Fujitsu 16 J. Peterson 17 NeuStar 18 October 27, 2002 20 Common Profile: Presence 21 draft-ietf-impp-pres-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 Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 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 http:// 39 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 April 27, 2003. 46 Copyright Notice 48 Copyright (C) The Internet Society (2002). All Rights Reserved. 50 Abstract 52 Presence is defined in RFC2778 [12]. Today, numerous presence 53 protocols are in use (largely as components of commercial instant 54 messaging services), and little interoperability between services 55 based on these protocols has been achieved. This specification 56 defines common semantics and data formats for presence to facilitate 57 the creation of gateways between presence services. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Abstract Presence Service . . . . . . . . . . . . . . . . . 5 64 3.1 Overview of the Presence Service . . . . . . . . . . . . . . 5 65 3.2 Identification of PRESENTITIES and WATCHERS . . . . . . . . 7 66 3.3 Format of Presence Information . . . . . . . . . . . . . . . 7 67 3.4 The Presence Service . . . . . . . . . . . . . . . . . . . . 7 68 3.4.1 The Subscribe Operation . . . . . . . . . . . . . . . . . . 7 69 3.4.2 The Notify Operation . . . . . . . . . . . . . . . . . . . . 8 70 3.4.3 Subscribe Operation (with Zero Duration) . . . . . . . . . . 8 71 4. Security Considerations . . . . . . . . . . . . . . . . . . 10 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 73 5.1 The PRES URI Scheme . . . . . . . . . . . . . . . . . . . . 11 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 75 A. PRES URL IANA Registration Template . . . . . . . . . . . . 16 76 A.1 URL scheme name . . . . . . . . . . . . . . . . . . . . . . 16 77 A.2 URL scheme syntax . . . . . . . . . . . . . . . . . . . . . 16 78 A.3 Character encoding considerations . . . . . . . . . . . . . 16 79 A.4 Intended usage . . . . . . . . . . . . . . . . . . . . . . . 16 80 A.5 Applications and/or protocols which use this URL scheme 81 name . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 A.6 Interoperability considerations . . . . . . . . . . . . . . 16 83 A.7 Security considerations . . . . . . . . . . . . . . . . . . 17 84 A.8 Relevant publications . . . . . . . . . . . . . . . . . . . 17 85 A.9 Person & email address to contact for further information . 17 86 A.10 Author/Change controller . . . . . . . . . . . . . . . . . . 17 87 A.11 Applications and/or protocols which use this URL scheme 88 name . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 89 B. Issues of Interest . . . . . . . . . . . . . . . . . . . . . 18 90 B.1 Address Mapping . . . . . . . . . . . . . . . . . . . . . . 18 91 B.2 Source-Route Mapping . . . . . . . . . . . . . . . . . . . . 18 92 References . . . . . . . . . . . . . . . . . . . . . . . . . 12 93 C. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 19 94 Full Copyright Statement . . . . . . . . . . . . . . . . . . 20 96 1. Introduction 98 Presence is defined in RFC2778 [12]. Today, numerous presence 99 protocols are in use (largely as components of commercial instant 100 messaging services, and little interoperability between services 101 based on these protocols has been achieved. This specification 102 defines semantics and data formats for common services of presence to 103 facilitate the creation of gateways between presence services. 105 Service behavior is described abstractly in terms of operations 106 invoked between the consumer and provider of a service. Accordingly, 107 each presence service must specify how this behavior is mapped onto 108 its own protocol interactions. The choice of strategy is a local 109 matter, providing that there is a clear relation between the abstract 110 behaviors of the service (as specified in this memo) and how it is 111 faithfully realized by a particular presence service. 113 The parameters for each operation are defined using an abstract 114 syntax. Although the syntax specifies the range of possible data 115 values, each Presence and IM service must specify how well-formed 116 instances of the abstract representation are encoded as a concrete 117 series of bits. 119 For example, one strategy might transmit presence information as key/ 120 value pairs, another might use a compact binary representation, and a 121 third might use nested containers. The choice of strategy is a local 122 matter, providing that there is a clear relation between the abstract 123 syntax (as specified in this memo) and how it is faithfully encoded 124 by an particular presence service. 126 In order to provide a means for the preservation of end-to-end 127 features (especially security) to pass through presence 128 interoperability gateways, this specification also provides 129 recommendations for presence document formats that could be employed 130 by presence protocols. 132 2. Terminology 134 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 135 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 136 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 137 described in RFC2119 [1] and indicate requirement levels for 138 compliant implementations. 140 This memos makes use of the vocabulary defined in RFC 2778[9]. Terms 141 such as CLOSED, INSTANT INBOX, PRESENCE, and OPEN are used in the 142 same meaning as defined therein. 144 This document defines operations and attributes of a presence 145 service. In order for a protocol to interface with a presence 146 gateway, it must support all of the operations described in this 147 document (i.e. the presence protocol must have some message or 148 capability that provides the function described by this operation). 149 Similarly, the attributes defined for these operations must 150 correspond to information available in the presence protocol in order 151 for the protocol to interface with gateways defined by this 152 specification. Note that these attributes provide only the minimum 153 possible information that needs to be specified for interoperability 154 - the functions in a presence protocol that correspond to the 155 operations described in this document can contain additional 156 information that will not be mapped by CPIM. 158 3. Abstract Presence Service 160 3.1 Overview of the Presence Service 162 When an application wants to (periodically) receive the presence 163 information associated with a PRESENTITY, it invokes the subscribe 164 operation, e.g., 166 +-------+ +-------+ 167 | | | | 168 | appl. | -- subscribe ----> | pres. | 169 | | | svc. | 170 +-------+ +-------+ 172 The subscribe operation has the following attributes: watcher, 173 target, duration, SubscriptID and TransID. The 'watcher' and 174 'target' identify the WATCHER and PRESENTITY, respectively, using the 175 identifiers described in Section 3.2. The duration specifies the 176 maximum number of seconds that the SUBSCRIPTION should be active 177 (which may be zero, in which case this is a one-time request for 178 presence information). The SubscriptID creates a reference to the 179 SUBSCRIPTION that is used when unsubscribing. The TransID is a 180 unique identifier used to correlate the subscribe operation with a 181 response operation. 183 Upon receiving a subscribe operation, the service immediately 184 responds by invoking the response operation containing the same 185 transaction- identifier, e.g., 187 +-------+ +-------+ 188 | | | | 189 | appl. | <----- response -- | pres. | 190 | | | svc. | 191 +-------+ +-------+ 193 The response operation has the following attributes: status, TransID, 194 and duration. 'status' indicates whether the subscribe operation has 195 succeeded or failed. The TransID of the response operation 196 corresponds to the TransID of the subscription operation to which it 197 is responding. The 'duration' attribute specifies the number of 198 seconds for which the subscription will be active (which may differ 199 from the value requested in the subscribe operation). 201 If the response operation indicates success, the service immediate 202 invokes the notify operation to communicate the presence information 203 to the WATCHER, e.g., 205 +-------+ +-------+ 206 | | | | 207 | appl. | <------- notify -- | pres. | 208 | | | svc. | 209 +-------+ +-------+ 211 The notify operation has the following attributes: watcher, target, 212 and TransID. The values of 'watcher' and 'target' are identical to 213 those given in the subscribe operation that triggered this notify 214 operation. The TransID is a unique identifier for this notification. 216 The notify operation also has content, namely PRESENCE INFORMATION. 217 Some further information on notify content is given in Section 3.3. 219 If the duration parameter is non-zero, then for up to the specified 220 duration, the service invokes the notify operation whenever there are 221 any changes to the PRESENTITY's presence information. Otherwise, 222 exactly one notify operation is invoked, achieving a one-time poll of 223 the presence information. Regardless, there is no application 224 response to the notify operation (i.e., the application does not 225 invoke a response operation when a notify operation occurs) defined 226 in CPP. 228 The application may prematurely cancel a subscription by re-invoking 229 the subscribe operation (as described above) with a duration of 0, 230 e.g., 232 +-------+ +-------+ 233 | | | | 234 | appl. | -- subscribe 0 --> | pres. | 235 | | | svc. | 236 +-------+ +-------+ 238 The service immediately responds by invoking the response operation 239 containing the same transaction- identifier, e.g., 241 +-------+ +-------+ 242 | | | | 243 | appl. | <----- response -- | pres. | 244 | | | svc. | 245 +-------+ +-------+ 247 3.2 Identification of PRESENTITIES and WATCHERS 249 A PRESENTITY is specified using the PRES URI scheme, which is further 250 described in Appendix A. An example would be: 251 "pres:fred@example.com" 253 To resolve identifiers associated with the Presence A client 254 determines the address of an appropriate system running a server by 255 resolving the destination domain name that is part of the identifier 256 to either an intermediate relay system or a final target system. 258 Compliant implementations SHOULD follow the guidelines for 259 dereferencing URIs given in [2]. 261 3.3 Format of Presence Information 263 This specification defines an abstract interoperability mechanism for 264 presence protocols; the message content definition given here 265 pertains to semantics rather than syntax. However, some important 266 properties for interoperability can only be provided if a common end- 267 to-end format for presence is employed by the interoperating presence 268 protocols. Implementations therefore SHOULD support the format 269 defined in PIDF [10]. 271 3.4 The Presence Service 273 An implementation of the service must maintain information about both 274 presence information and in- progress operations in persistent 275 storage. 277 Note that the transaction-identifier parameter used by the service is 278 potentially long-lived. Accordingly, the values generated for this 279 parameter should be unique across a significant duration of time. 281 3.4.1 The Subscribe Operation 283 When an application wants to (periodically) receive the presence 284 information associated with a PRESENTITY, it invokes the subscribe 285 operation. 287 When the service is informed of the subscribe operation, it performs 288 these steps: 290 1. If the watcher or target parameter does not refer to a valid 291 PRESENTITY, a response operation having status "failure" is 292 invoked. 294 2. If access control does not permit the application to request this 295 operation, a response operation having status "failure" is 296 invoked. 298 3. If the duration parameter is non-zero, and if the watcher and 299 target parameters refer to an in-progress subscribe operation for 300 the application, a response operation having status "failure" is 301 invoked. 303 4. Otherwise, if the service is able to successfully deliver the 304 message: 306 A response operation having status "success" is immediately 307 invoked. (If the service chooses a different duration for the 308 subscription then it conveys this information in the response 309 operation.) 311 A notify operation, corresponding to the target's presence 312 information, is immediately invoked for the watcher. 314 For up to the amount of time indicated by the duration 315 parameter, if the target's presence information changes, and 316 if access control allows, a notify operation is invoked for 317 the watcher. 319 Note that if the duration parameter is zero-valued, then the 320 subscribe operation is making a one-time poll of the presence 321 information. Accordingly, the final step above (continued 322 notifications for the duration of the subscription) does not occur. 324 When the service invokes a response operation as a result of this 325 processing, the transID parameter is identical to the value found in 326 the subscribe operation invoked by the application. 328 3.4.2 The Notify Operation 330 The service invokes the notify operation whenever the presence 331 information associated with a PRESENTITY changes and there are 332 subscribers to that information. 334 There is no application response to the notify operation. 336 3.4.3 Subscribe Operation (with Zero Duration) 338 When an application wants to terminate a subscription, it issues a 339 SUBSCRIBE 0 with the transID of an existing subscription. 341 There is no explicit UNSUBSCRIBE command. 343 When an application wants to directly request presence information to 344 be supplied immediately without initiating any persistent 345 subscription, it issues a SUBSCRIBE 0 with a new transID. 347 There is no explicit FETCH command. 349 4. Security Considerations 351 Detailed security considerations for presence protocols given in 352 RFC2779 (in particular, requirements are given in sections 5.1 353 through 5.3 and some motivating discussion in 8.2). 355 CPP defines an interoperability function that is employed by gateways 356 between presence protocols. CPP gateways MUST be compliant with the 357 minimum security requirements of the presence protocols with which 358 they interface. 360 Note that end-to-end security properties (especially confidentiality 361 and integrity) between presentities and watchers that interface 362 through a CPIM gateway can only be provided if a common presence 363 format (such as the format described in [10]) is supported by the 364 protocols interfacing with the CPIM gateway. 366 5. IANA Considerations 368 The IANA assigns the "pres" URL scheme. 370 5.1 The PRES URI Scheme 372 The Presence (PRES) URI scheme designates an Internet resource, 373 namely a PRESENTITY or WATCHER. 375 The syntax of a PRES URL is given in Appendix A. 377 References 379 [1] Bradner, S., "Key words for use in RFCs to indicate requirement 380 levels", RFC 2119, March 1997. 382 [2] Crocker, D., Diacakis, A., Mazzoldi, F., Huitema, C., Klyne, 383 G., Rosenberg, J., Sparks, R., Sugano, H. and J. Peterson, 384 "Address resolution for Instant Messaging and Presence", draft- 385 ietf-impp-srv-00 (work in progress), October 2002. 387 [3] Crocker, D., "Standard for the format of ARPA Internet text 388 Messages", RFC 822, STD 11, August 1982. 390 [4] Resnick, P., "Internet Message Format", RFC 2822, STD 11, April 391 2001. 393 [5] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 394 1034, STD 13, November 1987. 396 [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 397 Extensions (MIME) Part One: Format of Internet Message Bodies", 398 RFC 2045, November 1996. 400 [7] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP 401 Message Format", RFC 2440, November 1998. 403 [8] Klyne, G., "XML Coding of RFC822 Messages", draft-klyne- 404 message-rfc822-xml-00 (work in progress), November 2001. 406 [9] Atkins, D. and G. Klyne, "Common Presence and Instant 407 Messaging: Message Format", draft-ietf-impp-cpim-msgfmt-05 408 (work in progress), December 2001. 410 [10] Sugano, H., "CPIM Presence Information Data Format", draft- 411 ietf-impp-cpim-pidf-00 (work in progress), August 2001. 413 [11] Ramsdell, B., "S/MIME Version 3 Certificate Handlng", RFC 2632, 414 June 1999. 416 [12] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 417 Instant Messaging", RFC 2778, February 2000. 419 [13] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 420 Presence Protocol Requirements", RFC 2779, February 2000. 422 [14] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 423 Specifying the Location of Services (SRV)", RFC 2782, February 424 2000. 426 [15] Allocchio, C., "GSTN Address Element Extensions in Email 427 Services", RFC 2846, June 2000. 429 Authors' Addresses 431 Dave Crocker 432 Brandenburg InternetWorking 433 675 Spruce Drive 434 Sunnyvale, CA 94086 435 US 437 Phone: +1 408/246-8253 438 EMail: dcrocker@brandenburg.com 440 Athanassios Diacakis 441 Network Projects Inc. 442 4516 Henry Street 443 Suite 113 444 Pittsburgh, PA 15213 445 US 447 Phone: +1 412/681-6950 x202 448 EMail: thanos@networkprojects.com 450 Florencio Mazzoldi 451 Network Projects Inc. 452 4516 Henry Street 453 Suite 113 454 Pittsburgh, PA 15213 455 US 457 Phone: +1 412/681-6950 458 EMail: flo@networkprojects.com 460 Christian Huitema 461 Microsoft Corporation 462 One Microsoft Way 463 Redmund, WA 98052-6399 464 US 466 EMail: huitema@microsoft.com 467 Graham Klyne 468 Baltimore Technologies 469 1310 Waterside 470 Arlington Business Park 471 Theale, Reading RG7 4SA 472 UK 474 Phone: +44 118 903 8000 475 EMail: gk@acm.org 477 Jonathan Rosenberg 478 dynamicsoft 479 200 Executive Drive 480 Suite 120 481 West Orange, NJ 07052 482 US 484 EMail: jdrosen@dynamicsoft.com 486 Robert Sparks 487 dynamicsoft 488 200 Executive Drive 489 Suite 120 490 West Orange, NJ 07052 491 US 493 EMail: rsparks@dynamicsoft.com 495 Hiroyasu Sugano 496 Fujitsu Laboratories Ltd. 497 200 Executive Drive 498 64 Nishiwaki, Ohkubo-cho 499 Akashi 674-8555 500 JP 502 EMail: suga@flab.fujitsu.co.jp 503 Jon Peterson 504 NeuStar, Inc. 505 1800 Sutter St 506 Suite 570 507 Concord, CA 94520 508 US 510 Phone: +1 925/363-8720 511 EMail: jon.peterson@neustar.biz 513 Appendix A. PRES URL IANA Registration Template 515 This section provides the information to register the pres: presence 516 URL . 518 A.1 URL scheme name 520 pres 522 A.2 URL scheme syntax 524 The syntax follows the existing mailto: URL syntax specified in 525 RFC2368. The ABNF is: 527 PRES-URL = "pres:" [ to ] [ headers ] 528 to = #mailbox 529 headers = "?" header *( "&" header ) 530 header = hname "=" hvalue 531 hname = *urlc 532 hvalue = *urlc 534 A.3 Character encoding considerations 536 Representation of non-ASCII character sets in local-part strings is 537 limited to the standard methods provided as extensions to RFC 2822[1] 539 A.4 Intended usage 541 Use of the pres: URL follows closely usage of the mailto: URL. That 542 is, invocation of an PRES URL will cause the user's instant messaging 543 application to start, with destination address and message headers 544 fill-in according to the information supplied in the URL. 546 A.5 Applications and/or protocols which use this URL scheme name 548 It is anticipated that protocols compliant with RFC2779, and meeting 549 the interoperability requirements specified here, will make use of 550 this URL scheme name. 552 A.6 Interoperability considerations 554 The underlying exchange protocol used to send an instant message may 555 vary from service to service. Therefore complete, Internet-scale 556 interoperability cannot be guaranteed. However, a service conforming 557 to this specification permits gateways to achieve interoperability 558 sufficient to the requirements of RFC2779. 560 A.7 Security considerations 562 When PRES URLs are placed in presence protocols, they convey the 563 identity of the sender and/or the recipient. In some cases, 564 anonymous messaging may be desired. Such a capability is beyond the 565 scope of this specification. 567 A.8 Relevant publications 569 RFC2779, RFC2778 571 A.9 Person & email address to contact for further information 573 Jon Peterson [mailto:jon.peterson@neustar.biz] 575 A.10 Author/Change controller 577 This scheme is registered under the IETF tree. As such, IETF 578 maintains change control. 580 A.11 Applications and/or protocols which use this URL scheme name 582 Instant messaging service; presence service 584 Appendix B. Issues of Interest 586 This appendix briefly discusses issues that may be of interest when 587 designing an interoperation gateway. 589 B.1 Address Mapping 591 When mapping the service described in this memo, mappings that place 592 special information into the im: address local-part MUST use the 593 meta-syntax defined in RFC 2846[12]. 595 B.2 Source-Route Mapping 597 The easiest mapping technique is a form of source- routing and 598 usually is the least friendly to humans having to type the string. 599 Source-routing also has a history of operational problems. 601 Use of source-routing for exchanges between different services is by 602 a transformation that places the entire, original address string into 603 the im: address local part and names the gateway in the domain part. 605 For example, if the destination INSTANT INBOX is "pepp://example.com/ 606 fred", then, after performing the necessary character conversions, 607 the resulting mapping is: 609 im:pepp=example.com/fred@relay-domain 611 where "relay-domain" is derived from local configuration information. 613 Experience shows that it is vastly preferable to hide this mapping 614 from end-users - if possible, the underlying software should perform 615 the mapping automatically. 617 Appendix C. Acknowledgments 618 Full Copyright Statement 620 Copyright (C) The Internet Society (2002). All Rights Reserved. 622 This document and translations of it may be copied and furnished to 623 others, and derivative works that comment on or otherwise explain it 624 or assist in its implementation may be prepared, copied, published 625 and distributed, in whole or in part, without restriction of any 626 kind, provided that the above copyright notice and this paragraph are 627 included on all such copies and derivative works. However, this 628 document itself may not be modified in any way, such as by removing 629 the copyright notice or references to the Internet Society or other 630 Internet organizations, except as needed for the purpose of 631 developing Internet standards in which case the procedures for 632 copyrights defined in the Internet Standards process must be 633 followed, or as required to translate it into languages other than 634 English. 636 The limited permissions granted above are perpetual and will not be 637 revoked by the Internet Society or its successors or assigns. 639 This document and the information contained herein is provided on an 640 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 641 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 642 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 643 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 644 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 646 Acknowledgement 648 Funding for the RFC Editor function is currently provided by the 649 Internet Society.