Re: news: vs. nntp://host (was RE: mailto: + parameters?)

In message <01I3TG7ZYBNA0070CU@SCI.WFBR.EDU>, Foteos Macrides writes:
>"Daniel W. Connolly" <connolly@beach.w3.org> wrote:
>>>	That was also the reason, wasn't it, for adding nntp as an
>>>access type which accepts a host field, and leaving news as an access
>>>type which uses an independently configured host?
>>
>>That was another bogus idea. There's nothing wrong with:
>>
>>	news://foo.com/comp.text.sgml
>>
>>No conflict at all.
>>
>>>  That's another
>>>interoperability principle, embodied in RFC 1738, which has been
>>>trashed.
>>
>>How does this cause interoperability problems? Where is the
>>case where a conforming implementation will behave unreliably?
>
>	It's not a bogus idea.  It reflects the original values of the
>Web as a cross-platform, cross-protocol, INTEROPERABLE, content-rich,
>information sharing system.

I disagree. And I'm still interested in an answer to my question.


>	The NNTP protocol is like mail in that the articles are referenced
>analogously to a usename@host, and can include characters that are reserved
>in the http protocol.  Also, NNTP servers almost universally have restricted
>access.  Therefore, news URLs were structured analogously to mailto URLs
>
>	news:*
>	news:comp.infosystems.www.authoring.html
>	news:j462#36487@foo.bar
>
>and the client is configured to use an NNTP server to which it has access
>rights.  That '#' does *not* mean what it normally would in a URL, and
>should not be parsed as when in other URLs.

Please cite a source for this bit about the meaning of '#'. It may
well be in the specs, but I'd like to see which specs your invoking.

And even if it's in there, those specs need updating. They contain
some inconsistencies, mistakes, and bogus ideas like this one.
Note that in RFC1630, # always separates a fragment ID from the
rest of the URL, regardless of the URL scheme. See:

http://www.w3.org/pub/WWW/Addressing/URL/5_URI_BNF.html


>	To allow for specification of a host if multiple servers are
>available to a client, a separate, "nntp" scheme exists, and *that*
>is what a client with earnest concern for interoperability should use,
>not "news", when specification of an NNTP server is needed in the URL.

Under the KISS principle (or Occam's razor, etc.) nttp: is completely
unnecessary.


>	How does Netscape's behavior cause interoperability problems?
>Take a look at the "W3C Reference Library".

What should I look at in the librarary? There's a lot of code in there.
I'll repeat the question:

 Where is the
 case where a conforming implementation will behave unreliably?


>   That may have become an
>anachronism in "today's market place", but it's not bogus, is it?
>(I hope not, 'cuz I "reference" it regularly. 8-).

I've done some testing of libwww against the specs, and I've found
some differences. We didn't get around to deciding whether the
code or the specs should be changed.


>	Which isn't to say that the nntp scheme is well designed.  It
>is well intended, but not well designed.  RFC1738 specifies that a
>news group element should precede an article element in the path
>field, and that's not a good idea because articles are not tied to
>a news group (they could have been multiply cross-posted).  Also, it
>does not specify that reserved characters in the path field should
>be hex escaped, and it would be better if they were.

Now you're talking :-)

Dan

Received on Friday, 26 April 1996 17:19:41 UTC