Mozilla appears not being able parse nttp:// URIs correctly. As per RFC1738 (sect. 3.7), a nntp URL take the form: nntp://<host>:<port>/<newsgroup-name>/<article-number> Mozilla do not handle the last part, the article-number as one might expect, but rather sees it as part of the newsgroup name. So, when requesting an URL like nntp://localhost/group/666, Mozilla interprets the groupname as group/666 and asks the user if he/she would like to subscribe to it, instead of what I'd expect, bring up the requested message in the browser, the same manner as Opera does. (btw, MSIE also has a broken nntp uri parser in an even worse manner.) IMHO, a full nntp: request should be handled at a browser level and don't be routed to the MailNews component at all, since what I actually am requesting is a document explicitly, not a news-server subscription request. Equal to if it were an full ftp:// request, I am not expecting to be directed to the index page if requesting ftp://host/path/foo.txt References <http://www.faqs.org/rfcs/rfc1738.html>

*** Bug 195875 has been marked as a duplicate of this bug. ***

I (humbly) disagree with the idea that the article should be viewed in the browser (a Usenet item is better viewed in the application dedicated to handle it). But more to the point, check bug 127357. There is a conflict possible here, unless there is a different handling of nntp:// and news:// URIs. The problem would be evident if the address is typed in the address bar of the browser: nntp://server/group/number would open the article in the browser while news://server/group/number would subscribe the server, open the group and show the article. I agree the expected result in that case would be to open the article in the browser. But I personaly never have typed a Usenet address in the address bar, short of testing the browser ;-) If the link is simply in the body of a web page and the user clicks on it then I think the result should be to call the news reader, in the same way a mailto: link fires up the associated mail application. A possible way out of that problem could be to offer a contextual menu on nntp and news links, to offer the alternative solution. For the record, note that RFC 2396 updates RFC 1738 (and RFC 1808).

sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.

Filter on "Nobody_NScomTLD_20080620"

The correct reference is now RFC 5538 at <http://www.rfc-editor.org/rfc/rfc5538.txt>.