[Mailman-Developers] Re: Dates
Tue, 1 May 2001 17:52:08 -0500
On 2001.05.01, in <email@example.com>,
"Jay R. Ashworth" <firstname.lastname@example.org> wrote:
> > correct. How would it possibly know? You're discussing ways to make a
> > correct guess in most cases, but not a way to ensure correct
> > information in all cases.
> Stipulated. But we're not rewriting for retransmission, only to keep
> the archives clean; right, Barry?
That's what I understand, too. My personal taste is that an archive
reflect with complete accuracy and fidelity what was received from the
transmitter -- not the recipient's interpretation thereof. This is
only relevant to particulars of implementation, though, not to whether
the general solution is applied at all. For example, I think it's more
appropriate to leave the default at "don't munge incoming mail at
> > > Fine. Then turn those switches off. You're in a minority, many other
> > > people hate having *incorrect* (and they are incorrect -- those messages
> > I don't think the discussion thus far is sufficient to say who's a
> > minority, and I don't think that's relevant. What matters is that
> > Barry seems to agree with you, and that not one has proposed a way to
> > make everyone happy.
> Well, it's a matter of personal taste, to some degree... but we could
> always dig up Einar Stefferud and Marshall Rose, and see what they
> But as it happens, I agree with Barry, not the other way round.
Fine. I suppose I used "agree" in the sense of having equivalent
opinion, not of changing one's mind to match another's. I tend to
think of this commutatively. Since I was speaking to you, and my
emphasis was on what Barry thinks rather than on what you think....
> not the time it was actually injected. Now, while I don't think the
> standard actually *says* (section 3.3 certainly doesn't), *I* would
> personally assert that that field is invalid if the clock it was
> generated from isn't within *some* reasonable percentage of accurate
> (for a machine which is continuously connected to the Internet, I'd
> call that a second or so; for a machine *regularly* connected, probably
> 30-45 seconds).
Without looking, I would wager cash that the *standard-track* RFC
doesn't specify expected transmission time. I think you perhaps expect
too much of the Internet.
> > This approach to the hypothetical problem doesn't cover all cases, just
> > the majority of cases where there's damage due to misconfiguration.
> Where damage can be interpreted as "people getting annoyed about the
> behaviours of others based on messages with incorrect time stamps"?
Where "damage" means "undesired harm or inconvenience".
> I wasn't trying to suggest otherwise. What I *can* be construed as
> trying to suggest is that, since the proposed solution can be switched
> on and off at will, popping up with "Well, *I* don't think it needs to
> be fixed cause I don't think it's a problem" seems, at best, not
> especially productive. Particularly in light of the fact that *it's
> already done*.
I disagree, but we can each choose our crusades.
-D. email@example.com NSIT University of Chicago