Re: #227: Encoding advice for new headers and parameters

Julian Reschke <> Tue, 04 October 2016 05:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 057451295C9 for <>; Mon, 3 Oct 2016 22:57:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.917
X-Spam-Status: No, score=-9.917 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.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EMJ0oafjXDdU for <>; Mon, 3 Oct 2016 22:57:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5944B129558 for <>; Mon, 3 Oct 2016 22:57:32 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1brIfJ-0004m9-0G for; Tue, 04 Oct 2016 05:53:21 +0000
Resent-Date: Tue, 04 Oct 2016 05:53:21 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1brIfE-0004lS-RN for; Tue, 04 Oct 2016 05:53:16 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1brIfC-00027p-UK for; Tue, 04 Oct 2016 05:53:16 +0000
Received: from [] ([]) by (mrgmx002) with ESMTPSA (Nemesis) id 0MBnvD-1bioKH2wcR-00AmhK; Tue, 04 Oct 2016 07:52:38 +0200
To: Mark Nottingham <>
References: <> <> <>
Cc: HTTP Working Group <>
From: Julian Reschke <>
Message-ID: <>
Date: Tue, 4 Oct 2016 07:52:37 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:tgfXHrHPL0VmKNYQJ7xpBj9dhLWW8m5mNq5PGzijIXW+b9CtsOH 9UZme3L0WJ0F1L/PnvuVUl8s0jq06Ssx0yB/NmvxcqTfNUr0+4gZ5ggbzffa9zijK4kYBck VKQaeU09XrowjzF9ic2cv2ylZhAQA4WG7kUNy17Tqf20bl/S9XAF6/L9qtQ5XAsscGcg7Qf xixYbow2OO0y3ymu6cGug==
X-UI-Out-Filterresults: notjunk:1;V01:K0:c6Ko9cxAgZk=:5A0YXUR2Fr1n2BQ2HXrkSw oyPm9uXoghMPczdtdMEc5mmaiIbJZR7OK+yx2FbTlRJdP4Tovoy0Z53N6TfEXWH0KvucCdUXJ gU2BHNAPx8cudMqw70BXVGDhRzLWCxEOwYg1vaks6+HZoW9MkrRvPJERKmkz738Y63YClo8qj KGxkU7pSpZM1X84V1xtQukFnCExfNuVeGuB0AZ/rg6/PNGBtdJn5CIljVJpnwhyDDJ5tPKg86 mQ5G5KSEBA5vCg8PAlDGTY2ZDx36hE1pM96MfP/wsa8AT8Lt/v+kwW1hrUH7QtEF593n58sbq AoAh7u3W/gO+obSl/mJYKkf50GHv9D9K6lRbOWWeWZ9cXQgnxwcR0Aqy0PWBxRBSLb0VYFlrY SozprzIoDaCeM6b7EDqkP4kLCJkTbNu/u2EHUZw/Reh8TDNqd7vAabUhH7Z7dLdy/Fj2KYcKh DZElXjl4bcykOj2ugM3INl0nycty1QZYjrzUxQxKawcfcvXoZ0xD1e+dR8c36n+CGiR9gk6j5 g1tY/X8rLNKCuLvUBoXd+wD1/tScxgot8c0hClHqsRsbdkomLkaT0ALWWnadRcV0Ka67ebuea ulFCk7ZZjQ2d1I2gLXMJcDLWUR9phBn2uOh+NreWh4IT22fU9sQSA1UME9GKNKh103Z23InDw vnNfmntKz7CfH3WZ7xOAySlGAxy2psxWLx11OAFuSxijs1ni+xvpmmU5k9k01XvFMsOtVKrH+ ml47hWjpAjyQn2RYs+LyZXQjq4W/X54YvzPSOn3GTWCZ/2aZV6LOhDJR7WdvEx7MTZ2EpHgOl xmINJke
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-8.2
X-W3C-Hub-Spam-Report: AWL=1.422, BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1brIfC-00027p-UK 40ad17be267fda2e4812eb55fc719662
Subject: Re: #227: Encoding advice for new headers and parameters
Archived-At: <>
X-Mailing-List: <> archive/latest/32460
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 2016-10-04 03:59, Mark Nottingham wrote:
>> On 29 Sep. 2016, at 11:48 pm, Julian Reschke <> wrote:
>> On 2016-09-28 04:29, Mark Nottingham wrote:
>>> [ "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 <>), 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.
>> It complicates processing *slightly*.
> I'm not taking about parsing overhead, I'm talking about complication to the model for headers that use it -- as we saw in Link.

Yes, that's what I'm talking about as well. Reasoning about

   title=x; title*=UTF-8''y

is not that different than about

   title=x; title=y

>> The issue of parameters potentially repeating, and the fact that you need to define what to do in that case, exists in any way. It is inherent in any format that supports name/value pairs.
> Yes, but RFC5987 encoding complicates it further, because now you have the possibility of multiple parameters in two different encodings, and potentially different rules / precedences for each encoding.

I don't see how that makes it significantly harder. Furthermore, the old 
spec already recommends precedence (and that' what is implemented), and 
we can talk about strengthening that requirement.

>>> 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).
>> RFC 5987 defines a way to deal with non-ASCII. It's not pretty, has a slightly bizarre syntax, but at least it's there, and it has been implemented successfully in all widely deployed user agents.
> I agree with all of that.
>> Defining *another* way to achieve this seems like a bad idea to me (insert XKCD reference here...).
> I didn't say we needed to define another one; I just think we should stop promoting this one.

Which IMHO leaves spec authors in a worse position.

> ...

Best regards, Julian