Subject: [Simple] MSRP update

From: Ben Campbell <[email-masked]>
Date: Wed, 31 Mar 2004 17:26:04 -0600

The chairs have requested that we put MSRP on a "release early and 
often" track. That is, rather than waiting until I have all the planned 
updates completed, I will put out a revision for each significant update.

Therefore I will be submitting a revised MSRP base spec draft either 
this evening (Wednesday) or Thursday, followed by a series of revisions 
over the next few weeks.

This revision will include changes to MSRP URL handling and connection 
handling needed to allow relays to be used. As we discussed in Korea, it 
will not describe relays themselves; this will be handled in a separate 
draft. But there were a number of base specification changes needed to 
make it possible to integrate relays.

We are working from a number of assumptions about how relays will work, 
even though the MSRP relay draft is pending:

--Relays are session-stateless

--Relay chains are source routed, with the route negotiated in the SDP.

-- Transactions are hop-by-hop, and downstream transactions do not 
depend on upstream transactions.

Specific changes in this revision:

-- The answerer always opens the TCP connection to the offerer. The 
comedia like direction negotiation is removed.

--  Shared connections are allowed.

--  MSRP URLs identify a destination within a session, rather than the 
entire session itself. MSRP requests will now have a To field describing 
the destination, and a From field describing the source. The sdp 
negotiation allows each endpoint to contribute its URL.

-- To enable routing across relays, an SDP request can carry a list of 
URLs. We expect this to be used with relays to describe a route across 
relays. The base spec will not say how one would determine a list of 
more than one URL, but it does require an endpoint to be able to receive 
such a list and process it reasonably. Basically, if you receive a list, 
you put the entire list in To headers on SEND requests. This will work 
even if the receiver wants to contribute their own relays to the path, 
but that belongs in the relay spec, not the base.

There are still a number of outstanding items we discussed in Korea,that 
will be required to allow relay integration, but are not covered by this 
revision:

-- DSN handling and negotiation. Since relays will be able to originate 
DSNs, even endpoints that don't understand relays will need to be able 
to receive them.

-- Chunking

-- Using message bounderies instead of length fields for message 
framing, so you can abort a request without destroying framing for the 
connection.

-- Orit requested that we allow a mode where there are no transaction 
responses. She has agreed to document the motivation for this. I will 
hold any changes based on this request until after the work group has a 
chance to discuss that document.

-- a few outstanding, non-controversial items, such as allowing all 
standard MIME headers.

Watch this channel for revisions covering these items in the very near 
future.

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: Wed, 31 Mar 2004 21:01:15 -0600

The aformentioned draft has been submitted. For the impatient, you can 
find it at:

http://www.nostrum.com/~ben/draft-ietf-simple-message-sessions-04.txt

Or for the HTML inclined:

http://www.nostrum.com/~ben/draft-ietf-simple-message-sessions-04.html

...until it hits the repository.

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 31 Mar 2004 21:01:15 -0600

Thanks!

Ben.