Subject: [hybi] [Technical Errata Reported] RFC7692 (4982)

From: RFC Errata System <[email-masked]>
Date: Tue, 28 Mar 2017 03:52:56 -0700 (PDT)

The following errata report has been submitted for RFC7692,
"Compression Extensions for WebSocket".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7692&eid=4982

--------------------------------------
Type: Technical
Reported by: Mark Straver <[email-masked]>

Section: 7.1.1.1

Original Text
-------------
A server MAY include the "server_no_context_takeover" extension
parameter in an extension negotiation response even if the extension
negotiation offer being accepted by the extension negotiation
response didn't include the "server_no_context_takeover" extension
parameter.

Corrected Text
--------------
A server MAY include the "server_no_context_takeover" extension
parameter in an extension negotiation response even if the extension
negotiation offer being accepted by the extension negotiation
response didn't include the "server_no_context_takeover" extension
parameter.
A client SHOULD treat the "server_no_context_takeover" extension
parameter in an extension negotiation response as a hint with no
requirement to provide an implementation, and MUST NOT treat this
parameter, if included in the response, as an invalid configuration.

Notes
-----
It is currently possible for a client and a server to implement per spec and fail to make a connection.

There is no requirement for a client to implement this purely optional parameter, nor to understand this parameter if not implemented. If not supported, this would result in an invalid configuration. As a result, point 7 mandates that the socket connection MUST be closed.
This will only occur if a client has no implementation for this parameter and does not understand/accept the parameter, and the server sends an unsolicited "server_no_context_takeover" parameter in its response, which is allowed.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7692 (draft-ietf-hybi-permessage-compression-28)
--------------------------------------
Title               : Compression Extensions for WebSocket
Publication Date    : December 2015
Author(s)           : T. Yoshino
Category            : PROPOSED STANDARD
Source              : BiDirectional or Server-Initiated HTTP
Area                : Applications and Real-Time
Stream              : IETF
Verifying Party     : IESG

---

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 28 Mar 2017 21:57:26 +0900

I discussed this with Mark a bit before Mark filed this.

I hesitated to agree with the opinion initially because everyone can just
choose to have their client support the parameter. But after the discussion
I understood that lack of an explicit requirement asking clients to be
prepared for a server_no_context_takeover in a handshake response would
bother client implementors.

The paragraph "A server MAY include the "server_no_context_takeover"
extension ..." is a (MAY) requirement for servers. It's natural that client
implementors don't look into it much. The spec shouldn't ask client
implementors to infer what clients MUST do from the paragraph. In fact, a
client that rejects a server_no_context_takeover in a handshake response is
totally spec conformant as Mark said but it would encounter interop issues.
Since it's uncommon that a server sends an unsolicited
server_no_context_takeover, it can be after releasing their binary. That's
worse.

----

For consistency with other paragraphs, we could also rewrite the paragraphs
as follows.

A server MAY ... response _as a hint_ even if ...

A client MUST support the "server_no_context_takeover" extension parameter
in an extension negotiation response regardless of whether or not the
client may include the "server_no_context_takeover" extension parameter in
an extension negotiation offer.

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 29 Mar 2017 02:51:45 +0900

The rationale can be applied also to an unsolicited server_max_window_bits
which servers are allowed to send as specified in
https://tools.ietf.org/html/rfc7692#section-7.1.2.1

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 29 Mar 2017 13:04:57 +0900

On Wed, Mar 29, 2017 at 5:20 AM, Moonchild <[email-masked]> wrote:

> I think you have to be careful here that you're not going to imply that
> a client must support the parameter in its implementation, but merely
>

I tried to avoid introducing a new term "treat" and added "a hint" to the
first paragraph instead to clarify this point. The term hint is well
explained in https://tools.ietf.org/html/rfc7692#section-5 and readers
should be able know that they can safely ignore it as far as all the
requirements are met. But yes, you're right. I lost the original point by
you again here that the statement for client requirements should be
self-contained.

> that the parameter as part of a response must be *accepted* (but may be
> ignored if no implementation is being provided to back this parameter)
>

In this document, the term "support" is really used to indicate that an
endpoint can accept an offer/response with the extension parameter.
Requirements for endpoints that accepted it are described separately.

The main pain point was that if the spec is not clear that a client should
be prepared (must be able to "accept") for an unsolicited
server_no_context_takeover, it leads the interop issue. "MUST support"
would work enough to avoid this badness.

When readers try to understand what's the implementation to provide,
they'll look for that and find one in
https://tools.ietf.org/html/rfc7692#section-7.2.2 section. As far as the
spec is saying that readers need to always pay attention to
server_no_context_takeover, the confusion can be clarified here.

   If the "agreed parameters" contain the "server_no_context_takeover"
   extension parameter, the client MAY decompress each new message with
   an empty LZ77 sliding window.  Otherwise, the client MUST decompress
   each new message using the LZ77 sliding window used to process the
   last compressed message.

The MAY sentence is already implying that point. The Otherwise sentence
corresponds to the "ignoring the parameter" case. What do you think. Can't
this serve enough for clarification?

Thanks

---

From: Moonchild <[email-masked]>
Date: Tue, 28 Mar 2017 22:20:07 +0200

On 28/03/2017 14:57, Takeshi Yoshino wrote:
> For consistency with other paragraphs, we could also rewrite the
> paragraphs as follows.
> 
> A client MUST support the "server_no_context_takeover" extension
> parameter in an extension negotiation response regardless of whether or
> not the client may include the "server_no_context_takeover" extension
> parameter in an extension negotiation offer.
>  

I think you have to be careful here that you're not going to imply that
a client must support the parameter in its implementation, but merely
that the parameter as part of a response must be *accepted* (but may be
ignored if no implementation is being provided to back this parameter)
as part of a valid configuration. That is why I suggested my initial
errata wording as I did in the corrected text.

I also agree that the exact same rationale applies to 7.1.2.1
"server_max_window_bits" since that can also be sent unsolicited by the
server to a client, even if the client may not support that functionality.

---

From: Moonchild <[email-masked]>
Date: Wed, 29 Mar 2017 10:29:12 +0200

> The main pain point was that if the spec is not clear that a client
> should be prepared (must be able to "accept") for an unsolicited

I see. Having the coherence of statements spread out over 3 points in
the text doesn't make it the clearest or easiest to interpret and could
maybe use a rewrite, but that's an editorial issue that is beside this
point of change.

> corresponds to the "ignoring the parameter" case. What do you think.
> Can't this serve enough for clarification?

Yes, it would serve well since it is made clear that
implementation-backing is optional in those cases, even though support
for the response becomes mandatory.

Kind regards,
MC