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

From: Sabahattin Gucukoglu <[email-masked]>
Date: Fri, 1 Jan 2010 16:15:12 +0000

On 31 Dec 2009, at 08:27, Russ Allbery wrote:
> 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.)

I guess I meant that I would have to keep trying until I got a non-error response.  Yes, that's what's happening, thanks.  I have come away from this with the definite impression that NNTP clients should be very tolerant indeed of error conditions.

>> 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.

If that's the case, then the only use for code 420 is after commands following entering an empty group, since it's impossible to invalidate the article pointer by any other means.

Happy new year, everybody!

Cheers,
Sabahattin

---

From: Julien ÉLIE <[email-masked]>
Date: Fri, 1 Jan 2010 18:25:12 +0100

Hi Sabahattin,

> the only use for code 420 is after commands following entering
> an empty group, since it's impossible to invalidate the article
> pointer by any other means.

ARTICLE
220 100 <example@mid> article follows
[...]

Suppose you wait for two minutes and the article is cancelled
during that period, and you issue again the command:

ARTICLE
420 No current article selected

The article pointer has been made invalid (though it still points
to 100).

It is the same thing that happens when you send a GROUP command
and the first valid article in the newsgroup is not the reported
low water mark.  The article pointer points to the reported low
water mark, and is therefore invalid.  You have a 420 error.
NEXT will give you, if the group is not empty, the first valid
article in the newsgroup.

It is how it currently works, at least with INN.  But it should
be clarified in RFC 3977.

** Note that maybe INN is wrong! **

One interesting thing I have just discovered is that the NNTP
reference implementation returns the FIRST VALID ARTICLE when
ARTICLE/BODY/HEAD/STAT is sent!

>From nntp-1.5.12.1:

        while (open_valid_art(artbuf, art_id) == NULL) {
                if (argc > 1) {
                        printf("%d Invalid article number: %s.\r\n",
                                ERR_NOARTIG, artbuf);
                        (void) fflush(stdout);
                        return;
                } else {
                        if (++art_ptr >= num_arts) {
                                printf("%d Invalid article number.\r\n",
                                        ERR_NOARTIG);
                                (void) fflush(stdout);
                                return;
                        }
                        (void) sprintf(artbuf, "%d", art_array[art_ptr]);
                }
        }

Note the ++art_ptr, and while it does not exceed the high water mark,
it will grow until an article is found!

Is it how the NNTP protocol is supposed to work?
If that's the case, then RFC 3977 should be amended to mention that...

Incidentally, ARTICLE answers 423 (and not 420) in the NNTP reference
implementation even though no argument is given to ARTICLE.

-- 
Julien ÉLIE

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

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Fri, 1 Jan 2010 18:02:21 +0000

> The article pointer has been made invalid (though it still points

Doh!  Yes, sorry, of course, that's right.  My brain is clearly not working today. :-)

> ** Note that maybe INN is wrong! **

I thought we'd "Established" that the article pointer is valid on group entry.  It is wrong for NEXT to operate when the article number is invalid.  The only way inn can hope to be in conformance is if the low watermark *just so happens* to be the first article, which of course is fine.  Reinstatement is then some sort of implementation detail which I can't think of just now. :-)

Cheers,
Sabahattin

---

From: Russ Allbery <[email-masked]>
Date: Fri, 01 Jan 2010 11:13:04 -0800

Julien ÉLIE <[email-masked]> writes:

> It is the same thing that happens when you send a GROUP command and the
> first valid article in the newsgroup is not the reported low water mark.
> The article pointer points to the reported low water mark, and is
> therefore invalid.

This shouldn't happen.  GROUP is supposed to find the first valid article
on entry.  (The article may become invalid later, of course.)  You should
only ever get an invalid article number immediately after GROUP if the
group is actually empty.

> One interesting thing I have just discovered is that the NNTP reference
> implementation returns the FIRST VALID ARTICLE when

> it will grow until an article is found!

That's intriguing.

> If that's the case, then RFC 3977 should be amended to mention that...

Well, it isn't what we standardized, so changing it would require changing
the protocol.  I suspect that at this point it's better to go with what we
standardized, even if that means that reference NNTP isn't compatible in
that one case.

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 5 Jan 2010 11:41:53 GMT

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>The news client is allowed to assume that no articles below the reported
>low water mark will ever reappear, which is semantically equivalent to
>saying that the low water mark will never decrease if the low water mark
>is actually meaningful.  The harm (clients thinking articles no longer
>exist on the server that actually do) doesn't apply in this situation
>since the inconsistency would be due to the LIST ACTIVE command lagging,
>and those articles wouldn't actually be accessible.

