s-o-1036 June 1994

1. Introduction

Network  news articles resemble mail messages but are broad-
cast to potentially-large audiences, using a flooding  algo-
rithm  that  propagates one copy to each interested host (or
groups thereof), typically stores only one  copy  per  host,
and  does  not require any central administration or system-
atic registration of interested users.  Network news  origi-
nated as the medium of communication for Usenet, circa 1980.
Since then Usenet has grown explosively, and  many  Internet
sites  participate  in it.  In addition, the news technology
is now in widespread use for other purposes, on the Internet
and elsewhere.

The  earliest  news  interchange used the so-called "A News"
article  format.   Shortly  thereafter,  an  article  format
vaguely  resembling  Internet  mail  was  devised  and  used
briefly.  Both of those  formats  are  completely  obsolete;
they  are  documented  in  appendix A for historical reasons
only.  With publication of RFC 850 [rrr] in 1983, news arti-
cles  came  to closely resemble Internet mail messages, with
some restrictions and some  additional  headers.   RFC  1036
[rrr]  in 1987 updated RFC 850 without making major changes.

In the intervening five years, the RFC 1036  article  format
has  proven  quite  satisfactory,  although minor extensions
appear desirable to match recent developments in areas  such
as  multi-media  mail.  RFC 1036 itself has not proven quite
so satisfactory.  It is often  rather  vague  and  does  not
address  some  issues  at  all;  this has caused significant
interoperability problems at times, and implementations have
diverged  somewhat.  Worse, although it was intended primar-
ily to document existing  practice,  it  did  not  precisely
match  existing  practice even at the time it was published,
and the deviations have grown since.

INTERNET DRAFT to be        NEWS                      sec. 1


This Draft attempts to specify the format of  articles,  and
the  procedures  used  to exchange them and process them, in
sufficient detail to allow full interoperability.  In  addi-
tion,  some  tentative suggestions are made about directions
for future development, in an attempt to  avert  unnecessary
divergence  and  consequent loss of interoperability.  Major
extensions (e.g.  cryptographic  authentication)  that  need
significant  development effort are left to be undertaken as
independent efforts.

     NOTE: One question this all may raise is:  why  is
     there  no  News-Version header, analogous to MIME-
     Version, specifying a version number corresponding
     to  this specification?  The answer is: it doesn't
     appear  to  be  useful,  given  news's   backward-
     compatibility  constraints.   The  major  use of a
     version number  is  indicating  which  of  several
     INCOMPATIBLE  interpretations  is  relevant.   The
     impossibility of orchestrating any sort of  simul-
     taneous change over news's installed base makes it
     necessary to avoid such incompatible  changes  (as
     opposed  to extensions) entirely.  MIME has a ver-
     sion number mostly because it introduced incompat-
     ible  changes  to  the  interpretation  of several
     "Content-"  headers.   This  Draft   attempts   no
     changes  in interpretation and it appears doubtful
     that future Drafts will find it feasible to intro-
     duce any.

     UNRESOLVED  ISSUE:  Should  this  be reconsidered?
     Only if the header has SPECIFIC IDENTIFIABLE  uses
     today.  Otherwise it's just useless added bulk.

As  in  this  Draft's  predecessors, the exact means used to
transmit articles from one host to another is not specified.
NNTP  [rrr]  is probably the most common transmission method
on the Internet, but a number of others are known to  be  in
use,  including  the UUCP protocol [rrr] extensively used in
the early days of Usenet and still much used on its  fringes
today.

Several  of  the mechanisms described in this Draft may seem
somewhat strange or even bizarre at first reading.  As  with
Internet  mail, there is no reasonable possibility of updat-
ing the entire installed base of news software promptly,  so
interoperability  with  old  software  is  crucial  and will
remain so.  Compatibility with existing practice and robust-
ness  in  an  imperfect world necessarily take priority over

INTERNET DRAFT to be        NEWS                      sec. 1


elegance.

--- ../rfc1036/Introduction.out          December 1987
+++ ../s-o-1036/Introduction.out          June 1994
@@ -1,14 +1,93 @@
 1.  Introduction
 
