email-arch intro

Hi all,

In among all of the other balls I have been juggling (or dropping 
depending on your view of it), I've definitely let this one get far 
too close to the ground. I've been talking to Klensin about his 
earlier expressed concerns regarding the doc, and found talking to 
Crocker who (shock of all shocks) seems to agree with the overarching 
concern. What it comes down to is that the email-arch doc ought not 
turn into a club with which to beat other standards (or the 
applications that implement them). The architecture presented in the 
document is a model under which we believe our protocols work, but 
there is always a difference between architecture and implementation 
and sometimes it is perfectly fine for protocols to break with the 
architecture.
So, I think the architecture document needs an intro somewhere saying 
as much. Here's an attempt taken from my conversations with both of 
them:
---
1.3 The Role of This Architecture

An Internet service is an integration of related capabilities among 
two or more participating nodes. The capabilities are accomplished 
across the Internet by one or more protocols. What connects a 
protocol to a service is an architecture. An architecture specifies 
how the protocols implement the service by defining the logical 
components of a service and the relationships among them. From that 
logical view, a service defines what is being done, an architecture 
defines where the pieces are (in relation to each other) and a 
protocol defines how particular capabilities are performed.
As such, an architecture will more formally describe a service at a 
relatively high level. A protocol which implement some portion of a 
service will conform to the architecture to a greater or lesser 
extent, depending on the pragmatic tradeoffs they make when trying to 
implement the architecture in the context of real-world constraints. 
Failure to precisely follow an architecture is not a failure of the 
protocol, nor is failure to precisely cast a protocol a failure of 
the architecture. Where a protocol varies from the architecture, it 
should of course explain the reason for the variance. However, such 
variance is not a mark against a protocol: Happily, the IETF prefers 
running code to architectural purity.
In this particular case, this architecture attempts to define the 
logical components of Internet email and does so post hoc, trying to 
capture the architectural principles that the current email protocols 
embody. To different extents, email protocols will conform to this 
architecture more or less well. Insofar as this architecture differs 
from those protocols, the reasons are generally well understood and 
are required for interoperation. The differences are not a sign that 
protocols need to be fixed. However, this architecture is a best 
attempt at a logical model of Internet email, and insofar as new 
protocol development varies from this architecture, it is necessary 
for designers to understand those differences and explain them 
carefully.
---

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