SRFI 56 Binary I/O bear (17 Jun 2004 00:44 UTC)
Re: SRFI 56 Binary I/O Alex Shinn (17 Jun 2004 02:40 UTC)
Re: SRFI 56 Binary I/O tb@xxxxxx (17 Jun 2004 06:14 UTC)
Re: SRFI 56 Binary I/O bear (17 Jun 2004 09:06 UTC)
Re: SRFI 56 Binary I/O Alex Shinn (17 Jun 2004 10:17 UTC)
Re: SRFI 56 Binary I/O Shiro Kawai (17 Jun 2004 10:40 UTC)
Re: SRFI 56 Binary I/O tb@xxxxxx (17 Jun 2004 15:09 UTC)

Re: SRFI 56 Binary I/O Alex Shinn 17 Jun 2004 02:39 UTC

Hi!

Thanks for your comments.

At Wed, 16 Jun 2004 17:44:48 -0700 (PDT), bear wrote:
>
> 	One issue; how much of a standard is BER?  12.5 percent
> protocol lossage seems like a lot to me.

BER (Basic Encoding Rules) is part of the X.690 standard, listed in
the references.  Unfortunately it's not freely available, but there
are various descriptions of BER on the net, with bindings in several
languages.  It's a system for binary encoding various types such as
integers, strings and lists, involving a tag field, length for strings
and lists, followed by the data.  It's actively used in SNMP and LDAP,
and is used in the (non-standard) RFC2503.

The "ber-integer"s as provided in SRFI-56 are actually the length
field used in the BER encoding.  The obvious binary encoding for a
string or list is to provide a length followed by the actual data.  In
the majority of cases the length will be small, but you don't want to
build in any predefined limits and hence 1 bit in 8 is designated as a
continuation flag.  So even without actually supporting BER, I think
the length encoding it uses is the most efficient, and reusable in any
binary serialization.

If we keep the ber-integers I will probably describe them more in
terms of length encoding than bignum (which suggests the numbers are
typically large).  When you do expect very large bignums the most
efficient encoding may be a BER length field followed by a byte
sequence.

--
Alex