Message-Id: <199408071919.MAA18708@nic.cerf.net>
Date: Sun, 07 Aug 1994 12:14:43 -0700
To: Larry Masinter <masinter@parc.xerox.com>
From: miked@CERF.NET (Michael A. Dolan)
Subject: Re: URL News/NNTP
At 08:12 PM 8/6/94 PDT, Larry Masinter wrote:
>> 5. (3.6, 3.7) Is the form
>> ....newsgroup/n1[-n2]
>> now illegal ? (where n1 and n2 are article number ranges as used in libwww).
>
>There are many forms used in libwww that are not part of this
>specification. The problem with news:group/n1[-n2] is that while group
>names and message IDs are not tied to a particular news server,
>message numbers are. Thus, while a web browser might know that
>"news:group/n1[-n2]" might refer to a particular news server, you
>can't reliably put such a URL in your hotlist.
I completely agree, but now we're into the realm of un-exposed URL syntax
that can be well-defined and useful to implementors, but generally unusable
by human authors. Following your argument above, then the use of article
numbers should be prohibited syntax since they cannot globally be resolved.
If you accept the concept of useful, unexposed URLs (such as news article
numbers), then why not define and permit *all* other forms in use today in
libwww ? Someone thought they were useful when they wrote the code.
>> 6. (3.6, 3.7) Apparently omitted is the form:
>> nntp://[host[:port]]/message-id
>> There are NNTP efficiencies that would make this very useful. Is there a
>> reason it was OK in news but not here ?
>
>I'm not sure, but I believe the point was that 'news:' URLs are
>adequate for the case when you have a message-ID.
News prohibits a hostname and thus is inadequate. Since this is a
valuable and useful syntax, and there is an analogous syntax for news,
it is puzzling why it is omitted from nntp.
>> 7. (3.6, 3.7) This whole news thing seems messy. I'm sure I've
>> missed out on much useful discussion on how news and nntp URL's
>> evolved, but could someone provide in a nutshell why the following
>> won't work ?
>
>> news://[host[:port]]/*
>> news://[host[:port]]/newsgroup[/n1-n2]
>> news://[host[:port]]/message-id
>
>> Use whatever protocol is accepted at the local site....
>
>Surely you can't supply a host and port and then 'use whatever
>protocol is supported'.
Port generally implies a protocol, so perhaps not. However I see no reason
why specifying a host would inherently restrict the protocol selection.
>I could imagine an implementation that allowed these, but, as it
>stands, 'news' is used for URLs that are site independent, and 'nttp'
>for those that specify a particular host and port.
The problem with this is that news URL's are *not* site independent !
First of all (as you also noted) message numbers never are, so use of
message numbers in news syntax breaks the site-independent model.
Second, not all sites have all news articles. Thus, while specifying a news
article by message-id is unique and some chance of succeeding, it still is
no guarantee that an article you have access to I will also. The only way
to ensure a reasonable level of success in accessing a news item is with
inclusion of the host where you know it exists, along with a message-id.
But even this is no guarantee as the article might have scrolled off the
FIFO or the host may (as they frequently are) be restricted.
*Requiring* a host violates the spirit of news.
It would be nice to access articles on local newsgroups that are publicly
(or available to a group such as a company) accessible.
Given all this, the existing URL syntax/functionality doesn't seem to
solve these issues. Perhaps the solution rests in the algorithm for
GET. Since message-id's are globally valid, perhaps the client first
tries to obtain the article from the local feed by whatever protocol,
host, port, etc it knows about, then if it fails, tries the
optionally-specified host. If no host is specified (most common use)
then the access might fail. But at least there's a greater chance of getting
the article. In addition, there is support for local newsgroups via
message-id (impossible with current nntp or news syntax).
Article numbers should be dropped, unless of course you wish to support the
internally-useful-non-human-URL-syntaxes.
If you still don't buy the above argument, and there is a need for two URL
syntaxes, it still doesn't explain why they have differing functionality
(ie omitted message-id for nntp).
Are there any reference implementations for nntp actually in use ? If
not, maybe news should stand as is to support existing implementations and
nntp should be dropped from the spec to be debated/proposed at a future
date ?
-----------------------------------------------
Michael A. Dolan - <mailto:miked@cerfnet.com>
TerraByte Technology (619) 445-9070, FAX -8864