|
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.
Regards,
-sm
|
|