David MacQuigg, One difference that I see is an inferred conceptual implementation that is explicitly not presumed in your model, while being completely unmentioned or challenged in David Crocker's models. This inferred conceptual implementation is that a mail server is a mediator in the communication process between author and intended recipient, but a mail server can become an participant if were acting as an application response.
Let me demonstrate this in the model of software as a service. Suppose I were communicating with a known destination, such as a retailer, who receives and replies to mail as an automated application system. At the same time another content application system is installed on the local mail server of this intended recipient that is capable of intercepting communications, making decisions upon those communication, and sending automated responses that beg further communication from the initial author. In this model application programming and scripting can be running in response to human supplied communications from the originating author, while those same applications can also be relaying data relevant only to the distant end to the intended recipient for status responses and session content details. In that model the mail server of the distant end transforms from a mediator to an intermediate responding agent. Such a model could allow things such as cloud computing or ecommerce. It is not practiced by anybody, because a definable characteristic that is uniformly described and universally understood would have to exist in the content to provide such a hook for application engagement. So, in summary, a mail transfer agent MUST NOT be presumed to be separate from a designated point of intended receipt. Crocker's models do not mention or challenge this concept, but your model does imply such a challenge. Thanks, Austin Cheney -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of David MacQuigg Sent: Thursday, May 14, 2009 5:11 PM To: [email protected] Cc: Pete Resnick; SM; [email protected] Subject: Re: email-arch intro On 5/14/09 Pete Resnick wrote: > On 5/14/09 at 6:36 AM -0700, SM wrote: >> One of the "problems" with the email-arch is that the document does >> not constrain itself to the higher level only. It would have made >> matters easier if the document was descriptive instead of prescriptive. > I disagree, and that is one of the reasons for this intro: We want the > architecture to be prescriptive insofar as *any* IETF document is > prescriptive in that it helps interoperability. My first reaction to Pete's intro was - Yea, that's great, says it all. Now I'm not sure what it means. Upon careful reading, it looks like it is intending to protect protocols and implementations (but not anything else) from anyone wanting to wield this document as a "club". Why not just say "This document is intended to describe a complex real-world system, and provide a model and terminology that will improve our understanding of that system. It is not intended to add additional requirements to regular IETF standards, or enforce conformity in any way." If the model is useful, as I believe it is, it will be widely used. If not, it won't become an impediment to development of other models. Perhaps an example will help. I have been developing an "administrative-level" model for email systems, which I view as an extension of Dave's Figure 4. See http://en.citizendium.org/wiki/Email_system for a more complete description. I have tried to conform with Dave's terminology, but found it inadequate to fully describe what is happening at the administrative level. This doesn't mean Dave's model is wrong, just that it is more focused on the Relay-level, and provides only a very general description of the "ADMD level". For a textbook presentation, we need something more than Figure 4, but less than what is in Dave's draft. What I worry about is a document like this becoming a basis for obstructive arguments over terminology. I would like to say in some future discussion - "Let's use the terminology from RFC-<whatever number it gets assigned>, but with the following differences:" Then add a few definitions appropriate to the topic at hand. Maybe my worries are un-necessary. Let's find out now, rather than later. Is there anyone here who thinks the differences between my model and Dave's are a problem? Can you suggest improvements in either model? Best Regards, David MacQuigg, PhD Research Associate ECE Department, University of Arizona http://purl.net/macquigg
