--On Friday, October 30, 2015 20:42 +0000 Ted Lemon
<Ted.Lemon@xxxxxxxxxxx> wrote:
>> AFAIK everything I've talked about is described in an RFC
>> somewhere. Indeed, the problem isn't that it's not there,
>> it's that there's too much and it's difficult for
>> inexerienced people to match up the right capabilities and
>> architecture to solve a given problem.
>
> That may well be so. It may be that all that's needed (by me
> anyway) is a document of some sort that points out where all
> this stuff is. Having read the SMTP documents pretty closely
> recently, there is definitely a substantial amount of stuff in
> there that I don't see implemented in systems that are
> available to me. However, I am fairly sure that there are in
> fact gaps in the docs in terms of the features i want to see.
> Even if I'm wrong, I think it's worth going through the
> exercise of figuring that out. By which I do not mean "go do
> some work for me." I'm interested in this and willing to do
> work, but as I'm sure you've gathered, I do not have a
> complete picture of what's been documented and what hasn't
> been.
Ted,
As the guy who is sitting on, rather than holding and moving,
the pen on some of the critical documents (notable 5321bis), let
me explain why because it is an important part of the picture.
First, the path from 821 and 974 and through 1123 plus 1869 and
assorted extensions and small modifications to 2821, then from
2821 to 5321, became largely an exercise in merging text. The
result contains a number of artifacts, including in how the
document is organized, and is consequently redundant in some
places and _very_ hard to read in others. I can't keep track of
all of it: if someone asks me a question, I typically have to go
back and check. When I don't, I make mistakes more than half
the time. Others may have better memories (some probably as a
consequence of working with the specs every day) but, if I can't
keep track, expecting casual readers to do so is probably
unrealistic.
I wanted to do a complete rewrite in the 5321 timeframe and even
engaged a very good technical editor to help with reorganizing
and structuring. I eventually gave up because, especially in
the absence of a forcused WG, several members of the community
(including a large subset of the obvious experts) were concerned
about the risk of inadvertent changes accompanying changes in
organization and some needed changes in terminology. Much as I
might wish otherwise, I don't see any 5321bis being any
different. We could fix or patch known issues (of which the
current errata list is a subset), fold in some of the EAI
material if it were ready and make informative references to it
is it were not, but what is needed to make things clear and
coherent to you and others is unlikely to happen in 5321bis for
the same reason it didn't happen in 5321. That reason might be
summarized as a hypothesis that the relevant community just
doesn't have the energy to deal with a very careful review of a
significantly rewritten and restructured document.
The second issue is that I believe that we have ample evidence
that any attempt to open 5321bis would generate a tremendous
amount of discussion (some would say "noise") from people who
believe that email is obsolete, people who believe that multihop
email models are unnecessary and harmful, people who believe
that hop-by-hop in-transit (TLS-based or otherwise) encryption
is an important security measure and those who don't, and people
who have better ideas than SMTP or even MIME. Think "final
ultimate solution to the email problem". It is hard to figure
out a model that would prevent those people from being heard and
it would probably not be desirable if we could figure it out.
But if resolving even a large fraction of those arguments
becomes prerequisite to 5321bis, then I suggest that the
community will run out of energy before we have an approved
spec, even if it is the minimum update to 5321 with none of the
structural changes suggested above.
So we are stuck, have been stuck for several years, and I have
no idea how to get unstuck.
In addition, there are some areas where the IETF could do useful
architectural work. For example, there is a common trend these
days (one referred to indirectly in several recent notes) to
view email addresses as good personal identifiers. They
probably aren't, especially in a world where the mailboxes are
not really under the control of the user being identified. But,
while it is mostly not a technical problem (certainly one that
can't be "solved" by protocol changes) no one has ever explained
the issues in terms that can be understood by those who are
making the decisions, much less publicly recommended against it.
That work, and similar things, may be more important than
"fixing" SMTP... and new SMTP documents would be easier to write
and get agreement about if those issues were under control.
best,
john