ietf-nntp GROUP Responses (was: Commetns on draft-15.pdf)

Charles Lindsey chl at clw.cs.man.ac.uk
Tue Jan 1 04:00:19 PST 2002


In <yladvz5c4f.fsf at windlord.stanford.edu> Russ Allbery <rra at stanford.edu> writes:


>Charles Lindsey <chl at clw.cs.man.ac.uk> writes:

>> P19. S9.1.1.1.1 (GROUP Responses)
>> Some servers permit active file entries of the form
>> 	comp.bar 00003456 4567 y
>> 	comp.foo 00001234 2345 =comp.bar
>> in which the group comp.foo is "aliased" onto comp.bar (and the low/high
>> marks 00001234 and 2345 are actually redundant - see comp.bar for the true
>> marks). In that case, if you give
>> 	GROUP comp.foo
>> I would expect the response
>> 	211 1111 3456 4567 comp.bar

>Except that isn't actually how aliasing works in INN, and I don't think
>anyone else implements it.  Aliasing is *only* a set of instructions to
>the server for how to file new incoming articles; it doesn't actually do
>anything particularly useful for clients.  It would be nice, perhaps, to
>figure out something interesting and useful for it to do for article
>reading, but that belongs in an extension.

OK, but you haven't really answered the question.

AIUI, if you POST (or IHAVE) an article to comp.foo, INN stores it as if
it had been posted to comp.bar. Or does this only apply to IHAVE, with
POST rejecting with a 440 response?

But the interesting question is what happens if you try to read articles
from comp.foo, using GROUP + ARTICLE commands. You say "GROUP comp.foo",
and what response do you get?

Does it return 411? That would seem somewhat unhelpful.
Otherwise, it has to return 211, in which case what count, low water mark
and high water mark does it return?

CNews + model-NNTP used to give 211 with the count and water marks from
comp.bar, but still reporting the group as comp.foo (which I think was
unhelpful). When I was experimenting with mvgroup, I changed it to report
as comp.bar (since that was the group that had actually been entered).


>I disagree.  I don't think this discussion is ripe until someone actually
>defines an extension that does something sensible with aliasing, and even
>when someone does that I don't think it's clear that this is the right way
>of handling things.

I don't think anyone should be defining aliasing in detail at this point,
but that is no reason not to state what responses should be regarded as
legitimate in such seemingly bizarre situations. All I am saying is that
if you return a 211 with apparently working count and water marks, then it
would also be better to report the group that the server had actually made
current, whether or not that was the one you had asked for.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl at clw.cs.man.ac.uk      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



More information about the ietf-nntp mailing list