SIMPLE Instant Messaging Sessions (SIMS)

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. Below we list several definitions important to SIMS: SIMS node: A host that implements the SIMS protocols as a Client or a Relay SIMS Client: A SIMS role which is the initial sender or final target of messages and delivery status. SIMS Relay: A SIMS role which forwards messages and delivery status and may provide policy enforcement. Relays MAY fragment and reassemble portions of messages. Message-Taker: A SIMS Client which persistently stores messages on behalf of specific users or resources message: arbitrary MIME content which one client wishes to send to another. For the purposes of this specification, a complete MIME body as opposed to a portion of a complete message. message fragment: a portion of a complete message carried in a message/byteranges MIME type. message: binary MIME content of an arbitrary type. Each message has a unique message-id. In SIMS, messages may be broken up into pieces and sent in separate CHUNK requests. parcel: a SIMS request or response. CHUNK request parcels typically contain a portion of a complete message. end-to-end: delivery of data from the initiating client to the final target client hop: delivery of data between one SIMS node and an adjacent node. transaction: a request and response as seen from a single SIMS node. Each transaction has a locally significant transaction identifier.

The IETF SIMPLE Working Group has identified a number of scenarios where using a separate protocol for bulk messaging is desirable. In particular, the SIMPLE WG will use this facility to handle a sequence of messages as a session of media initiated using SIP, just like any other media type. The SIMPLE community has investigated many options for sessions of messages (Jabber, SIP, IMTP, and AMSX), the most recent of these called MSRP. While the wireless community has responded favorably to MSRP for point-to-point usage, the authors feel that MSRP does not sufficiently address the relay requirements of the Enterprise and Consumer IM community. Indeed, the most recent version of MSRP has completely removed any normative discussion about building relays at all. This proposal attempts to capture the benefits of MSRP (especially peer-to-peer operation) and also address these additional requirements. SIMS instead borrows heavily from the relay capabilities of IMTP. discusses how the concepts in SIMS could be implemented as MSRP extensions. The rest of this document describes SIMS as a separate protocol for conveying arbitrary MIME content in near-real time through zero or more relays, with the opportunity for store and forward. SIMS (SIMPLE Instant Messaging Sessions) can be used as a standalone protocol, or in conjunction with a rendezvous or session setup protocol such as SIP. As with MSRP, all SIMS traffic is sent over reliable, congestion-safe transports. SIMS was designed to allow SIMS clients to communicate directly, or through an arbitrary number of relays. Each client is responsible for identifying any relays acting on its behalf and providing appropriate credentials. The Goals of SIMS are listed below: convey arbitrary binary MIME data operate as a standalone protocol or as a session media protocol support client to client operation (no servers required) operate through an arbitrary number of relays for policy enforcement allow each client to control which relays are traversed on its behalf prevent unsolicited messages (spam), "open relays", and denial of service amplification allow relays to use one or a small number of TCP or TLS connections to carry messages for multiple sessions, recipients, and senders allow large messages to be sent over a slow connection without causing head-of-line blocking problems allow transmission of a large message to be interrupted and resumed in place when network connectivity is lost and later reestablished offer end-to-end notification of message receipt provide notification of message storage (desirable) easy to implement allow relays to delete state after a short amount of time

SIMS defines the concept of clients and relays. Clients send messages to relays and other clients. Relays forward messages and message delivery status to clients and other relays. Clients which can open TCP connections to each other without intervening policy restrictions, can communicate directly with each other. Clients who are behind a firewall or who need to use an intermediary for policy reasons can use the services of a relay. Each client is responsible for enlisting the assistance of one or more relays for its half of the communication. SIMS also defines the special role of a Message-Taker, which is a client that can receive messages and store them persistently on behalf of a user. Note that these roles can be co-resident. Clients which use a relay operate by first opening a connection with a relay and authenticating. When clients wish to send a short message, they send a CHUNK request with the entire contents of the message.

, Content-Type: text/plain Hi Bob, I'm about to send you "The Lord of the Rings". ]]> Each hop (relay or recipient client) that receives a CHUNK request acknowledges receipt of the request before forwarding. For larger messages, each CHUNK request may contain only a portion of the complete message. To avoid confusion and ambiguity, each request or response is called a "parcel". When Alice sends Bob a 4GB file called "The Lord of the Rings.mpeg", she will sends several CHUNK requests (parcels) each with one part of the complete message. Relays can repack parcels en-route. As individual parts of the complete message arrive at the final destination client, the receiving client sends INFORM requests indicating delivery status.

| client is spewing chunks!" | | | 200 OK | |<-----------------------| | INFORM | |<-----------------------| Message displayed | 200 OK | |----------------------->| | | ]]> When a client uses a relay, it first opens a TLS connection to its first relay and authenticates using an AUTH request which can contain Digest Authentication credentials. In a successful AUTH response, the relay provides a SIMS URI associated with the path to the client that the client can give to other clients for end-to-end message delivery. SIMS nodes can send individual portions of a complete message in multiple CHUNK requests. Each parcel uses the message/byteranges MIME type defined in RFC 2616 to correlate that part to the complete message. As each CHUNK request is received, the next hop acknowledges the request. As relays receive parcels they can reassemble or re-fragment them as long as each chunk is sent in order. Once a chunk or complete message arrives at the destination client, the destination sends an INFORM request indicating that a chunk arrived end-to-end. This request travels back along the reverse path of the CHUNK request. Unlike the CHUNK request which is acknowledged along every hop, only the sender of the INFORM request responds to an INFORM. Relays then forward the INFORM response back to the recipient of the original CHUNK.

| |<-- AUTH ------------| |<-- 401 Auth---------| |--- 401 Auth-------->| |--- AUTH ----------->| |<-- AUTH ------------| |<-- 200 OK-----------| |--- 200 OK---------->| | | | | .... time passes .... | | | | |--- CHUNK 0-3 ------>| | | |<-- 200 OK ----------| | (slow link) | |--- CHUNK 4-7 ------>|--- CHUNK 0-5 ----->| | |<-- 200 OK ----------|<-- 200 OK ---------|--- CHUNK 0-3 ------>| |--- CHUNK 8-10 ----->|--- CHUNK 6-10 ---->| ....>| |<-- 200 OK ----------|<-- 200 OK ---------| ..>| | | |<-- 200 OK ----------| | | |<-- INFORM 0-3 ------| | |<-- INFORM 0-3 -----|--- CHUNK 4-7 ------>| |<-- INFORM 0-3 ------| | ...>| |--- 200 OK --------->| | ..>| | |--- 200 OK -------->| | | | |--- 200 OK --------->| | | |<-- INFORM 4-7 ----->| | |<-- INFORM 4-7 -----|--- CHUNK 8-10 ----->| |<-- INFORM 4-7 ------| | ..>| |--- 200 OK --------->| |<-- 200 OK ----------| | |<-- INFORM done-----|<-- INFORM done -----| |<-- INFORM done -----|--- 200 OK -------->| | |--- 200 OK --------->| |--- 200 OK --------->| | |--- 200 OK -------->| | | | |--- 200 OK --------->| | | | | ]]> Relays only keep transaction state for a short period of time for each chunk. Delivery of each hope should take no more than 32 seconds after the last byte of data is sent. Clients applications define their own implementation-dependent timers for end-to-end message delivery. In some cases the end user node may not have its own client or that client or node may be unavailable. In this case, a message-taker can take receipt of the message or fragment and deliver an INFORM back to the sender indicating that the message or fragment was successfully stored. For client to client communication, the sender of a message typically opens a new TCP connection if one is needed. Relays reuse existing connections first, but can open new connections (typically to another relay) to deliver a CHUNK request. INFORM requests are only delivered over an existing connection.

While SIMS is described as a standalone protocol in the bulk of this document, this proposal could be applied to MSRP while preserving the energy the SIMPLE working group has invested in discussing MSRP.

If a SIMS-inspired relay extension to MSRP is implemented, a number of changes need to be made to the core MSRP specification. Specifically, many changes are needed when the requirements of multiplexing and no head-of-line blocking are introduced. The most significant of these deals with the elimination of the VISIT command and with connection oriented media. The authors propose that the offerer initiate any needed TCP or TLS connections and immediately use a SEND to send the first message or portion of a message. SEND requests will require a new mandatory header field which correlates a message or chunk with the session responsible for that session. Likewise for some conferencing applications, it may be necessary to include the identity of the original sender of the request. Instead of relying on port numbers, connection identifiers or connection handles would be needed in an MSRP URI so that a client can provide enough information for a relay to forward over an existing TCP or TLS connection. To prevent head-of-line blocking, it is necessary for clients to be able to stop sending large messages midstream and chunk messages using the message/byteranges MIME type. (Since using multiple connections as described in section 5.1 of MSRP is undesirable in a relay environment). Portions of messages conveyed with SEND need a corresponding message identifier to correlate them. Similarly the length value in the start line of each MSRP request should be replaced with a MIME boundary. The end of that boundary marker would signal the end of a request. TLS and TCP on the same port with no STARTTLS command would be an unacceptable implementation burden for relay providers. Either two port numbers of a STARTTLS command should be introduced. Further, it is unacceptable and of questionable usefulness to switch from TCP to TLS at any time other than immediately at connection establishment.

Other features of SIMS could be introduced as an extension to MSRP or even as a separate protocol. It is desirable for example to add an optional Route header in MSRP which clients can use to direct their request through specific relays. The "hop" SDP attribute could be added to convey this information in SIP offers and answers. Because introducing relays which can repack messages changes the way chunks are acknowledged, an end-to-end message delivery mechanism such as INFORM would be needed. A mechanism to authenticate with relays to prevent open relay and DoS amplification is needed. A mechanism similar to AUTH can be added.

SIMS defines the concept of a parcel, which is analogous to a "message" (a request or response) in HTTP, SIP, and RTSP. In SIMS, a message is a complete MIME document with a single Message-ID. Since messages can be arbitrarily large, a message can be sent in one or more piece, each piece carried in its own parcel. SIMS parcels can be either requests or responses. Like HTTP messages, SIMS Parcels consist of a start line, headers and an optional body. Requests contain a method name and the Request-URI in the start line. Responses contain a response code and response phrase in the start line. The Request-URI in a SIMS request is typically a SIMS URI. A SIMS URI takes the form sims:userinfo@hostport;param=value. For example: sims:r13-9dELHJ@server.example.com:9000;transport=tls+tcp SIMS defines three types of requests, the CHUNK request, the INFORM request, and the AUTH request. The semantics of each of these methods is described in turn. The CHUNK method is used to send a chunk of a message. CHUNK requests contain a Message-ID used to associate all the chunks of a message. In addition, an optional Thread-ID and Call-ID can correlate the chunk with a specific thread or session respectively. CHUNK requests are sent one hop at a time. Once a CHUNK request is received by a hop, that hop immediately generates a response parcel. This kind of request and response is called a per-hop transaction. CHUNK requests are per-hop for two reasons: 1) SIMS relays may pack or rechunk any message in a different set of chunks as long as they preserve ordering, and 2) since the amount of bandwidth available between each hop may be radically different, there is no way to set a sensible timer for the success or failure of a chunk delivered end-to-end.

<- 200 OK CHUNK -> <- 200 OK ]]> Chunks of messages are managed using the message/byterangesmessage/byteranges MIME container defined in RFC 2616. Each CHUNK parcel MAY contain a complete MIME body, or it MAY contain a chunk, described using message/byterange. It is not necessary to know the length of a message or a chunk before sending, although setting one or both of these can help SIMS clients receiving a message, display progress information (for example, a progress thermometer). INFORM requests are sent to indicate delivery status of a chunk. INFORM requests contain a Message-ID header with the same value as the corresponding CHUNK requests. INFORM requests are typically sent by the final recipient to indicate the delivery status of a chunk. (Note that the INFORM may provide status for a different sized chunk than sent in any of the original CHUNK requests). Other INFORM requests can be sent to indicate a forwarding delay or error condition. Unlike CHUNK transactions, INFORM transactions are multi-hop. Only the sender of the original message responds to an INFORM request. Relays forward responses to an INFORM back to the sender of the INFORM.

200 OK --> ]]> Finally, AUTH requests are used by clients with ephemeral addresses to create a handle they can use to receive incoming requests. AUTH requests can also contain credentials used to authenticate a client, and authorization policy used to block Denial of Service attacks. AUTH requests do not contain a Message-ID header. AUTH requests are discussed in more detail in Section XXX TODO. SIMS responses contain a 3-digit response code. Responses in the range 200-299 indicate a successful transaction. Responses in the ranges 400-499 and 500-599 indicate client and server errors respectively. Responses in the 600-699 range indicate that the receiver of a request has declined the request. Unlike in HTTP and SIP there are no redirection responses and no provisional responses.

