SIMPLE WG                                                    C. Jennings
Internet-Draft                                                   R. Mahy
Expires: October 19, 2004                            Cisco Systems, Inc.
                                                          April 20, 2004

      Relay Extensions for Message Sessions Relay Protocol (MSRP)

Status of this Memo

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

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

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

   The list of current Internet-Drafts can be accessed at http://

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on October 19, 2004.

Copyright Notice

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


   The SIMPLE Working Group uses two separate models for conveying
   instant messages.  Pager-mode messages stand alone, whereas
   Session-mode messages are setup as part of a session using the SIP
   protocol. MSRP (Message Sessions Relay Protocol) is a protocol for
   near-real-time, peer-to-peer exchange of binary content without
   intermediaries, which is designed to be signaled using a separate
   rendezvous protocol such as SIP.  This document introduces the notion
   of message relay intermediaries to MSRP and describes the extensions
   necessary to use them.

Jennings & Mahy         Expires October 19, 2004                [Page 1]

Internet-Draft                MSRP Relays                     April 2004

Table of Contents

   1.    Conventions and Definitions  . . . . . . . . . . . . . . . .  3
   2.    Introduction and Requirements  . . . . . . . . . . . . . . .  3
   3.    Protocol Overview  . . . . . . . . . . . . . . . . . . . . .  4
   4.    New Protocol Elements  . . . . . . . . . . . . . . . . . . . 10
   4.1   The AUTH Method  . . . . . . . . . . . . . . . . . . . . . . 10
   4.2   The Use-Path header  . . . . . . . . . . . . . . . . . . . . 10
   4.3   Authentication headers . . . . . . . . . . . . . . . . . . . 10
   4.4   Time-related headers . . . . . . . . . . . . . . . . . . . . 11
   5.    Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 11
   5.1   Client behavior  . . . . . . . . . . . . . . . . . . . . . . 11
   5.1.1 Connecting to relays acting on your behalf . . . . . . . . . 11
   5.1.2 Sending requests . . . . . . . . . . . . . . . . . . . . . . 12
   5.1.3 Receiving Requests . . . . . . . . . . . . . . . . . . . . . 13
   5.1.4 Managing Connections . . . . . . . . . . . . . . . . . . . . 13
   5.2   Relay behavior . . . . . . . . . . . . . . . . . . . . . . . 13
   5.2.1 Handling Incoming Connections  . . . . . . . . . . . . . . . 13
   5.2.2 Generic request behavior . . . . . . . . . . . . . . . . . . 13
   5.2.3 Receiving AUTH requests  . . . . . . . . . . . . . . . . . . 13
   5.2.4 Forwarding SEND requests . . . . . . . . . . . . . . . . . . 15
   5.2.5 Forwarding non-SEND requests . . . . . . . . . . . . . . . . 16
   5.2.6 Forwarding Responses . . . . . . . . . . . . . . . . . . . . 16
   5.2.7 Managing Connections . . . . . . . . . . . . . . . . . . . . 17
   5.2.8 Forwarding unknown requests  . . . . . . . . . . . . . . . . 17
   5.3   Acting as a Message Taker  . . . . . . . . . . . . . . . . . 17
   6.    Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . 17
   7.    Finding MSRP Servers . . . . . . . . . . . . . . . . . . . . 19
   8.    Security Considerations  . . . . . . . . . . . . . . . . . . 20
   8.1   Using HTTP Authentication  . . . . . . . . . . . . . . . . . 20
   8.2   Using TLS  . . . . . . . . . . . . . . . . . . . . . . . . . 20
   8.3   Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 20
   8.4   Security Mechanism . . . . . . . . . . . . . . . . . . . . . 21
   8.5   Preventing Spam and Denial of Service Attacks  . . . . . . . 22
   9.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 23
   10.   Example SDP with multiple hops . . . . . . . . . . . . . . . 23
   11.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 23
         Normative References . . . . . . . . . . . . . . . . . . . . 24
         Informative References . . . . . . . . . . . . . . . . . . . 25
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26
         Intellectual Property and Copyright Statements . . . . . . . 27

Jennings & Mahy         Expires October 19, 2004                [Page 2]

Internet-Draft                MSRP Relays                     April 2004

1. Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC-2119 [1].

   Below we list several definitions important to MSRP:
      'MSRP node:' A host that implements the MSRP protocols as a Client
      or a Relay
      'MSRP Client:' A MSRP role which is the initial sender or final
      target of messages and delivery status.
      'MSRP Relay:' A MSRP role which forwards messages and delivery
      status and may provide policy enforcement.  Relays MAY fragment
      and reassemble portions of messages.
      'Message-Taker:' A MSRP 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
      (for example) a message/byteranges MIME type.
      'message:' binary MIME content of an arbitrary type. Each message
      has a unique message-id.  In MSRP, messages may be broken up into
      pieces and sent in separate SEND requests.
      'end-to-end:' delivery of data from the initiating client to the
      final target client
      'hop:' delivery of data between one MSRP node and an adjacent
      'transaction:' a request and response as seen from a single MSRP
      node.  Each transaction has a locally significant transaction

2. Introduction and Requirements

   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 [2], just like
   any other media type.  (The benefits of the session-mode approach are
   further discussed in [19].) The SIMPLE Working Group has also
   developed MSRP (the Message Sessions Relay Protocol) to convey
   sessions of messages directly between two end systems with no
   intermediaries.  With MSRP, messages can be arbitrarily large and all
   traffic is sent over reliable, congestion-safe transports.

   This document describes extensions to the core MSRP protocol to
   introduce intermediaries called Relays.  With these extensions MSRP
   clients can communicate directly, or through an arbitrary number of

Jennings & Mahy         Expires October 19, 2004                [Page 3]

