[Cbor] Another view on tags

Laurence Lundblade <lgl@island-resort.com> Fri, 29 March 2019 11:07 UTC

Return-Path: <lgl@island-resort.com>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6AB95120264 for <cbor@ietfa.amsl.com>; Fri, 29 Mar 2019 04:07:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ezqdf113DOuq for <cbor@ietfa.amsl.com>; Fri, 29 Mar 2019 04:07:51 -0700 (PDT)
Received: from p3plsmtpa11-10.prod.phx3.secureserver.net (p3plsmtpa11-10.prod.phx3.secureserver.net []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AABA120258 for <cbor@ietf.org>; Fri, 29 Mar 2019 04:07:51 -0700 (PDT)
Received: from dhcp-95db.meeting.ietf.org ([]) by :SMTPAUTH: with ESMTPSA id 9pMShQROOtlFQ9pMTh0e8B; Fri, 29 Mar 2019 04:07:50 -0700
From: Laurence Lundblade <lgl@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_10DDAC5F-0C23-494D-B100-AA9DDCA158DC"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Message-Id: <250C6053-B5B2-4A51-ACC7-3D156A8D17EF@island-resort.com>
Date: Fri, 29 Mar 2019 12:07:47 +0100
To: cbor@ietf.org
X-Mailer: Apple Mail (2.3445.9.1)
X-CMAE-Envelope: MS4wfCHxoMAnJ8GZZJfudwVYkIoP1KLSlnpW5K8E6RLv6jLbJFS4/jv3vzJlDYqH1uivwzimPgFzQzeIzoq5X1Zwy70O08djo/tApXdhDTdSp+YV8MExx62i NLYxKSmRFmSo6fSVmjWBZCe6YWPOyJeOoYzAh6eIDWT0hvJSKNvF8vMOj5kRPedV1fPIFN/8debyvg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/DkCs0Oa1iv5nXb14I7WvN_1iS_Q>
Subject: [Cbor] Another view on tags
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: Fri, 29 Mar 2019 11:07:54 -0000

Seems like a large part of the value of defining tags is in the selection or design of the type itself rather than the actual tagging.  It is the CBOR experts writing down the best way to encode some particular type of data. Epoch-based date is a good example. If you want to put a nice compact date into a CBOR protocol, use the epoch-based date (and don’t do something awkward like repackage ASN.1 GeneralizedTime). Bignums, decimal fractions, big floats and arrays are types designed by CBOR experts. Epoch date, date string and the like are existing types pre-approved for use in CBOR protocols by experts.

Further, these standardized extended types, can be implemented by generalized encoder/decoders and get broad support. This is a big win IMO.

It seems possible and sometimes useful to use these “extended types” without an explicit tag. A protocol might say, a particular data item in a map should be in the format of a bigfloat even though there is no tag 5. You might call this implicit tagging.

I’m not sure where to go next:
- Should we say explicitly that it is OK to use extended data types without a tag?
- Should general encoder decoders have APIs to deal with these extended types even when not tagged? 
- Recommendations for use of explicit or implicit tagging of extended types in protocols?