Subject: [NNTP] Article Numbers Becoming Invalid (RFC 3977)

From: Sabahattin Gucukoglu <[email-masked]>
Date: Sat, 26 Dec 2009 21:52:31 +0000

Hi all,

RFC 977 makes no special mention of article numbers being no longer valid, but assigns a code 430 for "Article not found".  RFC 3977 does away with that code, but then describes the possibility of articles being removed.  It doesn't say why or how.

I'm trying to write a program that gets all articles from a group, articles numbered in ascending order, noting first and last reported by the GROUP response, and noting the minimum article number written into a user rc file that is updated with each invocation.
http://get.sabahattin-gucukoglu.com/newsfetch

Like a tool I used before, this is intended to get news into a mailbox, but this hand-written tool delivers them using raw SMTP that is a lot faster and more useful than delivering to mbox files.  Quite often I am getting errors from my news server about articles that disappeared but that are in the newsgroup's range.  Presumably, they were once valid.

How and why do articles disappear, and what can I do about this?  Shall I just ignore errors about invalid article numbers, or try to enumerate article numbers?  (Most news servers don't know about the listgroup range operand.)

Cheers,
Sabahattin

---

From: Russ Allbery <[email-masked]>
Date: Sat, 26 Dec 2009 14:06:40 -0800

Sabahattin Gucukoglu <[email-masked]> writes:

> RFC 977 makes no special mention of article numbers being no longer
> valid, but assigns a code 430 for "Article not found".  RFC 3977 does
> away with that code, but then describes the possibility of articles
> being removed.  It doesn't say why or how.

I'm not sure that I understand.  430 is still in RFC 3977 as the return
code for ARTICLE and related commands when retrieving an article number
(or message ID) that doesn't exist.

> I'm trying to write a program that gets all articles from a group,
> articles numbered in ascending order, noting first and last reported by
> the GROUP response, and noting the minimum article number written into a
> user rc file that is updated with each invocation.

> Like a tool I used before, this is intended to get news into a mailbox,
> but this hand-written tool delivers them using raw SMTP that is a lot
> faster and more useful than delivering to mbox files.  Quite often I am
> getting errors from my news server about articles that disappeared but
> that are in the newsgroup's range.  Presumably, they were once valid.

> How and why do articles disappear, and what can I do about this?

Generally, it means that the articles have either expired or been
cancelled or deleted by the news administrator.  When they disappear out
of the middle of the article range, it generally means they've been
cancelled.

> Shall I just ignore errors about invalid article numbers, or try to
> enumerate article numbers?  (Most news servers don't know about the
> listgroup range operand.)

Articles that have disappeared normally never reappear.  Most news
software just treats them as if they never existed and increments the low
water mark past them.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Julien ÉLIE <[email-masked]>
Date: Sat, 26 Dec 2009 23:25:26 +0100

Hi Sabahattin,

> RFC 977 makes no special mention of article numbers being no longer valid,
> but assigns a code 430 for "Article not found".  RFC 3977 does away with
> that code, but then describes the possibility of articles being removed.
> It doesn't say why or how.

RFC 3977 still uses the 430 error code.

Both RFCs 977+2980 and 3977 have:

   Response code 423
      Generated by: ARTICLE, BODY, (X)HDR, HEAD, (X)OVER, STAT
      Meaning: no article with that number or in that range.

   Response code 430
      Generated by: ARTICLE, BODY, (X)HDR, HEAD, (X)OVER, STAT
      Meaning: no article with that message-id.

Examples:

GROUP news.software.nntp
211 4420 1 8093 news.software.nntp

LISTGROUP news.software.nntp 8080-
211 4420 1 8093 news.software.nntp
8081
8082
8083
8084
8085
8087
8088
8090
8092
8093
.

STAT <unknown@article>
430 No such article

STAT 8086
423 Bad article number

STAT 8085
223 8085 <[email-masked]> status

NEXT
223 8087 <[email-masked]> Article retrieved; request text separately

> articles numbered in ascending order, noting first and last reported
> by the GROUP response, and noting the minimum article number written
> into a user rc file that is updated with each invocation.

Note that you could use LISTGROUP, as shown above, and use the article
numbers returned.
Or with GROUP only, play with LAST/NEXT.

> Shall I just ignore errors about invalid article numbers,

Yes.

> or try to enumerate article numbers?  (Most news servers don't know
> about the listgroup range operand.)

Send CAPABILITIES.

CAPABILITIES
101 Capability list:
VERSION 2
IMPLEMENTATION INN 2.6.0 (20091201 prerelease)
AUTHINFO USER SASL
HDR
LIST ACTIVE ACTIVE.TIMES DISTRIB.PATS HEADERS NEWSGROUPS OVERVIEW.FMT
NEWNEWS
OVER
READER
SASL GSSAPI OTP PLAIN NTLM LOGIN DIGEST-MD5 CRAM-MD5
STARTTLS
.

If READER is advertised, then use LISTGROUP with a range and collect
the returned article numbers.  Note that even with that, an article
could have disappeared between the time you sent LISTGROUP and the
time you asked for that article.

Otherwise, send LISTGROUP without a range and start from the last
article number you have in your rc file.
If you receive 500 to LISTGROUP, then try GROUP, and if 12 is your
last article number in your rc file, try to collect 13, 14, 15, etc.
until you have a valid article number.  Then use NEXT until you
receive 421.

-- 
Julien ÉLIE

« En vérité, le chemin importe peu, la volonté d'arriver suffit à tout. »

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Sat, 26 Dec 2009 22:52:10 +0000

> (or message ID) that doesn't exist.

Hmm.  Section 6.2.1.1 that describes the article command's usage mentions code 430, but only for when a Message-Id was given, and not for the article number form.  The two subsequent sections seem to confirm that, as does Appendix C.  RFC 977 didn't make any similar restriction.  The changes in Appendix D of RFC 3977 make no note of the change from RFC 977.

I should have clarified my problem by saying that I was talking about article number references, not Message Ids or articles in general.

Cheers,
Sabahattin

---

From: Russ Allbery <[email-masked]>
Date: Sat, 26 Dec 2009 14:53:50 -0800

> Hmm.  Section 6.2.1.1 that describes the article command's usage
> mentions code 430, but only for when a Message-Id was given, and not for
> the article number form.

Oh, yes, I'm sorry, you're right.  The error code is 423 if an article
number is specified, not 430.

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Sun, 27 Dec 2009 03:25:51 +0000

>     Meaning: no article with that message-id.

OK, I see the problem here: RFC 977 defined both codes for use with the article <number> syntax, while RFC 3977 didn't.  So we ignore RFC 977, and all is right with the world again. :-)

The problem was that maybe the RFC 977 use of code 430 meant something, say, "That article number is in range but its data can't be found on disk" or some such.  But I see now that codes 423 and 430 mean the same thing, for number and Message-ID respectively.  Probably should be noted somewhere though - I am seeing a Tornado use 430 exclusively (I have no access to an inn install).  Suck, a program with similar uses but for feeding a local spool, gets around this entirely by just using xhdr.
>> Shall I just ignore errors about invalid article numbers,
Fair enough.  It's easier this way anyway.  It means I spend most of my time reading article data instead of trying to find them, or receiving very long lists of headers or article numbers each time I get run from cron.

I still have a concern though: RFC 2980 clears up the detail of article numbering, monotonically increasing.  So how does a news server work efficiently if the last article number just added is instantly removed?  Now, the group's high watermark is lowered again, and a new article will replace the recently removed article, thus destroying the server-only-uniqueness of article numbers (and therefore any use of the numbers as place markers in the news stream).  And even if that isn't the case, the server will have to note a next article number that is greater than the high watermark it reports, in order that it not reuse the recently removed article's number.  How does it do that, if at all?  If it doesn't reset the high watermark, it's a liability to clients taking the maximum number as gospel, since they will fail to receive the article with the highest article number.  How clear is all of this?
> until you have a valid article number.  Then use NEXT until you

This seems like the next obvious thing to try, thanks.  Right now it just blindly tries every article number from min to max, which works 99% of the time, of course.  Perhaps these removals are the results of spam filtering?  This is the Tornado server provided by my ISP, but haven't checked the reliability of other servers yet.

Cheers,
Sabahattin

---

From: Russ Allbery <[email-masked]>
Date: Sat, 26 Dec 2009 20:08:20 -0800

Sabahattin Gucukoglu <[email-masked]> writes:

> OK, I see the problem here: RFC 977 defined both codes for use with the
> article <number> syntax, while RFC 3977 didn't.  So we ignore RFC 977,
> and all is right with the world again. :-)

