Subject: Re: [core] #395 (coap-tcp-tls): Session resumption

From: "core issue tracker" <[email-masked]>
Date: Tue, 05 Apr 2016 02:50:16 -0000

#395: Session resumption

Comment (by [email-masked]):

 In http://www.ietf.org/mail-archive/web/core/current/msg06909.html Hannes
 assumed that the question was about TLS session resumption. Instead the
 question focused on TCP, as Klaus clarified in http://www.ietf.org/mail-
 archive/web/core/current/msg06948.html

 -------------------

 > When DTLS / TLS client communicates with a server then it typically
 > establishes a session cache to allow session resumption. [...]

 To clarify, the question is about sessions at the CoAP level, not at
 the DTLS/TLS level.

 Should it be possible to send a CoAP request, close the TCP
 connection, reconnect and receive the response?

 -------------

 Both Klaus and Carsten subsequently agree that there is no expectation
 that a re-connect from the client would allow it to retrieve (buffered)
 data. Instead the connection lifetime is bound to the TCP connection.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-coap-tcp-
  [email-masked]         |  [email-masked]
     Type:  protocol     |      Status:  new
  enhancement            |   Milestone:
 Priority:  minor        |     Version:
Component:  coap-tcp-    |  Resolution:
  tls                    |
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/core/trac/ticket/395#comment:1>
core <https://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Tue, 26 Apr 2016 11:14:36 -0000

#395: Session resumption

 Here is a summary of the session resumption (for CoAP over TCP).

 MQTT allows a client to terminate a TCP connection and to reconnect at a
 later time to then receive buffered data from the server side.

 For CoAP over TCP the proposal is to keep implementation complexity
 simpler by using the following policy: whenever a TCP connection is
 terminated then all state information is dumped. Caching of application
 layer messages is still possible using dedicated concepts, for example
 with queue mode (introduced by a mirror server).

 The recommendation is therefore not to make any changes in the document
 (or alternatively highlight that this functionality is not provided even
 thought it wouldn't normally be assumed to exist anyway).

Ticket URL: <https://trac.tools.ietf.org/wg/core/trac/ticket/395#comment:2>
core <https://tools.ietf.org/core/>