MSRP Core

1. MSRP Core draft-ietf-simple-message-sessions-06

2. New in 06 • Changed To and From to To-Path and From-Path • Semantics different than traditional To and From. Confusion insued. • Framing: Use boundary instead of length field. • SDP: Transport and TLS indicated in URL, rather than M-Line. • Inviter always opens the connections • Updated DSN section

3. Relationship to Relay Draft • Core specification talks about route path handling • Makes minimum necessary assumptions about relay behavior to allow relays. • Does not talk about how relays work, or how endpoints select relays.

4. Path handling in SDP • Each client puts a URL into a path attribute. • Can put more than one URL in the path attribute. • The path given by peer indicates the “path to the peer.” • Path applies to all messages in session.

5. Path handling in MSRP requests • To-Path holds a list of URLs. • Path to destination • First URL is first hop. • Last URL is destination. • From-URL also takes a list • “Where it’s been” • Initial request has one entry pointing to client. • When request arrives at destination, it will contain URLs for all hops.

6. Request Framing • Length Field goes away. • Add Boundary header. • Random String (different for each message) • Matching closing field • 7 hyphens • Boundary string • Continuation char. ($ if content complete, + if more to come.)

7. Request Framing • MSRP Boundary unrelated to any MIME boundary in the payload. • Full MIME body between headers and closing. May have its own MIME boundaries. • Presence of MIME boundaries does not change use of MSRP boundary. • Boundary must not collide with payload. • Cannot use same boundary string for MSRP boundary and any MIME boundaries.

8. Other SDP Changes • msrp://host/asf;transport=tcp,protection=yes • msrps://host/asdf3; transport=tcp • msrps://host/tcp/asfed • Transport and TLS determined by URL scheme, rather than M-line. • msrp: - TCP • msrps: - TLS over TCP • smsrp: - SCTP • smsrps: - TLS over SCTP • SCTP related schema are “reserved” for whenever we specify the SCTP binding.

9. Connection Handling • Defaults to TCP connection opened by client that sends the INVITE. • No COMEDIA • Active client MUST send an immediate MSRP request, so the peer can tell who opened the connection. • May be SEND if there is a message to send right away. • Otherwise use VISIT • Inviter must wait for answer before connecting.

10. Delivery Status Notification • Only specifies enough to let an endpoint without relay support talk to peers that use relays. • RFC1894 format • DSN requested on per request basis. • Receipt-Request header field • Negative – only report on failures • None – never report • All – report failures and delivery success. • Default is “negative” • Sent using REPORT method • Never REPORT on a REPORT

11. Message Fragmentation • May break content into “parcels” using message/byteranges • Only message/byteranges content can be interrupted and resumed. • SHOULD fragment anything over 2k. • Final parcel uses “$” in the continuation flag field. Non-final parcels use “+”

12. Open Issues and To Do’s • Responses • Proposal to make transaction responses optional or remove them entirely. • Orit will present details.

13. SDP Issues • How will SIP delayed offers work? • Can we expect the answerer to propose MSRP rather than voice? • Should we specify what a client that supports MSRP should do if it gets an INVITE with no offer? • Do we want this much SIP specificity in this document?

14. SDP Issues • Old text on updated offers obsolete with new approach to connection direction. • Section needs a re-write. • SDP offer/answer arcana experts _please_ help.

15. Connection Direction • Number of non-relay scenarios reduced • Offerer must choose whether to use relay prior to making offer. If the answerer is not firewalled, the offerer cannot learn of this until too late. • Thus, a firwalled answerer will always propose a relay, even if the answerer is reachable. • A firewalled answerer must use a relay, even if the offerer is reachable.

16. Connection Direction • Do we want to allow for more sophisticated direction selection in the future? • What if COMEDIA becomes an option? • Can we say that arbitrary signaling protocols can have their own method of determining direction?

17. Fragmentation • How much of the RFC2616 language concerning message/byteranges do we need to reproduce here? • Currently only refers to RFC, and add text that specifically constrains the use in MSRP. Does not explain message/byteranges in general.

18. SEND vs VISIT • VISIT has become less important • VISIT only serves to identify the active party to the passive party, in the context of a particular session. • Active party may jump straight to SEND if it has content to send. • Since the active party initiated communication in the first place, it probably has content. • Can we remove VISIT entirely? • Should we require VISIT all the time, and not overload SEND?

19. DSN Issues • Do we need them at all? • What about DSN reports after session is over? • Should we default to no DSN for peer-peer session? • DSN is redundant with transaction responses for p2p. • DSN section needs to be updated to use new handling of To-Path and From-Path.

20. Other To Do items • Still need to add support for all appropriate MIME headers. • Does not seem controversial, just stuck in line behind the harder stuff. • More text needed on TLS certificate handling.