From: Bruce Lilly (blilly@erols.com)
Date: Sun Feb 01 2004 - 06:14:50 CST
I think the following issues warrant some discussion:
1. semantics of the Date header field vs. RFCs 850/1036/2822
2822 gives semantics as the time of completion of composition/editing by the author
(paraphrasing), which is consistent with RFCs 822, 733, 724, 561 (though not
explicitly stated by those).
RFCs 850/1036 give a quite different meaning, viz. the time the message first
was posted to "the network".
Though the context of RFCs 806/841 is an unrelated message format, the various date
fields defined there give definitions which may be of interest and utility in
discussion.
Note also that RFC 850 had a Date-Received field.
RFCs 821/822/2821/2822 have a "time stamp line", a.k.a. Received field, which marks
the time of transport of a message.
2. Bases for expiration of an article from a storage system.
Clearly one is the Expires header field, which is an absolute date-time.
Another is local policy, often on a per-newsgroup basis -- but is that/should that be
based on:
a) amount of time the article has been on *that* system
b) elapsed time since composition/editing
c) elapsed time since initial injection
3. Source of delay between composition/editing, injection, and arrival at a given system.
Offline composition has been mentioned.
Obviously, delays in the moderation process also cause delay between composition and
injection.
And clearly there are transport delays -- it is not unusual for propagation of an article
to take several days.
4. Injector-Info, specifically the posting-date parameter (section 6.19 of this version of
the draft)
5. Road map/transition plan.
Clearly, the differences in semantics between RFCs 850/1036 and 822/2822 are undesirable.
Equally clearly, the posting-date parameter of Injector-Info fulfills the role attributed
to Date by 850/1036.
And the fact of offline/moderation/transport delays makes use of either composition date
or initial injection date dubious at best for the purpose of expiration.
I believe that the most productive path for addressing these issues is to determine how
an ideal news system should operate, then to figure out a suitable means of transitioning
from the current situation to that ideal.
Here are some thoughts regarding an ideal system:
A. Date should have the same semantics as in 2822, and its content should be essentially
ignored by all news software, except for syntax and semantic checking per RFC 2822 at
injection (i.e. for human consumption).
B. Injector-Info posted-date records time of initial injection
C. Expiration should be based on time an article exists on the system in question and
local policy, with possible modification based on absolute date-time given by Expires
field if present. Whether local arrival time is recorded in something like a non-
transmitted Date-Received field a la RFC 850, or by some implementation-specific
unspecified mechanism is an open issue.
D. Given C, Injector-Info and its posted-date are optional (irrelevant to expiration,
useful for tracing, possibly slightly useful for sorting for display).
E. Given C, Date is not strictly required, but should be maintained as a mandatory
field consistent with 2822s requirements.
Comments? In particular, data regarding different server implementations of expiration
policy (item #2) would be useful.