Hi. I am opposed to publication of this document on the standards track. I believe that it should be published, but as an Informational or FYI document with an IESG statement that stresses that it represents a consensus description of the Internet email model, that other descriptions are possible, but that the document is not a Standard and not normative in any way. If the IESG also wanted to make a statement indicating that the terminology in this document would be required for _new_ protocol specification in the email area, I think that might be an acceptable compromise for those who believe that is the document's purpose.
I do not consider that an ideal solution. I think documents like this one strongly suggest that our categories of Proposed/ Draft/ Full Standard, BCP, Experimental, Informational, and perhaps FYI are not well-suited to all of the documents circumstances we regularly encounter and that it is time to review and revise those categories. But I don't believe the community would be well-served by blocking this document until that work is done. My opposition to Standards Track is based on several concerns. Any one of these would, in my opinion, call standards-track publication into question. The main argument I see for standards-track publication is that it would give the document greater authority. However, I believe that level of authority is not justified, that it would be problematic in other ways, and that the document is not quite ready for it. The most important of those concerns are: (1) Publication of a retrospective "architectural" document as a standard is inherently problematic. It is not a specification or model for how to do something, but a retrospective description of what exists. Even though it might be used to shape future developments and protocols, it remains a retrospective description -- an attempt to impose a model where none really exists with strong consensus-- not a forward-looking architectural specification. (2) This is not a protocol specification. As a Proposed Standard, there would be no model for interoperability testing or examination of deployment unless it were compared to implementations of the existing standards-track protocol specifications. And we know that it would fail such a comparison, at least in some details. (3) I believe that the community has significant experience that, no matter what disclaimers appear in the document, its publication on the standards track will be used to argue that other standards are "wrong". Whether that leads to demands that any modifications of those standards be brought into compliance with this document or is used as an argument for partially disregarding whatever they say, that would be a problem. The new introductory material reduces this problem somewhat, and it might occur even with an informational document, but I believe that not having it identified as a standard would significantly reduce the scope of the problem. (4) If this were to be published as a standards-track spec despite the reasoning in the rest of these comments, I believe it should explicitly call out differences in terminology or concepts from existing standards-track protocol specifications and discuss those differences. To do otherwise invites more, rather than less, confusion. (5) The extensive discussions on the ietf-smtp list and elsewhere since the first Last Call was initiated suggest that there are still significant disagreements in the community about the accuracy and applicability of the model and about the terminology used, especially with regard to administrative boundary issues and handoffs. I think that each of those could be resolved in some way (possibly by explicitly documenting the differences and rough edges), but that doing so would not be worth the added effort relative to the advantages of getting the document published sooner, rather than later. However, if the document is going to be published as a consensus standard, rather than as a description, I believe that those issues do need to be addressed and settled, one at a time, probably via a WG process. For the information of the community, I sent a much longer and more extensive analysis of the situation as I saw it to the IESG some time ago. Since that discussion has been circulated privately beyond the IESG, I don't see any further advantage in treating it as confidential. I have attached that note to this one for further reading by anyone who wants to do it, but I believe the notes above constitute a reasonable summary. In particular, the attached notes have been interpreted as a suggestion from me that the document not be published at all. That is not the case: I think it is more than useful enough to be published, just not on the standards track. I also do not believe that the investment of significantly more effort in it would yield a significant payoff even though I believe that effort is required for a standards-track document that will not progress further. regards, john
--- Begin Message ---Hi. Given that cluttering this discussion with the tradition of a long-standing feud between Dave and myself would not help anyone and that most of these comments are ultimately procedural rather than specific technical criticisms, I've decided that the circumstances are "exceptional" and hence am sending this directly to the IESG. I do not believe that any of the comments in this note will be a surprise to any of the people who have been most active in getting the subject draft together. I have no objection to the IESG making the note public if you conclude that doing so would be in the best interests of the community. First, this document continues to improve. The first Last Call caused sufficient changes to require a second Last Call. Discussions after that one caused further substantive changes. Some of those changes are, themselves, controversial enough to have stimulated significant additional discussion from people who are sensible and well-grounded in Internet email systems (as well as from a few who may be less grounded and/or qualified). Most of those discussions have occurred on the ietf-smtp list. The advantage of having discussions there is that it has kept the discussions off the main IETF list and thereby avoided contributing to what, from the standpoint of most of the community, would be noise on that list. The disadvantage is that it has largely hidden from IESG members who do not follow that list just how much controversy remains about this document and how much discussion is ongoing about it (much of it non-converging). The latest version (to be posted today, I believe) represents a further improvement, but is sufficiently different from the previous ones to suggest that yet another Last Call would be in order. I do not believe that is in the best interest of the community because discussion of the document draws energy away from other work and that stretching it out could easily lead to consensus by attrition as those who do not believe they are making progress wander away in frustration. There is an alternate proposal below. There are, I believe, three fundamental controversies with this document. At least two of them are sufficiently fundamental that no amount of document tuning is really going to resolve them and create consensus instead, even though it might reduce the pain: (1) The document is written to be normative and prescriptive but is inconsistent with a number of basic protocol documents (in part because they are inconsistent with each other). Even if it contains disclaimers --for existing documents or going forward-- it is inevitable that the differences in terminology and model will cause confusion in the broader community, lead to discussions about where the protocol standards are "wrong" and the architectural one is "right" (or vice versa). Such confusion benefits no one and, in the email world, has often been used to justify bad behavior. The new disclaimer text improves on the situation for those who read the documents carefully, in context, and with good intent, but will do nothing to help with those who either want to justify behavior that is inconsistent with one set of specifications or the other or who wish to impede progress by insisting on conformance with the language and model of the architectural document. (2) It is a reality that there are fundamental differences in perspective about Internet mail and the underlying models. One of these is actually at the technical root of the ancient disagreements between Dave and myself. With the understanding that I'm oversimplifying both views, one is that the important part of the model is the transport mechanisms that actually get the messages across the network and delivered. Consequently, what appears in headers, etc., is just metadata, some flexibility of interpretation and actions at the endpoints is appropriate and we should be looking at things primarily in terms of the transport and what happens on the actual wire and what affects that. The other view is that the headers and message formats are important, the transport is relatively unimportant --no more important than, say, the details of TCP to an application-- and that our focus should be on the message before and after the transport process, with the latter important only to the extent of getting something across the network. The differences get especially important when one starts talking about gateways between more or less disparate email systems and about extensive relaying (at the behest of either the sending or receiving system). They are less important in practice with initial-point-to-destination-point Internet mail. We have successfully gotten through the last quarter-century or more, not by ignoring these differences but by keeping them in healthy tension, trying to allocate functions between them, and creating a certain amount of interpretation "slop" that has contributed positively to interoperability. When something can be handled differently according to the different perspectives, we've tended to have acrimonious arguments but to be able to sort things out, largely because no one can really point to a higher authority. The difficulty in this situation is that this architecture document is clearly written from one of those perspectives. The other perspective has been dismissed, sometimes fairly abruptly. If we standardize the one perspective, it is inevitable that it will be cited as an authority to "settle" the decisions about how some new capability should be handled without the healthy discussions that have occurred in the past. Again, we have not been able to reach consensus on which of the two approaches is "correct" for the last quarter century. I see that as a problem only if the intent is to publish draft-crocker-email-arch as a normative consensus document. (3) Partially because no one could come up with anything better, the document uses some terminology that is drawn from other contexts, contexts in which that terminology has very specific meanings and/or some semantics that are inappropriate for Internet mail. Because people often tend to read long documents quickly, looking for information, rather than beginning to end and keeping all local definitions in mind, this can be a source of additional confusion and, in the long term, contention. Perhaps the worst example of this is "ADMD" which, in ISO MHS/X.400-land, has a very specific meaning that implies both government authorizations and direct ADMD-ADMD handoffs with formal bilateral arrangements. But there are others. Conclusion and Recommendation: While Pete's new disclaimer text helps quite a bit, one can imagine ways to improve it further, point out some of the issues and differences above in a clear way in the document, and perhaps even further tune the document. It could also, in principle, be rewritten from a prescriptive form to a descriptive one (far more appropriate to what we usually think of as an "architecture" document), but I believe that change would be violently opposed by several of those who have contributed to the document. I think we are past the point of diminishing returns and that the amount of energy required to "fix" the document far exceeds the likely value of the improvements... and that assumes that consensus could be reached, which I believe is unlikely. This document should be published, but it should not be published in a way that gives it even the appearance of formal normative status. Instead, it should be published either as Informational (possibly taking advantage of the new provisions in "headers-and-boilerplate" to specify that it does represent IETF consensus _as a description_ or, if the IESG wants to bring out an old category that we have never quite retired, as an FYI (those documents are, by definition, consensus documents that are descriptive, rather than normative). It would also be desirable to reconsider the title in the light of the comments above. Something like "An Overview of the Internet Mail Model" would be much more clear as to role and purpose than characterizing it as _The_ Internet Mail Architecture (emphasis added). Thanks for listening. regards, john
--- End Message ---
_______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
