idnits 2.17.1 draft-day-rpim-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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) 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 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. == 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 175 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 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 74: '...4.1 A client MUST be able to communica...' RFC 2119 keyword, line 78: '...4.2 All clients MUST implement some co...' RFC 2119 keyword, line 81: '... presence format MUST include a means ...' RFC 2119 keyword, line 85: '... presence format MUST include a means ...' RFC 2119 keyword, line 89: '... presence format MUST include a means ...' (16 more instances...) 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) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Mark Day 2 Expires: September 13, 1998 Lotus Development Corporation 4 Requirements for Presence and Instant Messaging 6 draft-day-rpim-00.txt 8 1. Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 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 19 "work in progress." 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 25 Coast), or ftp.isi.edu (US West Coast). 27 2. Abstract 29 This document is an alternative approach to defining the requirements 30 for a presence information protocol. It may be usefully compared and 31 contrasted with "Presence Information Protocol Requirements" by Lisa 32 Dusseault, draft-dusseault-pipr-00.txt. Although worthy in many 33 respects, that document includes numerous desiderata, design 34 considerations, and implementation concerns. This document attempts 35 to define only requirements, and a minimal set of requirements at 36 that. In addition, this document treats "presence" and "instant 37 messaging" as distinct entities for the purpose of defining 38 requirements. We leave open the possibility of a single protocol 39 fulfilling both sets of requirements, without requiring it. 41 3. Introduction 43 A presence information protocol provides a means for clients to find, 44 retrieve, and be notified of changes in the presence information of 45 others. Presence information is information exposed by a client to 46 indicate the presence or availability of a person or resource. 48 An instant messaging protocol provides a means for clients to deliver 49 small, simple messages to other clients. Instant messaging is similar 50 to email, but instant messages are not stored for later 51 delivery. Instant messages are intended only as a lightweight 52 conversation and rendezvous mechanisms for persons or systems, 53 exchanging information that may be used to set up heavier-weight 54 mechanisms for conversation or sharing. 56 Presence information and instant messaging are distinct but 57 interdependent. When user A knows that user B is available, it is 58 useful for A to be able to initiate a conversation with B, building on 59 the information and service already shared by both 60 parties. Correspondingly, when A is preparing to send a message to B, 61 it is useful to know whether B is present and able to receive an 62 instant message. If B is not available, A may not send a message, may 63 send the message via email, or may compose a different message via a 64 different medium. 66 This document describes the requirements for a presence protocol and 67 an instant messaging protocol. Although these are described as 68 requirements on separate protocols, there is no requirement that they 69 be separate. The requirements may be satisfied by a single combined 70 protocol. 72 4. Requirements for a Presence Information Protocol 74 4.1 A client MUST be able to communicate its presence information, 75 either directly or via intermediaries such as servers, to other 76 clients. 78 4.2 All clients MUST implement some common presence format for 79 presence information. 81 4.3 The common presence format MUST include a means to represent an 82 individual name (a personal name in the case of a person), and 83 organizational or other disambiguating information. 85 4.4 The common presence format MUST include a means to represent 86 contact information, such as email address, telephone number, postal 87 address, or the like. 89 4.5 The common presence format MUST include a means to represent at 90 least the following conditions: active, inactive, unavailable, do not 91 disturb. 93 4.6 There MUST be a means of extending the common presence format to 94 represent additional information not included in the common format, 95 without undermining or rendering invalid the fields of the common 96 format. 98 4.7 A client MUST be able to indicate its interest in the presence 99 information of other clients, even when those other clients are not 100 available or not reachable. 102 4.8 When a client changes its presence information, and another client 103 has indicated interest in the presence information of that client, the 104 interested client MUST receive the changed information rapidly enough 105 that the delay is not objectionable. For most applications, this 106 implies a delay of no more than a few seconds. 108 4.9 The protocol MUST provide a means so that a client receiving an 109 update can be confident that it represents the correct presence 110 information (that is, it has not been corrupted or delayed). 112 4.10 The protocol MUST provide a means so that a client receiving an 113 update can be confident that it represents the presence information of 114 the client claimed (that is, it has not been forged). 116 4.11 The protocol MUST provide a means for changing presence 117 information automatically in circumstances such as broken network 118 connections, which cannot be anticipated by a client providing its 119 presence information. 121 5. Requirements for an Instant Messaging Protocol 123 5.1 A client MUST be able to communicate an instant message, either 124 directly or via intermediaries such as servers, to other clients. 126 5.2 All clients MUST implement some common message format for instant 127 messages. 129 5.3 The common message format MUST include a means to represent a 130 recipient's individual name (a personal name in the case of a person), 131 and organizational or other disambiguating information. 133 5.4 The common message format MUST include enough information to allow 134 the receiver to send an instant message as a reply. 136 5.5 The common message format MUST include a MIME-encoded body. 138 5.6 The protocol MUST make visible to the sender whether the instant 139 message was successfully received. Successful receipt means only that 140 the message was transmitted to an entity on the receiving machine 141 responsible for displaying it, not that the message was actually read 142 by a user. 144 5.7 The transport of instant messages MUST be sufficiently rapid to 145 allow for comfortable conversational exchanges of short messages. For 146 most applications, this means that the time to deliver a message 147 can be no more than a second or two. 149 5.8 The protocol MUST provide a means so that a client receiving a 150 message can be confident that it represents the message as recently 151 sent (that is, it has not been corrupted or delayed). 153 5.9 The protocol MUST provide a means so that a client receiving a 154 message can be confident that it represents the message sent by the 155 client claimed (that is, it has not been forged). 157 5.10 The protocol MUST provide a means for a client to send a message 158 with an encrypted body to another client, so that both parties can 159 have confidence that no other party is able to read the body. 161 6. Author's Address 163 Mark Day 164 Lotus Development Corporation 165 55 Cambridge Parkway 166 Cambridge, MA 02142 167 USA 169 Mark_Day@lotus.com