[Top] [All Lists]

Re: email-arch intro

2009-05-14 09:51:37

Hi Pete,
At 20:23 13-05-2009, Pete Resnick wrote:
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

I'm glad to hear that you agree with each other.

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.

One of the reasons not to have a rigid architecture (after that fact) is that the protocols won't be an exact fit.

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

One of the "problems" with the email-arch is that the document does not constrain itself to the higher level only. It would have made matters easier if the document was descriptive instead of prescriptive.

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.

According to the above paragraph, the protocols (RFC 5321 and RFC 5322) should explain why they vary from the architecture.

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.

If I understand correctly, the last part of the last sentence excludes existing protocols from having to explain the variance. What you are proposing is to have designers explain the differences between the architecture and core protocol documents. That presumes that the designers have a good understanding of these documents. The documents are already quite lengthy and I think that we will see more inconsistencies once we go down that path.

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