[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 draft-ietf-simple-messaging-requirements

SIMPLE                                                      J. Rosenberg
Internet-Draft                                               dynamicsoft
Expires: August 12, 2004                               February 12, 2004


   Advanced Instant Messaging Requirements for the Session Initiation
                             Protocol (SIP)
            draft-rosenberg-simple-messaging-requirements-01

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 12, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   This specification defines a set of requirements for new capabilities
   for instant messaging in SIP-based systems.













Rosenberg               Expires August 12, 2004                 [Page 1]


Internet-Draft              IM Requirements                February 2004


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Delivery Status Reporting  . . . . . . . . . . . . . . . . . .  4
   3.  Is-Composing . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Content Capabilities . . . . . . . . . . . . . . . . . . . . .  9
   5.  Page-Mode Groups . . . . . . . . . . . . . . . . . . . . . . . 10
   5.1 Invitations to Non-Real-Time Sessions  . . . . . . . . . . . . 10
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
       Informative References . . . . . . . . . . . . . . . . . . . . 15
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16
       Intellectual Property and Copyright Statements . . . . . . . . 17





































Rosenberg               Expires August 12, 2004                 [Page 2]


Internet-Draft              IM Requirements                February 2004


1. Introduction

   The Session Initiation Protocol (SIP) defines several specifications
   that support Instant Messaging (IM). The SIP MESSAGE method [2]
   allows for "page-mode" messaging, offering a service similar to Short
   Message Service (SMS) in wireless networks. A more advanced
   capability, called session mode messaging, uses the SIP INVITE method
   to establish a session whose media type is messaging [8]. This allows
   for many SIP capabilities to be directly applied to instant
   messaging, such as conferencing [9].

   However, there are many additional features that exist in current,
   proprietary IM systems. Some of these features do not require
   protocol extensions in order to be deployed (IM message archival, for
   example). However, others do.

   This specification provides requirements for a number of advanced IM
   features which require additional standardization activity to
   support. It does not cover features which can be achieved with
   existing protocols and specifications. It is also limited to instant
   messaging only, and does not consider presence [5].






























Rosenberg               Expires August 12, 2004                 [Page 3]


Internet-Draft              IM Requirements                February 2004


2. Delivery Status Reporting

   In most cases, an IM is delivered immediately to the recipient.
   Indeed, this is the principal motivation behind the "Instant" in
   "Instant Messaging". However, in many systems, and instant message
   can be sent even when the recipient is not available. Indeed, even if
   they are available when the message is sent, the user may log off
   before the message can be delivered.

   Typically, this is dealt with through a combination of two features.
   The first is message archival and retrieval. These features allow the
   intended recipient to retrieve their messages at a later time. To
   support this, the receiving domain stores the content of the IM,
   allowing the user to fetch it later. In this regard, it is very
   similar to existing email systems. Existing protocols, such as IMAP4
   [7], can be used for the retrieval functions of IM [[Note - is there
   any need for an "IM" profile for IMAP, similar to the "voice" profile
   for IMAP as specified in RFC 2421 [6]?]].

   The second feature is message delivery confirmation. This feature
   allows the sender to know that the receiver has received the message.
   This feature exists in SMS and in email [10]. A similar function is
   needed for IP-based instant messaging. Indeed, it is provided in
   several commercial IM systems, including Wireless Village.

   Certainly, much of the email specifications for message delivery
   confirmation can be reused for IM. However, much of it is
   email-specific, and IM introduces some new requirements. The
   following requirements apply to IM delivery status notifications:

      REQ-DELNOT-1: It MUST be possible for the sender of an IM to
      request a delivery notification.

      REQ-DELNOT-2: It MUST be possible for the sender of an IM to learn
      immediately that a delivery notification will, or will not, be
      sent.

      REQ-DELNOT-3: It MUST be possible for the delivery notification to
      be sent at an arbitrary time in the future.

      REQ-DELNOT-4: The delivery notification MUST be capable of
      indicating that the message was delivered to the intended target.

      REQ-DELNOT-5: The delivery notification MUST be capable of
      indicating whether the message was delivered successfully, or
      whether, when it was delivered, the recipient genreated an error.
      It MUST be possible for the sender to learn the specific error
      condition.



Rosenberg               Expires August 12, 2004                 [Page 4]


Internet-Draft              IM Requirements                February 2004


      REQ-DELNOT-6: The delivery notification MUST indicate the time of
      message delivery.

      REQ-DELNOT-7: The delivery notification MUST indicate the specific
      message which was delivered.

      REQ-DELNOT-9: In order to support interaction conversations where
      the sender can re-type their message if it is not received, the
      delivery notifications MUST be sent rapidly when the message can
      be immediately delivered. In this case, rapidly is loosely
      defined, but generally, fast enough to support an interactive
      conversation.

      REQ-DELNOT-10: It MUST be possible for the message sender (the
      recipient of the notification) to authenticate the sender of the
      notification. There is no explicit requirement for confidentialy
      of the notification.

      REQ-DELNOT-11: As it is anticipated that this mechanism will be
      used frequently from wireless devices, it SHOULD keep overhead to
      a minimum, and in particular, SHOULD NOT provide extraneous
      information not relevant to the above requirements.

      REQ-DELNOT-12: When an IM is sent to a group, there MUST be
      delivery notifications generated about the delivery of the IM to
      each group participant.

      REQ-DELNOT-13: REQ-DELNOT-12 MUST support recursive groups.

      REQ-DELNOT-14: The identity of the ultimate recipient MUST be made
      known to the message sender.

      REQ-DELNOT-16: Any error condition reported by the notification
      MAY contain a textual description of the error meant for human
      consumption [[EDITORS NOTE: Do we need this?]]

      REQ-DELNOT-17: If an IM is being relayed through a gateway, for
      example, to SMS, the delivery report SHOULD indicate such a
      condition [[EDITORS NOTE: Do we need this?]]

      REQ-DELNOT-18: The delivery notification MUST indicate the
      Content-Type of the message that was delivered.

      REQ-DELNOT-19: The delivery notification MUST indicate the
      Content-Length of the message that was delivered.






Rosenberg               Expires August 12, 2004                 [Page 5]


Internet-Draft              IM Requirements                February 2004


      REQ-DELNOT-20: The delivery notification MUST indicate the To
      header field from the message that was delivered.

      REQ-DELNOT-21: The delivery notification MUST indicate the Expires
      header field of the message that was delivered.














































Rosenberg               Expires August 12, 2004                 [Page 6]


Internet-Draft              IM Requirements                February 2004


3. Is-Composing

   Many commercial instant messaging and presence systems provide a
   feature generally referred to as "is-typing". This feature is used
   during instant messaging chat sessions. Whenever one user is in the
   process of typing a message to another user, the recipient-to-be can
   see that a message is in progress. This avoids a common problem where
   both participants are typing replies at the same time, so that the
   resulting stream of converation is not well synchronized.

   Generalizing this concept, the idea is really to allow one
   participant to inform another participant that they are composing a
   message of some type. By conveying a type, a broader set of features
   can be enabled. For example, if one user indicates that they are
   composing a message of type audio/basic, the other user will know
   that a voice IM is coming.

      REQ-COMP-1: The is-composing feature must work with instant
      messaging sessions [8].

      REQ-COMP-2: Either side in the session should be able to indicate
      that they can receive the indicators. The indicators must not be
      sent from A to B if B does not explicitly indicate that they can
      receive them.

      REQ-COMP-3: It must be possible for indicators to be sent in only
      one direction, i.e., A sends them to B, but B does not send them
      to A.

      REQ-COMP-4: It must be possible for usage of the indicators to be
      added or removed to any IM session after the session has begun.

      REQ-COMP-5: The indicator must be able to inform the recipient
      that the sender has begun composing a message.

      REQ-COMP-6: The indicator must be able to inform the recipient
      that the sender has stopped composing a message.

      REQ-COMP-7: The indicator must be able to convey the MIME type of
      the message that is being composed.

      REQ-COMP-8: The indicator must be able to convey the
      content-disposition of the message that is being composed. [Do we
      want this requirement?]

      REQ-COMP-9: The indicator must be synchrnonized with the message
      stream itself. That is, if a recipient gets an indicator that a
      user has stopped composing a message, and they also get a message,



Rosenberg               Expires August 12, 2004                 [Page 7]


Internet-Draft              IM Requirements                February 2004


      the recipient must be able to know which came first.

      REQ-COMP-10: It must be possible to provide end-to-end message
      integrity and authentication over the indicators.

      REQ-COMP-11: It must be possible to associate the is-composing
      indicator with a particular instant messaging session.

      REQ-COMP-12: It should be possible to interwork is-composing
      indicators between CPIM compliant systems, possibly with some loss
      of functionality, but with integrity and authentication in tact.

      REQ-COMP-13: It should be possible for is-composing indicators to
      work, possibly with loss of functionality, in page mode. [Do we
      want this requirement?]

      REQ-COMP-14: The is-composing indicator should not result in an
      increase on the load of proxies.

      REQ-COMP-15: It must be possible to receive delivery confirmation
      reports for is-composing indicators [Do we need this requirement?]

      REQ-COMP-16: The overhead of the indicators should be minimal.




























Rosenberg               Expires August 12, 2004                 [Page 8]


Internet-Draft              IM Requirements                February 2004


4. Content Capabilities

   Although traditionally used with text, an IM can contain any kind of
   content. There is an increasing trend to send multimedia content,
   including audio, video, and even applications, over IM. However,
   recipients may not wish to receive content that they do not
   understand, or is over a particular size limit.

   Handling these "content capabilities" is done differently for page
   mode and session mode. In session mode, the initial offer/answer
   exchange [3] can be used to convey content capabilities. Indeed, the
   messaging sessions mechanism allows for negotiation of supported
   content types. However, some additional aspects of negotiation are
   required:

      REQ-CONTENT-1: A UA MUST be able to indicate the maximum message
      size it is willing to receive.

   In page mode messaging, a 413 response can be sent if a MESSAGE
   request is too large. However, there is no way to indicate what the
   largest allowed size is:

      REQ-CONTENT-2: A 413 response MUST be capable of indicating the
      maximum allowed message size.

   Note that, there is no requirement to support transcoding of content
   at an intermediary in order to reduce the size of a sent message to
   match that of a recipient.























Rosenberg               Expires August 12, 2004                 [Page 9]


Internet-Draft              IM Requirements                February 2004


5. Page-Mode Groups

   There is no explicit support for groups in page mode. Supporting
   groups in session mode is trivial, and is completely handled through
   the SIP conferencing specifications [9]. While there is no
   expectations that the same level of features will be available in
   page mode conferencing as session mode, some minimal features are
   desirable.

      REQ-GROUP-1: It MUST be possible to address a page-mode IM to a
      group.

      REQ-GROUP-2: Each recipient of a group page IM MUST be capable of
      determining the set of other recipients that got the request.

      REQ-GROUP-3: It MUST be possible for a user to send to an ad-hoc
      group, where the identities of the recipients are carried in the
      message itself.

      REQ-GROUP-4: It MUST be possible for the recipient of a group IM
      to send a message to all other participants that received the same
      group IM (i.e., Reply-To-All).

   [[Editors NOTE: It is not clear at all that we want to support any of
   this. Session mode provides a much more comprehensive conferencing
   story. Do we really want to add features for page mode??]]

5.1 Invitations to Non-Real-Time Sessions

   SIP fundamentally deals with real-time sessions. That is, it allows
   users to invite other users to communicate using some kind of
   interactive media. However, there are many other types of "sessions",
   in the broad sense of the word, that one can be invited to. As an
   example, one user could invite another user to join an email mailing
   list, to join a conference call occuring next week, or to view a web
   site.

   Specific desired capabilities are:

      REQ-NRT-1: It MUST be possible to send a user a message requesting
      that they perform some specific action.

      REQ-NRT-2: The set of possible actions MUST include the ability to
      request that a user add another user to their buddy list.

      REQ-NRT-3: The set of possible actions MUST include the ability to
      request the user to join a meeting scheduled at a specific time.




Rosenberg               Expires August 12, 2004                [Page 10]


Internet-Draft              IM Requirements                February 2004


      REQ-NRT-4: The set of possible actions MUST include the ability to
      request the user to view a certain URL.

      REQ-NRT-5: The set of possible actions MUST include the ability to
      request the user to join a specific group (such as a page-mode
      group IM list).

      REQ-NRT-6: The set of actions MUST be easily extensible.

      REQ-NRT-7: It MUST be possible for the sender to cancel the
      request, i.e., ask that the user not bother to perform the
      previous requested action. Of course, there is no expectation that
      the request is honored, and no way to enforce it. The only
      requirement is the ability to convey this desire.

      REQ-NRT-8: It MUST be possible for the sender to learn when the
      recipient has performed the desired action.

      REQ-NRT-9: It MUST be possible for the sender to learn that the
      recipient has received the request to perform the desired action.

      REQ-NRT-10: It MUST be possible for the recipient to indicate that
      they accept the invitation, reject it, or will defer it (consider
      it later).

      REQ-NRT-11: It MUST be possible for REQ-NRT-10, REQ-NRT-9 and
      REQ-NRT-8 to occur at an arbitrarily long period of time after the
      invitation was issued.

      REQ-NRT-12: The set of actions MUST include the ability to ask a
      user to initiate a Push-To-Talk session.

   This capability is a hybrid between a traditional SIP INVITE and a
   SIP MESSAGE. It is like INVITE in that it is accepted or rejected,
   and can be cancelled. It is not like INVITE in that the acceptances
   or rejections can come at any time, even days after the invitation.
   In that sense, it is more like a MESSAGE.














Rosenberg               Expires August 12, 2004                [Page 11]


Internet-Draft              IM Requirements                February 2004


6. IANA Considerations

   There are no IANA Considerations associated with this specification.
















































Rosenberg               Expires August 12, 2004                [Page 12]


Internet-Draft              IM Requirements                February 2004


7. Security Considerations

   Security requirements are discussed above where relevant.
















































Rosenberg               Expires August 12, 2004                [Page 13]


Internet-Draft              IM Requirements                February 2004


8. Acknowledgments

   This draft includes requirements contributed by Aki Niemi [11].
















































Rosenberg               Expires August 12, 2004                [Page 14]


Internet-Draft              IM Requirements                February 2004


Informative References

   [1]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

   [2]   Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and
         D. Gurle, "Session Initiation Protocol (SIP) Extension for
         Instant Messaging", RFC 3428, December 2002.

   [3]   Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
         Session Description Protocol (SDP)", RFC 3264, June 2002.

   [4]   Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "Instant
         Messaging / Presence Protocol Requirements", RFC 2779, February
         2000.

   [5]   Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
         Instant Messaging", RFC 2778, February 2000.

   [6]   Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail
         - version 2", RFC 2421, September 1998.

   [7]   Crispin, M., "Internet Message Access Protocol - Version
         4rev1", RFC 2060, December 1996.

   [8]   Campbell, B., "Instant Message Sessions in SIMPLE",
         draft-ietf-simple-message-sessions-03 (work in progress),
         January 2004.

   [9]   Rosenberg, J., "A Framework for Conferencing with the Session
         Initiation Protocol",
         draft-ietf-sipping-conferencing-framework-01 (work in
         progress), October 2003.

   [10]  Moore, K. and G. Vaudreuil, "An Extensible Message Format for
         Delivery Status Notifications", RFC 3464, January 2003.

   [11]  Niemi, A., "Requirements for Instant Messaging in 3GPP Wireless
         Systems", draft-niemi-simple-im-wireless-reqs-02 (work in
         progress), October 2003.










Rosenberg               Expires August 12, 2004                [Page 15]


Internet-Draft              IM Requirements                February 2004


Author's Address

   Jonathan Rosenberg
   dynamicsoft
   600 Lanidex Plaza
   Parsippany, NJ  07054
   US

   Phone: +1 973 952-5000
   EMail: jdrosen@dynamicsoft.com
   URI:   http://www.jdrosen.net








































Rosenberg               Expires August 12, 2004                [Page 16]


Internet-Draft              IM Requirements                February 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2004). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Rosenberg               Expires August 12, 2004                [Page 17]


Internet-Draft              IM Requirements                February 2004


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Rosenberg               Expires August 12, 2004                [Page 18]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/