IETF Logo Mail Archive

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

John C Klensin <john-ietf@jck.com> Tue, 04 February 2020 01:30 UTC

Return-Path: <john-ietf@jck.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 0018712004A for <i18ndir@ietfa.amsl.com>; Mon, 3 Feb 2020 17:30:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 H8ajiefMh1J9 for <i18ndir@ietfa.amsl.com>; Mon, 3 Feb 2020 17:30:18 -0800 (PST)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6344412001A for <i18ndir@ietf.org>; Mon, 3 Feb 2020 17:30:18 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1iyn2d-000KbZ-9p; Mon, 03 Feb 2020 20:30:15 -0500
Date: Mon, 03 Feb 2020 20:30:10 -0500
From: John C Klensin <john-ietf@jck.com>
To: John R Levine <johnl@taugh.com>
cc: i18ndir@ietf.org
Message-ID: <D03AE38116EF15538E10CFAF@PSB>
In-Reply-To: <alpine.OSX.2.21.99999.374.2002031653540.31381@ary.qy>
References: <20200203173404.88EE813AA055@ary.qy> <E2361F8BA970A15043416C2D@PSB> <alpine.OSX.2.21.99999.374.2002031653540.31381@ary.qy>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18ndir/giemDsd5UduB8gQKHXPPMrLGN-o>
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: Tue, 04 Feb 2020 01:30:20 -0000


--On Monday, February 3, 2020 17:05 -0500 John R Levine
<johnl@taugh.com> wrote:

>...
> 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.

And omission of a clear model for specifying what is really what
we call a "charset" elsewhere (not just an encoding) is the one
clear defect in that particular discussion in the document.

Seems to me that, unless there is a desire to reinvent the
wheel, using the encoded word model of RFC 2231 (or something
very much like it)  but strictly with Base64, would be the right
way to go.

best,
  john

v2.23.0 | Report a Bug | By Email