[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gzz-commits] gzz/doc/pegboard/simple_storm--benja peg.rst
From: |
Benja Fallenstein |
Subject: |
[Gzz-commits] gzz/doc/pegboard/simple_storm--benja peg.rst |
Date: |
Sun, 23 Mar 2003 10:36:08 -0500 |
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
- [Gzz-commits] gzz/doc/pegboard/simple_storm--benja peg.rst,
Benja Fallenstein <=