Re: [Cbor] MIME tag 257 vs 36

Laurence Lundblade <> Fri, 25 September 2020 05:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E50BD3A0C2D for <>; Thu, 24 Sep 2020 22:24:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BZ1lBh9LngCg for <>; Thu, 24 Sep 2020 22:24:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 948263A0C27 for <>; Thu, 24 Sep 2020 22:24:54 -0700 (PDT)
Received: from [] ([]) by :SMTPAUTH: with ESMTPA id LgE1kc1Y5InvDLgE2khuFE; Thu, 24 Sep 2020 22:24:54 -0700
X-CMAE-Analysis: v=2.3 cv=LpLsNUVc c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=IkcTkHD0fZMA:10 a=gKmFwSsBAAAA:8 a=VrHXGImtAAAA:8 a=48vgC7mUAAAA:8 a=_5UdozuOaFNZ2wQscVoA:9 a=QEXdDO2ut3YA:10 a=nnPW6aIcBuj1ljLj_o6Q:22 a=rjybpTLx1R2UrS7S5igv:22 a=w1C3t2QeGrPiZgrLijVG:22
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\))
From: Laurence Lundblade <>
In-Reply-To: <>
Date: Thu, 24 Sep 2020 22:24:53 -0700
Cc: Jim Schaad <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <03e801d68f77$297a2800$7c6e7800$> <>
To: Carsten Bormann <>
X-Mailer: Apple Mail (2.3445.104.15)
X-CMAE-Envelope: MS4wfAfMY90a4QMrWnWRdFve+vAv3LTXFgmaItw8os3dJPsLet+GMLNq4PYTN7o5XpkdJ51W+cDsLkc96AfSgfbepdujFdW5Ui78qan53Flctpzu6qaiST3M G7FWBRah1qy3kM7QTvJMqa1jWGMdansNglxYrjXb31JiYl76mgJZw6JVAsGJMGDmLCEmU5biYEyFGKF7DmjAiWQo0U2TT5ek66NnaxlLwOUuOI0+lwVgDdjl
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 05:24:56 -0000

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
- Git stores LF and translates to local line ending

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.

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.

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)

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.


> On Sep 20, 2020, at 12:23 PM, Carsten Bormann <> wrote:
> On 2020-09-20, at 19:54, Jim Schaad <> wrote:
>> I don't see this as a CBOR problem at all.
> I agree.  Please see for my last year’s attempt to get some progress on the issue.  I got some great feedback and need to submit the -03 based on this feedback.  When a few CBOR drafts are out of the way…
> Grüße, Carsten