[Gzz-commits] gzz/doc/pegboard/simple_storm--benja peg.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Benja Fallenstein <address@hidden>      03/03/23 10:36:08

Modified files:
        doc/pegboard/simple_storm--benja: peg.rst 

Log message:
        resolve issues

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/simple_storm--benja/peg.rst.diff?tr1=1.6&tr2=1.7&r1=text&r2=text

Patches:
Index: gzz/doc/pegboard/simple_storm--benja/peg.rst
diff -u gzz/doc/pegboard/simple_storm--benja/peg.rst:1.6 
gzz/doc/pegboard/simple_storm--benja/peg.rst:1.7
--- gzz/doc/pegboard/simple_storm--benja/peg.rst:1.6    Wed Feb 26 01:51:07 2003
+++ gzz/doc/pegboard/simple_storm--benja/peg.rst        Sun Mar 23 10:36:08 2003
@@ -4,17 +4,17 @@
 
 :Author:       Benja Fallenstein
 :Date:         2003-02-16
-:Revision:     $Revision: 1.6 $
-:Last-Modified: $Date: 2003/02/26 06:51:07 $
+:Revision:     $Revision: 1.7 $
+:Last-Modified: $Date: 2003/03/23 15:36:08 $
 :Type:         Architecture
 :Scope:                Major
-:Status:       Incomplete
+: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
+a single time, as Tuomas suggests, we should take the opportunity to
 get rid of our mistakes from the past, in order to make
 the future simpler.
 
@@ -46,14 +46,36 @@
    We'll be using that (and we'll fully specify it when
    writing the informal URN namespace registration).
 
-- How do we represent charsets?
-
-   SUGGESTED RESOLUTION: Like in ``data:`` URIs:
-   ``...text/plain;charset=utf-8``.
-
 - Why bitzi bitprint? What is it? Why not SHA-1?
 
+   RESOLVED: Bitprints are a combination of a SHA-1 hash with a
+   Merkle hash tree based on the Tiger hash algorithm.
+   Hash algorithms get broken; when one of the above
+   is broken, you have a transitional period before
+   the other is, too, in which you can e.g. sign blocks,
+   ensuring you can still use them when the other
+   is broken too.
+
+   Having a hash tree allows you to download pieces
+   of a block from different sources, verifying each
+   piece individually. This can be of great help
+   in speeding up download times.
+
 - Are bitprints too long for short blocks like ours?
+  (How long are the IDs going to be and whether 
+  this will be a problem.)
+
+   RESOLVED: Here's an example URI, 102 characters long:
+
+     urn:urn-?:application/rdf+xml,QLFYWY2RI5WZCTEP6MJKR
+     5CAFGP7FQ5X.VEKXTRSJPTZJLY2IKG5FQ2TCXK26SECFPP4DX7I
+  
+   This is long, but IMO not 'too long.'
+
+- Why this syntax? Why not another?
+
+   RESOLVED: For similarity to RFC 2397 (The "data"
+   URL scheme).
 
 Changes
 =======
@@ -61,23 +83,33 @@
 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>:block:[<mediatype>],<data>
 
 ``<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.
+by <http://bitzi.com/developer/bitprint>. ``<mediatype>`` is
+the token defined in [RFC2397]--
+
+    mediatype  := [ type "/" subtype ] *( ";" parameter )
+    parameter  := attribute "=" value
+
+"where [...] 'type', 'subtype', 'attribute' and 'value' are 
+the corresponding tokens from [RFC2045], represented using 
+URL escaped encoding of [RFC2396] as necessary" [RFC2397].
+(Escaping is necessary when a character isn't in the set
+of allowed URN characters.)
+
+"X-" types aren't allowed, as they work against the persistence
+of Storm blocks; ``application/octet-stream`` or similar
+must be used instead. 
 
-If no ``<content-type>`` is given, or a URI content type
-is not known, ``application/octet-stream`` is assumed.
+Unlike in [RDF2397], if no ``<mediatype>`` is given,
+``application/octet-stream`` is assumed (not ``text/plain``).
 
 There is a public domain Java implementation of bitprints at
 <http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/bitcollider/jbitprint/>.
 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.
+according to Bitzi. However, they will not include a
+content type.
 
 \- Benja