On 14 Feb 2021, at 16:38, Dave Crocker wrote:
I'm not a fan of having a spec include language about various things
it is not saying, since the list of such things is infinite. As well,
saying that it is not being covered is a form of covering it. And,
indeed, it invites the reader to find problems with what hasn't been
said. And with what has.
I may be volunteering myself for more work by saying this (and perhaps
this part of the discussion should be brought back to emailcore), but:
I generally agree with the above stated principle. The thing that seems
different here is that 822, 2822, and 5322 all (for better or worse)
treated "trace" as a block containing a Return-Path: field followed by
one or more Received: fields, and recommended (to only slightly varying
degrees) keeping them in that order. This document (among others)
changes that. Compare, for example, RFC 8601 section 4.1, where there's
a whole discussion about positioning and interpretation. There's
certainly way more going on in 8601 that justifies that discussion, but
I'm worried about documents changing the "trace block" assumption of x22
without saying anything.
Maybe this means that the discussion should really take place in
5322bis, explaining that things may appear in between Received: fields
and Return-Path: fields, and you can't really depend on order for any of
it (cf. ticket #7 in emailcore, hence increased work for me/emailcore).
If so, such is life. I just want to make sure that an explicit decision
is being made, and who has the token.
pr
--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp