[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[minion-cvs] Integrate comments/changes from PP



Update of /home/minion/cvsroot/doc/spec
In directory moria.mit.edu:/tmp/cvs-serv9208

Modified Files:
	E2E-spec.txt minion-spec.txt 
Log Message:
Integrate comments/changes from PP

Index: E2E-spec.txt
===================================================================
RCS file: /home/minion/cvsroot/doc/spec/E2E-spec.txt,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -d -r1.11 -r1.12
--- E2E-spec.txt	1 Oct 2003 22:15:23 -0000	1.11
+++ E2E-spec.txt	2 Oct 2003 14:23:32 -0000	1.12
@@ -114,7 +114,7 @@
 
       * "Corrupted packet" - A packet which has had its payload
         corrupted on the second leg of its path.  [Other forms of
-        corruption will result in the message's not being delivered.]
+        corruption will result in the packet not being delivered.]
 
 2. End-to-end message encoding
 
@@ -162,7 +162,7 @@
    version.
 
    We also define DECOMPRESS as the inverse of COMPRESS: namely, ZLIB
-   decompression as described in RFCs 1950 and 1951.  Note that not
+   decompression as described in RFCs 1950 and 1951.  Note that
    DECOMPRESS is not defined for every sequence of bytes.
 
 2.1.2. K-of-N fragmentation
@@ -183,11 +183,11 @@
    Currently, we use the algorithm described by Luigi Rizzo in several
    papers and implemented in software at
              http://info.iet.unipi.it/~luigi/fec.html .
-   This algorithm has
-   several advantages: first, it has freely-available implementations
-   in C and Java under a modified-BSD style license.  Second, it runs
-   with acceptable performance for modest values of K (less than 30 or
-   so).  Third, it does not seem to be patent encumbered.
+   This algorithm has several advantages: first, it has freely-available
+   implementations in C and Java under a modified-BSD style license.
+   Second, it runs with acceptable performance for modest values of K
+   (less than 30 or so).  Third, it does not seem to be patent
+   encumbered.
 
    Of course, this algorithm has disadvantages.  First, it lacks a
    complete, byte-level specification beyond that given at the URL
@@ -249,7 +249,7 @@
    WHITEN(M) = SPRP_Encrypt(K_whiten, "WHITEN", M)
    UNWHITEN(M) = SPRP_Decrypt(K_whiten, "WHITEN", M)
 
-   where K_whiten is equal to the octet sequence {57 48 49 54 45 4E}.
+   where K_whiten is equal to the octet sequence [57 48 49 54 45 4E].
 
    Note that applying K_whiten and DIVIDE together has the effect of
    turning DIVIDE from an erasure correcting code into a full secret
@@ -747,6 +747,22 @@
   [XXXX Are msg-ids really what we want? Should we say more?  Should
         we restrict encoding? -NM]
 
+  [XXXX The client should not be allowed to supply IN-REPLY-TO.  Instead
+        the exit node should set IN-REPLY-TO to the last msg-id in the
+        REFERENCES header.
+        Also there should be a standard encoding of msgd-ids: for
+        instance msg-ids should be seperated by one space (0x20)
+        exactly.
+        Additionaly there should be a specified way of dealing with
+        references lines that are too long.  The standard in news seems
+        to be to keep the first msg-id in the list (the original post
+        that started a thread), and then remove as many of the following
+        msg-ids so that the line fits in the space available.
+        (XXX: need to cross-check that with the usefor drafts).  - PP]
+
+  [XXXX Okay; let me know when you have crosschecked successfully, and
+        when you have an citation for this. -NM]
+
   Unrecognized or malformatted headers MUST be removed.
 
 3.2.3. Delivery
@@ -794,8 +810,16 @@
    The "In-Reply-To" and "References" lines should be taken verbatim
    from the corresponding headers, if those headers are present.
    [XXXX Is this sensible? -NM]
+   [XXXX See my comment about in-reply-to above. -PP]
 
-   The "X-Anonymous" line should be present, and set to "yes".
+   The "X-Anonymous" line SHOULD be present, and set to "yes".
+   [XXXX Do you really think this is a good idea? -PP]
+   [XXXX Yes.  There's nothing wrong with letting people who don't
+         want anonymous messages block 'em.  (On IRC, PP says that he
+         is worried about large ISPs filtering.)  This bears more
+         thought, but I think it's probably a bad idea to deliberately
+         screw over unwilling recipients in order to bypass
+         clueless/draconian sysadmins. -NM]
 
    Note again that all unrecognized or misformatted headers MUST be
    rejected.
@@ -812,7 +836,7 @@
    maximum permitted message size in KB (before compression).  Note
    that because of base64-encoding, actual delivered messages may be
    longer than this by a factor of ~1.33.  The value must be at least
-   "32".  It MUST contain a "Allow-From" line, containing 'yes' if the
+   "32".  It MUST contain an "Allow-From" line, containing 'yes' if the
    server allows user-supplied from addresses and 'no' if it does not.
 
 3.3. SMTP
@@ -831,7 +855,7 @@
 
       MAILBOX ::= LOCALPART AT HOSTPART
       LOCALPART ::= ATOM | LOCALPART DOT ATOM
-      HOSTPART ::= ATOM | LOCALPART DOT ATOM
+      HOSTPART ::= ATOM | HOSTPART DOT ATOM
       ATOM ::= ATOMCHAR | ATOM ATOMCHAR
       ATOMCHAR ::= Any character in the range hex 21 through hex 7E,
              excluding '[', ']', '(', ')', '<', '>', '@', ',', '.',
@@ -843,6 +867,12 @@
    blacklisting hard, and encourage senders to resolve target hosts.
 
    [XXXX I suspect the above should be "SHOULD NOT." -NM]
+   [XXXX It is possible that an email address is in fact
+         example@[192.186.2.1], so it really should be SHOULD NOT.
+         Also can we reach all possible mail addresses using this
+         strict syntax?  Do we care? -PP] 
+   [XXXX Using IP addresses does, as noted above, make blacklisting
+         hard.  But we should review RFC2821 to see if we care. -NM]
 
 3.3.2. Formatting: Message body
 
@@ -870,7 +900,7 @@
    that because of base64-encoding, actual delivered messages may be
    longer than this by a factor of ~1.33. The value must be at least
    "32".  A server MAY drop any message that uncompresses to be
-   longer than this type. It MUST contain a "Allow-From"
+   longer than this type. It MUST contain an "Allow-From"
    line, containing 'yes' if the server allows user-supplied from
    addresses and 'no' if it does not.
 

Index: minion-spec.txt
===================================================================
RCS file: /home/minion/cvsroot/doc/spec/minion-spec.txt,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -d -r1.14 -r1.15
--- minion-spec.txt	1 Oct 2003 22:15:24 -0000	1.14
+++ minion-spec.txt	2 Oct 2003 14:23:33 -0000	1.15
@@ -317,7 +317,7 @@
       enemy from oppression."
 
    (In hexadecimal, the hash of P is:
-    [90 89 60 BC 88 EF 92 B0 9c 58 26 C4 BE 32 B3 34 A7 1C AA 5A].)
+    [90 89 60 BC 88 EF 92 B0 9C 58 26 C4 BE 32 B3 34 A7 1C AA 5A].)
 
    For all public key operations in Type III packets, we use 2048-bit
    keys.  We define: