Move all text-only specifications into the OLD_TXT directory.

1 files changed, 0 insertions, 94 deletions

diff --git a/address-spec.txt b/address-spec.txt
deleted file mode 100644
index 1e90e6e..0000000
--- a/address-spec.txt
+++ /dev/null
@@ -1,94 +0,0 @@
-                          Special Hostnames in Tor
-                               Nick Mathewson
-
-Table of Contents
-
-    1. Overview
-    2. .exit
-    3. .onion
-    4. .noconnect
-
-1. Overview
-
-  Most of the time, Tor treats user-specified hostnames as opaque:  When
-  the user connects to www.torproject.org, Tor picks an exit node and uses
-  that node to connect to "www.torproject.org".  Some hostnames, however,
-  can be used to override Tor's default behavior and circuit-building
-  rules.
-
-  These hostnames can be passed to Tor as the address part of a SOCKS4a or
-  SOCKS5 request.  If the application is connected to Tor using an IP-only
-  method (such as SOCKS4, TransPort, or NATDPort), these hostnames can be
-  substituted for certain IP addresses using the MapAddress configuration
-  option or the MAPADDRESS control command.
-
-2. .exit
-
-  SYNTAX:  [hostname].[name-or-digest].exit
-           [name-or-digest].exit
-
-  Hostname is a valid hostname; [name-or-digest] is either the nickname of a
-  Tor node or the hex-encoded digest of that node's public key.
-
-  When Tor sees an address in this format, it uses the specified hostname as
-  the exit node.  If no "hostname" component is given, Tor defaults to the
-  published IPv4 address of the exit node.
-
-  It is valid to try to resolve hostnames, and in fact upon success Tor
-  will cache an internal mapaddress of the form
-  "www.google.com.foo.exit=64.233.161.99.foo.exit" to speed subsequent
-  lookups.
-
-  The .exit notation is disabled by default as of Tor 0.2.2.1-alpha, due
-  to potential application-level attacks.
-
-  EXAMPLES:
-     www.example.com.exampletornode.exit
-
-        Connect to www.example.com from the node called "exampletornode".
-
-     exampletornode.exit
-
-        Connect to the published IP address of "exampletornode" using
-        "exampletornode" as the exit.
-
-3. .onion
-
-  SYNTAX:  [digest].onion
-           [ignored].[digest].onion
-
-  Version 2 addresses (deprecated since 0.4.6.1-alpha), the digest is the first
-  eighty bits of a SHA1 hash of the identity key for a hidden service, encoded
-  in base32.
-
-  Version 3 addresses, the digest is defined as:
-
-     onion_address = base32(PUBKEY | CHECKSUM | VERSION)
-     CHECKSUM = H(".onion checksum" | PUBKEY | VERSION)[:2]
-
-     where:
-       - PUBKEY is the 32 bytes ed25519 master pubkey of the onion service.
-       - VERSION is a one byte version field (default value '\x03')
-       - ".onion checksum" is a constant string
-       - H is SHA3-256
-       - CHECKSUM is truncated to two bytes before inserting it in onion_address
-
-  When Tor sees an address in this format, it tries to look up and connect to
-  the specified onion service. See rend-spec-v3.txt for full details.
-
-  The "ignored" portion of the address is intended for use in vhosting, and
-  is supported in Tor 0.2.4.10-alpha and later.
-
-4. .noconnect
-
-  SYNTAX:  [string].noconnect
-
-  When Tor sees an address in this format, it immediately closes the
-  connection without attaching it to any circuit. This is useful for
-  controllers that want to test whether a given application is indeed
-  using the same instance of Tor that they're controlling.
-
-  This feature was added in Tor 0.1.2.4-alpha, and taken out in Tor
-  0.2.2.1-alpha over fears that it provided another avenue for detecting
-  Tor users via application-level web tricks.
-