On Fri, 27 May 2005 09:31:37 -0700 (PDT), <ned+ietf-smtp(_at_)mrochek(_dot_)com>
> This could even result in reordering of trace fields in some cases,
> if clocks are out of sync (which they often are). The mapping of trace
> to X.400 in particular is pretty complicated.
I should have noted that this issue only applies to Recevied: and
X400-Received: fields. No other field mappings have similar characteristics,
and I doubt very much that mappings of newly defined trace fields to X.400
constructs will be done.
So, why not have some explicit ordering of any new trace fields, rather
than relying in their order in the header
It's a cute idea, one that might even be useful for future trace
header definitions. But it is much too late to change the syntax
of Received: fields. And even if it were applied to Received-SPF fields,
it does nothing to keep the Received-SPF ordered relative to Received: fields.
Just a thought...
And not a bad one. I just don't see how it can be used to deal with problems
associated with existing fields and their relative ordering.