Re: email-arch intro
On 5/14/09 at 6:36 AM -0700, SM wrote:
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
I disagree, and that is one of the reasons for this intro: We want
the architecture to be prescriptive insofar as *any* IETF document is
prescriptive in that it helps interoperability. What we don't want is
for the document to be used to prevent interoperability by forbidding
reasonable protocol choices. We are not going to completely prevent
people from being idiots, but it would be nice to use this document
to say to folks with new protocols, "Get with the program. If you're
not going to conform to this architecture you better tell us why!"
while still being able to point to this section and say, "No, we're
not going to rewrite SMTP just because it does not fully conform to
I may be a bit more sanguine than you (or Klensin) about this stuff,
but I think this paragraph addresses those issues.
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.
And they do. There are many places where they describe that they have
made compromise choices.
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.
No, it's simply saying that new protocols will have to understand why
they're differing and explain it. It would certainly be nice for
existing protocols to have those explanations, and as I said earlier,
they do in many instances (albeit in a "pre-hoc" way).
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.
(*Shrug*) I think you underestimate what we can expect from folks.
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102