SIMS parcels contain a number of header fields. Many header fields can contain an ordered list of multiple header field values separated by commas or printed on several lines with the same header name. For example, the following two Accept header fields are semantically identical (they contain the same header field values in the same order.

Accept: message/cpim Accept: text/plain Accept: message/cpim, text/plain Note that for many headers fields, the order of header field values is significant and must be preserved (for example, see the discussion on the Via and Route header fields).

There are three addresses which work in concert to properly route parcels. The Request-URI and the Route header work together to route SIMS requests: the Request-URI is the final target (Client) of the request) , and the Route header contains a list of relays (if any) which must be visited before contacting the Request-URI. The Via header contains a list of SIMS nodes used to route responses back to the sender of the request. The Via header indicates the path taken by a request so far and the path that should be followed to route responses. The "branch" parameter contains a transaction identifier which allows SIMS nodes to correlate responses with requests. [blah blah] The Route header contains a list of SIMS relays through which a request must traverse to reach a specific destination. A Route header MAY appear in any request. In a request, the top-most Route header is contacted according to the rules in [seciton foo] until the Route list is exhausted. Then the Request-URI is contacted. In addition, a Route header MUST appear in any 2xx response to an AUTH request. This indicates the list of URIs that the client should advertise for requests targetted to the client. The Max-Forwards header contains an integer value of the maximum number of nodes the current request may pass through, before a 483 Too Many Hops error is generated. The Max-Forwards header prevents infinite message forwarding loops. When a client sends a request for the first time, it sets the Max-Forwards header to the default starting value of 20.

The Message-ID header contains a identifier unique to each message. The Message-ID header MUST be present in CHUNK and INFORM requests. In CHUNK requests it is used to associate multiple portions of a message (sent in several CHUNK requests) for reassembly. In INFORM requests it is used to correlate delivery status with the appropriate message. The Message-ID header MUST NOT be sent in responses. The Thread-ID header is an optional header which can contain a unique identifier for threading related messages which do not share a common session (for example in a conference, group chat, or data collaboration). The Call-ID header is optional in CHUNK and INFORM requests to correlate a message with a session identifier from other protocols such as SIP. The Delivery-Status header contains the status of delivery of a portion of a message. The status is indicated by one of the following tokens. The portion of the message is identified by a byterange. [need more!] Copy a bunch of the values from RFC xxxx on message delivery disposition. These include dispositions such as displayed, dispatched, processed, deleted, denied, failed. the delivery status can indicate a portion of the relevant message was received (with the range parameter), whether the status was caused by human or automatic action, and can include an additional 3-digit error code. The Message-Context header contains ... text-message or multimedia-message = email. instant-message and page-message are instant.

The Accept header contains a list of the MIME types that the sender of the parcel supports. Note that SIMS mandatory to implement types do not need to be included in this list. An empty list implies support for only the mandatory to implement types. The Accept-Language header contains a list of preferred languages for reason phases, message bodies, delivery status, and other textual information. The "q" parameter specifies the relative preference among the listed languages, with the default value of 1.0 the most preferred. The Content-Disposition header described how the content of the body is to be interpreted. This header is copied from RFC 2183. The value "inline" means to render the content immediately, while "attachment" means to store the attached MIME type as a file. An instant-message with Content-Disposition of attachment is a bit like a file transfer. The Content-Language header describes the language of the contents of the body. It is optional. The Content-Length header describes the length of the content of the body. It's use is optional when there is no body, or if there is a body which has natural MIME boundaries. The Content-Type header describes the MIME type of the content. The Content-Type header MUST be present if a body is present. The Content-Type header MUST be present in CHUNK requests, even if no body is present. The Message-Context header defined in RFC 3458 describes the context of a message (for example: fax-message, voice-message, page-message, instant-message). This specification extends this header with two additional context values: instant-message, and file-delivery.

The Allow header contains a list of method names supported by the sender of the parcel. The Require header contains a list of option tags which the other client must support. In a request, this indicates a list which the target client MUST support for the request to succeed. If the target client does not support these options it returns a 420 "Unsupported Extension" error response and includes a list of the option tags it does not understand in an Unsupported header field. In a 421 "Extension Required" response, this indicates a list of option tags which the responder expected the requester to advertise in a Supported header field value in the request. The Supported header lists all the extensions supported by the sender of a parcel. The Supported header MAY included in any request, but it MUST be included in any 420 response. The Unsupported header lists all the extensions in a request which where not supported or understood by the sender of a parcel. The Unsupported header is only sent in a 420 "Bad Extension" response.

The Authentication-Info header provides optional information for HTTP Digest authentication. This header MAY be included in the response to an AUTH request. Semantics of the header are described in RFC 2617 The Authorization header contains authentication credentials for HTTP Digest authentication in an AUTH request. Section [x.y] . Note that the parameters of this header are separated by commas instead of semicolons. The presence of commas in this header does not imply that there is more than one header field value for this header field (only one header field value is allowed). Semantics of the header are described in RFC 2617. This header MUST NOT appear in any parcel other than an AUTH request. The WWW-Authenticate header [more]

