This document is a high level architecture document describing a project that is currently being developed. It is out of date and should be replaced in the near future.

The new approach is to extend the JSON-B specification with a 'frame' container that contains a length indicator at both the front and the back of the frame. This allows a log containing a sequence of entries to be read efficiently from either the start or the end. This should be very useful since it is most convenient to update files in an append only fashion, which may be supported by an atomic transaction by the platform.

JSON Web Container

The JSON Web container is based on the following specifications and standards:

The use of JSON-B instead of JSON avoids the 33% increase in data size that would otherwise occur due to the use of Base64 encoding.

A JSON Web Container is a sequence of three types of entry:

Decryption entry
Contains the cryptographic parameters to be used for decryption
Content entry
Consists of a metadata block, the content data and an optional integrity block.
Directory entry
A content entry that is marked as being a list of indexes to other entries.

The format is intended for use as a means of collecting a sequence of updates to a single resource or a collection of variations on a resource. For example:

  • A list of instant messages sent and received in a chat room.

        Directory entries provide a means of providing rapid access to content entries without having to scan the entire container. They might also be used as a means of bundling a complete Web Page or even a site into a single convenient package for archive, etc.

        A JWC may be static or dynamic. A static JWC contains content that has been fixed and will not be extended. A dynamic JWC is used for data such as chat logs that may be being extended by one user at the same time another is reading.

        Static JWC

        A static JWC is typically used to wrap a single content item and will have exactly two entries. The first entry is a Decryption Entry describing how the data is to be decrypted. The second entry is a Content Entry containing a sequence of up to three individually encrypted blocks containing the metadata, data and integrity data.

        Another possible use for a static JWC is as a container for a collection of related files, similar to a ZIP file. Since it is generally desirable for an application to be able to read the directory as the first item in such a container, but it is the element that is usually written last, we may wish to allow the first entry in a JWC to be a pointer to the directory entry at the end of the file. Alternatively, we might decide to make the file offsets recorded in the directory entry relative to the end of the directory entry so that it composed separately and prepended when complete.

        Dynamic JWC

        A dynamic JWC is used to wrap content such as chat room logs, comments to a Web forum, voice and video streams. As with a static JWC, the first entry is a Decryption Entry. But that entry may be followed by any number of Decryption and Content Entries.

        For certain messaging interactions, it is the nature of the communication that all parties begin at the beginning of a stream and finish at the end. In others a participant may join part way through but immediately catch up to the current point in the proceedings.

        In other cases there may be a need to support 'random access' to the data stream, thus the need for directory entries.