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

Jiri Vlasak <> Mon, 13 June 2022 23:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A10B8C15AAF4 for <>; Mon, 13 Jun 2022 16:07:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Status: No, score=-2.105 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_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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xucamD0DqQ24 for <>; Mon, 13 Jun 2022 16:07:49 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::536]) (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 1D1FCC15AAFD for <>; Mon, 13 Jun 2022 16:07:14 -0700 (PDT)
Received: by with SMTP id n28so9212333edb.9 for <>; Mon, 13 Jun 2022 16:07:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=IhkQZwIQ64RiYcgMtiv480fCgIy7avns5RYMdyAR2pE=; b=nXx7fzpJMJqDy7NcQbxEp7wghzS9BZbQJqEwtCtuuPhvV25YffxCmlV7IkRgbLGSXQ yDXe6qrf99NplpOotQ7+kjR4+ExEOBMNQvKRfq9UMT1Zf9AckT6gz5kmI0HWvV35+gNU bLlpZiGvNv8Vb6231mQfewcGQQfBkjex1bCGyD6EvoFGWeTHIbP99wY6ZrNnkczt/XkC BevYrwIBPxD+RVSoVaFpEJD9rR3RujvZEfWLoCc4M4R6u+tDc9+jY/k5E9uGLAwyMt8W K5OI34wvofwmVo3WcFUUAC67P3gnYotDDoMRyCjXt31cGlXoW8eDsKlZDPWk8l/acJBd 4D+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=IhkQZwIQ64RiYcgMtiv480fCgIy7avns5RYMdyAR2pE=; b=NXolUSELStKcZseGRc+H4M24hgwR1zQJnQ1XEESYIPcOKUcXAI3GFxGwWhzysNaj30 fEIXH86y5Ki+eUi+RsDalwQDUTYSdOagLs3rnQG5CkCyVXfYVkGvj5wiHACoP4xg95rH bVfR7WnOhLQzmY1IG2P72+HiuNLEa/NQndPWFGfnwyWOHKgvnQg358QPhEqjCqY8d5In vfpwU65KBxwwC9TYEYEyXfUikxuNRdQzdROTDNsh9IqIjkE/GFVTZNGwAUlRrhnnMUMe Ejb26f8l7wzShGk/XQ6bRVLGE3baVQW+dMOsXK2/S1qH215kAjWjb1hD/Pj0vgXBMLF2 HXjA==
X-Gm-Message-State: AOAM533HyF2L2co+E8NS/BDVzCkQVdJ2lQB0DHIsYcARAOFbC/etzfNP QqLXP89+T3aUWj68M1iBpKg=
X-Google-Smtp-Source: AGRyM1uM34cnS7doDKfYBX54RxrAYSTmMvyzqUONbMqrDgVaCGuTSry9/gGuh2Y9Z8VC5WPITvBakw==
X-Received: by 2002:a05:6402:5c9:b0:420:aac6:257b with SMTP id n9-20020a05640205c900b00420aac6257bmr2499495edx.128.1655161631895; Mon, 13 Jun 2022 16:07:11 -0700 (PDT)
Received: from ( []) by with ESMTPSA id ku3-20020a170907788300b006fe8b456672sm4352618ejc.3.2022. (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Jun 2022 16:07:11 -0700 (PDT)
Date: Tue, 14 Jun 2022 01:07:09 +0200
From: Jiri Vlasak <>
To: Tim Bray <>
Cc: Eric Rescorla <>, John Levine <>, DISPATCH <>
Message-ID: <>
References: <> <20220608210551.72EB94341C93@ary.qy> <> <> <YqJUjF8W3Dw/> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
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: Mon, 13 Jun 2022 23:07:53 -0000

I am sorry for letting you wait.

> 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 found the comparison on wiki [1]. What is unfortunate, in my opinion,
is that neither of the above protocols/frameworks/libraries is, to my
knowledge, standardized. (Now we can discuss about "de facto standard"
and if the standardization matters.)

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

BARE has concise messages; it does not embed the schema. The messages
are octet-aligned and use little-endian representation. The encoding is
bijective when possible [2]. BARE is designed with the simplicity of
implementation in mind.

BARE specifies many primitive types:

- variable-length unsigned/signed integers: uint, int
- unsigned integers of different lengths: u8, u16, u32, u64
- signed integers of different lengths: i8, i16, i32, i64
- floating-point numbers: f32, f64
- bool, (utf-8) string, variable- and fixed-length (arbitrary) data,
  void, enum

which is not the case for the other specifications, e.g. only Cap'n
proto and FlatBuffers (from the above) specify all the fixed-length
integers (u8, u16, u32, u64, i8, i16, i32, i64), but they both miss the
variable-length integers.

Only FlatBuffers seems to specify fixed-length list/data, but maybe I am
just missing something.

BARE specifies aggregate types that store zero or more value(s) of
primitive or aggregate types:

- optional -- a value of "type" that may or may not be present
- variable- and fixed-length list of "type" values
- a mapping of "type B" values keyed by "type A" values
- a tagged union containing single value of any "type" from a set of
  "types" agreed upon in advance
- a struct -- a set of values of arbitrary "types" concatenated in an
  order agreed upon in advance

The distinction between primitive and aggregate types is clear --
primitive type encodes just one value; aggregate type encodes zero or
more values. Complex types are to be created by users by composing
primitive and aggregate types.

Even comprehensive, BARE is kept simple and well-defined.