< draft-devault-bare-06.txt		draft-devault-bare-07.txt >
	Internet Engineering Task Force D. DeVault		Internet Engineering Task Force D. DeVault
	Internet-Draft SourceHut		Internet-Draft SourceHut
	Intended status: Informational 2 May 2022		Intended status: Informational 11 May 2022
	Expires: 3 November 2022		Expires: 12 November 2022
	Binary Application Record Encoding (BARE)		Binary Application Record Encoding (BARE)
	draft-devault-bare-06		draft-devault-bare-07
	Abstract		Abstract
	The Binary Application Record Encoding (BARE) is a data format used		The Binary Application Record Encoding (BARE) is a data format used
	to represent application records for storage or transmission between		to represent application records for storage or transmission between
	programs. BARE messages are concise and have a well-defined schema,		programs. BARE messages are concise and have a well-defined schema,
	and implementations may be simple and broadly compatible. A schema		and implementations may be simple and broadly compatible. A schema
	language is also provided to express message schemas out-of-band.		language is also provided to express message schemas out-of-band.
	Comments		Comments
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 3 November 2022.		This Internet-Draft will expire on 12 November 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 5, line 4 ¶		skipping to change at page 4, line 49 ¶
	The maximum precision of such a number is 64-bits. The		The maximum precision of such a number is 64-bits. The
	maximum length of an encoded uint is therefore 10 octets.		maximum length of an encoded uint is therefore 10 octets.
	Numbers that require all ten octets will have 6 bits in the		Numbers that require all ten octets will have 6 bits in the
	final octet that do not have meaning, between the least- and		final octet that do not have meaning, between the least- and
	most-significant bits. The implementation MUST set these to		most-significant bits. The implementation MUST set these to
	zero.		zero.
	int		int
	A signed integer with a variable-length encoding. Signed		A signed integer with variable-length encoding. Signed
	integers are represented as uint using a "zig-zag" encoding:		integers are represented as uint using a "zig-zag" encoding:
	positive values x are written as 2x + 0, negative values are		positive values x are written as 2x + 0, negative values as
	written as 2(^x) + 1. In other words, negative numbers are		-2x - 1. Another way of looking at it is that negative
	complemented and whether to complement is encoded in bit 0.		numbers are complemented, and whether to complement is
			encoded in bit 0.
	The encoder MUST encode int using the minimum necessary		The encoder MUST encode int using the minimum necessary
	number of octets, and the decoder SHOULD raise an error if it		number of octets, and the decoder SHOULD raise an error if it
	encounters the opposite.		encounters the opposite.
	The maximum precision of such a number is 64-bits. The		The maximum precision of such a number is 64-bits. The
	maximum length of an encoded int is therefore 10 octets.		maximum length of an encoded int is therefore 10 octets.
	Numbers that require all ten octets will have 6 bits in the		Numbers that require all ten octets will have 6 bits in the
	final octet that do not have meaning, between the least- and		final octet that do not have meaning, between the least- and
	skipping to change at page 10, line 22 ¶		skipping to change at page 10, line 22 ¶
	any-type =/ "int" / "i8" / "i16" / "i32" / "i64"		any-type =/ "int" / "i8" / "i16" / "i32" / "i64"
	any-type =/ "f32" / "f64"		any-type =/ "f32" / "f64"
	any-type =/ "bool"		any-type =/ "bool"
	any-type =/ "str"		any-type =/ "str"
	any-type =/ "data" [length]		any-type =/ "data" [length]
	any-type =/ "void"		any-type =/ "void"
	any-type =/ "enum" [WS] "{" [WS] enum-values [WS] "}"		any-type =/ "enum" [WS] "{" [WS] enum-values [WS] "}"
	any-type =/ "optional" type		any-type =/ "optional" type
	any-type =/ "list" type [length]		any-type =/ "list" type [length]
	any-type =/ "map" type type		any-type =/ "map" type type
	any-type =/ "union" [WS] "{" [WS] union-members [WS] ["|" [WS]] "}"		any-type =/ "union" [WS] "{" [[WS] "|"] [WS] union-members [WS] ["|" [WS]] "}"
	any-type =/ "struct" [WS] "{" [WS] struct-fields [WS] "}"		any-type =/ "struct" [WS] "{" [WS] struct-fields [WS] "}"
	length = [WS] "[" [WS] integer [WS] "]"		length = [WS] "[" [WS] integer [WS] "]"
	integer = 1*DIGIT		integer = 1*DIGIT
	enum-values = enum-value [WS enum-values]		enum-values = enum-value [WS enum-values]
	enum-value = enum-value-name [[WS] "=" [WS] integer]		enum-value = enum-value-name [[WS] "=" [WS] integer]
	enum-value-name = UPPER *(UPPER / DIGIT / "_")		enum-value-name = UPPER *(UPPER / DIGIT / "_")
	type = [WS] "<" [WS] any-type [WS] ">"		type = [WS] "<" [WS] any-type [WS] ">"
	union-members = ["|" [WS]] union-member [[WS] "|" [WS] union-members]		union-members = union-member [[WS] "|" [WS] union-members]
	union-member = any-type [[WS] "=" [WS] integer]		union-member = any-type [[WS] "=" [WS] integer]
	struct-fields = struct-field [WS struct-fields]		struct-fields = struct-field [WS struct-fields]
	struct-field = 1*ALPHA [WS] ":" [WS] any-type		struct-field = 1*ALPHA [WS] ":" [WS] any-type
	UPPER = %x41-5A ; uppercase ASCII letters, i.e. A-Z		UPPER = %x41-5A ; uppercase ASCII letters, i.e. A-Z
	ALPHA = %x41-5A / %x61-7A ; A-Z / a-z		ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
	DIGIT = %x30-39 ; 0-9		DIGIT = %x30-39 ; 0-9
	WS = 1*(%x0A / %x09 / " ") ; whitespace		WS = 1*(%x0A / %x09 / " ") ; whitespace
	skipping to change at page 20, line 24 ¶		skipping to change at page 20, line 24 ¶
	why: str		why: str
	}		}
	type Graph struct {		type Graph struct {
	nodes: map<NodeId><Node>		nodes: map<NodeId><Node>
	edges: list<Connection>		edges: list<Connection>
	}		}
	Appendix D. Design Decisions		Appendix D. Design Decisions
	This section documents the reasoning behind the decision made during		This section documents the reasoning behind the decisions made during
	BARE specification process.		BARE specification process.
	*f32 and f64 are fully compliant with IEEE 754 [IEEE.754.1985]*		*f32 and f64 are fully compliant with IEEE 754 [IEEE.754.1985]*
	The use-case is a sensor sending NaN values or encoding of		The use-case is a sensor sending NaN values or encoding of
	infinity in scientific applications.		infinity in scientific applications.
	The consequences are that encoded values of f32 and f64 types are		The consequences are that encoded values of f32 and f64 types are
	not canonical, and therefore forbidden as map keys.		not canonical, and therefore forbidden as map keys.
	*Types of a union needs to be unique*		*Types of a union needs to be unique*
End of changes. 8 change blocks.
	11 lines changed or deleted		12 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/