Closed Bug 133792 Opened 22 years ago Closed 22 years ago

URL news: scheme used incorrectly

Categories

(MailNews Core :: Networking: NNTP, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED INVALID

People

(Reporter: braden, Assigned: sspitzer)

References

Details

Internally, news: URLs include a hostname|IP + port number. This is not how it
is describedin RFC 1738.

From RFC 1738:

  3.6. NEWS
  
  The news URL scheme is used to refer to either news groups or individual
  articles of USENET news, as specified in RFC 1036.
  
  A news URL takes one of two forms:
  
  news:<newsgroup-name>
  news:<message-id>
  
  A <newsgroup-name> is a period-delimited hierarchical name, such as
  "comp.infosystems.www.misc". A <message-id> corresponds to the Message-ID of
  section 2.1.5 of RFC 1036, without the enclosing "<" and ">"; it takes the
  form <unique>@<full_domain_name>. A message identifier may be distinguished
  from a news group name by the presence of the commercial at "@" character. No
  additional characters are reserved within the components of a news URL.
  
  If <newsgroup-name> is "*" (as in <URL:news:*>), it is used to refer to "all
  available news groups".
  
  The news URLs are unusual in that by themselves, they do not contain
  sufficient information to locate a single resource, but, rather, are
  location-independent.
-> mailnews
Assignee: new-network-bugs → sspitzer
Component: Networking → Networking - News
Product: Browser → MailNews
QA Contact: benc → stephend
Summary: "news" URLs used incorrectly → URL news: scheme used incorrectly
see my comments on bug 130089 about this
Blocks: 133793
INVALID, pursuant to Jeremy Dolan's comments in bug 130089.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
verified
Status: RESOLVED → VERIFIED
I am not really convinced. As it says there, this is a draft which was never
published. But why not use nntp when this is strictly correct?

pi
Mailnews owns this. At the URL parsing level, I have my meta bug, where we can
set the record straight for scheme correctness.

I agree, intellectually, that news should work this way. The decision to make
news non CISS (news://) while simulatenously claiming "it's not really a URN",
has proven to be a mistake.

Trying to move that draft to an RFC would be ideal...
Boris: Probably because it's more convenient (I'm guessing) to use message IDs
than to use article numbers. But I think it's a moot point. The genie's already
out of the bottle on this one, and at least there *is* a workable spec--even if
it's just a draft. The Gilman draft specifies "news:" URLs that are a superset
of those specified by RFC 1738; so supporting the Gilman form won't break
support for RFC 1738 "news:" URLs. Problem is, support for *both* forms is
broken right now (bug 133793).

Ben: I think you mean "URI", not "URN". And "news:" *are* URIs, in both their
RFC 1738 and Gilman forms; to claim otherwise is not simply a mistake, it
blatantly disregards reality.

I strongly suspect hopes that the Gilman draft will ever become an RFC are in
vain. But that's okay; I don't think it really matters.

What's "CISS"?
Braden: I was thinking out-loud about the following comment from RFC 1630:

Among URLs the "news" URLs are anomalous in that they are
      location-independent. They are unsuitable as URN candidates
      because the NNTP architecture relies on the expiry of articles and
      therefore a small number of articles being available at any time.
      When a news: URL is quoted, the assumption is that the reader will
      fetch the article or group from his or her local news host.  News
      host names are NOT part of news URLs.

This "we are still trying to make URN's a meaninful concept", in my mind is
where the news/nntp problems began. Considering the overall strength of RFC 1630
and 1738, this is the only part of the document where you read it and go "wow,
history really proved that wrong."
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.