ntor3, rend3: clarify extension field defaults.

These patch changes describe new default behaviors for extension
field lists, as appear in ntor3 and in many places throughout the
ntor3 protocol.  In general:

* Unrecognized extensions MUST be ignored.

Additionally, all the following rules apply _unless otherwise stated
in the documentation for an extension.

* Extensions are sent in sorted order.
* Extensions should only be sent once in a message
* If you receive multiple copies of an extension, only the first
  one counts.

This comes out of discussions on tor!525.

1 files changed, 18 insertions, 10 deletions

diff --git a/proposals/332-ntor-v3-with-extra-data.md b/proposals/332-ntor-v3-with-extra-data.md
index 4e55713..8e6dedc 100644
--- a/proposals/332-ntor-v3-with-extra-data.md
+++ b/proposals/332-ntor-v3-with-extra-data.md
@@ -338,20 +338,28 @@ We use the following meta-encoding for the contents of client and
 server messages.
 
     [Any number of times]:
-       TYPE     [one byte]
-       LEN      [one byte]
-       BODY     [LEN bytes]
-
-We do not specify specific TYPE semantics here; we leave those for
-other proposals.
+    EXTENSION
+       EXT_FIELD_TYPE     [one byte]
+       EXT_FIELD_LEN      [one byte]
+       EXT_FIELD          [EXT_FIELD_LEN bytes]
 
 All parties MUST reject messages that are not well-formed per the
 rules above.
 
-To avoid partitioning, clients MUST reject messages with TYPEs that
-they do not recognize.  (Therefore, whenever we specify a new server
-message TYPE, we must say that it can only be included if the client
-signals that it understands it.)
+We do not specify specific TYPE semantics here; we leave those for
+other proposals and specifications.
+
+Parties MUST ignore extensions with `EXT_FIELD_TYPE` bodies they do not
+recognize.
+
+Unless otherwise specified in the documentation for an extension type:
+* Each extension type SHOULD be sent only once in a message.
+* Parties MUST ignore any occurrences all occurrences of an extension
+  with a given type after the first such occurrence.
+* Extensions SHOULD be sent in numerically ascending order by type.
+
+(The above extension sorting and multiplicity rules are only defaults;
+they may be overridden in the description of individual extensions.)
 
 # A.3 How much space is available?