Re: [Fwd: More information requested on publication status of dr

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          *
************************************************************     *