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.
This commit is contained in:
Nick Mathewson 2010-08-02 12:28:25 -04:00
parent 6f45101327
commit c4b83b2177

View File

@ -595,9 +595,15 @@ see tor-design.pdf.
To tear down part of a circuit, the OP may send a RELAY_TRUNCATE cell 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 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 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 RELAY_TRUNCATED cell.
circuit for the next node in that it had not yet sent, it MAY
drop them without sending them. [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 When an unrecoverable error occurs along one connection in a
circuit, the nodes on either side of the connection should, if they circuit, the nodes on either side of the connection should, if they