doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc3428.txt b/doc/rfc/rfc3428.txt
new file mode 100644
index 0000000..65a7f2f
--- /dev/null
+++ b/doc/rfc/rfc3428.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                   B. Campbell, Ed.
+Request for Comments: 3428                                  J. Rosenberg
+Category: Standards Track                                    dynamicsoft
+                                                          H. Schulzrinne
+                                                     Columbia University
+                                                              C. Huitema
+                                                                D. Gurle
+                                                   Microsoft Corporation
+                                                           December 2002
+
+
+   Session Initiation Protocol (SIP) Extension for Instant Messaging
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   Instant Messaging (IM) refers to the transfer of messages between
+   users in near real-time.  These messages are usually, but not
+   required to be, short.  IMs are often used in a conversational mode,
+   that is, the transfer of messages back and forth is fast enough for
+   participants to maintain an interactive conversation.
+
+   This document proposes the MESSAGE method, an extension to the
+   Session Initiation Protocol (SIP) that allows the transfer of Instant
+   Messages.  Since the MESSAGE request is an extension to SIP, it
+   inherits all the request routing and security features of that
+   protocol.  MESSAGE requests carry the content in the form of MIME
+   body parts.  MESSAGE requests do not themselves initiate a SIP
+   dialog; under normal usage each Instant Message stands alone, much
+   like pager messages.  MESSAGE requests may be sent in the context of
+   a dialog initiated by some other SIP request.
+
+
+
+
+
+
+
+
+
+Campbell, et. al.           Standards Track                     [Page 1]
+
+RFC 3428                 SIP Message Extension             December 2002
+
+
+Terminology
+
+   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
+   RECOMMENDED", "MAY" and "OPTIONAL" are to be interpreted as described
+   in BCP 14, RFC 2119 [6] and indicate requirement levels for compliant
+   SIP implementations.
+
+Table of Contents
+
+   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.    Scope of Applicability . . . . . . . . . . . . . . . . . . .  3
+   3.    Overview of Operation  . . . . . . . . . . . . . . . . . . .  4
+   4.    UAC Processing . . . . . . . . . . . . . . . . . . . . . . .  5
+   5.    Use of Instant Message URIs  . . . . . . . . . . . . . . . .  6
+   6.    Proxy Processing . . . . . . . . . . . . . . . . . . . . . .  6
+   7.    UAS Processing . . . . . . . . . . . . . . . . . . . . . . .  7
+   8.    Congestion Control . . . . . . . . . . . . . . . . . . . . .  8
+   9.    Method Definition  . . . . . . . . . . . . . . . . . . . . .  9
+   10.   Example Messages . . . . . . . . . . . . . . . . . . . . . . 11
+   11.   Security Considerations  . . . . . . . . . . . . . . . . . . 13
+   11.1  Outbound authentication  . . . . . . . . . . . . . . . . . . 13
+   11.2  SIPS URIs  . . . . . . . . . . . . . . . . . . . . . . . . . 14
+   11.3  End-to-End Protection  . . . . . . . . . . . . . . . . . . . 14
+   11.4  Replay Prevention  . . . . . . . . . . . . . . . . . . . . . 14
+   11.5  Using message/cpim bodies  . . . . . . . . . . . . . . . . . 15
+   12.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 15
+   13.   Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
+   14.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 15
+   15.   Normative References . . . . . . . . . . . . . . . . . . . . 16
+   16.   Informational References . . . . . . . . . . . . . . . . . . 16
+   17.   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
+   18.   Full Copyright Statement . . . . . . . . . . . . . . . . . . 18
+
+1. Introduction
+
+   Instant Messaging (IM) is defined as the exchange of content between
+   a set of participants in near real time.  Generally, the content is
+   short text messages, although that need not be the case.  Generally,
+   the messages that are exchanged are not stored, but this also need
+   not be the case.  IM differs from email in common usage in that
+   instant messages are usually grouped together into brief live
+   conversations, consisting of numerous small messages sent back and
+   forth.
+
+   Instant messaging as a service has been in existence within intranets
+   and IP networks for quite some time.  Early implementations include
+   zephyr [11], the UNIX talk application, and IRC.  More recently, IM
+
+
+
+Campbell, et. al.           Standards Track                     [Page 2]
+
+RFC 3428                 SIP Message Extension             December 2002
+
+
+   has been used as a service coupled with presence and buddy lists;
+   that is, when a friend comes online, a user can be made aware of this
+   and have the option of sending the friend an instant message.  The
+   protocols for accomplishing this are all proprietary, which has
+   seriously hampered interoperability.
+
+   The integration of instant messaging, presence, and session-oriented
+   communications is very powerful.  The Session Initiation Protocol
+   (SIP) [1] provides mechanisms that are useful for presence
+   applications, and for session-oriented communication applications,
+   but not for instant messages.
+
+   This document proposes an extension method for SIP called the MESSAGE
+   method.  MESSAGE requests normally carry the instant message content
+   in the request body.
+
+   RFC 2778 [3] and RFC 2779 [2] give a model and requirements for
+   presence and instant messaging protocols.  Implementations of the
+   MESSAGE method SHALL support all the instant message requirements in
+   RFC 2779 relevant to its scope of applicability.
+
+2. Scope of Applicability
+
+   This document describes the use of the MESSAGE method for sending
+   instant messages using a metaphor similar to that of a two-way pager
+   or SMS enabled handset.  That is, there are no explicit association
+   between messages.  Each IM stands alone--any sense of a
+   "conversation" only exists in the client user interface, or perhaps
+   in the user's own imagination.  We contrast this with a "session"
+   model, where there is an explicit conversation with a clear beginning
+   and end.  In the SIP environment, an IM session would be a media
+   session initiated with an INVITE transaction and terminated with a
+   BYE transaction.
+
+   There is value in each model.  Most modern IM clients offer both user
+   experiences.  The user can choose to send an IM to a contact, or he
+   can choose to invite one or more contacts to join a conversation.
+   The pager model makes sense when the user wishes to send a small
+   number of short IMs to a single (or small number of) recipients.  The
+   session model makes sense for extended conversations, joining chat
+   groups, if there is a need to associate a conversation with some
+   other SIP initiated session, etc.
+
+   This document addresses the pager model only.  We recognize the value
+   of the session model as well, but we do not define it here.  Such a
+   solution will require additional work beyond that of this document.
+   The SIMPLE work group currently plans to address IM sessions in a
+   separate document.
+
+
+
+Campbell, et. al.           Standards Track                     [Page 3]
+
+RFC 3428                 SIP Message Extension             December 2002
+
+
+   There may be a temptation to simulate a session of IMs by initiating
+   a dialog, then sending MESSAGE requests in the context of that
+   dialog.  This is not an adequate solution for IM sessions, in that
+   this approach forces the MESSAGE requests to follow the same network
+   path as any other SIP requests, even though the MESSAGE requests
+   arguably carry media rather than signaling.  IM applications are
+   typically high volume, and we expect the IM volume in sessions to be
+   even higher.  This will likely cause congestion problems if sent over
+   a transport without congestion control, and there is no clear
+   mechanism in SIP to prevent some hop from forwarding a MESSAGE
+   request over UDP.
+
+   Additionally, MESSAGE requests sent over an existing dialog must, by
+   the nature of SIP, go to the same destination as any other request
+   sent in that dialog.  This prevents any separation between the IM
+   endpoint and the signaling endpoint.  This is not an acceptable
+   limitation for the session-model of instant messaging.
+
+   The authors recognize that there may be valid reasons to send MESSAGE
+   requests in the context of a dialog.  For example, one participant in
+   a voice session may wish to send an IM to another participant, and
+   associate that IM with the session.  But implementations SHOULD NOT
+   create dialogs for the primary purpose of associating MESSAGE
+   requests with one another.
+
+   Note that this statement does not prohibit using SIP to initiate a
+   media session made up of IMs, just like any other session.  Indeed,
+   we expect the solution for IM sessions to use that metaphor.  The
+   reader should avoid confusing the concepts of a SIP dialog and a
+   media session.
+
+3. Overview of Operation
+
+   When one user wishes to send an instant message to another, the
+   sender formulates and issues a SIP request using the new MESSAGE
+   method defined by this document.  The Request-URI of this request
+   will normally be the "address of record" for the recipient of the
+   instant message, but it may be a device address in situations where
+   the client has current information about the recipient's location.
+   For example, the client could be coupled with a presence system that
+   supplies an up to date device contact for a given address of record.
+   The body of the request will contain the message to be delivered.
+   This body can be of any MIME type, including message/cpim [7].  Since
+   the message/cpim format is expected to be supported by other instant
+   message protocols, endpoints using different IM protocols, but
+   otherwise supporting message/cpim body types, should be able to
+
+
+
+
+
+Campbell, et. al.           Standards Track                     [Page 4]
+
+RFC 3428                 SIP Message Extension             December 2002
+
+
+   exchange messages without modification of the content by a gateway or
+   other intermediary.  This helps to enable end-to-end security between
+   endpoints that use different IM protocols.
+
+   The request may traverse a set of SIP proxies, using a variety of
+   transports, before reaching its destination.  The destination for
+   each hop is located using the address resolution rules detailed in
+   the Common Profile for Instant Messaging (CPIM) [8] and SIP
+   specifications.  During traversal, each proxy may rewrite the request
+   URI based on available routing information.
+
+   Provisional and final responses to the request will be returned to
+   the sender as with any other SIP request.  Normally, a 200 OK
+   response will be generated by the user agent of the request's final
+   recipient.  Note that this indicates that the user agent accepted the
+   message, not that the user has seen it.
+
+   MESSAGE requests do not establish dialogs.
+
+4. UAC Processing
+
+   Unless stated otherwise in this document, MESSAGE requests and
+   associated responses are constructed according to the rules in
+   section 8.1 of the SIP specification [1].
+
+   All UACs which support the MESSAGE method MUST be prepared to send
+   MESSAGE requests with a body of type text/plain.  They may send
+   bodies of type message/cpim [7].
+
+   MESSAGE requests do not initiate dialogs.  User Agents MUST NOT
+   insert Contact header fields into MESSAGE requests.
+
+   A UAC MAY associate a MESSAGE request with an existing dialog.  If a
+   MESSAGE request is sent within a dialog, it is "associated" with any
+   media session or sessions associated with that dialog.
+
+   If the UAC receives a 200 OK response to a MESSAGE request, it may
+   assume the message has been delivered to the final destination.  It
+   MUST NOT assume that the recipient has actually read the instant
+   message.  If the UAC receives a 202 Accepted response, the message
+   has been delivered to a gateway, store and forward server, or some
+   other service that may eventually deliver the message.  In this case,
+   the UAC MUST NOT assume the message has been delivered to the final
+   destination.  If confirmation of delivery is required for a message
+   that has been responded to with a 202 Accepted, that confirmation
+   must be delivered via some other mechanism, which is beyond the scope
+   of this specification.
+
+
+
+
+Campbell, et. al.           Standards Track                     [Page 5]
+
+RFC 3428                 SIP Message Extension             December 2002
+
+
+   Note that a downstream proxy could fork a MESSAGE request.  If this
+   occurs, the forking proxy will forward one final response upstream,
+   even though it may receive multiple final responses.  The UAC will
+   have no way to detect whether or not a fork occurs.  Therefore the
+   UAC MUST NOT assume that a given final response represents the only
+   UAS that receives the request.  For example, multiple branches of a
+   fork could have resulted in 2xx responses.  Even though the UAC only
+   sees one of those responses, the request has in fact been received by
+   the second device as well.
+
+   The UAC MAY add an Expires header field to limit the validity of the
+   message content.  If the UAC adds an Expires header field with a
+   non-zero value, it SHOULD also add a Date header field containing the
+   time the message is sent.
+
+5. Use of Instant Message URIs
+
+   An instant inbox may be most generally referenced by an Instant
+   Message URI [8] in the form of "im:user@domain".  IM URIs are
+   abstract, and will eventually be translated to concrete, protocol-
+   dependent URI.
+
+   If a UA is presented with an IM URI as the address for an instant
+   message, it SHOULD resolve it to a SIP URI, and place the resulting
+   URI in the Request-URI of the MESSAGE request before sending.  If the
+   UA is unable to resolve the IM URI, it MAY place the IM URI in the
+   Request-URI, thus delegating the resolution to a downstream device
+   such as proxy or gateway.  Performing this translation as early as
+   possible allows SIP proxies, which may be unaware of the im:
+   namespace, to route the requests normally.
+
+   MESSAGE requests also contain logical identifiers of the sender and
+   intended recipient, in the form of the From and To header fields.
+   These identifiers SHOULD contain SIP (or SIPS) URIs, but MAY include
+   IM URIs if the SIP URIs are not known at the time of request
+   construction.
+
+   Record-Route and Route header fields MUST NOT contain IM URIs.  These
+   header fields contain concrete SIP or SIPS URIs according to the
+   rules of SIP [1].
+
+6. Proxy Processing
+
+   Proxies route MESSAGE requests according to the rules of SIP [1].
+   Note that the MESSAGE request MAY fork; this allows for delivery of
+   the message to several possible terminals where the user might be.  A
+   proxy forking a MESSAGE request follows the normal SIP rules for
+   forking a non-INVITE request.  In particular, even if the fork
+
+
+
+Campbell, et. al.           Standards Track                     [Page 6]
+
+RFC 3428                 SIP Message Extension             December 2002
+
+
+   results in multiple successful deliveries, the forking proxy will
+   only forward one final response upstream.
+
+7. UAS Processing
+
+   A UAS that receives a MESSAGE request processes it following the
+   rules of SIP [1].
+
+   A UAS receiving a MESSAGE request SHOULD respond with a final
+   response immediately.  Note, however, that the UAS is not obliged to
+   display the message to the user either before or after responding
+   with a 200 OK.  That is, a 200 OK response does not necessarily mean
+   the user has read the message.
+
+   A 2xx response to a MESSAGE request MUST NOT contain a body.  A UAS
+   MUST NOT insert a Contact header field into a 2xx response.
+
+   A UAS which is, in fact, a message relay, storing the message and
+   forwarding it later on, or forwarding it into a non-SIP domain,
+   SHOULD return a 202 (Accepted) [5] response indicating that the
+   message was accepted, but end to end delivery has not been
+   guaranteed.
+
+   A 4xx or 5xx response indicates that the message was not delivered
+   successfully.  A 6xx response means it was delivered successfully,
+   but refused.
+
+   A UAS that supports the MESSAGE method MUST be prepared to receive
+   and render bodies of type "text/plain", and may support reception and
+   rendering of bodies of type "message/cpim" [7].
+
+   A MESSAGE request is said to be expired if its expiration time has
+   passed. The expiration time is determined by examining the Expires
+   header field, if present.  MESSAGE requests without an Expires header
+   field do not expire.  If the MESSAGE request containing an Expires
+   header field also contains a Date header field, the UAS SHOULD
+   interpret the Expires header field value as delta time from the Date
+   header field value.  If the request does not contain a Date header
+   field, the UAS SHOULD interpret the Expires header value as delta
+   time from the time the UAS received the request.
+
+   If the MESSAGE expires before the UAS is able to present the message
+   to the user, the UAS SHOULD handle the message based on local policy.
+   This policy could mean: the message is deleted undisplayed,
+
+
+
+
+
+
+
+Campbell, et. al.           Standards Track                     [Page 7]
+
+RFC 3428                 SIP Message Extension             December 2002
+
+
+   the message is still displayed to the user, or some other policy may
+   be invoked.  If the message is displayed, the UAS SHOULD clearly
+   indicate to the user that the message has expired.
+
+   If the UAS is acting as a message relay, and is unable to deliver the
+   message before expiration, it chooses an action based on local
+   policy.  This action could involve deleting the message undelivered,
+   delivering it as is, logging the expired message, or any other local
+   policy.
+
+8. Congestion Control
+
+   Existing IM services have a history of very high volume usage.
+   Additionally, MESSAGE requests differ from other sorts of SIP
+   requests in that they carry media, in the form of IMs, as payload.
+   Conventional SIP payloads carry signaling information about media,
+   but not media itself.  There is potential that when a SIP
+   infrastructure is shared between call signaling and instant
+   messaging, the IM traffic will interfere with call signaling traffic.
+   Congestion control in general is an issue that should be addressed at
+   the SIP specification level rather than for an individual method.
+   But since the traffic patterns are likely to be different for MESSAGE
+   than for most other methods, it makes sense to give MESSAGE special
+   consideration.
+
+   Whenever possible, MESSAGE requests SHOULD be sent over transports
+   that implement end-to-end congestion control, such as TCP or SCTP.
+   However, SIP does not provide a mechanism to prevent a downstream hop
+   from sending a request over UDP.  Even the requirement to use TCP for
+   requests over a certain size can be overridden by the receiver.
+   Therefore use of a congestion-controlled transport by the UAC is not
+   sufficient.
+
+   The size of MESSAGE requests outside of a media session MUST NOT
+   exceed 1300 bytes, unless the UAC has positive knowledge that the
+   message will not traverse a congestion-unsafe link at any hop, or
+   that the message size is at least 200 bytes less than the lowest MTU
+   value found en route to the UAS.  Larger payloads may be sent as part
+   of a media session, or using some type of content-indirection.
+
+      At the time of this writing, there is no mechanism for a UAC to
+      gain such knowledge outside of trivial network architectures, or
+      networks that are wholly controlled by a single administrative
+      domain.  But if a mechanism for ensuring congestion-control at
+      each hop is created in the future, MESSAGE clients can relax the
+      size limit without requiring a change to this specification.  The
+      authors expect that such a mechanism or mechanism will be created
+      in the near future.
+
+
+
+Campbell, et. al.           Standards Track                     [Page 8]
+
+RFC 3428                 SIP Message Extension             December 2002
+
+
+      There have been discussions on making the 1300 byte limit based on
+      the path MTU to the next hop SIP device.  The SIP specification
+      does exactly that, choosing the limit 200 bytes less than the path
+      MTU, or 1300 bytes if the device does not know the path MTU.
+      Transport decisions are made on a per-hop basis.  However, the
+      point of this limit is to make sure that no upstream proxy chooses
+      to send a MESSAGE request with large content over UDP.  Since,
+      except in trivial circumstances, a MESSAGE client is very unlikely
+      to know the MTU for upstream devices beyond the next hop, an MTU
+      based limit is not very useful.
+
+   A UAC MUST NOT initiate a new out-of-dialog MESSAGE transaction to a
+   given URI if there is a previous out-of-dialog transaction pending
+   for the same URI.  Similarly, A UAC SHOULD NOT initiate overlapping
+   MESSAGE transactions inside a dialog, and MUST NOT do so unless the
+   route set for that dialog uses a congestion-controlled transport at
+   every hop.
+
+      The prohibition against overlapping MESSAGE request provides some
+      degree of congestion-safe behavior.  A request and its associated
+      response must each cross the full path between the UAC and the
+      UAS.  The time required for this will increase as networks become
+      congested.  This provides an adaptive mechanism to slow the
+      introduction of new MESSAGE requests to the same destination.
+
+   It has been suggested that provisional responses should not be
+   allowed for pager-model MESSAGE requests.  However, it is not
+   possible to require special treatment for MESSAGE, since many proxy
+   servers will not be aware of the MESSAGE method.  Therefore MESSAGE
+   requests will receive the same provisional response treatment as any
+   other non-INVITE method, as described in the SIP specification.
+
+9. Method Definition
+
+   This specification defines a new SIP method, MESSAGE.  The BNF for
+   this method is:
+
+      MESSAGEm = %x4D.45.53.53.41.47.45 ;MESSAGE in caps
+
+   As with all other methods, the MESSAGE method name is case sensitive.
+
+   Tables 1 and 2 extend Tables 2 and 3 of SIP [1] by adding an
+   additional column, defining the header fields that can be used in
+   MESSAGE requests and responses.
+
+
+
+
+
+
+
+Campbell, et. al.           Standards Track                     [Page 9]
+
+RFC 3428                 SIP Message Extension             December 2002
+
+
+                   Header Field       where  proxy  MESSAGE
+                   __________________________________________
+                   Accept               R              -
+                   Accept              2xx             -
+                   Accept              415             m*
+                   Accept-Encoding      R              -
+                   Accept-Encoding     2xx             -
+                   Accept-Encoding     415             m*
+                   Accept-Language      R              -
+                   Accept-Language     2xx             -
+                   Accept-Language     415             m*
+                   Alert-Info           R              -
+                   Alert-Info          180             -
+                   Allow                R              o
+                   Allow               2xx             o
+                   Allow                r              o
+                   Allow               405             m
+                   Authentication-Info 2xx             o
+                   Authorization        R              o
+                   Call-ID              c      r       m
+                   Call-Info                  ar       o
+                   Contact              R              -
+                   Contact             1xx             -
+                   Contact             2xx             -
+                   Contact             3xx             o
+                   Contact             485             o
+                   Content-Disposition                 o
+                   Content-Encoding                    o
+                   Content-Language                    o
+                   Content-Length             ar       t
+                   Content-Type                        *
+                   CSeq                c       r       m
+                   Date                        a       o
+                   Error-Info       300-699    a       o
+                   Expires                             o
+                   From                c       r       m
+                   In-Reply-To         R               o
+                   Max-Forwards        R      amr      m
+                   Organization               ar       o
+
+                   Table 1: Summary of header fields, A--O
+
+
+
+
+
+
+
+
+
+
+Campbell, et. al.           Standards Track                    [Page 10]
+
+RFC 3428                 SIP Message Extension             December 2002
+
+
+                   Header Field       where  proxy  MESSAGE
+                   __________________________________________
+                   Priority             R     ar         o
+                   Proxy-Authenticate  407    ar         m
+                   Proxy-Authenticate  401    ar         o
+                   Proxy-Authorization  R     dr         o
+                   Proxy-Require        R     ar         o
+                   Record-Route               ar         -
+                   Reply-To                              o
+                   Require                    ar         c
+                   Retry-After   404,413,480,486         o
+                                     500,503             o
+                                     600,603             o
+                   Route                R     adr        o
+                   Server               r                o
+                   Subject              R                o
+                   Timestamp                             o
+                   To                 c(1)     r         m
+                   Unsupported         420               o
+                   User-Agent                            o
+                   Via                  R     amr        m
+                   Via                 rc     dr         m
+                   Warning              r                o
+                   WWW-Authenticate    401    ar         m
+                   WWW-Authenticate    407    ar         o
+
+                 (1): copied  with  possible addition of tag
+
+                   Table 2: Summary of header fields, P--Z
+
+   A MESSAGE request MAY contain a body, using the standard MIME header
+   fields to identify the content.
+
+10. Example Messages
+
+   An example message flow is shown in Figure 1.  The message flow shows
+   an initial IM sent from User 1 to User 2, both users in the same
+   domain, "domain", through a single proxy.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Campbell, et. al.           Standards Track                    [Page 11]
+
+RFC 3428                 SIP Message Extension             December 2002
+
+
+           |  F1 MESSAGE          |                         |
+           |--------------------> |  F2 MESSAGE             |
+           |                      | ----------------------->|
+           |                      |                         |
+           |                      |  F3 200 OK              |
+           |                      | <-----------------------|
+           |  F4 200 OK           |                         |
+           |<-------------------- |                         |
+           |                      |                         |
+           |                      |                         |
+           |                      |                         |
+        User 1                  Proxy                    User 2
+
+                   Figure 1: Example Message Flow
+
+   Message F1 looks like:
+
+   MESSAGE sip:user2@domain.com SIP/2.0
+   Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse
+   Max-Forwards: 70
+   From: sip:user1@domain.com;tag=49583
+   To: sip:user2@domain.com
+   Call-ID: asd88asd77a@1.2.3.4
+   CSeq: 1 MESSAGE
+   Content-Type: text/plain
+   Content-Length: 18
+
+   Watson, come here.
+
+   User1 forwards this message to the server for domain.com.  The proxy
+   receives this request, and recognizes that it is the server for
+   domain.com.  It looks up user2 in its database (built up through
+   registrations), and finds a binding from sip:user2@domain.com to
+   sip:user2@user2pc.domain.com.  It forwards the request to user2.  The
+   resulting message, F2, looks like:
+
+   MESSAGE sip:user2@domain.com SIP/2.0
+   Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds
+   Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;
+                                              received=1.2.3.4
+   Max-Forwards: 69
+   From: sip:user1@domain.com;tag=49394
+   To: sip:user2@domain.com
+   Call-ID: asd88asd77a@1.2.3.4
+   CSeq: 1 MESSAGE
+   Content-Type: text/plain
+   Content-Length: 18
+
+
+
+
+Campbell, et. al.           Standards Track                    [Page 12]
+
+RFC 3428                 SIP Message Extension             December 2002
+
+
+   Watson, come here.
+
+   The message is received by user2, displayed, and a response is
+   generated, message F3, and sent to the proxy:
+
+   SIP/2.0 200 OK
+   Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds;
+                                            received=192.0.2.1
+   Via: SIP/2.0/TCP user1pc.domain.com;;branch=z9hG4bK776sgdkse;
+                                               received=1.2.3.4
+   From: sip:user1@domain.com;tag=49394
+   To: sip:user2@domain.com;tag=ab8asdasd9
+   Call-ID: asd88asd77a@1.2.3.4
+   CSeq: 1 MESSAGE
+   Content-Length: 0
+
+   Note that most of the header fields are simply reflected in the
+   response.  The proxy receives this response, strips off the top Via,
+   and forwards to the address in the next Via, user1pc.domain.com, the
+   result being message F4:
+
+   SIP/2.0 200 OK
+   Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;
+                                              received=1.2.3.4
+   From: sip:user1@domain.com;;tag=49394
+   To: sip:user2@domain.com;tag=ab8asdasd9
+   Call-ID: asd88asd77a@1.2.3.4
+   CSeq: 1 MESSAGE
+   Content-Length: 0
+
+11. Security Considerations
+
+   In normal usage, most SIP requests are used to setup and modify
+   communication sessions.  The actual communication between
+   participants happens in the media sessions, not in the SIP requests
+   themselves.  The MESSAGE method changes this assumption; MESSAGE
+   requests normally carry the actual communication between participants
+   as payload.  This implies that MESSAGE requests have a greater need
+   for security than most other SIP requests.  In particular, UAs that
+   support the MESSAGE request MUST implement end-to-end authentication,
+   body integrity, and body confidentiality mechanisms.
+
+11.1 Outbound Authentication
+
+   When local proxies are used for transmission of outbound messages,
+   proxy authentication, as specified in RFC 3261, is RECOMMENDED.  This
+   is useful to verify the identity of the originator, and prevent
+   spoofing and spamming at the originating network.
+
+
+
+Campbell, et. al.           Standards Track                    [Page 13]
+
+RFC 3428                 SIP Message Extension             December 2002
+
+
+11.2 SIPS URIs
+
+   The SIPS URI mechanism [1] allows a UA to assert that every hop must
+   occur over a secure connection.  This provides some level of
+   integrity and privacy protection.  However, this requires the users
+   to trust that each proxy in the request path is well-behaved, that
+   is, they do not violate the rules for routing SIPS URIs.  Also, any
+   unencrypted bodies are fully exposed to the proxies.
+
+   Additionally, the possibility of a forking proxy allows a MESSAGE
+   request to be delivered to additional endpoints without the knowledge
+   of the UAC.  If only hop-by-hop protection is used, the users must
+   trust all proxies in the chain to not fork requests to unauthorized
+   destinations.
+
+11.3 End-to-End Protection
+
+   When the goal is to remedy the concerns stated above, the MESSAGE
+   bodies MUST be secured with S/MIME.  If bodies specified in future to
+   be carried by the MESSAGE method have different means of providing
+   end-to-end security, their specification MUST describe the usage.
+   SIP MESSAGE endpoints MUST support encryption (CMS EnvelopeData) and
+   S/MIME signatures (CMS SignedData).
+
+   The S/MIME algorithms are set by RFC 3369 [4].  The AES [10]
+   algorithm should be preferred, as it is expected that AES best suits
+   the capabilities of many platforms.  However, an IETF specification
+   for this is still incomplete as of the time of this writing.
+
+11.4 Replay Prevention
+
+   To prevent the replay of old SIP requests, all signed MESSAGE
+   requests and responses MUST contain a Date header field covered by
+   the message signature.  Any message with a date older than several
+   minutes in the past, or which is more than several minutes in the
+   future, SHOULD be answered with a 400 (Incorrect Date or Time)
+   message, unless such messages arrive repeatedly from the same source,
+   in which case they MAY be discarded without sending a response.
+   Obviously, this replay attack prevention mechanism does not work for
+   devices without clocks.
+
+   Note that there are situations where an stale Date header field is
+   normal.  For example, the MESSAGE request may have been stored in a
+   store and forward server while the recipient was offline.  When the
+   recipient returns, that server might then forward the message.  Final
+   receipt of the message would then occur some time after it was
+   originally sent.
+
+
+
+
+Campbell, et. al.           Standards Track                    [Page 14]
+
+RFC 3428                 SIP Message Extension             December 2002
+
+
+   If a UAS receives a stale message that can be confirmed to have come
+   from a known store and forward server (perhaps over a TLS
+   connection), it makes sense for it to accept the message normally.
+   Also, if one or more stale messages arrive shortly after an offline
+   period, the UAS MAY accept the message, but SHOULD warn the user that
+   there is a risk the message has been replayed.
+
+11.5 Using message/cpim Bodies
+
+   The message/cpim format [7] allows for the S/MIME protection of
+   metadata in addition to the message payload itself.  In many cases,
+   this metadata is redundant with SIP header fields.  Still,
+   message/cpim adds value in that the protection of metadata can extend
+   across protocol boundaries.  For example, a signed message/cpim body
+   can provide sender authentication using the message/cpim From header
+   field, even if the message crosses a gateway to another CPIM
+   compliant instant message service that does not understand SIP header
+   fields.
+
+12. IANA Considerations
+
+   This specification registers the MESSAGE method in the
+   http://www.iana.org/assignments/sip-parameters/Method registry,
+   according to the following information:
+
+   MESSAGE        [RFC3428]
+
+13. Contributors
+
+   The following people made substantial contributions to this work:
+
+   Bernard Aboba     Microsoft
+   Steve Donovan     dynamicsoft
+   Jonathan Lennox   Columbia University
+   Dave Oran         Cisco
+   Robert Sparks     dynamicsoft
+   Dean Willis       dynamicsoft
+
+14. Acknowledgments
+
+   The authors would like to thank the following people for their
+   support of the concept of SIP for IM, support for this work, and for
+   their useful comments and insights:
+
+      Jon Peterson     NeuStar
+      Sean Olson       Microsoft
+      Adam Roach       dynamicsoft
+      Billy Biggs      University of Waterloo
+
+
+
+Campbell, et. al.           Standards Track                    [Page 15]
+
+RFC 3428                 SIP Message Extension             December 2002
+
+
+      Stuart Barkley   UUNet
+      Mauricio Arango  SUN
+      Richard Shockey  NeuStar
+      Jorgen Bjorker   Hotsip
+      Henry Sinnreich  MCI Worldcom
+      Ronald Akers     Motorola
+      Torrey Searle    Indigo Software
+      Rohan Mahy       Cisco
+      Christian Groves Ericsson
+      Allison Mankin   ISI
+      Tan Ya-Ching     Siemens
+
+15.Normative 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]  Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
+        Presence Protocol Requirements", RFC 2779, February 2000.
+
+   [3]  Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
+        Instant Messaging", RFC 2778, February 2000.
+
+   [4]  Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369,
+        August 2002.
+
+   [5]  Roach, A., "Session Initiation Protocol (SIP)-Specific Event
+        Notification", RFC 3265, June 2002.
+
+   [6]  Bradner, S., "Keywords for Use in RFC's to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+16. Informational References
+
+   [7]  Atkins, D. and G. Klyne, "Common Presence and Instant Messaging
+        Message Format", Work in Progress.
+
+   [8]  Crocker, D., Diacakis, A., Mazzoldi, F., Huitema, C., Klyne, G.,
+        Rose, M., Rosenberg, J., Sparks, R., Sugano, H. and J. Peterson,
+        "Address Resolution for Instant Messaging and Presence", Work in
+        Progress.
+
+   [9]  Rosenberg, J. and H. Schulzrinne, "SIP Caller Preferences and
+        Callee Capabilities", Work in Progress.
+
+   [10] Schaad, J. and R. Housley, "Use of the AES Encryption Algorithm
+        and RSA-OAEP Key Transport in CMS", Work in Progress.
+
+
+
+Campbell, et. al.           Standards Track                    [Page 16]
+
+RFC 3428                 SIP Message Extension             December 2002
+
+
+   [11] DellaFera, C., Eichin, M., French, R., Jedlinski, D., Kohl, J.
+        and W. Sommerfeld, "The Zephyr notification service", in USENIX
+        Winter Conference (Dallas, Texas), Feb. 1988.
+
+17. Authors' Addresses
+
+   Ben Campbell
+   dynamicsoft
+   5100 Tennyson Parkway
+   Suite 1200
+   Plano, TX  75024
+
+   EMail: bcampbell@dynamicsoft.com
+
+
+   Jonathan Rosenberg
+   dynamicsoft
+   72 Eagle Rock Avenue
+   First Floor
+   East Hanover, NJ  07936
+
+   EMail: jdrosen@dynamicsoft.com
+
+
+   Henning Schulzrinne
+   Columbia University
+   M/S 0401
+   1214 Amsterdam Ave.
+   New York, NY  10027-7003
+
+   EMail: schulzrinne@cs.columbia.edu
+
+
+   Christian Huitema
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052-6399
+
+   EMail: huitema@microsoft.com
+
+
+   David Gurle
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052-6399
+
+   EMail: dgurle@microsoft.com
+
+
+
+
+Campbell, et. al.           Standards Track                    [Page 17]
+
+RFC 3428                 SIP Message Extension             December 2002
+
+
+18. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  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 assigns.
+
+   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
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Campbell, et. al.           Standards Track                    [Page 18]
+