Robert Wilton's No Objection on draft-ietf-httpbis-client-hints-14: (with COMMENT)

Robert Wilton via Datatracker <> Thu, 21 May 2020 10:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AAB0F3A0B87 for <>; Thu, 21 May 2020 03:20:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.649
X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id meoIoLZf4sVZ for <>; Thu, 21 May 2020 03:20:50 -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 0E3C03A0B84 for <>; Thu, 21 May 2020 03:20:49 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jbiGt-0007FL-SR for; Thu, 21 May 2020 10:17:51 +0000
Resent-Date: Thu, 21 May 2020 10:17:51 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jbiGs-0007EY-Fo for; Thu, 21 May 2020 10:17:50 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jbiGq-0002kk-Rx for; Thu, 21 May 2020 10:17:50 +0000
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id B34DA3A0B9C; Thu, 21 May 2020 03:17:36 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton via Datatracker <>
To: "The IESG" <>
Cc:,,, Mark Nottingham <>,
X-Test-IDTracker: no
X-IETF-IDTracker: 7.0.0
Auto-Submitted: auto-generated
Reply-To: Robert Wilton <>
Message-ID: <>
Date: Thu, 21 May 2020 03:17:36 -0700
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.2
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1jbiGq-0002kk-Rx 482d94ff8cce2279036c6e83d2fbb130
Subject: Robert Wilton's No Objection on draft-ietf-httpbis-client-hints-14: (with COMMENT)
Archived-At: <>
X-Mailing-List: <> archive/latest/37703
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Robert Wilton has entered the following ballot position for
draft-ietf-httpbis-client-hints-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:



Thanks for this document.  It seemed relatively easy to read, although I'm not
sure whether I'm totally bought into the idea since it feels like it is perhaps
making HTTP a little bit less stateless.  However, I'm not particularly
familiar with the details of HTTP as it is outside my domain of expertise.

One issue that wasn't clear to me was how do you ensure that two independent
entities don't both try and standardize the same client hint.  From looking at
the IANA section in it seems the answer
is probably that the client hint headers would be expected to be registered in
RFC3864.  It might be useful if this document had some text describing this,
along with a reference to RFC 3864.