Re: Redirected Trace header draft

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!)