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

Moonchild <> Wed, 29 March 2017 08:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DC20C129666 for <>; Wed, 29 Mar 2017 01:30:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=pass (1024-bit key); domainkeys=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eUx8pO-BiJNb for <>; Wed, 29 Mar 2017 01:30:05 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (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;; 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;; c=simple; q=dns; h=from:message-id; b=Mvdny2iguO14WFkmSu+wCMKpJpXMBs5c87LqRs2rqhG26deeHCM5hPlPgDkA TaGFr0rTrjx0DAwGgk1w0IDDzBA4s/R0afKtkCV4uvm5KX8YlUIAykmwU JErMqLP8fNZerSlimv6KvybywApIm2D2VK5ln9uVAtIU9WV5oc8VVI=;
Received: from [] by (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:, Wed, 29 Mar 2017 08:30:01 +0000 (not processed: message from trusted or authenticated source)
X-HashCash: 1:24:170329:md50000125774::sZrgt9/4/9FuKGF1:0001vZO1
To: Takeshi Yoshino <>
References: <> <> <> <>
Cc: RFC Errata System <>, Ben Campbell <>,,, Salvatore Loreto <>, Gabriel Montenegro <>, "" <>
From: Moonchild <>
Organization: Moonchild productions
Message-ID: <>
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-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,