[Top] [All Lists]

Re: [Fwd: More information requested on publication status of draft-crocker-email-arch]

2009-05-27 14:41:15

Pete Resnick wrote:
This is an architecture document. We don't do these much anymore in the IETF, and this one is particularly strange because it is describing an architecture for a deployed service. However, I don't think that means we should shy away from it. We in the email community have needed this document for a *very* long time. We end up re-discussing architectural issues in each new WG just to get our terms straight and constrain solution spaces (cf. LEMONADE, MARID, DKIM). And we need to have a document to point to so that newcomers can couch their proposals in terms we understand without having to re-argue the model every time. But in order for it to work in these roles, and for it to have the ability to evolve over time, it really needs to be a standards track document.

I agree with everything but that last statement. We don't need to declare this one model as the Standard Model in order to use it in our discussions. An Informational document should serve that purpose. Making it a standard will only discourage the development of better models in the future. Surely, you can't think this is the only or even the best model we will ever have.

I too have been frustrated by futile arguments over terminology, but I believe this futility comes from the politics of the situation, not an inability to agree on terms for a discussion. When people are not driven by politics, or some hidden corporate agenda, and are actually wanting to move a discussion forward, it is not hard to agree on a model and terminology, at least for that one discussion. If people want to block progress in a discussion, then saying you MUST use the terms and models in this document will as likely help those who want to block progress as help those who want to move things forward.

Standards should constrain what we do in implementing protocols, not limit our thinking on models. Standards are needed to ensure interoperability of these implementations, not try to get everyone to think the same. Perhaps the few things in this document that need to be standardized should be labeled with MUST and SHOULD, and the rest clearly understood to be just a model. The semantics of the Mail From address is certainly one of those things. The ADMD diagram is not.

It may be that this model will be so widely used over the next few years that it becomes a defacto standard. That's the way things work in science, anyway. There are no committees to declare one or another scientist's theory as "the standard". I think it has worked quite well.

Yes, there will inevitably be differences between the overall architecture of the system and the protocols that instantiate it. There are simply pragmatics which make such compromise required, and it is in fact a healthy tension. And yes, that fact means that some people will do stupid things, like claiming that where the architecture and protocols diverge, the architecture must win. There will always be such folks who don't understand that sometimes pragmatics prevail over architectural purity. But I think to not call this document what it is (i.e., an evolving community consensus on the email architecture) in fear of how it might be used is frankly a bit nuts.

It is already happening. I have been in discussions where we have deadlocked over the words actor and agent. I use them in their original plain-English meanings, as an individual or organization. The person with whom I was attempting to have a discussion insisted, even after repeated clarification of this point, that everything I said was wrong. In his mind, agents are machines and cannot be anything else.

Let's address the problems as they arise rather than further diminishing the meaning of our document series.

What will most diminish the value of IETF standards? I believe it is having those standards widely ignored. That will happen if you over-reach with this document.

************************************************************     *
* David MacQuigg, PhD    email: macquigg at   *  *
* Research Associate                phone: USA 520-721-4583   *  *  *
* ECE Department, University of Arizona                       *  *  *
*                                 9320 East Mikelyn Lane       * * *
*        Tucson, Arizona 85710          *
************************************************************     *

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [Fwd: More information requested on publication status of draft-crocker-email-arch], David MacQuigg <=