[Gzz] PEG simple_storm--benja: Simplify Storm by dropping headers

[Benja Fallenstein]

===========================================================
``simple_storm--benja``: Simplify Storm by dropping headers
===========================================================

:Author:        Benja Fallenstein
:Date:          2003-02-16
:Revision:      $Revision$
:Last-Modified: $Date$
:Type:          Architecture
:Scope:         Major
:Status:        Current


Storm is quite complex with its MIME headers, and prone to become
more complex if we choose to separate hashing of headers and bodies
(``raw_blocks--benja``). If we break backward compatibility
once, as Tuomas suggests, we should take the opportunity to
get rid of our mistakes from the past, in order to make
the future simpler.


Issues
======

- Won't dropping headers make it harder to include metadata?

   RESOLVED: MIME headers are a non-extensible form of metadata
   anyway; if we allow ``X-`` headers, we have problems with
   permanence. We can still put metadata into another block
   refering to this one; alternatively, many file formats
   allow inclusion of metadata in the file itself (e.g. PNG).

   The benefits outweigh the problems by far.


Changes
=======

Storm blocks do not have headers any more; the hash in their URN
is only of the body. Storm URNs have the following form:

    <namespace>:block:<bitprint>[:<content-type>]

``<namespace>`` is an informal URN namespace to be registered,
like ``urn:urn-5``. ``<bitprint>`` is a Bitzi bitprint as defined
by <http://bitzi.com/developer/bitprint>. ``<content-type>`` is
either a non-"X-" MIME content type or a URI. ``X-`` types are
prohibited because they work against the persistence of Storm blocks.
We allow URIs as a namespace for experimental identifiers instead.

If no ``<content-type>`` is given, or a URI content type
is not known, ``application/octet-stream`` is assumed.

Bitprints may be registered as a URN namespace in the future,
according to Bitzi. If they're willing to include an optional
content type, ``urn:bitprint:`` and our ``urn:...:block:``
would be equivalent.

\- Benja