[tor-commits] [torspec/master] Reword address format definition in section 4.5

[nickm at torproject.org]

commit 7282e122886e9198e8a9fb368252e9e99dde6eb9
Author: rl1987 <rl1987 at sdf.lonestar.org>
Date:   Thu Nov 29 12:19:33 2018 +0200

    Reword address format definition in section 4.5
    
    Let's refrain from mentioning section 6.4 in here, as the format
    is not exactly the same - not all address type field values from
    section 6.4 make sense in NETINFO cell and NETINFO cell does not
    have a TTL value at the end of each address. It's a little confusing
    to suggest that there is a reuse of wire format fragment between
    RELAY_RESOLVED and NETINFO cells.
---
 tor-spec.txt | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/tor-spec.txt b/tor-spec.txt
index 97d5159..9203842 100644
--- a/tor-spec.txt
+++ b/tor-spec.txt
@@ -857,10 +857,19 @@ see tor-design.pdf.
          Number of addresses    [1 byte]
          This OR's addresses    [variable]
 
-   The address format is a type/length/value sequence as given in
-   section 6.4 below, without the final TTL.  The timestamp is a
-   big-endian unsigned integer number of seconds since the Unix epoch.
-   Implementations MUST ignore unexpected bytes at the end of the cell.
+   The address format is as follows:
+         Type [1 byte]
+           * 0x04 - IPv4
+           * 0x06 - IPv6
+         Length (size of Value field) [1 byte]
+           * 4 if Type is IPv4
+           * 16 if Type is IPv6
+         Value [Variable-width]
+           * Address value in network byte order.
+
+   The timestamp is a big-endian unsigned integer number of seconds
+   since the Unix epoch. Implementations MUST ignore unexpected bytes
+   at the end of the cell.
 
    Implementations MAY use the timestamp value to help decide if their
    clocks are skewed.  Initiators MAY use "other OR's address" to help