> The problem was that maybe the RFC 977 use of code 430 meant something,
> say, "That article number is in range but its data can't be found on
> disk" or some such.  But I see now that codes 423 and 430 mean the same
> thing, for number and Message-ID respectively.

This didn't really change between RFC 3977 and RFC 977 except that RFC
3977 more clearly breaks out the return codes for their allowed context
and RFC 977 didn't.  But I think the intention of RFC 977 was the same:

   423 no such article number in this group
   430 no such article found

To know for sure, though, one would need to check the reference NNTP
implementation that was developed in conjunction with RFC 977 and see what
it did.

> Probably should be noted somewhere though - I am seeing a Tornado use
> 430 exclusively (I have no access to an inn install).  Suck, a program
> with similar uses but for feeding a local spool, gets around this
> entirely by just using xhdr.

Clients can generally treat 423 and 430 as synonymous.

> I still have a concern though: RFC 2980 clears up the detail of article
> numbering, monotonically increasing.  So how does a news server work
> efficiently if the last article number just added is instantly removed?
> Now, the group's high watermark is lowered again,

It works by not doing that.  :)

The group's high water mark for the purposes of new arriving articles must
not decrease.  In other words, a new arriving article must receive a
higher article number than the article that was removed.

RFC 3977 allows for the high water number reported to the client to
decrease, but that's because it allows for the removed article to be
reinstated.  But that article number cannot be reused for a different
article.

