Re: Murray Kucherawy's Discuss on draft-ietf-httpbis-client-hints-13: (with DISCUSS and COMMENT)

"Murray S. Kucherawy" <> Mon, 11 May 2020 17:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 89A3F3A0B47 for <>; Mon, 11 May 2020 10:28:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.748
X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IWM6CNYwiHzB for <>; Mon, 11 May 2020 10:27:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7366B3A0B4B for <>; Mon, 11 May 2020 10:27:56 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jYCAb-000080-OS for; Mon, 11 May 2020 17:24:49 +0000
Resent-Date: Mon, 11 May 2020 17:24:49 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jYCAa-00007A-Lj for; Mon, 11 May 2020 17:24:48 +0000
Received: from ([2607:f8b0:4864:20::e29]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jYCAY-00075O-8Q for; Mon, 11 May 2020 17:24:47 +0000
Received: by with SMTP id s11so6103486vsm.3 for <>; Mon, 11 May 2020 10:24:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ErTZn/2H3Sn8T1onuPjKOzqdWDpAtnHflE62IzsnEHU=; b=C51c+N9mxrdZCl0ywuBnVOdhn9/6KudBGUPdQBEICHYNNFmZFzPv8W665+SD8lFnOJ T4wygUp93TudoLbRwW7DuHugyuO3Uwl9CCjHZDoxh65HhucQX64ZSTDXcuDmKiLGfgJq cHriyf7MCpD9F0yaXeZw0JB/Sn5OxKKLzHCagC2l8rlehUx5nJHifJmKmXop7a6SB90D +7GJqab58TYNBiBvEoTxHNVXaqzDuihor36XAurZllkS630VmHtlNCeXWSxNVIwE+VCX k8tTUNyQ73Mkvt6Fk3X3jGoqGk1sISYaXrdSpt20o9E/ZooWiVZgnowgYKCeokRdmpJK dEwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ErTZn/2H3Sn8T1onuPjKOzqdWDpAtnHflE62IzsnEHU=; b=S0ECky5rQLCU81oZBJh1jwwGvSA6c4+mMVstzievq2lNUwod9W0fT2ez0DGwr4Zyng g8UHzcXX9t8N+eKly49nb6SYwPH79fkD6Xslchzuhpce9am7Ar+9WcuKd/u4Jul6UWBh kTZahQocpVGBVpkj0O9vPZ132gQ7tptFMVDXnep2MG8fSq1FiS5nkxF43Vas1kLyfM/q vB9pC4UOecVXa4bBFRMRCclDkhvafo4/i7JJQY7fjcGj+k3VNJF4zx4vRroCgJLGMcRa FmrgDjU99h/FfVMxYWzp2brluaYKwfHe5M2oIFiI77F2OKclnvoMQJA9bnHT5jCD5W9x 8bkg==
X-Gm-Message-State: AGi0PuaAj/RKHGuXrnEu7BWbEL+6WsMfv7tUNk7d7J+p/9cJ4Pd0V6SD OQDWXcqm1Cb/GtQY8mp8rIz5doi2/As7bHa1U68=
X-Google-Smtp-Source: APiQypLaU9eueP2HyG6id0u2mt45BD4x5Xb5QUpNv1yu/s9V1an2s/KIvxX4sSkbIBumHZ5UE2i3iwuHc3FDVS9oXQc=
X-Received: by 2002:a67:f7c9:: with SMTP id a9mr12578765vsp.7.1589217875367; Mon, 11 May 2020 10:24:35 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: "Murray S. Kucherawy" <>
Date: Mon, 11 May 2020 10:24:23 -0700
Message-ID: <>
To: Yoav Weiss <>
Cc: The IESG <>,,, " Group" <>, Mark Nottingham <>
Content-Type: multipart/alternative; boundary="000000000000ee9b8105a5629e41"
Received-SPF: pass client-ip=2607:f8b0:4864:20::e29;;
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1jYCAY-00075O-8Q bd8407897fd8b7b2180317f9fc4ae9f6
Subject: Re: Murray Kucherawy's Discuss on draft-ietf-httpbis-client-hints-13: (with DISCUSS and COMMENT)
Archived-At: <>
X-Mailing-List: <> archive/latest/37594
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Thanks for replying.  As a reminder, once you've dealt with the IANA
concern, the rest of these comments are non-blocking.  However, I'm happy
to discuss them too.

On Mon, May 11, 2020 at 12:58 AM Yoav Weiss <> wrote:

> * "Implementers SHOULD be aware ..." -- this feels like an
>> awkward construction; might I choose not to be aware?
> MUST be aware?

Just "need to be aware".  I find it awkward to apply
compliance/requirements language to people.

* "Such features SHOULD take
>> into account ..." -- same issue as before, this seems an odd use of BCP 14
>> language
> * "User agents SHOULD consider ..." -- same
> * "Implementers ought to
>> consider ..." -- why is this only "ought to" given the prior SHOULDs?
> Would turning all those to a MUST work?

In the third bullet I was trying to illustrate my point: I think it makes
more sense not to use requirements language when talking about people, so
that one seems right to me.

RFC2119 Section 6 gives guidance that's relevant here.

In the first two bullets above, I don't know how to measure compliance with
the requirement that a feature SHOULD take something into account, or
SHOULD consider something.  I think the guidance you're providing needs to
either be more direct and explain what compliance looks like, or not use
these key words at all (at least not in their all-caps forms) if all you
want to do is bring a particular topic to the attention of an implementer.

You also have a "SHOULD take into account" wrapping a list that has two
SHOULD NOTs in it.  I don't know how to interpret that.

Section 6.1:
>> * Why does "Specification document(s)" refer to only a specific section
>> of this
>> document?  Isn't the whole document applicable?
> Sure. It's currently pointing at the specific section that defines the
> header, but I can change it to refer to the whole document if that's
> preferred.

The registration document says you can do it either way.  I just find
identifying a specific section to be unusual and I was curious.