Re: draft-ellermann-news-nntp-uri-04

Charles Lindsey wrote:

> There has not been much said on the actual facilities to be accessed
> by the two schemes, or with the way they are described

It was clear that I'm not interested to make up new features, and want
to describe the schemes as they are used today, in many existing servers
and many existing clients.  It's still based on Paul's original idea,
and that deprecated the nntp scheme.

RFC 1738 and the Gilman draft also stated more or less clearly that the
nntp-scheme might be a bad idea.  So that's not the time to add ranges,
for starters I couldn't test it, none of my clients support this scheme.

While it's not more deprecated in the last drafts it's still discouraged
indirectly.  Rearranging the quotes:

> Again, you have a format for a whole group:
 
> nntp://server.example/comp/lang.c
 
> which was not actually allowed in RFC 1738, but might be useful even
> though it means the same as
 
> news://server.example/comp/lang.c

Oddly RFC 1738 allows the server + group syntax only for the
nntp-scheme.

Not for news, it had no server for news.  That was added by Gilman, and
widely implemented, so now there are two equivalent ways to talk about a
single group on a given server.

But because nntp is less widely supported it's now better to use the
latter format.  Interoperability and backward compatibility are high
values, and at least for me they come before "make up new stuff and
let's see what happens",

It's frustrating for users if some URLs don't work for them.  It's also
bad for the support stuff if they'd have to answer question why some
fancy style of URLs for a protocol they've never before heard of (their
own NNTP server) doesn't work.

Not all features of a decent newsreader or NNTP-server implemented after
3977 was published some weeks ago need a 1:1 correspondence in URIs.  An
URL is a "hey, look at this" thing, it's supposed to work for anybody.

That's not the case with the fancier wildmats, and also unnecessary.
The comma doesn't work unencoded with some UAs, the question mark is a
nightmare, and the exclamation mark doesn't fly without the comma.

The "*" wildcard was already in Gilman's draft, therefore and based on
other feedback I picked the RFC 3977 <wildmat-pattern>, adding CAVEATs
why that might not "yet" work as expected for most users.

> when inventing a URI to interface to some particular protocol, you
> should aim to provide the maximum access to that protocol that can
> reasonably be defined.

I don't subscribe to that principle, I'm a KISS fundamentalist.  And of
course I'm not trying to invent an URI scheme, I try to document what's
actually used and needed, or why it's a bad idea (like snews, arguably
also nntp). 

It's for standards track, not experimental.  The goal is to move 1738 to
historic at some point in time (ftp and file are also still waiting for
their update, and maybe there are a few normative references elsewhere)

All the changes from 1036 via s-o-1036 to usefor, from 1738 over 2396 to
3986, and from 977 over 2980 to 3977 are interesting enough, it's not
the
time to add fancy features like nntp-ranges, or news-URLs not working
for
many users.  Some XXXXbis can do that later, based on a USEFOR-bis with
internationalized group names, adding some words about IRIs if
necessary.

Doing it all in one giant jump doesn't work, look at the mailto-bis I-D,
it tried to throw in IRIs and EAI and making coffee in various scripts.
It's too much.  It breaks.  RFC 1738 is state of the art 1994.  I want
to document state of the art 2005 (when 3986 was published) + Usefor-11.

It uses the usefor-11 concept of Message-ID, that's a huge step forward,
even in relation to 2822.  That's something I care about, because it is
essential for NetNews, unlike those wildmats or article ranges.  

The precise number of nntp-URLs not talking about groups I've seen in
the wild outside of discussions like this is zero.  I have never seen a
single article nntp-URL, let alone any article-range nntp-URL.  I have
never seen a wildmat-URL outside of such theoretical discussions.

>From my POV I have already documented tons of utter dubious features,
not used anywhere.  Folks talk about single articles by Message-ID in
URLs, about groups, and about servers, sometimes combining it if it's
important to specify the server (as for GMaNe or spamcop).

Adding new features to this mix, even more dubious than the old cruft
inherited from former spec.s, makes no sense as far as I'm concerned.

Say "go" and I'd remove the wildmat-question mark.  It's ugly like hell
in an URL.  Nobody needs it, nobody uses it (in URLs), and if anybody
tries it anyway I bet that they'll get it wrong and forget to percent-
encode it. 

> news:/comp.lang.c

Syntax error.  My UA accepts it.  Remove the slash or add a ///server.

A newsgroup name or Message-ID is no "path" as in http / ftp / file.
For a new scheme we'd probably use it, but news and nntp are not new,
they're (very) old.
 
> Supposing you know that you have already read all the articles in the
> group up to 124. Now you want to see what has come in since then, so
> you ask for "125-".

URLs aren't some kind of command line for newsreaders.  They're used to
communicate with others about the resources.  Nobody but me cares when
I've read articles up to number 124 in a specific group on a specific
server.  And my vintage '98 UA manages to fetch 125 ff. without using
any nntp URL, all I've to say is news:group (or news://server/group if
it's not the default server) if I insist on using an URL for that task.

The idea is to discourage nntp URLs, not to "improve" them.  I can see
a point in an XREF to nntp URL transformation on dedicated servers like
GMaNe, and that's documented.

> Essentially, which command you use depends on what sort of newsreader
> you are intending to use to display the resoures returned.

It also depends on what the server supports, and a general UA might
have to check the server capabilities, and that's the point where a
willing implementor might decide to drop NNTP completely because it's
just too obscure and anyway dying.  Counterproductive.  A common set
of URLs expected to be working everywhere without hassles is better.

Frank

Received on Tuesday, 5 December 2006 21:22:37 UTC