> And even if that isn't the case, the server will have to note a next
> article number that is greater than the high watermark it reports, in
> order that it not reuse the recently removed article's number.

The server is permitted to report a high-water mark that's larger than the
highest number of the retrievable articles in the group.

> How does it do that, if at all?  If it doesn't reset the high watermark,
> it's a liability to clients taking the maximum number as gospel, since
> they will fail to receive the article with the highest article number.

Which is fine.  That can happen for any article if it's been removed.
There's nothing special about the highest-numbered article.

> This seems like the next obvious thing to try, thanks.  Right now it
> just blindly tries every article number from min to max, which works 99%
> of the time, of course.  Perhaps these removals are the results of spam
> filtering?

Usually, yes.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Sun, 27 Dec 2009 23:10:53 +0000

Sabahattin Gucukoglu said:
> I'm trying to write a program that gets all articles from a group, articles numbered in ascending order,

Most of your questions have been answered, but the usual way to do this is:

    GROUP a.group
    ARTICLE

The ARTICLE might give a 420 failure response - don't worry if it does.
Then repeat the following pair of commands:

    NEXT
    ARTICLE

until you get a 421 response from NEXT. That will get you all the articles.
Again, you might get a 420 from any of the ARTICLE commands if an article
is removed at just the wrong moment.

If you just want a list of numbers, then:

    GROUP a.group
    STAT
    NEXT
    NEXT
    NEXT
    ...

until the NEXT gives a 421.

-- 
Clive D.W. Feather          | If you lie to the compiler,
Email: [email-masked]     | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646

---

From: Julien ÉLIE <[email-masked]>
Date: Mon, 28 Dec 2009 01:07:23 +0100

Hi Clive,

> until you get a 421 response from NEXT.

Interesting.  It is indeed how it is implemented in INN 2.5.2 (previous versions
were improperly returning 423 instead of 420):

GROUP fr.test
211 7303 3716 11692 fr.test
ARTICLE
420 No current article
NEXT
223 3723 <[email-masked]> Article retrieved; request text separately

Yet, I do not understand the following paragraph in RFC 3977:

6.1.3.  LAST

6.1.3.2.  Description

   If the currently selected newsgroup is valid, the current article
   number MUST be set to the previous article in that newsgroup (that
   is, the highest existing article number less than the current article
   number).  If successful, a response indicating the new current
   article number and the message-id of that article MUST be returned.

[...]

   If the current article number is already the first article of the
   newsgroup, a 422 response MUST be returned.  If the current article
   number is invalid, a 420 response MUST be returned.

6.1.4.  NEXT

6.1.4.2.  Description

   In all other aspects (apart, of course, from the lack of 422 response),
   this command is identical to the LAST command (Section 6.1.3).

Isn't there a contradiction between the fact that the current article
number MUST be set to the [next] article in the newsgroup (and therefore
returning 423) and the fact that the current article number is invalid
(and therefore returning 420)?

-- 
Julien ÉLIE

« Aliquis non debet esse iudex in propria causa,
  quia non potest esse iudex et pars. »

---

From: Julien ÉLIE <[email-masked]>
Date: Sun, 27 Dec 2009 11:06:34 +0100

Hi Russ,

> implementation that was developed in conjunction with RFC 977 and see what

Just checked in nntp-1.5.11:

