Re: Realisticness of header rearrangement

david nicol wrote:
> On Mon, 2004-04-05 at 17:49, Philip Miller wrote:
> 
>>If someone comes up with a more aesthetically pleasing way to match tag to 
>>Received header, with similar or better functional characteristics than the 
>>Received-timestamp, I'm all ears.
>>
> What if we declared an extension to Received: header syntax?  Instead
> of a new header, we would define some parseable pairs that go inside a
> Received header.  

Looking at the syntax definition of the Received header in RFC 2821, that 
would require some serious abuse of the optional fields. There is no room in 
that definition for extension, *at*all*.

The problems I see with using the Received timestamp are as follows:
1. It's not really a stamp of when the filtering event occurred.
Of course it isn't, and it and the filtering timestamp will each be labeled 
appropriately.
2. It could confuse users reading these headers
Users who are advanced enough to be reading headers will learn quickly how 
to read the pair of timestamps appearing in this new one.
3. It's aesthetically unpleasing to see 2 timestamps in a header
So it may look ugly, but aesthetics considerations hold carry little weight 
in comparison to authentication and cost.

There is a compromise position on this, but I rather dislike it:
Use a one-way hash of the Received timestamp (or the whole Received header) 
instead of the timestamp itself. This eliminates the above problems, when 
they're read narrowly, but presents its own:
1. Reading users see a big number that they have to go to some effort to 
match to the Received line that they will learn it should correspond with.
2. It's aesthetically unpleasing to see a semi-random big number with little 
semantic meaning attached to it.
3. It has the computational cost not only of minimally parsing Received 
lines, as copying the timestamp does, but also of hashing those lines.

In the long term, I think that we're better off explicitly using the 
timestamp and making its usage and meaning in that role clear than trying to 
use something more opaque (a hash) or with less backward compatibility 
(extending Received).

Philip Miller