#227: Encoding advice for new headers and parameters

Mark Nottingham <mnot@mnot.net> Wed, 28 September 2016 02:34 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id F3BCA12B3BD for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 27 Sep 2016 19:34:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.237
X-Spam-Status: No, score=-9.237 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Sx6bl5J6p9Iv for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 27 Sep 2016 19:34:10 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B09C12B3A4 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 27 Sep 2016 19:34:10 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bp4d8-0004rO-9G for ietf-http-wg-dist@listhub.w3.org; Wed, 28 Sep 2016 02:29:54 +0000
Resent-Date: Wed, 28 Sep 2016 02:29:54 +0000
Resent-Message-Id: <E1bp4d8-0004rO-9G@frink.w3.org>
Received: from lisa.w3.org ([]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mnot@mnot.net>) id 1bp4cw-0004qB-FY for ietf-http-wg@listhub.w3.org; Wed, 28 Sep 2016 02:29:42 +0000
Received: from mxout-07.mxes.net ([]) by lisa.w3.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <mnot@mnot.net>) id 1bp4cu-0001uM-Nv for ietf-http-wg@w3.org; Wed, 28 Sep 2016 02:29:41 +0000
Received: from [] (unknown []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D55FD22E1FA for <ietf-http-wg@w3.org>; Tue, 27 Sep 2016 22:29:16 -0400 (EDT)
From: Mark Nottingham <mnot@mnot.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\))
Message-Id: <0168B53E-A4CB-41BA-B371-7499837A327E@mnot.net>
Date: Wed, 28 Sep 2016 12:29:13 +1000
To: HTTP Working Group <ietf-http-wg@w3.org>
X-Mailer: Apple Mail (2.3226)
Received-SPF: pass client-ip=; envelope-from=mnot@mnot.net; helo=mxout-07.mxes.net
X-W3C-Hub-Spam-Status: No, score=-8.3
X-W3C-Hub-Spam-Report: AWL=1.351, BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1bp4cu-0001uM-Nv 316dea3eb178cbe07b535530b9bb867d
X-Original-To: ietf-http-wg@w3.org
Subject: #227: Encoding advice for new headers and parameters
Archived-At: <http://www.w3.org/mid/0168B53E-A4CB-41BA-B371-7499837A327E@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32418
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

[ "just me" hat on ]


After some discussion in Berlin and Stockholm, as well as experience with dealing with i18n in parameters for the Link header (see <https://github.com/mnot/I-D/issues/180>), I think we should give more definite advice about when RFC5987(bis) encoding should and should not be used.

In particular, flagging encoding by using a parameter name complicates extension processing (see the issue referenced above), and causes a lot of uncertainty about precedence, etc.

I think it would be much simpler and more reliable to advise people minting new HTTP headers to *not* use RFC5987(bis) encoding, but instead advise that they mandate use of an encoding on the field (or a specified portion thereof).

E.g., if the "foo" parameter on the "bar" header field might need to accept non-ascii content, it MUST be generated with those characters encoded, and MUST be parsed by first decoding that portion of the header.

The actual encoding to be used need not be specified, but the simplest approach would probably be to use RFC3986 %-encoding over a UTF-8 string.

A more aggressive approach would be to also recommend that new parameters on existing fields (even if they specify use of 5987) SHOULD use such encoding. 

Thoughts? I'm not going to lie down in the road for this, in that I suspect that most people will gravitate towards this kind of solution naturally, rather than use 5987, but it'd be nice to put clear advice out there.


Mark Nottingham   https://www.mnot.net/