Re: [dispatch] draft-devault-bare-07 to be discussed during IETF 114

Tim Bray <tbray@textuality.com> Thu, 09 June 2022 21:19 UTC

Return-Path: <tbray@textuality.com>
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 7BC52C159485 for <dispatch@ietfa.amsl.com>; Thu, 9 Jun 2022 14:19:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20210112.gappssmtp.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 YvMhCHr2EPHz for <dispatch@ietfa.amsl.com>; Thu, 9 Jun 2022 14:19:38 -0700 (PDT)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 4566AC14792F for <dispatch@ietf.org>; Thu, 9 Jun 2022 14:19:38 -0700 (PDT)
Received: by mail-ed1-x52e.google.com with SMTP id w27so32760218edl.7 for <dispatch@ietf.org>; Thu, 09 Jun 2022 14:19:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O/5kLkeabEoPcaUgykLfLCqsrN6zT3ZFrsz0zyLEhXs=; b=Y7+0YZlxQy1Qxa23bw/BSanDFWzuzx86/1WFxsJ+YnXQoVgShxUxLVwyoyyYmoDfJR NJxLzKhTP0cjhhL1e9v48zfUSOtKborhs+/a4PvNajAGgU9EZIZhD9dkFWvLhk/0KCfh 3rrU3eeoKRjGFHr3LGtntcuBN8MnZa164jZm0bTXOelrVy4zVdDOSsXpja99KYsfXwNF SbqwyIiTYY0jWQDpJvfxnPYk2whRz31XuHl5Sa2CUqY90fgCXfmDWAo3NTwVgFP9V9MS TW0I9PQNuGQx7QWaRVWZ7lwRKJO4M1zo6OxMK+yZr2aaCVswIG/sKSuBCKTG6JHtczG6 YFVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O/5kLkeabEoPcaUgykLfLCqsrN6zT3ZFrsz0zyLEhXs=; b=q1bc19ivjaKd1vcZ19ULOIDDzvz18iZEfxg/OC9parh8MX+qG646wsY9BqQVV0gmtT 2foo1t7T9fGv5SD5B1Gx0VoFmq0hMA6zPP3gaNDz+JUlvzQYvpQYIBM62cHsDtOisuwc BLmgqomIxzTSP/P/t5uc75k1AetqyD+jNH6cpXyjR1i6JPf9n1JtdgTJ5uVjKn4+SU2J 1GmEGANPC94asnTlv2n2uPY2E4dSmRUMLm3MZ5Kk3a6KjSADMY/kUWbcU9o+KYX6myGe 49kMli3KEVbrDvjG4NtZUZKKvsYPFW9KG8CB0rcDRigqA+jr+hlvoV2a8cQrDgggu2Ii Fkhw==
X-Gm-Message-State: AOAM532Du26fM0mM8Nklj6r7HPd73cF6UAMjKjWiSmlLrIpgWXtF1Yvl Mh5ofLCAsXuKNeypJ9/cyhk/i94h+cpEmjcX6CJaUw==
X-Google-Smtp-Source: ABdhPJzEeKMp5izOGQLQyPHbdtLsLduudBW0kGTUhtDSqRbFfRo32FooQZnATwq8Hoqzm9dS+Khuo/QhDGOwrpedgws=
X-Received: by 2002:a05:6402:50d0:b0:431:70e1:956 with SMTP id h16-20020a05640250d000b0043170e10956mr22597526edb.205.1654809576490; Thu, 09 Jun 2022 14:19:36 -0700 (PDT)
MIME-Version: 1.0
References: <YqC0MHD7MPpcFEuc@cvut.cz> <20220608210551.72EB94341C93@ary.qy> <YqH16YukCzEbLBF3@cvut.cz> <CABcZeBNBSt0z7ur7_JwhBs30s05wT9n4jsDZA1wre991fkvS8w@mail.gmail.com> <YqJUjF8W3Dw/XgKB@gmail.com> <CABcZeBPRkW1iHVDVG4fLTdGzigfFtNLQDu_UkRHE1-V7jXgKrA@mail.gmail.com>
In-Reply-To: <CABcZeBPRkW1iHVDVG4fLTdGzigfFtNLQDu_UkRHE1-V7jXgKrA@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
Date: Thu, 09 Jun 2022 14:19:25 -0700
Message-ID: <CAHBU6isB2-u5TUUMz76ZHF=FcRW9rokEPGtNZzeM2a6NjFxHNA@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Jiri Vlasak <jiri.hubacek@gmail.com>, John Levine <johnl@taugh.com>, DISPATCH <dispatch@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fa5ec305e10a6012"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/_wCQxV0RT92Dv2gF5xs1rOdhX1I>
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 <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jun 2022 21:19:42 -0000

