commit 82d9b977ac264fa7b5b1003e092c539f3ee1e0e3 Author: Karsten Loesing karsten.loesing@gmx.net Date: Tue Jan 14 19:42:29 2014 +0100
Make section 6 and its subsections the new section 5.4.
This specification should end at the point where clients have downloaded all directory information they need. Using this information should be covered in path-spec.
This results in the following changes to section numbers: * 6 -> 5.4 * 6.1 -> 5.4.1 * 6.2 -> 5.4.2 * 6.3 -> 5.4.3 * 6.4 -> 5.4.4 * 6.5 -> 5.4.5
This commit does not yet repair subsequent section numbers. --- dir-spec.txt | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/dir-spec.txt b/dir-spec.txt index 7429446..f60beea 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -2648,7 +2648,7 @@ - The client does not currently have it. - The client is not currently trying to download it. - The client would not discard it immediately upon receiving it. - - The client thinks it is running and valid (see section 6.1 below). + - The client thinks it is running and valid (see section 5.4.1 below).
If at least 16 known routers have downloadable descriptors, or if enough time (currently 10 minutes) has passed since the last time the @@ -2718,14 +2718,16 @@ documents are missing. Clients try to download from caches. We follow the same splitting and back-off rules as in section 5.2.
-6. Using directory information +5.4. Using directory information + + [XXX This subsection really belongs in path-spec.txt, not here. -KL]
Everyone besides directory authorities uses the approaches in this section to decide which relays to use and what their keys are likely to be. (Directory authorities just believe their own opinions, as in section 3.4.2 above.)
-6.1. Choosing routers for circuits. +5.4.1. Choosing routers for circuits.
Circuits SHOULD NOT be built until the client has enough directory information: a live consensus network status [XXXX fallback?] and @@ -2754,7 +2756,7 @@
See the "path-spec.txt" document for more details.
-6.2. Managing naming +5.4.2. Managing naming
In order to provide human-memorable names for individual router identities, some directory servers bind names to IDs. Clients handle @@ -2782,12 +2784,12 @@ SHOULD NOT ever use a router in response to a user request for a router called "Unnamed".
-6.3. Software versions +5.4.3. Software versions
An implementation of Tor SHOULD warn when it has fetched a consensus network-status, and it is running a software version not listed.
-6.4. Warning about a router's status. +5.4.4. Warning about a router's status.
If a router tries to publish its descriptor to a Naming authority that has its nickname mapped to another key, the router SHOULD @@ -2802,7 +2804,7 @@
...
-6.5. Router protocol versions +5.4.5. Router protocol versions
A client should believe that a router supports a given feature if that feature is supported by the router or protocol versions in more than half