idnits 2.17.00 (12 Aug 2021) /tmp/idnits39789/draft-hudson-impp-arch-01.txt: ** The Abstract section seems to be numbered 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 250 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 39 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'Model' on line 242 looks like a reference -- Missing reference section? 'Reqts' on line 246 looks like a reference -- Missing reference section? 'RFC 1034' on line 238 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Greg Hudson 2 Expires: June 2, 2000 ghudson@mit.edu 3 MIT 5 Instant Messaging / Presence Architecture 6 draft-hudson-impp-arch-01.txt 8 1. Status of this Memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Please send comments to the IMPP working group at impp@iastate.edu. 30 2. Abstract 32 This document proposes an architecture for the protocols to be 33 produced by the IMPP working group. 35 3. Terminology 37 The following terms are defined in [Model] and are used with those 38 definitions in this document: 40 ACCESS RULES 41 FETCH 42 INSTANT INBOX 43 INSTANT MESSAGE 44 INSTANT MESSAGE SERVICE 45 NOTIFICATIONS 46 PRESENCE INFORMATION 47 PRESENCE SERVICE 48 PRESENTITY 49 SENDER 50 SUBSCRIPTION 51 WATCHER 52 WATCHER INFORMATION 54 The following terms are defined in [Reqts] and are used with those 55 definitions in this document: 57 DOMAIN 58 IDENTIFIER 60 The following terms are defined here: 62 An ENTITY is a PRESENTITY or WATCHER participating in the PRESENCE 63 SERVICE, or a SENDER or INSTANT INBOX participating in the INSTANT 64 MESSAGE SERVICE. 66 A PRESENCE CLIENT is a network endpoint communicating as a PRESENTITY 67 and WATCHER with the same IDENTIFIER. It may choose to exercise the 68 functions of only one role. 70 An INSTANT MESSAGE CLIENT is a network endpoint communicating as a 71 SENDER and INSTANT INBOX with the same IDENTIFIER. It may choose to 72 exercise the functions of only one role. 74 A CLIENT is either a PRESENCE CLIENT or INSTANT MESSAGE CLIENT. 76 [XXX open issue: these definitions assume that presence and instant 77 messaging will take place over separate wire protocols (separate TCP 78 connections, separate well-known ports, etc.). If we decide they 79 should take place over one wire protocol, it would make more sense to 80 define just "CLIENT" which can communicate as any of the four.] 82 4. Basic Principles 84 Each ENTITY has an IDENTITIFIER which contains a DOMAIN part and a 85 locally assigned part. The DOMAIN part names a domain within the 86 Domain Name Service [RFC 1034]. 88 [XXX open issue: does an IDENTIFIER also contain a resource name or 89 some other kind of text which does not affect the identity of the 90 ENTITY? Does an IDENTIFIER contain a service name? These issues don't 91 really affect the rest of the architecture but they certainly live 92 above the actual wire protocol specifications and so belong in this 93 document.] 95 Each DOMAIN has one or more SERVERS implementing that DOMAIN's part of 96 the INSTANT MESSAGE SERVICE or PRESENCE SERVICE. If a DOMAIN has more 97 than one SERVER for one of the two services, a party communicating 98 with that domain will pick one of the SERVERS and talk to it; the 99 collection of SERVERS must ensure that the other party achieves the 100 same result communicating with any SERVER. The protocol for 101 communication between SERVERS within a DOMAIN is not specified by the 102 IMPP suite. 104 [XXX open issue: Is server synchronization within a domain our 105 problem, or do we let the creators of server farms develop their own 106 algorithms? Does the same server-server protocol for inter-domain 107 traffic also apply to servers within a single domain? There are some 108 mildly hard issues not covered by the inter-domain server-server 109 protocol, e.g. if there are a hundred servers for my domain and you 110 don't connect to the one which has my client connection IMs, how does 111 the other server keep track of where to forward your IM request to? I 112 think it's not our problem, personally; it's not important that I be 113 able to put together a server farm consisting of servers from multiple 114 different vendors, so if different vendors' server farms synchronize 115 using proprietary protocols, that's not a big deal. And since 116 synchronization is a tricky issue, perhaps it's better to let people 117 innovate rather than trying to solve it within a standards body.] 119 A CLIENT speaks to one of the SERVERS for the DOMAIN part of its 120 ENTITIES' IDENTIFIER. The SERVER may establish the authenticity of 121 the CLIENT connection to the local policy of the DOMAIN and will 122 forward requests to and from the SERVERS of other DOMAINS as 123 necessary. Thus, a request such as an instant message transmission 124 which travels from CLIENT 1 in DOMAIN X to CLIENT 2 in a different 125 DOMAIN Y will travel as follows: 127 CLIENT 1 -> DOMAIN X SERVER 128 | 129 V 130 CLIENT 2 <- DOMAIN Y SERVER 132 If CLIENT 1 and CLIENT 2 are in the same domain, the communication 133 path is simpler: 135 CLIENT 1 -> DOMAIN X SERVER -> CLIENT 2 137 If a DOMAIN has multiple servers, it may be necessary to forward some 138 requests between servers within a domain. Such forwarding is not 139 shown in the diagrams above because it is not in the scope of this 140 architecture. [XXX affected by the previous open issue about server 141 synchronization within a domain.] 143 NOTE: The protocol suite might be more flexible if it 144 specified ways for CLIENT A to communicate directly 145 with SERVER B or with CLIENT B. But the rigid 146 arrangement has three key advantages: 148 * A SERVER never has to worry about authenticating 149 ENTITIES from other DOMAINS. So each DOMAIN can use 150 its own authentication infrastructure without 151 concerning itself with the authentication 152 infrastructure of other DOMAINS. 154 * If many users from DOMAIN A are communicating with 155 resources in DOMAIN B, DOMAIN B only needs to 156 maintain one security context for all of DOMAIN A 157 and the setup of that security context may not need 158 to occur as often as it would if DOMAIN A's users 159 communicated directly with DOMAIN B. 161 * A SERVER may act as a gateway to a different 162 messaging service by using a nonstandard protocol to 163 communicate with CLIENTS, and this will be 164 transparent to CLIENTS from other DOMAINS. 166 Most scenarios which call for direct communication 167 (e.g. several laptops communicating over an ad-hoc 168 private network) can be accomodated by running a SERVER 169 on the same machine as one or more of the CLIENTS. It 170 may be necessary to use different IDENTIFIERS than one 171 ordinarily would in this kind of setup. 173 5. Protocols 175 The IMPP suite consists of two applications: instant messaging and 176 presence. The basic architecture divides communications into two 177 categories: communication between a CLIENT and a SERVER for its DOMAIN 178 and communication between SERVERS for two different DOMAINS. There 179 are therefore four different wire protocols in the suite. 181 [XXX open issue: are presence and instant messaging two different 182 protocols or the same protocol using different methods? Are 183 client-server and server-server communication different two different 184 protocols or the same protocol operating in two different modes? How 185 do we slice this pie? For now I'm assuming that we slice it finely, 186 because it's easier to combine than to separate.] 188 [XXX open issue: there is also communication between SERVERS within 189 the same DOMAIN, if we are going to tackle this issue, and potentially 190 communication involving proxies, something we haven't discussed in 191 much detail.] 193 5.1. Client-Server Presence Transfer Protocol 195 This protocol communicates presence and related data between a 196 PRESENCE CLIENT and a SERVER for its DOMAIN. The following kinds of 197 data may be transferred through this protocol: 199 * The PRESENTITY can publish PRESENCE INFORMATION and ACCESS 200 RULES to the SERVER. 202 * The WATCHER can FETCH or SUBSCRIBE to PRESENCE INFORMATION 203 for another PRESENTITY, and receive NOTIFICATIONS for 204 PRESENTITIES it has a SUBSCRIPTION to. 206 * The WATCHER can request WATCHER INFORMATION about the 207 PRESENTITY. 209 5.2. Server-Server Presence Transfer Protocol 211 This protocol allows a SERVER to forward presence and related data 212 from ENTITIES within its DOMAIN to a SERVER for another DOMAIN. Since 213 publishing PRESENCE INFORMATION and retrieving WATCHER INFORMATION 214 occur inside a domain, only one kind of data may be transferred 215 through this protocol: 217 * A FETCH or SUBSCRIPTION request or a NOTIFICATION may be 218 forwarded from one SERVER to another. 220 [XXX open issue: several people have suggested that the server-server 221 protocol should also be used for synchronization within a server farm 222 or for proxy servers. In this case, the full range of presence 223 operations would need to be supported.] 225 5.3. Client-Server Instant Message Transfer Protocol 227 This protocol allows an INSTANT MESSAGE CLIENT to transfer INSTANT 228 MESSAGES from and to a SERVER for its DOMAIN. 230 5.4. Server-Server Instant Message Transfer Protocol 232 This protocol allows a SERVER for one DOMAIN to transfer INSTANT 233 MESSAGES on behalf of one of its SENDERS to a SERVER for another 234 DOMAIN, for delivery to an INSTANT INBOX in the other DOMAIN. 236 6. References 238 [RFC 1034] 239 P. V. Mockapetris. "Domain names - concepts and facilities." RFC 240 1034, November 1987. 242 [Model] 243 M. Day, J. Rosenberg, H. Sugano. "A Model for Presence." Work in 244 progress, draft-ietf-impp-model-03.txt. 246 [Reqts] 247 M. Day, S. Aggarwal, G. Mohr, J. Vincent. "Instant Message / Presence 248 Protocol Requirements." Work in progress, 249 draft-ietf-impp-reqts-03.txt.