[Top] [All Lists]

Re: email-arch intro

2009-05-15 12:26:24

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

<Prev in Thread] Current Thread [Next in Thread>