Re: [Cbor] MIME tag 257 vs 36

Carsten Bormann <> Sat, 26 September 2020 06:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E0973A1059 for <>; Fri, 25 Sep 2020 23:57:08 -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 H0B33ULN_x_B for <>; Fri, 25 Sep 2020 23:57:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A15FC3A1055 for <>; Fri, 25 Sep 2020 23:57:04 -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 4Bz02N6c0lzySW; Sat, 26 Sep 2020 08:57:00 +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: Sat, 26 Sep 2020 08:57:00 +0200
Cc:, Jim Schaad <>
X-Mao-Original-Outgoing-Id: 622796220.4544491-302ddcdfb877371e79c8c459c1f7bc3e
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: Sat, 26 Sep 2020 06:57:08 -0000

Hi Laurence,

> On 2020-09-25, at 19:11, Laurence Lundblade <> wrote:
> Hi Carsten,
> Thanks for the detailed explanation.
> Is this a good summary of the upshot?
> Text lines in Internet protocols (on the wire) are delimited by either a CRLF or just an LF. Officially many protocols specify CRLF, but implementations often work with either.


> CBOR type 3 text can be either line ending, even a mixture of both.

CBOR text strings can contain any UTF-8, so they are agnostic to line endings.
(“CBOR type 3 text” is a pleonasm, but also leaving out the word “major”.)

> Operating systems usually have a line end convention. Windows uses CRLF. Linux and MacOS use LF. Some applications on a given OS may work with either and some may prefer the OS’s line ending convention.


> The majority of use cases and CBOR protocols using type 3 text will work with either line ending. However, some use cases or protocols may not work with either in which case translation to and/or from the local line end convention, typically that of the OS, is necessary.

I think the important observation is that most of the limitations to one type of line ending stem from using line endings as part of the encoding/framing of a TCP-based protocol.  E.g., SMTP is less tolerant of modern line endings because it needs to react to CRLF dot CRLF (unless some SMTP framing is used).  That is not a problem with CBOR-based protocols, as the framing is coming from the self-delimiting CBOR encoding, not from parsing text streams.

> Are you proposing that CDDL be able to specify a line end convention for type 3 items?

I think that might be useful.  Most text strings in CBOR protocols are “1-D”, i.e., they don’t employ line endings.  Where “2-D” text is intended, indicating a preference for a form of line ending, or a restriction to a form of line ending, might be useful.  Of course, restricting text content can today be done with regexes (and soon with ABNF); there is no .feature in regex/ABNF though…

Grüße, Carsten