1 / 16

Major Rewrite of MSRP Core: Enhancements and Optimizations for Report Handling

This document outlines a significant rewrite of the MSRP Core, focusing on clarity and effective editing through collaborative sessions. Key changes include adjustments to report handling, transport, and chunking mechanisms, alongside the removal of the VISIT method. Enhancements in media type negotiation, status headers for reports, and a refined boundary handling strategy are highlighted. Open issues invite discussion on report request separation and future extensibility, paving the way for further improvements and potentially moving towards WGLC.

zoltan
Download Presentation

Major Rewrite of MSRP Core: Enhancements and Optimizations for Report Handling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. MSRP Core Ben Campbell (ben@nostrum.com)

  2. Status • Major rewrite (iterative editing sessions with Rohan and Cullen) • Tried to make things clearer, reduce “cut-and-paste-itus” • Lots of late-night editing

  3. Significant Changes • Report Handling • Framing/Transaction Mapping • Moved chunk handling into headers • Removed VISIT method • Changed transport and TLS selection • Added max-size to media type negotiation

  4. Reports • Two headers for report selection • Report-Success (yes / no) • End-to-end success reports • Defaults to no • Report-Failure (yes / no / partial) • MSRP responses _only_ used if Report-Failure:yes • Defaults to yes • Partial allows failure reports for failures that can be detected w/o MSRP responses

  5. Reports • DSN Payload optional • MAY for success reports • SHOULD for failure reports • Added status header to allow reports w/o payloads • Scoped to Message-ID • Byte-range header for reports about “chunks”

  6. Framing • Boundary moved to start-line • No more boundary header • Also acts as transaction ID • MSRP response shares same value • Must be unique for session.

  7. Chunking • Removed dependency on multipart/byte-ranges • Any kind of content can be chunked • Added Byte-Range header • SEND: tells you what range is carried in the message • REPORT: tells you what range is being reported on

  8. Removed VISIT • Semantics became almost identical to SEND • Replaced with an initial SEND request • May or may not carry content.

  9. Transport and Protection • Transport URL parameter • Protection indicated in scheme • msrps:alice.example.com:9938/sfa934s;tcp

  10. Max-Size • Optional parameter to media type entries • In accept-types and accept-wrapped-types • Indicates maximum size you are willing to receive for the given type • Refers to complete message content, not “chunk” content.

  11. Open Issues

  12. Report Handling • Should we separate report request negotiating from transaction response negotiation? • Transaction responses only serve to enable error reports. • Separation allows nonsensical states • Proposal: leave as is.

  13. Extensibility • How do we evolve to future versions? • Paul proposed adding a URL parameter for version • Do we care? • If so, I propose we accept Paul’s suggestion.

  14. What does max-size mean? • Questions about how max-size applies to body parts inside of multiparts. • Proposal: It applies to any matching body part, regardless of encapsulation.

  15. Page vs Session Mode • We have had requests for a discussion about when to use Session mode vs Page mode. Does that belong here? • Proposal: No, this really belongs somewhere else. Maybe the SIMPLE architecture work?

  16. Now What? • Seems like we are getting close to done here! • Proposal: • One minor revision RSN… • … then WGLC?

More Related