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

Eric Rescorla <> Thu, 09 June 2022 21:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 38922C14792F for <>; Thu, 9 Jun 2022 14:14:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wN9KZYns-ImN for <>; Thu, 9 Jun 2022 14:14:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2c]) (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 (Postfix) with ESMTPS id 7D4FFC14CF18 for <>; Thu, 9 Jun 2022 14:14:02 -0700 (PDT)
Received: by with SMTP id y12so23456925ior.7 for <>; Thu, 09 Jun 2022 14:14:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i8ks9tnVwoo3O/9dqWCYmS+0B3hfk/C6QX3dHwupx/k=; b=0HAqvr0kzYe5sL5o6IYXFk/FAH7/zQwjVdDrECRCa1xfRA9bSunr9Xu3sKh1G1Ocjg SdqUOvQNnWeDggFwOlhLycu2NEUHnT5h2oZHII84izqDt2Bh/IrcavwBHszDmdE1KIxN DdS8+6OGwQoCg7a9sOHS6Izgt74cRb9cuwhUMr0aXAQVgMEZIcHii3HVvcoORp+/UDvT HH9nbAjDgNJAFjtv3MkorMcblblMH0p0QC/ISrQFFDX+pqeQFDXg2LXY9ruDwQjoAwU5 q4qXp+7RonwFVsDzod6Gln7S47lM03l4A4VsnuTCHCzvEZs+C0w+V3zoMvHPeiYGe/sU iWKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=i8ks9tnVwoo3O/9dqWCYmS+0B3hfk/C6QX3dHwupx/k=; b=j+UHOI9GS+9Ucif8zrroYoyMRURUbH6O1tVNJTlHCXr0h1Ow4dpl8YrFsJ3BQPpT6O chNwmEWrPIP9bO5YKQDaKl9j4lX95G+SyvXCXRVWQmbmO3xBY6SaYVwWKiUXTpkDzCfn KZhStHTNBhgAOzI5QBtzgxKidi/P3mMlxohy7fLn/JmhxpMtVUcehH6UcdU/DGWI6J99 Shi+PF9A8UI3rYuGjgv28NHYUE1UghDNFyhCPqtmOOcdKUScwKXmv1Hx+OHhSQ626hCo S9FKNlhlXUQ/hd5BLDTwkNLazh/8DL1c9+keo8l1U5wCK/oK53ejHoIbKWw3ktq3EsQV 6INw==
X-Gm-Message-State: AOAM532UkQxbe3QyH1TvjDQGt04TENuFaydK9i8x6pCY4BAeIlZdw+BR BeXJ9HgiUEsf0JGe15igd3c/CB/naREGGWt40rXobA==
X-Google-Smtp-Source: ABdhPJycPvB052EyPRhGuGTm6wC2j4c4+TciyU2yvcg1QnaizVHYuBZ983zYNFQHpU2PwyNi7ya8Tofh5xErorsoFRI=
X-Received: by 2002:a05:6638:22c1:b0:331:f39:dc21 with SMTP id j1-20020a05663822c100b003310f39dc21mr22153018jat.75.1654809241751; Thu, 09 Jun 2022 14:14:01 -0700 (PDT)
MIME-Version: 1.0
References: <> <20220608210551.72EB94341C93@ary.qy> <> <> <YqJUjF8W3Dw/>
In-Reply-To: <YqJUjF8W3Dw/>
From: Eric Rescorla <>
Date: Thu, 09 Jun 2022 14:13:25 -0700
Message-ID: <>
To: Jiri Vlasak <>
Cc: John Levine <>, DISPATCH <>
Content-Type: multipart/alternative; boundary="00000000000006ac7e05e10a4d59"
Archived-At: <>
Subject: Re: [dispatch] draft-devault-bare-07 to be discussed during IETF 114
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, 09 Jun 2022 21:14:06 -0000

On Thu, Jun 9, 2022 at 1:14 PM Jiri Vlasak <> 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

> > > 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.


> Thanks, have a nice day,
> jiri
> [1]:
> [2]: