Case-insensitive parsing of <id-right> in message-IDs

[Russ Allbery]

Julien ÉLIE <julien at trigofacile.com> writes:

> Too bad just using "hisv7" instead of "hisv6" is not that easy.
> Incidentally, do you remember were the previous hisv1, ..., hisv5
> formats were and how they were handled before the hismethod: parameter
> in inn.conf?

The dbz format that came with INN 1.0 was v3, so I think everything prior
to that was in C News.  It looks like INN 2.0 switched to v6.  I'm not
sure what happened between v3 and v6; I didn't start working on INN
seriously until after 2.0 (around 2.1 or so).

> A database version number would indeed be interesting to have.  That's a
> nice idea.  It would be checked when history is (re)opened.  It would
> even allow a smooth transition because as long as the history belongs to
> an old version, the hash could still be searched in lower-case
> characters.

> When you speak about keeping a database version number, is it something
> like a <pathdb>/history.version file that contains "1.0", "1.1", etc. or…
> a <pathdb>/history.format file that contains lines parsable with the new
> parser:
>   tagged-hash: no
>   case-sensitive: yes
>   large-file: no
>   hismethod: hisv6
>   format: [hash, date, token]

> Funny, extensible things possible to do afterwards with the history file!

history.dir does store the database *format* version, and from it you can
tell whether it's tagged-hash or not.  But I like your history.format idea
above; that looks like a better approach in the long run.  Particularly
since abusing the database format version to control whether the data is
case-insensitive is probably not a good idea.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.