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

Julian Reschke <> Thu, 06 October 2016 12:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ECB42129639 for <>; Thu, 6 Oct 2016 05:50:06 -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 P9AQbUzENlj0 for <>; Thu, 6 Oct 2016 05:50:03 -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 BA8BE12963F for <>; Thu, 6 Oct 2016 05:49:54 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bs83D-0007kK-1f for; Thu, 06 Oct 2016 12:45:27 +0000
Resent-Date: Thu, 06 Oct 2016 12:45:27 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bs837-0006xN-As for; Thu, 06 Oct 2016 12:45:21 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1bs833-0007Qm-HS for; Thu, 06 Oct 2016 12:45:19 +0000
Received: from [] ([]) by (mrgmx102) with ESMTPSA (Nemesis) id 0LcEPJ-1b9TQN2Ih3-00jWjl; Thu, 06 Oct 2016 14:44:10 +0200
To: "Martin J. Dürst" <>, Mark Nottingham <>
References: <> <> <> <>
Cc: HTTP Working Group <>
From: Julian Reschke <>
Message-ID: <>
Date: Thu, 06 Oct 2016 14:44:10 +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="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:yaOm1B6lUM4mPByXGo1HsmkcElpVXUwMV8ej9VPCnafSBaZn0WZ w63m7ecj0IvjtgUQ0LdNmP8es2S4cgM4l+XUmv0qzeSKTVv5gkajg+aW0zt6IjK+YIi6PVE e0IL2kY8gJj6q2xwAPXF7LZFEobAaBFeHAX7tW+gxIem173mzjGwGWwnNtH53M30dz1AIsI 4sVrAT5PieY4isQz9GgcQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:ZwFBmbLSnH0=:7c7yWF87wb/Vw02pJDxKMF b4jjpSSD9Z6Am8hAaS4nEz8iVR80IS+1XmnFodRn97x3pqHcjQ6AjDpNSCNypMTSKbhlI6nem odY2JtPDx4ye9J8zOwsUlEOUM7z2np+MZpVO29ZV7OVblkoQInwciCMJDmezs9qMNi55RdSA9 Gqu9fWTGX1J6FGdqBZVA4bOPLdbgNs/Q0PenSAfHOTPe4bLSIeZ1GwfD8BzZ+iUr6NfrnYfly ktER7glt8NMAvdM6GbCY0KGVacgjX98EAehCVNeevmjR5LtL+MLNi7k6pNdixE7slntutKnSv /seAEM5GVkqonw0Avpcuc4ONd3QOvFC8/gMRhtuuuyqaVblhIV4n7V6dkZYIc+XpDOm1VqJUj 5XviG4PJ0JXZYUwaS69lgkNng0irlu1gUqyKEWUPk+TeZ87SfkVa6ZZGznF4WqnKFm7X4pIdy DtZlO6w6fLO8AY7uMyPEqtQW4lRYvAYOYRpg62kJb/NF1JLqhX/mnsYPgpOyXuDbwKMZ2XAJm pe8kql1Pax/feIJ8SmNxcp7df7o3VIpstjPcPULus5bJPHs6C/Wb+45PhT3mm2o7O1qZ8fCKk 5OPAgpJmcYFZunKFi0L/DlcBvIwtqGauhpNzfc7yL5pKURPGL05WbyA9bvx43bymjUHr17Ub4 rcNThWMr1h3xTOcSnNDVOatpPRq7W89pQ7O13EKyJtda5Lcd9OjDPNQm1T6emhRF4vBrSvO9H ptPOfAPMES0UO0+nay/p7i5he8gpV4H7jDGzK/FJxZoivdClOTacEeFSBU1O76PNPb+tTqPgT mwsm/si
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-8.2
X-W3C-Hub-Spam-Report: AWL=1.351, 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: 1bs833-0007Qm-HS 3f329f826df4bd3f4bd44d031d664765
Subject: Re: #227: Encoding advice for new headers and parameters
Archived-At: <>
X-Mailing-List: <> archive/latest/32502
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 2016-10-04 05:28, Martin J. Dürst wrote:
> On 2016/10/04 10:59, Mark Nottingham wrote:
>> <chair hat> it sounds like we can close this issue with no action --
>> anyone else have thoughts?
> Well, this is in no way a new thought, but it is worth repeating: What
> about just using UTF-8, plain and simple.

Well, that's an orthogonal discussion. It hasn't been UTF-8 in the past, 
and APIs assume otherwise, so it's not that simple. But it's certainly 
something we can consider in the future.

FWIW, I tried to better explain this in 

(We discussed this a bit in Stockholm, and my proposal was just to 
opt-in using a BOM in the first bytes of the field value...).

> This solution was available almost 20 years ago (see RFC 2277). There
> were certain backwards-compatibility issues, the worst of which
> according to my knowledge would have been that UTF-8 would have shown up
> as double-encoded garbage when interpreted as iso-8859-1 (as defined in
> HTTP at that time).
> What I find extremely disappointing is that despite this group being
> composed of a lot of very intelligent people, it was impossible to move
> towards such a simple solution even at a slow pace. The good thing is
> that it's never too late. But that doesn't mean that we have to push
> this solution out another 20 or 50 years.

I agree that we need a better solution than RFC 5987.

However, the purpose of 5987bis is just to update a specification that's 
already in use.

Best regards, Julian