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

Takeshi Yoshino <tyoshino@google.com> Tue, 28 March 2017 12:57 UTC

Return-Path: <tyoshino@google.com>
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 <hybi@ietfa.amsl.com>; 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 <hybi@ietfa.amsl.com>; 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 <hybi@ietf.org>; Tue, 28 Mar 2017 05:57:49 -0700 (PDT)
Received: by mail-wr0-x22c.google.com with SMTP id w11so85956245wrc.3 for <hybi@ietf.org>; 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 <tyoshino@google.com>
Date: Tue, 28 Mar 2017 21:57:26 +0900
Message-ID: <CAH9hSJZczOmsDPo-7gmTxWLtzE=VKXFFoh20OVWQtvNeCKz=mg@mail.gmail.com>
To: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: Ben Campbell <ben@nostrum.com>, alissa@cooperw.in, aamelnikov@fastmail.fm, Salvatore Loreto <Salvatore.Loreto@ericsson.com>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, Moonchild <moonchild@palemoon.org>, "hybi@ietf.org" <hybi@ietf.org>
Content-Type: multipart/alternative; boundary=94eb2c1b57c0ad3ecb054bca01fd
Archived-At: <https://mailarchive.ietf.org/arch/msg/hybi/dc5Iw0GVo9eaK2fZr0qvd5ItLig>
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 <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hybi/>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=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
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.