Re: email-arch intro

Pete Resnick wrote:
> On 5/14/09 at 3:11 PM -0700, David MacQuigg wrote:
> > On 5/14/09 Pete Resnick wrote:
> >
> > > 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.
> > [...]
> > 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.
> So, I'm going to try and split a relatively fine hair here, so bear 
> with me:
> - I *don't* want this document to be used as a club against 
> well-established (and well-understood) protocols. To use a personal 
> favorite example, RFC 5321 and current implementations have a lot of 
> "nuance" when it comes to address correction , forwarding, aliasing, 
> etc. Some examples are "ReSender", or "Gateway", or "Alias", or 
> "Mailing List" from email-arch, and some simply don't fit cleanly in 
> one of those architectural categories. However, RFC 5321 explains how 
> implementations are to deal with each of them and describes the edge 
> cases. It is not reasonable to say, "RFC 5321 must be corrected so 
> that it agrees with the architecture down to the last detail." Where 
> they disagree, the protocol with the explanation wins the day.
> - I *do* want this document to be used as a club against proposed 
> protocols, especially when they have no implementation base, if those 
> protocols differ significantly from the architecture *without any 
> explanation*. When someone comes along and writes a protocol or 
> implementation that assumes that the RFC5321.MailFrom is the author of 
> the text of the message, I want to be able to say, "Look dude! That's 
> not what RFC5321.MailFrom is for. Go read the bloody architecture and 
> get your mind right, or give me a long interesting explanation about 
> how the state of the world you live in is different than what the 
> architecture says and convince me that your use is reasonable."
I understand the need to set a high hurdle for proposed protocols which 
differ significantly from existing standards, and  your example of the 
MailFrom address is a good one.  A clear standard on the purpose of this 
address would have avoided a major debate with supporters of the SPF 
protocol.
What I don't understand is the need for a new standard to re-state what 
should be in the existing standards.  I would rather see the purpose of 
MailFrom clarified in RFC-5321, and not worry about the exact wording in 
email-arch.  (It's still not clear.)  If we can't get it clear in the 
primary standard relating to this protocol, slipping clarifications into 
lesser-known standards might only add more confusion, and not resolve 
the issue.
We can avoid this problem by keeping the document as a best effort to 
explain "the way things are", rather than what I am hearing now for the 
first time, "the way things ought to be".  The vast majority of 
Forwarders do not re-write the MailFrom address, contrary to the 
expectations of the SPF community.  You can state that as a fact, 
without saying "and that's the way it should be".
I value email-arch for its explanation of the way email systems work, 
not its effort to standardize things that have been unclear.  Perhaps I 
am misunderstanding what it is you are wanting to standardize.  If it is 
models and terminology, I think that would be a mistake.  Better models 
for email systems are still being developed.
Best Regards,
David MacQuigg