Re: [Cbor] Chair review of cbor-file-magic 08

Christian Amsüss <christian@amsuess.com> Mon, 07 March 2022 11:39 UTC

Return-Path: <christian@amsuess.com>
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 603BB3A0A16; Mon, 7 Mar 2022 03:39:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 ioDcurD9zJGA; Mon, 7 Mar 2022 03:38:57 -0800 (PST)
Received: from smtp.akis.at (smtp.akis.at [IPv6:2a02:b18:500:a515::f455]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3ECF3A0A13; Mon, 7 Mar 2022 03:38:55 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by smtp.akis.at (8.17.1/8.17.1) with ESMTPS id 227BcosQ041798 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 7 Mar 2022 12:38:50 +0100 (CET) (envelope-from christian@amsuess.com)
X-Authentication-Warning: smtp.akis.at: Host 095129206250.cust.akis.net [95.129.206.250] claimed to be poseidon-mailhub.amsuess.com
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id EFC5CD0; Mon, 7 Mar 2022 12:38:49 +0100 (CET)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:bb44:afd1:dcfc:f47a]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id AC1707F; Mon, 7 Mar 2022 12:38:49 +0100 (CET)
Received: (nullmailer pid 1239472 invoked by uid 1000); Mon, 07 Mar 2022 11:38:49 -0000
Date: Mon, 7 Mar 2022 12:38:49 +0100
From: Christian =?iso-8859-1?Q?Ams=FCss?= <christian@amsuess.com>
To: Carsten Bormann <cabo@tzi.org>, Michael Richardson <mcr+ietf@sandelman.ca>
Cc: cbor@ietf.org, draft-ietf-cbor-file-magic@ietf.org
Message-ID: <YiXuySHqGatarVQa@hephaistos.amsuess.com>
References: <164442074235.12313.4216473952031101282@ietfa.amsl.com> <YgPhxUmjDUqLTEtK@hephaistos.amsuess.com> <YhTi7sT7O7xzjLQz@hephaistos.amsuess.com> <0425DF6E-EB50-4711-89A6-DFD14FE3FD8A@tzi.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="+1hG5F6GLKJ9cm/u"
Content-Disposition: inline
In-Reply-To: <0425DF6E-EB50-4711-89A6-DFD14FE3FD8A@tzi.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/8sZjtE-BTPqA2-rmicnq1KjRU2g>
Subject: Re: [Cbor] Chair review of cbor-file-magic 08
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: Mon, 07 Mar 2022 11:39:01 -0000

Hello Michael, Carsten,

thanks for the update, it does address the semantic concerns.

Two things were left but minor enough to be addressed in the next phase:

* In Section 5.3 (IANA / CBOR Tags for CoAP Content-Format Numbers), it
  still says "Date item: byte string"

  (when the rest of the document is now clear that it depends on the
  the context and (when in 55799) the individual content format).

* The introduction of Appendix A ("CBOR Tags for CoAP Content Formats")
  says:

  > Often, there is a need to identify a media type (or content type,
  > i.e., media type optionally used with parameters) that applies to
  > the contents of a byte string in a CBOR data item.

  Of all the things we describe how these 64k tags could be used,
  annotating a byte string is none of them -- and I think the sentence
  just needs an editorial nudge.

  (Incidentally, that is one variation which I might want to use in
  embedded representations in CoRAL, but now is most definitely not the
  time ask for things being added, especially when I'm not perfectly
  sure yet I'll need them).

I'll update the shepherd review after the cut-off.

Best regards,
Christian

-- 
This may seem a bit weird, but that's okay, because it is weird.
  -- perldata(1) about perl variables