From: Bruce Lilly (blilly@erols.com)
Date: Sun Feb 01 2004 - 15:24:07 CST
Russ Allbery wrote:
> Bruce Lilly <blilly@erols.com> writes:
>
>
>>1. semantics of the Date header field vs. RFCs 850/1036/2822
>
>
> It's unfortunately going to be very difficult to change the effective
> semantics of Date on Usenet since it's an integral part of the acceptance
> algorithms of pretty much every news server out there. That being said,
> the ideal would be to preserve the e-mail semantics of Date for
> compatibility and introduce a new header, like Injection-Date, which is
> used for the accept/reject algorithm that's dominated by history size.
> This would also make gatewaying far easier, since one could preserve the
> original Date header and just add the new Usenet-specific header.
>
> I'm very skeptical of our ability to get there from here, though.
Rough outline of how to get from here to there:
1. Introduce means to record injection date (Injection-Date sounds fine),
strongly recommending that injection agents generate it (i.e. "SHOULD")
2. change SHOULD to MUST; simultaneously strongly recommend servers use
Injection-Date (or whatever) rather than Date.
N.B. at this point the semantics of Date can be uniform
3. mandate (SHOULD->MUST) use of Injection-Date by servers. Done.
If wording such as "injection agents claiming compliance with this standard"
etc. is used, the number of steps can be compressed to two. I hope that if
we provide a road map outlining that progression, that the changes can be made
as the document progresses along the standards track without having to be
reset to Proposed Standard at each step.
>>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.
>
>
> Actually, that is pretty unusual on Usenet. Not unheard of, but you have
> to be behind a very slow initial link for it to take anywhere near that
> long, and at some point those cases start looking a lot like off-line
> composition rather than a true case of slow propagation.
I've seen it happen in binary groups where some number of multi-part
postings appear at about the same time, but others arrive several days
later via a somewhat different path. In some cases, some parts never
arrive. I suspect that the phenomenon is caused by expiration before
relaying at some site.
> Parsing Injector-Info in its current form in order to get that information
> is, I believe, a non-starter. It's certainly code I have no interest in
> writing.
Certainly a dedicated field such as you suggest would be simpler to
parse.
>>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.
>
>
> It depends on how you're defining injection. It makes injection date look
> quite attractive assuming that you define injection to mean something that
> doesn't happen until the article is approved.
Point taken, However, that effectively means that as long as the Date field
is to have semantics of injection date, that means that an injection agent MUST
remove any Date field in a proto-article, and MUST insert a new Date field
with the then-current date and time. But that's not what the draft currently
says.
>>B. Injector-Info posted-date records time of initial injection
>
>
> I agree with this in principal but think the current header design for
> Injector-Info is the wrong way to do it. We need something dead-simple
> and easy, since this is a core news protocol component.
That sounds reasonable.
>> 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.
>
>
> Given that all existing news systems that I'm aware of manage just fine
> with a local database, I really see no reason to add another header to the
> list of headers that can be modified by transit servers.
OK, but note that RFC 850 specified that Date-Received was never to be
transmitted (much like Xref). If a local database works, then I guess
something like Date-Received is unnecessary; at least I can't think of
any reason any software other then the news server (e.g. an IMAP client)
would need access to receipt time of an article.
>>D. Given C, Injector-Info and its posted-date are optional (irrelevant
>> to expiration, useful for tracing, possibly slightly useful for
>> sorting for display).
>
>
> No. If you change the semantics of the Date header, whatever you replace
> it with must be mandatory, since the Date header is an integral component
> of the accept/reject decision for an incoming article. Expiration is a
> minor additional use that's not nearly as important.
OK.
>>Comments? In particular, data regarding different server
>>implementations of expiration policy (item #2) would be useful.
>
>
> Don't focus on the expiration policy. Focus on the history retention
> policy and the accept/reject decision for incoming messages.
OK. It probably doesn't matter much anyway.