ietf-nntp streaming NNTP

[USENET news manager <[e-mail]>]

Back in mid-August, we discussed whether the streaming extensions to NNTP
should be included, and Stan Barber declined to include them in his initial
draft on the grounds both that there were insufficient independent and
official (i.e. excluding INN 1.4unoffN) implementations and that
documentation of the extra commands was lacking.

That was before the first draft was available for discussion, and Stan noted
(on 13th Aug)

"After the draft is released, folks are welcome to comment on it. If they
don't like my criteria for what is in or not in that document, they are
welcome to suggest changes to the draft that will liberalize or make more
restrictive what is considered part of the basic functionality of NNTP.
Alternatively, they can write drafts for extensions to NNTP under the new
extension mechanism to add whatever functions they like. Some of those may
become standard extensions, others may not. That's part of the process."

Well, INN 1.5 is now available as an official, public, albeit beta-test
release and includes the streaming commands, and the draft revision of the
NNTP standard is also available and under discussion. It seems like time to
think about the status of streaming NNTP again.

To me, the availability of the INN 1.5 beta with streaming included seems
sufficient to confirm the legitimacy of the streaming support included in
the unofficial INN 1.4unoffN releases and establish its position as a (to
be) supported part of INN 1.5 onward, so that streaming meets Stan's stated
criteria for support by multiple official implementations.

Even without that, of course, the case could be argued (as it was before,
but put "on hold" pending completion of the draft) that the widespread 
use of various implementations (though perhaps primarily INN 1.4unoffN)
should count for something. If we are supposed to be documenting current
practice, then streaming has to be included; a *lot* of people have clearly
chosen to move to streaming versions of INN (apart from any use of other
servers with streaming). It seems far better to include it now, in the base
document, when an ever-increasing number of sites is relying on it, than to
leave it to be defined later as an "extension" (by which time it may be
almost universal). This assumes someone can provide a suitable definition
of the extra commands...

[The meta-issue here, I suppose, is whether "current practice" should be 
defined by number of independent implementations, the scale on which a 
facility is used (i.e. how many thousands of servers, regardless of the 
software used), or a combination of those and other factors.]

                                John Line
-- 
Cambridge University Computing Service - USENET news manager. Usually John Line
[e-mail]    (alias {newsmaster,news,usenet}@news.cam.ac.uk)