[Top] [All Lists]

Re: email-arch intro

2009-05-14 19:36:44

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."

The architecture will develop, it will be refined over time, and it ought to be prescriptive for how to write an interoperable protocol in the land of email. That sounds to me like a standards-track document. But like everything else we do here (unlike some other standards organizations we all know and love), there are going to be rough edges in both protocols and architectures that make them not completely align. That's OK. We like rough edges.

That's what I'm hoping that intro expresses.

Pete Resnick <>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

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