Internet-Draft                MSRP Relays                     April 2004

   relays.  Each client is responsible for identifying any relays acting
   on its behalf and providing appropriate credentials.  Clients which
   can receive new TCP connections directly do not have to implement any
   new functionality to work with these relays.

   This document is far from complete, but was submitted to allow the
   SIMPLE WG to understand the proposed concept and bring up issues with
   the general approach.

   The Goals of the MSRP Relay extensions are listed below:
   o  convey arbitrary binary MIME data without modification or transfer
   o  continue to support client to client operation (no relay servers
   o  operate through an arbitrary number of relays for policy
   o  allow each client to control which relays are traversed on its
   o  prevent unsolicited messages (spam), "open relays", and denial of
      service amplification
   o  allow relays to use one or a small number of TCP or TLS [3]
      connections to carry messages for multiple sessions, recipients,
      and senders
   o  allow large messages to be sent over a slow connection without
      causing head-of-line blocking problems
   o  allow transmission of a large message to be interrupted and
      resumed in place when network connectivity is lost and later
   o  offer notification of message failure at any intermediary
   o  provide notification of message storage (desirable)
   o  allow relays to delete state after a short amount of time

3. Protocol Overview

   With the introduction of this extension, MSRP has the concept of both
   clients and relays.  Clients send messages to relays and/or 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.

   We also define 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.

Jennings & Mahy         Expires October 19, 2004                [Page 4]

Internet-Draft                MSRP Relays                     April 2004

   Clients which use a relay operate by first opening a connection with
   a relay, authenticating, and retreiving a URI on the relay the client
   can provide to its peers to receive messages later. 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 HTTP Digest or
   Basic [4] Authentication credentials.  In a successful AUTH response,
   the relay provides an MSRP URI associated with the path back to the
   client that the client can give to other clients for end-to-end
   message delivery.

   When clients wish to send a short message, they send a SEND request
   with the entire contents of the message. If any relays are required,
   they are included in the To-Path header. The leftmost URI in the
   To-Path header is the next hop to deliver a request or response.  The
   rightmost URI in the To-Path header is the final target.

    Tr-ID: 892341
    To-Path: \ \
    Boundary: 6aef
    Content-Type: text/plain

    Hi Bob, I'm about to send you LoTR.mpeg

    MSRP 200 OK
    Tr-ID: 892341

    Tr-ID: 132452
    To-Path: \
    From-Path: \
    Boundary: 6aef
    Content-Type: text/plain

    Hi Bob, I'm about to send you LoTR.mpeg

    MSRP 200 OK
    Tr-ID: 132452

Jennings & Mahy         Expires October 19, 2004                [Page 5]

Internet-Draft                MSRP Relays                     April 2004


    Tr-ID: 0987231
    From-Path: \ \
    Boundary: 6aef
    Content-Type: text/plain

    Hi Bob, I'm about to send you LoTR.mpeg

    MSRP 200 OK
    Tr-ID: 0987231

    Tr-ID: 784333
    To-Path: \ \
    Receipt: success

    Tr-ID: 784333
    To-Path: \
    From-Path: \
    Receipt: success

    Tr-ID: 784333
    From-Path: \ \
    Receipt: success

    MSRP 200 OK
    Tr-ID: 784333
    To-Path: \ \

Jennings & Mahy         Expires October 19, 2004                [Page 6]

Internet-Draft                MSRP Relays                     April 2004
    Receipt: success

    MSRP 200 OK
    Tr-ID: 784333
    To-Path: \
    From-Path: \
    Receipt: success

    MSRP 200 OK
    Tr-ID: 784333
    From-Path: \ \
    Receipt: success

                       Typical flow involving two relays

   Alice                 Bob
     |                     |                    |                     |
     |::::::::::::::::::::>| connection opened  |<::::::::::::::::::::|
     |--- AUTH ----------->|                    |<-- AUTH ------------|
     |<-- 401 Auth---------|                    |--- 401 Auth-------->|
     |--- AUTH ----------->|                    |<-- AUTH ------------|
     |<-- 200 OK-----------|                    |--- 200 OK---------->|
     |                     |                    |                     |
           ....                time passes           ....
     |                     |                    |                     |
     |--- SEND ----------->|                    |                     |
     |<-- 200 OK ----------|:::::::::::::::::::>|  (slow link)        |
     |                     |--- SEND ---------->|                     |
     |                     |<-- 200 OK ---------|--- SEND ----------->|
     |                     |                    |                ....>|
     |                     |                    |                  ..>|
     |                     |                    |<-- 200 OK ----------|
     |                     |                    |<-- REPORT ----------|
     |                     |<-- REPORT ---------|                     |
     |<-- REPORT ----------|                    |                     |
     |--- 200 OK --------->|                    |                     |
     |                     |--- 200 OK -------->|                     |
     |                     |                    |--- 200 OK --------->|
     |                     |                    |                     |

Jennings & Mahy         Expires October 19, 2004                [Page 7]

Internet-Draft                MSRP Relays                     April 2004

   SEND requests are sent hop-by-hop. (Each relay that receives a SEND
   request acknowledges receipt of the request before forwarding the
   content in other SEND requests.) All other requests are sent

   With the introduction of relays, the subtle semantics of the To-Path
   and From-Path header becomes more relevant. The To-Path in both
   requests and responses is the list of URIs that need to be visited in
   order to reach the final target of the request.  The From-Path is the
   list of URIs that indicate how to get back to the original sender of
   the request or response (Note these semantics are slightly different
   for SEND requests). This differs from the To and =46rom headers in =
   which do not "swap" from request to response. (Note that sometimes a
   request is sent to or from an intermediary directly.)

   When a relay forwards a request, it removes its address from the
   To-Path header and inserts it at as the first URI in the From-Path
   header.  For example if the path from Alice to Bob is through relays
   A and B, when B receives the request it contains path headers that
   look like this:

   To-Path: msrp:B msrp:Bob
   From-Path: msrp:A msrp:Alice

   after forwarding the request, the path headers look like this:

   To-Path: msrp:Bob
   From-Path: msrp:B msrp:A msrp:Alice

   MSRP Nodes respond to SEND requests by taking the first URI form the
   From-Path and placing that in a To-Path header in the response, and
   placing their URI in the From-Path of the response.  MSRP Nodes
   response to all other requests addressed to them, by swapping the
   To-Path and From-Path headers.

   When sending large content the client may split up a messsage into
   smaller pieces; each SEND request might contain only a portion of the
   complete message.  For example, when Alice sends Bob a 4GB file
   called "LoTR.mpeg", she sends several SEND requests each with a
   portion of the complete message. Relays can repack message fragments
   en-route.  As individual parts of the complete message arrive at the
   final destination client, the receiving client can optionally send
   REPORT requests indicating delivery status.

   MSRP nodes can send individual portions of a complete message in
   multiple SEND requests.  Each parcel uses the message/byteranges MIME
   type defined in RFC 2616 [5] to correlate that part to the complete
   message.  As each SEND request is received, the next hop acknowledges

Jennings & Mahy         Expires October 19, 2004                [Page 8]

Internet-Draft                MSRP Relays                     April 2004

   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 can optionally send a REPORT request indicating that a
   chunk arrived end-to-end. This request travels back along the reverse
   path of the SEND request.  Unlike the SEND request which is
   acknowledged along every hop, only the sender of the REPORT request
   responds to an REPORT.  Relays then forward the REPORT response back
   to the recipient of the original SEND.

                  Flow involving re-chunking through two relays

   Alice                 Bob
     |                     |                    |                     |
     |                     |                    |                     |
     |--- AUTH ----------->|                    |<-- AUTH ------------|
     |<-- 401 Auth---------|                    |--- 401 Auth-------->|
     |--- AUTH ----------->|                    |<-- AUTH ------------|
     |<-- 200 OK-----------|                    |--- 200 OK---------->|
     |                     |                    |                     |
           ....                time passes           ....
     |                     |                    |                     |
     |--- SEND 0-3 ------->|                    |                     |
     |<-- 200 OK ----------|                    |  (slow link)        |
     |--- SEND 4-7 ------->|--- SEND 0-5 ------>|                     |
     |<-- 200 OK ----------|<-- 200 OK ---------|--- SEND 0-3 ------->|
     |--- SEND 8-10 ------>|--- SEND 6-10 ----->|                ....>|
     |<-- 200 OK ----------|<-- 200 OK ---------|                  ..>|
     |                     |                    |<-- 200 OK ----------|
     |                     |                    |<-- REPORT 0-3 ------|
     |                     |<-- REPORT 0-3 -----|--- SEND 4-7 ------->|
     |<-- REPORT 0-3 ------|                    |                 ...>|
     |--- 200 OK --------->|                    |                  ..>|
     |                     |--- 200 OK -------->|                     |
     |                     |                    |--- 200 OK --------->|
     |                     |                    |<-- REPORT 4-7 ----->|
     |                     |<-- REPORT 4-7 -----|--- SEND 8-10 ------>|
     |<-- REPORT 4-7 ------|                    |                  ..>|
     |--- 200 OK --------->|                    |<-- 200 OK ----------|
     |                     |<-- REPORT done-----|<-- REPORT done -----|
     |<-- REPORT 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 over each hop should take no more than 32

Jennings & Mahy         Expires October 19, 2004                [Page 9]

Internet-Draft                MSRP Relays                     April 2004

   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 a REPORT back to
   the sender indicating that the message or fragment was successfully

   For client to client communication, the sender of a message typically
   opens a new TCP connection (with or without TLS) if one is needed.
   Relays reuse existing connections first, but can open new connections
   (typically to another relay) to deliver requests such as SEND or
   REPORT.  Responses can only be sent over existing connections.

4. New Protocol Elements

4.1 The AUTH Method

   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 are discussed in more detail in Section XXX TODO.

   In response to an AUTH request, a successful response contains a Path
   header with a list of URIs that the Client can give to its peers to
   route responses back to the Client.

4.2 The Use-Path header

   The Use-Path header is a list of URIs provided by an MSRP Relay in
   response to a successful AUTH request.  This list of URIs can be used
   by the MSRP Client that sent the AUTH request to receive MSRP
   requests, and can advertise this list of URIs, for example in a
   session description.

4.3 Authentication headers

   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

   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

Jennings & Mahy         Expires October 19, 2004               [Page 10]

Internet-Draft                MSRP Relays                     April 2004

   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]

4.4 Time-related headers

   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].  Specifically an Expires header in an AUTH request indicates
   how long the provided URIs will be valid.

   The Min-Expires header contains the minimum duration a server will
   permit in an Expires header.  It is sent only in 423 "Interval
   Out-of-Bounds" responses.  Likewise the Max-Expires header contains
   the maximum duration a server will permit in an Expires header.

   423 Interval Out-of-bounds.  Max-Expires header

5. Procedures

5.1 Client behavior

5.1.1 Connecting to relays acting on your behalf

   Clients which want to use the services of a relay or list of relays,
   need to send an AUTH request to each relay which will act on their
   behalf. For example, some organizations could deploy an "intra-org"
   relay and an "extra-org" relay.  A client using these relays opens a
   connection to the intra-org relay and sends an AUTH request.

   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 Use-Path header
   of the response. When using a session-protocol such as SIP, these
   URIs are used by the client in the path attribute that is sent in the

Jennings & Mahy         Expires October 19, 2004               [Page 11]

Internet-Draft                MSRP Relays                     April 2004

   SDP to setup the session. The same URI can be used for multiple
   sessions to send to the client.

   When sending an AUTH request, the client MAY add an Expires header to
   request a MSRP 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 MSRP is only permitted for AUTH
   requests.  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

   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 REPORT 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.

   auth to-path: intra-org
        from-path: alice@a
   200  to-path: alice@a
        from-path: intra-org
        use-path: alice@intra-org/abcd alice@a

   auth to-path: alice@intra-org/abcd extra-org
       auth to-path: extra-org
       200 use-path: extra-org/xyzpdq alice@intra-org/abcd alice@a
   200 use-path: extra-org/xyzpdq alice@intra-org/abcd alice@a

