[tor-dev] New Fallback Directory File Format

[teor]

> On 25 Dec 2017, at 07:13, Damian Johnson <atagar at torproject.org> 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 at torproject.org> 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
------------------------------------------------------------------------



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20171226/3e184ee4/attachment.sig>