W3C home > Mailing lists > Public > public-secondscreen@w3.org > April 2017

[presentation-api] Turn SHOULD into MUST for close/terminate messages handling?

From: François Daoust via GitHub <sysbot+gh@w3.org>
Date: Fri, 14 Apr 2017 15:14:11 +0000
To: public-secondscreen@w3.org
Message-ID: <issues.opened-221828402-1492182849-sysbot+gh@w3.org>
tidoust has just created a new issue for https://github.com/w3c/presentation-api:

== Turn SHOULD into MUST for close/terminate messages handling? ==
As I'm reviewing tests prepared by @tomoyukilabs for [close/terminate on the receiving side](https://github.com/w3c/web-platform-tests/pull/5562), there are two SHOULD in the Presentation API that now strike me as odd:

1. "If the user agent receives a signal from the destination browsing context that a PresentationConnection S is to be closed, it SHOULD close the presentation connection S with closed or wentaway as closeReason and an empty closeMessage", in [section 6.5](https://w3c.github.io/presentation-api/#interface-presentationconnection)
2. "When a receiving user agent is to send a termination confirmation for a presentation P, and that confirmation was received by a controlling user agent, the controlling user agent SHOULD run the following steps", in [section 6.5.8](https://w3c.github.io/presentation-api/#handling-a-termination-confirmation-in-a-controlling-user-agent)

Are there good reasons for these not to be MUST clauses? With SHOULD, it means a conforming implementation can reasonably ignore "close" and "terminate" messages it receives from the other end. By contrast, in Web socket, the user agent MUST close the connection if it receives a closing handshake from the other side.

Chrome seems to honour these messages. I haven't checked Mozilla's implementation but I suspect that's the case as well.

I get it we cannot guarantee that these messages reach the other side, but if they do, why ignore them?

Please view or discuss this issue at https://github.com/w3c/presentation-api/issues/422 using your GitHub account
Received on Friday, 14 April 2017 15:14:18 UTC

This archive was generated by hypermail 2.3.1 : Friday, 14 April 2017 15:14:18 UTC