MSRP%20Again!

1
MSRP Again!

• draft-ietf-simple-message-session-09

2
Updates

• Security Review
• Lots of editorial feedback
• Clarifications on REPORT handling

3
Quick Stuff First

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

4
Pretty Quick Stuff

• Added 501 response code for unknown methods.
• Clarify the userinfo field is unreserved--additi
  onal restriction over RFC2396
• Change URL reference to rfc2396bis draft
• Recommended SIP 488 response if no common MIME
  types.

5
Security Review Changes
6
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.

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

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

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

10
Other Issues
11
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.

12
Overlapping Chunks

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

13
Report handling

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

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

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

16
Report Handling

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