[or-cvs] [tor/master 2/5] Clarify that TRUNCATE behavior isn't as-intended

[nickm at torproject.org]

Author: Nick Mathewson <nickm at torproject.org>
Date: Mon, 2 Aug 2010 12:28:25 -0400
Subject: Clarify that TRUNCATE behavior isn't as-intended
Commit: c4b83b21776bd2c205d038ded5a7e5260a1c39df

In tor-spec.txt, instead of saying "nodes may X" instead say "Current
nodes do X; this is nonconformant. Clients should watch out for that."

Based on observations by wanoskarnet.
---
 doc/spec/tor-spec.txt |   12 +++++++++---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/doc/spec/tor-spec.txt b/doc/spec/tor-spec.txt
index 5283442..d0c60c0 100644
--- a/doc/spec/tor-spec.txt
+++ b/doc/spec/tor-spec.txt
@@ -595,9 +595,15 @@ see tor-design.pdf.
    To tear down part of a circuit, the OP may send a RELAY_TRUNCATE cell
    signaling a given OR (Stream ID zero).  That OR sends a DESTROY
    cell to the next node in the circuit, and replies to the OP with a
-   RELAY_TRUNCATED cell.  If the OR has any RELAY cells queued on the
-   circuit for the next node in that it had not yet sent, it MAY
-   drop them without sending them.
+   RELAY_TRUNCATED cell.
+
+   [Note: If an OR receives a TRUNCATE cell and it any RELAY cells queued on
+   the circuit for the next node in that it had not yet sent, it will drop
+   them without sending them.  This is not considered conformant behavior,
+   but it probably won't get fixed till a later versions of Tor.  Thus,
+   clients SHOULD NOT send a TRUNCATE cell to a node running any current
+   version of Tor if they have sent relay cells through that node, and they
+   aren't sure whether those cells have been sent on.]
 
    When an unrecoverable error occurs along one connection in a
    circuit, the nodes on either side of the connection should, if they
-- 
1.7.1