The Date header contains the date and time in RFC 1123 format. In SIMS, the date and time are always expressed in the "GMT" timezone. The Expires header in a provides a relative time after which the action implied by the method of the request is no longer of interest. In a request, the Expires header indicates how long the sender would like to . In a response, the Expires header indicates how long the responder considers this information relevant (if the responder [more] The Min-Expires header contains the minimum duration a server will permit in an Expires header. It is sent only in 423 "Interval Too Brief" responses. The Retry-After header [more]

The Error-Info header provides a pointer to additional information about an error-code in a response, or delivery error (conveyed in an INFORM request). The Warning header [snore, maybe we should delete this one]

The Server header contains information about the software used to handle the request. Use of this header is useful for debugging and troubleshooting, but can also reveal potentially private information. The User-Agent header contains information about the software used to initiate the request. Use of this header is useful for debugging and troubleshooting, but can also reveal potentially private information.

The following table explains which headers are optional (o), mandatory (m), or not appropriate (-) for requests and responses to each method defined in this specification. For the requests, a specific 3-digit code indicates that the header is only meaningful for that specific code. The code 4xx indicates that the header is valid in any 400-class response.

Requests Responses CHUNK INFORM AUTH ??? CHUNK INFORM AUTH ??? Accept o o o o 4xx 4xx 4xx 4xx Accept-Language o o o o 4xx 4xx 4xx 4xx Allow o o o o - - 405 405 Authentication-Info - - - - - - o - Authorization - - o - - - - - Call-ID o o - o - - - - Content-Disposition o o o o o o o o Content-Language o o o o o o o o Content-Length o o o o o o o o Content-Type m o o o o o o o Date o o o o o o o o Delivery-Status - m - - - - - - Error-Info - o - - 4xx 4xx 4xx 4xx Expires o o o o o o o o Max-Forwards m m m m - - - - Message-Context o - - - - - - - Message-ID m m - o - - - o Min-Expires - - - - 423 423 423 423 Require o o o o 421 421 421 421 Retry-After - o - o 501 501 501 501 Route o o o o - - 2xx - Server - - - - o o o o Supported o o o o o o o o Thread-ID o o - o - - - - Unsupported - - - - 420 420 420 420 User-Agent o o o o - - - - Via m m m m m m m m Warning - o - - 4xx 4xx 4xx 4xx WWW-Authenticate - - - - - - 401 -

All parcels MUST contain a Via header field. Clients and relays set the Via header when sending requests and consume the Via on the return to route responses. The Route header is used to provide a list of relays to traverse before visiting the Request-URI. The Message-ID header is used in CHUNK and INFORM requests to refer to a specific message. The Delivery-Status header is used in INFORM requests to indicate the status of a chunk or an entire message. Some examples:

Delivery-Status: ok;range=0-131071 Delivery-Status: ok;range=* Delivery-Status: stored Delivery-Status: failure;error=disk-full Other Optional headers (temporal relevance, priority) Note Expire header must look like Expire: 3600 meaning expires 3600 seconds in future. Absolute times are not supported.

Response codes semantically convey the success or failure of a request. These meaning of each response code is described briefly. 200 OK indicates that the request was successful. 202 Accepted indicates that the request was accept for further processing.

[TODO: fill-in semantics] 400 Bad Request 401 Unauthorized 402 Payment Required 403 Forbidden 404 Not Found 405 Method Not Allowed 406 Not Acceptable 408 Request Timeout 409 Puzzle Required 410 Gone 413 Request Entity Too Large 414 Request-URI Too Large 415 Unsupported Media Type 416 Unsupported URI Scheme 420 Bad Extension 421 Extension Required 423 Interval Too Brief 480 Temporarily not available 481 Message/Transaction Does Not Exist 482 Loop Detected 483 Too Many Hops 488 Not Acceptable Here 491 Request Pending 493 Undecipherable 500 Internal Server Error 501 Not Implemented 503 Service Unavailable 504 Server Time-out 603 Decline indicates that the request was declined due to user or administrator policy

Body handling and use of message/byteranges

CHUNK Content-type: multipart/byteranges; boundary=------bound123456 -------bound123456 Content-type: text/plain Content-range: bytes 0-2/8 hi -------bound123456-- The "0" indicates that the data in this body starts is for byte location 0 in the complete message. The "2" is a hint of the byte position of the last byte in this chunk but MUST be ignored if the actual size is different. The "8" indicates the size of the total parcel. If it is unknown, a * would be used. An important feature of the way the bodies are defined is that a network element sending a message, can decide to change the size of what it is sending after it starts sending. For example, say that an element has 500 bytes of a message that start at location 1000 to 2000. It expects to send all 500 bytes but after sending the first 5 bytes that contain the the word hello, the element discovers there is a higher priority message that it needs to send over the same link. It closes off the first messages. The receiver will get something that looks like:

CHUNK Content-type: multipart/byteranges; boundary=-----bound123456 -------bound123456 Content-type: text/plain Content-range: bytes 1000-1499/8000 12345 -------bound123456-- If a relay has selected a boundary marker of "bound1234" and encounters the string "bound1234" in the data it is sending. It can just close off the current parcel and start a new one so there is no need to escape any of the data inside of the multipart bodies. The multipart boundaries are constructed in a special way to allow for simple high speed parsing of them. In addition to the two dashes (-) that are normally before a boundary, the boundary itself MUST start with five additional dashes followed by a string that MUST have at least 16 bits of randomness in it. For example, a valid boundary would be "boundary=-----6ea7" where the 6ea7 was a randomly chosen four digit hexadecimal number. The advantage of this is there will always be several "-" in a row in the boundaries that the scanner is searching for. This guarantees that 4 of then will be aligned on a 32 bit boundary and the scanner can quickly look for them by just looking for a 32 bit value that is equal to the "----". Once this word is found, the scanner can carefully check and see if this is the boundary it is looking for or just some random data. All SIMS clients and relays must support multipart/related, multipart/mixed, message/byteranges, and multipart/signed MIME types. It is not required to check the signatures if they don't support S/MIME but they still need to be able to receive the content in a multipart/signed messages. Any MIME type that is acceptable for content (such as text/plain) must also be supported inside any supported MIME container.

To send a new request, clients start by setting the Request-URI to the final target (the URI of the receiving client) and the method of the request (ex: CHUNK, AUTH, INFORM). The client also includes a Max-Forwards header with the default value (20), and a Via identifying itself. If the requests needs to be routed through any relays, those relay should be listed in a Route header field. If a body is present in the request, the appropriate Content-* headers need to be present (for example: Content-Type, Content-Disposition, Content-Length). If the attached content is large as defined by local policy, the outermost MIME container SHOULD be of the type message/byteranges. If any extensions involving option-tags are required, the client includes these in a Require header field. The client also includes any method-specific headers and any optional headers desired. When a new request is ready to send, the client MUST determine the next-hop target URI by taking the URI in the topmost Route header field value if one exists or the Request-URI if no Route header field values exist. Once the next-hop URI is determined, the client MUST use the resolution rules described in to find the appropriate address, port, and transport to use. Next the client MUST check if there is already an existing suitable connection to the next-hop target. If so, the client MUST send the request over the most suitable connection. Suitability MAY be determined by a variety of factors such as measured load and local policy, however in most simple implementations a connection will be suitable if it exists and is in an active state. If the client wants to interrupt sending a request after the request headers have been sent (while sending the body contents) to deliver another parcel, the client SHOULD close the MIME boundary associated with the outermost request body, and therefore complete the request early. Clients MUST NOT interrupt sending parcel start lines (the request or response line) or parcel headers. In addition, clients SHOULD chunk messages based on the amount of data sent in a configurable amount of time. The default time for a chunk is one minute. After the last byte of the request is sent, the client MUST set a timer for 32 seconds. If a response to that request is not received within 32 seconds, the client will consider that the request failed. When receiving a response, all SIMS nodes MUST verify that the top Via header field value corresponds to the node receiving the response, and that the branch tag matches a valid transaction for that node. If either case is not true the client SHOULD silently discard the response. If the branch tag matches a valid transaction, the client MUST mark the transaction completed. If the client receives a success response, it should continue sending any additional portions of the relevant outstanding message. If the client receives a recoverable error (for example a 416 Not Acceptable response), the client SHOULD try to resubmit the request if it is capable after modifying the request to address the nature of the error. Note that any resubmitted request MUST have a different transaction identifier than the original request. When sending a CHUNK request, the client MUST include a Message-ID header, and MAY add Thread-ID, Call-ID, Content-Disposition, and Message-Context headers to further identify the handling of the content of the message. If the client wishes to convey that the parcel is no longer relevant after some time period, it can include an Expires header field indicating when the chunk should no longer be forwarded. When sending an INFORM request, the client MUST include a Message-ID header and a Delivery-Status header. The client MAY also include Error-Info, Retry-After, and Warning headers if the Delivery-Status does not indicate successful delivery. When sending an AUTH request, the client MAY add an Expires header to request a SIMS URI that is valid for no longer that the provided interval. If an AUTH request returns a 401 Unauthorized request, the client SHOULD fetch the Digest challenge from the WWW-Authenticate header in the response and retry the AUTH request, including an Authorization header with the Digest response. Unlike in HTTP and SIP, Digest authentication in SIMS is only permitted for AUTH requests.

Upon receiving a valid SIMS request, SIMS clients add a "received" parameter to the topmost Via to indicate to the client the connection handle over which the request arrived. Clients MUST verify the Request-URI corresponds to an address managed by the client. (A collocated client and relay would handle the request as a relay). If the request is unacceptable for any reason, the client creates an appropriate error response and returns it over the connection from which the request arrived. To form a request, a client deletes all the headers from the response except for the Via headers. If an extension is required in the response, the client includes the required option-tags in a Require header. If a body is present (typically one is not), include the appropriate Content-* headers. If an error occurred, the client SHOULD include any headers mentioned in the description of the corresponding response code. (For example the Accept header should be included in a 416 Not Acceptable response). The receiving client MAY also include Retry-After, Error-Info, and/or Warning header fields. If the request was successful, the client returns a 200 or 202 response and may optionally include an Expires header indicating the actual time after which the receiving client will ignore the contents of the request. When a client receives a CHUNK request, it SHOULD send an INFORM request to the client which initiated the content indicating the delivery status of the corresponding message.

A SIMS client that receives a CHUNK request MUST respond with a final response immediately. A 200-class response indicates the successful delivery of the message fragment to the final hop, but does not mean that the message has been read by the user. The final response to the CHUNK MUST be sent to the previous hop, which could be a SIMS relay or the sender of the CHUNK. The 2xx response to the CHUNK MUST NOT contain a body. A 4xx or 5xx response indicates that the message was not delivered successfully. A 6xx response means it was delivered successfully, but refused. The client SHOULD reconstruct the original message sent by combining the message fragments that it receives in different CHUNK requests with the same messageID. It SHOULD not display or store the message until the entire message has been reconstructed. After the final response has been sent, the client MUST send back an INFORM to the sender of the CHUNK request,indicating the successful end-to-end delivery of the message fragment. For more details on constructing the INFORM request, see section . After the message has received fully, the client may display the message to the user. If the CHUNK expires before the client is able to present the message to the user, the client SHOULD handle the message based on local policy. Example policies include: deleting the message without displaying it, displaying to the user with an indication that the message is expired, or some other policy. If the message is displayed, the client SHOULD clearly indicate to the user that the message has expired.

When a client or a note taker receives a message parcel, it MUST send an INFORM request that indicates the byte range that has been received. The route header for this INFOM message is formed by looking at the Via headers of the CHUNK request that was received. If an error response is received when sending an INFOM, it is not retried. A relay can also send an INFORM to indicate that some error happened when sending sending a parcel. It is possible to get INFORM requests a long time after the original message was sent. If a client receives an INFORM for a message it knows nothing about, it can discard the INFORM.

Clients can be configured (typically through discovery or manual provisioning) with a list of relays they need to use. They MUST be able to form a connection to each relay and send an AUTH command to get a URI that can be used in route headers. The client can authenticate the relay by looking at the relay's TLS certificate. The relay MUST authenticate the client using digest authentication. The relay will return a URI, or list of URIs, in the Route header of the response. When using a session-protocol such as SIP, these URI can be used by the client in the route set that is sent in the SDP to setup the session. The same URI can be used for multiple session to send to the client. Example with two relays on one side. Need to AUTH to first, then use the supplied route header to AUTH to second thought the first. NOTE - only auth not auth-int is needed because TLS provides integrity When a client wishes to use more than one relay, they must AUTH to each relay they wish to use. Consider a client A, that whishes messages to flow from A to the first relays, R1, then on to a second relays, R2. This client with do a normal AUTH with R1. It will then do an AUTH transaction with R2 that is routed through R1. The client will form this AUTH messages by setting the request URI to R2 and adding a route header with the URI learned from R1 then sending this message to R1. R1 will forward this like a INFORM request is forwarded to R2. When the client sends an AUTH request, it may set the Expires header a relative time. The relay will return a URI that is only valid for that periods of time.

Clients should open connection whenever they wish to deliver a request and no suitable connection exists. For client to client connections, a client should close a connection when there are no longer any sessions associated with the connection. For connections to relays, the client should leave a connection up until no sessions are using the connection for a locally defined period of time, which defaults to 5 minutes for foreign relays and one hour for the client's relays.

Like clients receiving requests, relays receiving requests MUST add a "received" parameter to the top most Via header. Relays then examine the topmost Route header field value and remove this if it matches a URI corresponding to the relay. If no Route header field value is present, the relay examines the Request-URI to determine if the Request-URI corresponds to the relay itself.

A SIMS relay that receives a CHUNK request MUST respond with a final response immediately. A 200-class response indicates the successful delivery of the message fragment, but does not mean that the message has been forwarded on to its next hop. The final response to the CHUNK MUST be sent to the previous hop, which could be a SIMS relay or the sender of the CHUNK. The 2xx response to the CHUNK MUST NOT contain a body. A 4xx or 5xx response indicates that the message was not delivered successfully. A 6xx response means it was delivered successfully, but refused. The SIMS relay MAY further break up the message fragment received in the CHUNK request into smaller fragments and forward them to the next hop in separate CHUNK requests. It MAY also combine message fragments received before or after this CHUNK request, and forward them out in a single CHUNK request to the next hop identified in the Route header. The SIMS relay MUST NOT combine message fragments from CHUNK requests with different messageIDs. The SIMS relay MAY choose whether to further fragment the message, or combine message fragments, or send the message as is, based on some policy which is administered, or based on the network speed to the next hop, or any other mechanism. If the SIMS relay has knowledge of the byte range that it will transmit to the next hop, it SHOULD update the message/byteranges parameter in the CHUNK request appropriately. Before forwarding the CHUNK request to the next hop, the SIMS relay MUST inspect the URI in the topmost Route header field value. If it indicates this relay, the relay removes it from the Route header field. It MUST then delete all the Via headers from the new request. Then it MUST insert a Via header into the request for itself. If the SIMS relay fails to forward the CHUNK on to the next hop, it SHOULD return an INFORM back to the sender of the CHUNK indicating the reason for failure. [how? example. see section]

When a relay receives an AUTH request, it must digest challenge the request. Once the challenge is complete, it MUST provide a URI that can be used in future route headers. When the route URI is received in future messages. It MUST verify that this URI was issues by this relay. It MUST ensure that the message is either being forwarded from an entity that did the AUTH request that resulted in this URI or it is being forwarded to the the entity that did the AUTH request that resulted in this URI. The relay does not necessarily needs to save state to meet these requirements. One way that a relay could implement this is the following. When an AUTH request arrives, the relay concatenates the current time, the identity of the sender of the AUTH request, the identity of the previous hop the request came from. It then takes the concatenates string and encrypts it with a key only the relay knows and uses this for form the user portion of the sims URI that it returns. Later when it receives a URI, it can decrypt this information and use it to decide if the request should be forwarded or not. If the relay is actually several servers that share a DNS name, the URI may also encrypt which server actually has the connection to the client. When a relay receive an AUTH request, it must authenticate the client that sent it with digest, it must also authenticate the previous hop that send the message to it. When previous hop was a relay this is done with the mutual TLS while when the previous hop was a client mutual TLS MAY be used it is available or the client authorization from the digest is used. The relay will generate a URI that it a token that allows messages to be forwarded to and from this client. If the previous hop was authenticated by mutual TLS, then the URI MUST be valid to route across any connection the relay has to the previous hop relay. If the previous hop was not authenticated by mutual TLS, then the URI MUST only be valid to route across the same connection that the AUTH was received on. If this connection is closed then reopened, the URI MUST NOT be valid. Valid to route means that when the relay receives a messages that contains this URI, if the message it going to element that was the previous hop in the AUTH, then the relay can forward it and if the messages is coming from previous hop in the AUTH, then the relay can forward it to any location, otherwise the RELAY must discard the message and MAY send a INFORM indicating the auth URI was bad. If the AUTH request contains an Expires header, then the relay MUST ensure that the URI is not valid to route after the expiry time. It is possible to implement all of the above requirements without the relay saving any state. When a relay starts up it could pick a crypto random 128 bit password (K) and 128 bit initialization vector (IV). If the relay was actually a NDS farm, all the machines in the farm would need to share the same K. When an ATUH request was received the relay form a string that contains: the expiry time of the URI, an indication if the previous hop was mutual TLS authenticated or not and it it was, the name of the previous hop, if it was not the identifier for the connection which received the AUTH request. This string would be padded by appending a byte with the value 0x80 then adding zero or more bytes with the value of 0x00 until the string length is a multiple of 16 bytes long. A new random IV vector would be selected (it needs to change because it forms the salt) and the padded string would be encrypted using AES-CBC with a key of K. The IV and encrypted data and an SPI (security parameter index) that changed each time K changed would be base 64 encoded and form the user portion of the request URI. The SPI allows the key to be changed and for the system to know which K should be used. Later when the relay received this URI, it could decrypt it and check the current time was before the expiry time and check that the messages was coming from or going to the connection or location specified in the URI. Integrity protection is not required because it is extremely unlikely that random data that was decrypted would result in a valid location that was the same as the messages was routing to or from. When implementing something like this, implementers should be careful not to use a scheme like EBE that would allows portion of encrypted tokens to be cut and paste into others. Note: A successful AUTH response returns a Route header which contains a base SIMS URI that the client can use to create a number of different URIs which are all associated with the current connection.

A SIMS relay that receives an INFORM request, MUST inspect the URI in the topmost Route header field value. If it indicates this relay, the relay removes it from the Route header field. It MUST then insert a Via header into the request. Then, it MUST forward the INFORM request on to the next hop listed in the Route Header.

Relays forward responses by first verifying the topmost Via corresponds to the Via and that the response matches a valid transaction. Then the relay sends the request over the connection which corresponds to the handle in the received tag of the next Via header field value. If this connection has closed, then the response is silently discarded. A SIMS relay can distinguish between responses for an INFORM and a CHUNK request based on the transaction ID of the request (the branch tag in the Via)

Relays should keep connection open as long as possible. If a connection has not been used in a significant time (many minutes) it could be closed. If the relay runs out of resource and must close connections, it should first stop accepting new connections from clients then start closing connections on a least recently used basis.

Requests with an unknown method are forwarded as if they were INFORM requests.

A Message Taker merely acts like a Client which returns different INFORM responses. TODO - how do I let the message taker know to send all the requests it saved for me to me. I assume I still send INFOMS to the original sender as well as the message take to let them know I got the message.

The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234. Section 6.1 of RFC 2234 defines a set of core rules that are used by this specification, and not repeated here. Implementers need to be familiar with the notation and content of RFC 2234 in order to understand this specification. Certain basic rules are in uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc. Angle brackets are used within definitions to clarify the use of rule names. The use of square brackets is redundant syntactically. It is used as a semantic hint that the specific parameter is optional to use. The following rules are used throughout this specification to describe basic parsing constructs. Also, several rules are incorporated from RFC 2396 [5] but are updated to make them compliant with RFC 2234 [10]. These include:

alphanum = ALPHA / DIGIT reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" / "$" / "," unreserved = alphanum / mark mark = "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")" escaped = "%" HEXDIG HEXDIG The most frequently-used production in SIMS is the token. Unless otherwise stated, tokens are case- insensitive. Non-token characters MUST be in a quoted string to be used within a parameter value.

token = 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" ) A string of text is parsed as a single word if it is quoted using double-quote marks. In quoted strings, quotation marks (") and backslashes (\) need to be escaped. The backslash character (\) MAY be used as a single-character quoting mechanism only within quoted-string and comment constructs. Unlike HTTP/1.1, the characters CR and LF cannot be escaped by this mechanism to avoid conflict with line folding and header separation.

