From nobody Tue Mar 28 03:53:10 2017 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3079B12989F for ; Tue, 28 Mar 2017 03:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngHymmEi8P80 for ; Tue, 28 Mar 2017 03:53:06 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 819E91294E9 for ; Tue, 28 Mar 2017 03:53:06 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E5282B8128B; Tue, 28 Mar 2017 03:52:56 -0700 (PDT) To: tyoshino@google.com, ben@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm, Salvatore.Loreto@ericsson.com, Gabriel.Montenegro@microsoft.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: moonchild@palemoon.org, hybi@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170328105256.E5282B8128B@rfc-editor.org> Date: Tue, 28 Mar 2017 03:52:56 -0700 (PDT) Archived-At: Subject: [hybi] [Technical Errata Reported] RFC7692 (4982) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 10:53:08 -0000 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 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 nobody Tue Mar 28 05:57:52 2017 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C3E129539 for ; Tue, 28 Mar 2017 05:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAMbX_rtUN-H for ; Tue, 28 Mar 2017 05:57:49 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68EDB1243FE for ; Tue, 28 Mar 2017 05:57:49 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id w11so85956245wrc.3 for ; Tue, 28 Mar 2017 05:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0ecUUNYU6GXASAI6o4MXQhtrbhOZOOtANTqa5c7Kxos=; b=Z2w8HVk7A0x3MGWlOPU4OTfcRD6fdSDYZfivdT5kXK7Kiio++CmfhIHCRDQPGq7xsW VcvK6cvhz4195o1bwYQnq+WDZrVz4+NnP++DlvJQh5DYvVGEow3Lax4HT+11p+WdVA3V dPge3nCQV6Qi1FjQQik5ic/TXPDeCT9qCP1PHZhYgSPuJMSSsNLNmxYBF4CkbA9gWl2K M5e5/Pgc4DJ6ftpf6tAnLeuX9sC9T8sywMaUI3hNiUQBw9aSRLRCszvxq6eYjmeR6Rl+ rmazmVF63fm2asc/C9uPiicTc2g67Ik9K/DYVRydbOASSz8dUJs9Xcig3wjnNsSS5GqK mdOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0ecUUNYU6GXASAI6o4MXQhtrbhOZOOtANTqa5c7Kxos=; b=mDvhfzcJCL5Y+pjZbrrFXntg9ORPxWHASZC19zF+SRV/X1yDXz0IXsGSRXCTDh02EH zVXEJEAAvniF1WUl/kyWIKI9g9K4uYeUKRp4//Xrsd0jWVjCOA7Oa+Lqw8IsVGoSCzgt 3aM3bqRYgm/AaydwJCSo5GjWPp4KIZRaQvjNNniTcJqInYizY8tQj/ui/gy7fcdt44fX NAGDmXX86LDgCg/T8FHnHA8IN5+7f+W5DoQoG7KAaUiNUilm8YinFtM9h3D7Pg7hqWT5 ESpQHR9V+70f4ii9ebCILmPF1B18JFyiiDnBBvl36OR4KsLkYMCBbybl8b7q7NqIQi/F SOkQ== X-Gm-Message-State: AFeK/H2mahqZxcyYK1P/dkmtOHSOkr5WuJ1xHqWn3yqE6KRooxNjJe5f8Yy/mRQBeSAXvoqsmZHI5wTiL5UQl1zk X-Received: by 10.223.171.22 with SMTP id q22mr9640607wrc.163.1490705867112; Tue, 28 Mar 2017 05:57:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.172.39 with HTTP; Tue, 28 Mar 2017 05:57:26 -0700 (PDT) In-Reply-To: <20170328105256.E5282B8128B@rfc-editor.org> References: <20170328105256.E5282B8128B@rfc-editor.org> From: Takeshi Yoshino Date: Tue, 28 Mar 2017 21:57:26 +0900 Message-ID: To: RFC Errata System Cc: Ben Campbell , alissa@cooperw.in, aamelnikov@fastmail.fm, Salvatore Loreto , Gabriel Montenegro , Moonchild , "hybi@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c1b57c0ad3ecb054bca01fd Archived-At: Subject: Re: [hybi] [Technical Errata Reported] RFC7692 (4982) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 12:57:51 -0000 --94eb2c1b57c0ad3ecb054bca01fd Content-Type: text/plain; charset=UTF-8 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. --94eb2c1b57c0ad3ecb054bca01fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I discussed this with Mark a bi= t 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 a= fter the discussion I understood that lack of an explicit requirement askin= g clients to be prepared for a server_no_context_takeover in a handshake re= sponse 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 infe= r 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 conform= ant as Mark said but it would encounter interop issues. Since it's unco= mmon that a server sends an unsolicited server_no_context_takeover, it can = be after releasing their binary. That's worse.

----

For consistency with other para= graphs, 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" exten= sion parameter in an extension negotiation response regardless of whether o= r not the client may include the "server_no_context_takeover" ext= ension parameter in an extension negotiation offer.
=C2=A0
--94eb2c1b57c0ad3ecb054bca01fd-- From nobody Tue Mar 28 10:52:14 2017 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 823DF129713 for ; Tue, 28 Mar 2017 10:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apzH4J0VyZi9 for ; Tue, 28 Mar 2017 10:52:10 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4A3112878D for ; Tue, 28 Mar 2017 10:52:08 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id w43so97224572wrb.0 for ; Tue, 28 Mar 2017 10:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hY+rgde+fPPWNYcBLFspvumK55b2m+1RutgYw08f144=; b=KE57banwjeN8OZt8Oa79ntEzn5lREdCtNVdA/t+qOyj52TY+dscZEpQDXaff/4P2oF ragYQr2Pilq/b5vuHwfbVENXqJu9Q6jfY4/NoV3sd49pa3sUSjI+IA5JL8ObDOfC7jp6 rZpb04ZYN0aQOnGwo8CdfnGAYsULDcST/qM/MWR49TqOG+4cEKY+7L0UChtEK7U4zq4J tU/CiGEjGO/VDpScWyO/022ToRghd2U5KVwxHPsZySq3lI7I3RZstmXzTryYg7EWiBO2 /C7HxDqkLUUEoEulkYSWUNr/jghbfWcBi7aH35eeKqAzZ8EoS0S8LKOUFDYuQjfj0CHc LKTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hY+rgde+fPPWNYcBLFspvumK55b2m+1RutgYw08f144=; b=Mbc+2j2iAKyG+FMwoGL8kv+cyo6MkwlDQnH/oxYPfONE4q7mxMMNFr6Mj53ESnXlvD gC3yK7utUFJ4N6XCq3C1xg0iLerpISdY/wHSjYZH9BN3P7Ug2SeHJxqZr0w40ivkUCza bjbxpEy8vgV4TU+OM37J9Xt223SY4JOL8RaAxXu1iNAaen5hnUzyd2ic6HY9SH8uXGo6 HI2dzzdtw1vse2XvqmRtV3mMRO84SIedwdMIvqozSmFlv+NlRcSelLW7YuHaqO0Chv2g yrlm/EoyN/56wGaoHWMjIiVbR7yaAH4jj/k7l8F+tMthAyRPj3JvawFHieiNpNPJuVfP NHwQ== X-Gm-Message-State: AFeK/H2yjtmn5zqOYCsrqhhEOkjqsf+GrkVZc+3rm6aaIF7lEWH4fJCbixJlLWGlTGuf8hgiv36eDrkLmcm49QjU X-Received: by 10.223.163.206 with SMTP id m14mr29121687wrb.34.1490723527033; Tue, 28 Mar 2017 10:52:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.172.39 with HTTP; Tue, 28 Mar 2017 10:51:45 -0700 (PDT) In-Reply-To: References: <20170328105256.E5282B8128B@rfc-editor.org> From: Takeshi Yoshino Date: Wed, 29 Mar 2017 02:51:45 +0900 Message-ID: To: RFC Errata System Cc: Ben Campbell , alissa@cooperw.in, aamelnikov@fastmail.fm, Salvatore Loreto , Gabriel Montenegro , Moonchild , "hybi@ietf.org" Content-Type: multipart/alternative; boundary=f403045f220449de3e054bce1e1c Archived-At: Subject: Re: [hybi] [Technical Errata Reported] RFC7692 (4982) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 17:52:13 -0000 --f403045f220449de3e054bce1e1c Content-Type: text/plain; charset=UTF-8 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 --f403045f220449de3e054bce1e1c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The rationale can be applied al= so to an unsolicited server_max_window_bits which servers are allowed to se= nd as specified in https://tools.ietf.org/html/rfc7692#section-7.1.2.1
--f403045f220449de3e054bce1e1c-- From nobody Tue Mar 28 21:05:26 2017 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E9D1292AE for ; Tue, 28 Mar 2017 21:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvbxZIj00aw1 for ; Tue, 28 Mar 2017 21:05:23 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BACE412948D for ; Tue, 28 Mar 2017 21:05:19 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id x124so14091392wmf.0 for ; Tue, 28 Mar 2017 21:05:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=piLOnyEmnlc4lMJC9drD2gYNyInkY+02BDK5N5bkmaE=; b=BggWU23JPX7x028RfpNYe8mZveQkj0DeL8e7pcyQHgvCpG51rpmOn9Ohd8MK3yIm1Q mxIQjg+mvU3WaC2KKuzdX2BbPG2DOWmftWrN3pVxAtA8o0Kj8ZU5XEYtEFpR5hAJlcuX QtwsWlVOCULkrfSHqN6PcbKe7WF6abR1DAENSyYpxSf+B/YBNDEO+KCHd454OlIAtuy1 S7XWYBCCGnkwShVGmulb6FMfHtnUqpK4aM6Awe+kwHoySa7E6CS6P7thXQok+qKHDXh+ dTB7osH1/U7jbI07eTIcpCuDS5fbYou4uz/XOKUZ68RG9x1nU5bIpmRw/5Nz6qLWEtQd sQ0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=piLOnyEmnlc4lMJC9drD2gYNyInkY+02BDK5N5bkmaE=; b=tlvMdlFYbpC63ubCwVQhV5cCEgA8/0/JvoFUkZ2RIOt2W8fpuTX77IlgxdR4cl68Cz 9ZODVa27Vj7O84Xs27ImTQlWiyNTXLwJKUVmhWds7s5gs7aLvo0axsM+raXczeszNWmf B1wqd4+AEmiREUhWFHMQ+XgMuGCtDYZrrK9rXErgKa0Llg6lOe3sBwGEKKAZrcRjD4r2 YLyxMlUnothB1VArKzt61HCIFUgElE+3bZ9iNAWbcXn9i/HG5PE4Z7nYvRJDuuv88jt9 5CJPVOFCa8/+3CgraohVXFdc5eJyDLvUn94NBy+qTGL4GLoCy5uXJGhZtuk5eWsaxCba lITQ== X-Gm-Message-State: AFeK/H1WXjARVSxoGj5Mf0qeKyksahlt4VzkDd2znwnl1vuo8jfwJJnhBhz4LhGg65TlEwxSIxHGaZAKxXrgeB4E X-Received: by 10.28.109.214 with SMTP id b83mr17246655wmi.21.1490760318193; Tue, 28 Mar 2017 21:05:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.172.39 with HTTP; Tue, 28 Mar 2017 21:04:57 -0700 (PDT) In-Reply-To: <58DAC577.3000505@palemoon.org> References: <20170328105256.E5282B8128B@rfc-editor.org> <58DAC577.3000505@palemoon.org> From: Takeshi Yoshino Date: Wed, 29 Mar 2017 13:04:57 +0900 Message-ID: To: Moonchild Cc: RFC Errata System , Ben Campbell , alissa@cooperw.in, aamelnikov@fastmail.fm, Salvatore Loreto , Gabriel Montenegro , "hybi@ietf.org" Content-Type: multipart/alternative; boundary=001a1146a17a366e89054bd6afe4 Archived-At: Subject: Re: [hybi] [Technical Errata Reported] RFC7692 (4982) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 04:05:25 -0000 --001a1146a17a366e89054bd6afe4 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 29, 2017 at 5:20 AM, Moonchild 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 --001a1146a17a366e89054bd6afe4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Mar 29, 2017 at 5:20 AM, Moonchild <moonchild@palemoon.org>= ; wrote:
I thin= k 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 &quo= t;treat" and added "a hint" to the first paragraph instead t= o 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 los= t the original point by you again here that the statement for client requir= ements should be self-contained.
=C2=A0
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)
<= /blockquote>

In this document, the term "support&qu= ot; is really used to indicate that an endpoint can accept an offer/respons= e 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 ab= le to "accept") for an unsolicited server_no_context_takeover, it= leads the interop issue. "MUST support" would work enough to avo= id this badness.

When readers try to understa= nd what's the implementation to provide, they'll look for that and = find one in=C2=A0https://tools.ietf.org/html/rfc7692#section-7.2.2 section. As far a= s the spec is saying that readers need to always pay attention to server_no= _context_takeover, the confusion can be clarified here.
=C2=A0 =C2=A0If the "agreed parameters" contain = the "server_no_context_takeover"
=C2=A0 =C2=A0extension= parameter, the client MAY decompress each new message with
=C2= =A0 =C2=A0an empty LZ77 sliding window.=C2=A0 Otherwise, the client MUST de= compress
=C2=A0 =C2=A0each new message using the LZ77 sliding win= dow used to process the
=C2=A0 =C2=A0last compressed message.

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

Thanks
=C2=A0
--001a1146a17a366e89054bd6afe4-- From moonchild@palemoon.org Tue Mar 28 13:21:11 2017 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B376212944C for ; Tue, 28 Mar 2017 13:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=palemoon.org; domainkeys=pass (1024-bit key) header.from=moonchild@palemoon.org header.d=palemoon.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EH0eP5SCDeXk for ; Tue, 28 Mar 2017 13:21:10 -0700 (PDT) Received: from vmx.palemoon.org (vmx.palemoon.org [80.255.0.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CA3112955F for ; Tue, 28 Mar 2017 13:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/relaxed; d=palemoon.org; s=PaleMoon; t=1490732465; x=1491337265; q=dns/txt; h=DomainKey-Signature:Received:Subject:To:References: Cc:From:Organization:Message-ID:Date:User-Agent:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=4nVwLltjl RGzInmXBdm7EHOPs3yONQ5nRFuCeYZfHT4=; b=FK9CCJcz9LacKDVuQhB+aBl3S KBd+z7eYM5DcvfFf+p2kA4pYMvaSKPEtK3KrE1oMOg491SRFWx9+bsJVnUIgOzio xSm6O4fX5s8fg6ACnITUH1D3b6djA+gZjc77GWifykKFqVtNfgmkLHYyd50+xmt3 GccmFNS8mnSWoVDmkw= DomainKey-Signature: a=rsa-sha1; s=PaleMoon; d=palemoon.org; c=simple; q=dns; h=from:message-id; b=Yu3VFn/ghYWw98SJfX97rmfSONAeSLAuSPcSdYyMiHs3yqDFuEXTd8PjN7Sp kgsOb5lZDK+HA0KtP6ebbmWgQTEBbkhTCpmWdnhanlh7DAX103vDe9SpW AtygvoCDI0oL2Z2KtyHHcRJwBe/fu9pkIpAJT+XdOcyoj3bbPD/5aQ=; Received: from [192.168.0.53] by vmx.palemoon.org (Cipher TLSv1:-SHA:256) (MDaemon PRO v13.0.5) with ESMTP id md50000125717.msg for ; Tue, 28 Mar 2017 20:21:04 +0000 X-Spam-Processed: vmx.palemoon.org, Tue, 28 Mar 2017 20:21:04 +0000 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: moonchild@palemoon.org X-HashCash: 1:24:170328:md50000125717::KvSd3Zohh+dactwm:0005fpQg X-MDRemoteIP: 80.217.114.90 X-Return-Path: moonchild@palemoon.org X-Envelope-From: moonchild@palemoon.org X-MDaemon-Deliver-To: hybi@ietf.org To: Takeshi Yoshino , RFC Errata System References: <20170328105256.E5282B8128B@rfc-editor.org> Cc: Ben Campbell , alissa@cooperw.in, aamelnikov@fastmail.fm, Salvatore Loreto , Gabriel Montenegro , "hybi@ietf.org" From: Moonchild Organization: Moonchild productions Message-ID: <58DAC577.3000505@palemoon.org> Date: Tue, 28 Mar 2017 22:20:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:3.2) Gecko/20100101 Goanna/20170325 FossaMail/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Wed, 29 Mar 2017 02:49:16 -0700 Subject: Re: [hybi] [Technical Errata Reported] RFC7692 (4982) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 08:12:01 -0000 On 28/03/2017 14:57, Takeshi Yoshino wrote: > 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. > 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 nobody Wed Mar 29 02:49:36 2017 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC20C129666 for ; Wed, 29 Mar 2017 01:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=palemoon.org; domainkeys=pass (1024-bit key) header.from=moonchild@palemoon.org header.d=palemoon.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUx8pO-BiJNb for ; Wed, 29 Mar 2017 01:30:05 -0700 (PDT) Received: from vmx.palemoon.org (vmx.palemoon.org [80.255.0.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EEBD128B38 for ; Wed, 29 Mar 2017 01:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/relaxed; d=palemoon.org; s=PaleMoon; t=1490776202; x=1491381002; q=dns/txt; h=DomainKey-Signature:Received:Subject:To:References: Cc:From:Organization:Message-ID:Date:User-Agent:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=q8WzFfuWH V6T5KgYL38DaZlY3Sd1U+4OdSg+weLwyik=; b=ES/7skkJEIR9dz7Kje13tpM55 KODNpmc5qOvwAMqX8gHkY5s6yl3fICff9e8N7ZOtnhV3XC6uvzcms/wfyN1e24qN upBIruT1ZLweGQ9haknF6cz5oj1A+lAoTDvNIi7DzvibR0cCtd61KrXbH5IiovTZ FrFuY4c76FoNsQeM94= DomainKey-Signature: a=rsa-sha1; s=PaleMoon; d=palemoon.org; c=simple; q=dns; h=from:message-id; b=Mvdny2iguO14WFkmSu+wCMKpJpXMBs5c87LqRs2rqhG26deeHCM5hPlPgDkA TaGFr0rTrjx0DAwGgk1w0IDDzBA4s/R0afKtkCV4uvm5KX8YlUIAykmwU JErMqLP8fNZerSlimv6KvybywApIm2D2VK5ln9uVAtIU9WV5oc8VVI=; Received: from [192.168.0.53] by vmx.palemoon.org (Cipher TLSv1:-SHA:256) (MDaemon PRO v13.0.5) with ESMTP id md50000125774.msg for ; Wed, 29 Mar 2017 08:30:01 +0000 X-Spam-Processed: vmx.palemoon.org, Wed, 29 Mar 2017 08:30:01 +0000 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: moonchild@palemoon.org X-HashCash: 1:24:170329:md50000125774::sZrgt9/4/9FuKGF1:0001vZO1 X-MDRemoteIP: 80.217.114.90 X-Return-Path: moonchild@palemoon.org X-Envelope-From: moonchild@palemoon.org X-MDaemon-Deliver-To: hybi@ietf.org To: Takeshi Yoshino References: <20170328105256.E5282B8128B@rfc-editor.org> <58DAC577.3000505@palemoon.org> Cc: RFC Errata System , Ben Campbell , alissa@cooperw.in, aamelnikov@fastmail.fm, Salvatore Loreto , Gabriel Montenegro , "hybi@ietf.org" From: Moonchild Organization: Moonchild productions Message-ID: <58DB7058.5000102@palemoon.org> Date: Wed, 29 Mar 2017 10:29:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:3.2) Gecko/20100101 Goanna/20170325 FossaMail/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Wed, 29 Mar 2017 02:49:35 -0700 Subject: Re: [hybi] [Technical Errata Reported] RFC7692 (4982) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 08:30:07 -0000 > 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. 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. > 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? 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