5.1.2 Sending requests

   The procedure for sending SEND, VISIT, and REPORT requests is
   identical for clients whether relays are involved or not. The
   specific procedures are described in section TODO of [MSRP].

Jennings & Mahy         Expires October 19, 2004               [Page 12]

Internet-Draft                MSRP Relays                     April 2004

   As usual, once the next-hop URI is determined, the client MUST find
   the appropriate address, port, and transport to use and then 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.

5.1.3 Receiving Requests

   The procedure for receiving requests is identical for clients whether
   relays are involved or not.

5.1.4 Managing Connections

   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.

5.2 Relay behavior

5.2.1 Handling Incoming Connections

5.2.2 Generic request behavior

   Upon receiving a new request, relays first verify the validity of the
   request. [NO: Relays then tag valid requests with a
   locally-significant connection identifier which they add to the last
   URI in the Back-Path header.  This is used to insure that responses
   can be routed over an existing connection.  ???] Relays then examine
   the first URI in the To-Path header and remove this URI if it matches
   a URI corresponding to the relay. Authorization -- determine if the
   final target is a URI under its control or from a URI under its

5.2.3 Receiving AUTH requests

   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

Jennings & Mahy         Expires October 19, 2004               [Page 13]

Internet-Draft                MSRP Relays                     April 2004

   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.

   Discuss forwarding of AUTH requests for another relay

   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 the base URI of a
   family of URIs, each of which 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 REPORT 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.

   [*** NOTE: Consider moving to another section ***]

   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

Jennings & Mahy         Expires October 19, 2004               [Page 14]

Internet-Draft                MSRP Relays                     April 2004

   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 MSRP URI that the client can use to create a number
   of different URIs which are all associated with the current

5.2.4 Forwarding SEND requests

   A MSRP relay that receives a SEND request MUST respond with a final
   response immediately. A 200-class response indicates the successful
   receipt of a message fragment, but does not mean that the message has
   been forwarded on to its next hop.

   The final response to the SEND MUST be sent to the previous hop,
   which could be a MSRP relay or the original sender of the SEND

   The 2xx response to the SEND 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 MSRP relay MAY further break up the message fragment received in
   the SEND request into smaller fragments and forward them to the next
   hop in separate SEND requests. It MAY also combine message fragments
   received before or after this SEND request, and forward them out in a

Jennings & Mahy         Expires October 19, 2004               [Page 15]

Internet-Draft                MSRP Relays                     April 2004

   single SEND request to the next hop identified in the Hops header.
   The MSRP relay MUST NOT combine message fragments from SEND requests
   with different values in the Message-ID header.

   The MSRP 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 MSRP relay has knowledge of the byte range that it will
   transmit to the next hop, it SHOULD update the message/byteranges
   parameter in the SEND request appropriately.

   Before forwarding the SEND request to the next hop, the MSRP relay
   MUST inspect the first URI in the To-Path header. If it indicates
   this relay, the relay removes this URI from the To-Path header and
   inserts this URI in the From-Path header before any other URIs.

   If the MSRP relay fails to forward the SEND on to the next hop, it
   SHOULD return a REPORT back to the sender of the SEND indicating the
   reason for failure using the list of URIs in the From-Path header.
   [how?  example.  see section]

