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

Christophe Lohr <christophe.lohr@imt-atlantique.fr> Thu, 24 October 2019 08:51 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 933101200B8 for <cbor@ietfa.amsl.com>; Thu, 24 Oct 2019 01:51:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 4JboanRkhEkm for <cbor@ietfa.amsl.com>; Thu, 24 Oct 2019 01:51:06 -0700 (PDT)
Received: from zproxy110.enst.fr (zproxy110.enst.fr [137.194.2.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E3BD12006B for <cbor@ietf.org>; Thu, 24 Oct 2019 01:51:06 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id EF82682423 for <cbor@ietf.org>; Thu, 24 Oct 2019 10:51:04 +0200 (CEST)
Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id sUo_btuaDvvK for <cbor@ietf.org>; Thu, 24 Oct 2019 10:51:01 +0200 (CEST)
Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id 6312582223 for <cbor@ietf.org>; Thu, 24 Oct 2019 10:51:01 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy110.enst.fr 6312582223
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1571907061; bh=AHGkMyaHFYTqyx5KYNW0QIhVshOO7goyHWg9XpwIK9I=; h=To:From:Message-ID:Date:MIME-Version; b=UJx3JfkROKMDq7+CXv5LKtUOMKKYilfnCjuAZyVnXlepVLpiARkPI208YcGGUcKEE xOYpRf+7rdhPNyfKu9ZMchlUNHgw+NZ+Z+MzpVlCnLh0cNfhe0mltahVqEIhst1IJS 0dEGwsMeNqeXSrIFtnTMaCG6zDksx5gDTnC8+Z1A=
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 sDQ6eRqM9P3q for <cbor@ietf.org>; Thu, 24 Oct 2019 10:51:01 +0200 (CEST)
Received: from [IPv6:2001:660:7302:5:ba85:84ff:feb0:351a] (unknown [IPv6:2001:660:7302:5:ba85:84ff:feb0:351a]) by zproxy110.enst.fr (Postfix) with ESMTPSA id 36FF68242E for <cbor@ietf.org>; Thu, 24 Oct 2019 10:51:01 +0200 (CEST)
To: cbor@ietf.org
References: <92400DAA-A713-4905-A721-34B138E25192@tzi.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: <ed45e995-1858-3169-1be6-0cce5ce37ce3@imt-atlantique.fr>
Date: Thu, 24 Oct 2019 10:50:59 +0200
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: <92400DAA-A713-4905-A721-34B138E25192@tzi.org>
Content-Type: text/plain; charset=utf-8
Content-Language: fr
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/34jYFnwD31J7r5dG0k8gVnYM8Rw>
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: Thu, 24 Oct 2019 08:51:09 -0000

On 23/10/2019 13:38, Carsten Bormann wrote:
> Section 3.4 talks about "optional tagging" as a secondary purpose of tags. But in today's CBOR protocols, tags are rarely "optional" in the sense that they can simply be left out without a change in semantics, as 3.4 para 3 implies.
>
> This concept comes up again in 4.2.2, where "optional tagging" is outlawed in deterministic encoding (but then the text goes on to explain that protocols might choose to retain tags, but doesn't say why).

To be honest, I don't really understand how much optional are tags.

A CDD rule with tags matchs cbor items with tags and reject cbor items
without tags. Tags are not optional from the data-model point of view.


Moreover, please consider this CDDL objective:
(https://tools.ietf.org/html/rfc7049#section-1.1)

   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.


Well, how to do this without putting tags everywhere for everything?
(Or I need more explanation about what is "self-describing" and what is
a "schema description")

Let say I receive data. How may I know that this number is a temperature
and not a distance, and that this byte-string is an uuid and not a small
picture?

The first way is to have a schema (written or not): That is to say a
certain preliminary knowledge of expected data which tell me that this
number at this place or associated to this map-key is a temperature.
The second way is to decorate data with tags, all data.
A third way is a compromise between the two first ones: I have a certain
level of preliminary knoledge of what data are (a kind of schema
description), with possibly some missing parts that are filled by tags.

But the only way to decode data _without_ a schema description is to
have tags everywhere for everything.
Surprisingly, json has no tags and is claimed to be self-describing. Is
it really? I'm lost.

My feeling is that this objective CBOR should be not so demanding.

Best regards,
Christophe