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
william(_at_)elan(_dot_)net