[NNTP] Consensus?

Richard Clayton richard at highwayman.com
Wed Aug 10 06:02:10 PDT 2005


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In message <877jeu1tir.fsf at windlord.stanford.edu>, Russ Allbery
<rra at stanford.edu> writes
>Steve Walker <nntp at nntpserver.com> writes:
>> Russ Allbery wrote:
>
>>> For (1), the discussion has been wide-ranging enough that I'm not sure
>>> on (a).  I know some folks here would like the limit removed entirely,
>>> but I don't have a good feeling on what people think about 2^32-1
>>> versus 2^31-1 assuming that we keep a limit.  More discussion would be
>>> valuable there, I believe.
>
>> If you mean remove the limit in the draft and leave the issue 
>> open for further discussion I'm ok with that.
>
>No, I didn't mean that; I meant discussion of Clive's specific proposal.
>There had been a lot of discussion around other things, but not about what
>Clive said in particular, so I didn't feel like I could judge consensus on
>that proposal.

If you meant Clive's BIGNUM proposal

    http://lists.eyrie.org/pipermail/ietf-nntp/2005-July/001656.html

I thought it was elegant and looked reasonably straightforward to cope
with from an implementation point of view -- and had the advantage that
everyone knew exactly where they were with it.

It does mean that there is no wrap around -- so clients cannot access
groups that have overflowed (but today's clients probably can't cope
with groups with that sort of volume on anything other than a sampling
basis anyway).

The only real problem seems to be this one server design that doesn't
have separate numbers for separate groups (thereby breaking assumptions
about file sizes for clients that thought they could use the space-
saving "10-15, 17-23, 25" style recording for articles they had read,
and also breaking all sorts of heuristics for "catching up" the last 50
articles....)

I'm reluctant to see ANY solution discarded for a single design that
although it doesn't break any rules bends them significantly.

Since Turnpike (a client, albeit one in development hibernation) was
mentioned earlier and I know a few things about it -- I should point out
that it spends most of its time handling message IDs and deals with
article numbers only occasionally (mainly for spotting when the server
has renumbered the newsgroup). However, it does store these values in
its files (which are not flat ASCII files), so it's not just a case of
changing a typedef and recompiling, but changing the file format,
providing a migration tool and such...  I doubt anyone will be
interested in bothering.

As a developer, I think I'm more impressed with a system like Clive's
that allows me to make my own judgment as to what sort of limits I'm
prepared to support (and handle the failure elegantly and with precise
details for the user) than a SHOULD for 64bits, which I'm likely to just
say "I know better, this will ruin my pretty design for something that
will not happen for decades" and get on with something else (ie: it's
not going to make me implement 64 bits unless I'm very motivated or have
personally encountered this one strange server design).

>> Personally I would like the wording changed to require (a MUST) 32 bit
>> support and suggest (a SHOULD) 64 bit support.
>
>That's two people supporting that option.  What does everyone else think
>about that?

The MUST for 32 bits might get people's attention on a slow afternoon
and may prevent a few people using signed values...   but I doubt the
SHOULD will make any impression at all -- after all, they ought to be
starting to worry about what their time_t code will do in 2038...

- -- 
richard                                              Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.         Benjamin Franklin

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBQvn60poAxkTY1oPiEQIwRgCeMcd2y8bP66GSFsj0hfPpJYF2NyMAn25j
CUklgOLwudOmlUrW2ptPQ9/u
=FWsf
-----END PGP SIGNATURE-----



More information about the ietf-nntp mailing list