Re: [I18ndir] Fwd: Working Group Last Call: Structured Headers for HTTP

"John R Levine" <johnl@taugh.com> Mon, 03 February 2020 22:05 UTC

Return-Path: <johnl@taugh.com>
X-Original-To: i18ndir@ietfa.amsl.com
Delivered-To: i18ndir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4028120C50 for <i18ndir@ietfa.amsl.com>; Mon, 3 Feb 2020 14:05:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=B+TnTqyW; dkim=pass (1536-bit key) header.d=taugh.com header.b=q9Qw0jCI
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-0oXzxu0fxB for <i18ndir@ietfa.amsl.com>; Mon, 3 Feb 2020 14:05:56 -0800 (PST)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEDC412090D for <i18ndir@ietf.org>; Mon, 3 Feb 2020 14:05:55 -0800 (PST)
Received: (qmail 96061 invoked from network); 3 Feb 2020 22:05:55 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1773b.5e389943.k2002; i=johnl-iecc.com@submit.iecc.com; bh=IzU0AtigFP3RYxs8ep0fKxU5QfVJXuwN7gtk1WSTNaY=; b=B+TnTqyWvTwKirxJTDS3ZpHCIZ6Y5uF1bcvE7l+GMpBUNusyW91RUAS9V0sPJmrC36twYezxYi8L0GOtyHr/1saHi3OWjMDbcl9PcFU7BvWPnsvTV2n0pNI6TtuvwancJw1Lx4faAGF+Slpn9yaPxClfxRG3yaR07MixNU3pnIZIdCy4NwxWIqQlMOmYgnYvNfJhTCWcSgNXfZbkbdtBwinJYJwmVSeSsTh6KIIvb0vTZWDKVFJdTpv1ZIsNUAOx
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1773b.5e389943.k2002; olt=johnl-iecc.com@submit.iecc.com; bh=IzU0AtigFP3RYxs8ep0fKxU5QfVJXuwN7gtk1WSTNaY=; b=q9Qw0jCIxBfph0fuOqeVPgq7Z3gVSYVrA+DFJlezg6PHIzqzS48Nz9bnB8RTGawUmaiuEITMFBJ4fC+Vv+GWussZ0K/W3BxQbDfS2JU7LqHJBnW556nUAw1kBkGZTyI0vhfltBsJruHs9R0sMZ7GI0yeykvuXG17rrWFzDawpDRanN40aJ2n5IRksbuISpLchukNxuoRh3YIA96AMKSMSkrKZpokNGkpjkHrClms9trOta8H1cNpQIew1YuNuasU
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 03 Feb 2020 22:05:54 -0000
Date: Mon, 03 Feb 2020 17:05:54 -0500
Message-ID: <alpine.OSX.2.21.99999.374.2002031653540.31381@ary.qy>
From: John R Levine <johnl@taugh.com>
To: John C Klensin <john-ietf@jck.com>
Cc: i18ndir@ietf.org
In-Reply-To: <E2361F8BA970A15043416C2D@PSB>
References: <20200203173404.88EE813AA055@ary.qy> <E2361F8BA970A15043416C2D@PSB>
User-Agent: Alpine 2.21.99999 (OSX 374 2019-10-27)
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18ndir/-IFb0QYEs4Y8A-CVzUjDoTkot4c>
Subject: Re: [I18ndir] Fwd: Working Group Last Call: Structured Headers for HTTP
X-BeenThere: i18ndir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Internationalization Directorate <i18ndir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i18ndir/>
List-Post: <mailto:i18ndir@ietf.org>
List-Help: <mailto:i18ndir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Feb 2020 22:06:00 -0000

On Mon, 3 Feb 2020, John C Klensin wrote:
> I had assumed that Martin was concerned about HTTP header field
> values, not field names. ...

You're right, I misread it, but I still agree with you that it would not 
be a great idea to allow UTF-8.  While UTF-8 is the most popular encoding 
for web pages, it's not mandatory and I'm sure there are still plenty of 
pages in other encodings, particularly in Asian languages.

In section 3.3.3 it says that non-ASCII text is to be encoded as base64, 
which seems reasonable, "along with a character encoding (preferably 
UTF-8)" but it doesn't have any convention for where the encoding goes. 
Experience with MIME suggests that life is simpler if there's a standard 
form for an encoded text blob so libraries can decode and if need be 
transliterate in one go.

It also seems to me that this draft is reinventing JSON badly, but I don't 
think it would be helpful to point it out.  I do like section 1.1 which 
instructs implementors to fix bugs rather than working around them.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly