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

Takeshi Yoshino <> Tue, 28 March 2017 12:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 64C3E129539 for <>; Tue, 28 Mar 2017 05:57:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KAMbX_rtUN-H for <>; Tue, 28 Mar 2017 05:57:49 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 68EDB1243FE for <>; Tue, 28 Mar 2017 05:57:49 -0700 (PDT)
Received: by 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;; 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;; 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 with SMTP id q22mr9640607wrc.163.1490705867112; Tue, 28 Mar 2017 05:57:47 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 28 Mar 2017 05:57:26 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Takeshi Yoshino <>
Date: Tue, 28 Mar 2017 21:57:26 +0900
Message-ID: <>
To: RFC Errata System <>
Cc: Ben Campbell <>,,, Salvatore Loreto <>, Gabriel Montenegro <>, Moonchild <>, "" <>
Content-Type: multipart/alternative; boundary=94eb2c1b57c0ad3ecb054bca01fd
Archived-At: <>
Subject: Re: [hybi] [Technical Errata Reported] RFC7692 (4982)
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

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


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.