The world is well-supplied with schema-driven binary encoding schemes, all
claiming excellent compatibility and performance characteristics: Avro,
Protobufs, Cap'n proto, Thrift, FlatBuffers are the ones I can think of off
the top of my head.

I'd be interested in hearing why BARE is different/better/interesting.

On Thu, Jun 9, 2022 at 2:14 PM Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> On Thu, Jun 9, 2022 at 1:14 PM Jiri Vlasak <jiri.hubacek@gmail.com> wrote:
>
>> > > > An obvious question is why one would use BARE rather than CBOR
>> > > > which appears at first glance to do the largely the same thing.
>> > > > See RFCs 8949, 8152, 8392, 8610, 8742, 8746, and 8812.
>> > >
>> > > An obvious answer is that because BARE spec [1] is short. It has
>> > > about 17 pages (depends on the format), that include schema language
>> > > and many examples.
>> > >
>> >
>> > Without taking a position on BARE, this is not necessarily a virtue.
>> > There are (at least) two reasons why a draft might be shorter than
>> > alternative technologies (1) that it is simpler (2) that is
>> > underspecified.
>>
>> (1) is one of the BARE's goals. We worked hard to avoid (2) and I am
>> happy to discuss it.
>>
>
> Since sending this email I have taken a quick look at the specification,
> and IMO the description of the schema language needs to be fleshed
> out some. Providing the ABNF is insufficient, you need to explain
> what each piece of the syntax means. You might be able to
> save some space by interlacing that with the description of each
> type.
>
>
>
>> > > Moreover, BARE needs the schema available prior to the
>> > > communication, which is not needed in CBOR [2] as stated in the
>> > > objectives. In this manner, BARE better compares to XDR [3].
>> > >
>> >
>> > As I understand it, CBOR does however support schema, no? If so, I'm
>> > not sure why requiring it is an advantage. Is the idea that it makes
>> > the format more compact? Something else?
>>
>> To my understanding, yes, CBOR supports schema. However, to cite from
>> the CBOR specification [1], "3. Data must be able to be decoded without
>> a schema description." That is not the case for BARE. So, to cite from
>> the BARE specification [2], "A BARE message has a comparable size and
>> entropy to the underlying state it represents."
>>
>> I am not saying that requiring the schema is an advantage, which lead us
>> to the original question -- you probably use BARE when you need simple
>> schema and concise messages; you probably use CBOR when you need
>> self-descriptive messages.
>>
>
> It would probably help to provide some measurements that compared
> the overhead of CBOR to the overhead of BARE. As a bonus, it
> would help to compare the overhead of compressed CBOR to the
> overhead of compressed BARE.
>
>
>
>
>> > Finally, I note that your name does not appear in the author list of
>> > this document.  Can you clarify the situation here?
>>
>> Of course, and I am sorry I did not do it earlier. After the -01 version
>> of the BARE draft the development stagnated. The original author was out
>> of free time, letting the BARE I-D to expire. After some time, the
>> requests to revive the specification appeared from the interested
>> developers. I worked with one of the developers/implementers to review
>> the BARE and incorporated all the received feedback.
>>
>> My primary motivation is to understand the RFC process on the
>> specification, which I believe is worth the standardization.
>>
>> I was hesitating to add myself and the imlementor mentioned earlier as
>> the authors, because our roles are more like pre-editor and contributor
>> ones. So I decided not to, but it is maybe wrong? Could I, please, ask,
>> what is the common practice in the similar situations?
>>
>
> I'm not sure about wrong, but it's just surprising to see someone proposing
> a specification without their name on it. It would probably be better to
> add
> your name so that people know who to contact, etc., but I don't think
> you need to submit a -08 just for that.
>
> -Ekr
>
>
>>
>> Thanks, have a nice day,
>> jiri
>>
>> [1]: https://www.rfc-editor.org/rfc/rfc8949.html
>> [2]: https://www.ietf.org/archive/id/draft-devault-bare-07.html
>>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>