draft-ellermann-news-nntp-uri-04

Discussion on this series of drafts so far has concentrated mainly on  
matters related to snews, registration of schemes, and so on. There has  
not been much said on the actual facilities to be accessed by the two  
schemes, or with the way they are described (and that has been largely  
because I have just not found the time to do it). Time to rectify that now.

So firstly, to deal with the facilities.

The chief change since your draft-00 is that you now admit wildmats in the  
news scheme (which is good, though not quite good enough) and the chief  
change you have *not* made is the introduction of ranges in the nntp  
scheme; what you say is

[RFC1738] has no <range> for the "nntp" 'nntp' URI scheme, and this memo
       isn't the place to invent new tricks for a rarely used scheme.

Let me make a general overall statement first:

Both these schemes are intended to provide access to resources available  
 from NNTP servers, usually using port 119. ISTM that 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. So if  
there is some feature of the protocol that cannot be accessed by that URI,  
then it is reasonable to ask "Why Not?"

So first consider using the news URI to gain access to particular  
newsgroups.

news:/comp.lang.c
	should tell you what articles are available in that group, and hopefully
	provide an opportunity to select the ones you want to read
news:/comp.lang.*
	should tell you what groups are available within the comp.lang
	sub-hierarchy, and what articles are availbe in each
news:/*
	(which was the only 'wildcard' facility in RFC 1738) will tell you all
	the groups known to the server, but that list will be so huge as to be
	almost useless (when 1738 was written, it might have been manageable)

Current implementations support a variety of wildcard notations that have  
grown up, some more comprehensive than others, so we need to bring some  
order to this chaos. Hence the suggestion to use 'wildmats' as currently  
provided in NNTP implementations, but as recently reinvented with a more  
general syntax in RFC 3977. I think we may assume that NNTP  
implementations will come into line with RFC 3977 over the coming years,  
so we should base our scheme on that.

Now it is clear that in order to implement this particular format of the  
news scheme, all you have to do is to issue an NNTP LIST ACTIVE command  
(or possibly LIST NEWSGROUPS) giving it exactly what appears after the '/'  
in the news URI; and back will come a list of groups and the ranges of  
article numbers available within each of them, and from that (and possibly  
some use of the OVER command on each group to give you more detail) your  
browser/newsreader should be able to provide a comprehensive view of what  
is available to be read.

Now the syntax of the LIST ACTIVE command is

	LIST ACTIVE [wildmat]

so that seems the obvious thing to put into the URI. That would enable  
things like

news:/comp.*.java*
	which would give you all the java-related groups, not just in
	comp.lang.*, but also comp.compilers.tools.javacc which you might not
	have thought of looking for.
news:/*.religion.bahai,!talk.*
	will find all the bahai groups, except talk.religion.bahai (supposing you
	find the talk.* hierarchy too noisy for your taste).
news:/comp.lang.*,sci.lang.*
	look for lang groups in those two hierarchies

So my question to you is Why have you disallowed the last two cases by  
permitting only <wildmat-pattern>s instead of full <wildmat>s? What have  
you gained by this, given that LIST ACTIVE understands both (or will as  
soon as NNTP implementations catch up with RFC 3977)?



Now for the nntp scheme and <range>s. Note that the nntp scheme is  
primarily for accessing articles by their article numbers.

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

No wildmats here (and I have no quarrel with that). What NNTP command does  
this correspond to? You could again use LIST ACTIVE, but a sensible  
alternative here is LISTGROUP, which just returns a list of article  
numbers that are available. The syntax is

LISTGROUP [group [range]]

so why not make full use of it? That would allow

nntp://server.example/comp/lang.c		for the whole group
nntp://server.example/comp/lang.c/125-237	for than range of article numbers
nntp://server.example/comp/lang.c/125-	for all articles 125 and above
nntp://server.example/comp/lang.c/-237	for all articles below 238

Easily implemented, so why not? Well, you may ask what use is it?  
certainly 125-237 is not particularly relevant, but the 3rd one could be  
quite useful.

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-". It gives you the list, and then you can ask for each one  
in turn using the format
nntp://server.example/comp/lang.c/126

A crude form of newsreader, maybe, but that is the sort of thing that the  
nntp scheme seems to be aimed at. So why not allow it, since its  
implementation is trivially easy (the NNTP server does all the work for  
you)?

Note that the <range> parameter here is a new feature of RFC 3977. Before  
that you could only ask for the whole group with that command. But we must  
assume that implementations will soon be supporting it, so why not make it  
available?

As an alternative to the LISTGROUP command, if you want to get more  
information about the articles that are there, the OVER command can also  
be used with a <range> parameter (so you get a list of articles numbers,  
together with enough information to display all the Subjects, sizes and  
threading of them). And also the HDR command, if you just want to see all  
the Subjects, or whatever. Essentially, which command you use depends on  
what sort of newsreader you are intending to use to display the resoures  
returned.

All right, that is enough for today. I have dealt with the technical  
features you have not provided, so I will leave it till another day to  
look at how you have defined them.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Received on Tuesday, 5 December 2006 16:23:42 UTC