Skip to content
Snippets Groups Projects
Closed Revert change that made 'TRANSPORT' optional in our spec; restore backward compatibility
  • View options
  • Revert change that made 'TRANSPORT' optional in our spec; restore backward compatibility

  • View options
  • Closed Issue created by Nick Mathewson

    If I understand correctly: up until the TRANSPORT field in pt client STATUS messages was made optional in !63 (merged), the spec said it was mandatory. This means that arti had been correct to kill off PTs that omitted it (see arti#1488 (closed)) and C tor had been arguably correct to drop STATUS messages that omitted it (see !63 (comment 3046530) ).

    But with the change that made TRANSPORT optional, those existing implementations became incorrect. That's a compatibility break: we should really avoid those whenever we can.

    IMO, if we do really want to remove the TRANSPORT field without breaking backward compatibility, we need to do it in a staged process. We would want to say something like "PT implementations MUST send TRANSPORT; Tor implementations SHOULD accept STATUS lines that lack it" or something like that, and then explain that TRANSPORT will eventually become optional, but isn't yet.

    (And before removing TRANSPORT, we should ask whether we still want to support PTs that provide multiple transports. Do we not that any longer? Or do we intend that their status always be the same for all transports?)

    cc @ahf @meskio @dgoulet @dcf

    Linked items ... 0

  • Activity

    • All activity
    • Comments only
    • History only
    • Newest first
    • Oldest first
    Loading Loading Loading Loading Loading Loading Loading Loading Loading Loading