IETF Logo Mail Archive

Re: [Cbor] Status of Appendix A in RFC 8949

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 05 May 2023 21:42 UTC

Return-Path: <brian.e.carpenter@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 41A9FC17CEA7 for <cbor@ietfa.amsl.com>; Fri, 5 May 2023 14:42:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 1MkNobkPjrCl for <cbor@ietfa.amsl.com>; Fri, 5 May 2023 14:42:55 -0700 (PDT)
Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (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 0BCF5C14CF1A for <cbor@ietf.org>; Fri, 5 May 2023 14:42:55 -0700 (PDT)
Received: by mail-pf1-x431.google.com with SMTP id d2e1a72fcca58-6439b410679so1206800b3a.0 for <cbor@ietf.org>; Fri, 05 May 2023 14:42:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683322974; x=1685914974; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=7BIguR07Pzf4HxodWxj06q2Hv4GXn7U6Ov041GHUuto=; b=SfGpHSvBic8cLqZgAz6EU9Xim2NXlzwHTbP21KzOZPxpN8oYqPr5Ti20ccv6YxwipC 7E91EXEI3Ju8Zj1NzER46qzkcwljPx3+7FXQkAuxYzg3ZEaswqioFIVpEYgbYS8KZ1PN 223VAeq3wmWffv2te4kS5WaBKbiTbf12HePrHn1wT7q0PJMW/FyIIooTjsnEzHlLadAY xDaXKaHbcctp/EQK5IJ8EN49+wz4A/OKxRg83feXMJk1oB3Y7bsUgyAwTAxRzOQuR0zn d6YxkU0MEWpTZRXBSLr69WRi1eh9HWLO6jn9PXxlkYZAIgduZgStNKBfTCbYo+0vOZ9A 8O9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683322974; x=1685914974; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7BIguR07Pzf4HxodWxj06q2Hv4GXn7U6Ov041GHUuto=; b=cTRtQ+zsGgfzPbYx8w9tBiRoTJc3icipGNetB5cUlqIsLmqgd5ue04wP2Dqbt1tP1D 3t5Ct8Tf69CzaRMvscXgapNMwW2lGGWKRc0NVIoB71iK+tafwEvqRPg9uvOYXtFwq6ZL CNGtEut8oFbU+Qqgd6Zgps+D54IPNjdx6KclK1lO+fr7ZjtxBllqIjsvFlFvZVoN6cRy QgDPQS3nGMZAhCn8iWU1SmRVyPlZYrAMdgOSoc6h0fXoe2cRTxbpA/90fVuFQke226Gb fsw9ponz0I9Kkmx2QDgH5z6TCMfOv8VaSuaKFpo0Shubj3UKmURRlq/7q7UauZolu2OW A2pw==
X-Gm-Message-State: AC+VfDwgeV0bgngAJd8nZRDj0eTw9LZntNe6HYLvvfHY7zHywo39sP5w mGRdR3p5P+wTrhPpi+Wye64=
X-Google-Smtp-Source: ACHHUZ41JUT6leE5Bx1l/L79izh28Ztd3WMS7ZZgpk9++wE2mbHsRdpeaUCz4A8yoQQ+fa+wKhOo4w==
X-Received: by 2002:a05:6a21:2d8c:b0:ec:713f:3cb2 with SMTP id ty12-20020a056a212d8c00b000ec713f3cb2mr3265823pzb.53.1683322974498; Fri, 05 May 2023 14:42:54 -0700 (PDT)
Received: from ?IPV6:2406:e003:1184:f001:9991:d1ad:8c20:42bd? ([2406:e003:1184:f001:9991:d1ad:8c20:42bd]) by smtp.gmail.com with ESMTPSA id x1-20020a62fb01000000b0063d238c2e95sm2081310pfm.91.2023.05.05.14.42.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 May 2023 14:42:53 -0700 (PDT)
Message-ID: <3e2575c7-0935-fa5e-43ec-e2683c2278d8@gmail.com>
Date: Sat, 06 May 2023 09:42:44 +1200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
To: Carsten Bormann <cabo@tzi.org>, Anders Rundgren <anders.rundgren.net@gmail.com>
Cc: "cbor@ietf.org" <cbor@ietf.org>
References: <8233a692-df84-f093-96bf-fe99c03adfc5@gmail.com> <31111796-3CF7-4F8F-A805-4CBE1124E9D8@tzi.org> <e16961f5-edbc-233e-3e24-e3a20bc57ea4@gmail.com> <83052D85-36BE-45AA-81EA-A46068B89D95@tzi.org>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <83052D85-36BE-45AA-81EA-A46068B89D95@tzi.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/7oQjLbFZ6rJh7YJmWDmrTrUODuY>
Subject: Re: [Cbor] Status of Appendix A in RFC 8949
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: Fri, 05 May 2023 21:42:57 -0000

On 05-May-23 19:43, Carsten Bormann wrote:
> On 2023-05-05, at 09:27, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:

<snip>

> 
> I have been quite receptive for picking up the application rules in draft-mcnally-deterministic-cbor as a CBOR work item.
> You just need to stop thinking of them as changing CBOR.
> 
>> The target for an interoperability profile are the 80-90% of all developers working with enterprise systems as well as open standards for banking and similar.
> 
> The point here is “an interoperability profile”.
> You could define many, and defining one for fintech etc. is fine — it just isn’t a “CBOR interoperability profile”, but a “how is our specific set of applications going to use CBOR” profile.

That's my understanding of how CBOR is used. After all, CBOR isn't a protocol. It's a way of encoding structured data into bits on the wire. A given protocol needs to define what data structures it transmits, but that is IMHO *not* a CBOR profile; those data structures could equally well be encoded for transmission as COBOL statements or punched card images.

I don't understand why I'd need an interop profile for CBOR itself. What notation you use for the interop data model seems orthogonal to the choice of CBOR on the wire.

     Brian

v2.29.0 | Report a Bug | By Email | System Status