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

pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102