Re: [Fwd: More information requested on publication status of draft-crocker-email-arch]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On May 26, 2009, at 8:07 PM, Dave CROCKER wrote:
Alexey Melnikov wrote:
'Internet Mail Architecture' <draft-crocker-email-arch> as a Proposed Standard The IESG has received a concern about the intended publication status of this document and wishes to confirm the community's preferences.

Folks,

As the document's author, my preference for its status is obvious. But I thought it worth commenting on the reason I believe a document of this type -- and this particular document -- warrants standardization.

Any protocol specification that we do standardize is a component of an integrated service. Standardizing a component, without standardizing the context into which is it being used, is a bit like writing a precise contract for a supply of screws or a heating element or bits of sheet metal, but not specifying their integration into a toaster, or some other particular (integrated) product.

The screws or heating elements might be used for a variety of other products. There's nothing wrong with that. Those other uses do not constitute a "violation" of the toaster specification. They're just different.

So it should be for an integrated service like Internet Mail. We did not feel compelled to do the specification long ago because back then the service began in a kind of cottage industry within a small community. The systems specification was informally shared. The community, now, is much larger and shares none of that original history. This constantly causes confusion in discussions about the integrated service. So, that community needs to see a specification for this particular service we call Internet Mail.

While this document has value, and I would like to applaud your effort, it seems counter productive to impose architectural concepts as the definition of a standard. While the introduction that Pete suggested helps, it may become difficult to know which documents are authoritative. Your description of this document does not help. The status of standard should be limited to documents that describe specific interactions, where these protocols may conflict with previous architectural concepts that carry the status of informational. In doing so, there would be less danger of confusion.

They need to see it as a standard for the same reason they need to see the components as standards.

Email was not defined in this fashion, nor are the many aspects of interaction related to email assured to remain compliant with any fixed architectural concept. The components of a standard define the interaction. There is no overarching requirement to remain complaint with a general architecture, nor should there be at this time. Email is currently suffering from what might be described as the tragedy of the commons, and an aversion of some providers to identify themselves. It seems inevitable that subtle changes to email architecture will be needed. Having such efforts considered out-of- standards compliance may inhibit otherwise necessary changes. If email was not suffering from such levels of abuse, the situation could be different as a general change would not be desired. As such, it seems a less disruptive and less confusing to adopt this as a highly valuable informational document.

-Doug


_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]