IETF Logo Mail Archive

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

"Patrik Fältström " <patrik@frobbit.se> Tue, 04 February 2020 12:07 UTC

Return-Path: <patrik@frobbit.se>
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 F30CF1200A4 for <i18ndir@ietfa.amsl.com>; Tue, 4 Feb 2020 04:07:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=frobbit.se
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 BDJ92frQO_hJ for <i18ndir@ietfa.amsl.com>; Tue, 4 Feb 2020 04:07:08 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41D4A120020 for <i18ndir@ietf.org>; Tue, 4 Feb 2020 04:07:07 -0800 (PST)
Received: from [192.168.11.141] (194-218-220-102.customer.telia.com [194.218.220.102]) by mail.frobbit.se (Postfix) with ESMTPSA id B4D8E2703A; Tue, 4 Feb 2020 13:07:04 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=frobbit.se; s=mail; t=1580818024; bh=qlujfN3OZaD4i45mz090kXJy3/zhS7ktwLoJNL8QkN0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=q1TZ1wUK3I+rEOKLI+G6wt7zyC2Evyd794XYqEXvPgswik2wCeUmKC9VDnEPVSbss BuUUMbnfuDtoigmt37ezlNrR9H9AzypOwoq0gqx9XwZsc9ckqBHdDfLqueI/q1i/Dy lZOkORksr7MllRwSd+6+2Lp9fdEypBax8vJhc/Ug=
From: Patrik Fältström <patrik@frobbit.se>
To: John C Klensin <john-ietf@jck.com>
Cc: John R Levine <johnl@taugh.com>, i18ndir@ietf.org
Date: Tue, 04 Feb 2020 13:07:02 +0100
X-Mailer: MailMate (1.13.1r5676)
Message-ID: <7D31FE0A-D4EC-4096-83FE-97D2BF4908F5@frobbit.se>
In-Reply-To: <D03AE38116EF15538E10CFAF@PSB>
References: <20200203173404.88EE813AA055@ary.qy> <E2361F8BA970A15043416C2D@PSB> <alpine.OSX.2.21.99999.374.2002031653540.31381@ary.qy> <D03AE38116EF15538E10CFAF@PSB>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_9FE29EAD-AD17-4B4A-8D42-54F0E07EB723_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18ndir/IlcRa_YUNLuTQbbD0iiQXaqnBTo>
Subject: Re: [I18ndir] 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 12:07:10 -0000

On 4 Feb 2020, at 2:30, John C Klensin wrote:

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

Don't forget normalization or otherwise how comparison is to be done of the UTF-8 encoded characters in the string. Nothing about that either.

   Patrik

> 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
>
> -- 
> I18ndir mailing list
> I18ndir@ietf.org
> https://www.ietf.org/mailman/listinfo/i18ndir

v2.23.0 | Report a Bug | By Email