OK, so if on some distributed implementation the "official" active list
lags behind the truth, nobody is going to suffer any consequences, so long
as the "truth" eventually prevails (i.e. no articles in the disputed
region ever actually get reinstated). So any errata or advice we might
issue should be in the direction of allowing that state of affairs to
remain. Not that I am suggesting any erratum needs to be issued at this
point in time.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131            Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: Julien ÉLIE <[email-masked]>
Date: Wed, 6 Jan 2010 19:35:20 +0100

Hi Russ,

>>   Note that a previously valid article number MAY become invalid if the
>>   article has been removed.  A previously invalid article number MAY
>>   become valid if the article has been reinstated, but this article
>>   number MUST be no less than the reported low water mark for that
>>   group.
>>
>> The validity of the pointer MAY change.
>
> I wonder if we should file an erratum against that paragraph suggesting a
> rewording to use another word than invalid.  Although that paragraph does
> talk about the validity of the article number, not the validity of the
> current article pointer, so there is a subtle distinction.  But I think
> it's too subtle to be clear on a first reading.
>
> I suspect s/invalid/unavailable/ and s/valid/available/ would still be
> fairly clear and avoid the ambiguity.

Yes, I think it would be useful to file an erratum.
Even though it is rejected, it will be reviewed when a successor, if any,
to RFC 3977 comes.

>> I think the whole point is that after entering a non-empty group, 420 is
>> not a valid answer to ARTICLE without argument.  It should have been 423
>> as it was the case in RFC 977.
>
> Well, somewhat more precisely, 420 is only a valid answer to ARTICLE
> without an argument if the group was empty at the time of the GROUP
> command.  If the group was not empty but the current article is
> unavailable, 423 should be used instead.

It is indeed the explained behaviour:

   If the argument is a message-id and no such article exists, a 430
   response MUST be returned.  If the argument is a number or is omitted
   and the currently selected newsgroup is invalid, a 412 response MUST
   be returned.  If the argument is a number and that article does not
   exist in the currently selected newsgroup, a 423 response MUST be
   returned.  If the argument is omitted and the current article number
   is invalid, a 420 response MUST be returned.

We do not know the answer to give when the argument is omitted and the
article does not exist in the currently selected newsgroup!

>> And it is also what is implemented in the NNTP reference implementation,
>> INN, and probably other news servers.
>
> I'm almost tempted to propose an erratum for this, but changing a return
> code is probably more than we really should do in an erratum.

Well, I think that would not change the code at all.  The code is
currently *unspecified* in RFC 3977!

So the erratum would basically just mention the code to use.  And this
code is 423.

-- 
Julien ÉLIE

« Medicus dedit qui temporis morbo curam,
  Is plus remedii quam cutis sector dedit. »

---

From: Russ Allbery <[email-masked]>
Date: Wed, 06 Jan 2010 11:14:25 -0800

>>> And it is also what is implemented in the NNTP reference
>>> implementation, INN, and probably other news servers.
>>

> So the erratum would basically just mention the code to use.  And this

Hm, that's a very interesting point.  Clive, what do you think?

---

From: Julien ÉLIE <[email-masked]>
Date: Sun, 10 Jan 2010 11:55:49 +0100

Hi Russ,

> there's an edge case here so we have to be careful about reading.  LAST
> returns 420 iff the article number is invalid, not just if the group is
> empty.  If you enter a group with one article, and that article is then
> cancelled (making the group empty), LAST should still return 422.

Yes.

I have just re-read the whole Section 6 about articles and the wording
in LAST about that edge-case is inconsistent.

GROUP defines the "first article in the group at the moment of selection"
as the "reported low water mark".  I'm OK with that.

But LAST uses a different wording:

   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.  In
   all three cases, the currently selected newsgroup and current article
   number MUST NOT be altered.

It is NOT the *first* article here, for 422.  I suggest to reword the
sentence this way:

   If the current article number is already lower or equal to the lowest
   existing article number (if any) in the newsgroup, a 422 response MUST
   be returned.

It will fix the consistency of the terminology and also deal with the
edge-case you mention.  Same for NEXT.

-- 
Julien ÉLIE

« Rubor, tumor, dolor, calor et functio laesa. »

---

From: Russ Allbery <[email-masked]>
Date: Sun, 10 Jan 2010 10:24:05 -0800

> edge-case you mention.  Same for NEXT.

Shouldn't we go ahead and use the same terminology?  Something like:

    If the current article number is invalid, a 420 response MUST be
    returned.  If the current article number is equal to or lower than the
    reported low water mark, a 422 reponse MUST be returned.  [...]

