[tor-bugs] #22827 [Core Tor/Tor]: Formalise CollecTor spec for sanitised bridge descriptors and put in torspec

[Tor Bug Tracker & Wiki]

#22827: Formalise CollecTor spec for sanitised bridge descriptors and put in
torspec
---------------------------------------------+-----------------------------
 Reporter:  isis                             |          Owner:  karsten
     Type:  enhancement                      |         Status:
                                             |  needs_review
 Priority:  Medium                           |      Milestone:  Tor:
                                             |  unspecified
Component:  Core Tor/Tor                     |        Version:
 Severity:  Normal                           |     Resolution:
 Keywords:  tor-spec, tor-docs, tor-bridges  |  Actual Points:
Parent ID:                                   |         Points:
 Reviewer:                                   |        Sponsor:
---------------------------------------------+-----------------------------

Comment (by iwakeh):

 Replying to [comment:12 karsten]:
 > Replying to [comment:11 iwakeh]:
 > > Looks fine!
 > >
 > > Maybe keep the comment section small by removing all resolved
 comments,
 >
 > Ah, yes. In fact, I thought we'd remove the entire WIP section and the
 build instructions before publishing.

 The instructions could be turned into a comment in the xml, if the xslt-
 processing doesn't complain.

 >
 > > like c00, c00a, c01,c01a (actually the entire xslt discussion), c07,
 c07a.
 >
 > Yep, they can all go away.
 >
 > > c03&c03a could be replaced by a remark that ANTLR is too much overhead
 for the moment.
 >
 > Yep, good idea.
 >
 > > Regarding c02, c02a:  There is no list of references in the new html.
 If that resolves the issue, it could also be removed.
 >
 > Works for me.
 >
 > > Minor format issue/nitpick:
 > > I don't find the choice of `[:n]` very intuitive as operator (and also
 applying it from the right.  Maybe just use a function notation, e.g.,
 `Bn`.  For example:
 > > `KeyedHash = SHA256(Ipv4Address | Fingerprint | Secret)[:3]` could
 become
 > > `KeyedHash = B3(SHA256(Ipv4Address | Fingerprint | Secret))`.
 >
 > This notation is being used in other Tor specification documents. That's
 why I'd rather not touch it without suggesting a more formal and hopefully
 at the same time more intuitive notation for the remaining specification
 parts. Do you mind if we keep this unchanged for now?

 I don't insist on the change.

 >
 > > Shouldn't the additional xslt and awk files used for generating html
 be also added to git?
 >
 > Yes. I just wasn't sure whether this will be the final place for putting
 the specification file, so I only checked in the source file. But they can
 certainly go into the repo.
 >
 > How do we proceed (assuming we can resolve the remaining parts above)?
 How would we include the generated HTML in the Tor Metrics website? Do we
 edit the XSLT template for that, or do we write a shell script for this
 that rips out the pieces of the generated HTML file that we want, or what?

 We found a place for the page (cf. team meeting).
 I think it would be best to adapt the XSLT.  That would complete the task
 in one processing step.
 Maybe, first define the target page (incl. colors etc.) and then give it a
 try with XSLT?
 shell scripting should be last resort.

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