[Enum] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail"
lconroy <lconroy@insensate.co.uk> Wed, 15 June 2005 13:38 UTC
From: lconroy <lconroy@insensate.co.uk>
Date: Wed, 15 Jun 2005 09:38:45 -0400
To: "'enum at ietf.org>"
Subject: [Enum] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail"
Message-ID: <30e5bff888ee593a196af6faa4b149bc@insensate.co.uk>
MIME-Version: 1.0
Content-Type: text/plain
Status: RO
Hi Folks, For those of you not registered on the IETF-General list... If you are wondering why the message Enumservice registration(s) document is not an RFC yet... During IESG evaluation, we were asked to add a normative reference to this Lemonade document. We did. Now that referenced document is subject to an appeal against standardisation. As such, the Message RFC-to-be is stuck in the RFC-Editor queue waiting on the normative references to reach standardisation (or not). all the best, Lawrence Begin forwarded message: From: John C Klensin <john-ietf at jck.com> Date: 10 June 2005 19:49:17 BST To: Brian E Carpenter <brc at zurich.ibm.com> Cc: Randall Gellens <randy at qualcomm.com>, iesg at ietf.org, ietf at ietf.org Subject: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" Brian, This is a formal appeal addressed to you as IETF Chair and, if necessary and appropriate, to the IESG, over the recent approval of draft-ietf-lemonade-mms-mapping-04.txt, "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" as a proposed standard. The appeal is self-contained and self-explanatory and proposes both specific and general remedies to the problems it identifies. It raises questions, not only of technical content, but of the procedures used to review documents within WGs as well as between WGs and other areas of expertise and the mechanisms used to determine adequacy of IETF consensus. The appeal necessarily takes no position on whether the problems demonstrated by this particular document and its approval are limited to it as an exceptional and deviant case or whether they have more general implications, but perhaps that is a topic to which the community should give some consideration in parallel with your, and the IESG's, evaluation of the specific issues raised. regards, john This is an appeal of the approval by the IESG of "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail (draft-ietf-lemonade-mms-mapping-04.txt) as a Proposed Standard. The appeal specifies that the document, as written, (i) violates an important and long-standing design principle for Internet applications protocols, does so without compelling justification, and puts existing deployed and conforming programs at risk by doing so (ii) represents a process violation in that substantive changes were made to earlier versions without review and approval by the relevant WG (iii) contains a number of other errors or probably- inappropriate specifications that strengthen the impression that the document was approved by the IESG without adequate evidence of review and consensus in the WG and cross-area review in the community It requests that the IESG suspend or withdraw the Protocol Action Notice, that it refer the document back to the relevant WG, that the conflict with existing norms either be eliminated or strong justification for retaining it be provided to the IETF community and consensus demonstrated that an exception be justified, and that the WG be asked to review the other changes suggested. ------------------------ Details: When the LEMONADE WG was formed, it was established on the basis of an agreement that it would make no substantive changes to the Internet mail fabric. That agreement was spelled out in the charter, which said: A primary goal of this work is to ensure that those profiles and enhancements continue to interoperate with the existing Internet email protocols in use on the Internet, so that these environments and more traditional Internet users have access to a seamless service. That agreement may have led to less intensive review of LEMONADE products, at least including this one, by members of the community who were not particularly concerned by work the WG did within the boundaries of that agreement and the scope statements based on it. To the degree to which the WG reached conclusions that pushed the boundaries of that agreement, an unusually high burden should be placed on it, and the responsible AD(s), to ensure that any specifications that could impact the existing email fabric are carefully reviewed in the broader community. Consensus must be demonstrated that the changes are both necessary and that they will not cause harm. Discussion with working group participants and review of the WG's mailing list archives indicates that the number of comments on this document received during WG Last Call was zero. Rather than meeting that high burden of review, there is no evidence at all that this document was examined by any significant fraction of the participants in the WG. This specification violates that principle and agreement. The handling of the specification as it passed through the WG and the IESG did not demonstrate the exceptional standard of care and review that is required to avoid interfering with the Internet's email fabric. It was also procedurally irregular even within normal standards of WG and community review. In particular, substantive changes were made to the specification between the version that was Last Called (-02) and the version approved by the IESG (-04), but a review of the WG's mailing list archive does not show any indication of WG review or discussion of those changes or of the newer drafts. Indeed, a review of the WG's archives did not show evidence of any review or discussion of this document in the last year and a half. We believe that any post-Last-Call revisions to the substance of a WG-produced specification must be sent back to that working group for review and approval, especially if it is probable that the need for the changes resulted from lack of adequate WG consideration in the first place. The overall conclusion that led to this appeal was that the document is severely defective in several ways and that there is no evidence that it represents proper review or consensus in the WG or the IETF more generally. Some, but not all, of what the appeal considers to be defects might be acceptable in a Proposed Standard if they had been carefully considered as tradeoffs within relevant communities of experts, but there is no evidence --in the document or in the WG archives-- that has been done. Other defects violate important principles of Internet mail and should not be permitted except in the absence of plausible alternatives and evidence of overwhelming support. Some fractions of these issues, but by no means all of them are, at least individually and in the opinion of those lodging the appeal, consistent with the types of rough edges that can be tolerated, indeed expected, in a Proposed Standard and could be noted simply for future reference and attention if and when the specification is proposed for advancement to the next maturity level. They are included here, as noted above, largely to illustrate that review and consensus about this document has been inadequate. There appears to be significant risk of harm if this document goes forward as standards-track implementation guidance for the public Internet. On the assumption that they will be corrected by the RFC Editor's process, this appeal does not address instances of bad grammar that make the document harder to follow that is desirable. Each identified problem below is followed by a brief statement of "REMEDY", which is a recommendation about what should be done if that portion of the appeal is judged to be valid. Specifically: (1) In order to allow extensions by private agreements among interchanging parties, the original definitions of the file transfer protocol provided that commands starting in "X" would always be treated as for private use and that such commands would never be standardized. That model was carried forward into the email system as private-extension commands in SMTP and private-extension ("X-") headers in RFC 822. In each case, the principle has been that we do not standardize such headers or assign semantics to them in standards-track specifications. Not only do Email systems all over the net assume that such headers can be safely discarded, but we have, for years, told the designers of such systems that they cannot rely on the interpretation of any such header in the absence of specific bilateral agreements (and presumed authentication to at least some level) with the initiator. The requirement that X-headers be treated in a special way was relaxed with the adoption of RFC 2822, but remains controversial. At best, it is unwise to violate the principle in this document unless doing so is necessary or represents extremely well-established operational practice. This specification violates those principles. It provides, e.g., that an X-MMS-Message-ID arriving from the MMS side "SHOULD" be mapped into an identically-named header on the Internet side to facilitate interpretation and conversion of that header back into an MMS environment. The problem here is not that the MMS environment has an X-MMS-Message-ID header (their problem, not IETF's) or that a mapping is required (although that issue is discussed below), but that the recommended _Internet_ is "X-MMS-Message-ID" and not "Message-ID" or "MMS-Message-ID". While the risk of problems is probably low, the principle is important. More important, there is no justification for violating the principle: the guidance given in RFC 2822 (and 822 before it) makes it clear that the WG could simply define and register "MMS-Message-ID:", translate whatever relevant form appears in the MMS environment into it, and then translate back as needed, without violating the "X-" rule or incurring even a slight risk of conflicts or ambiguity. Similar comments apply to X-Priority. The specification indicates how the X-MMS-Priority header on the MMS side can be mapped to the widely-used "Importance:" header on the Internet side. But it then specifies that it is reasonable to map X-MMS-Priority to "X-Priority:" and then assigns specific field values to the latter. It isn't good to standardize two fields with similar semantics: doing so raises interoperability concerns as different implementations give different interpretations if both appear. Further confusion is caused by the fact that "X-Priority" appears to be, as the draft notes, a class-of-service indication rather than an end-to-end message importance indicator. But, if there is a need to standardize or recommend some sort of priority field in addition to "Importance:", the standard Internet form should not use an "X-". REMEDY: Either remove these proposed mappings or define real, standards-track, headers, presumably MMS-Message-ID and/or MMS-Priority, for use in this situation. If two Importance/Priority fields are to be recommended (or even not forbidden), specify the semantics when their values are different. (2) RFC 822 defined a syntax for use in address fields when it was desired to not enumerate the recipients, the so-called "Group syntax". That syntax was carried forward into RFC 2822. By contrast, we have generally been careful to avoid assigning semantics to information that appears in comments, or specifying the text or syntax that should appear in such comments, at least unless there are no other possibilities. This specification violates those rules: rather than using the group syntax specified in RFC 2822, it recommends (even if only as a "MAY") that a field containing a comment (but no data) be supplied instead of the group syntax. Interestingly, a reading the syntax productions of RFC 2822 (or RFC 822) indicates that To: (some comment) is equivalent to To: which is not permitted ("To:" requires an address-list) so this recommendation actually violates the standard and is hence not tolerable. In is interesting to note that, while what is done in the MMS environment does not bind what occurs on the Internet side of the gateway, the MMS specification (Section 3.2.1.2 of X.S0016-340-0) provides: In case there are only blind carbon-copy recipient(s) (Bcc:), the behavior shall be as recommended by [RFC2821], Appendix B, i.e. the originating MMS Relay/Server shall only insert an empty Bcc: header and no To: or Cc: headers. The recipient(s) shall then only be indicated in the SMTP command layer (RCPT TO:). So the 3GPP-produced specification conforming to the specifications of RFCs 2821 and 2822 while this proposed gateway specification does not. This is ironic at best. REMEDY: Preferred: Use the group syntax with an empty group. If the LEMONADE WG (or the IESG) are convinced that the "(undisclosed recipients)" comment is an appropriate substitute for the group syntax and should be permitted or encouraged, they should attempt to convince the community of that conclusion via an update to RFC 2822, not by (deliberately or accidentally) concealing the change in this type of document. Alternate 1: Use a "Bcc:" field that is empty or contains only a comment, a form that is permitted by both RFC 822 and RFC 2822. Alternate 2: Do not generate recipient fields. This is permitted by RFC 2822 but not by RFC 822 and is hence probably the least desirable valid option in terms of interoperability. While a case can be made for any of the three choices, the choice made in the document is violation of the existing standards (and their predecessors) and must not be specified without opening and updating those standards. (3) The "contemporary email systems" principle of RFC 2821 is violated. That principle suggests and requires that no new features or capabilities be added to unextended environments (i.e., environments conforming to RFC 821 rather than 2821). The current draft attempts to support the RFC 821 level of specification where possible, and the 2821 level elsewhere. This makes makes the specification far more complex and convoluted than it would be if the mapping that is specified simply required 2821-based gateways. This extra complexity, indeed any excess complexity, is undesirable in an Internet protocol unless it is required by some documented situation or constraint. This document does not contain any evidence of such constraints, nor does there appear to be any evidence of discussion of, much less consensus about, such constraints in the WG email archives. REMEDY: Remove all support for, and discussion of, RFC 821-only email. (4) Under "Sender address" in Section 2.1.3.2 of the specification, there is a fairly convoluted discussion of hidden senders and untrusted relays and receiving servers. Again, this violates a long-standing, although not specifically standardized, principle of Internet mail. Stated simply, if one doesn't trust a relay or any subsequent server in the path (with the understanding that this raises all of the complicated issues about what such "trust" actually means), one should not send the message. This section can be read as attempting to standardize a bad practice. More generally, it is not clear that this document is either a necessary or appropriate place to try to describe or resolve the complex trust issues involved in mail relaying, even though the gateway aspect further complicates those issues. The right solution, actually suggested elsewhere in the document, is to avoid all attempts to support or guarantee hidden senders. REMEDY: See (6), below. (5) Under "Content type" in Section 2.1.3.2 of the specification, reference is made to conversions being done without "significant loss of content". It is not at all clear what "loss of content" means, or how "significant" is to be interpreted. More broadly, there have been extended, and sometimes quite heated, discussions in the community during the last few years about midstream conversions and content alterations of various sorts (discussions about OPES, VPIM, the FAX WG's "CONNEG" features, and ongoing discussions about use of message submission come to mind). Given those discussions, it is quite surprising that the language in this document, which seems to suggest "do whatever you want based on your understanding of what the Internet supports and what you think isn't too damaging", could move through the WG and be accepted by the IESG without comment. At as minimum, this is more evidence that the document was never really reviewed. REMEDY: Perhaps the WG intends "...loss of information" rather than "...loss of content"? "Significant" would still be an issue, but the intent would be considerably more clear. The spirit of the language about gateways in RFC 2821 and general assumptions about desirable practice in the area suggests that this specification should permit no conversions that are not strictly necessary to make the message conform with standards on the side of the gateway to which it is being introduced and should make provision for documenting the conversions that are made. (6) In section 2.1.3.2.2, under "Sender visibility", the specification says "Support for sender address hiding is not included in this version of the mapping document". However, the discussion of "sender address" in 2.1.3.2 specifies how to hide a sender address. At best, this is inconsistent. More generally, invisible sender addresses are an opportunity for spammers, would add to the difficulties of some proposed anti-spam techniques, and are a fairly radical departure from the Internet mail architecture. Not supporting them seems appropriate but, if LEMONADE ever wants to open that door, it should be opened as part of an update to base Internet mail specifications, not through a discussion of syntax in this document. REMEDY: Remove all syntax for sender address hiding and all discussion of the topic other than the current "does not support" text or equivalent. This includes removing the much weaker recommendation, in the security considerations section, that sender identity hiding not be attempted across carrier networks. If it is desired to say anything beyond "does not support", it should be said as part of a clear explanation of why support for this type of option is not practical. (7) In Section 1.3 of the specification, a definition is given for "Gateway Function". With all respect to ongoing efforts to better-define the Internet's email model, there is a fairly extensive definition of gateways and gateway functions in RFC 2821 and the text here is inconsistent with this definition. Going beyond matters of the terminology in this document, the provisions of section 2.1.2 of the specification make use of the term "Relay/Server" inappropriate. If the relevant system does format, media, or transport conversion, it is a Gateway as defined in RFC 2821. REMEDY: As with the group syntax, if the LEMONADE WG believes that current, established, definitions are inadequate, the correct solution is to generate a proposal to update RFC 2821. The definition in this document should either refer to RFC 2821 (or, where applicable, RFC 2822) or be strictly consistent with them. (8) There is an assertion in section 2.1.1 of the specification about the requirements of SMTP with regard to return paths. The assertion in the example is incorrect: SMTP _requires_ null return paths only for error messages involving non-delivery. The extended requirement that null addresses be used for automatically-generated messages occurs elsewhere or are covered by MAY statements or the equivalent in RFC 2821. REMEDY: Correct this reference. (9) This specification provides, in the table of section 2.1.3.1, for a "Resent-Count:" header in Internet mail. This header is not defined in RFC 2822, which is usually assumed to be normative for all "Resent-" headers and their relationships. More important, it violates the important design principle that one should not provide both a list of things that can be counted and the count, lest the two counts disagree. If it is going to do so, text is needed as to what occurs when the number of Resent field sets and the Resent-count differ. Since Resent-count does not appear in 2822, it is reasonable to anticipate that some, probably many, systems will not notice its presence and hence will not update it when the add Resent- fields. It seems completely out of scope for this document unless it really is going to define a "Resent-count:" field (there is no definition at present), but it is not clear how a gateway might calculate such a field given the amount of flexibility in RFC 2822 about which of the Resent- fields may appear and in what combinations. In the general case, if any Resent- fields appear, the value of Resent-count could be reliably bounded only by 1 and the total number of such fields. REMEDY: Drop "Resent-count:" entirely in the absence of compelling need and explanation. If that explanation is provided, it should be explicit about the relationship between the count of Resent field sets and the counter if they happen to differ. It is unlikely that an adequate definition is possible in the absence of an update to RFC 2822 and mechanisms for changing existing deployed practice, so such definition is presumably well outside the scope of the LEMONADE WG. (10) In Section 2.1.3.2.2, there is a subsection titled "Resending/Forwarding" that discusses quoting of message sections and message encapsulation. The quoting mechanism that is discussed has never been standardized because, while there seems to have been some convergence in the last few years, the community has never been able to reach consensus on the subject. The section appears to be completely confused about the relationships among quoting or excerpting and embedding. More important, the encapsulation norm cited, RFC 934, has been generally considered obsolete (even though still widely used) since MIME and its encapsulation mechanisms came into general use. The discussion of that referenced document also appears normative although the reference is listed as informative (see item (14), below. There is also a fairly extensive discussion of forwarding and resending in RFC 2822 and the material in this section does not appear to be completely consistent with it. Similar comments apply to the discussion of Resent- and Received- headers in the next section. This document should cite RFC 2821 or 2822 as appropriate, not try to paraphrase their recommendations (or requirements) and get it even slightly wrong. REMEDY: This document should be rewritten to avoid general discussions and tutorials of aspects of Internet mail that are outside the scope of the specific conversions or mappings being specified. If it is necessary, in the opinion of the WG, to discuss these additional issues, the discussions should confine themselves to agreed-up best practices only or LEMONADE should extend its charter to include discussion and standardization of common, but currently non-standard, practices in Internet mail and then follow up with a document along those lines. (11) In section 2.1.3.3.1 (apparently), there is a discussion of "Sensitivity" that indicates that an "appropriate extended error response code" be used. If this is a protocol specification, it should specify the code(s) to be used or how the implementer should determine such code(s). Without that level of specification, this document is an invitation to interoperability problems. REMEDY: Where codes are intended, they should be specified. (12) In section 3, it is asserted that SMTP Authentication protects against misidentification of message source. SMTP Authentication protects only against misidentification of the most-recent sender and has little to do with message sources except through out of band (whether explicit or implicit) trust chains. REMEDY: Correct this text. (13) The IANA Considerations section, section 4, indicates that no actions are requested of IANA. However, this specification introduces several new headers into the Internet mail environment. Those headers should be registered in the registry specified in RFC 4021. REMEDY: Correctly specify the IANA actions and explicitly identify the new headers. (14) While this document specifies in its introduction that an understanding of the MMS specifications is required to read and understand it, the MMS specifications are all listed as informative, not normative. Even if that text did not appear, the notion of a gateway specification that did not require an understanding of the definitions of the systems on both sides would be, at best, very unusual. "You need to understand that in order to read and implement this" is the very essence of a normative reference. Apparently neither the WG nor the IESG did an adequate review to determine which references were actually normative and which were not. There are fairly well-defined procedures for normative references to the documents of other standards bodies in IETF standards-track specifications; there is no evidence that they have been followed here. The reference to RFC 934 raises an additional issue: that specification's maturity level is listed as "unknown". While RFC 3967 provides a mechanism for referring normatively to documents at a "lower level", it is not clear how, or if, one can refer to a document with status "unknown". Even if RFC 3967 is construed to treat "unknown" as equivalent to the lowest permitted reference level, there is no evidence in the WG archives or the Last Call for this document that the procedures it specifies have been followed here. REMEDY: Get rid of the reference to RFC 934 by cleaning up the material discussed under (10) or, if it is to be retained, clarify its status (presumably requiring an IETF Last Call and probably a new document). Move the MMS references to the "normative" section and make sure that all requirements for references to such documents have been met. (15) In Section 3 (Security Considerations), there is a paragraph that begins "Since MMS does not include a clear separation between in-transit envelope and message content, there are increased risks of unauthorized disclosure of information, and additional challenges in protecting data. For example, Bcc recipients do not normally appear in the message content, only in the envelope; care MUST be taken in...". This is at variance with the current (cited) version of the MMS specification, which appears to specify what should be done in this case very clearly, where it says: In case there are both To: / Cc: and Bcc: recipients, the Bcc: headers shall be removed by the originating MMS Relay/Server and the Bcc: recipients shall only be indicated in the SMTP command level (RCPT TO:). This is in accordance with the functionality recommended by [RFC2821], Appendix B. That statement is not only fairly clear, it is consistent with the specification in RFC 2821, which the document itself is not. Whether a MUST-level requirement should appropriately appear in an example embedded in the middle of the security considerations section is an issue we will leave for the editorial process, but, again, it suggests a lack of adequate review. REMEDY: Since the MMS specification is well-aligned with the requirements of RFC 2821 and 2822, this text and recommendation should be aligned with it. Gateways should make as few conversations, and do as little damage, as possible. (16) There are a number of mapping issues about which the document appears to hand-wave, indicating that something MAY be done but without any specification as to how to do it. The issue is somewhat similar to that of (11), above, but involves fundamental design principles that the document does not address. For example, the document indicates that, if a Message-ID is not present, "...the value of the 'X-Mms-Message-Id:' header MAY be used" to create one. But X-MMS-Message-ID doesn't obey the syntax rules for Message-IDs, so, if traceability is desired, this document needs to specify how the Message-ID mapping is accomplished. If traceability is not important, then the document should probably just indicate that a Message-ID MUST be made up (a requirement of RFC 2822) and that any handy information, including the contents of an X-MMS-Message-ID header if present MAY optionally be used to create it, but that the information will not be useful for tracing messages or their relationships. Similar issues arise with addresses. It is common in the MMS environment for addresses to be E.164-format telephone numbers, without domain names. The MMS specification makes a recommendation about how to handle this but it may or may not be appropriate in all cases. Following precedent in other areas, it may be appropriate is insert the domain of the gateway, thereby making the assumption (faulty in X.400 and faulty here) that forward and reverse paths for these messages across gateways are necessarily equivalent. Note that injecting an address without a fully-qualified domain name into the Internet violates RFC 2821 and RFC 2822. REMEDY: The document needs to be specific about mappings when it is intended that they be useful (e.g., for routing of messages or message tracing or linking) and to be explicit when the mappings are for informal documentation purposes or conformance on one side of the gateway only. If domain names are made up (e.g., by inserting a gateway domain), the document needs to discuss the security and operational implications of doing so. (17) Another paragraph of the Security Considerations section reads: It is possible to hide the sender's identity from non-recipients using anonymous remailers. It is hard to hide the sender's identity from recipients when the mail is cryptographically signed. In view of anti-spam measures it may be undesirable to hide the sender's identity. This borders on the silly, since one can eliminate the particular identity-revealing problem associated with signed mail by simply removing the signature. More important, it is not clear why a general discussion of anonymous remailers and similar tools belongs in this document unless the WG or editor are just trying to tell us how much they know (and the editor in this case knows a great deal more than this). The document repudiates sender-hiding (see (6) above); this is gateway specification should focus on issues associated with the gateway, leaving general issues of anonymity in Internet Mail to other specifications. REMEDY: Remove this text unless there is a substantive reason to include it. If there is, it is going to need significant reworking including, presumably, addressing the case of address hiding or exposure with encrypted message body parts that might contain full RFC 822/ 2822 headers. (18) The listed of bulleted "existing mechanisms" in the Security Considerations section is deeply flawed. As noted in (12) above, SMTP Authentication does not "protect against misidentification of message source", it merely protects against spoofing of the previous-hop server. Anything more requires trust assumptions or agreements about the behavior of that server that are not covered in this document (or in the SMTP AUTH one). The document is correct in stating that IPSEC and SSH or TLS are useful only in protecting against in-transit modification between adjacent servers, but, if it is going to make those statements, it should discuss the limitations of those techniques in an email environment and the particular difficulties associated with them on the two sides of a gateway. To do otherwise appears to be a pretense of security and completeness to pad out the document, one that can be misleading to readers (whether implementers or users). It also recommends use of PGP or S/MIME to protect message contents. This is normally a good recommendation for email, since the techniques work end to end rather than hop-by-hop. However, there is a long history of problems when PGP and S/MIME message privacy and message integrity mechanisms cross gateway boundaries between systems of a rather different character, and it is irresponsibile to recommend those techniques without discussing those potential problems or demonstrating an understanding of them and providing a pointer to the places where they have been discussed (such as RFC 2480). REMEDY: The Security Considerations generally, and this material in particular, should be updated to reflect operational realities and the actual applicability and utility of techniques in a gateway environment. (19) It is possible that this should be viewed as a primarily an editorial comment, but, at this point, we understand how to construct and write a mail gateway specification. RFC 2821 outlines the basic requirements and we have worked examples for even more complex cases than this one, e.g., in RFCs 2156 and 2157 and the documents leading up to them. We start with one protocol and definition as input, figure out which of its components can be mapped accurately to the other side in terms of their semantics, specify those mappings, and then examine the components that cannot be mapped exactly and figure out what should be done about them -- either dropping them or producing the nearest possible semantics on the receiving side while continuing to conform to all of the requirements of the receiving side. The process is then repeated with the sides reversed, and then both sides are reviewed to be sure that any traceability or "reply" considerations are satisfied. It is key to gateway specification models that the document make no assumption that the behavior of client or end systems that receive or send mail that will ultimately pass through the gateway change in any way. If such changes are desired, they must be pursued independently, explicitly, and with due consideration of the likelihood of effective deployment, with the organizations who have change control of the individual systems and protocols that feed into the gateway. Unless those other groups can somehow be expected to be able to instantly make and deply those changes, the gateway specification must be [still] written on the assumption that the changes will not occur or will not be ubiquitious. Obviously those constraints make the job of the gateway-specifier harder, but any other assumption is just not operationally plausible, especially --as is typically the case-- the end systems assume that they are communicating within their own environments rather than through a gateway. This document does not convey the impression that the above model was followed and all of the steps carefully taken. In particular, there are mismatches in semantics and mappings that impact traceability or replies that are not properly accounted for. Some of those are described above. Others involve skimming over serious semantic mismatches between the "Disposition-Notification-To:" header specified in [MDN] and the "X-MMS-Read-Reply" header. "Replacing" one field with the other requires pulling information from elsewhere, and the document provides no guidance as to how to do that. A more systematic analysis along the lines above would, presumably, have at least identified the problem and called for some discussion. Similarly, since the document is not written clearly as a gateway specification --with no assumption that it can change the downstream or upstream environments on either side-- it is muddled about whether the MDNs it describes are generated by the gateway or whether they are generated in the MMS (or Internet mail) environments respectively and then translated by the gateway. That muddle leads to, e.g., a situation in which the specification appears to call for mapping of a Disposition-Notification-To field in an MMS-generated MDN to an Internet message, but that field will not appear in an MMS-environment MDN. REMEDY: Revoke the Protocol Action notice and return this document to the WG, insisting that all of the substantive points above be addressed and that the document not be forwarded back to the IESG until there is evidence of adequate review and consensus about the results. ------------- In several, but certainly not all, of the cases listed above, there would be little basis for appeal if there were evidence that the WG had carefully considered the issues, the tradeoffs, and the possible impact, consulted as needed with others about them, and then arrived at informed conclusions. However, there is little or no evidence of such consideration and deliberation on the part of the WG, at least since version -02 of the relevant document was posted. In other cases, there has been a clear failure of adequate review and justification for changes to the Internet's email fabric and its definitions, changes that go well beyond the agreed-upon scope of the WG. In accepting this document for publication as a standards-track specification, especially after many of the above issues had been pointed out to it, the IESG either failed in its responsibility to determine the existence and adequacy of community consensus or chose to substitute its judgment for that of a largely-silent WG and broader community without making an attempt to raise these issues when them. In either case, the decision to accept this document, in its present form, as a Proposed Standard should be withdrawn and a review and revision process initiated. It is important to stress that this appeal, however lengthy and detailed, is not a comprehensive review of the document and, hence, that "fix the points listed in the appeal" is not an adequate or appropriate remedy. It would be especially inappropriate if that instruction were delivered to the document editor as a matter for negotiation with the IESG. Instead, the details above should be considered as nothing more than a set of examples whose cumulative impact should be to demonstrate that this document should be returned to the WG with instructions to perform the level of analysis, and guarantee the level of review, that should have preceeded submission to the IESG as a WG document._______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum