IETF Logo Mail Archive

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

Moonchild <moonchild@palemoon.org> Wed, 29 March 2017 08:30 UTC

Return-Path: <moonchild@palemoon.org>
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 <hybi@ietfa.amsl.com>; 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 <hybi@ietfa.amsl.com>; 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 <hybi@ietf.org>; 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 <hybi@ietf.org>; 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 <tyoshino@google.com>
References: <20170328105256.E5282B8128B@rfc-editor.org> <CAH9hSJZczOmsDPo-7gmTxWLtzE=VKXFFoh20OVWQtvNeCKz=mg@mail.gmail.com> <58DAC577.3000505@palemoon.org> <CAH9hSJYb1WYSOB7hZGfBcM0ubeeWkG28AeV8XyVey-o4hKt7CA@mail.gmail.com>
Cc: RFC Errata System <rfc-editor@rfc-editor.org>, Ben Campbell <ben@nostrum.com>, alissa@cooperw.in, aamelnikov@fastmail.fm, Salvatore Loreto <Salvatore.Loreto@ericsson.com>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, "hybi@ietf.org" <hybi@ietf.org>
From: Moonchild <moonchild@palemoon.org>
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: <CAH9hSJYb1WYSOB7hZGfBcM0ubeeWkG28AeV8XyVey-o4hKt7CA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/hybi/j_n2mBG1w0oyIEwXTGJeOkzUJwE>
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 <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: 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

v2.23.0 | Report a Bug | By Email