Be more explicit that connection handling is in the hand of the application

[cabo]

(See TSVART review and Mirja's questions:)

"Summary: This document is well-written. It is almost ready to be
published
as a PS draft once the following points are addressed.

1: It is not clear how the protocol reacts the errors from transport
layers
(e.g. connection failure).
  The protocol will just inform apps of the events and the app will
decide
what to do or the protocol itself will do something?

2: There will be situations where the app layer is freezing while the
transport layer is still working. Since transport layers cannot detect
this
type of failures, there should be some mechanisms for it somewhere in
the
protocol or in the app layer.  The doc needs to address this point. For
example, what will happen when a PONG message is not returned for a
certain
amount of time?

3: Since this draft defines new SZX value, I think the doc needs to
update
RFC7959. This point should be clarified more in the doc.“

3) And inline with Yoshi's comment, I don't think this part in section
3.3 is well specified; especially I don't understand how these two thing
fit together:
"To avoid unnecessary latency, a Connection Initiator MAY send
  additional messages without waiting to receive the Connection
  Acceptor's CSM; ..."
and
  "Endpoints MUST treat a missing or invalid CSM as a connection error
  and abort the connection (see Section 5.6)."
Also how long should I wait until I abort the connection?

[brianraymor]

My perception is that this has been asked and answered. For example - https://www.ietf.org/mail-archive/web/core/current/msg08621.html

PONG is modeled on similar mechanisms in RFC6455 and RFC7540. Neither provides any guidance for this case. It's expected that an application framework would define and enforce the appropriate policy for timeouts or retries.

[brianraymor]

From https://www.ietf.org/mail-archive/web/core/current/msg08958.html

... One plan would be to appropriate some text from section 6 of RFC 7230, which might include phrases such as "It is beyond the scope of this specification to describe “ and "Implementations ought to anticipate the need to recover from asynchronous close events.”

I don’t think it is the intention of the WG to prescribe specific timing or other parameters related to connection management; e.g., we have learned from RFC 2616 that standardizing a specific number for the limit to simultaneous connections (end of section 8.1.4 there) can be a mistake; this was not repeated in RFC 7230 (replacement text: "A client ought to limit the number of simultaneous open connections that it maintains to a given server.” — no specific number given, and non-RFC2119 “ought to” language).