quoted-string = SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE qdtext = LWS / %x21 / %x23-5B / %x5D-7E / UTF8-NONASCII quoted-pair = "\" (%x00-09 / %x0B-0C / %x0E-7F) Unlike SIP/2.0 and HTTP/1.1 which allow line folding, line folding in SIMS is not allowed. In SIMS header field values, all unquoted linear white space has the same semantics as SP. A recipient MAY replace any unquoted linear white space with a single SP before interpreting the field value or forwarding the message downstream. The SWS construct is used when linear white space is optional, generally between tokens and separators. When tokens are used or separators are used between elements, whitespace is often allowed before or after the characters below.

LWS = 1*WSP SWS = [LWS] HCOLON = SWS ":" SWS EQUAL = SWS "=" SWS ; equal LPAREN = SWS "(" SWS ; left parenthesis RPAREN = SWS ")" SWS ; right parenthesis RAQUOT = ">" SWS ; right angle quote LAQUOT = SWS "<"; left angle quote COMMA = SWS "," SWS ; comma SEMI = SWS ";" SWS ; semicolon LDQUOT = SWS DQUOTE; open double quotation mark RDQUOT = DQUOTE SWS ; close double quotation mark The TEXT-UTF8 rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT-UTF8 contain characters from the UTF-8 charset (RFC 2279 [7]). The TEXT-UTF8-TRIM rule is used for descriptive field contents that are n t quoted strings, where leading and trailing LWS is not meaningful. In this regard, SIMS differs from HTTP, which uses the ISO 8859-1 character set.

