From nobody Mon May 8 21:51:16 2023 Return-Path: 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 543D0C151533 for ; Mon, 8 May 2023 21:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiN4_6DTHoPf for ; Mon, 8 May 2023 21:51:11 -0700 (PDT) Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [134.102.50.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BF16C14CE31 for ; Mon, 8 May 2023 21:51:09 -0700 (PDT) Received: from smtpclient.apple (p548dc0f6.dip0.t-ipconnect.de [84.141.192.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4QFm2M15VGzDCc9; Tue, 9 May 2023 06:51:07 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\)) From: Carsten Bormann In-Reply-To: <463016EF-0DAB-45D4-AB30-53FB2B76F52B@wolfmcnally.com> Date: Tue, 9 May 2023 06:50:56 +0200 Cc: Christopher Allen , cbor@ietf.org, Shannon.Appelcline@gmail.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EBE3640-5F7F-46B8-961A-D1872A6A0CA4@tzi.org> <463016EF-0DAB-45D4-AB30-53FB2B76F52B@wolfmcnally.com> To: Wolf McNally X-Mailer: Apple Mail (2.3731.500.231) Archived-At: Subject: Re: [Cbor] Updated Drafts for dCBOR I-D and Gordian Envelope Structured Data Format I-D & IANA Tag Registration X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2023 04:51:14 -0000 On 9. May 2023, at 00:42, Wolf McNally wrote: >=20 >> Because of this incompatibility between the CBOR and standard = representations, dCBOR disallows encoding negative integer values in the = range [CBOR_NEGATIVE_INT_MAX ... STANDARD_NEGATIVE_INT_MAX - 1]: = conformant encoders MUST never encode these values and conformant = decoders MUST reject these values as invalid. >>=20 >> Implementations that support BIGNUM are able to encode and decode = these values as BIGNUM. >=20 How is=20 "c3 48 89 ab cd ef 01 23 45 67" a better encoding of -9920249030613615976 than "3b 89 ab cd ef 01 23 45 67=E2=80=9D ? I think what you are trying to say is the obvious fact that int64 does = not include -2**64 to -2**63-1. The is nothing wrong with encoding values in this range with major type = 3, these are just outside the range of int64. Same with int64, 2**63 to 2**64-1 and major type 1, by the way (these do = fit in a uint64, though). Similar considerations apply to int32, if your applications need that = type; there will be some CBOR major type 0 and major type 1 values that = your application cannot process where int32 is required. There is no incompatibility between CBOR and =E2=80=9Cstandard = representations=E2=80=9D, it just so happens that the boundaries between = int8, int16, int32, int64 are not one-to-one with the boundaries between = the various lengths of integers that CBOR can express. So if int64 happens to be your largest native signed integer, you need = big integer support (or a third choice in addition to uint64 and int64) = for handing around -2**64 to -2**63-1. This does not mean you cannot (or should not) encode these non-int64 = integers as =E2=80=9C3b 80=E2=80=A6=E2=80=9D to =E2=80=9C3b ff=E2=80=A6=E2= =80=9D. Gr=C3=BC=C3=9Fe, Carsten