5.2.5 Forwarding non-SEND requests

   An MSRP relay that receives any request other than a SEND request
   (including new methods unknown to the relay), first follows the
   validation and authorization rules for all requests in Section x.y.
   Then the relay moves its URI from the beginning of the To-Path
   header, to the beginning of the From-Path header and forwards the
   request on to the next hop. It MUST use the most suitable conection,
   etc, etc..  If no suitable connection exists, the relay opens a new

5.2.6 Forwarding Responses

   Relays receiving a response, first check the Tr-ID of the response.
   If the relay is unaware of this transaction, the response MUST be
   dropped. Likewise if the message is unparsable, the relay MUST drop
   the response.  If the response matches an existing transaction, the
   transaction state MUST be deleted. The relay MUST verify that the
   first URI in the To-Path corresponds to it. If not, the response
   SHOULD be dropped. If there are additional URIs in the To-Path
   header, the relay can then move its URI from the list To-Path header,
   insert its URI in front of any other URIs in the From-Path header,
   and forward the response to the next URI in the To-Path header.  The
   relay sends the request over the best connection which corresponds to
   the next URI in the To-Path header.  If this connection has closed,

Jennings & Mahy         Expires October 19, 2004               [Page 16]

Internet-Draft                MSRP Relays                     April 2004

   then the response is silently discarded.

5.2.7 Managing Connections

   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

5.2.8 Forwarding unknown requests

   Requests with an unknown method are forwarded as if they were REPORT

5.3 Acting as a Message Taker

   A Message Taker merely acts like a Client which returns different
   REPORT 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 REPORTs to the original
   sender as well as the message take to let them know I got the

6. Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in RFC-2234 [6].

   AUTHm           =3D %x41.55.54.48           ; AUTH in caps
   Method          =3D SENDm / VISITm / REPORTm / AUTHm
                        / extension-method

                /   "401"  ;  Authentication Required
                /   "423"  ;  Interval Out-of-Bounds

   Authentication-Info  =3D  "Authentication-Info" HCOLON ainfo
                           *(COMMA ainfo)
   ainfo                =3D  nextnonce / message-qop
                            / response-auth / cnonce
                            / nonce-count
   nextnonce            =3D  "nextnonce" EQUAL nonce-value
   response-auth        =3D  "rspauth" EQUAL response-digest

Jennings & Mahy         Expires October 19, 2004               [Page 17]

Internet-Draft                MSRP Relays                     April 2004

   response-digest      =3D  LDQUOT *LHEX RDQUOT

   Authorization     =3D  "Authorization" HCOLON credentials
   credentials       =3D  ("Digest" LWS digest-response)
                        / other-response
   digest-response   =3D  dig-resp *(COMMA dig-resp)
   dig-resp          =3D  username / realm / nonce / digest-uri
                         / dresponse / algorithm / cnonce
                         / opaque / message-qop
                         / nonce-count / auth-param
   username          =3D  "username" EQUAL username-value
   username-value    =3D  quoted-string
   digest-uri        =3D  "uri" EQUAL LDQUOT digest-uri-value RDQUOT
   digest-uri-value  =3D  rquest-uri ; Equal to request-uri as specified
                        by HTTP/1.1
   message-qop       =3D  "qop" EQUAL qop-value
   cnonce            =3D  "cnonce" EQUAL cnonce-value
   cnonce-value      =3D  nonce-value
   nonce-count       =3D  "nc" EQUAL nc-value
   nc-value          =3D  8LHEX
   dresponse         =3D  "response" EQUAL request-digest
   request-digest    =3D  LDQUOT 32LHEX RDQUOT
   auth-param        =3D  auth-param-name EQUAL
                        ( token / quoted-string )
   auth-param-name   =3D  token
   other-response    =3D  auth-scheme LWS auth-param
                        *(COMMA auth-param)
   auth-scheme       =3D  token
   LHEX              =3D  DIGIT / %x61-66 ;lowercase a-f
   ;   Some elements (authentication) force hex alphas to be lower case.

   WWW-Authenticate  =3D  "WWW-Authenticate" HCOLON challenge
   challenge           =3D  ("Digest" LWS digest-cln *(COMMA =
                          / other-challenge
   other-challenge     =3D  auth-scheme LWS auth-param
                          *(COMMA auth-param)
   digest-cln          =3D  realm / domain / nonce
                           / opaque / stale / algorithm
                           / qop-options / auth-param
   realm               =3D  "realm" EQUAL realm-value
   realm-value         =3D  quoted-string
   domain              =3D  "domain" EQUAL LDQUOT URI
                          *( 1*SP URI ) RDQUOT
   URI                 =3D  MSRP-URI / anyURI
   nonce               =3D  "nonce" EQUAL nonce-value
   nonce-value         =3D  quoted-string
   opaque              =3D  "opaque" EQUAL quoted-string
   stale               =3D  "stale" EQUAL ( "true" / "false" )

Jennings & Mahy         Expires October 19, 2004               [Page 18]

Internet-Draft                MSRP Relays                     April 2004

   algorithm           =3D  "algorithm" EQUAL ( "MD5" / "MD5-sess"
                          / token )
   qop-options         =3D  "qop" EQUAL LDQUOT qop-value
                          *("," qop-value) RDQUOT
   qop-value           =3D  "auth" / token

7. Finding MSRP Servers


   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

   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
   [7] 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
   domain might return:

   ;; in      Pri Wght Port Target
   _sims+tls._tcp   IN SRV 0   1    9000
   _sims+tls._tcp   IN SRV 0   2    9000
   _sims._tcp       IN SRV 1   1    8999
   _sims._tcp       IN SRV 1   2    8999

   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

Jennings & Mahy         Expires October 19, 2004               [Page 19]

Internet-Draft                MSRP Relays                     April 2004

   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.

8. Security Considerations

   This section first describes the security mechanisms available for
   use in MSRP. Then the threat model is presented.  Finally we list
   implementation requirements related to security.

8.1 Using HTTP Authentication

   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 MSRP 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.

8.2 Using TLS

   TLS is used to authenticate relays to senders and to provide
   integrity and confidentiality for the headers being transported. MSRP
   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 [8]. A TLS cipher-suite of
   TLS_RSA_WITH_AES_128_CBC_SHA [9] 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.

8.3 Threat Model

   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

   MSRP 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.

Jennings & Mahy         Expires October 19, 2004               [Page 20]

Internet-Draft                MSRP Relays                     April 2004

   There often exists a channel outside of MSRP, such as out-of-band
   provisioning or an explicit rendezvous protocol such as SIP, that can
   securely negotiate setting up the MSRP 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.

8.4 Security Mechanism

   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.

Jennings & Mahy         Expires October 19, 2004               [Page 21]

Internet-Draft                MSRP Relays                     April 2004

   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

   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 MSRP 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

   TODO talk about example from client to client and from Client A, then
   to a relay that A uses, RA, then on to client B.

8.5 Preventing Spam and Denial of Service Attacks

   While this specification already implements a number of significant
   improvements to prevent unsolicited messaging and Denial of Service,

Jennings & Mahy         Expires October 19, 2004               [Page 22]

Internet-Draft                MSRP Relays                     April 2004

   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.

9. IANA Considerations

   This document introduces no requirements for IANA.

10. Example SDP with multiple hops

   A sample SDP offer for a MSRP session could look like:

   c=3DIN IP4 invalid.none
    m=3Dmessage 1234 msrp/tcp
    a=3Daccept: message/cpim text/plain text/html;transport=3Dtcp

   In this offer Alice wishes to receive MSRP messages at She wants to use TCP as the transport for
   the MSRP session. She can accept message/cpim, text/plain and text/
   html message boldies in SEND requests. She wishes to use the relay for the MSRP session.

   To this offer, Bob's answer could look like:

   c=3DIN IP4 invalid.none
    m=3Dmessage 1234 msrp/tcp
    a=3Daccept: message/cpim text/plain;transport=3Dtcp;transport=3Dtcp

   Here Bob has agreed to use tcp as the transport, and wishes to
   receive the MSRP messages at He can accept only
   message/cpim and text/plain message bodies in SEND requests and has
   rejected text/html offer made by Alice. He wishes to use two relays
   for the MSRP session - and

11. Acknowledgments

   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, Juhee
   Garg, Pekka Pessi, and Chris Boulton

Jennings & Mahy         Expires October 19, 2004               [Page 23]

Internet-Draft                MSRP Relays                     April 2004

Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

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

   [3]   Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
         P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January

   [4]   Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
         Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
         Basic and Digest Access Authentication", RFC 2617, June 1999.

   [5]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
         Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
         HTTP/1.1", RFC 2616, June 1999.

   [6]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
         Specifications: ABNF", RFC 2234, November 1997.

   [7]   Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
         specifying the location of services (DNS SRV)", RFC 2782,
         February 2000.

   [8]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and
         T. Wright, "Transport Layer Security (TLS) Extensions", RFC
         3546, June 2003.

   [9]   Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
         Transport Layer Security (TLS)", RFC 3268, June 2002.

   [10]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
         Extensions (MIME) Part One: Format of Internet Message Bodies",
         RFC 2045, November 1996.

   [11]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
         Extensions (MIME) Part Two: Media Types", RFC 2046, November

   [12]  Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
         2633, June 1999.

   [13]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
         Resource Identifiers (URI): Generic Syntax", RFC 2396, August

Jennings & Mahy         Expires October 19, 2004               [Page 24]

Internet-Draft                MSRP Relays                     April 2004


   [14]  Braden, R., "Requirements for Internet Hosts - Application and
         Support", STD 3, RFC 1123, October 1989.

   [15]  Troost, R., Dorner, S. and K. Moore, "Communicating
         Presentation Information in Internet Messages: The
         Content-Disposition Header Field", RFC 2183, August 1997.

   [16]  Handley, M. and V. Jacobson, "SDP: Session Description
         Protocol", RFC 2327, April 1998.

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

   [18]  Burger, E., Candell, E., Eliot, C. and G. Klyne, "Message
         Context for Internet Mail", RFC 3458, January 2003.

Informative References

   [19]  Mahy, R., "Benefits of Session-Mode Instant Messaging",
         draft-mahy-simple-why-session-mode-00.txt (work in progress),
         February 2004.

   [20]  Campbell, B., "Instant Message Sessions in SIMPLE",
         draft-ietf-simple-message-sessions-02 (work in progress), Oct

   [21]  Atkins, D. and G. Klyne, "Common Presence and Instant
         Messaging: Message Format", draft-ietf-impp-cpim-msgfmt-08
         (work in progress), January 2003.

   [22]  Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
         Protocol (RTSP)", RFC 2326, April 1998.

   [23]  Levinson, E., "Content-ID and Message-ID Uniform Resource
         Locators", RFC 2392, August 1998.

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

   [25]  Resnick, P., "Internet Message Format", RFC 2822, April 2001.

   [26]  Mahy, R., "Relay Requirements for Session-Mode Instant
         Messaging", draft-mahy-simple-session-relay-reqs-00.txt (work
         in progress), February 2004.

Jennings & Mahy         Expires October 19, 2004               [Page 25]

Internet-Draft                MSRP Relays                     April 2004

Authors' Addresses

   Cullen Jennings
   Cisco Systems, Inc.
   170 West Tasman Dr.
   MS: SJC-21/2
   San Jose, CA  95134

   Phone: +1 408 527-9132

   Rohan Mahy
   Cisco Systems, Inc.
   5617 Scotts Valley Drive, Suite 200
   Scotts Valley, CA  95066


Jennings & Mahy         Expires October 19, 2004               [Page 26]

Internet-Draft                MSRP Relays                     April 2004

Intellectual Property Statement

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

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

Full Copyright Statement

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

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

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

   This document and the information contained herein is provided on an

Jennings & Mahy         Expires October 19, 2004               [Page 27]

Internet-Draft                MSRP Relays                     April 2004



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

Jennings & Mahy         Expires October 19, 2004               [Page 28]