[Top] [All Lists]

Re: email-arch intro

2009-05-14 13:21:37

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 prescriptive.

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 the architecture."

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 <>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

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