Re: header-munging

[Keith Moore <[e-mail]>]

Stef writes:

> Our job in the standards business is to define the ABSTRACT model and
> the interactions between ABSTRACT model components.
> 
> Out job is NOT to decide anything about how an implementation might
> actually make it happen, as long as no ABSTRACT MODEL violations can
> be detected outside the boundaries of the code that does the work.

I strongly disagree.  

Our job is to make the net work well, using such tools as we have at
our disposal.  (Our tools tend to be published documents, but also
include hallway discussions, technical meetings, private email, and
other mechanisms for sharing information.)  We don't have to
artifically limit ourselves to writing standards documents in terms of
abstract models.

Abstract models are fine things, and are quite useful in the proper
context.  It's true in general that we try not to constrain
implementations more than necessary.  Instead, we define the protocols
to be used on the wire.  This is in keeping with the longstanding goal
of letting the Internet be composed of -- and work well with -- a wide
variety of systems and users.

Defining the protocols isn't enough to make the net work well.  We
must also describe the context in which those protocols are expected
to be used.  Abstract models help supply the missing context.  But
defining the abstract model, without considering what implementations
are likely to do in practice, does not produce a working system.

Case in point: There's nothing wrong with the abstract model we are
currently using for email.  The problem we have -- that MUAs don't
generate correctly formatted messages -- isn't due to a failing of the
abstract model, but due to the practical difficulty of supplying the
MUA with the correct information that it needs to do the job right.

Splitting the MUA into two abstract components -- one of which
generates a message on the basis of incomplete or inaccurate
information and the other of which fixes it up -- isn't going to help,
UNLESS we somehow significantly increase the liklihood that the
component that fixes things up has more accurate information than
present-day MUAs.  

NONE of the proposals which use SMTP in any way to do "fixup" of
submitted messages are ANY more likely (certainly not "significantly"
more likely) to produce correct messages than the status quo.

We can twiddle the abstract model all we want, but if IN PRACTICE, the
guy doing the fixup still lacks the correct information, we will not
have improved the reliability of email.  We'll have succeeded only in
creating a new way to talk about the same old problem (we'll blame a
different component of the system), and perhaps even in making the
problem worse than it is now.

On the other hand, if we want to improve the reliability of email, we
need to arrange things so that the component that generates the
message that goes out on the wire, is likely IN PRACTICE to have all
of the information that it needs to do so.  That means that the parts
of the message which are dependent on the sender's environment, need
to be somehow supplied by the sender's environment.

The whole approach of transmitting an incomplete 822 message over a
network connection, and having it be "fixed up" by the entity at the
other end of that connection, makes it likely that the "fixup guy"
will be in a different environment than the sender, and thus likely
that the "fixup guy" will not have the information it needs.  So the
whole approach is likely to lose.

Keith