From: Nick Mathewson Date: Mon, 2 Aug 2010 16:28:25 +0000 (-0400) Subject: Clarify that TRUNCATE behavior isn't as-intended X-Git-Tag: tor-0.2.2.16-alpha~7^2~3 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=c4b83b21776bd2c205d038ded5a7e5260a1c39df;p=thirdparty%2Ftor.git Clarify that TRUNCATE behavior isn't as-intended 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. --- diff --git a/doc/spec/tor-spec.txt b/doc/spec/tor-spec.txt index 5283442fe9..d0c60c0e6a 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