Thanks, Karsten. > - Does ExtraInfoDescriptor support bridge descriptors yet? Those don't > contain a signature, which means that the signature variable shouldn't > be marked as required. Also, there should be a digest() method for > RelayExtraInfoDescriptor and a digest variable for > BridgeExtraInfoDescriptor; the relay descriptor digest is calculated, > whereas the bridge descriptor digest is parsed from the "router-digest" > line.
> - ServerDescriptor also has a digest() method for both relay and bridge > descriptors. The same reasoning about a digest() method for relays and > a digest variable for bridges applies here, too. In the documentation > of digest(), better talk about "network status entry" instead of "server > descriptor entry". Ack! Good points. Time permitting I'll fix these over the weekend. > - Why does digest() return the base64-encoded digest, not the > hex-formatted one? Network statuses are the only documents in Tor using > base64 (or rather, a variant of it without trailing ='s), so it's easier > to convert those to hex than to convert everything else to base64. Now, > if you switch to hex, you'll only have to decide between lower-case and > upper-case. I think Tor and metrics-lib use upper-case hex in most places. I went with base64 because I thought that this was only useful for comparing with the network status. What uses the hex encoded digest? > - Should the conn_bi_direct_* variables be grouped under "Bi-directional > connection usage:"? > > And here are a few typos that I found while reading: > > - "fastest querter" -> "fastest quarter" > > - "circuits in a deciles" -> "circuits in a decile" > > - "doens't conform" -> "doesn't conform" > > - "averate rate" -> "average rate" > > - "appeard" -> "appeared" great, changed > - address_alt is not bridge-specific, but relays are going to list > additional OR addresses in their descriptors in the near future. Yup, but they don't yet nor is it in the tor spec (last that I checked). I was planning to move it up to the ServerDescriptor class when it is. _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
