1 / 7

STIR WG RFC 4474bis: Jon Going, Going, Gone?

This document discusses concerns related to "canon" and PAI as an extension in STIR WG RFC 4474bis. It also addresses bad dates and how to respond when a Date header is stale. The document proposes solutions and suggests adding a terminology section.

fgerald
Download Presentation

STIR WG RFC 4474bis: Jon Going, Going, Gone?

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. stir-rfc4474bis STIR WG / IETF 96 Berlin, July 2016 Jon

  2. Going, going, gone? • In WGLC at the moment • Some list discussion, some private correspondence • Bad dates • “canon” or something else • PAI: baseline or an extension • Diversion • Housekeeping

  3. Bad dates • How to respond when a Date header is stale • Signature is valid, Date is bad • Could send, like, a 400 Bad Request with an appropriate reason phrase • Really, this is • Could make up a new status code • Better chance it could be repaired • Remember some Dates changed in transit • If you do that, you are bad and you should feel bad

  4. “canon” or something else • Some last minute concerns about “canon” • Does SIP really even carry a PASSporT object? • Or just the data needed to let a verifier make one • Two other paths: • Should we always include the whole PASSporT? • Some list discussion • If not, should we use the baseline RFC7515 Appendix F mechanism? • Seems to only let us omit the claims, not the header • Whatever we do, we need some motivation text • And at least one solid “canon” example

  5. PAI as an extension? • Today,“orig” can come from From or PAI • If PAI is in the request, take it from PAI • One implementer commented that this might be better as a “ppt” extension • It would be explicit then rather than • Just have an extra claim for PAI, so we’d cover both it and the From • Why not? • Our motto: any environment where you send PAI knows to use PAI already – 4474bis reflects that • My proposal: no change

  6. Diversion • Got one comment about how to handle forwarding and other cases where the effective “To” changes • A known limitation in the mechanism • In baseline SIP, of course, the Request-URI changes, not the To • But, this is still worth thinking about • Could conceivably have a “ppt” extension • Add a new ppt Identity header with an OCN field • Possibly even chainable a la History-Info

  7. Housekeeping • Should we add a terminology section? • Got some good nits from Olle

More Related