usefor-article-03 February 2000

6.8.  References

   The References header lists optionally CFWS-separated message
   identifiers of precursors. The content syntax makes use of syntax
   defined in [MESSFOR].

      References-content  = msg-id *( CFWS msg-id )

        NOTE: This differs from the syntax of [MESSFOR] by requiring at
        least one CFWS between the msg-ids (this was an [RFC 1036]
        requirement).

   A followup MUST have a References header, and an article that is not
   a followup MUST NOT have a References header. In a followup, if the
   precursor did not have a References header, the followup's
   References-content MUST be formed by the message identifier of the
   precursor. A followup to an article which had a References header
   MUST have a References header containing the precursor's References-
   content (subject to trimming as described below) plus the precursor's
   message identifier appended to the end of the list (separated from it
   by CFWS).

   Followup agents SHOULD NOT trim message identifiers out of a
   References header unless the number of message identifiers exceeds
   21, at which time trimming SHOULD be done by removing sufficient
   identifiers starting with the second so as to bring the total down to
   21. However, it would be wrong to assume that References headers
   containing more than 21 message identifiers will not occur.

--- ../s-o-1036/References.out          June 1994
+++ ../usefor-article-03/References.out          February 2000
@@ -1,126 +1,29 @@
-6.5. References
+6.8.  References
 
-The References header content lists message IDs  of  precur-
-sors:
-
-     References-content = message-id *( space message-id )
-
-A  followup  MUST  have  a References header, and an article
-which is not a followup MUST not have a  References  header.
-In a followup, if the precursor had a References header, the
-message ID of the precursor is appended to the  end  of  the
-precursor's References-content to form the followup's Refer-
-ences-content.  a References header containing  the  precur-
-sor's message ID.  A followup to an article which had a Ref-
-erences header MUST have a References header containing  the
-precursor's References content, plus the precursor's message
-ID appended to the end of the list.
-
-     NOTE: Use the See-Also header (section  6.16)  for
-     interconnection  of  articles  which  are not in a
-     followup relationship to each other.
-
-     NOTE: In retrospect, RFCs 850 and  1036,  and  the
-     implementations  whose  practice they represented,
-     erred here.  The proper MAIL  header  to  use  for
-     references  to  precursors is In-Reply-To, and the
-     References header is meant to be used for the pur-
-     poses  here ascribed to See-Also.  This incompati-
-     bility is far too solidly established to be fixed,
-     unfortunately.   The  best  that can be done is to
-     provide a clear mapping between the two, and  urge
-     gateways to do the transformation.  The news usage
-     is (now) a deliberate violation of the MAIL speci-
-     fications;  articles  containing  news  References
-     headers are technically not valid  MAIL  messages,
-     although  it  is  unlikely that much MAIL software
-     will notice because the incompatibility  is  at  a
-     subtle  semantic  level  that  does not affect the
-     syntax.
-
-     UNRESOLVED ISSUE: Would it be better to just  give
-     up  and  admit  that news uses References for both
-     purposes?
-
-     UNRESOLVED ISSUE: Should the syntax be generalized
-     to  include  URLs  as alternatives to message IDs?
-     Perhaps not; too many things know about References
-     already.   And non-articles can't be precursors of
-     articles, not really.
-
-INTERNET DRAFT to be        NEWS                    sec. 6.5
-
-
-Followup agents SHOULD not shorten References  headers.   If
-it  is absolutely necessary to shorten the header, as a des-
-perate last resort, a followup agent MAY do this by deleting
-some  of  the  message IDs.  However, it MUST not delete the
-first message ID, the last three message IDs (including that
-of  the immediate precursor), or any message ID mentioned in
-the body of the followup.  If it is possible  for  the  fol-
-lowup agent to determine the Subject content of the articles
-identified in the References header, it MUST not delete  the
-message  ID of any article where the Subject content changed
-(other than by prepending of a back  reference).   The  fol-
-lowup  agent MUST not delete any message ID whose local part
-ends with "_-_" (underscore (ASCII 95), hyphen  (ASCII  45),
-underscore);  followup  agents are urged to use this form to
-mark subject changes, and to avoid using it otherwise.
-
-     NOTE: As software capable of exploiting References
-     chains  has grown more common, the random shorten-
-     ing permitted by RFC 1036 has become  increasingly
-     troublesome.   ANY  shortening is undesirable, and
-     software should do it only in cases of dire neces-
-     sity.  In such cases, these rules attempt to limit
-     the damage.
-
-     NOTE: The first message ID is  very  important  as
-     the  starting point of the "thread" of discussion,
-     and absolutely should not be deleted.  Keeping the
-     last  three  message  IDs  gives  thread-following
-     software a fighting chance to reconstruct  a  full
-     thread  even  if  an  article  or  two is missing.
-     Keeping message IDs mentioned in the body is obvi-
-     ously desirable.
-
-     NOTE:  Subject changes are difficult to determine,
-     but they are significant as possible beginnings of
-     new  threads.  The "_-_" convention is provided so
-     that posting agents (which have  more  information
-     about  subjects)  can  flag  articles containing a
-     subject change in a way that followup  agents  can
-     detect  without access to the articles themselves.
-     The sequence is  chosen  as  one  that  is  fairly
-     unlikely to occur by accident.
-
-     NOTE: Is "_-_" really worth having?
-
-When a References header is shortened, at least three blanks
-SHOULD be left between adjacent message IDs  at  each  point
-where  deletions  were  made.  Software preparing new Refer-
-ences headers SHOULD preserve multiple blanks in older  Ref-
-erences content.
-
-     NOTE:  It's desirable to have some marker of where
-     deletions occurred, but the restricted  syntax  of
-     the  header  makes  this  difficult.   Extra white
-
-INTERNET DRAFT to be        NEWS                    sec. 6.5
-
-
-     space is not a very good marker, since it  may  be
-     deleted  by  software  that ill-advisedly rewrites
-     headers, but at least it  doesn't  break  existing
-     software.
-
-To  repeat:  followup  agents  SHOULD not shorten References
-headers.
-
-     NOTE:  Unfortunately,  reading  agents  and  other
-     software  analyzing References patterns have to be
-     prepared for the worst anyway.  The worst includes
-     random  deletions  and the possibility of circular
-     References chains (when References is  misused  in
-     place of See-Also, section 6.16).
+   The References header lists optionally CFWS-separated message
+   identifiers of precursors. The content syntax makes use of syntax
+   defined in [MESSFOR].
+
+      References-content  = msg-id *( CFWS msg-id )
+
+        NOTE: This differs from the syntax of [MESSFOR] by requiring at
+        least one CFWS between the msg-ids (this was an [RFC 1036]
+        requirement).
+
+   A followup MUST have a References header, and an article that is not
+   a followup MUST NOT have a References header. In a followup, if the
+   precursor did not have a References header, the followup's
+   References-content MUST be formed by the message identifier of the
+   precursor. A followup to an article which had a References header
+   MUST have a References header containing the precursor's References-
+   content (subject to trimming as described below) plus the precursor's
+   message identifier appended to the end of the list (separated from it
+   by CFWS).
+
+   Followup agents SHOULD NOT trim message identifiers out of a
+   References header unless the number of message identifiers exceeds
+   21, at which time trimming SHOULD be done by removing sufficient
+   identifiers starting with the second so as to bring the total down to
+   21. However, it would be wrong to assume that References headers
+   containing more than 21 message identifiers will not occur.