MRPT 0.2.2 Transport

Initial: 2003-09-15
Modify: 2003-09-19

MRPT Transport Encoding 0.2.2

This encoding will borrow some ideas from ASN.1.
Both types and semantic objects will be included in the type system.
ASN.1 may be considered as a possible alternate encoding.

All multibyte values will be in big-endian ordering.

VLI Numbers

VLI Numbers are variable length integers. The goal of a VLI Num is to allow a compact representation for smaller numbers, and to still allow for reasonably compactness of larger numbers (approx a 1/8th inflation).
Each byte in a VLI Num has the MSB set to 1 to indicate a subsequent byte comprising lower bits, otherwise the byte is considered as being terminal (holds the lowest 7 bits).

Objects

the header will consist of a VLI Num tag possibly followed by the length and contents.
no semantics info will be transmitted with the tags.

There is to be no padding between objects within compound structures.

Object {
    vli tag;
    if(has_contents(tag))
    {
        if(variable_length(tag))
        {
            vli len;
            byte data[len];
        }else
        {
            byte data[data_length(tag)];
        }
    }
}

Rationale:
I am saving space. It is assumed that the usage of this transport will disambiguate any tag/encoding issues.

Tag Translation

A sub-protocol will exist for the purpose of translating tags and working with internal/external representation. Before any tags (outside this sub protocol) are sent, they must be declared to the other end. This will define the textual representation of tags, along with some type info for the purpose of decoding the tags. Tags within this sub-protocol are to have predefined structure.
These predefined tags are to only appear at top-level. A len of 'T' indicates variable length contents.

Number	Nmonic	Len	Description
0	(invalid)	0	Invalid code, not to be sent.
1	negotiation	T	String, sends options or requests.
2	declare-tag	T	64 bit tag info followed by the string tag nmonic. TagInfo { short-be flags; //1&=compound, 2&=fixed length, 8-128&=encoding related, it is an error if an unknown flag is set short-be tag; //tag value byte len; //length for fixed len objs, 0 means no-data byte class; //value class for primitives, 0=default/raw, 1=string, 2=integer, 3=ieee float; intended more as a decoder hint byte resv[2]; }
3-31	(reserved)	T	Reserved tags. It is considered an error if one of these is recieved and is unknown.

Tag values are to be assigned dynamically starting with 32.

Tag names are to follow the form: '<protocol>/<tag>', '<protocol>-<implementation>/<tag>', '<protocol>-<creator>/<tag>', or '<protocol>-<creator>-<implementation>/<tag>'. these conventions are mainly to avoid name clashes between multiple, likely unrelated, tags.
The prefix part of the tag will be viewed as the "protocol class".

Establishing Connections

This will by default use TCP, port 7938.

Negotiation

Negotiation strings can be sent to request/declare information to the other end of the node, each will have the form 'C...', where C is a special key character. '<' and '>' are used to indicate variables embedded in the form, they do not appear in the transmission of the string.
Any unknown negotiation strings are to be ignored. The connection is to be closed if unacceptable values can't be reached.

Form	Description
?<var>	Request the value of the variable on the other end.
=<var> <val>	Response to a request for a value/assignment, or to declare some property.
!<var> <val>	Try to assign a value on the other end.
E<name> <opts> <description...>	There was an error, name is an error name, opts is a comma seperated list of options ('-' for none), description is some text.

Upon connection, each end is to query the other end's version
"?MRPT", with a response of "=MRPT <ver>", for this spec ver="0.2.2". An implementation is not to send base tags/options not defined for that version.