[tor-bugs] #14165 [Tor]: Tor needs a protocol versioning scheme

Tor Bug Tracker & Wiki blackhole at torproject.org
Sun Jan 11 17:29:30 UTC 2015


#14165: Tor needs a protocol versioning scheme
-----------------------------+----------------------
     Reporter:  TvdW         |      Owner:
         Type:  enhancement  |     Status:  new
     Priority:  normal       |  Milestone:
    Component:  Tor          |    Version:
   Resolution:               |   Keywords:  tor-spec
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+----------------------

Comment (by massar):

 >  They're nice and compact but require all alternative implementations to
 implement the exact same set of features

 One compare this in same way to HTML4, HTML5 etc.

 > Also doesn't deal with forward compatibility well if features are
 dropped in newer versions.

 Should work totally fine.

 eg, lets say we have:
  Protocol 5 = before ntor
  Protocol 6 = ntor supported
  Protocol 7 = ntor, but does not support anything before P6

 If the client is at P5 then it can't use P6 nodes or higher. A P7 node
 won't be able to use a P6 node as it knows that itself does not have

 Yes, one will have to be smart about picking features. But basically it
 will mean that the protocol number is more a 'feature package' number than
 an actual 'version number'.

 Clients implementing higher versions will know what capabilities the older
 clients do or do not have and thus if they are compatible with them.
 Newer clients won't know the newer editions (though we could backport the
 list of course, eg supports P5, but knows upto P8) for stable branches.

 The above thus avoids the problem of having all these flags represented in
 the consensus ,and a small consensus is a good consensus.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/14165#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list