Re: [Cbor] 7049bis: The concept of "optional tagging" is not really used in practice #126

Christophe Lohr <christophe.lohr@imt-atlantique.fr> Sun, 03 November 2019 20:41 UTC

Return-Path: <christophe.lohr@imt-atlantique.fr>
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 6BCA0120073 for <cbor@ietfa.amsl.com>; Sun, 3 Nov 2019 12:41:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=imt-atlantique.fr
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 dFVwc6EBpg55 for <cbor@ietfa.amsl.com>; Sun, 3 Nov 2019 12:41:42 -0800 (PST)
Received: from zproxy110.enst.fr (zproxy110.enst.fr [IPv6:2001:660:330f:2::c0]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 668E712002E for <cbor@ietf.org>; Sun, 3 Nov 2019 12:41:42 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id B032E81360 for <cbor@ietf.org>; Sun, 3 Nov 2019 21:41:40 +0100 (CET)
Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id exssrNXDt_FO for <cbor@ietf.org>; Sun, 3 Nov 2019 21:41:40 +0100 (CET)
Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id 44A9B8137C for <cbor@ietf.org>; Sun, 3 Nov 2019 21:41:40 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy110.enst.fr 44A9B8137C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1572813700; bh=X68noN6GxAo7Zbt+MvNamy6oS0EkN+vxCwxT3iCdjio=; h=To:From:Message-ID:Date:MIME-Version; b=QvBomA9HNYasGtxE2KkhS600lvbdW/wEz0Ki1/v7caOoaztbBh9seeYX+vzWYPUac GPiZORRVWDEKgAjZBBLk1CpH8YA5xTw0rrmRETQ1bo5+pCm1uieCdwrLok4id5TiCm m/KrbaCt06qXNxYAbQpLva8si+4GQ5KIeY0ga4vg=
X-Virus-Scanned: amavisd-new at zproxy110.enst.fr
Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id HRwztPTVZlbI for <cbor@ietf.org>; Sun, 3 Nov 2019 21:41:40 +0100 (CET)
Received: from [192.168.1.4] (157.68.93.79.rev.sfr.net [79.93.68.157]) by zproxy110.enst.fr (Postfix) with ESMTPSA id 0D58181360 for <cbor@ietf.org>; Sun, 3 Nov 2019 21:41:39 +0100 (CET)
References: <92400DAA-A713-4905-A721-34B138E25192@tzi.org> <ed45e995-1858-3169-1be6-0cce5ce37ce3@imt-atlantique.fr> <87889E65-0152-455A-A6B7-C5F336DC97A4@island-resort.com>
To: cbor@ietf.org
From: Christophe Lohr <christophe.lohr@imt-atlantique.fr>
Openpgp: preference=signencrypt
Autocrypt: addr=christophe.lohr@imt-atlantique.fr; prefer-encrypt=mutual; keydata= mQINBFidiI4BEAC/zpewWjK9zQSDxb5ue3RvpVE3GJJZHZtCTnUpUnlMs2cKE5ZFwgYnMGr6 hFZFubcZcg2iTWCAcGcaqGHufFlv1+T/zw6tN0XUEnJRDAdqPeefjrRzf264efp/2kfftJkU rWS7cPPOYjSbsB+TMjDL13+lGAh3wceo8kXrCRSEKnzCGKcwrgNNIWwISqD/+1/2rppCEE55 Mx7Gh/NtLDhrhrlSJe5UhRa5PHG17FyFwnpP+Mplqy5AGjt2cEdooQBqOJR8k0UksYmSw2uU 2zP779xr9Jh9zjwZxXFia6Q7ZmOMnMjMWG225iVPphye5TS1s/1LTOXZYUWFY8RCuVxR2YHg C0qsd5lC0Hei/WODt0Lx0T4DgHXEe6zqg1X4PKCqWW7DaPUMy1v1yfu8K1T7ySUSxNan8XuA om15iYqJHjHLBuMxq3TKAOoHaWecdP7tAK58WVncsWb4vQZGweSQRsr/CBgRmsZM4UcT0Kkr t0rOAfpW9t4vz3dqn80MwRu9UGVnc2fLgC0Ml+ymsBFnDZjYTg/4vAas7E9V2E7uVfOXB9Mr PwB4u3+VdKgI2qRYEUUbvmrw9sYX/we4eh3qUtXcSXuvhu4ukDrjFKMGgZXccgXbsevzi24o j3IopUdrY0OrsMXhqHlMwrw4iq5aZujxP0T1CzVW6qAIZD9HewARAQABtEJDaHJpc3RvcGhl IExvaHIgKFdvcmsgYWRkcmVzcykgPGNocmlzdG9waGUubG9ockBpbXQtYXRsYW50aXF1ZS5m cj6JAk4EEwEIADgWIQRBlpOqI8ZwLZqLQzc/4GWuK29VCgUCWJ2IjgIbAwULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRA/4GWuK29VCnAaD/wIwRul4rfN5g9PPX5o89JtXKJHbdl/Ql8W +td240unsleBaJkqZTcnARmk+enYB5d54taM6e+Sodsjskt1P4mwX1AVR2/F/woeqEZxMMKQ xAQHFP+IInYsJHFw8qYO33Dc+Xlf6FGXMHGsPDoPbpWIZLMJbh20K9VeeEMuOBuTGnZHJhDy SyBnkgF3z4m37VVZKIC4CMbpswEqSPrI+U7Bmcr4LseqRN/6P3ivAHvF3hTy2cpAvLfbBQSm E91CdRzzZ5rvYnk3SsiBZ75IelYmaCqpDSPuzJSMAePiI3SvdoVWl4Hl81y0lGfFeMkx+xxk 01YJUFAjIllOW0xVueODuXT70XI+xkds1QIuSG8IO/AaDk7zrB+5LpPTF+vrdd07yTyk6gUD ZJqWI56Nhvkq+ORskWnPDOHy6Zd1Ov4ke3bVxuGn0Y/Vzkdp7U2SqJEb82OkGAWw4IS9NbWm IlKKxsGJSsnlq7HxX0m/5+DTHnlCjdI/iyXxUOwp15Wc7M7xOwg+34ME1uUJ9lOsqxVUopYG e2rbJK+LNzRUHx+aDSE3LYSEd481h6lelqJ9bE1Dri2Um/YHZK8DoVvrMV7+FdfjX75ooaV+ XDa4rc6M0lIz20yPBB2kWC2qAObelRNK28pUWMfc4fS238pIjYqlhassImksSEVWq52ypryi l7kCDQRYnYiOARAAwdGm1tsrDtx8nn5ykcld8fYM4LRPRrwekDi7GYuJZq2rQvVccMpmb9v8 nlloYEDAf7nnqlH7nHEmZP+j6w0oxkUp/leKGeGddEiLsKY+BcmgricktNxdsoIryDLpmI+j qjGw5UtEBDO8+iBDi+Nu78SSa9UKEfxw+KUhPWWUiHSKEO4+wov0B5dswTtVGACtbjwTFVVr LHCXP0O4nmlRgh89y7rEFIReOMLQUxzHttMsEe7qlZuX49jYtAabAaFmmh96BoepQY1Gq1+M ShD9PTUb2dKpNBwWbM94gHIkYYHcChPsAbj1D3Xgxx2U+55+49zUClJ6AXxNZQGtPvhYsYm+ Fde2REQh7zcefjTq2FvXIXyUiRyYL2nR3oQTzdsuoY81zBokETt7hVeRa/vHblLIx25mFrqF ccjKvE4NmMzYTh7oUJWPWGB/o6WxGlDG01hz6Kv+fCxRReW1nbMOxe7FjCTTuzxF9Y9pueE8 MOKMTXR1Z1dnznOyTfqkKEYKejPpD3nZPhNUrnxkiccjKI1RRyWqz9mXCZWw/NdWOscGorNL +KAyFpNRFXelgIsPcmSBrZq3Z6+QBYEgm92qo5/dnvf/vwZBXdeiNuhkz0iyDiFsMWIyiJ/b bZBmbnNTbSHmbS0ObbuO3duWCs/m3wKiDjACAdG7HXNsFFL2L1sAEQEAAYkCNgQYAQgAIBYh BEGWk6ojxnAtmotDNz/gZa4rb1UKBQJYnYiOAhsMAAoJED/gZa4rb1UKpO4P/RqIjeePf4o9 rcT93UfSPgg+dlJjv1OgCYkURrXHB80h3PKEO9YDCcW6b0Zmzr048eNNGk54d5pflqZClIte IjgV6OcsGrSydickN9rRmXhRbwqcEhLasjJaSyIFwxmadc7aBuiFSJyuvHU4OPBZIx3eArb5 e+vNeNkP14p0yrWUeQ608xn8WgReDyIxwmnMkxoZkwlj9O2+zCyyLo6jKtVCfn4LZpwcwUP9 awQeQqU7WYckzm4fO+2JxmZ0zhIjia3ROdrw00H3V8KbDWcKTL7IWDqoLF/afDRQTMkrDmmY LF6Pgk5Lg/uUo3CBv8EzJXscZ2w6Ttzv0o5lECHMpQvmeitW56/rfQMIZTXhOxrhzi5jXWRz t0M54F9PVmyOX9a5qrlyU28mi1Mgs+uvmjXMFEwg+h8lCrayeOR1nwPMr4FgoHsHU6JyUVxv pIgBF5Q8HpPZuQUEaEz5Bl3uEI3ofI616dCmh42GCHOFvc8bIORwLYaNTs0zGEc4bLVe9cGf i7uJTfshDnL4aKGLbNebV7mUJ1TNEQ8Syx5fWpt/92XECtE9ovSQHCXabTNzGb63Z5HtqOUA TTNmm76rXBSrlvtPv548cMXw4dejA09u1tCFNEyuHzOgT2ZJzEkUY96iNf5ZC+qyOcttgQWV ejdE1EpSVxnHMn0oG8z+dXZZ
Message-ID: <06592ab7-f3cb-1a59-1b32-ffba3194162c@imt-atlantique.fr>
Date: Sun, 3 Nov 2019 21:40:39 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <87889E65-0152-455A-A6B7-C5F336DC97A4@island-resort.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: fr
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/-axF7tKS0O7FaHa__RjPuumccI0>
Subject: Re: [Cbor] 7049bis: The concept of "optional tagging" is not really used in practice #126
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: Sun, 03 Nov 2019 20:41:46 -0000

>>    3.  Data must be able to be decoded without a schema description.
>>        *  Similar to JSON, encoded data should be self-describing so
>>           that a generic decoder can be written.

My confusion comes probably from vocabulary issues.

The sentence here probably talks about "a schema description" from the
/coding-decoding/ point of view, and nothing else.

Such as, let's say, the IP header: without the RFC in hands (its
description), there is no way to decode a set of 20 bytes and to guess
that the first 4 bits are an unsigned int, followed by another 4 bits
unsigned int, followed by an array of 8 booleans, etc. 
A CBOR (or a JSON) coding format can tell this, without the need of
another writing document to specify this.

However, I read "schema description" from the /semantic/ point of view:
a description which explains the meaning of data items.  The IP RFC not
only tells that the first 4bits are an unsigned int, it also tells that
this number is the protocol version. 
CBOR (neither JSON) can't tells this by itself, except if one defines a
TAG for this.


So, the next question is: "is there some guidelines for using TAGs?"

Well, it's probably too early. One may have to wait that CBOR usages
grow in maturity.
But what's your opinion?

Let's say I'm designing a system.  CBOR is used (for messages, recording
data files, or whatever).
What should I decide for my system design regarding CBOR TAGs?
Shall I:
- prohibit TAGs since this is redundant with other parts of my design
specifications (which already explicit the meaning of each field); or
- put TAGs everywhere for everything because TAGs bring semantic to data; or
- add TAGs to some fields and not to others (which ones and why?)

The right answer is probably: "this depends". ;-)
but of what?

Best regards
Christophe