Re: email-arch intro

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.

pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102