[or-cvs] mark off todo items; add todo items; correct tor-spec.txt

[Roger Dingledine]

Update of /home/or/cvsroot/doc
In directory moria.mit.edu:/home2/arma/work/onion/cvs/doc

Modified Files:
	TODO tor-spec.txt 
Log Message:
mark off todo items; add todo items; correct tor-spec.txt


Index: TODO
===================================================================
RCS file: /home/or/cvsroot/doc/TODO,v
retrieving revision 1.136
retrieving revision 1.137
diff -u -d -r1.136 -r1.137
--- TODO	22 Jul 2004 01:35:52 -0000	1.136
+++ TODO	22 Jul 2004 07:34:03 -0000	1.137
@@ -105,10 +105,10 @@
           - and working
 
       for pre1:
-        - 0.0.8 ORs should use identity key for 0.0.7 ORs sometimes but
+        o 0.0.8 ORs should use identity key for 0.0.7 ORs sometimes but
           not always?
-        - we should publish advertised_bandwidth in descriptor
-        - bug: 0.0.8 OPs can't extend from an 0.0.7 OR to an 0.0.8 OR
+        o we should publish advertised_bandwidth in descriptor
+        o bug: 0.0.8 OPs can't extend from an 0.0.7 OR to an 0.0.8 OR
 
       post pre1:
         - when we sigint tor, the dns/cpuworkers don't intercept sigint?
@@ -117,6 +117,13 @@
         - ORs use uniquer default nicknames
         - Tors deal appropriately when a newly-verified router has the
           same nickname as another router they know about
+        X 007 can't extend to unverified 008. they will never be able to.
+        - if a begin failed due to exit policy, but we believe the IP
+          should have been allowed, switch that router to exitpolicy
+          reject *:* until we get our next directory.
+        - make advertised_server_mode() ORs fetch dirs more often.
+        - should the running-routers list put unverified routers at the
+          end?
 
 
       ongoing:

Index: tor-spec.txt
===================================================================
RCS file: /home/or/cvsroot/doc/tor-spec.txt,v
retrieving revision 1.59
retrieving revision 1.60
diff -u -d -r1.59 -r1.60
--- tor-spec.txt	1 Jul 2004 01:34:02 -0000	1.59
+++ tor-spec.txt	22 Jul 2004 07:34:03 -0000	1.60
@@ -11,10 +11,6 @@
 more information on why Tor acts as it does, see tor-design.pdf.
 
 TODO: (very soon)
-      X EXTEND cells should have hostnames or nicknames, so that OPs never
-        resolve OR hostnames.  Else DNS servers can give different answers to
-        different OPs, and compromise their anonymity.
-         - Alternatively, directories should include IPs.
       - REASON_CONNECTFAILED should include an IP.
       - Copy prose from tor-design to make everything more readable.
 
@@ -68,8 +64,8 @@
    support any suite without ephemeral keys, symmetric keys of at
    least 128 bits, and digests of at least 160 bits.
 
-   An OR always sends two-certificate chain, consisting of a self-signed
-   certificate containing the OR's identity key, and of a second certificate
+   An OR always sends a two-certificate chain, consisting of a self-signed
+   certificate containing the OR's identity key, and a second certificate
    using a short-term connection key.  The commonName of the second
    certificate is the OR's nickname, and the commonName of the first
    certificate is the OR's nickname, followed by a space and the string
@@ -79,8 +75,7 @@
    as expected.  (When initiating a connection, the expected identity key is
    the one given in the directory; when creating a connection because of an
    EXTEND cell, the expected identity key is the one given in the cell.)  If
-   the key is not as expected, the party must close the connection if it is
-   not.
+   the key is not as expected, the party must close the connection.
 
    Once a TLS connection is established, the two sides send cells
    (specified below) to one another.  Cells are sent serially.  All
@@ -175,18 +170,18 @@
    The relay payload for an EXTEND relay cell consists of:
          Address                       [4 bytes]
          Port                          [2 bytes]
-         Public key hash               [20 bytes]
          Onion skin                    [186 bytes]
+         Public key hash               [20 bytes]
 
    The port and address field denote the IPV4 address and port of the
    next onion router in the circuit; the public key hash is the SHA1 hash of
    the ASN1 encoding of the next onion router's identity key.
 
    [XXXX Before 0.0.8, EXTEND cells did not include the public key hash.
-   Servers running 0.0.8 distinguish the old-style cells based on the length
-   of payloads.  Clients running 0.0.8 check for servers version 0.0.7 or
-   later, and send them the old-style EXTEND cells.  In a future release,
-   old-style EXTEND cells will not be supported.]
+   Servers running 0.0.8 distinguish the old-style cells based on the
+   length of payloads. (Servers running 0.0.7 blindly pass on the extend
+   cell regardless of length.) In a future release, old-style EXTEND
+   cells will not be supported.]
 
    The payload for a CREATED cell, or the relay payload for an
    EXTENDED cell, contains: