IETF Logo Mail Archive

Re: [Cbor] 65-bit negatives, big nums conflict between CDE and dCBOR drafts?

Anders Rundgren <anders.rundgren.net@gmail.com> Sun, 07 April 2024 04:24 UTC

Return-Path: <anders.rundgren.net@gmail.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 5E86AC14F68B for <cbor@ietfa.amsl.com>; Sat, 6 Apr 2024 21:24:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 9zFG_IMDjC70 for <cbor@ietfa.amsl.com>; Sat, 6 Apr 2024 21:24:50 -0700 (PDT)
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 3F249C14F694 for <cbor@ietf.org>; Sat, 6 Apr 2024 21:24:50 -0700 (PDT)
Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-4155819f710so25992645e9.2 for <cbor@ietf.org>; Sat, 06 Apr 2024 21:24:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712463888; x=1713068688; darn=ietf.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=kw1FHOICASjx5YeMY86GHjqAU6X0hdY+ZymFS6Cm5iw=; b=Lujt/PxLpR5GDei1DqxbO0YAIoA3hN0g22Ra01i3WVzscUvlyFa0R+uvrYK3ck9q1k j4WfhGEuaXeh3nlSu3nFUQpVtJUQ1ak1ftINwpj26LF+nujvkE4iLYeHffK9uA8qmuh9 zb0isLJLTcR8AwMHAcyucboX+4zysuzWui9m30l7tlOWAhUtBU9859xdYVIgjUH6XF2+ cnlpngHcWI/gYMo2erZzfdM3gLHBKP8rvI8LaKkO0P2XCD0cLYS3+Bo5BfUPDP+fHQXQ 8xjDFIqWpXeGmf5HAx8Synml8Law10i2Gf58ZmwtT82Fo8qXMmbqPtX2tjquutbXp9qD BS0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712463888; x=1713068688; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=kw1FHOICASjx5YeMY86GHjqAU6X0hdY+ZymFS6Cm5iw=; b=ohFG6OLqe6/RaykoeIKmw3ueRmstK1jFUMQRkJITwjmON112rCRiVThFVInXeVR6We xiCew1r/pmPie3/y39MTK2//rfr37wERcdlnvxphPMnq+VGs0mSMicImYI6hEI6BiNop WHmT0omJozQSC4pURjrGNK0ki2dfW61lANzDsgP+5vIAHHf6o6iJBXYyuT04IYQKdTUB 2rJGYh+kuneGwWv0JQxOIGRfLNe0+D4breRBvHpDz8tE40yhkqBSBJJw7eVDw+e4c3ea QmfOXhUn7FvvZ36EKIQ3CnChcB4w3aaP+erpIgH6FLBhQEdx4t1F2k3fda7me3OtT8nO wkqA==
X-Gm-Message-State: AOJu0Yy7c+FzaKC7LLMd96DytvNjdiGHTDeE0fhHpQCUEVEVGpHonA3Q 8iDU2TriKBmdn+gSTcMj/ehpMJYhi2XbzjNccPAeHOgkTYE6iLySwZd2O6kk
X-Google-Smtp-Source: AGHT+IENgeJxMp4w1XpN227I8T2fVak6zWQjONyjwHRxcIADF/Ha1Vd0W2rxAb1l1tAmdgVmdL02qQ==
X-Received: by 2002:a05:600c:1f82:b0:414:bfd:379d with SMTP id je2-20020a05600c1f8200b004140bfd379dmr4528857wmb.22.1712463888346; Sat, 06 Apr 2024 21:24:48 -0700 (PDT)
Received: from ?IPV6:2a01:e0a:e1b:64b0:a1be:ffe5:5740:6b1d? ([2a01:e0a:e1b:64b0:a1be:ffe5:5740:6b1d]) by smtp.googlemail.com with ESMTPSA id o32-20020a05600c512000b004163321790esm5897785wms.19.2024.04.06.21.24.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 06 Apr 2024 21:24:47 -0700 (PDT)
Message-ID: <0fe493cd-5bfd-463b-8ffe-70620ff25056@gmail.com>
Date: Sun, 07 Apr 2024 06:24:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: "lgl island-resort.com" <lgl@island-resort.com>
Cc: "cbor@ietf.org" <cbor@ietf.org>
References: <775D5398-1A78-4255-B337-B9B25ED03ED3@island-resort.com> <1aea13ce-9646-41cb-8f1a-5a249d08e693@gmail.com> <32A30872-2701-49E6-AAFE-4E8CC7EA4C31@island-resort.com>
Content-Language: en-US
From: Anders Rundgren <anders.rundgren.net@gmail.com>
In-Reply-To: <32A30872-2701-49E6-AAFE-4E8CC7EA4C31@island-resort.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/QAzTUH7iOCwwAtL9phYX6_sB9NM>
Subject: Re: [Cbor] 65-bit negatives, big nums conflict between CDE and dCBOR drafts?
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.39
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, 07 Apr 2024 04:24:54 -0000

On 2024-04-06 19:47, lgl island-resort.com wrote:
> 
>> On Apr 6, 2024, at 6:56 AM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
>>
>> Although I personally don't find the CBOR int/bignum arrangement ideal, this boat has (since long) already sailed and nobody died.
> 
> It looks to me that there is a new requirement in draft-ietf-cbor-cde-02 that isn’t in RFC 7049 (canonical CBOR) or RFC 8949 (Preferred Serialization and CDE). The requirement is that no value that can fit into an int64 or uint64 can be sent as a tag 3. That implies 65-bit negatives ints must be sent.

This has been my assumption [*] all the time, long before CDE was born.  IMO, this is not more of a problem than any value < -2**63 which does not match traditional (two-complement) 64 bit-integer implementations.  Applications that do NOT support bignum would preferably flag such values as invalid, like the Blockchain Commons implementations already do.

Anders

*] https://cbor.me once took me there. RFC 8949 is a bit overwhelming for a typical engineer like me 😆



> 
> It’s the new requirement that I’m bringing up, not the coexistence of int and bignum.
> 
> LL
> 
>

v2.23.0 | Report a Bug | By Email