idnits 2.17.1 draft-dusseault-pipr-00.txt: ** The Abstract section seems to be numbered -(45): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(72): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(198): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(271): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(272): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(312): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(347): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(452): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(497): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(621): 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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 22 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 4) being 83 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.) ** There are 151 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 248: '... Users MUST be able to protec...' RFC 2119 keyword, line 257: '... Users MUST be able to set ac...' RFC 2119 keyword, line 263: '... Users MUST be able to block ...' RFC 2119 keyword, line 266: '...f blocked parties and MUST block them....' RFC 2119 keyword, line 268: '... Users MUST be able to specif...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 22 has weird spacing: '...listing conta...' == Line 205 has weird spacing: '...minimum who c...' -- 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? '1' on line 629 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Calsyn & Dusseault 3 Expires: August 1998 Microsoft Corporation 5 Presence Information Protocol Requirements 6 draft-dusseault-pipr-00.txt 8 1. Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are 11 working documents of the Internet Engineering Task Force (IETF), 12 its areas, and its working groups. Note that other groups may 13 also distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as "work 19 in progress." 21 To learn the current status of any Internet-Draft, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ds.internic.net (US East Coast), 24 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 25 munnari.oz.au (Pacific Rim). 27 2. Abstract 29 Online users have demonstrated a desire to know instantly whether 30 another individual is online, to be notified when another 31 individual arrives online, and to send instant messages. These 32 applications currently use independent, non-standard and usually 33 non-interoperable protocols. The goal is to define a standard 34 protocol so that independently written client and server 35 implementations can participate in a global network of ''online'' 36 users. 38 This draft outlines requirements for a Presence Information 39 Protocol to support these applications. 41 Distribution of this document is unlimited. Please send comments 42 to the RVP discussion list at rvp@iastate.edu, which may be 43 joined by sending a message with subject ''subscribe'' to rvp- 44 request@iastate.edu. Archives of past messages are available. 45 Send the single word �help� to rvp-request@iastate.edu for more 46 information. 48 Calsyn & Dusseault 50 3. Contents 52 1. Status of this Memo........................................1 53 2. Abstract...................................................1 54 3. Contents...................................................2 55 4. Introduction...............................................3 56 4.1. Purpose of a Presence Information Protocol............3 57 4.2. Desired Characteristics...............................4 58 4.3. Definitions...........................................4 59 5. Detailed Requirements......................................5 60 5.1. Security Requirements.................................5 61 5.1.1. Confidentiality..................................5 62 5.1.2. Privacy..........................................5 63 5.1.3. Authentication...................................6 64 5.2. Addressing Requirements...............................6 65 5.2.1. Naming Format....................................6 66 5.2.2. Locating a Server................................7 67 5.3. Container Schema Requirements.........................7 68 5.3.1. User Schema Requirements.........................7 69 5.3.2. Group Schema Requirements........................7 70 5.4. Other Requirements....................................7 71 5.4.1. Control over peer-to-peer messaging..............7 72 5.4.2. Nature of �Instant� Messaging....................8 73 5.4.3. Media Types......................................8 74 5.4.4. Location Independence............................8 75 5.4.5. One to many or group messaging...................8 76 6. Goals......................................................9 77 6.1. Scalable..............................................9 78 6.2. Flexible..............................................9 79 6.3. Efficient.............................................9 80 7. Protocol Implementation Issues............................10 81 7.1. Transport-Protocol Neutral...........................10 82 7.2. Text-based...........................................10 83 7.3. Supports Versioning..................................10 84 7.4. Minimal State........................................10 85 7.5. Encryption...........................................10 86 7.6. Authentication.......................................10 87 7.7. Firewalls............................................11 88 7.8. Content types........................................11 89 8. Non-Goals.................................................11 90 8.1. Presence Information and Email.......................11 91 8.2. Presence Information and LDAP........................12 92 8.3. Peer-to-peer vs. client-to-server....................12 93 9. Discussion Group..........................................12 94 10. REFERENCES................................................12 95 11. Authors' Addresses........................................12 97 4. Introduction 99 4.1. Purpose of a Presence Information Protocol 101 Users want to know instantly when a friend or colleague logs on, 102 and to be able to send this acquaintance a quick message. The 103 desired functionality includes both the ability to subscribe to 104 instant notifications of remote events, such as a friend logging 105 on, and the ability to send instant messages to others. 107 Also note that in early discussions on the problem there has been 108 agreement that a client-only solution is not feasible. Users 109 wish to be notified when another user comes online. When the 110 target user is offline, there must be another entity responsible 111 for taking subscription requests. The protocol must specify how: 113 @ a client requests or subscribes to dynamic user status 114 information, 116 @ a server responds to queries and subscriptions, 118 @ a client sends instant messages, and 120 @ a server forwards instant messages to recipients. 122 Besides being able to subscribe to online status, users may also 123 be able to subscribe to other properties of users or properties 124 of non-user objects. 126 Users and administrators must be able to set access control 127 levels on queryable objects and properties. 129 Interest-based messaging, in which a user sends a message to a 130 group of individuals which share some characteristics, should be 131 supported by the protocol. This group of individuals or 132 aggregate entity may be handled by the server much like email 133 distribution lists. 135 Examples of existing presence information systems include: 137 @ Activerse�s �Ding!� 139 @ AOL�s �Instant Messenger� 141 @ IChat�s �IChat Pager� 143 @ Flash Communications�s �Flash Communicator� 145 @ Mirabilis�s �ICQ� 147 @ MSN�s �Friends Online� 149 @ PeopleLink�s �People Link� 151 4.2. Desired Characteristics 153 This section briefly outlines the desired characteristics of a 154 presence information system. Requirements and goals of the 155 protocol are discussed in more detail in sections 5 and 6. 157 Protocol Characteristics: 159 1. Can scale to support number of users on internet within 160 foreseeable future 162 2. Provides rich extensibility 164 3. Globally unique human-readable address can be assigned to a 165 user without consulting a central authority 167 4. Server is not required to store messages long-term 169 User Features: 171 5. Standard way to find the address of a user 173 6. Standard way to see if a user is online 175 7. Supports 1-to-1, 1-to-many and interest-classified messaging 177 8. Supports acknowledgements of received instant messages 179 9. Supports a subscription and notification model 181 10. Responsive: quick notifications of status changes 183 11. Provides maximum flexibility for message content 185 12. Supports media negotiation and session initiation: users can 186 switch to another application (server-based or peer-to-peer) 188 13. The target of subscriptions can list who initiated those 189 subscriptions 191 14. Supports non-humans on either end (or both) of a subscription, 192 query or message 194 15. Supports location independence 196 Security Features: 198 16. Supports �reverse-lookup� to find out who has asked for 199 information 201 17. Provides endpoint to endpoint security 203 18. Support firewall-friendly deployment 205 19. Supports access control, at minimum who can read or write to 206 any object, object property, or list of objects. 208 20. Allows users to maintain privacy by blocking others 210 4.3. Definitions 212 This specification uses a number of terms to refer to the roles 213 of participants and the kinds of messages passed between them. 215 Client: An application program that establishes connections to 216 the server for the purpose of registering to be online or 217 requesting information on another client or group. Clients may 218 or may not interact directly with a human user. 220 Server: A program that accepts connections from clients and that 221 is responsible for maintaining online/offline state. 223 Request: A request is a subscription to a property or a query 224 for a property value, or the setting of the property. 226 Response: A response is a message from a server to a client who 227 has made a query or who has an active subscription. 229 Subscription: A subscription is a request from a client to be 230 notified when a property changes or to receive all instant 231 messages on a channel. Commonly, a subscription from user A to 232 user B will be for the purpose of notifying user A when user B's 233 status changes to "online". 235 Property: Presence information and other information should 236 accessed as properties, or name/value pairs. 238 Property Container: A property container can represent a real- 239 world object which has properties queryable through the Presence 240 Information Protocol. - 242 5. Detailed Requirements 244 5.1. Security Requirements 246 5.1.1. Confidentiality 248 Users MUST be able to protect information about themselves. This 249 requirement should be considered met by a system which allows 250 users to set fine-grained access control levels on client or 251 server held objects and properties. 253 5.1.2. Privacy 255 Access Control 257 Users MUST be able to set access control flexibly for objects and 258 properties of objects. Read and write must be handled 259 separately. 261 Blocking 263 Users MUST be able to block all requests and messages from 264 specified parties. When a server is responsible for handling 265 requests or forwarding messages for a user container, the server 266 must know the list of blocked parties and MUST block them. 268 Users MUST be able to specify blocking lists using either 269 positive or negative blocking lists at their choice. That is, 270 the user MUST be able to state "I do not wish to receive messages 271 from anyone but the following users� and �I wish to receive 272 messages from anybody except the following�. This requirement is 273 necessary for good user experience with the protocol. 275 When a party is blocked, the protocol should not require that the 276 party be informed that they are blocked. Instead, the blocking 277 user could appear always offline to the blocked user. 279 Encryption 281 The content components of requests and responses MUST be capable 282 of being encrypted. 284 The protocol should support some mechanism to prevent an active 285 attacker from modifying or replaying messages and to prevent 286 repudiation. 288 5.1.3. Authentication 290 Clients should be able to issue authentication for their user and 291 should be able to verify credentials offered by other users. 292 Servers should likewise be able to generate and verify the 293 credentials of users and other servers. 295 Rather than mandate a particular security authority or mandate 296 signing or sealing in any form, the successful proposal for a 297 protocol should allow for optional inclusion of credentials, 298 keys, signatures and encryption. 300 5.2. Addressing Requirements 302 Property containers and properties MUST be identifiable by one or 303 more unambiguous names. The namespace for containers and 304 properties should be federated (distributed across the network 305 and with no central management structure). 307 URI naming would meet the above stated requirements. 309 There MUST NOT be a requirement for a central address-management 310 server. 312 User addresses SHOULD be closely linked to a user�s name. This 313 may require addresses to be represented in Unicode in order to 314 represent names which contain non-Latin characters. 316 5.2.1. Naming Format 318 There should be a naming format usable for this system. This 319 should be flexible enough so that the user entering a name into a 320 client can: 322 o Specify a property or a node 324 o Specify whether to query or subscribe to a property 325 o Include a password for access 327 5.2.2. Locating a Server 329 A name representing a property container or property in the PIP 330 namespace should be mappable to one or more servers capable of 331 answering requests targeted at that container or property. 333 5.3. Container Schema Requirements 335 The user container must have some standard properties so that 336 other users know which property to query to find the information 337 most commonly sought. Protocol designers may wish to define 338 schemas for the user container and possibly for other kinds of 339 containers. Schema proposals should be defined separately from 340 the protocol proposals. 342 5.3.1. User Schema Requirements 344 The schema for user containers should facilitate, at a minimum: 346 @ A property representing whether a user is online or offline. 347 Other status information (e.g., refining that into �busy�, 348 �do not disturb�, etc) is desirable. 350 @ A writable location for sending instant messages to a 351 recipient 353 @ Access control entries controlling who may view a user�s 354 status or send message content to the user. 356 Other properties may be desirable and might become part of a 357 successful draft for a PIP, but the above are sufficient for 358 basic PIP functionality. 360 5.3.2. Group Schema Requirements 362 Users should be able to query standard properties of a group to 363 obtain a list of current subscribers. Individual groups may deem 364 this information sensitive and the server may respond that access 365 to this information is denied. A successful PIP must also support 366 control over who may join a group and/or send messages to the 367 group. 369 5.4. Other Requirements 371 5.4.1. Control over peer-to-peer messaging 373 Many clients will wish to exchange messages peer-to-peer. While 374 there are security implications, this can greatly reduce load on 375 servers. The protocol should allow implementations that support 376 this kind of message exchange. The protocol should also allow 377 implementations that do not do this kind of message exchange. 379 5.4.2. Nature of �Instant� Messaging 381 In order for instant messaging to be real-time, the protocol must 382 not require clients to poll the server. Servers should be able 383 to notify the clients of instant messages. 385 5.4.3. Media Types 387 Content Types 389 The PIP should support many different types of content in instant 390 messages, such as images, sounds and formatted text. 392 Languages and Character Sets 394 The IETF mandates certain levels of internationalization in 395 protocols. 397 Streaming Media 399 It is not required for the protocol to support streaming media. 400 In general, instant messages should be brief and self-contained. 401 However, the protocol must be able to support invitation to a 402 streaming-media interaction. 404 Media Negotiation 406 Media Negotiation is the ability for clients to transmit 407 information on supported applications or protocols and use this 408 information to choose to enter a session together. This could be 409 a H.323-based or IRC-based session, peer-to-peer or client-to- 410 server, etc. 412 Users MUST be able to initiate sessions over other protocols. 413 Mandatory client-side support for SIP could be considered a 414 possible solution to this problem. This is an essential 415 usability feature and improves scalability/efficiency of the 416 presence information system by offloading some communication onto 417 other bands. 419 5.4.4. Location Independence 421 User may roam, using different clients on different machines in 422 different locations. However, it is desirable that users remain 423 identifiable with a persistent address, even when roaming. 425 The protocol MUST provide a mechanism such that a client can 426 access any machine on the network and be able to have messages 427 directed, on a temporary or permanent basis, from their normal 428 machine to this machine. This mechanism could be referral, 429 forwarding, proxying, or some combination of these or other 430 methods. 432 5.4.5. One to many or group messaging 433 The protocol must support the concept of groups or distribution 434 lists for one-to-many messaging. 436 There must be a way to find out who is receiving instant messages 437 in a group, although the server may respond that access to that 438 list is denied. 440 6. Goals 442 The following issues are of particular relevance to the creation 443 of a presence protocol and thus are listed to help the protocol 444 designers in making design choices. 446 6.1. Scalable 448 The protocol designers should keep in mind that it will be 449 desirable to accommodate most of the users on the Internet, plus 450 many non-user objects with dynamic data, in a federated presence 451 information system. While not all users of presence information 452 will be online at all times, many will want to keep a �ghost� 453 presence online even when offline. 455 In order to reduce load on servers, message duplication should be 456 avoided where possible. 458 6.2. Flexible 460 Flexible: the protocol should accommodate the design of presence 461 technology implementations with different goals. For example, 462 the protocol should accommodate the following variations 464 o a combined client and server 466 o different authentication schemes 468 o high-security server vs. low-security server 470 o additional dynamic properties 472 o different �schemas� in addition to a user schema 474 6.3. Efficient 476 Efficiency: the protocol SHOULD avoid message duplication when 477 possible. This can be done by allowing servers to single- 478 instance messages to another server which can fan out those 479 messages further. 481 Allowing peer-to-peer communication (both instant messaging and 482 requests/notifications) and session negotiation can make the 483 protocol more efficient by offloading some communication onto 484 other bands. 486 7. Protocol Implementation Issues 488 Although this section begins to stray into implementation 489 details, the authors wish to provide some recommendations on the 490 nature of the protocol. These recommendations are based on early 491 discussions on what kind of protocol would be best suited to the 492 task at hand. 494 7.1. Transport-Protocol Neutral 496 The protocol should able to utilize both UDP and TCP as transport 497 protocols. When TCP is used, users should be marked as �offline� 498 if the connection is dropped. When UDP is used, there must be 499 some way for users to periodically assert their presence online. 501 7.2. Text-based 503 The protocol should be text-based. This allows easy 504 implementation in languages such as Tcl and Perl, allows easy 505 debugging, and most importantly, makes the protocol flexible and 506 extensible. 508 7.3. Supports Versioning 510 There should be some way of exchanging protocol version 511 information. 513 7.4. Minimal State 515 In order to support a large number of users in some scenarios, 516 there should be very little state required by the protocol for 517 the server to maintain. 519 7.5. Encryption 521 Signing and sealing (encrypting) of protocol elements should use 522 the prevailing standards and be flexible enough to support as yet 523 unspecified new standards in this area. For instance, presuming 524 that MIME is used to encapsulate content, S/MIME should be 525 supported. SSL should be supported for encapsulating of the 526 entire transport stream. 528 7.6. Authentication 530 The protocol should facilitate the transport of credentials using 531 prevailing standards (e.g., MIME delivery of certificate 532 information, negotiation of common authentication providers, 533 etc). It is unclear at this time how much of this exchange 534 should occur in the transport and how much should occur within 535 the content components of a PIP protocol. 537 7.7. Firewalls 539 The protocol should take into account the broad presence of 540 firewalls, and the desirability for users to be able to exchange 541 instant messages and subscribe to properties from behind 542 firewalls. 544 The protocol should allow servers to proxy instant messages, 545 queries, subscriptions and responses in order to facilitate 546 server-side security and firewall security. 548 7.8. Content types 550 To accommodate rich and varied content components, the PIP SHOULD 551 support MIME as its content encapsulation format. This allows 552 arbitrary byte-pattern data to be sent, and includes common 553 formats such as plain text and HTML text. 555 MIME types destined for user clients MUST be transported through 556 servers unaltered. Clients SHOULD support some important MIME 557 types such as text and HTML-formatted text. Multipart- 558 alternative formats should be supported by clients to facilitate 559 the rendering of a single message by clients of differing 560 capabilities. 562 Clients will need to understand some basic MIME types in order 563 for users to communicate but need not support most or all. 565 8. Non-Goals 567 In order to make progress in a reasonable time, the designers of 568 a presence information protocol should avoid taking on problems 569 with too large a scope or problems which have been previously 570 solved. In the interest of preventing repetitive discussions on 571 these topics, they are outlined here. 573 8.1. Presence Information and Email 575 It is not a goal of this effort to replace email. While email 576 protocols offer some experience and features we can benefit from 577 when designing a system for instant messaging, we are not 578 interested in using an existing email protocol. 580 Some points of difference between instant messaging and email: 582 @ Instant messages cannot wait for the user to poll. 584 @ Instant messaging should have no requirement for the server to 585 store messages for unreachable or offline users. 587 @ Users need to be able to differentiate between their 588 asynchronous messages and their synchronous messages. Using 589 the same system would confound the two. 591 @ Notifications are meant to overwrite old state information 592 rather than add to it. Whereas an email model might work for 593 instant messages, it would be less applicable to notifications. 595 8.2. Presence Information and LDAP 597 It is not a goal of this effort to replace directory servers 598 which excel in presenting static data. LDAP also can offer us 599 some experience, ideas and has useful features, but LDAP is not 600 designed for dynamic data or for server-initiated sending of 601 data. LDAP also lacks the instant messaging functionality which 602 we require. 604 8.3. Peer-to-peer vs. client-to-server 606 It is not a goal of this effort to restrict communication to 607 either peer-to-peer the or the client-to-server model. Both 608 models must be supported. Servers are required in some settings 609 to proxy for users and to respond to requests for information on 610 offline users. Peer-to-peer communication is desirable in many 611 situations to avoid load on servers. 613 9. Discussion Group 615 A discussion group on Presence Information Protocols is 616 available. The authors welcome your participation in the shaping 617 of this draft and the several proposals for protocols in this 618 space. 620 You can join the discussion list by sending a message body 621 containing the single word �subscribe� (without the quotes) to 622 rvp-request@iastate.edu. Mail to the list recipients should be 623 sent to rvp@iastate.edu. Archives of past messages are 624 available. Send the single word �help� to rvp- 625 request@iastate.edu for more information. 627 10. REFERENCES 629 [1] S. Bradner, "Key words for use in RFCs to indicate 630 requirement levels," RFC 2119, Internet Engineering Task Force, 631 Mar. 1997. 633 11. Authors' Addresses 635 Martin R. Calsyn 636 Microsoft Corporation 637 One Microsoft Way 638 Redmond, WA 98052 640 Email: martinca@microsoft.com 642 Lisa Dusseault 643 Microsoft Corporation 644 One Microsoft Way 645 Redmond, WA 98052 647 EMail: lisadu@microsoft.com