This project has moved and is read-only. For the latest updates, please go here.

Command parsing

May 28, 2010 at 6:12 PM
Do we need the dash and an explicit range to specify one message number? Allowing an implicit range of one would avoid a misleading error message. Example: xover 69185 423 no such article number in this group xover 69185-69185 224 overview information follows 69185 =?utf-8?B?UmU6IEdvb2dsZSB0b29sYmF At first I thought that this would explain why you didn't like dashes in Message-ID but that wouldn't matter because the syntax for using a Message-ID as a parameter requires that it be enclosed in angle brackets. This was observed on V08.
May 28, 2010 at 6:17 PM

Hi!

In RFC 2980 it is specified as:

The optional range argument may be any of the following:
* an article number
* an article number followed by a dash to indicate all following
* an article number followed by a dash followed by another article number

So why should I change the standard?

Which newsreader are you using?

Greetings
  Jochen

May 28, 2010 at 7:02 PM

Did you understand my example?   I think that  xover 69185  is an example of the first specification.  Evidently the bridge does not recognize it.   I didn't even bother trying the second syntax because the MS bridge never recognized it, though I had mentioned that deficiency when I first encountered it.  So, so far you're just following the MS bridge in supporting just the third most general, most specific, syntax.   I don't think this will be very important, just something for users to be aware of.   I would only expect to use it via telnet.   What was slightly amusing but very useful is that the MS bridge supported having a  <Message-ID>  as a parameter for XOVER.   E.g. that allows us to do backchaining by XOVER instead of having to use something more verbose such as ARTICLE which would actually allow that syntax by the RFC.

Thanks

Robert
---

May 28, 2010 at 10:22 PM

Hi Robert,

I solved this in the next release. Also it now supports XOVER n- and XOVER <messageId>

Greetings
  Jochen

May 30, 2010 at 1:37 PM
jkalmbach wrote:

I solved this in the next release. Also it now supports XOVER n- and XOVER <messageId>

 

XOVER <messageID> is not a valid command and MUST answer 501.

Julien

May 30, 2010 at 1:41 PM

A good client is never submitting this; a bad client is happy ;)

May 30, 2010 at 2:12 PM
jkalmbach wrote:

A good client is never submitting this; a bad client is happy ;)

And the server is broken.  Not RFC-compliant.

   An implementation is not compliant if it fails to satisfy one or more
of the MUST requirements for this protocol. An implementation that
satisfies all the MUST and all the SHOULD requirements for its
protocols is said to be "unconditionally compliant"; one that
satisfies all the MUST requirements but not all the SHOULD
requirements for NNTP is said to be "conditionally compliant".

 

May 30, 2010 at 2:30 PM
jkalmbach wrote:

I solved this in the next release. Also it now supports XOVER n- and XOVER <messageId>

 

Besides, I think you are confusing the two different NNTP commands XOVER and OVER.

The second one allows <messageID>.  The first one does not allow it.

 

Do you compare what you implement with what other news servers implement?  If you wish, you can try "telnet news.trigofacile.com 119" and see how it (INN) behaves with all these commands.  You can send "HELP" to see all the understood commands.  RFC 3977 + errata to RFC 3977 on rfc-editor.org should be followed.
In case you have any question about NNTP, do not hesitate to ask in the news.software.nntp newsgroup.

And please remember that ("obsolete") RFC 2980 is wrong at a few places regarding response codes.  See what Diablo or INN implement.  Especially when there is no article in the range...  (With what RFC 2980 mentions about that, Outlook Express and Windows Mail give an error message! -- and not with what news servers in the wild implement)

--
Julien ÉLIE

May 30, 2010 at 2:34 PM

Hi julius!

I am very pleased, that you test the NNTP server very well! You must remeber, that I took the NNTP server from an other project (http://spnews.codeplex.com/) and it seems that it is not fully implemented... therefor I will try to fix the problems.

Therefor I am very happy that you has brought up some issues! Keep going ;)

Greetings
  Jochen