[Top] [All Lists]

email-arch intro

2009-05-13 23:50:20

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.

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

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