Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text ChatCisco Systems, Inc.1899 Wynkoop Street, Suite 600DenverCO80202USA+1-303-308-3282psaintan@cisco.comEricssonDecarie BoulevardTown of Mount RoyalQuebecCanadaeddy.gavita@ericsson.comEricssonDecarie BoulevardTown of Mount RoyalQuebecCanadaNazin.Hossain@ericsson.comEricssonHirsalantie 1102420JorvasFinlandSalvatore.Loreto@ericsson.com
RAI
Text ChatInstant MessagingSession Initiation ProtocolSIPMessage Sessions Relay ProtocolMSRPExtensible Messaging and Presence ProtocolXMPPThis document defines a bi-directional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP).Both the Session Initiation Protocol and the Extensible Messaging and Presence Protocol can be used for the purpose of one-to-one text chat over the Internet. To ensure interworking between these technologies, it is important to define bi-directional protocol mappings.The architectural assumptions underlying such protocol mappings are provided in , including mapping of addresses and error conditions. Mappings for single instant messages (sometimes called "pager-mode" messaging) are provided in . This document specifies mappings for one-to-one text chat sessions (sometimes called "session-mode" messaging); in particular, this document specifies mappings between XMPP and the Message Session Relay Protocol . Mapping of multi-user text chat (sometimes called "groupchat") is out of scope for this document.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .Both XMPP and SIP/SIMPLE technologies enable end users to send "instant messages" to other end users. The term "instant message" usually refers to messages sent between two end users for delivery in close to real time (rather than messages that are stored and forwarded to the intended recipient upon request). Generally, there are three kinds of instant messages:Single messages, which are sent from the sender to the recipient outside the context of any one-to-one chat session or multi-user text conference. The message is immediately delivered and not stored in an inbox. In XMPP a single message is a <message/> stanza of type "normal" as specified in . In SIP/SIMPLE a single message is sent via the MESSAGE method as specified in .One-to-one chat messages, which are sent from the sender to the recipient (i.e., one-to-one) in the context of a "chat session" between the two entities. In XMPP a chat message is a <message/> stanza of type "chat". In SIP/SIMPLE a chat message is sent using an MSRP session as specified in .Groupchat messages, which are sent from a sender to multiple recipients (i.e., two or more) in the context of a "multi-user chat session", "text conference", or "chatroom". In XMPP a groupchat message is a <message/> stanza of type "groupchat" that is reflected from the sender to multiple recipients by a multi-user chat service, as defined in . In SIP/SIMPLE a groupchat message is reflected from the sender to multiple recipients by a conference server that uses MSRP to handle groupchat sessions, as defined in .This document covers only scenario #2 for converting XMPP messages of type "chat" to and from their corresponding SIP INVITE and MSRP message types on the SIP/SIMPLE side.As in and related documents, the approach taken here is to directly map syntax and semantics from one protocol to another. The mapping described herein depends on the protocols defined in the following specifications:XMPP chat sessions using message stanzas of type "chat" are specified in .A method for formally negotiating an XMPP chat session is specified in the Stanza Session Negotiation extension to XMPP .SIP-based chat sessions using the SIP INVITE and SEND request types are specified in .The traditional model for a one-to-one chat "session" in XMPP is for a user to simply send a message of type "chat" to a contact, without any formal negotiation of session parameters; the contact would then reply to the message, and the sum total of such messages exchanged during a defined period of time can be considered a chat session. This informal approach to chat sessions in XMPP can be mapped both to SIP pager-mode messaging using the SIP MESSAGE method (as documented in ) and to an MSRP chat session. How a gateway chooses to map the XMPP chat session to the SIP side is a matter of the implementation, although guidelines are provided under .However, in XMPP it is also possible to formally request a chat session and negotiate its parameters (e.g., security, privacy, message logging) before beginning the session and exchanging messages. The protocol for doing so is defined in . In this case, the XMPP chat session SHOULD be translated into an MSRP session.This document covers the mapping of both informal and formally-negotiated XMPP chat sessions into MSRP sessions, and from MSRP sessions into XMPP informal and formal sessions.When a gateway receives a chat message or chat session request intended for a recipient that is registered with the gateway itself or has an account on a local service, it SHOULD adhere to the following process in determining whether to (1) initiate a formal chat session with the recipient, (2) initiate an informal chat session with the recipient, or (3) return an error to the sender.If the gateway has knowledge of the recipient's online endpoints (available resources in XMPP or registered UAs in SIP), then it SHOULD discover the capabilities of those endpoints.If the gateway determines that one or more of the endpoints supports formal chat sessions, it SHOULD initiate a formal chat session with one of those endpoints (deciding among the endpoints based on presence information or communications priority).If the gateway determines that none of the endpoints supports formal chat sessions, it SHOULD initiate an informal chat session with one of those endpoints (deciding among the endpoints based on presence information or communications priority).If the gateway does not know if the recipient has any online endpoints, it SHOULD return an appropriate error to the sender.The methods by which a gateway determines support for various capabilities are protocol-specific. For XMPP a gateway SHOULD use the Service Discovery extension defined in or, if it receives presence information from the XMPP endpoint, use the Entity Capabilities extension defined in . For MSRP a gateway SHOULD use the Session Description Protocol defined in in conjunction with a high-level protocol that provides a capability query, such as the SIP OPTIONS request defined in .XMPP makes use of long-lived TCP connections. If mobility affecting Layer 3 causes a dropped connection, the connection must be re-established. If mobility does not preserve the IP address, the TCP connection will be dropped. Any TLS session and SASL associations must be re-established if the TCP connection is dropped. XMPP binds directly to TCP in the core specification, so the TCP session must remain open for the entire duration of the chat session. The XMPP Standards Foundation does define protocol extensions enabling transport of XMPP traffic over HTTP (refer to and ), so that individual messages are carried using HTTP and are more robust in environments such as mobile networks, allowing for better recovery if a TCP session is broken.SIMPLE is similar when using MSRP. The Message Session Relay Protocol is a protocol for transmitting instant messages (IM) in the context of a session. The protocol specification describes how the session can be negotiated and established with an offer or answer (see ) using the Session Description Protocol . In SIMPLE, this exchange is carried using SIP as the signaling protocol. After the TCP connection is established, if it fails for any reason, then an MSRP endpoint MAY choose to re-create such a session using a new SDP exchange in a SIP re-INVITE. SIMPLE also uses the MESSAGE request type for transporting instant messaging outside the context of a session. The MESSAGE request is sent inside the signaling path without establishing any dedicated connection.Some text in this document was borrowed from and from .The authors welcome discussion and comments related to the topics presented in this document. The preferred forum is the <sip-xmpp@xmpp.org> mailing list, for which archives and subscription information are available at .This section describes how to map an XMPP "formal session" to an MSRP session.The XMPP formal session is based on the protocol described in , which enables the initiation, renegotiation, and termination of a formal chat session on the XMPP side. This approach maps to the semantic of the SIP INVITE and BYE methods.When the XMPP user ("Juliet") wants to initiate a negotiated session with a SIP user ("Romeo"), she sends a <message/> stanza to Romeo containing a <feature/> child qualified by the 'http://jabber.org/protocol/feature-neg' namespace. The <message/> stanza must not contain a <body/> child (as specified in ), since that child element is used for human-readable text. The <message/> stanza type should be "normal". The stanza MUST contain a <thread/> element for tracking purposes (where the newly-generated ThreadID is unique to the proposed session). The encapsulated data form MUST contain a FORM_TYPE field whose type is "hidden" and whose value is "urn:xmpp:ssn"; it must also contain a boolean field named "accept".The XMPP user may request a session with a specific resource of the contact. However in this document the resource identifier will be ignored and discarded for cross-system interworking.Upon receiving such a session request, the XMPP server to which Juliet has authenticated attempts to deliver the request to a local user or attempts to route the request to the remote domain that services the hostname in the 'to' attribute. Naturally, in this document we assume that the hostname in the 'to' attribute is an IM-aware SIP service hosted by a separate server.As specified in , the XMPP server needs to determine the identity of the remote domain, which it does by performing one or more lookups. For message stanzas, the order of lookups recommended by is to first try the "_xmpp-server" service as specified in and to then try the "_im" service as specified in . Here we assume that the first lookup will fail but that the second lookup will succeed and return a resolution "_im._simple.example.net.", since we have already assumed that the example.net hostname is running a SIP instant messaging service. (Note: The XMPP server may have previously determined that the remote domain is a SIMPLE server, in which case it would not need to perform the SRV lookups; the caching of such information is a matter of implementation and local service policy, and is therefore out of scope for this document.)Once the XMPP server (example.com) has determined that the remote domain is serviced by a SIMPLE server, it hands the XMPP message off to its local XMPP-to-SIP gateway (x2s.example.com), which transforms the message into SIP syntax and routes it to the remote SIMPLE server (example.net).Here the Session Description Protocol offer specifies the MSRP-aware XMPP-to-SIP gateway on the XMPP side as well as other particulars of the session.There is no direct mapping for the MSRP URIs. In fact MSRP URIs identify a session of instant messages at a particular device; they are ephemeral and have no meaning outside the scope of that session. The authority component of the MSRP URI MUST contain the XMPP-to-SIP gateway hostname or numeric IP address and an explicit port number.Native XMPP messages as described in supports text (i.e., UTF-8) only. However, there exists an XMPP extension for XHTML-formatted messges, as defined by the XHTML-IM integration set specified in . Unless the use of XHTML-formatted messages is supported by the endpoints or negotiated during session establishment, the "accept-types" attribute that follows an MSRP media line SHOULD indicate "text/plain" as the only media-type that is acceptable to the endpoint; if XHTML is supported or negotiated, the "accept-types" attribute MAY also indicate a media-type of "text/html". (Note: The XHTML-IM integration set supports only a subset of XHTML formatting; it is the responsibility of a gateway to map between full XHTML and XHTML-IM.)As specified in , the mapping of XMPP syntax elements to SIP and SDP syntax elements SHOULD be as shown in the following table. (Mappings for elements not mentioned are undefined.)Here we assume that the SIP user agent that receives the SIP invitation (containing an offered session description that includes a session of MSRP) accepts the invitation and includes an answer session description that acknowledges the choice of media.Upon receiving such a response, the SIMPLE server or associated SIP-to-XMPP gateway SHOULD remember that this is a response to a SIP transaction related to an XMPP-SIP translation, based on the SIP Call-ID (which is functionally equivalent to the XMPP <thread/>). The SIP-to-XMPP gateway is responsible for translating the response into an XMPP message stanza and routing it from the SIP user to the XMPP server or associated XMPP-to-SIP gateway.The SIP-to-XMPP gateway MUST include in the response translation values for all the fields that the XMPP request indicated are required.The SIP-to-XMPP gateway MUST also send a SIP ACK to the SIP user.If Romeo accepted the session, Juliet MUST either complete or cancel the stanza session negotiation. The user's client SHOULD verify that the selected values of the fields are acceptable before completing the stanza session negotiation -- and confirming that the session is open -- by replying with the form 'type' attribute set to 'result'. The form MUST contain the FORM_TYPE field and the "accept" field set to "1" or "true".Upon receiving such a stanza completing the session negotiation, the XMPP server MUST NOT send any confirmation to the SIP side; instead, it MUST route the acceptance to the SIMPLE server or associated SIP-to-XMPP gateway.The session is now open and the parties can proceed to exchanging messages.Once the session is created, the endpoints can exchange an unbounded number of messages.The XMPP 'id' attribute is not required in the protocol and there is no way to enforce its use for messages. It is RECOMMENDED to include it as a negotiable item in the SSN negotiation, via the "message-ids" field. However, it is possible that the 'id' will not be present within the <message/> stanza; in this case the XMPP-to-SIP gateway MUST generate a new unique Message-ID.If the XMPP user has not explicitly requested message receipts during the negotiation, it is RECOMMENDED that the SIP-to-XMPP gateway shall insert a Failure-Report header field value of "no" during the creation of a SEND request. The XMPP user can include a request for message receipts using the Message Receipts XMPP protocol extension ; use of this extension can be negotiated via the "urn:xmpp:receipts" field during SSN negotiation.The mapping of XMPP syntax elements to MSRP syntax elements SHOULD be as shown in the following table. (Mappings for elements not mentioned are undefined.)The following examples show an exchange of messages.Upon receiving the SEND request, if the request either contains a Failure-Report header field value of "yes" or does not contain a Failure-Report header at all, Romeo's client MUST immediately generate and send a response.Romeo can then send a reply using his MSRP user agent.The SIP-to-XMPP gateway would then transform that message into appropriate XMPP syntax for routing to the intended recipient.Note: The size of the XML character data of an XMPP message is not limited by the protocol, but is sometimes limited in deployment. However messages sent using MSRP can be delivered in several SEND requests, so when the XMPP-to-SIP gateway receives a message longer then 2048, it is STRONGLY RECOMMENDED it delivers this message using as few chunks (at least 2048 octets long) as possible.If Juliet decides to terminate the negotiated chat session, her client sends a <message/> stanza to Romeo containing a data form of type "submit". The <message/> stanza MUST contain a <thread/> element with the same XML character data as the original initiation request. The data form containing a boolean field named "terminate" set to a value of "1" or "true".Upon receiving such stanza terminating the chat session, the XMPP-to-SIP gateway terminates the SIP session by sending a SIP BYE to tear down the MSRP session with Romeo's client. Romeo's SIP client then responds with a 200 OK.Upon receiving the 200 OK, the SIP-to-XMPP gateway acknowledges the termination of the chat session on the XMPP side by sending a <message/> containing a data form of type "result", and the value of the "terminate" field set to "1" or "true". The client must mirror the <thread/> value it received.If Romeo accepted the session but Juliet decides to cancel the stanza session negotiation, the flow is as follows.That is, Juliet's client shall reply with a data form containing the FORM_TYPE field and the "accept" field set to "0" or "false":Upon receiving such stanza cancelling the session negotiation, the XMPP-to-SIP gateway MUST send a SIP BYE. Once the XMPP-to-SIP gateway receives the 200 OK, the internal session data is removed and the session is officially cancelled also in the SIP-to-XMPP gateway.If the SIP user had sent any messages to XMPP while awaiting confirmation of the session, the SIP-to-XMPP gateway MUST return them to the SIP user with an appropriate error.A common scenario occurs when the SIP UA is currently unwilling or unable to accept a formal session, in which case the flow is as follows.Here the SIP UA declining an offer contained in an INVITE SHOULD return a 4xx or a 6xx response, such as 406 Not Acceptable or 603 Decline. Such a response SHOULD include a Warning header field value explaining why the offer was rejected.Upon receiving the error response for the SIP INVITE, the XMPP-to-SIP gateway shall send a "Session Reject" message back to the XMPP Client. This message contains a data form that MUST contain the FORM_TYPE field and the "accept" field set to "0" or "false". It is RECOMENDED that the form does not contain any other field even if the request indicated they are required. The client MAY include a reason in the <body/> child of the <message/> stanza. The content of the Warning header field present in the SIP response SHOULD be mapped to a "reason" field in the data form. If the Warning header is not present then the descriptive phrase of the SIP response can be used.In XMPP, the "informal session" approach is to simply send someone a <message/> of type "chat" without starting any session negotiation ahead of time (as described in ). The XMPP "informal session" approach maps very well into a SIP MESSAGE request, as described in . However, the XMPP informal session approach can also be mapped to MSRP if the XMPP-to-SIP gateway maintains additional state.The order of events is as follows.First the XMPP user would generate an XMPP chat message.The local SIP-to-XMPP gateway at the SIMPLE server would then determine if Romeo supports MSRP. If so, the SIP-to-XMPP gateway would initiate an MSRP session with Romeo on Juliet's behalf.Here we assume that Romeo accepts the MSRP session request.The XMPP-to-SIP gateway then acks the session acceptance on behalf of Juliet.The XMPP-to-SIP gateway then transforms the original XMPP chat message into MSRP.Romeo can then send a reply using his MSRP user agent.Note: As previously described, if the users have not negotiated the use message receipts, it is RECOMMENDED that the SIP-to-XMPP gateway shall insert a Failure-Report header field value of "no" during the creation of a SEND request.The SIP-to-XMPP gateway would then transform that message into appropriate XMPP syntax for routing to the intended recipient.When the MSRP user wishes to end the chat session, the user's MSRP client sends a SIP BYE.The BYE is then acknowledged by the XMPP-to-SIP gateway.Unlike the XMPP protocol, the MSRP protocol offers only one way to initiate a chat session, typically using the Session Description Protocol via the SIP offer/answer mechanism (see ).The order of events is as follows.When Romeo wants to start an MSRP message session with Juliet, he first has to start the SIP session by sending out a SIP INVITE request containing an offered session description that includes an MSRP media line accompanied by a mandatory "path" attribute and corresponding URIs. The MSRP media line is also accompanied by an "accept-types" attribute used to specify the only media-types acceptable for Romeo (i.e., text/plain and/or text/html).Note: In addition to plain text messages, MSRP is able to carry arbitrary (binary) Multipurpose Internet Mail Extensions compliant content, such as images or video clips. Disposition of media types other than text/plain and text/html is out of scope for this specification and is a matter of implementation.Upon receiving the INVITE, the SIP-to-XMPP gateway needs to determine the identity of the remote domain, which it does by performing one or more DNS SRV lookups . The SIP-to-XMPP gateway SHOULD resolve the address present in the To header of the INVITE to an im URI, then follow the rules in regarding the "_im" SRV service for the target domain contained in the To header. If SRV address resolution fails for the "_im" service, the SIP-to-XMPP gateway MAY attempt a lookup for the "_xmpp-server" service as specified in or MAY return an error to the sender (i.e. 502 Bad Gateway).If SRV address resolution succeeds, the SIP-to-XMPP gateway is responsible for translating the request into an XMPP message stanza to initiate a negotiated session from the SIP user to the XMPP user.The mapping of SIP and SDP syntax elements to XMPP syntax elements SHOULD be as shown in the following table. (Mappings for elements not mentioned in the foregoing table are undefined.)See previous note regarding negotiation and use of the XHTML-IM integration set for XHTML-formatted messages (i.e., the "text/html" accept-type).If the request is accepted then Juliet's client MUST include all the fields that were marked as required in the request message.In the example below, we assume that Juliet accepts the session and specifies that she prefers to speak Italian with Romeo.Upon receiving such a response, the SIP-to-XMPP gateway SHOULD remember that this is a response to a stanza related to an SIP-XMPP translation, based on the SIP Call-ID. The SIP-to-XMPP gateway is responsible for translating the response into a SIP response and delivering it from the XMPP user back to the SIP user.In this case, the 200 OK is routed back and is received by Romeo's UA. Finally, Romeo's client sends an acknowledgment message, ACK, to Juliet's client to confirm the reception of the final response (200 OK).Upon receiving the ACK, the SIP-to-XMPP gateway SHOULD remember this is an acknowledgment to an XMPP formal session. The SIP-to-XMPP gateway is responsible for translating the acknowledgment into a confirmation stanza, without inserting other content (e.g. a <body/> element cannot be inserted).When Romeo wants to send a message, he creates an MSRP SEND request that contains the message.Upon receiving the MSRP SEND request, the SIP-to-XMPP gateway SHOULD remember that the message is for an XMPP user. The SIP-to-XMPP gateway is responsible for translating the MSRP SEND request into an XMPP message stanza.The mapping of MSRP syntax elements to XMPP syntax elements SHOULD be as shown in the following table. (Mappings for elements not mentioned are undefined.)Upon receiving the chat message, Juliet can send a reply.When Romeo wants to terminate the session, he is required to send a SIP BYE request.Upon receiving the SIP BYE request, the XMPP-to-SIP gateway SHOULD translate the request to a <message/> stanza containing a data form of type "submit". The <message/> element MUST contain a <thread/> element with the same XML character data as the original initiation request. The data form containing a boolean field named "terminate" should be set to a value of "1" or "true".Juliet explicitly acknowledges the termination of the chat session on the XMPP side by sending a <message/> containing a data form of type "result", and the value of the "terminate" field set to "1" or "true". The client MUST mirror the <thread/> value it received.Upon receiving the acknowledgment message, the XMPP-to-SIP gateway SHOULD translate it to a SIP answer 200 OK.A common scenario occurs when the SIP user issues an invitation to set up a chat session with an XMPP user and immediately after the SIP invitation is sent, the SIP user decides to cancel it. The SIP-to-XMPP gateway will receive the CANCEL request and using the Call-ID, To, From and CSeq (sequence number only) header field values as a guide, will issue an XMPP stanza session termination request to the XMPP user to cancel the XMPP formal session (assuming that it was already set up). Once the XMPP-to-SIP gateway receives an ACK stanza message for the session termination, the XMPP-to-SIP gateway will respond with a status of 200 (OK) back to the SIP user. It is important to note that if the SIP session transaction does not exist, the XMPP-to-SIP gateway will return a status of 481 (Transaction Does Not Exist) back to the SIP User.Another common scenario occurs when the XMPP UA is currently not willing or able to accept a formal session request. The XMPP UA SHOULD decline the invitation. The data form MUST contain the FORM_TYPE field and the "accept" field set to "0" or "false". It is RECOMMENDED that the form does not contain any other fields even if the request indicated they are required.Upon receiving the declined response for the XMPP formal session request, the XMPP-to-SIP gateway SHOULD return a 4xx or a 6xx SIP response back to the SIP client.If the XMPP recipient of a formal session request does not support stanza session negotiation as specified in , it will return an XMPP <service-unavailable/> stanza error. Upon receiving this error from the XMPP recipient, the XMPP-to-SIP gateway SHOULD return a 501 SIP response back to the SIP sender.When an MSRP client sends messages through a gateway to an XMPP client that does not support formal sessinos, the order of events is as follows.To follow.This document requests no actions of IANA.Key words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keyword
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
SIP: Session Initiation ProtocolThis document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS TRACK] An Offer/Answer Model with Session Description Protocol (SDP)This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS TRACK] Address Resolution for Instant Messaging and PresencePresence and instant messaging are defined in RFC 2778. The Common Profiles for Presence and Instant Messaging define two Universal Resource Identifier (URI) schemes: 'im' for INSTANT INBOXes and 'pres' for PRESENTITIES. This document provides guidance for locating the resources associated with URIs that employ these schemes. [STANDARDS TRACK] The Message Session Relay Protocol (MSRP)This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol. [STANDARDS TRACK]Extensible Messaging and Presence Protocol (XMPP): CoreThe Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions. This document obsoletes RFC 3920. [STANDARDS-TRACK]Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and PresenceThis document defines extensions to core features of the Extensible Messaging and Presence Protocol (XMPP) that provide basic instant messaging (IM) and presence functionality in conformance with the requirements in RFC 2779. This document obsoletes RFC 3921. [STANDARDS-TRACK]Stanza Session Negotiationian.paterson@clientside.co.ukstpeter@jabber.orgInterworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): CoreAs a foundation for the definition of application-specific, bi-directional protocol mappings between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions.Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant MessagingThis document defines a bi-directional protocol mapping for the exchange of single instant messages between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP).Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message BodiesInnosoft International, Inc.1050 East Garvey Avenue SouthWest CovinaCA91790US+1 818 919 3600+1 818 919 3614ned@innosoft.comFirst Virtual Holdings25 Washington AvenueMorristownNJ07960US+1 201 540 8967+1 201 993 3032nsb@nsb.fv.comSTD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for(1) textual message bodies in character sets other than US-ASCII,(2) an extensible set of different formats for non-textual message bodies,(3) multi-part message bodies, and(4) textual header information in character sets other than US-ASCII.These documents are based on earlier work documented in RFC 934, STD 11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.This initial document specifies the various headers used to describe the structure of MIME messages. The second document, RFC 2046, defines the general structure of the MIME media typing system and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final document, RFC 2049, describes MIME conformance
criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.These documents are revisions of RFCs 1521, 1522, and 1590, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions.A DNS RR for specifying the location of services (DNS SRV)Troll TechWaldemar Thranes gate 98BOsloN-0175NO+47 22 806390+47 22 806380arnt@troll.noInternet Software Consortium950 Charter StreetRedwood CityCA94063US+1 650 779 7001Microsoft CorporationOne Microsoft WayRedmondWA98052USlevone@microsoft.comThis document describes a DNS RR which specifies the location of the
server(s) for a specific protocol and domain.Session Initiation Protocol (SIP) Extension for Instant MessagingInstant 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. [STANDARDS TRACK] SDP: Session Description ProtocolThis memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. [STANDARDS TRACK]Service Discoveryjhildebrand@jabber.comreatmon@jabber.orgMulti-User Chatstpeter@jabber.orgXHTML-IMEntity Capabilitiesjhildebrand@jabber.comjajcus@jajcus.netBidirectional-streams Over Synchronous HTTP (BOSH)ian.paterson@clientside.co.ukdizzyd@jabber.orgstpeter@jabber.orgMessage Receiptsjhildebrand@jabber.comXMPP Over BOSHian.paterson@clientside.co.ukMulti-party Instant Message (IM) Sessions Using the Message Session Relay Protocol (MSRP)The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). This document defines the necessary tools for establishing multi-party instant messaging (IM) sessions, or chat rooms, with MSRP.