s-o-1036 June 1994
[< Prev]
[TOC] [ Next >]
6.5. 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).
[< Prev]
[TOC] [ Next >]
#Diff to first older
--- ../rfc1036/References.out December 1987
+++ ../s-o-1036/References.out June 1994
@@ -1,32 +1,126 @@
-2.2.5. References
+6.5. References
- This field lists the Message-ID's of any messages prompting the
- submission of this message. It is required for all follow-up
- messages, and forbidden when a new subject is raised.
- Implementations should provide a follow-up command, which allows a
- user to post a follow-up message. This command should generate a
- "Subject" line which is the same as the original message, except
- that if the original subject does not begin with "Re:" or "re:", the
- four characters "Re:" are inserted before the subject. If there is
- no "References" line on the original header, the "References" line
- should contain the Message-ID of the original message (including the
- angle brackets). If the original message does have a "References"
- line, the follow-up message should have a "References" line
- containing the text of the original "References" line, a blank, and
- the Message-ID of the original message.
-
- The purpose of the "References" header is to allow messages to be
- grouped into conversations by the user interface program. This
- allows conversations within a newsgroup to be kept together, and
- potentially users might shut off entire conversations without
- unsubscribing to a newsgroup. User interfaces need not make use of
- this header, but all automatically generated follow-ups should
- generate the "References" line for the benefit of systems that do
- use it, and manually generated follow-ups (e.g., typed in well after
- the original message has been printed by the machine) should be
- encouraged to include them as well.
-
- It is permissible to not include the entire previous "References"
- line if it is too long. An attempt should be made to include a
- reasonable number of backwards 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).