When sending a response, the response is always forwarded over an existing connection using the connection handle set in the receiver parameter in the topmost Via header field value and the sent-by transport in that Via header field value to determine the correct connection. When resolving a URI (for example from a Route header field, or from the Request-URI), examine the hostport portion of the URI and the transport URI parameter to decide how to proceed. If the hostport is an IPv4 address or an IPv6 reference, send the request to that address using the port and transport specified in the URI. If no transport is provided, use the default (tls+tcp). If no port number is provided, use the default for the selected protocol (port 8999 for tcp, and port 9000 for tls over tcp). If the hostport is a domain name and an explicit port number is provided, attempt to lookup a valid address record (A, AAAA, or A6) for the domain name. Connect using the specified protocol (or the default of tls+tcp if none is specified) and port number. If a domain name is provided, but no port number, perform a DNS SRV lookup for all transports supported by the client and select the entry with the highest weight. If no SRV records are found, try an address lookup using the default port number procedures described in the previous paragraph. Note that AUTH requests MUST only be sent over a TLS-protected channel. An SRV lookup in the example.com domain might return:

;; in example.com. Pri Wght Port Target _sims+tls._tcp IN SRV 0 1 9000 server1.example.com. _sims+tls._tcp IN SRV 0 2 9000 server2.example.com. _sims._tcp IN SRV 1 1 8999 server1.example.com. _sims._tcp IN SRV 1 2 8999 server2.example.com. If implementing a relay farm, it is RECOMMENDED that each member of the relay farm have an SRV entry. If any members of the farm have multiple IP addresses (for example an IPv4 and an IPv6 address), each of these addresses SHOULD be registered in DNS as separate A, AAAA, or A6 records corresponding to a single target.

