On 11/2/2004 1:49 PM, william(at)elan.net sent forth electrons to convey:
I would like to receive comments and open discusion on ...
draft-leibzon-emailredirection-traceheaders-00pre02.txt
This looks good. It adds information that may well be useful for
debugging and investigating, without adding tons of redundant info.
An earlier criticism of mine wasn't that it adds tons of info, but that
(I thought) it added redundant info - that it duplicated info that was
already there in 'Received:'. Looking at it more closely, now in draft
format, I see that this isn't the case. It's not redundant. :)
I'm going to give another swing at explaining why I feel there are
SHOULDs that should be MUSTs in this spec.
At a high level, consider SMTP as an example of a set of specs. The
purpose of SMTP is to allow e-mail to flow in an interoperable way
between systems. If an implementation follows all the MUSTs in the specs
for SMTP, then it will be capable of accomplishing this purpose. (Or at
least that is the intent of the specs.)
In general:
If an implementation follows all the MUSTs in the specs for the
implementation, then it will be capable of accomplishing the purpose of
the implementation.
Or at least I think that's the way it should be.
The purpose of the Redirected spec is to enable interoperable
traceability of an automatically forwarded email by providing all the
key information that the forwarder changes or replaces.
The general case should apply:
If an implementation follows all the MUSTs in the spec for the
implementation, then it will be capable of accomplishing the purpose of
the implementation.
Using wording from RFC 2119 defining SHOULD, let me state: I can't
think of a valid reason in any particular circumstance where an
implementation's implementer who desires it to be compatible with this
spec would need to ignore the particular items suggested by (e.g.) the
first three SHOULDs in the spec.
Also, the goal of the spec can't be met if these SHOULDs aren't
followed, so they should be MUSTs. If an implementer doesn't want to
enable "interoperable traceability of an automatically forwarded email
by providing all the key information that the forwarder changes or
replaces" then fine, but it must be clear that isn't compatible with
this spec. Therefore, these SHOULDs must be MUSTs.
Does this make sense to you? Am I mis-reading 2119?
(Said another way: Some servers admins do not wish them to send or
receive e-mail. Their purpose does not include accomplishment of that
goal. So they don't support the RFCs defining SMTP. They violate the
MUSTS of these RFCs. This isn't a problem. It *doesn't* follow that
the MUSTs of these RFCs shouldn't have been SHOULDs or MAYs!)