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

Takeshi Yoshino <> Wed, 29 March 2017 04:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A9E9D1292AE for <>; Tue, 28 Mar 2017 21:05:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MvbxZIj00aw1 for <>; Tue, 28 Mar 2017 21:05:23 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BACE412948D for <>; Tue, 28 Mar 2017 21:05:19 -0700 (PDT)
Received: by 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;; 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;; 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 with SMTP id b83mr17246655wmi.21.1490760318193; Tue, 28 Mar 2017 21:05:18 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 28 Mar 2017 21:04:57 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Takeshi Yoshino <>
Date: Wed, 29 Mar 2017 13:04:57 +0900
Message-ID: <>
To: Moonchild <>
Cc: RFC Errata System <>, Ben Campbell <>,,, Salvatore Loreto <>, Gabriel Montenegro <>, "" <>
Content-Type: multipart/alternative; boundary=001a1146a17a366e89054bd6afe4
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: Wed, 29 Mar 2017 04:05:25 -0000

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 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

> 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 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?