1 / 12

Message Session Open Issues

Message Session Open Issues. draft-ietf-simple-message-sessions-02 Ben Campbell. Relay Shutdown. Stop Accepting Connections Reject new requests with 481 Wait one transaction timeout period for open transactions to complete. Should we talk about clients reconnecting when this happens?.

moored
Télécharger la présentation

Message Session Open Issues

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. Message Session Open Issues draft-ietf-simple-message-sessions-02 Ben Campbell

  2. Relay Shutdown • Stop Accepting Connections • Reject new requests with 481 • Wait one transaction timeout period for open transactions to complete. • Should we talk about clients reconnecting when this happens?

  3. SEND Failures • When SEND requests timeout, client may re-send content as new request. This may cause duplicates. • Do we want to disallow this? • Do we want to resend with same TR-ID, and suppress duplicates based on TR-ID? • Aki suggests going to contiguous, ordered TR-IDs

  4. SEND Failures • What about cross-session duplicates? • Client has a failure on a session, creates new session, resends on new session. • TR-ID based duplicate suppression would require globally unique TR-IDs… • …and require endpoints to remember TR-IDs from past sessions for some period of time.

  5. Session Purpose • We suggest using distinct sessions for things like large content transfer. • What keeps the other end from sending IMs on the session we intended for file transfer? • Do we need a mechanism to label the session purpose? • MIME type has been suggested, but not granular enough.

  6. Session Teardown at Visiting Relay • Currently done implicitly—no “unvisit” semantic. • Visiting relay destroys session state when its host connection goes away. • Do we need an explicit operation for this?

  7. SEND for Keep Alives • Relay uses SEND requests to determine liveness of a session. • Endpoints periodically generate empty SEND requests if they have no other traffic to send. • Several people have objected to this, and prefer a separate keep alive method. • Relay does not know difference between a “real” SEND and a “keep alive” Send. Adding a new method would change this.

  8. Multiple Digest Algorithms • Currently require a separate challenge per algorithm. • This is also true of HTTP digest. • Do we want to allow multiple algorithm choices be presented for the same challenge? • Multiple challenges possible in same response.

  9. Security Considerations • Cullen wants more specification on TLS certificate usage, and has kindly offered to supply text.  • Aki suggests more discussion of interaction between authentication mechanisms, MiTM attacks on digest, etc.

  10. Clean up MIME usage • Content-type syntax needs cleaning up • Do we need to indicate MIME version? • Should content-type be part of the body? • What about other MIME headers • Content-Disposition?

  11. More Examples • Several have requested more exhaustive use cases. • Should these go in base spec, or separate document? • Suggestions so far • New offer with no change • New offer with MIME type changes • New offer from Visitor (who continues as visitor)

  12. Congestion Issues • Are we “Trashing the Commons?” • Several people have requested more discussion on the congestion aspects. • Please send text!!!

More Related