INN not RFC 977 conform
Klaus Mueller
RFC 977 by INN:
RFC 977:
> Certain status responses contain parameters such as numbers and
> names. The number and type of such parameters is fixed for each
> response code to simplify interpretation of the response.
>
> [...]
>
> 3.2.2. Responses
>
> 211 n f l s group selected
> (n = estimated number of articles in group,
> f = first article number in the group,
> l = last article number in the group,
> s = name of the group.)
>
Behaviour of INN (1.2) (our local campus server) but seems to be a feature
in INN 1.4 too:
> group news.software.nntp
> 211 60 2494 2709 news.software.nntp
> listgroup news.software.nntp
> 211 Article list follows
> 2494
> 2628
> [...]
> 2707
> 2708
> 2709
> .
You can see the group- and the listgroup-command generate the same response
code but the number and type of the parametes is different. listgroup
additionally responds with a multiple lines which could confuse a reader
relying on the one line response indicated by the 211-code.
It seems at the moment there is no reader to be confused but to me this is a
misfeature.
Bye
Klaus
--
Klaus M"uller (mue...@rbg.informatik.th-darmstadt.de)
IRC: netmage MUD: loren
William Bardwell
> number]
Shouldn't be a problem, clients are expected to know what command they
sent, and therefore the format of the response (there are a couple
other overlaped uses of response codes, although they aren't as
drastic as this (also not in standard... (like list <param> always
returns same ok code, but different stuff after that) ) There
really aren't enough codes to not overlap if people keep adding
extensions.
William Bardwell
wbardwel+@[cs.]cmu.edu
Rich Salz
The RFC can only describe valid responses to valid commands. Since
the listgorup command is not part of RFC 977, it can use any reply
code that it wants. It is safe to assume that a client that sends
the listgroup command knows how the response is coming back.
/r$