From nobody Thu Jul 28 01:06:18 2022 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC06C13C23F for ; Thu, 28 Jul 2022 01:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.106 X-Spam-Level: X-Spam-Status: No, score=-7.106 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 HNWl217t4stt for ; Thu, 28 Jul 2022 01:06:13 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 611DCC16ECB3 for ; Thu, 28 Jul 2022 01:06:13 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id b26so1175451wrc.2 for ; Thu, 28 Jul 2022 01:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=cRIGsIx+CCn4fcT73bWcXTpdp4/SrtUMT9gwkCQWrgM=; b=qCvDjWcYJ56kDWY5AIMYKZSHYLQfcapwMWOz8bkENCUW5Sziz2icQj1empNgMGHoHu BDBhWCeZm567AA4tn/UQNPBVB9KmA880FUYm4FshHL3j8kACcUWhGbDAd4i4BlLzNbrz S8raiHrmaYEeLgC1pLYCnkO0SB0osQ2TIa8r4pwkBDVvALEywqg69EH/2B1k5eSmiAwo /E91Y0Y/eZXSEogCB7a8W3VPPioboeLmrG/YuLz5Vu8SXTgOi40t9h3wboXeW2cVlakP gv9i5JKjj7DM1yA2/qfGC/vy0PMpZsEAB6La/BteNd/kFM4Ws6xzZT2BwDgadiha52iJ tX4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=cRIGsIx+CCn4fcT73bWcXTpdp4/SrtUMT9gwkCQWrgM=; b=Qkq7IYh3v1bVRyNZmmgp3odG1RpJK6OnF/rbD+28rGR3vev3chV9OaLA/mE3BlHQ64 9IZQ+EVdjCUmao3HfSqYaneC4ZtN5u+3sPefgcB6ESNLupo5oUc9qecNVD/Wyvzul108 NqhsAHvV7kOaGrC0JBz/ERvUCpfv6/eBTmb+1d0x9r2dYDdrWwjUYUVcjKgP7Pbl6Hse 2vjW6Mrg055LTvodxWzp1OegXFMb6yrx/kzZi4PE7JGGVQ7fYZOu2hLgX/rwigW5V2OW hxGTZaK/ytjyxvFJw0DfMTC2a8xHHX7oGqikRn4eAcs21CodoBxrxdxWAm7s/SmOFkQB y+/g== X-Gm-Message-State: AJIora8LV9VXU/t90dHabW7PTFvorAZZKE3gTXdZx5lGFPL9SO6NM/xM L44UjvppV5oaJ5DCNfvNiCs8otJHcHw= X-Google-Smtp-Source: AGRyM1ucmKaTTv0CCiL4PucwBS3qQSGXqaS0Z7XpPYmfObWB9rHFKLXRC3vZasRVAl20npkkX71C5Q== X-Received: by 2002:a5d:5983:0:b0:21d:a811:3b41 with SMTP id n3-20020a5d5983000000b0021da8113b41mr15805756wri.441.1658995571257; Thu, 28 Jul 2022 01:06:11 -0700 (PDT) Received: from ?IPV6:2a01:e34:ec4e:5670:b0d5:55d1:2701:5d5a? ([2a01:e34:ec4e:5670:b0d5:55d1:2701:5d5a]) by smtp.googlemail.com with ESMTPSA id f18-20020a5d50d2000000b0021e9fafa601sm277684wrt.22.2022.07.28.01.06.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 Jul 2022 01:06:10 -0700 (PDT) Message-ID: Date: Thu, 28 Jul 2022 10:06:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Content-Language: en-US To: sir@cmpwn.com, dispatch@ietf.org References: From: Anders Rundgren In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] draft-devault-bare-07 to be discussed during IETF 114 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2022 08:06:17 -0000 On 2022-07-28 9:40, Jiri Vlasak wrote: > Please, note that I re-added the dispatch@ietf.org to CC. OK :) >> As an author of https://www.rfc-editor.org/rfc/rfc8785.html I would >> REQUIRE keys to be sorted. The cost isn't for real. > > With all the respect, it is not good idea in my opinion. These are the > reasons: > > - there is no wide support for ordered maps in programming environments I don't have full insight in this but in programming environments that actually support a map concept, ordered maps are likely to be found. > - there are situations when ordering is not important Right, what I'm saying is that the cost for ordering (on the sender side) is very small regardless of programming language. > - we would need to decide how to order Right. Given the fact that all BARE keys must be of the same type makes this a simple task. > - there is alternative, explicit solution (list of pairs) with no > difference in overhead That should work as well. > Please, note that BARE can not achieve full canonicity -- we need full > compliance to IEEE 754 (e.g. NaN values from sensors or infinity in > mathematical computations). You mean that using variant NaNs for "signaling" is a target for BARE? This concept is probably not overly useful since it is not supported by many platforms. >> For IEEE floating point data, I would consider adapting the CBOR >> encoding scheme so the re-serialization becomes fully compatible. > > I am sorry but I do not understand. Both, BARE and CBOR use IEEE 754 > binary formats. Yes, but to maintain a consistent format there should be exactly one representation of every number, including NaN. Anyway, if canonical representation is of no interest, you can safely ignore my comments :) Cheers, Anders