I am completely aware that if a model is too complicated for understandability of the intended consuming audience it will be completely ignored. There are several standards, both on and off the internet, where this has commonly occurred. Perhaps the most well known case is W3C's WAI2 standard, which produced much excessive whining because of the complexity of practice required to achieve that standard. Much of this whining was unfounded and did nothing, in this one case, but extend the development process of the document. The current ECMA Script standard, however, is so complex that nobody seem to be capable of adequately translating it to something that people new to the language are capable of understanding. This results in many books on the subject that are wrong or miss necessary fundamentals. As a result people commonly ignore the recommended methods of writing the language and do whatever the hell they want so long as it does not break immediately in a single limited context, which will result in a break.
A standard must not, however, strive to limit the subject of its description merely for the point of simplicity. When limitation occurs from such simplification innovation of otherwise unexplored approaches is blocked even if the stated limitations were unintentional. In my opinion blocking innovation is supremely more harmful than a standard which is ignored because that harm is immediately evident and not commonly known opposed to harm from an ignored standard which is not immediately evident but is well known and understood. As a result I would rather the models be too complex for us mere mortals to grasp so long as they are accurate and do not impose constraints that not absolutely necessary. I understand this is complicated work as such constraints may appear as common usage and not viewed as a constraining practice. Thanks, Austin Cheney -----Original Message----- From: Hector Santos [mailto:[email protected]] Sent: Sunday, May 17, 2009 9:27 AM To: David MacQuigg Cc: [email protected]; Cheney, Austin Subject: Re: Email System Model In my view, you have an over simplification and Crocker's doc is attempt to model a more complex integrated world. Its one view abeit one that attempts to prescribe a model based on STDs and RFCs. I think it could of been done in a more readable fashion, like a Requirements/Optional Grid to start work ala RFC 1153 I do think, in my opinion, your first illustration is pretty fundamental and much easier to understand, grasp without reading the context. IMO, Dave's doc is too overwhelming for MOST people to read - totally only useful for highly IETF trained geeks. -- Sincerely Hector Santos http://www.santronics.com David MacQuigg wrote: > > I'm splitting this off as a separate topic, so we don't distract from > the discussion on email-arch. In this thread, I welcome discussion of > the validity of the model at http://en.citizendium.org/wiki/Email_system. > > This model is focused on what happens at the administrative level in one > transit through the Mail Handling System, but it can easily extend to > systems involving multiple transits. To model the situation Austin > describes, I would put two "one-transit" models in series. > > Author ==> MSA/Transmitter --> / --> Receiver/MDA ==> Mediator > > Mediator ==> MSA/Transmitter --> / --> Receiver/MDA ==> Author > > The Mediator is a separate user-level Actor, even if it is automated. > The final Recipient is the original Author. > > I'm not sure if I fully understand Austin's concern, so I don't know if > more elaboration of the model will help. A model is only as good as its > ability to clarify real-world systems, helping with questions like "What > happens if ...", or "How should I ...". > > Best Regards, > David MacQuigg > > > Cheney, Austin wrote: >> 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 >> > > >