This also reverses the order so that it's clearer that an invalid article
number takes precedence in determining the return code.

---

From: Julien ÉLIE <[email-masked]>
Date: Sun, 10 Jan 2010 19:56:55 +0100

Hi Russ,

> number takes precedence in determining the return code.

The change of order is indeed better.

With the wording using the low water mark, I have doubts whether people
won't get confused.  It implies that the low water mark is moving without
actually being *reported* (after GROUP, the server says 12 so it is the
reported low water mark; and if article 12 is cancelled, then the low
water mark is 13 but the server does not mention it to the client).

Maybe that's OK to use "reported low water mark" even in that situation,
but it is something that is not done elsewhere in RFC 3977.

Couldn't we mention that it is the reported low water mark at the instant
of the execution of the command?

But I believe there is a major issue then:  it breaks the as-if principle
because we will end up with something unspecified for news servers that
cannot cope up in real time with the low water mark exactly matching
the first existing article in a newsgroup...

reported low water mark = 12
first existing article number = 13

GROUP -> current article number = 12
ARTICLE -> absent (423 response code)
NEXT -> current article number = 13
LAST -> ??

I think it should really be the "lowest existing article number"...

-- 
Julien ÉLIE

« Il vaut mieux un tapis persan volé qu'un tapis volant percé ! » (Astérix)

---

From: Russ Allbery <[email-masked]>
Date: Sun, 10 Jan 2010 11:15:59 -0800

> water mark is 13 but the server does not mention it to the client).

Oh, yes, that's the bit that I was missing.  Good point.  How about:

    If there are no articles available with an article number lower than
    the current article number, a 422 response MUST be returned.

That makes it slightly more concrete.  What we're after is whether there
are any articles to meaningfully return, and comparisons of article
numbers are just a means to get to that end.

Ideally, we would have defined available somewhere as "retrievable by
ARTICLE."  I suppose I'm introducing the term "available" and your wording
above is introducing the term "lowest existing article number" and it
depends on which one seems clearer.

I think the thing that was giving me pause about your proposed wording was
that it sounds a little like "lowest existing article number" might mean
something different than "number of the lowest existing article."

---

From: Julien ÉLIE <[email-masked]>
Date: Sun, 10 Jan 2010 20:50:53 +0100

Hi Russ,

>    the current article number, a 422 response MUST be returned.

That's nice.  However, is it enough precise regarding the case where
the current article number is the first article?
"lower than" may mean (abusively -- or translated into other languages)
"lower than or equal to".

> something different than "number of the lowest existing article."

The fact is that "lowest existing article number" (and the "next article")
already exists :)

See NEXT:

6.1.4.2.  Description

   If the currently selected newsgroup is valid, the current article
   number MUST be set to the next article in that newsgroup (that is,
   the lowest existing article number greater 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.
   No article text is sent in response to this command.

And of course, LAST defines the "highest existing article number"
(and the "previous article").

-- 
Julien ÉLIE

---

From: Russ Allbery <[email-masked]>
Date: Sun, 10 Jan 2010 13:11:39 -0800

> "lower than or equal to".

Yes, it should be lower than or equal to, indeed.

> And of course, LAST defines the "highest existing article number" (and
> the "previous article").

Oh!  Okay.  Then I think you've convinced me your wording is the best,
since we're reusing an existing term.

---

From: Julien ÉLIE <[email-masked]>
Date: Thu, 14 Jan 2010 23:35:26 +0100

Hi Russ,

> since we're reusing an existing term.

I have since found out something better because my wording was unclear when
the current article number is valid and the newsgroup empty (after GROUP
was sent):

LAST defines the notion of "previous article":

   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.
   No article text is sent in response to this command.

So the new suggested wording is:

   If the currently selected newsgroup is invalid, a 412 response MUST
   be returned.  If the currently selected newsgroup is valid but the
   current article number is invalid, a 420 response MUST be returned.
   If the current article number is valid and there is no previous article
   in the currently selected newsgroup, a 422 response MUST be returned.
   In all three cases, the currently selected newsgroup and current article
   number MUST NOT be altered.

We take everything into account, and in the right order for 412/420/422.
(Just suggested as an erratum.)

-- 
Julien ÉLIE

« Un dictionnaire est comme une montre ; il vaut mieux en avoir un
  que pas du tout, mais le meilleur n'est jamais tout à fait exact. »
  (Georges-Bernard Shaw)

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 15 Jan 2010 11:04:32 +0000

Firstly, my apologies for not replying to this thread for so long. I have
been reading postings, but haven't had time to sit down and think things
through.

I had misremembered some stuff and, as a result, have managed to introduce
some red herrings into this whole thread. So let's start again.

When you enter a group, the reported low and high water marks must
represent the first and last valid articles in that group. If you reissue
the GROUP command, the low water mark can increase, but it can't decrease.
The server must remember this fact and, if an article is reinstated, *not*
report it to you during this session. So:

    GROUP x.y
    211 5 100 104 x.y
    (articles 100 to 104 exist)
    (article 100 is now deleted)
    GROUP x.y
    211 4 101 104 x.y
    (article 100 is now reinstated)
    GROUP x.y
    211 4 101 104 x.y

However, if you disconnect from the server and then reconnect, it is
permitted for article 100 to reappear and the low water mark to decrease
again.

Having said that, that permission was only intended as a concession to
clustered systems which can't guarantee to keep everything in
synchronization. The intention was that there was a "master" representation
of the group that is replicated - with delay - on the various machines of
the cluster. Once the lowest numbered article in the master representation
was deleted, it couldn't be reinstated again. Reinstatement was thought to
be a rare circumstance (it requires a cancel to be cancelled, so to speak,
or expiry to be undone), so this isn't an issue. Most examples of
"reinstatment" would simply be the cluster catching up. If a very old
article genuinely gets reinstated, it can be given a new number.

This means that, unless the group is empty, the initial article number is
valid. If the group is empty, the article number is set to the special
"invalid" value.

[Russ]
> I don't believe NEXT can return 420 unless the group
> was empty when the GROUP command was issued.

[Sahahattin]
> If that's the case, then the only use for code 420 is after commands
> following entering an empty group, since it's impossible to invalidate
> the article pointer by any other means.

Those are both certainly what we meant when we wrote the wording.

-- 
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: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 15 Jan 2010 11:34:45 +0000

> 420 No current article selected

This is a corner case that we don't seem to have thought of.

If you used the explicit number:

    ARTICLE
    220 100 <example@mid> article follows
    (article 100 is deleted)
    ARTICLE 100
    423 No article with that number

it's clear that the correct response is 423.

> The article pointer has been made invalid (though it still points

No, the article pointer is still valid (the term "invalid article pointer"
has a special meaning.

In general, with commands like ARTICLE, the intent is that the form without
an argument is identical to the form with an argument, with the current
article number used as the argument.

So I would say that, in your example, 423 is the correct response. The 420
response is *only* for the case that you entered an empty group and
therefore GROUP wasn't able to assign an initial number.

Since 0 isn't a valid article number, you could think of "invalid article
pointer" as being "article number 0". Then:

    GROUP x.y
    211 5 100 104 x.y
    ARTICLE 100
    220 100 <example@mid> article follows
    (article 100 is deleted)
    ARTICLE
    (is equivalent to "ARTICLE 100")
    423 No article with that number

    GROUP p.q
    211 0 100 99 x.y
    (the article number is set to 0)
    ARTICLE
    (is equivalent to "ARTICLE 0")
    420 No current article selected

The wording at the end of 6.2.1.2 should say:

| If the argument is a number and that article does not
| exist in the currently selected newsgroup,
+ or the argument is omitted and the article with the
+ current article number does not exist in the currently
+ selected newsgroup (because it has been removed since
+ the current article number was set to it),
| a 423 response MUST be returned.

and the 423 response needs adding to the third form.

> low water mark.

This can't happen.

> ARTICLE/BODY/HEAD/STAT is sent!

This is absolutely and clearly wrong.

There's one problem with the wording of 3977. In 6.2.1.2 we wrote:

|  Note that a previously valid article number MAY become invalid if the
|  article has been removed.  A previously invalid article number MAY
|  become valid if the article has been reinstated, but this article
|  number MUST be no less than the reported low water mark for that
|  group.

This is misusing the term "invalid article number". The wording should have
been something like:

|  Note that a previously valid article number MAY cease to refer to any
|  article if that article has been removed, in which case use of that
|  article number (explicitly or implicitly) will cause a 423 response. A
|  previously removed article may be reinstated (but its number MUST be no
|  less than the reported low water mark for that group), in which case
|  that number will once again refer to that article.

[Julien on LAST]

>    number is invalid, a 420 response MUST be returned.
>
> I think the last sentence should be "If the currently selected newsgroup
> is empty, a 420 response MUST be returned."

The problem with this is that there are two ways for a group to be empty.
(1) The group was empty on entry. The current article pointer should have
the special "invalid" value, and LAST et.al. return 420.
(2) All the articles in the group were deleted after we entered. In this
case, the correct response to LAST is 422, because the current article
pointer is a valid number.

Note that the client can, in principle, track the value of the current
article pointer:
- GROUP sets it to either the low water mark or "invalid".
- NEXT and LAST either return the new value, or the value remains
unchanged.
- ARTICLE et.al. with a numeric argument either set it to that value if
they succeed, or leave it unchanged if they fail.
- ARTICLE et.al. with a message-ID, or with no argument, never change it.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 15 Jan 2010 11:35:15 +0000

Julien LIE said:
> Incidentally, if the currently selected newsgroup is empty and an article
> arrives in it, we cannot retrieve it without reselecting the newsgroup.
> ARTICLE will answer 420 (no valid pointer).  So will LAST.

Correct.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 15 Jan 2010 11:55:33 +0000

> Hm, that's a very interesting point.  Clive, what do you think?

[Catching up]

I agree with Julien, and I think we should submit an erratum covering all
these points. I think one of my previous messages today gives all the
wording changes needed.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 15 Jan 2010 12:02:27 +0000

>   number MUST NOT be altered.

This works for me. NEXT also needs a change:

    If the current article number is valid and there is no next article
    in the currently selected newsgroup, a 421 response ...

with the remaining wording left unchanged.

---

From: Julien ÉLIE <[email-masked]>
Date: Fri, 15 Jan 2010 23:16:39 +0100

Hi Clive,

> therefore GROUP wasn't able to assign an initial number.

OK, thanks.
What worries me most is that RFC 3977 explicitly does not allow 423 to be
returned for the third form of ARTICLE/HEAD/BODY/STAT, HDR and OVER.

It for instance led to the fact that INN 2.5.0 and INN 2.5.1 used 420
instead of 423 for HDR and OVER.  And maybe other servers (possibly new
implementations) did the same.  Besides, clients may also not expect 423
here...
And for the future, if someone implements RFC 3977 without looking at its
errata, then he will probably get it also wrong.  Not only it will lead to
broken HDR and OVER implementations regarding 420/423 but the issue will
also be present for ARTICLE/HEAD/BODY/STAT.
It is not a big deal but, still.

(Note that INN 2.5.0 and INN 2.5.1 are right for ARTICLE/HEAD/BODY/STAT
as they still use the historic value.
And INN 2.5.2 will use the right 423 response code for HDR and OVER.)

>> and the first valid article in the newsgroup is not the reported

And what for LIST ACTIVE?
It uses the same definition of water marks.
Therefore, according to RFC 3977, LIST ACTIVE is also required to
return the real values for the first and last valid articles in
every newsgroup.
Well, this does not always happen!  (Hopefully the as-if principle
mentioned by Russ exists to allow servers not to cope with that
requirement.)

> |  that number will once again refer to that article.

OK.  Could you please open an erratum for it?
(and use two spaces after the end of the first period, when submitting it)

-- 
Julien ÉLIE

« Omnia uincit Amor et nos cedamus Amori. » (Virgile)

---

From: Julien ÉLIE <[email-masked]>
Date: Fri, 15 Jan 2010 23:17:50 +0100

Hi Clive,

> with the remaining wording left unchanged.

Yes.  I did it yesterday:
    http://www.rfc-editor.org/errata_search.php?eid=2003

> these points.  I think one of my previous messages today gives all the

Also done (a bit too earlier) yesterday:
    http://www.rfc-editor.org/errata_search.php?eid=2004

Your wording is better than what I suggested.  If you want to change it,
please reply to the erratum mail of which you are in copy.  It will let
the RFC editor know what he should put.

-- 
Julien ÉLIE

---

From: Julien ÉLIE <[email-masked]>
Date: Fri, 22 Jan 2010 23:19:40 +0100

Hi Clive,

> This is absolutely and clearly wrong.

I see in the changelog of INN 2.4.0:

    Several other, more minor protocol issues have been fixed:  connections
    rejected due to the connection rate limiting in innd receive 400 replies
    instead of 504 or 505, and ARTICLE without an argument will always either
    retrieve the current article or return a 423 error, never advance the
    current article number to the next valid article.

So it happens that NNTP was originally designed to work that way:
when the current article pointer points to an article that is no longer
available, it advances to the next valid article in the group.

It is amusing.  I do not know how many news servers (if any) still do that.

-- 
Julien ÉLIE

« Boire du café empêche de dormir. Par contre, dormir empêche
  de boire du café. » (Philippe Geluck)