idnits 2.17.00 (12 Aug 2021) /tmp/idnits38167/draft-hudson-impp-issues-00.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == 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 551 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 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. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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) == Outdated reference: draft-ietf-impp-model has been published as RFC 2778 ** Downref: Normative reference to an Informational draft: draft-ietf-impp-model (ref. 'Model') == Outdated reference: draft-ietf-impp-reqts has been published as RFC 2779 ** Downref: Normative reference to an Informational draft: draft-ietf-impp-reqts (ref. 'Reqts') == Outdated reference: draft-ietf-dnsind-rfc2052bis has been published as RFC 2782 -- Possible downref: Normative reference to a draft: ref. 'SPADE' -- No information found for draft-earthart-acp-spec - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ACP' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- Possible downref: Non-RFC (?) normative reference: ref. 'Binary XML' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML-namespace' ** Obsolete normative reference: RFC 821 (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1652 (Obsoleted by RFC 6152) ** Obsolete normative reference: RFC 2060 (Obsoleted by RFC 3501) ** Obsolete normative reference: RFC 2197 (Obsoleted by RFC 2920) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Downref: Normative reference to an Historic RFC: RFC 2311 ** Downref: Normative reference to an Historic RFC: RFC 2312 ** Obsolete normative reference: RFC 2518 (Obsoleted by RFC 4918) Summary: 19 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Greg Hudson 2 Expires: March 22, 1999 ghudson@mit.edu 3 MIT 5 Instant Messaging / Presence Protocol Design Issues 6 draft-hudson-impp-issues-00.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 describes design issues in the creation of the instant 33 messaging and presence protocols in the IMPP working group. The goal 34 is to objectively present arguments for and against the various 35 options on each issue. 37 3. Terminology 39 The following terms are defined in [Model] and are used with those 40 definitions in this document: 42 INSTANT INBOX 43 INSTANT MESSAGE 44 PRESENCE INFORMATION 45 PRESENTITY 46 SERVER 47 WATCHER 49 The following terms are defined in [Reqts] and are used with those 50 definitions in this document: 52 DOMAIN 53 IDENTIFIER 55 4. Form of IDENTIFIERS 57 An IDENTIFIER uniquely determines a PRESENTITY or INSTANT INBOX and is 58 intended for humans. It may never appear in its human-readable form 59 in the wire protocols or in the message format, but it is nevertheless 60 important that the protocols define what an IDENTIFIER is and means; 61 it would not do to have different clients using different text strings 62 as IDENTIFIERS. 64 The most obvious conception of an IDENTIFIER is a string containing 65 two parts: a DNS domain part, which identifies the messaging or 66 presence provider, and the username part, which gives the local name 67 assigned to a PRESENTITY or INSTANT INBOX by the provider. There are, 68 of course, other ways to identify a person than through their 69 provider's DNS domain, but since there exists no Internet directory 70 service with the reach of the DNS, choosing some other method would 71 present an undesirable barrier to entry for users. 73 All that remains is how to represent these two components in a string. 74 There are two obvious precedents to follow: email addresses and World 75 Wide Web URLs. The email address form would be "username@domain", 76 whereas the obvious URL form would be either "impp://domain/username", 77 or "im://domain/username" for messaging and 78 "presence://domain/username" for presence information. Naturally, 79 choosing the email address form would not preclude the existence of a 80 secondary URL form; along the lines of the "mailto" URL, we would 81 expect to see at least "imto:username@domain" and possibly 82 "presence:username@domain". 84 Two obvious advantages of the email address format are conciseness and 85 the possibility of having a single contact address for email, 86 messaging, and presence information. The obvious advantage of the URL 87 format is that it makes the protocol explicit, and it also yields the 88 possibility of having similar though not identical addresses for one's 89 home page and for messaging and presence information. 91 5. Server Selection 93 Once a DNS domain is known for a PRESENTITY or INSTANT INBOX, there 94 must be some process for determining what servers to contact for 95 messaging or presence. 97 On the very simple end of the spectrum, we can do a simple A record 98 lookup. This is how HTTP works, which is why the domain part of most 99 URLs looks like "www.zone" instead of just "zone" (where "zone" is the 100 actual administrative demarcation). In addition to resulting in 101 longer domains, this scheme makes it difficult for multiple servers to 102 handle the messaging and presence load for a domain. On the other 103 hand, a simple hostname lookup is much easier in most current 104 programming environments than lookups of other kinds of DNS records. 106 A SRV record lookup, as defined in [SRV], solves both of the above 107 problems, providing both a level of indirection and a mechanism for 108 selecting from a set of servers by priority and weight. If a SRV 109 record does not exist for the domain, falling back to an A record 110 lookup would lower the barriers to adoption by people who don't 111 control their machines' DNS information or whose DNS servers do not 112 support SRV. 114 6. Basic Transport 116 Whatever protocols become standardized will be implemented on some 117 transport layer, whether it is one of the core Internet protocols such 118 as TCP or UDP, or a higher-level protocol such as HTTP, SMTP, or LDAP. 119 The messaging and presence protocols may use different transports, and 120 it may be possible to implement either protocol on multiple 121 transports, but the design of the protocols will depend in large part 122 on the preferred transport layers. 124 UDP bears the advantage of being lightweight for certain operations. 125 Especially on Unix, where in-kernel state is required for TCP 126 connections, a UDP-based protocol might increase the amount of load a 127 messaging server can handle. However, there are a number of 128 arguments against UDP: 130 * Over the wide-area Internet, it is important that 131 communications between two end-points behave politely, which 132 requires keeping connection state. 134 * A simplistic UDP protocol can actually increase the number 135 of packets transmitted over the wire, by not allowing 136 multiple operations to be sent in a single packet. 138 * A UDP protocol lends itself to a "routing" type of protocol 139 where the server keeps very little state about the client. 140 But modern point-to-point security mechanisms may require 141 several packet exchanges at the beginning of a session and 142 require at least some state to be kept about the client 143 during the session. 145 * The UDP-based protocol could not be used for large messages 146 without reimplementing the TCP logic for window sizes and 147 message fragmentation. 149 * UDP-based protocols do not cooperate as well with firewalls 150 as TCP-based protocols do (assuming the TCP protocol uses 151 only client-initiated connections). 153 Assuming UDP is rejected, TCP becomes the natural substrate for a new 154 protocol. The "politeness" argument against a UDP protocol also 155 applies to a TCP protocol with many short-lived connections, so it is 156 important that the protocol allow multiple operations to take place 157 within a single connection. 159 But it is also possible to use a higher-level protocol for transport. 160 The arguments for using a higher-level protocol are found in the 161 features present in that protocol which would apply to instant 162 messaging or presence information. The main argument against using a 163 higher-level protocol is complexity; a new, tailored protocol using 164 only TCP will generally be simpler than a layered protocol, when 165 viewed as a whole. 167 Note that using a higher-level transport protocol does not imply using 168 its port number. 170 One common proposal is to use [RFC 821] (SMTP) as the transport layer 171 for instant messaging. As a messaging protocol, SMTP is at least 172 superficially a good fit, meaning it wouldn't impose much complexity 173 beyond what is actually necessary to support messaging. Here are 174 arguments against using SMTP: 176 * SMTP's wide deployment cannot be considered as an argument 177 in its favor. Existing implementations of SMTP center 178 around the assumption that incoming messages should be 179 written synchronously to disk and delivered to their 180 destination at leisure, which is not appropriate for instant 181 messaging. 183 * As a simple protocol, SMTP doesn't actually lend much 184 machinery to the problem. Reimplementing the machinery 185 provided by SMTP would not require a great deal of work or 186 involve a large number of pitfalls. 188 * SMTP has an arbitrary limit on line length, and it cannot 189 transmit messages which do not end in a newline. Thus, some 190 messages must be encoded purely because of protocol 191 limitations. 193 * As originally specified, SMTP operates in lock-step with 194 many round trips per message, and can only be used for 7-bit 195 ASCII messages. The use of the [RFC 2197] (PIPELINING) and 196 [RFC 1652] (8BITMIME) service extensions remedy these 197 limitations, but a new protocol would not force implementors 198 to understand these bits of history. 200 Another proposal is to use [RFC 2251] (LDAP) as the transport layer 201 for presence information. As a directory protocol, LDAP would seem to 202 be a good fit for presence information. Here are arguments against 203 using LDAP: 205 * As originally specified, LDAP only allows a client to fetch 206 directory information, not subscribe to changes in it. 207 Since most of the interesting part of presence lookup is in 208 subscribing, not fetching, that is a serious defect. A 209 proposed "persistent search" extension to LDAP (in an 210 expired draft) could be applied to presence subscriptions, 211 but as a much more general tool, it might be difficult to 212 implement efficiently and might complicate the retrieval of 213 watcher information. 215 * As an ASN.1-based protocol, LDAP is not as simple as a new 216 protocol could be. 218 Another proposal is to use [RFC 2518] (WebDAV) as the transport layer 219 for presence information. WebDAV is a set of HTTP extensions for 220 distributed authoring. With presence attributes treated as HTTP 221 documents, WebDAV would provide the machinery for getting, setting, or 222 listing presence attributes. It would still be necessary to design 223 extensions for subscription and notification of presence information 224 and to set access controls. The argument against WebDAV comes from 225 its complexity: the vast majority of the machinery of HTTP and the 226 WebDAV extensions is inapplicable to presence information. Moreover, 227 the parts of the presence protocol WebDAV handles are probably the 228 least complicated parts. 230 7. Protocol Command Encoding 232 Depending on the choice of transport protocol, it may be necessary to 233 choose how to encode protocol commands as bytes. There are many 234 desirable properties for encodings for protocol commands, many of 235 which contradict each other: 237 * Simplicity (ease of implementation) 238 * Compactness 239 * Readability (can see the data easily) 240 * Self-description (can understand the data easily) 241 * Extensibility where it might be required 242 * Generality (no arbitrary restrictions on content) 244 One option is to design our own encoding. Tools such as [RFC 2234] 245 (ABNF) or bit-packing diagrams (as used in [RFC 791]) can be used to 246 specify the encoding precisely. This option gives us the most 247 flexibility to make tradeoffs different ways in different places. 248 Arguments against designing our own encoding are: 250 * It is more work for us. (Although probably not more work 251 than arguing about what kind of encoding is best.) 253 * It is more work for the implementor if the implementor would 254 have otherwise been able to use a general tool to handle the 255 encoding part of the protocol. (It might be less work if 256 the implementor would have otherwise had to implement some 257 complicated general encoding specification, however.) 259 * It carries more pitfalls--we could accidentally introduce 260 cases where the same encoding could correspond to two pieces 261 of data, or cases where certain kinds of data cannot be 262 encoded. 264 Two likely proposals are [XML] or [Binary XML]. An XML encoding would 265 be readable and self-describing, but it has some drawbacks: 267 * The full range of XML is a fairly complicated piece of 268 machinery and is not trivial to decode. 270 * Although we can choose to ignore or disallow some of XML's 271 features such as attributes and processor instructions, an 272 implementor who chooses to use an existing XML library will 273 generally be confronted with those features in the process 274 of learning how to use the library. 276 * If we choose to disallow some of the more complicated 277 features of XML to make it easier to write a custom decoder, 278 designers of future extensions may be fooled into believing 279 that the full range of XML is fair game. 281 * In text form, XML is gratuitously verbose; an element 282 terminator does not need to include the name of the element 283 for readability either by humans or machines. This oddity 284 is due to XML's heritage in SGML, which allowed overlapping 285 elements. 287 Binary XML is a more rigid format and would be somewhat easier to 288 implement for someone lacking an appropriate XML library, but the 289 encoding would not be readable or self-describing. 291 Another proposal is [SPADE]. A SPADE protocol would be readable, 292 simple, and general, but not self-describing. Although it would not 293 be a binary encoding per se, it would be fairly close to a binary 294 encoding in spirit. 296 Another proposal is [ACP]. An ACP-based protocol would be readable, 297 fairly simple, general, and self-describing. It would be similar in 298 spirit to [RFC 2060] (IMAP), which is a text protocol. 300 8. Presence Information Format 302 We will need to choose a model and encoding for presence information. 304 One approach is to take a very minimal and restrictive attitude 305 towards presence information, mandating that it consists only of a 306 fixed set of simple fields, preferrably containing only information 307 which varies frequently. This approach has a certain appeal and would 308 make it easy to design a custom encoding for presence information, but 309 it might leave too many potential adopters unsatisified. 311 If the minimal approach is not taken, presence information will tend 312 to grow complicated and highly structured over time. The encoding of 313 presence information will have to take this need for structure into 314 account, so simple formats like a series of name-value pairs would be 315 inadequate. Writing a decoder for a format which can handle arbitrary 316 structured information starts to approach being a non-trivial problem, 317 so it makes sense to put more weight on comforming to a format which 318 has existing implementations. 320 Probably the most widely accepted such format is [XML]. The same 321 arguments which apply against XML for protocol commands also apply 322 against it here, of course. One new argument in favor of XML in this 323 realm is the applicability of [XML-namespace] to the problem of 324 multiple parties definining new presence fields. A piece of presence 325 information using heavily-constrained XML and namespaces might look 326 like: 328 329 330 online 331 In my office 332 work(333) 333-3333 333 335 Note that the URL "http://www.ietf.org/impp/schema" is merely a name; 336 [XML-namespace] does not require or ensure that there is a document 337 available at that URL describing the schema in any way. All of the 338 field names are examples only. 340 Another possible format is the structure format used by [ACP]. This 341 format is less verbose and would be less likely fool people into 342 designing extensions using attributes and processor instructions, but 343 is also less widely accepted and implemented. A piece of presence 344 information using this format might look something like: 346 ((STATUS "online") 347 (TEXTLOC "In my office") 348 (PHONE "(333) 333-3333" (TYPE "work"))) 350 The field name examples are given in uppercase merely to offset them 351 from the content. Note that ACP does not specify a way of associating 352 values with names, just formats for atoms, strings, numbers, and 353 parenthesized lists. Specifying how to create nested name-value pairs 354 from those units would be a task for us, albeit a simple one. There 355 is no namespace extension specified for use with ACP, although of 356 course nothing would prevent us from adapting the ideas of 357 [XML-namespace] to an ACP-based presence structure. 359 Another possible format is the Kerberos profile format, which is based 360 on Windows INI files. A piece of presence information using this 361 format might look like: 363 [presence] 364 status = online 365 textloc = In my office 366 phone = { 367 type = work 368 number = (333) 333-3333 369 } 371 Note one subtle limitation of this format: a variable such as "phone" 372 cannot have a text value in addition to sub-variables, so an existing 373 variable such as "textloc" cannot be annotated with sub-variables. 375 Independent of the encoding, there is a question of whether we model 376 presence information as a single document or as a collection of 377 records which can be subscribed to individually. The finer-grain 378 approach could result in both smaller notifications and fewer of them 379 when only one component of presence information changse; the 380 monolithic approach results in a simpler protocol. It is worth 381 considering whether the bandwidth which will be used by presence 382 notifications will be significant enough to warrant optimizations of 383 this sort. 385 9. Instant Message Format 387 We will need to choose a format for instant messages. The most 388 obvious option is to adopt [RFC 2045-2049] (MIME). As a message 389 specification, MIME is a perfect fit for the problem at hand and 390 provides a lot of machinery which would be difficult to recreate. The 391 drawbacks of MIME come from its history in [RFC 822]; that is, MIME is 392 somewhat more complicated than it could have been if it had no 393 existing practice to be backward compatible with. 395 Since we have no existing practice to be compatible with and 396 potentially no SMTP restrictions to be concerned about, we could also 397 attempt to modify MIME, perhaps reusing the header specifications but 398 encoding the headers or message body in a different way. This option 399 might yield a message format which can be more easily implemented from 400 scratch, or it might lead to a lot of confusion. 402 10. Security 404 So far there have been no concrete proposals for security, except for 405 one sample implementation which uses OpenPGP. The problem breaks down 406 into several parts: 408 * When a WATCHER requests PRESENCE INFORMATION, how can it 409 verify that it is receiving correct data from the authorized 410 SERVER and not something tampered with by a third party? 412 * When a WATCHER requests PRESENCE INFORMATION, how does it 413 authenticate to the SERVER? Likewise, when a PRESENTITY 414 requests a change in its PRESENCE INFORMATION, how does it 415 authenticate to the SERVER? 417 * How are INSTANT MESSAGES authenticated and encrypted? 419 Potential security proposals for each part could fall into one of 420 three categories: 422 * Users authenticate and encrypt directly with other users 423 ("end to end"). 425 * Users authenticate and encrypt only with their local 426 DOMAINS, and DOMAINS authenticate and encrypt to each other 427 ("domain-based"). 429 * Users authenticate and encrypt with local and foreign 430 DOMAINS ("hybrid"). 432 In the domain-based case, each part of the security problem breaks 433 down into two sub-parts (user authenticating with local DOMAIN, 434 DOMAINS authenticating with each other). 436 A domain-based security system has the advantage that local sites can 437 take advantage of any existing security infrastructure they might have 438 such as Kerberos. An end-to-end security system has the advantage 439 that the compromise of a SERVER might not lead to the immediate 440 compromise of user communications (although it could lead to the 441 compromise of newly exchanged keys), and it would allow users to 442 exchange keys through external channels if they do not wish to trust 443 one or the other user's DOMAIN. But an end-to-end security system 444 does not allow sites to reuse existing security infrastructure, and 445 requires users to keep more state about other users. 447 A hybrid security system would seem to have all of the disadvantages 448 listed above and none of the advantages. 450 Using a domain-based system would not, of course, prohibit users from 451 also using an end-to-end system such as [RFC 2311, RFC 2312] (S/MIME) 452 for instant messages. 454 Regardless of what type of security system is chosen, there are two 455 essentially unsolveable problems: 457 * There is currently no security hierarchy with the reach of 458 the Domain Name System. 460 * United States export controls prevent the development of a 461 secure implementation which can be used outside of the 462 United States. 464 These problems make it likely that many users will not be able to 465 communicate securely. 467 [Possibly helpful machinery: DNSSEC, TLS, OpenPGP, SASL, 468 GSSAPI/SPNEG0] 470 11. References 472 [Model] 473 M. Day, J. Rosenberg, H. Sagano. "A Model for Presence." Work in 474 progress, draft-ietf-impp-model-03.txt. 476 [Reqts] 477 M. Day, S. Aggarwal, G. Mohr, J. Vincent. "Instant Message / Presence 478 Protocol Requirements." Work in progress, 479 draft-ietf-impp-reqts-03.txt. 481 [SRV] 482 A. Gulbrandsen. "A DNS RR for specifying the location of services 483 (DNS SRV)." Work in progress, draft-ietf-dnsind-rfc2052bis-02.txt. 485 [SPADE] 486 G. Hudson. "Simple Protocol Application Data Encoding." Work in 487 progress, draft-hudson-spade-03.txt. 489 [ACP] 490 R. Earthart. "Application Core Protocol." Work in progress, 491 draft-earthart-acp-spec-00.txt. 493 [XML] 494 T. Bray, J. Paoli, C. M. Sperberg-McQueen. "Extensible Markup 495 Language (XML) 1.0." W3C Recommendation REC-xml-19980210, February 496 1998. 498 [Binary XML] 499 "WAP Binary XML Content Format". 500 http://www1.wapforum.org/what/technical/SPEC-WBXML-19990616.pdf 502 [XML-namespace] 503 T. Bray, D. Hollander, A. Layman. "Namespaces in XML." W3C 504 Recommendation REC-names-19990114, January 1999. 506 [RFC 791] 507 J. Postel. "Internet Protocol." RFC 791, September 1981. 509 [RFC 821] 510 J. Postel. "Simple Mail Transfer Protocol." RFC 821, August 1982. 512 [RFC 822] 513 D. Crocker. "Standard for the format of ARPA Internet text message." 514 RFC 822, August 1982. 516 [RFC 1652] 517 J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker. "SMTP 518 Service Extension for 8bit-MIMEtransport." RFC 1652, July 1994. 520 [RFC 2045-2049] 521 N. Freed, N. Borenstein. "Multipurpose Internet Mail Extensions 522 (MIME)." RFC 2045-2049, November 1996. 524 [RFC 2060] 525 M. Crispin. "Internet Message Access Protocol - Version 4rev1." RFC 526 2060, December 1996. 528 [RFC 2197] 529 N. Freed. "SMTP Service Extension for Command Pipelining." RFC 2197, 530 September 1997. 532 [RFC 2234] 533 D. Crocker, Ed., P. Overell. "Augmented BNF for Syntax 534 Specifications: ABNF." RFC 2234, November 1997. 536 [RFC 2251] 537 M. Wahl, T. Howes, S. Kille. "Lightweight Directory Access Protocol 538 (v3)." RFC 2251, December 1997. 540 [RFC 2311] 541 S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade, L. Repka. "S/MIME 542 Version 2 Message Specification." RFC 2311, March 1998. 544 [RFC 2312] 545 S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. "S/MIME Version 2 546 Certificate Handling." RFC 2312, March 1998. 548 [RFC 2518] 549 E. Whitehead, A. Faizi, S. Carter, D. Jensen. "HTTP Extensions for 550 Distributed Authoring." RFC 2518, February 1999.