Binary Object REst Distributed (BORED) system - Part 3 - Structure

In this post I present version 0.1 of the BORED request and response structures. This will be refined in future posts as trade-offs are made and the protocol matures. I won't go into much detail here as future posts will provide a lot more detailed analysis.

There are only two message types in the BORED protocol; the request type and response type. Operations such as GET or POST found in HTTP are encapsulated in the message data and do not form the surrounding message. The request message consists of:

request:

preamble - BORED
version

location - URI location or other location type.

optional headers
- headers meta data
- headers data

message
- message meta data.
- message - request data.
- - operation - GET,META,POST,METHOD,etc
- - message data

optional security
- identity/signature meta data
- - optional identity
- - optional signature

The request data elements are:

preamble - "BORED" The six ASCII characters define the headers of the BORED protocol. This signifies the start of the message.
version - This will consist of a major and minor version as two unsigned 8-bit characters.
location - This is the location where the message should be delivered.
optional headers - This provides an area for additional information to be added. It is analogous to HTTP headers.
message - The message to be delivered to the specified location. This should include any POST data or URI request parameters found in HTTP.
optional security - This provides the option to provide identify of the client and sign requests.

A simple request message might look logically like:

BORED 0.1 - BORED://www.livemedia.com.au/document.pdf (GET) - ;

Note: For now these requests are demonstrated as text for human readability. As the elements of the protocol are refined binary examples will be provided.

In the example above the following elements are present:

preamble - BORED
version - 0.1
location - BORED://www.livemedia.com.au/document.pdf
optional headers - not included
message - (GET)
optional security - not included

The response has much of the same information as the request data. The response includes a response code and caching information.

response:

preamble - BORED
version

response code
cache information

optional headers
- headers meta data
- headers data

message
- message meta data.
- message - response data.
- - message data

optional security
- optional identity/signature meta data
- optional identity
- optional signature (from response code)

The response fields include many of the same data as in the request.

preamble - "BORED" The six ASCII characters define the headers of the BORED protocol. This signifies the start of the message.
version - This will consist of a major and minor version as two unsigned 8-bit characters.
response code - The response code for the data.
cache information - Information on if the response should be cached and for how long.
optional headers - This provides an area for additional information to be added. It is analogous to HTTP headers.
message - The message to be returned to the client.
optional security - This provides the option to provide identify of the server and sign responses.

A corresponding response might logically be:

BORED 0.1 200(OK) "No Cache" - (mime document/pdf .....data....) - ;

In this case the elements are:

preamble - BORED
version - 0.1
response code - 200(OK)
cache information - "No Cache"
optional headers - not included
message - (mime document/pdf .....data....)
optional security - not included

Tim Bray mentioned in this blog that it would be likely that any development of a protocol will probably end up looking a lot like HTTP. I think his spot on! You will find many of the same elements in different protocols. However, some of the nuances between each protocol can have a big effect on a protocols design and flexibility. For example, by moving the GET verb from the request header and into the body, we've completely changed the character of the protocol. HTTP is purposely constrained to a reduced set of verbs such as GET, PUT and POST. However, BORED places the verb into the body of the message which allows any number of verbs to be implemented without disturbing the transfer portion of the protocol.

Refering back to the layers of the protocol, we can see that most of the protocol is concerned with the transfer layer. The message/presentation layer is the message structure and its structure can be defined without concern for the transfer layer. The object receiver is concerned with how to process the message content and is outside the scope of the actual protocol. It is only important that any type of data can be transferred to the Object Receiver in the message body.

The layered design should allow the message data to arrive at the Object Receiver using different methods (protocols or in other data structures). This becomes important when providing a layered system. A front-end server (e.g. apache) may receive the message and then use a different transfer protocol to pass the message to an internal system. Using this method, the Object Receiver may receive additional information regarding the request; this would be dependent on the features of the internal system. This design ensures that the message can be separated from the transfer protocol in a simple way without requiring processing the data contained inside the message.

The import elements in the request which are required for the transfer layer include:

Preamble and Version – This simply sets the receiver of the message to understand and sync with the right version of the protocol.
Location – The location provides the target for the message.
Optional Headers – This can include information for Proxy servers, or request that the request is not responded to by caches.
Optional Security – This can be used for signing the message request data.

The message structure is the payload of the transfer protocol. The message layer requires a separate investigation and will be developed further later in this series of posts.

This post provides the rough outline of the data to be included in requests. The message structure and meta data associated with request and response will be developed in future posts. The next steps will be to test the protocol design against REST constraints and see what other features may be useful.