On Sat, Aug 04, 2007 at 04:09:57PM -0400, John C Klensin wrote:
The difficulty, IMO, is that since many of the "policy"
decisions have been made in practice to provide better security,
the distinction may not be clear and splitting things into
multiple codes may do as much to obscure what is going on as to
clarify it. As the obvious example, if I reject a message
because I've concluded that the apparent sender is often a
source of malware, but without having examined the message
sufficiently to make a solid determination of whether malware is
present in it, is that "security" or "policy"? Conversely, if I
detect malware as being present and identify it and then reject
the message, is that "security" or a "policy" of blocking known
malware at the MTA rather than letting user anti-virus software
sort it out?
IMO, both examples are policy. Since future codes must be registered,
group consensus would put things in the proper place.
I don't have a major objection to the proposed change, and
better documentation is always A Good Thing, but, especially
since there would be no way to tell whether a legacy system
emitting at 5.7.z code had been upgraded or not, I'm not
convinced that the benefits of this are worth the effort.
I don't understand the upgrade concern. If x.7.13 isn't widely used the
current meaning could be safely moved to x.8.3. x.7.1 and x.7.2 stay
defined as they are today. x.8.1 and x.8.2 are just the equivalent of
x.7.1 and x.7.2. The RFC would say implementations SHOULD use x.8.1 and
x.8.2 instead of x.7.1 and x.7.2. Perhaps an update could change that
SHOULD to a MUST 10 years from now.
John and Ned, you both mentioned 'worth the effort'. Is that because
you both believe the RFC wouldn't be an "Independent Submission"? I'm
very new to this whole process, so forgive me if this is a stupid
:: Jeff Macdonald | Principal Engineer, Messaging Technologies
:: e-Dialog | jmacdonald(_at_)e-dialog(_dot_)com
:: 131 Hartwell Ave. | Lexington, MA 02421
:: v: 781-372-1922 | f: 781-863-8118