[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Asrg] 6. Proposals - AMTP (rev 01)

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@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg