draft-ietf-simple-message-session-09 MSRP Again! draft-ietf-simple-message-session-09

Updates Security Review Lots of editorial feedback Clarifications on REPORT handling

Quick Stuff First Lots of ABNF scrubbing. Consolidated URL ABNF into general syntax section. Clarify that max-size sdp attribute is in octets.

Pretty Quick Stuff Added 501 response code for unknown methods. Clarify the userinfo field is “unreserved”--additional restriction over RFC2396 Change URL reference to rfc2396bis draft Recommended SIP 488 response if no common MIME types.

Security Review Changes

Applicability Statement MUST ONLY be used with a rendezvous protocol that: Negotiates MSRP URLs Handles AoRs with “im:” URIs. Can do all this securely. SIP can be used, others possible if they meet the criteria.

URI Mapping We need more clarity around how to use “im:” URLs with SIP. Assumption that the mapping can only be done by something in the target domain. Not specific to MSRP. RFC3428 has same issue. Need a referenceable SIMPLE document on how this works in general.

Draft Separation Security Review pointed out that relays are needed for a full security story. Suggested re-integrating the two drafts. Proposal: Leave them separate. We separated them for historical reasons, and re-integrating them now is not efficient use of effort.

RFC3862 Application Considerations RFC3862 requires all applications to describe usage of message/cpim headers. MSRP devices MUST recognize From, To, Datetime, and Require. SHOULD recognize CC MAY recognize Subject. Must include From and To. If using s/mime, then also DateTime. NS, To, and CC may repeat. All others must not occur more than once.

Other Issues

MSRP URI parameters Rohan proposed allowing “?” parameter syntax. Needed to allow the relay extension where a client gets a URL range from a single AUTH Intended to be in this release, but we missed it somehow. Proposal: Put it in.

Overlapping Chunks What if you receive chunks with overlapping ranges? Proposal: RECOMMEND that last chunk wins, unless the application constraints force other approaches.

Report handling Current revision not quite there. Currently say that negative reports are sent per chunk, positive can be either per-message or incremental.

Report Handling Proposal: Negative reports still per-chunk New “incremental” value for Report-Success If “yes”, the send positive reports for whole messages. If incremental, send periodic positive reports indicating the range received so far.

Report Handling Reliable delivery requires Report-Success = yes or incremental. Report-Failure allows rapid failure detection. If a failure occurs, and the sender wishes to recover, it renegotiates the session URLs, and resends any content that has not been acknowledged in a positive report.

Report Handling Spurious report handling Silently drop reports that do not match a previously sent message-id and range.