Re: [Cbor] MIME tag 257 vs 36

Carsten Bormann <> Fri, 25 September 2020 06:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 746D13A00E0 for <>; Thu, 24 Sep 2020 23:00:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.919
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sRAulpiglwra for <>; Thu, 24 Sep 2020 22:59:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BB1663A1188 for <>; Thu, 24 Sep 2020 22:59:57 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4ByLpz24VKzytC; Fri, 25 Sep 2020 07:59:55 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Fri, 25 Sep 2020 07:59:54 +0200
Cc: Jim Schaad <>,
X-Mao-Original-Outgoing-Id: 622706394.916219-793ac71ab77f37955d38ae78696fea2d
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <03e801d68f77$297a2800$7c6e7800$> <> <>
To: Laurence Lundblade <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Cbor] MIME tag 257 vs 36
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 25 Sep 2020 06:00:02 -0000

Hi Laurence,

On 2020-09-25, at 07:24, Laurence Lundblade <> wrote:
> I did some more reading:
> - CRLF is required for MIME headers, q-p, b64 CTEs (RFC 2045)
> - CRLF is required for text/xxx types (RFC 2046)
> - Unicode Format for Network Interchange requires CRLF (RFC 5198)
> - HTTP headers require CRLF

This is one of the big areas where the letter of the standards and the reality can differ a lot.  Newer versions of the standards tend to contain a larger dose of reality; e.g., RFC 7230:

   Although the line terminator for the start-line and header fields is
   the sequence CRLF, a recipient MAY recognize a single LF as a line
   terminator and ignore any preceding CR.

RFC 2616 was somewhat more weasely:

   RFC 2046 requires that content with a type of "text" represent
   line breaks as CRLF and forbids the use of CR or LF outside of line
   break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a
   line break within text content when a message is transmitted over

   Where it is possible, a proxy or gateway from HTTP to a strict MIME
   environment SHOULD translate all line breaks within the text media
   types described in section 3.7.1 of this document to the RFC 2049
   canonical form of CRLF. 

Since HTTP is what happens for most interchange, expect the strict CRLF requirement of RFC 2046 to be ignored.

> - Git stores LF and translates to local line ending

Git is rooted in reality.
(It gained CRLF support only after some gyrations.)

> These text formats choose a canonical line ending for on-the-wire messages so they can know to correctly translate to the local text format. These days it is just CRLF for Windows and LF for Linux/MacOS,


> it used to be CR for MacOS and in theory any local representation could be used including line lengths or a database of records.

I wish people would stop talking about CR line ends; these used to exist, but they no longer do in reality (outside very weird closed environments such as certain PDF files).  RFC 7230 reflects what the reality is, today, which is no longer very tolerant of pure-CR line endings (it’s been 20 years now since those became obsolete).

> It seems clear that tag 257 and 36 do require CRLF per the MIME standard. That’s all fine and there’s nothing more to do other than reference the MIME standard.

That’s what they say.
Any implementation that doesn’t accept LF line endings is pretty much broken for the real world.

> You all may have though about this more than me, but it also seems there is room for the definition of some tags for major type 3 used with line-oriented text since major type 3 is silent on the line ending convention (as it should be). Maybe:
>   Tag xx for IETF CRLF line endings (means translate CRLF to local; perhaps error on CR)
>   Tag yy fo MNU (means translate LF or CRLF to local; perhaps error on CR)

It may not be necessary to tag something for what it already is.
But it may be useful to be able to say in CDDL what a text string should look like  ; that may be something that could be added to the MNU specification or to a companion CDDL extension.

> CBOR protocols that use line-oriented data can specify which on-the-wire line ending they use, so the tags are not absolutely required, but they may be useful. They may also slightly help CBOR protocol designers using line-oriented text realize they need to say what the line ending is.

In reality, the line ending on the Internet is [CR] LF.  There is no other place CR can be used outside playing teleprinter (RFC 5198), so most software can simply treat CR as pure noise, which it typically does.

Grüße, Carsten