#define ERR_NOARTIG     423     /* No such article in this group */
#define ERR_NOART       430     /* No such article at all */

4 uses of ERR_NOARTIG and 2 uses of ERR_NOART.
All of them follow that meaning:

    printf("%d Invalid article number: %s.\r\n", ERR_NOARTIG,
           artbuf);

    printf("%d No article by message-id %s, sorry.\r\n",
           ERR_NOART, argv[2]);

It is exactly what RFC 3977 clearly documents.
423 for an article number; 430 for a message-ID.

[Sabahattin]
>> 430 exclusively (I have no access to an inn install).

Then it is a bug in Tornado.
If you want to test on an INN install, my news server news.trigofacile.com
has open read access.

-- 
Julien ÉLIE

« Avez-vous remarqué qu'à table les mets que l'on vous sert vous mettent
  les mots à la bouche ? » (Raymond Devos)

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Mon, 28 Dec 2009 01:53:35 +0000

> (and therefore returning 420)?

My feeling exactly.  The article pointer can't be manipulated while invalid according to spec, and it's only ever valid if set explicitly.  So how do you find the first valid article number without setting it?

Besides, in my program there has to be some minimum article per invocation, user set or script set on exit from the last round.

Hard to believe newsreaders even existed before the times of xover and xhdr and wildmats.  Did they really step article by article, retrieving headers and noting article numbers?  Wow!

Cheers,
Sabahattin

---

From: Julien ÉLIE <[email-masked]>
Date: Mon, 28 Dec 2009 13:24:40 +0100

Hi Sabahattin,

> My feeling exactly.

I think that sections 6.1.3.2 and 6.1.4.2 mix the current article number and
the *new* current article number.  Only the adjective "new" is missing at some
places.

Unless we have confirmation that "new" must not be added, NEXT is supposed
to return 420 after ARTICLE has returned 420.

> The article pointer can't be manipulated while invalid according to spec,
> and it's only ever valid if set explicitly.  So how do you find the first
> valid article number without setting it?

What INN does is that after GROUP, the article number is set to the low
water mark.  It is what is considered to be the first article in the group
(allowing a possible reinstatement).
If the group is empty, the new current article number is still invalid
(because it does not exist).
Note that if a new article arrives in that newsgroup, it will become valid
because INN uses the high water mark + 1 to give a number to the new article
(the high water mark is one less than the low water mark in the case of
an empty newsgroup).

How does INN find the first valid article number?  INN just tries every number
below the high water mark.  The first valid one is what will be returned
by NEXT.
It is also how LISTGROUP behaves:  INN will scan every number article
in the provided range (if specified).

I hope it answers your question.

Here is the relevant excerpt from RFC 3977 for GROUP:

   When a valid group is selected by means of this command, the
   currently selected newsgroup MUST be set to that group, and the
   current article number MUST be set to the first article in the group
   (this applies even if the group is already the currently selected
   newsgroup).  If an empty newsgroup is selected, the current article
   number is made invalid.  If an invalid group is specified, the
   currently selected newsgroup and current article number MUST NOT be
   changed.

-- 
Julien ÉLIE

« Ne parlez jamais de vous, ni en bien, car on ne vous
  croirait pas, ni en mal car on ne vous croirait que trop. » (Confucius)

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 30 Dec 2009 12:01:18 +0000

Julien LIE said:
> Interesting.  It is indeed how it is implemented in INN 2.5.2

The basic model here is:

* Articles are numbered from 1 to some limit X - the next arriving article
will be given a number Y greater than X, after which the limit will become
Y.
* There are two other numbers called LWM and HWM. HWM can increase or
decrease; LWM can increase but never decrease.
* All existing article numbers lie between LWM and HWMN inclusive.
* Articles can be removed and/or reinstated at any time, and LWM and HWM
changed at any time, providing that the above rules are obeyed.
* The GROUP command returns LWM and HWM, and sets the "current article
number" ("CAN") to LWM.
* The NEXT command sets CAN to the lowest number which is greater than CAN
and corresponds to an existing article at that moment (note this could be
greater than the HWM returned by GROUP if a new article has arrived).
* The LAST command sets CAN to the highest number which is less than CAN
and corresponds to an existing article at that moment.

Because articles arrive, are removed, and are reinstated, NEXT then LAST
might not take you back to where you are. Similarly for other sequences.
Similarly, because article LWM might have been removed, GROUP might not
leave CAN referring to a valid article.

[...]
>   If the current article

> (and therefore returning 420)?

