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 mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
