ietf-nntp Backfill

[Clive D.W. Feather]

Jon Ribbens <jon at oaktree.co.uk> writes
>I am looking at INN 1.4 for this reply.

Okay. However, bear in mind that my original message was to address the
general issue.

>> [Q1] When a group becomes the current group, is the set of articles made
>> available to the client fixed at that moment ?
>Yes and no. The list of article numbers available is fixed at the
>moment you execute 'group'.
>> [Q2] When will new articles become available and expired/cancelled ones
>> become unavailable ? Is it:
>New ones will become available and deleted ones will become unavailable
>immediately. However 'NEXT' will not attempt to show deleted articles,
>and it will not attempt to show newly-arrived articles. This seems
>reasonable to me.

So you are saying that NEXT from article 1200 might give article 1234,
even though there is an article 1212 ?

Hmm. I would never have thought of that as being a behaviour permitted
by RFC 977. But I can see where it comes from.

>> [Q5] Can an article appear with a number between the previous limits,
>> such as 1250 ?
>No.

Someone said at the BOF that this *does* happen with INN.

>> There are three common scenarios posited for NNTP clients and servers. I
>> call these "monotonic", "backfilling", and "wind-back". They answer the
>> first three questions:
>Wind-back?

"wind", as in winding a crank.

>> Servers appear to exist of all three kinds,
>Is there more than one site in existance which uses backfilling?

I don't know.

>> A sensible client needs to allow for the user wanting to mark articles
>> as unread. Therefore it must be able to cope with the backfilling
>> strategy, by (for example) maintaining a list of ranges.
>No. An unread article and an unavailable article are not the same
>thing.

Any mechanism for passing the concept "article 1234 is unread" between
session can equally cope with passing the concept "article 1234 hasn't
appeared yet". That's what I meant.

>> Given this, there seems little reason to require that servers be
>> monotonic.
>Given that almost every news client in existance requires that
>servers be monotonic, I would suggest that it would be a very
>good idea for the new NNTP specification to require it too.

Yet several people at the BOF thought that backfilling was reasonable.

>> On the other hand, there are advantages to the answer to Q4 being "no".
>> If it is, then it is possible to forget everything about articles with
>> numbers below the current minimum.
>There are 'advantages'!? Surely you mean 'it is essential that the
>answer to Q4 be "no"'? Otherwise, due to the occasionaly cancelled
>article and so on interrupting the numbering range, the news client
>must maintain a list of ranges which grows without bound.

Bear in mind that one long-lived low-numbered article can have the same
effect.

>Not only this, but on every connection it must explicitly check
>for every article not found before, in order to produce a valid
>display of available articles.

No, because a walk using NEXT will show what is and isn't there.

>The
>newsreader *must* have some mechanism of saying "well, this
>article is never going to turn up now, I don't need to worry
>about it any more".

I agree that it's highly desirable. But since the RFC currently says
nothing about article number behaviour, the question needs raising.

>Backfilling is not necessary, no widely used servers do it,

Not what was said at the BOF.

>It is a Bad Thing. RFC 977 did not allow it,

Where doesn't it allow it ? What wording forbids it ?

>It should be possible to fetch news without
>recourse to heuristics.

Agreed.

-- 
Clive D.W. Feather    | Associate Director  | Director
Tel: +44 181 371 1138 | Demon Internet Ltd. | CityScape Internet Services Ltd.
Fax: +44 181 371 1150 | <clive at demon.net>   | <cdwf at cityscape.co.uk>
Written on my laptop - please reply to the Reply-To address <clive at demon.net>