> On 25 Dec 2017, at 07:13, Damian Johnson <atagar@xxxxxxxxxxxxxx> wrote: > >> Done! >> >> * the file now starts with a type and a version line: >> /* type=fallback */ >> /* version=2.0.0 */ >> * extrainfo is mandatory (occasionally we won't get a descriptor, so >> we'll warn and mark the relay extrainfo=0) >> * each fallback entry ends with /* ===== */ > > Sweet, thanks Tim! > >> * is 6 extra info caches (up from 4) enough in a list of 150? > > Hmmm. Can't say on Stem's side I have an opinion on this. It doesn't > rely on fallback directories for anything so extrainfo caches aren't a > concern. So stem just uses a mix of fallbacks and authorities? Good, that's what Tor does. I think we will be fine then. >> * do you want the delimiter before the first fallback entry as well? > > Stem doesn't care about a delimiter before the first entry but that > seems like a good idea so we have a clear separation between comments > and the start of the machine readable section. I made the header end with a delimiter, and I made the list of entries start with a delimiter: https://trac.torproject.org/projects/tor/attachment/ticket/22759/fallback_dirs_new_format_version.3.inc This means that parsers can (and should) ingore the human-readable second section. > A detail Stem does care about is that the last entry ends with a > delimiter. If it doesn't that's fine, but code is a tad simpler if we > ensure it does. :) It does and it will continue to. > On 25 Dec 2017, at 07:26, Iain Learmonth <irl@xxxxxxxxxxxxxx> wrote: > > As we are planning to also add a parser to metrics-lib (#24434), would > it be possible to get a full description of the format of the file > possibly in RFC5234 format so that we can check that the generator and > parsers all match up to that specification? I have written up a format in the standard torspec style: https://github.com/teor2345/torspec/blob/fallback-format-2/fallback-spec.txt It is deliberately under-specified, please let me know if this causes any trouble when writing the parser, and I will tighten it up. It's not ABNF/RFC5234, it's rather restrictive, and strict ABNF is unreadable for case sensitive strings. I am happy to put an ABNF spec in an appendix, if someone wants to write one. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
Attachment:
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev