[tor-bugs] #6872 [Tor Client]: 'bwweightscale' pram missing from spec

Tor Bug Tracker & Wiki torproject-admin at torproject.org
Wed Sep 19 15:22:49 UTC 2012


#6872: 'bwweightscale' pram missing from spec
---------------------------+------------------------------------------------
    Reporter:  atagar      |       Owner:          
        Type:  defect      |      Status:  reopened
    Priority:  trivial     |   Milestone:          
   Component:  Tor Client  |     Version:          
  Resolution:              |    Keywords:          
      Parent:              |      Points:          
Actualpoints:              |  
---------------------------+------------------------------------------------
Changes (by atagar):

  * status:  closed => reopened
  * resolution:  fixed =>


Comment:

 Reopening with a patch as discussed in irc (again on my 6872 branch).
 Please see the commit description for more information...

 https://gitweb.torproject.org/user/atagar/torspec.git/commitdiff/f6b3177f78549fcd4705849c79d83a41f3c2f441

 Mike: Do you want to allow for negative weights? Are zero values ok? Any
 upper bound? If the answer to any of these isn't "any Int32 is ok" then
 now is the time to say so.

 Nick: As a person parsing these documents I've liked how localized and
 well defined they are. For server descriptors we say how additional
 arguments should be handled...

 {{{
 In lines that take multiple arguments, extra arguments SHOULD be
 accepted and ignored.
 }}}

 But extra-info descriptors and network status documents have no such note.
 This is probably an oversight. I'm happy for the above to be the default
 behavior for the dir-spec. My suggestion is to move the note from section
 2.1 to section 0 (right below the 'The key words "MUST", "MUST NOT"...'
 note). This is an important parsing detail and putting it anywhere lower
 will cause it to be lost in the spec's unpleasantly large header.

 I haven't given much about the control-spec. Iirc we defined how new
 parameters should be handled for events (that was the change that prompted
 the big TorCtl patch that was never merged...) but I'm not sure if this
 sort of default behavior would cause complications for other sections.

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


More information about the tor-bugs mailing list