From: Bruce Lilly (blilly@erols.com)
Date: Tue Feb 03 2004 - 07:44:52 CST
John Stanley wrote:
> If we want to rewrite the definition of the Date header to be the
> injection time, then now is the time to do it, so to speak.
>
> 5.1. Date
>
> The Date-header contains the date and time that the article was
> prepared by the poster ready for transmission and SHOULD express the
> poster's local time. ...
That definition is consistent with RFC 2822 (a good thing) but it
differs from RFC 1036. In other related discussion, Russ and I are
in agreement (and so far I haven't heard any dissent) that a move
to unify the semantics to 2822's definition is appropriate. I
suggested a method by which that could be achieved in stages, with
unified semantics at stage 2.
Russ correctly points out that the proposed mechanism in the draft
for recording injection time (viz. a date-time value in an
optional parameter of an optional "Injector-Info" header field)
is not easily parsed. The fact that the field and the time stamp
are both optional doesn't help either. Russ has informally proposed
an "Injection-Date" header field, presumably with a date-time field
body, as an improved mechanism for recording injection time in the
article content. I believe Russ' proposal has merit.
Is "Injection-Date" a good name?
I'm not opposed to it, but a more general name that could be used in
other applications might be better; perhaps "Posted-Date".
Should it be mandatory?
If it's critical for system operation, as appears to be the case,
probably so.
What do we do about "Injector-Info"?
Clearly if we have a mandatory header field for injection date, the
optional "posting-date" parameter is superfluous. Will parsing
issues be a consideration for other parameters (bearing in mind
the fact that parameters can be tagged, encoded, quoted, and
split (RFC 2231))?
Do we leave the definition of Date in the draft as it stands,
consistent with 2822, or do we revert to the nebulous 1036
definition and note that it will be changed in future to be
consistent with 2822?
Should we opt for a two-stage implementation by inserting suitable
phrases such as "compliant with this document", or do we want a
three-stage transition?
We will have to review the requirements for various agents to make
sure that they're consistent with the rest of the document. Clearly
they're not now (that's what started this discussion).