At 11:13 PM 9/28/2003, Yakov Shafranovich wrote:
It would be great if you can run your proposal past those two checklists,
and include the results inside the main draft instead of the separate FAQ.
I read the documents you referred to and applied what I thought was
relevant when I did my research before writing the current draft.
I did not write a point-by-point interlinear analysis of AMTP with respect
to the documents you cited, and regrettably I don't see how I can get that
done any time soon. I am preparing another draft and I'm busy writing the
proof-of-concept code. AMTP is on track, in spite of a heavy day-job work
load, and I am pleased with the momentum I have going.
OTOH, comments from this group and the other groups I've been working with
have been very helpful. I appreciate that and thank you for it. Adjustments
are being made to the draft, and specific acknowledgements are included there.
This way we can evaluate the impact of the proposal easier and can have
the information in the document itself, instead of a separate FAQ.
Yours is a research group, and as such its mission is naturally academic.
The AMTP draft is a protocol specification. Its mission is practical: to
present a clear and succinct description of the AMTP protocol so that
people can build compliant and compatible implementations. I don't see that
an analysis such as that you suggested would support the practical goal of
a protocol specification.
Your group is evaluating AMTP against the goals set out in your charter
documents. That's what the ASRG is here for, and I appreciate it.
Second, I would like to ask if you can clarify for us whether your
proposal seeks to replace SMTP completely. Section 3 of your draft says:
Yes, AMTP is intended as a replacement of SMTP. It is also substantially
derivative of SMTP, a design decision intended to ease transition.
" The idea of replacing SMTP is appealing because it
permits thinking in terms of creating an infrastructure
that has accountability and restrictions built in.
Unfortunately an installed base the size of the
Internet is not likely to make such a change anytime
soon. It seems far more likely that successful spam
control mechanisms will be introduced as increments to
the existing Internet mail service."
I am acutely aware of this issue and AMTP addresses it by maintaining the
overall design and command set of SMTP. AMTP is substantially derivative of
SMTP and as such the transition should be, not entirely trivial, but as
close as possible without sacrificing its operational advantages.
In particular we would like to consider whether it would be more viable to
reformulate your protocol as an ESMTP extension rather than a replacement
for SMTP.
I considered that approach carefully. Ultimately I realized that the SMTP
protocol REQUIRES (in the sense of RFC2119) a level of promiscuity that
would prevent AMTP from accomplishing its goals.
I spent many hours on transitional planning before I wrote the first draft,
and I am working on documents to describe the transition process. In short,
once I have working code I will provide tools to make the adoption of AMTP
sufficiently painless that I expect it to be adopted, gradually, by a
sufficient number of hosts to constitute a critical mass. Time will tell of
course, but I have yet to see any argument that convinces me otherwise.
--Bill
---
Never send a monster to do the work of an evil scientist.
~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~
- Home <http://bw.org/> | Whois <http://whois.bw.org/>
- Music <http://music.bw.org/> | Blog <http://blog.bw.org/>
- Gimme back my email! <http://amtp.bw.org/>
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg