idnits 2.17.1
draft-ietf-impp-cpim-01.txt:
-(233): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
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:
----------------------------------------------------------------------------
== There are 2 instances of lines with non-ascii characters in the document.
== 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.
** There are 21 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 211: '... 822[1] (i.e., "local@domain") is used, where the local-part MUST be...'
RFC 2119 keyword, line 231: '...ing, a DNS lookup MUST be performed to...'
RFC 2119 keyword, line 232: '... resolve the domain[2]. The names MUST be fully-qualified domain names...'
RFC 2119 keyword, line 240: '...ound for a given domain, a sender MUST...'
RFC 2119 keyword, line 272: '...ions, the client MUST be able to try e...'
(8 more instances...)
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== Line 105 has weird spacing: '...further infor...'
== Line 119 has weird spacing: '...further infor...'
== Line 997 has weird spacing: '...tion of servi...'
== Line 1116 has weird spacing: '... scheme name...'
== Line 1128 has weird spacing: '...ient to the r...'
== (6 more instances...)
-- 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 (November 2000) is 8563 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)
-- Looks like a reference, but probably isn't: 'RFC-1766' on line 809
-- Looks like a reference, but probably isn't: 'RFC-2396' on line 818
== Unused Reference: '3' is defined on line 977, but no explicit reference
was found in the text
** Obsolete normative reference: RFC 822 (ref. '1') (Obsoleted by RFC 2822)
** Obsolete normative reference: RFC 2440 (ref. '4') (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. '5'
** Obsolete normative reference: RFC 2632 (ref. '6') (Obsoleted by RFC 3850)
** Downref: Normative reference to an Informational RFC: RFC 2778 (ref. '7')
** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '8')
Summary: 10 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 D. Crocker
3 Internet-Draft Brandenburg Consulting
4 Expires: May 2, 2001 A. Diacakis
5 F. Mazzoldi
6 Network Projects Inc.
7 C. Huitema
8 Microsoft Corporation
9 G. Klyne
10 Content Technologies
11 M. Rose
12 Invisible Worlds
13 J. Rosenberg
14 R. Sparks
15 dynamicsoft
16 H. Sugano
17 Fujitsu Laboratories Ltd.
18 November 2000
20 A Common Profile for Instant Messaging (CPIM)
21 draft-ietf-impp-cpim-01
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 other
30 groups may also distribute working documents as Internet-Drafts.
32 Internet-Drafts are draft documents valid for a maximum of six months
33 and may be updated, replaced, or obsoleted by other documents at any
34 time. It is inappropriate to use Internet-Drafts as reference
35 material or to cite them other than as "work in progress."
37 The list of current Internet-Drafts can be accessed at
38 http://www.ietf.org/ietf/1id-abstracts.txt.
40 The list of Internet-Draft Shadow Directories can be accessed at
41 http://www.ietf.org/shadow.html.
43 This Internet-Draft will expire on May 2, 2001.
45 Copyright Notice
47 Copyright (C) The Internet Society (2000). All Rights Reserved.
49 Abstract
50 Semantics and data formats for common services of Instant Messaging
51 and online Presence, independent of underlying transport
52 infrastructure, are described. The CPIM profile meets the
53 requirements specified in RFC 2779 using a minimalist approach
54 allowing interoperation of a wide range of IM and Presence systems.
56 Table of Contents
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
59 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
60 1.2 A Note on The Examples . . . . . . . . . . . . . . . . . . 4
61 2. Abstract Messaging Service . . . . . . . . . . . . . . . . 5
62 2.1 Overview of the Messaging Service . . . . . . . . . . . . 5
63 2.2 Identification of INSTANT INBOXes . . . . . . . . . . . . 6
64 2.2.1 Address Resolution . . . . . . . . . . . . . . . . . . . . 6
65 2.2.1.1 Domain Name Lookup . . . . . . . . . . . . . . . . . . . . 6
66 2.2.1.2 Processing SRV RRs . . . . . . . . . . . . . . . . . . . . 7
67 2.2.1.3 Processing Multiple Addresses . . . . . . . . . . . . . . 7
68 2.3 Format of Instant Messages . . . . . . . . . . . . . . . . 8
69 2.4 The Messaging Service . . . . . . . . . . . . . . . . . . 9
70 2.4.1 The Message Operation . . . . . . . . . . . . . . . . . . 9
71 2.4.2 Looping . . . . . . . . . . . . . . . . . . . . . . . . . 10
72 3. Abstract Presence Service . . . . . . . . . . . . . . . . 11
73 3.1 Overview of the Presence Service . . . . . . . . . . . . . 11
74 3.2 Identification of PRESENTITIES . . . . . . . . . . . . . . 14
75 3.3 Format of Presence Information . . . . . . . . . . . . . . 15
76 3.4 The Presence Service . . . . . . . . . . . . . . . . . . . 16
77 3.4.1 The Subscribe Operation . . . . . . . . . . . . . . . . . 16
78 3.4.2 The Notify Operation . . . . . . . . . . . . . . . . . . . 18
79 3.4.3 The Unsubscribe Operation . . . . . . . . . . . . . . . . 19
80 4. Security Considerations . . . . . . . . . . . . . . . . . 20
81 4.1 Threats . . . . . . . . . . . . . . . . . . . . . . . . . 20
82 4.2 Hop-by-hop security . . . . . . . . . . . . . . . . . . . 21
83 4.3 End-to-end security . . . . . . . . . . . . . . . . . . . 22
84 4.3.1 Instant messages . . . . . . . . . . . . . . . . . . . . . 22
85 4.3.2 Presence service . . . . . . . . . . . . . . . . . . . . . 22
86 5. IANA Considerations . . . . . . . . . . . . . . . . . . . 23
87 5.1 The IM URI Scheme . . . . . . . . . . . . . . . . . . . . 23
88 5.2 The PRES URI Scheme . . . . . . . . . . . . . . . . . . . 23
89 6. The Common Service DTD . . . . . . . . . . . . . . . . . . 24
90 7. The Messaging Service DTD . . . . . . . . . . . . . . . . 25
91 8. The Presence Service DTD . . . . . . . . . . . . . . . . . 26
92 9. The Presence Information DTD . . . . . . . . . . . . . . . 28
93 References . . . . . . . . . . . . . . . . . . . . . . . . 29
94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 29
95 A. IM URL IANA Registration Template . . . . . . . . . . . . 32
96 A.1 URL scheme name . . . . . . . . . . . . . . . . . . . . . 32
97 A.2 URL scheme syntax . . . . . . . . . . . . . . . . . . . . 32
98 A.3 Character encoding considerations . . . . . . . . . . . . 32
99 A.4 Intended usage . . . . . . . . . . . . . . . . . . . . . . 32
100 A.5 Applications and/or protocols which use this URL scheme
101 name . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
102 A.6 Interoperability considerations . . . . . . . . . . . . . 32
103 A.7 Security considerations . . . . . . . . . . . . . . . . . 33
104 A.8 Relevant publications . . . . . . . . . . . . . . . . . . 33
105 A.9 Person & email address to contact for further information 33
106 A.10 Author/Change controller . . . . . . . . . . . . . . . . . 33
107 A.11 Applications and/or protocols which use this URL scheme
108 name . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
109 B. PRES URL IANA Registration Template . . . . . . . . . . . 34
110 B.1 URL scheme name . . . . . . . . . . . . . . . . . . . . . 34
111 B.2 URL scheme syntax . . . . . . . . . . . . . . . . . . . . 34
112 B.3 Character encoding considerations . . . . . . . . . . . . 34
113 B.4 Intended usage . . . . . . . . . . . . . . . . . . . . . . 34
114 B.5 Applications and/or protocols which use this URL scheme
115 name . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
116 B.6 Interoperability considerations . . . . . . . . . . . . . 34
117 B.7 Security considerations . . . . . . . . . . . . . . . . . 35
118 B.8 Relevant publications . . . . . . . . . . . . . . . . . . 35
119 B.9 Person & email address to contact for further information 35
120 B.10 Author/Change controller . . . . . . . . . . . . . . . . . 35
121 B.11 Applications and/or protocols which use this URL scheme
122 name . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
123 C. Issues of Interest . . . . . . . . . . . . . . . . . . . . 36
124 C.1 Address Mapping . . . . . . . . . . . . . . . . . . . . . 36
125 C.1.1 Source-Route Mapping . . . . . . . . . . . . . . . . . . . 36
126 Full Copyright Statement . . . . . . . . . . . . . . . . . 37
128 1. Introduction
130 To achieve interoperation of IM systems that are compliant with RFC
131 2779[8], there must be a common agreement on both Instant Messaging
132 and Presence services. This memo defines such an agreement according
133 to the philosophy that there must be no loss of information between
134 IM systems that are minimally conformant to RFC2779.
136 This memo focuses on interoperation. Accordingly only those aspects
137 of IM that require interoperation are discussed. For example, the
138 "open instant inbox" operation is not applicable as this operation
139 occurs within a single IM system and not across systems.
141 Service behavior is described abstractly in terms of operations
142 invoked between the consumer and provider of a service. Accordingly,
143 each IM service must specify how this behavior is mapped onto its own
144 protocol interactions. The choice of strategy is a local matter,
145 providing that there is a clear relation between the abstract
146 behavior of the service (as specified in this memo) and how it is
147 faithfully realized by a particular IM service.
149 The parameters for each operation are defined using an abstract
150 syntax. Although the syntax specifies the range of possible data
151 values, each IM service must specify how well-formed instances of the
152 abstract representation are encoded as a concrete series of bits.
154 For example, one strategy might transmit presence information as
155 key/value pairs, another might use a compact binary representation,
156 and a third might use nested containers. The choice of strategy is a
157 local matter, providing that there is a clear relation between the
158 abstract syntax (as specified in this memo) and how it is faithfully
159 encoded by an particular IM service.
161 1.1 Terminology
163 This memos makes use of the vocabulary defined in RFC 2778[7]. Terms
164 such as as CLOSED, INSTANT INBOX, INSTANT MESSAGE, OPEN, PRESENCE
165 SERVICE, PRESENTITY, SUBSCRIPTION, and WATCHER are used in the same
166 meaning as defined therein.
168 1.2 A Note on The Examples
170 In the examples which follow, this memo uses time-sequence diagrams
171 annotated with XML fragments to illustrate operations and their
172 parameters. The use of XML is an artifact of this memo's presentation
173 style and does not imply any requirement for the use of XML in an IM
174 system.
176 2. Abstract Messaging Service
178 2.1 Overview of the Messaging Service
180 When an application wants to send a message to an INSTANT INBOX, it
181 invokes the message operation, e.g.,
183 +-------+ +-------+
184 | | | |
185 | appl. | -- message ------> | IM |
186 | | | svc. |
187 +-------+ +-------+
189
192 ...
193 Content-Type: text/plain; charset="us-ascii"
195 Yabba, dabba, doo!
197 The service immediately responds by invoking the response operation
198 containing the same transaction-identifier, e.g.,
200 +-------+ +-------+
201 | | | |
202 | appl. | <----- response -- | IM |
203 | | | svc. |
204 +-------+ +-------+
206
208 2.2 Identification of INSTANT INBOXes
210 An INSTANT INBOX is specified using the IM URI (Section 5.1)f RFC
211 822[1] (i.e., "local@domain") is used, where the local-part MUST be
212 interpreted and assigned semantics only by the system specified in
213 the domain part of the identifier. Representation of non-ASCII
214 character sets in local-part strings is limited to the standard
215 methods provided as extensions to RFC 822[1]
217 2.2.1 Address Resolution
219 A client determines the address of an appropriate system running a
220 server by resolving the destination domain name that is part of the
221 identifier to either an intermediate relay system or a final target
222 system.
224 Only resolvable, fully-qualified, domain names (FQDNs) are permitted
225 when domain names are used in the messaging service (i.e., domain
226 names that can be resolved to SRV[9] or A RRs).
228 2.2.1.1 Domain Name Lookup
230 A client lexically identifies a domain to which instant messages will
231 be delivered for processing, a DNS lookup MUST be performed to
232 resolve the domain[2]. The names MUST be fully-qualified domain names
233 (FQDNs) �� mechanisms for inferring FQDNs from partial names or local
234 aliases are a local matter.
236 The lookup first attempts to locate SRV RRs associated with the
237 domain. If a CNAME RR is found instead, the resulting domain is
238 processed as if it were the initial domain.
240 If one or more SRV RRs are found for a given domain, a sender MUST
241 NOT utilize any A RRs associated with that domain unless they are
242 located using the SRV RRs; otherwise, if no SRV RRs are found, but an
243 A RR is found, then the A RR is treated as if it was associated with
244 an implicit SRV RR, with a preference of 0, pointing to that host.
246 2.2.1.2 Processing SRV RRs
248 To process an IM URI, a lookup is performed for SRVs for the target
249 domain and a desired IM transport protocol.
251 For example, if the destination INSTANT INBOX is
252 "im:fred@example.com", and the sender wishes to use an IM transport
253 protocol called "SIP", then a SRV lookup is performed for:
255 _im._sip.example.com.
257 The returned RRs, if any, specify the next-hop server.
259 The choice of IM transport protocol is a local configuration option
260 for each system.
262 Using this mechanism, seamless routing of IM traffic is possible,
263 regardless of whether a gateway is necessary for interoperation. To
264 achieve this transparency, a seperate RR for a gateway must be
265 present for each transport protocol and domain pair that it serves.
267 2.2.1.3 Processing Multiple Addresses
269 When the lookup succeeds, the mapping can result in a list of
270 alternative delivery addresses rather than a single address, because
271 of multiple SRV records, multihoming, or both. For reliable
272 operations, the client MUST be able to try each of the relevant
273 addresses in this list in order, until a delivery attempt succeeds.
274 However, there MAY also be a configurable limit on the number of
275 alternate addresses that can be tried. In any case, the client SHOULD
276 try at least two addresses. Two types of information are used to rank
277 the host addresses: multiple SRV records, and multihomed hosts.
279 Multiple SRV records contain a preference indication that MUST be
280 used in sorting. Lower numbers are preferrable to higher ones. If
281 there are multiple destinations with the same preference, and there
282 is no clear reason to favor one (e.g., by recognition of an easily-
283 reached address), then the sender MUST randomize them to spread the
284 load across multiple servers for a specific destination.
286 The destination host (perhaps taken from the preferred SRV record)
287 may be multihomed, in which case the resolver will return a list of
288 alternative IP addresses. It is the responsibility of the resolver to
289 have ordered this list by decreasing preference if necessary, and the
290 sender MUST try them in the order presented.
292 2.3 Format of Instant Messages
294 An INSTANT MESSAGE comprises a MIME Multipart/Related,
295 Type=message/RFC822+XML object, as defined in XML/MIME[5].
296 Representation of non-ASCII character sets in MIME is a standard
297 feature of MIME.
299 Note that the IETF provides numerous technologies that allow end-
300 users to exchange authenticated and private messages formatted as
301 MIME objects, c.f., PGP-MIME[4] and S/MIME[6].
303 2.4 The Messaging Service
305 Section 6 and Section 7 define the abstract syntax of the operations
306 invoked with the service.
308 Note that the transaction-identifier parameters used with the service
309 are potentially long-lived. Accordingly, the values of transaction-
310 identifiers should appear to be unpredictable.
312 2.4.1 The Message Operation
314 When an application wants to send an INSTANT MESSAGE, it invokes the
315 message operation.
317 The message operation has these parameters:
319 o the source parameter specifies the INSTANT INBOX on whose behalf
320 this message is sent (using an IM URI);
322 o the destination parameter specifies the INSTANT INBOX that the
323 message should be delivered to (using an IM URI);
325 o the transID parameter specifies the transaction-identifier
326 associated with this operation; and,
328 o the message to be sent.
330 When the service is informed of the message operation, it performs
331 these steps:
333 1. If the source or destination does not refer to a valid INSTANT
334 INBOX, a response operation having status "failure" is invoked.
336 2. If access control does not permit the application to request this
337 operation, a response operation having status "failure" is
338 invoked.
340 3. Otherwise:
342 1. If the service is able to successfully deliver the message, a
343 response operation having status "success" is invoked.
345 2. If the service is unable to successfully deliver the message,
346 a response operation having status "failure" is invoked.
348 3. If the service must delegate responsibility for delivery, and
349 if the delegation will not result in a future authoritative
350 indication to the service, a response operation having status
351 "indeterminant" is invoked.
353 4. If the service must delegate responsibility for delivery, and
354 if the delegation will result in a future authoritative
355 indication to the service, then a response operation is
356 invoked immediately after the indication is received.
358 When the service invokes the response operation, the transID
359 parameter is identical to the value found in the message operation
360 invoked by the application.
362 2.4.2 Looping
364 The dynamic routing of instant messages can result in looping of a
365 message through a relay. Detection of loops is not always obvious,
366 since aliasing and group list expansions can legitimately cause a
367 message to pass through a relay more than one time.
369 [[[ In Internet Mail, counting the number of Received headers is the
370 accepted technique for guessing that looping is occurring. Use of
371 this technique will require Instant Messaging to support Received
372 headers. /editor ]]]
374 3. Abstract Presence Service
376 3.1 Overview of the Presence Service
378 When an application wants to (periodically) receive the presence
379 information associated with a PRESENTITY, it invokes the subscribe
380 operation, e.g.,
382 +-------+ +-------+
383 | | | |
384 | appl. | -- subscribe ----> | pres. |
385 | | | svc. |
386 +-------+ +-------+
388
392 The service immediately responds by invoking the response operation
393 containing the same transaction-identifier, e.g.,
395 +-------+ +-------+
396 | | | |
397 | appl. | <----- response -- | pres. |
398 | | | svc. |
399 +-------+ +-------+
401
403 A WATCHER may have at most one subscription for a PRESENTITY.
405 If the response operation indicates success, the service immediate
406 invokes the notify operation to communicate the presence information
407 to the WATCHER, e.g.,
409 +-------+ +-------+
410 | | | |
411 | appl. | <------- notify -- | pres. |
412 | | | svc. |
413 +-------+ +-------+
415
418
419
421
422
424 If the duration parameter is non-zero, then for up to the specified
425 duration, the service invokes the notify operation whenever there are
426 any changes to the PRESENTITY's presence information. Otherwise,
427 exactly one notify operation is invoked, achieving a one time poll of
428 the presence information. Regardless, there is no application
429 response to the notify operation (i.e., the application does not
430 invoke a response operation when a notify operation occurs).
432 The application may prematurely cancel a subscription by invoking the
433 unsubscribe operation, e.g.,
435 +-------+ +-------+
436 | | | |
437 | appl. | -- unsubscribe --> | pres. |
438 | | | svc. |
439 +-------+ +-------+
441
445 The service immediately responds by invoking the response operation
446 containing the same transaction-identifier, e.g.,
448 +-------+ +-------+
449 | | | |
450 | appl. | <----- response -- | pres. |
451 | | | svc. |
452 +-------+ +-------+
454
456 3.2 Identification of PRESENTITIES
458 A PRESENTITY is specified using the PRES URI (Section 5.2) scheme.
459 Briefly, the "addr-spec" syntax of RFC 822[1] (i.e., "local@domain")
460 is used, where the local-part MUST be interpreted and assigned
461 semantics only by the host specified in the domain part of the
462 identifier. Representation of non-ASCII character sets in local-part
463 strings is limited to the standard methods provided as extensions to
464 RFC 822[1]
466 To resolve identifiers associated with the Presence service, the
467 mechanism defined in Section 2.2.1 is used, except that the
468 processing of a PRES URI is performed by looking up SRV RRs for a
469 desired presence transport protocol.
471 For example, if the destination PRESENTITY is
472 "pres:fred@example.com", and the sender wishes to use a presence
473 transport protocol called "PEPP", then a SRV lookup is performed for:
475 _pres._pepp.example.com.
477 3.3 Format of Presence Information
479 Section 9 defines the syntax for presence information using an XML
480 DTD.
482 Each PRESENTITY's presence information contains an "entityInfo"
483 attribute, and contains one or more "tuple" elements:
485 o the "entityInfo" attribute specifies arbitrary information about
486 the PRESENTITY (using a URI); and,
488 o each "tuple" element specifies information associated with the
489 PRESENTITY.
491 Each "tuple" element has a "destination" attribute, a "status"
492 attribute, and contains arbitrary content:
494 o the "destination" attribute specifies a URI;
496 o the "status" attribute is either OPEN or CLOSED; and,
498 o the content of the "tuple" element contains arbitrary information
499 about the tuple.
501 3.4 The Presence Service
503 Section 6 and Section 8 define the abstract syntax of the operations
504 invoked with the service.
506 An implementation of the service must maintain information about both
507 presence information and in-progress operations in persistent
508 storage.
510 Note that the transaction-identifier parameter used with the service
511 is potentially long-lived. Accordingly, the values generated for this
512 parameter should appear to be unpredictable.
514 3.4.1 The Subscribe Operation
516 When an application wants to (periodically) receive the presence
517 information associated with an PRESENTITY, it invokes the subscribe
518 operation.
520 The subscribe operation has these parameters:
522 o the watcher parameter specifies the WATCHER associated with the
523 subscription;
525 o the target parameter specifies the PRESENTITY associated with the
526 presence information;
528 o the duration parameter specifies the maximum number of seconds
529 that the SUBSCRIPTION should be active; and,
531 o the transID parameter specifies the transaction-identifier
532 associated with this operation.
534 When the service is informed of the subscribe operation, it performs
535 these steps:
537 1. If the watcher or target parameter does not refer to a valid
538 PRESENTITY, a response operation having status "failure" is
539 invoked.
541 2. If access control does not permit the application to request this
542 operation, a response operation having status "failure" is
543 invoked.
545 3. If the duration parameter is non-zero, and if the watcher and
546 target parameters refer to an in-progress subscribe operation for
547 the application, a response operation having status "failure" is
548 invoked.
550 4. Otherwise:
552 1. A response operation having status "success" is immediately
553 invoked. (If the service chooses a different duration for the
554 subscription then it conveys this information in the response
555 operation.)
557 2. A notify operation, corresponding to the target's presence
558 information, is immediately invoked for the watcher.
560 3. For up to the amount of time indicated by the duration
561 parameter, if the target's presence information changes, and
562 if access control allows, a notify operation is invoked for
563 the watcher.
565 Note that if the duration parameter is zero-valued, then the
566 subscribe operation is making a one-time poll of the presence
567 information. Accordingly, Step 4.3 above does not occur.
569 When the service invokes a response operation as a result of this
570 processing, the transID parameter is identical to the value found in
571 the subscribe operation invoked by the application.
573 3.4.2 The Notify Operation
575 The service invokes the notify operation whenever the presence
576 information associated with a PRESENTITY changes and there are
577 subscribers to that information.
579 The notify operation has these parameters:
581 o the watcher parameter specifies the WATCHER associated with the
582 subscription;
584 o the target parameter specifies the PRESENTITY associated with the
585 presence information;
587 o the transID parameter specifies the transaction-identifier
588 associated with this operation; and,
590 o the presence information for the PRESENTITY.
592 There is no application response to the notify operation.
594 3.4.3 The Unsubscribe Operation
596 When an application wants to terminate a subscription, it invokes the
597 unsubscribe operation.
599 The unsubscribe operations has these parameters:
601 o the watcher parameter specifies the WATCHER associated with the
602 subscription;
604 o the target parameter specifies the PRESENTITY associated with the
605 presence information; and,
607 o the transID parameter specifies the transaction-identifier
608 associated with this operation.
610 When the service is informed of the unsubscribe operation, it
611 performs these steps:
613 1. If the watcher and target parameters do not refer to an in-
614 progress subscribe operation for the application, a response
615 operation having status "failure" is invoked.
617 2. Otherwise, the in-progress subscribe operation for the
618 application is terminated, and a response operation having status
619 "success" is invoked by the service.
621 Note that following a successful unsubscribe operation, the WATCHER
622 may receive further notifications. Although the service will no
623 longer invoke the notify operation after successfully processing a
624 unsubscribe operation, earlier notify operations may still be in
625 progress.
627 4. Security Considerations
629 This memo makes no specific requirements on security procedures for
630 interoperation between IM systems. Accordingly, trust between
631 interconnected IM systems is determined in a bilateral matter.
633 However this memo does require that each IM system control access to
634 its Instant Messaging and Presence services. Consult both RFC 2778
635 and RFC2779 for a discussion of security considerations for for IM
636 systems.
638 4.1 Threats
640 Attacks, of concern for instant messaging, include access, deletion,
641 insertion, reordering and modification of messages by unauthorized
642 principals. Replay is a combination of a subset of these attacks.
644 These attacks can take place in the communication links between
645 sending client and its server, between two servers, between the
646 receiving client and its server, or by attacking any of the hosts
647 involved. This document, not being concerned with client-server
648 interchanges, only addresses threats aimed at server-server
649 communication.
651 Countermeasures against unauthorized access are encrypted
652 communication and encrypted messages.
654 Countermeasures against insertion of false messages are
655 authentication and authorization of sending servers and strongly
656 signed messages.
658 Countermeasures against reordered messages are date-stamped or
659 serial-numbered messages, coupled with digital signatures that
660 include the date or serial number, if modification is not otherwise
661 guarded against.
663 Countermeasures against replayed messages are date stamps and unique
664 message IDs, coupled with digital signatures that include the date or
665 serial number, if modification is not otherwise guarded against.
667 Countermeasures against deletion of messages are integrity-protected
668 connections between servers where the server's identity is verified.
669 Serial-numbered messages can also be useful in detecting deleted
670 messages.
672 Attacks that target the server hosts rather than the communication
673 channels can successfully defeat all countermeasures that depend on
674 host security. Digital signatures and encrypted messages do not
675 depend on host security, for intermediate systems, but cannot by
676 themselves guard against deletion or reordering of messages.
678 For presence, the attacks include giving presence information to
679 unauthorized watchers, not reporting watcher information back to a
680 presentity, and insertion, modification, deletion and replay of
681 presence update messages. The same set of countermeasures are
682 relevant.
684 Instant messaging and presence systems can provide security at two
685 levels: hop-by-hop and/or end-to-end.
687 4.2 Hop-by-hop security
689 A useful but imperfect level of security can be provided on a hop-by-
690 hop basis, with all aspects of the communication including message
691 content and originator verification, using transport level security
692 between servers. The main drawback of this approach is that it
693 requires that each server that handles message or presence
694 information must be trusted. But it is relatively easy to deploy,
695 because it depends only on bilateral arrangements between directly
696 communicating servers.
698 The underlying principles for using hop-by-hop security are:
700 (a) each server and/or domain must keep their own house in order,
701 ensuring that operations and information accesses are allowed only to
702 appropriately authorized parties, and
704 (b) each server and/or domain must make its own choices about the
705 levels of trust to be established to any other server and/or domain
706 with which they directly communicate. [[[Some debate about the degree
707 of trust necessary between servers. /dc]]]
709 When passing IM and presence information between services using
710 different protocols, a gateway system MUST be capable of using
711 security mechanisms appropriate to each of the protocols concerned,
712 and must have access to keys needed to authenticate any other system
713 with which it needs to directly communicate in a secure fashion.
715 [[[SUGGESTION: to allow the use of common keys across different
716 protocols, we might say that hop-by-hop security should be based on
717 SASL, and specify specific profiles that should be used. This
718 doesn't buy anything at the protocol level, but it might make it
719 easier to leverage some common key-distribution infrastructure, and
720 avoid having to distribute different keys for communicating with a
721 gateway using different protocols.]]]
723 4.3 End-to-end security
725 End-to-end security is widely regarded as being more satisfactory
726 than hop-by-hop security, as the need to trust intermediate parties
727 is reduced. However, some aspects of end-to-end security are
728 difficult to achieve because they need bilateral arrangement between
729 any pair of communicating parties about acceptable security standards
730 to use, and key exchange. Reliance on bilateral agreements does not
731 scale well. A moderating alernative is a third-party certification
732 service and this approach, so far, has not found large-scale use.
734 The two IETF standards for end-to-end MIME object security are
735 OpenPGP[7] and S/MIME[8]. They require a public key operation for
736 each message. For repeated, short transactions, this overhead can be
737 onerous. A version of these specifications which permited re-use of
738 the public key across multiple messages would greatly reduce instant
739 messaging overhead.
741 4.3.1 Instant messages
743 End to end security for instant messages can be provided using any of
744 the MIME-based security mechanisms (S/MIME [8], OpenPGP [7]), as
745 instant message payload content is not interpreted or reformatted in
746 transit.
748 [[[NOTE: may need to say something about allowable MIME C-T-Es?]]]
750 This specification allows any pair of communicating parties to use
751 any MIME-based security framework for instant messages (c.f. section
752 2.3), but mechanisms for establishing the required bilateral
753 arrangements and key exchange are not specified here.
755 4.3.2 Presence service
757 The situation regarding end-to-end security for presence services is
758 unclear, as there is no common encapsulation framework specified for
759 presence, and the presence data itself is not invariant across
760 different IM services.
762 [[[NOTE: this raises a case for fixing the presence information to a
763 specific format if end-to-end security capability is to be a
764 requirement.]]]
766 5. IANA Considerations
768 The IANA assigns the "im" and "pres" URL schemes.
770 5.1 The IM URI Scheme
772 The Instant Messaging (IM) URI scheme designates an Internet
773 resource, namely an INSTANT INBOX.
775 The syntax of an IM URL has the form:
777 "im:" addr-spec
779 where "addr-spec" is defined in RFC 822.
781 5.2 The PRES URI Scheme
783 The Presence (PRES) URI scheme designates an Internet resource,
784 namely a PRESENTITY or WATCHER.
786 The syntax of a PRES URL has the form:
788 "pres:" addr-spec
790 where "addr-spec" is defined in RFC 822.
792 6. The Common Service DTD
794
803
820
821
822
823
824
827
828
835 7. The Messaging Service DTD
837
846
848 %IMCOMMON;
849
856
857
860
861
867 8. The Presence Service DTD
869
878
880 %IMCOMMON;
881
888
889
892
893
896
897
901
904
905
911
914
915
920
923
924
930 9. The Presence Information DTD
932
942
945 %IMCOMMON;
947
954
955
958
959
963
964
969 References
971 [1] Crocker, D., "Standard for the format of ARPA Internet text
972 messages", RFC 822, STD 11, Aug 1982.
974 [2] Mockapetris, P.V., "Domain names - concepts and facilities",
975 RFC 1034, STD 13, Nov 1987.
977 [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
978 Extensions (MIME) Part One: Format of Internet Message Bodies",
979 RFC 2045, November 1996.
981 [4] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP
982 Message Format", RFC 2440, November 1998.
984 [5] Klyne, G., "XML coding of RFC822 messages", I-D draft-klyne-
985 message-rfc822-xml-00.txt, November 2000.
987 [6] Ramsdell, B., "S/MIME Version 3 Certificate Handling", RFC
988 2632, June 1999.
990 [7] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
991 Instant Messaging", RFC 2778, February 2000.
993 [8] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
994 Presence Protocol Requirements", RFC 2779, February 2000.
996 [9] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
997 specifying the location of services (DNS SRV)", RFC 2782,
998 February 2000.
1000 [10] Allocchio, C., "GSTN Address Element Extensions in E-mail
1001 Services", RFC 2846, June 2000.
1003 Authors' Addresses
1005 Dave Crocker
1006 Brandenburg Consulting
1007 675 Spruce Drive
1008 Sunnyvale, CA 94086
1009 US
1011 Phone: +1 408 246 8253
1012 EMail: dcrocker@dcrocker.net
1013 Athanassios Diacakis
1014 Network Projects Inc.
1015 4516 Henry Street
1016 Suite 113
1017 Pittsburgh, PA 15213
1018 US
1020 Phone: +1 412 681 6950 x202
1021 EMail: thanos@networkprojects.com
1023 Florencio Mazzoldi
1024 Network Projects Inc.
1025 4516 Henry Street
1026 Suite 113
1027 Pittsburgh, PA 15213
1028 US
1030 Phone: +1 412 681 6950
1031 EMail: flo@networkprojects.com
1033 Christian Huitema
1034 Microsoft Corporation
1035 One Microsoft Way
1036 Redmond, WA 98052-6399
1037 US
1039 EMail: huitema@microsoft.com
1041 Graham Klyne
1042 Content Technologies
1043 Henley Business Centre, Newtown Road
1044 Oxfordshire RG9 1HG
1045 UK
1047 Phone: +44 118 930-1300
1048 EMail: GK@Dial.pipex.com
1049 Marshall Rose
1050 Invisible Worlds
1051 1179 North McDowell Boulevard
1052 Petaluma 94954-655
1053 US
1055 Phone: +1 916-483-8878
1056 EMail: mrose@dbc.mtview.ca.us
1058 Jonathan Rosenberg
1059 dynamicsoft
1060 200 Executive Drive
1061 Suite 120
1062 West Orange, NJ 07052
1063 US
1065 EMail: jdrosen@dynamicsoft.com
1067 Robert Sparks
1068 dynamicsoft
1069 200 Executive Drive
1070 Suite 120
1071 West Orange, NJ 07052
1072 US
1074 EMail: rsparks@dynamicsoft.com
1076 Hiroyasu Sugano
1077 Fujitsu Laboratories Ltd.
1078 64 Nishiwaki, Ohkubo-cho
1079 Akashi 674-8555
1080 JP
1082 EMail: suga@flab.fujitsu.co.jp
1084 Appendix A. IM URL IANA Registration Template
1086 This section provides the information to register the im: instant
1087 messaging URL.
1089 A.1 URL scheme name
1091 im
1093 A.2 URL scheme syntax
1095 The syntax replicates the existing mailto: URL syntax specified in
1096 RFC2368. The ABNF is:
1097 IM-URL = "im:" [ to ] [ headers ]
1098 to = #mailbox
1099 headers = "?" header *( "&" header )
1100 header = hname "=" hvalue
1101 hname = *urlc
1102 hvalue = *urlc
1104 A.3 Character encoding considerations
1106 Representation of non-ASCII character sets in local-part strings is
1107 limited to the standard methods provided as extensions to RFC 822[1]
1109 A.4 Intended usage
1111 Use of the im: URL follows closely usage of the mailto: URL. That is,
1112 invocation of an IM URL will cause the user's instant messaging
1113 application to start, with destination address and message headers
1114 fill-in according to the information supplied in the URL.
1116 A.5 Applications and/or protocols which use this URL scheme name
1118 It is anticipated that protocols compliant with RFC2779, and meeting
1119 the interoperability requirements specified here, will make use of
1120 this URL scheme name.
1122 A.6 Interoperability considerations
1124 The underlying exchange protocol used to send an instant message may
1125 vary from service to service. Therefore complete, Internet-scale
1126 interoperability cannot be guaranteed. However, a service conforming
1127 to this specification permits gateways to achieve interoperability
1128 sufficient to the requirements of RFC2779.
1130 A.7 Security considerations
1132 When IM URLs are placed in instant messaging protocols, they convey
1133 the identity of the sender and/or the recipient. In some cases,
1134 anonymous messaging may be desired. Such a capability is beyond the
1135 scope of this specification.
1137 A.8 Relevant publications
1139 RFC2779, RFC2778
1141 A.9 Person & email address to contact for further information
1143 Dave Crocker
1145 A.10 Author/Change controller
1147 This scheme is registered under the IETF tree. As such, IETF
1148 maintains change control.
1150 A.11 Applications and/or protocols which use this URL scheme name
1152 Instant messaging service; presence service
1154 Appendix B. PRES URL IANA Registration Template
1156 This section provides the information to register the pres: presence
1157 URL .
1159 B.1 URL scheme name
1161 pres
1163 B.2 URL scheme syntax
1165 The syntax replicates the existing mailto: URL syntax specified in
1166 RFC2368. The ABNF is:
1167 PRES-URL = "pres:" [ to ] [ headers ]
1168 to = #mailbox
1169 headers = "?" header *( "&" header )
1170 header = hname "=" hvalue
1171 hname = *urlc
1172 hvalue = *urlc
1174 B.3 Character encoding considerations
1176 Representation of non-ASCII character sets in local-part strings is
1177 limited to the standard methods provided as extensions to RFC 822[1]
1179 B.4 Intended usage
1181 Use of the pres: URL follows closely usage of the mailto: URL. That
1182 is, invocation of an PRES URL will cause the user's instant messaging
1183 application to start, with destination address and message headers
1184 fill-in according to the information supplied in the URL.
1186 B.5 Applications and/or protocols which use this URL scheme name
1188 It is anticipated that protocols compliant with RFC2779, and meeting
1189 the interoperability requirements specified here, will make use of
1190 this URL scheme name.
1192 B.6 Interoperability considerations
1194 The underlying exchange protocol used for presence may vary from
1195 service to service. Therefore complete, Internet-scale
1196 interoperability cannot be guaranteed. However, a service conforming
1197 to this specification permits gateways to achieve interoperability
1198 sufficient to the requirements of RFC2779.
1200 B.7 Security considerations
1202 When PRES URLs are placed in presence protocols, they convey the
1203 identity of the sender and/or the recipient. In some cases, anonymous
1204 messaging may be desired. Such a capability is beyond the scope of
1205 this specification.
1207 B.8 Relevant publications
1209 RFC2779, RFC2778
1211 B.9 Person & email address to contact for further information
1213 Dave Crocker
1215 B.10 Author/Change controller
1217 This scheme is registered under the IETF tree. As such, IETF
1218 maintains change control.
1220 B.11 Applications and/or protocols which use this URL scheme name
1222 Instant messaging service; presence service
1224 Appendix C. Issues of Interest
1226 This appendix briefly discusses issues that may be of interest when
1227 designing an interoperation gateway.
1229 C.1 Address Mapping
1231 When mapping the service described in this memo, mappings which place
1232 special information into the im: address local-part MUST use the
1233 meta-syntax defined in RFC 2486[10].
1235 C.1.1 Source-Route Mapping
1237 The easiest mapping technique is a form of source-routing and usually
1238 is the least friendly to humans having to type the string. Source-
1239 routing also has a history of operational problems.
1241 Use of source-routing for exchanges between different services is by
1242 a transformation that places the entire, original address string
1243 into the im: address local part and names the gateway in the domain
1244 part.
1246 For example, if the destination INSTANT INBOX is
1247 "pepp://example.com/fred", then, after performing the necessary
1248 character conversions, the resulting mapping is:
1250 im:pepp=example.com/fred@relay-domain
1252 where "relay-domain" is derived from local configuration information.
1254 Experience shows that it is vastly preferrable to hide this mapping
1255 from end-users �� if possible, the mapping should be performed
1256 automatically by the underlying software.
1258 Full Copyright Statement
1260 Copyright (C) The Internet Society (2000). All Rights Reserved.
1262 This document and translations of it may be copied and furnished to
1263 others, and derivative works that comment on or otherwise explain it
1264 or assist in its implementation may be prepared, copied, published
1265 and distributed, in whole or in part, without restriction of any
1266 kind, provided that the above copyright notice and this paragraph are
1267 included on all such copies and derivative works. However, this
1268 document itself may not be modified in any way, such as by removing
1269 the copyright notice or references to the Internet Society or other
1270 Internet organizations, except as needed for the purpose of
1271 developing Internet standards in which case the procedures for
1272 copyrights defined in the Internet Standards process must be
1273 followed, or as required to translate it into languages other than
1274 English.
1276 The limited permissions granted above are perpetual and will not be
1277 revoked by the Internet Society or its successors or assigns.
1279 This document and the information contained herein is provided on an
1280 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1281 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1282 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1283 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1284 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1286 Acknowledgement
1288 Funding for the RFC Editor function is currently provided by the
1289 Internet Society.