fenfire-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Fenfire-dev] PEG: Pointer triple blocks (pointer_triple_blocks--benja)


From: Benja Fallenstein
Subject: [Fenfire-dev] PEG: Pointer triple blocks (pointer_triple_blocks--benja)
Date: Sat, 23 Aug 2003 14:37:50 +0200

=====================
Pointer triple blocks
=====================

:Author:  Benja Fallenstein
:Created: 2003-08-23
:Changed: $Date$
:Status:  Current
:Scope:   Major
:Type:    Architecture


Continuing the PEG `pointers_overview--benja`__, this PEG
defines a file format for storing triples about pointers.
(The overview PEG defined pointers as URIs that authoritative
triples can be associated with-- all other uses of pointers
build on this basic model.)

__ ../pointers_overview--benja/peg.gen.html



Issues
======

.. None yet.



Model
=====

A triple block contains the following information:

- The subject of the triple (a pointer URI).
- The property of the triple (any URI).
- The object of the triple (any URI; literal or bnode objects
  are not supported).
- A timestamp.
- A list of triples "obsoleted" by this triple; the meaning
  of this is defined by the property of the triple.
  (Represented as a list of the hashes of other triple blocks.)

Pointer URIs have the following form::

    urn:x-storm:ptr:<hash>

where ``<hash>`` is the hash of the pointer's "manifest," a Storm block 
containing defining information about the pointer, in a format defined
in a future PEG.

The timestamp has two components:

- The number of milliseconds since the epoch (as a binary number).
- The last known "root round." Root rounds are Storm blocks issued
  by a centralized entity in the system and play a role in the
  issuing of permanent digital signatures; details will be discussed
  in later PEGs.

Root rounds are issued in a series, i.e. there is an absolute order
on them. An order on timestamps is defined by the following rule
for comparing two timestamps:

- If they refer to different root rounds, the timestamp which
  refers to the earlier root round is the earlier timestamp.
- If they refer to the same root round, but have different
  millisecond values, the timestamp with the lower microsecond value
  is the earlier timestamp.
- Otherwise, the timestamps are equal.

This design seeks to avoid problems due to a computer clock being set
to some future time. 

For example, if some software problem causes
a computer's clock to be set to 2040 (this has happened to me),
and that computer signs a document version, it would be decidedly
inconvenient if no other document version could become current before
2040.

The proposed design avoids that problem because a timestamp issued
when the next root round value is known will be treated as having been
given later than the one from "2040."



Format
======

A triple block contains the following:

- The string "``PtrTriple``" in ASCII (9 bytes).
- A 0x00 byte (this may be used later to denote the format version).
- The serial number of the last known root round value,
  as an unsigned two-byte binary integer (2 bytes).
- The hash of the last known root round value, in binary
  representation (part of the timestamp, 44 bytes).
- The hash of the subject pointer's manifest (44 bytes).
- The length of the property URI, in UTF-8 octets, as an unsigned
  one-byte integer (1 byte).
- The property URI, encoded in UTF-8.
- One byte representing the object URI's type: 0x01 if a ``block`` URI;
  0x02 if a ``ref`` URI; 0x03 if a ``ptr`` URI; 0x00 if any other URI.
  Any other byte in this position is an error.
- The object URI, encoded differently depending on the type byte:

  - If 0x01, the hash of the block (44 bytes) followed by the length
    of the media type (1 byte, unsigned integer) followed by the
    media type.
  - If 0x02, the hash of the ``ref`` block.
  - If 0x03, the hash of the pointer manifest block.
  - If 0x00, the length of the object URI in UTF-8 octets (1 byte,
    unsigned integer), followed by the property URI in UTF-8.

- The number of triples obsoleted by this one, as a one-byte
  unsigned integer (1 byte).
- The hashes of the obsoleted triples. Each hash is 44 bytes long;
  there are as many hashes as indicated by the integer in the
  previous field.

In the case of an unexpected EOF or a value not expected in a
particular field (e.g., a 0x04 value in the object URI type field),
a processor must abort, essentially treating the whole block as junk.
A processor must also do the same if there is no EOF after the
above information.

Processors do not have to check that an object URI of type 0x00 (other)
is neither a ``block`` nor a ``ref`` or ``ptr`` URI.

Counting of the root round values starts with one. The "zeroth"
root round is a special, empty root round which is represented
not by a hash, but by 44 0x00 (zero) bytes. If no real root round value 
is known (yet), the zeroth root round can be used instead.
(This also allows bootstrapping the system without having the root
fully functioning, yet.)

There is also a special value for the subject pointer URI. This is
because the pointer manifest block, whose hash defines the identity
of a pointer, may already refer to a set of triples about that pointer;
when the corresponding triple blocks are created, the pointer's
identity is of course not yet known. Because of that, in this case,
the pointer manifest's hash is replaced by 44 0xFF bytes.



Media type
==========

No MIME type is defined for triple blocks, yet. For the moment,
``application/octet-stream`` is used. We should define a MIME type
at a later point, though.

\- Benja






reply via email to

[Prev in Thread] Current Thread [Next in Thread]