Re: [Fwd: More information requested on publication status of draft-crocker-email-arch]
David MacQuigg <macquigg@ece.arizona.edu> Wed, 27 May 2009 18:23 UTC
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RIN9Lm072960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 11:23:09 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4RIN9XB072959; Wed, 27 May 2009 11:23:09 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f
Received: from smtp108.prem.mail.sp1.yahoo.com (smtp108.prem.mail.sp1.yahoo.com [98.136.44.63]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n4RIMwLU072947 for <ietf-smtp@imc.org>; Wed, 27 May 2009 11:23:08 -0700 (MST) (envelope-from macquigg@ece.arizona.edu)
Received: (qmail 75721 invoked from network); 27 May 2009 18:22:58 -0000
Received: from ppp488.broadband01.tus.dakotacom.net (macquigg@69.9.25.232 with plain) by smtp108.prem.mail.sp1.yahoo.com with SMTP; 27 May 2009 11:22:57 -0700 PDT
X-Yahoo-SMTP: w0y7P.WswBDZ0jJGN667TA9o5a6IoN_2gYtT
X-YMail-OSG: seXe_qMVM1lTVU6hx.eIm6HfAJSMcPlc3ysghnddVBOi5kPG5IehvRlI2AK7lGPrt1qlT0utzM_wUlexFEzO.yg4K8Lj_WyW10tHPK8ZU6ALdeDbaF1FmTZoxHLsravNZN6HV9PqdmnDaSylQ0ID8ZlLiH_VEInCW5FLrn3RhYBULG2T7dDhcGknZ0kfFPjmW37KAA0FCdc4nm4RQCqaZkwSfXgxgsrjuUOHPSXdP8AmQsWQkrSRAOUMGzHLxtqJel28HSlGcWDLbIgylb.nI_B6fp1P_4DjfMAvUnwntv2WvDxGXxqBUZyJ6Z_P2nb6J3fT_.yXFONYmrUfgYX0
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A1D8500.3040108@ece.arizona.edu>
Date: Wed, 27 May 2009 11:22:56 -0700
From: David MacQuigg <macquigg@ece.arizona.edu>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: Pete Resnick <presnick@qualcomm.com>
CC: Alexey Melnikov <alexey.melnikov@isode.com>, ietf@ietf.org, ietf-smtp@imc.org
Subject: Re: [Fwd: More information requested on publication status of draft-crocker-email-arch]
References: <4A1C6239.9010909@isode.com> <p06250101c642158ad006@[75.145.176.242]>
In-Reply-To: <p06250101c642158ad006@[75.145.176.242]>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-smtp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=unsubscribe>
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 ece.arizona.edu * * * Research Associate phone: USA 520-721-4583 * * * * ECE Department, University of Arizona * * * * 9320 East Mikelyn Lane * * * * http://purl.net/macquigg Tucson, Arizona 85710 * ************************************************************ *
- Re: [Fwd: More information requested on publicati… SM
- Re: [Fwd: More information requested on publicati… David MacQuigg
- Re: [Fwd: More information requested on publicati… Dave CROCKER
- Re: [Fwd: More information requested on publicati… Pete Resnick
- More information requested on publication status … Alexey Melnikov