This section first describes the security mechanisms available for use in SIMS. Then the threat model is presented. Finally we list implementation requirements related to security. [TODO] Clients and Relays MUST implement TLS and Digest. AUTH requests and responses MUST be sent over a TLS-protected link.

AUTH requests SHOULD be authenticated using HTTP authentication. HTTP authentication is done as described in [RFC 2617], with the following exceptions. Basic authentication MUST NOT be used. A qop value of auth-int MUST NOT be used as the AUTH requests are integrity protected by TLS and there is no body to protect. Note that unlike in some usages of HTTP Authentication (for example, SIP), the uri parameter in the Authorize header is the same as the Request-URI in the request line of the SIMS parcel of the AUTH request. Note the BNF in RFC-2617 has an error--the value of the uri parameter MUST be in quotes. The BNF in this document is correct, as are the examples in RFC 2617.

TLS is used to authenticate relays to senders and to provide integrity and confidentiality for the headers being transported. SIMS client and relays MUST support TLS. Clients and relays MUST support the TLS ClientExtendedHello extended hello information for server name indication as described in RFC 3546. A TLS cipher-suite of TLS_RSA_WITH_AES_128_CBC_SHA MUST be supported (other cipher-suites MAY also be suported). Relays must act as TLS servers and present a certificate with their identity in the SubjectAltName using the choice type of dnsName. Relay to relay connections MUST use TLS and client to relay communications MUST use TLS for AUTH requests and responses. TODO Much More Needed

Since SIMS carries arbitrary MIME content, it can trivially carry S/MIME protected messages are well. Note that all SIMS implementations MUST support the multipart/signed MIME type even if they do not support S/MIME. Since SIP can carry a session key, S/MIME messages in the context of a session can be protected using a key-wrapped shared secret provided in the session setup.

This section discuses the threat model and the broad mechanism that must come into place to secure the protocol. The next section describes the details of how the protocol mechanism meet the broad requirements. SIMS allows two peer to peer clients to exchange messages. Each peer can select a set of relays to perform certain policy operation for them. This combined set of relays is referred to as the route set. There often exists a channel outside of SIMS, such as out-of-band provisioning or an explicit rendezvous protocol such as SIP, that can securely negotiate setting up the SIMS session and communicate the route set to both clients. A client may trust a relay with certain types of routing and policy decisions but it might or might not trust the relay with all the contents of the session. For example, a relay being trusted to look for viruses would probably need to be allowed to see all the contents of the session. A relay that helped deal with firewall traversal of the ISPs firewall would likely not be trusted with the contents of the session but would be trusted to correctly forward information. Clients need to be able to authenticate that the relay they are communicating with is the one they trust. Likewise, relays need to be able to authenticate the client is the authorized client for them to forward information to. Clients need the option of ensuring information between the relay and the client is integrity protected and confidential to elements other than the relays and clients. To simplify the number of options, traffic between relays must always be integrity protected and encrypted regardless of if the client request it or not. There is no way for the clients to tell the relays what strength of crypto to use between relays other than the clients to choose to use relays that are operated by people requiring an adequate level of security. The system also need to stop the messages from being directed to relays that are not supposed to see them. To keep the relays from being used in DDoS attacks, the relays must not forward messages unless they have a trust relationship with either the client sending or receiving the message and that they only forward that message if it is coming from or going to the client they have the trust relationship with. If a relay has a trust relationship with the client that is the destination of the message, it should not send the message anywhere except the client that is the destination. Some terminology used in this discussion is SClient is the client sending a message and RClient is the client receiving a message. SRelay is a relay the sender trusts and RRelay is a relay the receiver trusts. The message will go from SClient to SRelay1 to SRelay2 to RRelay2 to RRelay1 to RClient.

Confidentiality and Privacy from elements not in the route set is provided by using TLS on all the transports. If a client decided to not use TLS that is it's choice but relays must use TLS. Clients must implement TLS. The relays authenticate to the clients using TLS (but don't have to do mutual TLS). The clients authenticate to the relays using HTTP Digest inside of TLS. Relays authenticate to each other using mutual TLS. The clients can protect the contents so that the relays can not see them by using S/MIME encryption. End to end signing is also possible with S/MIME. The complex part is making sure that relays do not send messages place where they should not. This is done by having the client authenticate to the relay and having the relay return a token. Messages that contain this token can be relayed if they come from the client that got the token or if they are being forwarded towards the client that got the token. The tokens must only ever be seen by things in the route set or other elements that at least one of the parties trusts. If some 3rd party discovers the token that RRelay2 uses to forward messages to RClient, then that 3rd party can send as many messages as they want to RRelay2 and it will forward them to RClient. The 3rd party can not cause them to be forwarded anywhere except to RClient eliminating the open relay problems. SRelay1 will not forward the message unless it contains a valid token. When SClient goes to get a token from SRelay2, this request is relayed through SRelay1. SRelay authenticates that it really is SClient requesting the token but it generates a token that is only valid for forwarding messages to or from SRelay1. SRelay two knows it is connected to SRelay1 because of the mutual TLS. The tokens are carried in the user portion of the SIMS URLs. Issues: How to tokens expire - rekeying. Will probably use Expire header on AUTH response. Token MAY be valid for between 10 minutes and 24 hours with 1 hour recommended. Both sides need to do a SIP re-invite to set up new tokens before the old one expires. Issues: Token good for single session or for all session Note: tokens are only required for relays, not clients or note takers. TODO talk about where client to client and A, RA, B

While this specification already implements a number of significant improvements to prevent unsolicited messaging and Denial of Service, additional mechanisms are envisioned being useful in the future. The 402 Payment Required and 409 Puzzle Required response codes are reserved for future use and may be useful to further discourage unsolicited messages.

SIMS uses port XXX for SIMS over TCP and port YYY for TLS over TCP. These port numbers should be determined by allocation from IANA.

This document defines the sims: URI scheme.

Scheme: sims Syntax: Defined in Section 7 of this document Character-Encoding: UTF-8 Intended Usage: Real-time delivery of MIME content, especially instant messages Protocol: SIMPLE Instant Messaging Sessions (SIMS) Security Considerations: Section 9 of this document Relevant Publications: This document

This document registers the message-context: "instant-message". The contact person is Rohan Mahy, rohan@cisco.com.

This document registers the following SDP parameters:

[TODO] accept and hop attributes

In order for two SIMS clients to communicate with each other, they need to negotiate the characteristics of the SIMS session. These include the addresses where messages can be sent, the path that the SIMS requests/responses should take, and the content type that is acceptable to both ends. This information MAY be exchanged and agreed upon between two SIMS clients using a session setup protocol like SIP, and the negotation of the session characteristics MAY be done using the offer-answer approach with SDP contained in the SIP messages. The Call-ID of the SIP session SHOULD be used as the Call-ID in the SIMS messages, so that the correlation between the media and the control signaling can be achieved.

There will be an m-line in the SDP for the SIMS session. The m-line has the form:

]]>

The media type for a SIMS session SHOULD be "message". The port is not used. The protocol should be sims/tcp or sims/tcp+tls. And the format list is not used. It should be set to "*". The m-line used to define a SIMS session has two attributes: the hop attribute and the accept-type attribute. CHUNK requests can carry any MIME encoded payload. Endpoints specify MIME content types that they are willing to receive in the accept types "a"-line attribute. This attribute has the following syntax:

accept-types = accept-types-label ":" format-list accept-types-label = "accept-types" format-list = format-entry *( SP format-entry) format-entry = (type "/" subtype) type = token subtype = token SDP offers for SIMS sessions MUST include an accept-types attribute. SDP answers MUST also include the attribute, which MUST contain either the same list as in the offer or a subset of that list. If no format-entry is specified in the accept-types attribute, it indicates that the sender may attempt to send messages with media types that have not been explicitly listed. If the receiver is able to process the media type, it does so. If not, it will respond with a 415. Note that all explicit entries SHOULD be considered preferred over any non-listed types. This feature is needed as, otherwise, the list of formats for rich IM devices may be prohibitively large. The accept-types attribute may include container types, that is, mime formats that contain other types internally. If compound types are used, the types listed in the accept-types attribute may be used both as the root payload, or may be wrapped in a listed container type. (Note that the container type MUST also be listed in the accept-types attribute.) Clients specify the relays they wish to use in an "a=hop" attribute line in the SDP. A SIP answer only contains the relays that that side wishes to use, it does not include the relays that the client that made the offer wishes to use. This attribute line has the following syntax:

hop-attribute = hop-label ":" sims-url hop-label = "hop" There can be several hop labels in the SDP and they are associated with the m line that proceed them. The top hop one corresponds to the relay closest to the client that is sending the SDP and the next hop corresponds to the next relay out and so on.

[More TODO] Before a SIMS session can start, both sides need to communicate the relays they wish to use. One client puts the relays they wish to use in an SDP offer and sent it via SIP to the other client which adds the relays it which to use and sends the complete list of relays back in the answer. The SDP for an offer looks like:

c=IN IP4 invalid.none m=message 1234 sims/tcp+tls alice@alice.example.com a=accept: message/cpim text/plain text/html a=hop:sims:magic456@a.example.com:1234;transport=tcp+tls While the SDP for the answer would be:

c=IN IP4 invalid.none m=message 1234 sims/tcp+tls bob@bob.example.com a=accept: message/cpim text/plain a=hop:sims:magic789@b1.example.com:1234;transport=tcp+tls a=hop:sims:magic012@b2.example.com:1234;transport=tcp+tls explain above example Define how SDP works TODO define a=accept TODO define a=hop

TODO - Topics to compare: TCP fan out, HOL blocking, next hop congestion at a relay, congestion back pressure, robust sending of a message even as host temporarily disconnects and reconnects. scale, relay farms, multiple relays,

[TODO]

Many thanks to the following members of the SIMPLE WG for spirited discussions on session mode: Ben Campbell, Jonathan Rosenberg, Robert Sparks, Paul Kyzivat, Allison Mankin, Jon Peterson, Brian Rosen, Dean Willis, Adam Roach, Aki Niemi, Hisham Khartabil, Pekka Pessi, and Chris Boulton