Re: [Cbor] MIME tag 257 vs 36

Carsten Bormann <cabo@tzi.org> Wed, 16 September 2020 16:22 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25FFD3A0DE5 for <cbor@ietfa.amsl.com>; Wed, 16 Sep 2020 09:22:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 QSDJ3ucYqDWs for <cbor@ietfa.amsl.com>; Wed, 16 Sep 2020 09:22:47 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FA2F3A0A38 for <cbor@ietf.org>; Wed, 16 Sep 2020 09:22:47 -0700 (PDT)
Received: from [172.16.42.104] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Bs53n6r8qz109j; Wed, 16 Sep 2020 18:22:45 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <77902B73-54E2-455C-88D3-D9CC62EDD84E@island-resort.com>
Date: Wed, 16 Sep 2020 18:22:45 +0200
Cc: cbor@ietf.org
X-Mao-Original-Outgoing-Id: 621966164.862945-b8cae2110e6b89a96caff5d2a5d5f29e
Content-Transfer-Encoding: quoted-printable
Message-Id: <4271C433-0B38-4B05-AD44-01830EDBD834@tzi.org>
References: <77902B73-54E2-455C-88D3-D9CC62EDD84E@island-resort.com>
To: Laurence Lundblade <lgl@island-resort.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/BL4CwXYzE8cN3MBxlCSDCjEJ64o>
Subject: Re: [Cbor] MIME tag 257 vs 36
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Sep 2020 16:22:50 -0000

> On 2020-09-15, at 22:17, Laurence Lundblade <lgl@island-resort.com> wrote:
> 
> Does this seem right?
> 
> MIME tag 257 can carry MIME messages that have any content transfer encoding.

Yes, except we don’t really care about the content transfer encoding (that is internal to the MIME message), we care about whether the result is UTF-8 or not (and tag 257 can carry UTF-8 and non-UTF-8 MIME messages).

> It is not necessary to use tag 36 for content transfer encoding 7bit, base64 and quoted printable. You cannot however use tag 36 with content transfer encoding binary. You probably can use tag 36 with content transfer encoding 8bit.

In all these cases, if the encoded message happens to be UTF-8, you can still use tag 36.  Whether you should, is maybe another question.

> It is thus recommend protocols use tag 257 when encoding MIME messages. Use of tag 36 should be avoided. It’s primary use is in protocols that were defined before tag 257 was defined.

That is a permissible conclusion.

> I don’t think this is an issue, but I have little bit of worry that tag 36 might give you some end-of-line canonicalization because it is UTF-8 that tag 257 won’t.

I don’t think CBOR decoders can do end—of-line processing willy-nilly in their UTF-8 strings, so I don’t see an issue.

Note that I just did PR#210 for the tag 35 issues; I don’t see a need to apply any further changes to the text on tag 36.

Grüße, Carsten