On Mon, Feb 07, 2005 at 04:49:21PM +0100, Urs Janßen wrote: > > > LIST EXTENSION isn't specified by an RFC and it looks like that it > > > will never be officially implemented (CAPABILITIES might be it's > > > "replacement"). so officiall we can't blame the netscape server, but > > > usualy INN is regarded as reference implementation so I'd say that > > > expecting an 202 answer is the right thing and the server is > > > 'buggy'. there is still tins problem with unexpected multiline > > > responses and getting out of sync... > > OK. However, in the absence of a specification by an RFC, tin should > > support the Netscape answer. > there is a draft wich 'defines' the responsecode: > draft-ietf-nntpext-base-24.txt, section 5.3 > > | 5.3 LIST EXTENSIONS > | 5.3.1 Usage > | This command is optional. > | Syntax > | LIST EXTENSIONS > | Responses > | 202 Extension list follows (multiline) > | 402 Server has no extensions > > but as mentioned above the command might be replaced with the new > CAPABILITIES command which might have a different returncode (looks > like it will be 101 for success as stated in > draft-ietf-nntpext-authinfo-06.txt and > draft-ietf-nntpext-streaming-03.txt).
and in the upcomming draft-ietf-nntpext-base-25.txt draft which is not yet released, but a preview is available at <http://www.davros.org/nntp-texts/draft25.txt> anyway, attached is a diff against a plain tin-1.7.7er source which should work around that problem and which implements basic "CAPABILITIES" support (which is tried first, but AFAIK there is no server which currently supports it, so you might want to comment it out (#if 1 -> #if 0)). if you (or Marco) doen't like this hack I suggest to simply remove the call to check_extensions() (at least from the tin versions in stable). urs -- "Only whimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;)" - Linus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