-    This document defines the standard format for the interchange of
-    network News messages among USENET hosts.  It describes the format
-    for messages themselves and gives partial standards for transmission
-    of news.  The news transmission is not entirely in order to give a
-    good deal of flexibility to the hosts to choose transmission
-    hardware and software, to batch news, and so on.
-
-    There are five sections to this document.  Section two defines the
-    format.  Section three defines the valid control messages.  Section
-    four specifies some valid transmission methods.  Section five
-    describes the overall news propagation algorithm.
+Network  news articles resemble mail messages but are broad-
+cast to potentially-large audiences, using a flooding  algo-
+rithm  that  propagates one copy to each interested host (or
+groups thereof), typically stores only one  copy  per  host,
+and  does  not require any central administration or system-
+atic registration of interested users.  Network news  origi-
+nated as the medium of communication for Usenet, circa 1980.
+Since then Usenet has grown explosively, and  many  Internet
+sites  participate  in it.  In addition, the news technology
+is now in widespread use for other purposes, on the Internet
+and elsewhere.
+
+The  earliest  news  interchange used the so-called "A News"
+article  format.   Shortly  thereafter,  an  article  format
+vaguely  resembling  Internet  mail  was  devised  and  used
+briefly.  Both of those  formats  are  completely  obsolete;
+they  are  documented  in  appendix A for historical reasons
+only.  With publication of RFC 850 [rrr] in 1983, news arti-
+cles  came  to closely resemble Internet mail messages, with
+some restrictions and some  additional  headers.   RFC  1036
+[rrr]  in 1987 updated RFC 850 without making major changes.
+
+In the intervening five years, the RFC 1036  article  format
+has  proven  quite  satisfactory,  although minor extensions
+appear desirable to match recent developments in areas  such
+as  multi-media  mail.  RFC 1036 itself has not proven quite
+so satisfactory.  It is often  rather  vague  and  does  not
+address  some  issues  at  all;  this has caused significant
+interoperability problems at times, and implementations have
+diverged  somewhat.  Worse, although it was intended primar-
+ily to document existing  practice,  it  did  not  precisely
+match  existing  practice even at the time it was published,
+and the deviations have grown since.
+
+INTERNET DRAFT to be        NEWS                      sec. 1
+
+
+This Draft attempts to specify the format of  articles,  and
+the  procedures  used  to exchange them and process them, in
+sufficient detail to allow full interoperability.  In  addi-
+tion,  some  tentative suggestions are made about directions
+for future development, in an attempt to  avert  unnecessary
+divergence  and  consequent loss of interoperability.  Major
+extensions (e.g.  cryptographic  authentication)  that  need
+significant  development effort are left to be undertaken as
+independent efforts.
+
+     NOTE: One question this all may raise is:  why  is
+     there  no  News-Version header, analogous to MIME-
+     Version, specifying a version number corresponding
+     to  this specification?  The answer is: it doesn't
+     appear  to  be  useful,  given  news's   backward-
+     compatibility  constraints.   The  major  use of a
+     version number  is  indicating  which  of  several
+     INCOMPATIBLE  interpretations  is  relevant.   The
+     impossibility of orchestrating any sort of  simul-
+     taneous change over news's installed base makes it
+     necessary to avoid such incompatible  changes  (as
+     opposed  to extensions) entirely.  MIME has a ver-
+     sion number mostly because it introduced incompat-
+     ible  changes  to  the  interpretation  of several
+     "Content-"  headers.   This  Draft   attempts   no
+     changes  in interpretation and it appears doubtful
+     that future Drafts will find it feasible to intro-
+     duce any.
+
+     UNRESOLVED  ISSUE:  Should  this  be reconsidered?
+     Only if the header has SPECIFIC IDENTIFIABLE  uses
+     today.  Otherwise it's just useless added bulk.
+
+As  in  this  Draft's  predecessors, the exact means used to
+transmit articles from one host to another is not specified.
+NNTP  [rrr]  is probably the most common transmission method
+on the Internet, but a number of others are known to  be  in
+use,  including  the UUCP protocol [rrr] extensively used in
+the early days of Usenet and still much used on its  fringes
+today.
+
+Several  of  the mechanisms described in this Draft may seem
+somewhat strange or even bizarre at first reading.  As  with
+Internet  mail, there is no reasonable possibility of updat-
+ing the entire installed base of news software promptly,  so
+interoperability  with  old  software  is  crucial  and will
+remain so.  Compatibility with existing practice and robust-
+ness  in  an  imperfect world necessarily take priority over
+
+INTERNET DRAFT to be        NEWS                      sec. 1
+
+
+elegance.