Re: Redirected Trace header draft

On Wed, 3 Nov 2004, Matthew Elvey wrote:

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

I appreciate your feedback. New version based on all the feedback received 
today and fixes that I made is now available at:
http://www.elan.net/~william/emailsecurity/draft-leibzon-emailredirection-traceheaders-00pre03.txt

> I'm going to give another swing at explaining why I feel there are 
> SHOULDs that should be MUSTs in this spec.

Using MUST makes it appear that I'm making it an immediate requirement 
for all systems involved in forwarding/redirection. In fact it will
still be just a new optional trace header for recording what happened
during redirection. 

> 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.
>
> 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.

I'm going to try to follow your suggestion and change first three SHOULD 
to MUST because if somebody does follow this document, they really should
be doing it right (i.e. MUST). But i'll emphasise again that document in 
itself and new header is not any more requirement then current Received
header - its just a good idea. As such I believe in the end I'll be
forced to change language back to SHOULD when the draft is discussed at
ietf-822 and other lists.

> 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?

Yes it does. But Standard Track RFCs with MUST mandate required behavior
and in this case it would be required behavior of the forwarding systems 
and current forwarders don't do it so we really can't make it a MUST 
although as I said already if they are tryingto follow this spec, then
for them it should all be MUST.

-- 
William Leibzon
Elan Networks
[email protected]