Here, "invalid" is a special value for CAN. CAN is set to "invalid" at the
start of the session and when selectsing an empty newsgroup (but is not
altered following an unsuccessful GROUP).

So you get a 420 if you do NEXT/LAST before GROUP, or in an empty group.
You get 421 when NEXT reaches the end of the numbers. Look at the last two
examples for NEXT.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 30 Dec 2009 12:03:46 +0000

> My feeling exactly.  The article pointer can't be manipulated while invalid according to spec, and it's only ever valid if set explicitly.  So how do you find the first valid article number without…

It's set explicitly by GROUP on a valid non-empty group.

Contrary to my previous messagess, GROUP doesn't set it to LWM but to the
lowest valid article number.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 30 Dec 2009 12:06:12 +0000

> (allowing a possible reinstatement).

This is wrong.

Note that it does *not* say "the reported low water mark".

> (because it does not exist).

Correct.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 30 Dec 2009 12:07:59 +0000

> * The GROUP command returns LWM and HWM, and sets the "current article

This was wrong. It sets CAN to the lowest number which corresponds to an
existing article at that moment, which might be greater than LWM or equal
to LWM.

> leave CAN referring to a valid article.

That's wrong. If the group is not empty, GROUP, NEXT, and LAST must all
leave CAN referring to a valid article.

---

From: Julien ÉLIE <[email-masked]>
Date: Wed, 30 Dec 2009 14:23:46 +0100

Hi Clive,

> You get 421 when NEXT reaches the end of the numbers. Look at the last two

If we do NEXT/LAST before GROUP, isn't it 412?

RFC 3977:

   If the current article number is already the first article of the
   newsgroup, a 422 response MUST be returned.  If the current article
   number is invalid, a 420 response MUST be returned.  If the currently
   selected newsgroup is invalid, a 412 response MUST be returned.

   Example of an attempt to retrieve an article without having selected
   a group (via the GROUP command) first:

      [Assumes currently selected newsgroup is invalid.]
      [C] NEXT
      [S] 412 no newsgroup selected

Maybe the text should be amended to say that 420 is when the current article
number is invalid and the selected newsgroup is valid.  Otherwise, there is
a discrepancy.

-- 
Julien ÉLIE

« Les amis de la vérité sont ceux qui la cherchent,
  et non ceux qui se vantent de l'avoir trouvée. » (Condorcet)

---

From: Julien ÉLIE <[email-masked]>
Date: Wed, 30 Dec 2009 14:31:17 +0100

Hi Clive,

> lowest valid article number.

I still do not understand.

Section 6.1.1.2 of RFC 3977 clearly states for GROUP:

   The successful selection response will return the article numbers of
   the first and last articles in the group at the moment of selection
   (these numbers are referred to as the "reported low water mark" and
   the "reported high water mark") and an estimate of the number of
   articles in the group currently available.

   [...]

   newsgroup).

The first article in the group is LWM.

So in fact, you say that RFC 3977 is to be amended so that LWM is the
lowest valid article number?  But what for reinstatement?

Otherwise, the notion of "first article" is wrong in RFC 3977 and the
paragraph should be amended.

I am more and more confused...

-- 
Julien ÉLIE

« Nigro notanda lapillo. » (Catulle)

---

From: Julien ÉLIE <[email-masked]>
Date: Wed, 30 Dec 2009 14:35:54 +0100

Hi Clive,

> Note that it does *not* say "the reported low water mark".

Section 6.1.1.2 of RFC 3977 for GROUP, just before what you quote:

INN does exactly that.  The first article in the group *is* the "reported
low water mark" in the terminology of RFC 3977.

-- 
Julien ÉLIE

« Partout dans le monde, quand un pays touche le fond, il
  finit par remonter... Nous, les Algériens, quand on arrive
  au fond, on creuse... » (Fellag)

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 30 Dec 2009 14:21:46 +0000

> If we do NEXT/LAST before GROUP, isn't it 412?

Yes. Mea culpa. (Not enough sleep.)

> number is invalid and the selected newsgroup is valid.

Maybe, though a little thought shows that the other reading would not only
contradict the examples, it would also make 412 impossible in this context.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 30 Dec 2009 14:24:40 +0000

[...]
> I am more and more confused...

So am I. I need to go back and re-read what I wrote all those years ago.

---

From: Julien ÉLIE <[email-masked]>
Date: Wed, 30 Dec 2009 17:44:27 +0100

Hi Clive,

> I need to go back and re-read what I wrote all those years ago.

In case it could help, I found out "New wording on article numbers"
    <http://lists.eyrie.org/pipermail/ietf-nntp/1996-December/thread.html#365>
and "LISTGROUP":
    <http://lists.eyrie.org/pipermail/ietf-nntp/2005-April/thread.html#5258>

but no mention of the notion of "first article", except that for
LISTGROUP, there is an extensive discussion on whether the article
number should be set to the first existing number provided in the
optional range.

I was hoping to find a discussion about GROUP itself but did not
manage to.

-- 
Julien ÉLIE

« Tempora si fuerint nubila, solus eris. » (Ovide)

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Thu, 31 Dec 2009 05:36:11 +0000

Is there any chance we (nntp) can have some sort of teleconference?

> lowest valid article number?  But what for reinstatement?
No, I believe he simply means that LWM has no significance whatsoever other than it being LWM.  It is the minimum possible article number; it need not be valid.  This makes perfect sense, otherwise NEXT and LAST are basically useless.

> I am more and more confused...

I think it could be clearer, but it's only just starting to make sense to me too. :-)

But, and I hate to be a nuisance about this, my question is still not quite answered: if I cannot manipulate the article pointer while an invalid article number is the next to be fetched, how can I really use NEXT?  I have to target articles in ascending order till I find the first valid one by number, then I can use NEXT, is this not right?  I don't begin at the start of the group.

Cheers,
Sabahattin

---

From: Russ Allbery <[email-masked]>
Date: Wed, 30 Dec 2009 21:44:58 -0800

Sabahattin Gucukoglu <[email-masked]> writes:

> But, and I hate to be a nuisance about this, my question is still not
> quite answered: if I cannot manipulate the article pointer while an
> invalid article number is the next to be fetched, how can I really use
> NEXT?

Unless the group is empty, the article number is guaranteed to be valid
when you enter a group with GROUP.  NEXT sets the article number to the
next valid article.  It will skip over any invalid article numbers for
you.  So if you do:

GROUP example.test
ARTICLE
NEXT
ARTICLE
NEXT
[...]

until you get a 421 error from NEXT, you will traverse every article in
the group.  You may still get a 420 error from ARTICLE if the currently
selected article disappears between NEXT and the ARTICLE command, but NEXT
should still work.  I don't believe NEXT can return 420 unless the group
was empty when the GROUP command was issued.

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Thu, 31 Dec 2009 08:08:40 +0000

> was empty when the GROUP command was issued.

Right, this is fine.  But the question was really, how do I initialise the pointer to something not the beginning of the group?  I cannot use NEXT until I hit on a valid article.  Does this not mean that I will have to find it by trial and error with article numbers?

So, I want to retrieve articles beginning from 1000 in example.group.  I would do:
GROUP example.group
ARTICLE 1000
ARTICLE 1001
...
until I get a working article (not 423)
and then I can proceed to use NEXT.

A coinciding question: if I use the ARTICLE command specifying an invalid article number, has the state of the server changed so that NEXT will now no longer work, or will it work as it did before I issued ARTICLE, assuming a valid article before (as on GROUP)?

Cheers,
Sabahattin

---

From: Russ Allbery <[email-masked]>
Date: Thu, 31 Dec 2009 00:27:09 -0800

Sabahattin Gucukoglu <[email-masked]> writes:

> Right, this is fine.  But the question was really, how do I initialise
> the pointer to something not the beginning of the group?

ARTICLE <number> or STAT <number>.

> I cannot use NEXT until I hit on a valid article.  Does this not mean
> that I will have to find it by trial and error with article numbers?

Trial and error is an odd way to describe it, since that sounds like
you're trying article numbers at random.  You start with one greater than
the last article that you read and try each number in sequence from there
to the high-water mark until you get a successful reply.  From that point
forward, you can use NEXT.  (This is, in essence, what NEXT does
internally in the server.)

Note that if you don't want to retrieve the article automatically, just
simulate what NEXT would do by selecting it, you can use STAT instead.

Correct.

> A coinciding question: if I use the ARTICLE command specifying an
> invalid article number, has the state of the server changed so that NEXT
> will now no longer work, or will it work as it did before I issued
> ARTICLE, assuming a valid article before (as on GROUP)?

   The server MUST NOT change the current article number except when an
   article number argument was provided and the article exists; in
   particular, it MUST NOT change it following an unsuccessful response.

Nothing about an unsuccessful ARTICLE command changes state in the server,
so if NEXT was working beforehand, it's still working afterwards.