Initial: 2003-09-12
Modified: 2003-09-12

MRPT 0.2.1


MRPT 0.1 was not satisfactory, I will define MRPT 0.2. MRPT will not have a fixed type system, the type system may be extended as needed. The type system will try to be much more simplistic than other MRP type protocols.
MRPT 0.2.1: Changing general encoding a bit.

MRPT Base Encoding

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

Each object will begin with a 2 byte tag:

The the top 2 bits of the first byte will be a class:
0: base types;
1: implementation types;
2: context specific types;
3: dynamic types.

the next bit will specify whether it is a primitive or compound type:
0: primitive;
1: compound.

the next 3 bits are reserved and will be set to 0.

the lower 2 bits and the next byte together will form a 10 bit tag (with the next byte being the lower 8).

The tag is followed by a VLI num. 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). An encoder is allowed to insert pad bytes (0x80) if so needed.
This number indicates the length of the following data, with the meaning of the data depending on the type.

For primitive objects the contents will be raw data, with a meaning only explained by the type.
For compound objects the contents will be an array of objects.

There is to be no padding between objects.

Rationale:
Length fields make it easier for the decoder to determine if an entire structure is present and to allocate temporary storage.
As a cost of using lengths, it will be necessary that an encoder make use of buffers (or forward-predict the size of the data).

MRPT Base Types


These will be generally required for MRPT conformance, Implementation extension types are allowed as well, however it is required that an implementation verify that the other end knows/sends the same types as it (as to avoid interpreting invalid/garbage when dealing with an unknown implementation).
Implementation types are allowed to be fixed on both the sender and reciever, wheras dynamic types are allowed to vary (but will likely be fixed from the point of view of the sender), but are required to be variable for the reciever.

Unless stated otherwise all multibyte integers are to be interpreted as 2's complement big-endian ("Network Byte Order"). All floating point values are to follow the IEEE encoding and also be in big-endian ordering.

Primitive

Tag Value
 Description
0
 Invalid.
1
 Negotiation String.
2-31
 Reserved for primitive protocol types.
32-63
 Reserved for compound protocol types.
64
 Integer(value), required to have a power of 2 size.
65
 Special(value), single byte {0=false,1=true, 2=null, 3-255 reserved}.
66
 Narrow String(value), 7-bit ascii only.
67
 Wide String(value), UTF-16.
68
 Floating point(value), 4/8 bytes.
69
 Raw Data(value).
70
 Date String(value), 'YYYY-MM-DD', 'YYYY-MM-DD hh:mm:ss', 'YYYY-MM-DD hh:mm:ss.fff'.
71
 Symbolic String (value), UTF-8. If the implementation does not distinguish between strings and symbols or does not support symbols, then this is to be interpreted as a string. This is not to be sent by an implementation which does not distinguish symbols/strings.
72-95
 Reserved for MRPT primitive values.

Compound

Tag Value
 Description
0
 Invalid
1-31
 Reserved for primitive protocol types.
32
 Call, Contents are a: Method-ID (String or Implementation Dependant Integer); Arguments (Array); and, an Id-Value (Integer).
33
 Return, Contents are a return value, and the Id-Value from the call.
34
 Error, Contents are the Id-Value and an Error-String.
35
 Pass, Contents are a: Method-ID (String or Implementation Dependant Integer); Arguments (Array). A pass is a call that does not return a value.
36-63
 Reserved for compound protocol types.
64-95
 Reserved for MRPT primitive values.
96
 Array(value) of values.
97
 Structure(value), Contents are an array of name strings and value objects.
98-127
 Reserved


Establishing Connections

MRPT will by default use port 7937.
On connection the client is to write the raw string "MRPTID", and the server is to respond with "MRPTOK". The connection is to be closed if any other values are recieved, or if a response is not recieved within "a reasonable amount of time".

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.
!<var> <val>
 Try to assign a value on the other end.
E<ext>
 Try to enable an extension.
S<ext>
 Extension Enabled.
F<ext> <reason...>
 Extension Failed, reason is an implementation dependant string.
K<hhhh> <name>
 hhhh is the hex form of a tag value, name is the name of the tag. This is a possible response of enabling extensions.

Variable/extension names will be viewed as implementation dependant.
Implementation dependant extensions should have a name of the form:
'<implementation>-<extension>' or '<creator>-<extension>'. '<creator>-<implementation>-<extension>' may be used if names may collide within projects of the same creator.

An implementation may not enable/negotiate an extension it does not support.