From lemonade-bounces@ietf.org Fri Jun 10 15:16:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgozw-0008ND-VB; Fri, 10 Jun 2005 15:16:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgozv-0008N4-Gx for lemonade@megatron.ietf.org; Fri, 10 Jun 2005 15:16:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22440 for ; Fri, 10 Jun 2005 15:16:53 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgpLc-0003o4-U1 for lemonade@ietf.org; Fri, 10 Jun 2005 15:39:22 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5AJGZCK008686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 10 Jun 2005 12:16:36 -0700 (PDT) Received: from [192.168.1.4] (carbuncle.qualcomm.com [129.46.227.161]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5AJGXuo028481 for ; Fri, 10 Jun 2005 12:16:34 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Fri, 10 Jun 2005 12:16:28 -0700 To: lemonade@ietf.org From: Ted Hardie Content-Type: multipart/mixed; boundary="============_-1093691503==_============" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e73e7ad830b2f0a95c4eabd630e061d Subject: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --============_-1093691503==_============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" A process appeal has been raised on this document by John Klensin. The document for that appeal has been attached. One one point raised, that the document was changed between IETF Last Call and passage by the IESG, I will note that the author and I (as shepherd of the document) believed the changes made to be editorial clarifications rather than critical to the mechanisms agreed to by the WG. I expect that the working group will be involved in future discussion of this issue, and I encourage the WG to review the appeal. regards, Ted Hardie >Date: Fri, 10 Jun 2005 14:49:17 -0400 >From: John C Klensin >To: Brian E Carpenter >X-Scan-Signature: 58a894dbf8d0c4c152ea0be9e8cd3d14 >Cc: Randall Gellens , iesg@ietf.org, ietf@ietf.org >Subject: Appeal of decision to standardize "Mapping Between the > Multimedia Messaging Service (MMS) and Internet Mail" >X-BeenThere: iesg@ietf.org >List-Id: iesg.ietf.org >List-Unsubscribe: , > >List-Post: >List-Help: >List-Subscribe: , > >Sender: iesg-bounces@ietf.org >X-QUALCOMM-AV: Sophos AV Testing > >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 > --============_-1093691503==_============ Content-Id: Content-Type: text/plain; name="mms-mapping-appeal 1.txt"; charset="us-ascii" ; format="flowed" Content-Disposition: attachment; filename="mms-mapping-appeal 1.txt" ; modification-date="Fri, 10 Jun 2005 12:00:25 -0700" 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. --============_-1093691503==_============ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --============_-1093691503==_============-- From lemonade-bounces@ietf.org Fri Jun 10 15:39:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgpLh-0004lz-He; Fri, 10 Jun 2005 15:39:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgpLX-0004jT-3s for lemonade@megatron.ietf.org; Fri, 10 Jun 2005 15:39:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24998 for ; Fri, 10 Jun 2005 15:39:12 -0400 (EDT) Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgphC-0001GN-EW for lemonade@ietf.org; Fri, 10 Jun 2005 16:01:41 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout5.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5AJd9th014756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Jun 2005 12:39:09 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5AJd8rl004642 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 10 Jun 2005 12:39:08 -0700 Date: Fri, 10 Jun 2005 12:37:07 -0700 (Pacific Daylight Time) From: Mark Crispin To: Ted Hardie Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org I have read John Klensin's appeal. I do not wish to comment on the process issues, as doing would likely lead to a collosal waste of my time. However, John's technical objections seem to be largely excellent; and his suggested remedies seem to offer great benefit while causing negligible (if any) harm to this proposed specification. Unless there is harm that I missed (I admit that I have not studied it in detail), I suggest that adopting John's suggestions in entirety would be the best course for the proponents of this specification. Although doing so would leave the process issues unanswered, it would greatly reduce their impact. I personally am willing to accept an unintended process bypass if the technical work is otherwise excellent. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 10 15:55:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgpbe-0004Kb-IA; Fri, 10 Jun 2005 15:55:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgpbc-0004K2-KZ for lemonade@megatron.ietf.org; Fri, 10 Jun 2005 15:55:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00604 for ; Fri, 10 Jun 2005 15:55:49 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgpxK-0004s7-S4 for lemonade@ietf.org; Fri, 10 Jun 2005 16:18:19 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5AJtcCK012052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 10 Jun 2005 12:55:39 -0700 (PDT) Received: from [192.168.1.4] (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5AJtauR028438; Fri, 10 Jun 2005 12:55:37 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 10 Jun 2005 12:55:33 -0700 To: Mark Crispin From: Ted Hardie Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Speaking as a technical contributor, I think there are serious problems with his proposed remedies, and that he has missed the aim on some of this pretty widely. As an example: >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. While I would certainly consider shifting SHOULD to MAY here (since facilitating the passage of an MMS header across the Internet and back to MMS seems to be not required even if desirable), I think translating the X-* headers to standards headers is the wrong way to go. These *are* private use headers from the Internet perspective and the specification as it stands allows them to be treated as such--they can be wantonly dropped by an intermediate MTA, for example. Translating them into standards-based headers means that they must be retained, and I believe is far more liable to confusion about what they will mean on the Internet side of the gateway. They should mean nothing to the Internet recipient. That is, I believe, how the Internet recipient getting an unknown X-header will treat it now, and I see no advantage to putting them into something "Message-ID" which is extraordinarily liable to misconstruction. As before, just my view as a technical contributor. regards, Ted Hardie _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 10 16:26:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgq5a-0003Pg-UM; Fri, 10 Jun 2005 16:26:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgq5Z-0003Pb-79 for lemonade@megatron.ietf.org; Fri, 10 Jun 2005 16:26:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09476 for ; Fri, 10 Jun 2005 16:26:46 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgqRH-00048s-QG for lemonade@ietf.org; Fri, 10 Jun 2005 16:49:17 -0400 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j5AKQUiE006363; Fri, 10 Jun 2005 15:26:30 -0500 (CDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 10 Jun 2005 15:26:30 -0500 Message-ID: <54E40201497DF142B06B27255953F79715A44326@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Ted Hardie , Mark Crispin Subject: RE: [lemonade] Fwd: Appeal of decision to standardize "Mapping B etween the Multimedia Messaging Service (MMS) and Internet Mail" Date: Fri, 10 Jun 2005 15:26:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org As an active WG contributor, I have reviewed most itterations of the draft and have privately sent many comments to the author, comments incorporated in subseqent versions. I also recall regular, if short, discussions in the face-to-face working group meetings. I believe the X-MMS headers on the Internet side of the gateway are appropriate, and that inventing a new standard header for the narrow purpose of tunnelling a private header is unnecessary. This is a gateway document and as such necessitates a pragmatic approach to deciding which headers to map and which to tunnel. I see no general value to the unmapped headers. The specific issue of using X-priority is one I raised with the author, and was convinced that X-priority is so widely deployed, and that common semantic is widely understood, that it merited mention. The standard header is now importance, and that should be the primary mapping. However, there is a wide installed base that does not understand importance, and the addition of a redundant piece of data to improve the end-user-experience is appears a reasonable trade-off. The X-priotity is not required, just "suggested". Issues of senders privacy (anonymous, caller id blocking) in Internet messaging is an open issue with no standard resolution. I wish there was a better mapping or advise. I suggested several incorporated additions to the language in the draft, and while it is admittedly imperfect, I have no further suggestions for improvement. I don't have an opinion on the remaining objections. Greg V. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 10 16:35:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgqDp-0006Cp-R0; Fri, 10 Jun 2005 16:35:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgqDo-00067o-25 for lemonade@megatron.ietf.org; Fri, 10 Jun 2005 16:35:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10333 for ; Fri, 10 Jun 2005 16:35:17 -0400 (EDT) Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgqZW-0006ep-Gu for lemonade@ietf.org; Fri, 10 Jun 2005 16:57:47 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout7.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5AKZGq9011199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Jun 2005 13:35:16 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5AKZGxP013400 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 10 Jun 2005 13:35:16 -0700 Date: Fri, 10 Jun 2005 13:33:15 -0700 (Pacific Daylight Time) From: Mark Crispin To: Ted Hardie Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Fri, 10 Jun 2005, Ted Hardie wrote: > While I would certainly consider shifting SHOULD to MAY here > (since facilitating the passage of an MMS header across the > Internet and back to MMS seems to be not required even if > desirable), I think translating the X-* headers to standards > headers is the wrong way to go. These *are* private use > headers from the Internet perspective and the specification as > it stands allows them to be treated as such--they can be wantonly > dropped by an intermediate MTA, for example. If they are indeed private-use headers from the MMS standpoint, and utterly meaningless in Internet, then they should be *dropped*, not translated into something else. The moment that you state in an Internet specification that such-and-such is written with an X-* header, you have effectively standardized that header. You can be certain that IMAP clients will start requesting that header, and demanding that servers enforce the correct syntax. > Translating them into > standards-based headers means that they must be retained, and > I believe is far more liable to confusion about what they will mean > on the Internet side of the gateway. But that is exactly what the document does; by naming a header it has declared it to be a standards-based header. There are three ways out of the predicament. Pick your favorite poison: 1) Do as John says, and give them a real name. 2) Require that these headers be dropped. 3) Require that these headers be wrapped inside a Comments: header, e.g., Comments: X-MMS-Message-ID: blurdybloop I do not consider it be acceptable (or permissible) to have a X-* header with defined semantics yet claim "we're really not defining this header or its semantics." -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 10 18:04:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgrcZ-0000pE-OT; Fri, 10 Jun 2005 18:04:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgrcY-0000n0-35 for lemonade@megatron.ietf.org; Fri, 10 Jun 2005 18:04:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17303 for ; Fri, 10 Jun 2005 18:04:55 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgryH-0000VD-Ez for lemonade@ietf.org; Fri, 10 Jun 2005 18:27:26 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5AM4dCK025536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 10 Jun 2005 15:04:40 -0700 (PDT) Received: from [192.168.1.4] (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5AM4buR018567; Fri, 10 Jun 2005 15:04:37 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 10 Jun 2005 15:04:34 -0700 To: Mark Crispin From: Ted Hardie Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 1:33 PM -0700 6/10/05, Mark Crispin wrote: >But that is exactly what the document does; by naming a header it >has declared it to be a standards-based header. From my point of view, naming something does not make it standards based, especially since the name itself lets you know it is not. Mentioning something in a document with the clear message "This is not an Internet header" does not make it an Internet header. >There are three ways out of the predicament. Pick your favorite poison: > >1) Do as John says, and give them a real name. As I said before, I think that makes it much harder to let people know that they are *not* Internet headers. >2) Require that these headers be dropped. I believe that allowing the headers to be dropped is sufficient, but I would prefer requiring they be dropped to giving them Internet semantics by dropping the X-. >3) Require that these headers be wrapped inside a Comments: header, e.g., > Comments: X-MMS-Message-ID: blurdybloop > >I do not consider it be acceptable (or permissible) to have a X-* >header with defined semantics yet claim "we're really not defining >this header or its semantics." > But there are no defined semantics for the Internet; it is simply the case that if they happen to make it across the Internet to some other MMS-capable device, they are in the same form they started out in. For any consumption by Internet mail, they are garbage. They can be dropped by any device along the path and ignored if they are consumed an Internet mail user agent. Again, my personal technical opinion, regards, Ted _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 10 18:19:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgrqy-0005Vz-3y; Fri, 10 Jun 2005 18:19:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgrqw-0005Vr-BK for lemonade@megatron.ietf.org; Fri, 10 Jun 2005 18:19:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19436 for ; Fri, 10 Jun 2005 18:19:46 -0400 (EDT) Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgsCg-0001XT-Ha for lemonade@ietf.org; Fri, 10 Jun 2005 18:42:19 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5AMJlIf029037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Jun 2005 15:19:47 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5AMJlcD005291 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 10 Jun 2005 15:19:47 -0700 Date: Fri, 10 Jun 2005 15:17:46 -0700 (Pacific Daylight Time) From: Mark Crispin To: Ted Hardie Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Fri, 10 Jun 2005, Ted Hardie wrote: >> But that is exactly what the document does; by naming a header it has >> declared it to be a standards-based header. > From my point of view, naming something does not make it standards based, > especially since the name itself lets you know it is not. That may be a viable position to hold if we lived in a world in which everyone is rational and cooperative. Unfortunately, we do not live in such a world. > Mentioning > something > in a document with the clear message "This is not an Internet header" does > not make it an Internet header. I contend that you greatly underestimate the problem of individuals who will take text from an RFC out of context and demand that their resulting interpretation is the One True Way, notwithstanding explicit text elsewhere in the same RFC to the contrary. >> There are three ways out of the predicament. Pick your favorite poison: >> 1) Do as John says, and give them a real name. > As I said before, I think that makes it much harder to let people know that > they are *not* Internet headers. Such arguments would be more convincing if there was a compelling reason to believe that they are not headers. They certainly appear to be perfectly good informational headers to me. >> 2) Require that these headers be dropped. > I believe that allowing the headers to be dropped is sufficient, but I > would prefer requiring they be dropped to giving them Internet semantics > by dropping the X-. OK, we have a point of agreement that requiring these to be dropping is acceptable. Good, we have a fallback that we can both sign off on. > But there are no defined semantics for the Internet; it is simply the > case that if they happen to make it across the Internet to some other > MMS-capable device, they are in the same form they started out in. I'm afraid that this sentence is self-contradictory; or at least to me it is. I'm reading at least two defined semantics for these headers in the Internet: 1) informational data relating to how the message is transported in MMS 2) data to be passed when transporting the message back to MMS That's quite a bit. > For > any consumption by Internet mail, they are garbage. Is that really true? Are you saying that no human user will ever care about this information; that that information is utterly useless for any debugging or tracing purposes; and that this information being utterly useless should not be passed back to MMS if the message loops back for whatever reason? > They can be dropped > by any device along the path and ignored if they are consumed an > Internet mail user agent. I disagree. If the header appears, people will pay attention to it and attempt to use the data contained. The only way to get the semantics of "garbage" is mandatory dropping. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 10 19:19:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgsn0-00042v-8a; Fri, 10 Jun 2005 19:19:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgsmy-00042q-1i for lemonade@megatron.ietf.org; Fri, 10 Jun 2005 19:19:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24045 for ; Fri, 10 Jun 2005 19:19:44 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgt8g-0001Lu-S0 for lemonade@ietf.org; Fri, 10 Jun 2005 19:42:17 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5ANJSdv026204; Fri, 10 Jun 2005 16:19:28 -0700 (PDT) Received: from [192.168.1.4] (carbuncle.qualcomm.com [129.46.227.161]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5ANJPuo008609; Fri, 10 Jun 2005 16:19:26 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 10 Jun 2005 16:19:22 -0700 To: Mark Crispin From: Ted Hardie Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 3:17 PM -0700 6/10/05, Mark Crispin wrote: >On Fri, 10 Jun 2005, Ted Hardie wrote: >>>But that is exactly what the document does; by naming a header it >>>has declared it to be a standards-based header. >>From my point of view, naming something does not make it standards based, >>especially since the name itself lets you know it is not. > >That may be a viable position to hold if we lived in a world in >which everyone is rational and cooperative. Unfortunately, we do >not live in such a world. > >>Mentioning something >>in a document with the clear message "This is not an Internet header" does >>not make it an Internet header. > >I contend that you greatly underestimate the problem of individuals >who will take text from an RFC out of context and demand that their >resulting interpretation is the One True Way, notwithstanding >explicit text elsewhere in the same RFC to the contrary. Care to give your estimate of the numbers of these individuals creating that problem, just so I know? In percentage of readers, say? > >I'm afraid that this sentence is self-contradictory; or at least to >me it is. I'm reading at least two defined semantics for these >headers in the Internet: > 1) informational data relating to how the message is transported in MMS > 2) data to be passed when transporting the message back to MMS 1 should be something that the the Internet does not care about, at least in my view. 2, I would recast as "data to be passed back to MMS, if available", and I contend that it still has no semantic meaning to the Internet. Since *any* X- header can be dropped, the MMS system should not rely on it being present, and no intermediate non-MMS system would do anything special about it all. If they have a local policy to drop unknown X-headers; cool. If they have a local policy to pass on unknown X-headers; cool. >That's quite a bit. We apparently disagree here. >>For any consumption by Internet mail, they are garbage. > >Is that really true? Are you saying that no human user will ever >care about this information; that that information is utterly >useless for any debugging or tracing purposes; and that this >information being utterly useless should not be passed back to MMS >if the message loops back for whatever reason? > >>They can be dropped by any device along the path and ignored if >>they are consumed an Internet mail user agent. > >I disagree. If the header appears, people will pay attention to it >and attempt to use the data contained. > >The only way to get the semantics of "garbage" is mandatory dropping. Maybe my brain left early for the weekend, but this seems contrary to existing practice for X- headers. It seems now, we leave it up to local policy to act (or not act) on them; this seems to require a specific policy to drop them. I cannot see why that policy should be required here where it is not required in general. If I mis-understand you, and you really mean that all intermediate MTAs should drop all X- headers, then I think that's consistent but unnecessary. regards, Ted Hardie _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 10 19:29:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgswD-0007u8-1m; Fri, 10 Jun 2005 19:29:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgswB-0007tu-2s for lemonade@megatron.ietf.org; Fri, 10 Jun 2005 19:29:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24514 for ; Fri, 10 Jun 2005 19:29:15 -0400 (EDT) Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgtHu-0002eD-1M for lemonade@ietf.org; Fri, 10 Jun 2005 19:51:48 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5ANTE2I028310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Jun 2005 16:29:15 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5ANTEq3016443 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 10 Jun 2005 16:29:14 -0700 Date: Fri, 10 Jun 2005 16:27:13 -0700 (Pacific Daylight Time) From: Mark Crispin To: Ted Hardie Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Fri, 10 Jun 2005, Ted Hardie wrote: >> I contend that you greatly underestimate the problem of individuals who >> will take text from an RFC out of context and demand that their resulting >> interpretation is the One True Way, notwithstanding explicit text elsewhere >> in the same RFC to the contrary. > Care to give your estimate of the numbers of these individuals creating that > problem, > just so I know? In percentage of readers, say? I can't give such numbers. I can, however, say that the trouble raised by such individuals is greatly out of proportion to their numbers. There is, for example, a widely distributed IMAP server implementation that contemptously thumbs its nose at the IMAP specification and is a major source of headache for me. >> I'm afraid that this sentence is self-contradictory; or at least to me it >> is. I'm reading at least two defined semantics for these headers in the >> Internet: >> 1) informational data relating to how the message is transported in MMS >> 2) data to be passed when transporting the message back to MMS > 1 should be something that the the Internet does not care about, at least in > my view. 2, I would recast as "data to be passed back to MMS, if available", > and I contend that it still has no semantic meaning to the Internet. What if I start polluting the Internet with X-MMS-* headers that are completely bogus and would cause harm if inserted into the MMS world? Then, when the MMS world complains, I point at that bit in RFC 2822 that says that X-* headers are experimental and I can put whatever crap in such headers that I desire? Of course, I wouldn't do this. Nevertheless, the right way to look at this is not to consider how reasonable people behave. It's to consider how unreasonable people behave. > Since > *any* X- header can be dropped, the MMS system should not rely on it > being present, and no intermediate non-MMS system would do anything > special about it all. s/can be dropped/can contain any random crap that someone puts in >> I disagree. If the header appears, people will pay attention to it and >> attempt to use the data contained. >> The only way to get the semantics of "garbage" is mandatory dropping. > Maybe my brain left early for the weekend, but this seems contrary to > existing practice for X- headers. That's because, prior to now, no specification stipulates that such headers are to be generated. This document now says that such headers are to be generated under such-and-such conditions. Now, there are meaningful X-* headers with defined semantics. > If I mis-understand you, and > you really mean that all intermediate MTAs should drop all X- headers, > then I think that's consistent but unnecessary. No, I mean that headers from the MMS world must either be represented with real headers, or they are to be dropped. They should not be rendered into Internet X-* headers. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 10 20:08:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgtXf-0001VM-9c; Fri, 10 Jun 2005 20:08:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgtXd-0001VD-Lo for lemonade@megatron.ietf.org; Fri, 10 Jun 2005 20:08:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26583 for ; Fri, 10 Jun 2005 20:07:59 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgttO-0006iJ-4f for lemonade@ietf.org; Fri, 10 Jun 2005 20:30:31 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5B07ldv000429; Fri, 10 Jun 2005 17:07:48 -0700 (PDT) Received: from [192.168.1.4] (carbuncle.qualcomm.com [129.46.227.161]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5B07juo020359; Fri, 10 Jun 2005 17:07:46 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 10 Jun 2005 17:07:42 -0700 To: Mark Crispin From: Ted Hardie Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 4:27 PM -0700 6/10/05, Mark Crispin wrote: > >What if I start polluting the Internet with X-MMS-* headers that are >completely bogus and would cause harm if inserted into the MMS >world? Then, when the MMS world complains, I point at that bit in >RFC 2822 that says that X-* headers are experimental and I can put >whatever crap in such headers that I desire? > >Of course, I wouldn't do this. Nevertheless, the right way to look >at this is not to consider how reasonable people behave. It's to >consider how unreasonable people behave. > >>Since >>*any* X- header can be dropped, the MMS system should not rely on it >>being present, and no intermediate non-MMS system would do anything >>special about it all. > >s/can be dropped/can contain any random crap that someone puts in So, I don't see any point to debate the right point of view here; we clearly differ on that and on the role of this specification in managing it. But I do see a way of describing what you're putting forward as a threat into a Security Consideration, so that might be valuable if this document gets revised (or later re-spun at Proposed, if it does not). >>>I disagree. If the header appears, people will pay attention to >>>it and attempt to use the data contained. >>>The only way to get the semantics of "garbage" is mandatory dropping. > >>Maybe my brain left early for the weekend, but this seems contrary >>to existing practice for X- headers. > >That's because, prior to now, no specification stipulates that such >headers are to be generated. This document now says that such >headers are to be generated under such-and-such conditions. Now, >there are meaningful X-* headers with defined semantics. We continue to disagree with whether specifying how they are generated in a gateway has anything to do with their semantic content and/or how they are treated outside that gateway. Existing practice for anything other than the gateway doesn't change here--if you would drop X-Newsreader, you can drop this. I don't see why mentioning the creation in an RFC changes the ability to apply local policy. I'll be off-list until Monday, regards, Ted Hardie _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 10 20:08:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgtYK-0001gE-Iq; Fri, 10 Jun 2005 20:08:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgtYJ-0001g9-HT for lemonade@megatron.ietf.org; Fri, 10 Jun 2005 20:08:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26595 for ; Fri, 10 Jun 2005 20:08:41 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgtu3-0006kv-1I for lemonade@ietf.org; Fri, 10 Jun 2005 20:31:13 -0400 Received: from bbfujip7 (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11/8.12.11) with SMTP id j5B08xX4028293; Fri, 10 Jun 2005 17:09:00 -0700 From: Dave Crocker To: Ted Hardie X-Mailer: PocoMail 3.4 (2130) - Licensed Version X-URL: bbiw.net Date: Fri, 10 Jun 2005 17:08:10 -0700 Message-ID: <200561017810.847885@bbfujip7> In-Reply-To: Subject: Let's fix a process issue quickly (was: Re: [lemonade] Fwd: Appeal of decision...) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave Crocker List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org > Speaking as a technical contributor, Speaking as an IETF participant, I find it troublesome that the cognizant area director of an effort would also seek to participate as a direct contributor to that effort. It does not take much consideration of process management issues to see the inherent conflict of interest created by such a dual role. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 10 20:10:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgtZo-00024v-2W; Fri, 10 Jun 2005 20:10:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgtZm-00023u-88 for lemonade@megatron.ietf.org; Fri, 10 Jun 2005 20:10:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26636 for ; Fri, 10 Jun 2005 20:10:12 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgtvX-0006nZ-OT for lemonade@ietf.org; Fri, 10 Jun 2005 20:32:44 -0400 Received: from bbfujip7 (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11/8.12.11) with SMTP id j5B0Ahis028432; Fri, 10 Jun 2005 17:10:43 -0700 From: Dave Crocker To: Ted Hardie , Mark Crispin X-Mailer: PocoMail 3.4 (2130) - Licensed Version X-URL: bbiw.net Date: Fri, 10 Jun 2005 17:09:54 -0700 Message-ID: <200561017954.353811@bbfujip7> In-Reply-To: Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave Crocker List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org > From my point of view, naming something does not make it standards= based, sorry. i thought we were discussing a specific document intended for= standards track. the idea that a standards track document can provide specification for= something that is, itself, not standardized, is intriguing but mostly seems= oxymoronic. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 10 20:16:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgtgF-0004jO-Dk; Fri, 10 Jun 2005 20:16:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgtgD-0004jH-Ub for lemonade@megatron.ietf.org; Fri, 10 Jun 2005 20:16:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26981 for ; Fri, 10 Jun 2005 20:16:52 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgu1z-0006yy-HY for lemonade@ietf.org; Fri, 10 Jun 2005 20:39:23 -0400 Received: from bbfujip7 (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11/8.12.11) with SMTP id j5B0HJEc028643; Fri, 10 Jun 2005 17:17:19 -0700 From: Dave Crocker To: Ted Hardie , X-Mailer: PocoMail 3.4 (2130) - Licensed Version X-URL: bbiw.net Date: Fri, 10 Jun 2005 17:16:30 -0700 Message-ID: <2005610171630.976194@bbfujip7> In-Reply-To: Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave Crocker List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org > A process appeal has been raised on this document by John Klensin. > The document for that appeal has been attached. One one point > raised, that the document was changed between IETF Last Call > and passage by the IESG, I will note that the author and I (as > shepherd of the document) believed the changes made to be > editorial clarifications rather than critical to the mechanisms > agreed to by the WG. The technical problems with the current draft are substantial, and one might= even say fundamental. John's appeal is nicely focussed and pragmatic. As much as I tend to view John's notes as painfully verbose, I was struck by the number of items he cited AND that I thought every one of them significant. The cumulative effect is to feel quite simply that this document needs a thorough consideration by the working group and that a) it is nowhere near ready for publication, and b) it certainly never got proper wg review. With respect to one suggestion made, namely to simply adopt all of John's suggested changes, I think that we and the IESG can't get off that easy. First of all, John's note makes the explicit point that he has only listed examples. He sees more in the document to work on. And second, the underlying problem with the document is that it did not get the diligent review of the working group that is needed. Wholesale approval of John's suggested changes would not fix this necessary step of community review. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Jun 11 14:04:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhALQ-0000sV-Uv; Sat, 11 Jun 2005 14:04:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhALP-0000sP-IJ for lemonade@megatron.ietf.org; Sat, 11 Jun 2005 14:04:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02769 for ; Sat, 11 Jun 2005 14:04:30 -0400 (EDT) Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhAhJ-0004KI-Jd for lemonade@ietf.org; Sat, 11 Jun 2005 14:27:10 -0400 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j5BI4HV5016827; Sat, 11 Jun 2005 11:04:17 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j5BI4CNC016819; Sat, 11 Jun 2005 11:04:17 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sat, 11 Jun 2005 11:04:12 -0700 (PDT) From: "william(at)elan.net" To: Ted Hardie Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: lemonade@ietf.org, Mark Crispin X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Fri, 10 Jun 2005, Ted Hardie wrote: > 1 should be something that the the Internet does not care about, at least in > my view. While what you wrote is all true, to me X- header field is something that is specifically not standardized - none of them. Where as we appear to be trying to do just that. Additionally I would note that unless I understand things wrong, any fields that are unknown to MTA/MSA/MUA are totally ignored (same as with X- fields), so why would it make a difference if we have these MMS fields named as X-MMS- or MMS- if either case they are going to be ignored by internet MTAs? So is there really any arguments on that if these fields have MMS- prefix it could actually be bad or hurt any program operations? (as opposed to just arguing that its not the right prefix) -- William Leibzon Elan Networks william@elan.net _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 13 05:27:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhlDg-000081-BP; Mon, 13 Jun 2005 05:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhlDe-00007w-AR for lemonade@megatron.ietf.org; Mon, 13 Jun 2005 05:26:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23406 for ; Mon, 13 Jun 2005 05:26:55 -0400 (EDT) Received: from monkey.teamware.com ([62.61.83.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhlZq-0003Em-HL for lemonade@ietf.org; Mon, 13 Jun 2005 05:49:58 -0400 Received: from mx.teamw.com (mx.teamw.com [10.142.128.25]) by monkey.teamware.com (8.11.6/8.11.6) with ESMTP id j5D9S8C01470 for ; Mon, 13 Jun 2005 12:28:08 +0300 Received: from [10.142.1.3] ([10.142.1.3]) (authenticated bits=0) by mx.teamw.com (8.12.8/8.12.8) with ESMTP id j5D9ZD8L019501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 Jun 2005 12:35:15 +0300 Message-ID: <42AD511E.6020400@teamware.com> Date: Mon, 13 Jun 2005 11:25:50 +0200 From: Antony Bowesman Organization: Teamware Group User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: lemonade@ietf.org Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TWG-MailScanner: Found to be clean, Found to be clean X-TWG-MailScanner-Information: Please contact the ISP for more information X-TWG-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.717, required 5, autolearn=disabled, ALL_TRUSTED -2.82, AWL 0.10) X-MailScanner-From: adb@teamware.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Ted Hardie wrote: > While I would certainly consider shifting SHOULD to MAY here > (since facilitating the passage of an MMS header across the > Internet and back to MMS seems to be not required even if > desirable), I think translating the X-* headers to standards > headers is the wrong way to go. These *are* private use > headers from the Internet perspective and the specification as > it stands allows them to be treated as such--they can be wantonly I don't understand the benefit of defining a standardised way of achieving mapping using non standardised headers. The MIXER approach to use X400-* headers to tunnel private information seems a more sensible approach than adding X- headers. It seems clearer (and cleaner), if I want to add some MMS specific handling to my gateway, to extract semantic significance from a MMS- header than an X- one. > dropped by an intermediate MTA, for example. Translating them into > standards-based headers means that they must be retained, and > I believe is far more liable to confusion about what they will mean > on the Internet side of the gateway. They should mean nothing to > the Internet recipient. That is, I believe, how the Internet recipient > getting an unknown X-header will treat it now, and I see no > advantage to putting them into something "Message-ID" which is > extraordinarily liable to misconstruction. I see no extra confusion caused to the average internet recipient by retaining, fex. MMS-Transaction-Id: in a message compared to X- headers, such as the following in the message X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: lemonade@ietf.org I expect the average internet recipient doesn't know or even care what headers are in a message, most of which are never shown by the average MUA, and is very unlikely to understand the significance of the X- prefix in a header. Regards Antony _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 13 07:36:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhnFM-0003jU-PL; Mon, 13 Jun 2005 07:36:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhnF8-0003fe-Pc for lemonade@megatron.ietf.org; Mon, 13 Jun 2005 07:36:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01889 for ; Mon, 13 Jun 2005 07:36:37 -0400 (EDT) Received: from mail120.messagelabs.com ([216.82.255.211]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DhnbJ-0008Ni-GX for lemonade@ietf.org; Mon, 13 Jun 2005 07:59:39 -0400 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-4.tower-120.messagelabs.com!1118662576!1680112!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.69] Received: (qmail 22056 invoked from network); 13 Jun 2005 11:36:17 -0000 Received: from kcmso1.att.com (HELO kcmso1.proxy.att.com) (192.128.133.69) by server-4.tower-120.messagelabs.com with SMTP; 13 Jun 2005 11:36:17 -0000 Received: from maillennium.att.com ([135.25.114.99]) by kcmso1.proxy.att.com (AT&T IPNS/MLO-6.0) with ESMTP id j5DBaGBU031151 for ; Mon, 13 Jun 2005 06:36:16 -0500 Received: from [135.70.19.88] (unknown[135.70.19.88](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20050613113531gw100gipc9e> (Authid: tony); Mon, 13 Jun 2005 11:35:31 +0000 Message-ID: <42AD6FAC.3080401@att.com> Date: Mon, 13 Jun 2005 07:36:12 -0400 From: Tony Hansen User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: lemonade@ietf.org Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping References: <42AD511E.6020400@teamware.com> In-Reply-To: <42AD511E.6020400@teamware.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org IMHO, x- headers should never be standardized. Unfortunately, I made an assumption when I originally reviewed this document that the use of "x-" was acting as a placeholder and would be removed before publication. That was my mistake. To repeat: x- headers should never be standardized. Tony Hansen tony@att.com _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 13 15:37:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhuke-00049I-Ng; Mon, 13 Jun 2005 15:37:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhuka-000481-Ux for lemonade@megatron.ietf.org; Mon, 13 Jun 2005 15:37:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14806 for ; Mon, 13 Jun 2005 15:37:34 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dhv6s-0005RC-LV for lemonade@ietf.org; Mon, 13 Jun 2005 16:00:41 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5DJbJdv021771; Mon, 13 Jun 2005 12:37:20 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5DJbGuo007765; Mon, 13 Jun 2005 12:37:17 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <200561017810.847885@bbfujip7> References: <200561017810.847885@bbfujip7> Date: Mon, 13 Jun 2005 12:37:15 -0700 To: Dave Crocker From: Ted Hardie Subject: Re: Let's fix a process issue quickly (was: Re: [lemonade] Fwd: Appeal of decision...) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: lemonade@ietf.org, brc@zurich.ibm.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 5:08 PM -0700 6/10/05, Dave Crocker wrote: > > Speaking as a technical contributor, > > >Speaking as an IETF participant, I find it troublesome that the cognizant >area director of an effort would also seek to participate as a direct >contributor to that effort. > >It does not take much consideration of process management issues to see >the inherent conflict of interest created by such a dual role. > > d/ Dave, This is a much larger question than lemonade. I encourage you to write a draft stating your opinion that the cognizant area directors should not act as technical contributors to the efforts for which they hold management responsibilities. I believe Brian would be the right person to shepherd such a document, once you had gotten support for it. I've cc'ed him to let him know I've recommended that course of action. If you do take that course of action, please let me know where you will discuss it, as I have some comments on the proposal that don't really belong in lemonade. At the moment, however, I believe RFC 2026 is still in force. It says, in section 5: While it is recognized that entities such as the IAB and IESG are composed of individuals who may participate, as individuals, in the technical work of the IETF.... Prefacing my comments with "as technical contributor" and ending such comments with things like "my personal opinion" are ways of highlighting that I an individual participating in the technical work of the IETF, not acting in any particular role. regards, Ted Hardie _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 13 15:52:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhuzP-0002lc-Vc; Mon, 13 Jun 2005 15:52:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhuzN-0002lD-MS for lemonade@megatron.ietf.org; Mon, 13 Jun 2005 15:52:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20485 for ; Mon, 13 Jun 2005 15:52:51 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhvLe-0007eY-SV for lemonade@ietf.org; Mon, 13 Jun 2005 16:15:59 -0400 Received: from bbprime (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11/8.12.11) with SMTP id j5DJrCmV004296; Mon, 13 Jun 2005 12:53:12 -0700 From: Dave Crocker To: Ted Hardie X-Mailer: PocoMail 3.4 (2130) - Licensed Version X-URL: bbiw.net Date: Mon, 13 Jun 2005 12:52:23 -0700 Message-ID: <2005613125223.428378@bbprime> In-Reply-To: Subject: Re: Let's fix a process issue quickly (was: Re: [lemonade] Fwd: Appeal of decision...) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: lemonade@ietf.org, brc@zurich.ibm.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave Crocker List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org > > It does not take much consideration of process management issues to= see > > the inherent conflict of interest created by such a dual role. > This is a much larger question than lemonade. Actually, Ted, I was attempting to attend to a very narrow question that is= quite specific to lemonade. You are the cognizant AD for this working group. As is typical for= environments that have any concern for conflicts of interest, the IETF history is to have= the cognizant AD not be a direct contributor to the working group effort. This= keeps the authority issues notably simpler. You have chosen to take an active, technical role in the working group discussion. I was trying to point out to you the problem this causes. I= chose the working group forum in order to get it on the record and to suggest to others that we have a particularly awkward situation,. Given that there is now a rather substantial, formal appeal against your= actions concerning this working group's efforts, I was trying to suggest that you= cease your efforts to sway the group's technical discussions. > While it is recognized that entities such as the IAB and IESG are > composed of individuals who may participate, as individuals, in the > technical work of the IETF.... NOT in the activities they are overseeing, Ted. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 13 16:29:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhvYN-0002Zb-Kv; Mon, 13 Jun 2005 16:29:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhvYL-0002ZO-OI for lemonade@megatron.ietf.org; Mon, 13 Jun 2005 16:29:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03917 for ; Mon, 13 Jun 2005 16:28:59 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dhvuf-0004Jx-3Q for lemonade@ietf.org; Mon, 13 Jun 2005 16:52:07 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5DKSkCK007923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Jun 2005 13:28:46 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5DKSht1012778; Mon, 13 Jun 2005 13:28:44 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <2005613125223.428378@bbprime> References: <2005613125223.428378@bbprime> Date: Mon, 13 Jun 2005 13:28:42 -0700 To: Dave Crocker From: Ted Hardie Subject: Re: Let's fix a process issue quickly (was: Re: [lemonade] Fwd: Appeal of decision...) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: lemonade@ietf.org, brc@zurich.ibm.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 12:52 PM -0700 6/13/05, Dave Crocker wrote: > > > It does not take much consideration of process management issues to see >> > the inherent conflict of interest created by such a dual role. > >> This is a much larger question than lemonade. > > >Actually, Ted, I was attempting to attend to a very narrow question that is >quite specific to lemonade. > >You are the cognizant AD for this working group. As is typical for >environments >that have any concern for conflicts of interest, the IETF history is >to have the >cognizant AD not be a direct contributor to the working group effort. This >keeps the authority issues notably simpler. Having the Area Director directly manage a working group under himself or herself would clearly be a conflict of interest; some would argue that having an Area Director manage a working group in the same area would also be a conflict. Having an Area Director be a document author in a working group under his management might create the same conflict, and it would certainly require that a different Area Director sponsor the document while the author recused himself or herself from the ballot. But are you appear to be saying that an Area Director should make no technical contribution to the discussion of a working group on the matters before it, unless he or she is speaking as an Area Director. >You have chosen to take an active, technical role in the working group >discussion. I was trying to point out to you the problem this >causes. I chose >the working group forum in order to get it on the record and to suggest to >others that we have a particularly awkward situation,. > >Given that there is now a rather substantial, formal appeal against >your actions >concerning this working group's efforts, I was trying to suggest >that you cease >your efforts to sway the group's technical discussions. The formal appeal is on an IESG action: "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." If you are arguing that this is a special case because there an existing appeal, I misunderstood you. But that would then imply that no IESG member should enter the technical discussion on the mailing group list, and I think that is problematic as well. In general, if IESG members do not express their technical opinions on public lists, then the interaction with the technical community is limited in really unfortunate ways. I think the exchange with Mark was quite useful, even though there remain things about which we do not agree; we could have had it privately, of course, but how does that help? > >> While it is recognized that entities such as the IAB and IESG are >> composed of individuals who may participate, as individuals, in the >> technical work of the IETF.... > >NOT in the activities they are overseeing, Ted. > Again, I agree that having an individual manage himself or herself as a working group chair is over the line under most circumstances (Ned did it in one special case, as I recall, as a co-chair), and that there has to be real care taken when the role is as document author. But I think an AD would be hamstrung in his interaction with a working group if he could not make technical comments on the ongoing work or the issues that came up. And I think it is a change in our process to try to make that so. regards, Ted Hardie _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 13 16:50:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhvsj-0008CC-0a; Mon, 13 Jun 2005 16:50:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhvsg-0008BZ-1Y for lemonade@megatron.ietf.org; Mon, 13 Jun 2005 16:50:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05253 for ; Mon, 13 Jun 2005 16:49:59 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhwF0-0005J2-O9 for lemonade@ietf.org; Mon, 13 Jun 2005 17:13:08 -0400 Received: from bbprime (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11/8.12.11) with SMTP id j5DKoc0I009784; Mon, 13 Jun 2005 13:50:38 -0700 From: Dave Crocker To: Ted Hardie X-Mailer: PocoMail 3.4 (2130) - Licensed Version X-URL: bbiw.net Date: Mon, 13 Jun 2005 13:49:48 -0700 Message-ID: <2005613134948.454076@bbprime> In-Reply-To: Subject: Re: Let's fix a process issue quickly (was: Re: [lemonade] Fwd: Appeal of decision...) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Cc: lemonade@ietf.org, brc@zurich.ibm.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave Crocker List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org > But are you appear to be saying that an Area Director should make no > technical > contribution to the discussion of a working group on the matters before= it, > unless he or she is speaking as an Area Director. Not "appear to be" Ted. I am saying it simply and directly. What YOU appear to be missing is that the instant the cognizant area= director becomes a technical advocate, they lose the ability to hold the moderating position that is needed for a direct-line management position in a public decision process. For any issue that needs to be escalated to the area director, when there is= a debate about how to resolve it, how the heck can anyone expect= "impartiality" from an area director who has been an advocate? I will also note that active participation by the cognizant area director= can create some confusion, not the least of which is by that area director, themself. It is not too difficult to imagine that a directly contributing cognizant AD= could fail to distinguish when they should turn something to the group to decide, versus when it is appropriate for the AD to make a decision= directly. Oops. That's the process point of the current appeal. > The formal appeal is on an IESG action: Right. Like the cognizant AD had nothing to do with that decision? > If you are arguing that this is a special case because there an > existing appeal, I am arguing that the existing appeal is the final nail in the coffin of the= error in being both cognizant AD and direct contributor. > I misunderstood you. But that would then imply that no IESG member= should > enter the technical discussion on the mailing group list, and I think= that In the midst of an appeal, pretty much correct. Absent recusal from the authority role. Except that you can't recuse yourself after the fact. You= can, however, cease direct attempts to sway the working group decision= discussions. > problematic as well. In general, if IESG members do not express > their technical > opinions on public lists, then the interaction with the technical= community Here I am, making a very precise distinction between those activities over= which an AD has direct authority and those they don't, and here you are repeatedly= missing the point. The history has been very simple: An AD that wants to directly participate= must not have direct oversight for that activity. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 13 17:57:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhww7-0001Lu-TX; Mon, 13 Jun 2005 17:57:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhww7-0001LL-BX for lemonade@megatron.ietf.org; Mon, 13 Jun 2005 17:57:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10612 for ; Mon, 13 Jun 2005 17:57:36 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhxIR-00006L-N0 for lemonade@ietf.org; Mon, 13 Jun 2005 18:20:46 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5DLvJCK017522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Jun 2005 14:57:19 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5DLvGt1010599; Mon, 13 Jun 2005 14:57:17 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <2005613134948.454076@bbprime> References: <2005613134948.454076@bbprime> Date: Mon, 13 Jun 2005 14:57:16 -0700 To: Dave Crocker From: Ted Hardie Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: lemonade@ietf.org, Dave Crocker , brc@zurich.ibm.com Subject: [lemonade] AD as technical contributor (was Re: Let's fix a process issue quickly) X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 1:49 PM -0700 6/13/05, Dave Crocker wrote: > > But are you appear to be saying that an Area Director should make no >> technical > > contribution to the discussion of a working group on the matters >before it, >> unless he or she is speaking as an Area Director. > >Not "appear to be" Ted. I am saying it simply and directly. > >What YOU appear to be missing is that the instant the cognizant area director >becomes a technical advocate, they lose the ability to hold the moderating >position that is needed for a direct-line management position in a public >decision process. Does the phrase "speaking as an Area Director" in my statement above still hold for you, or do you, in fact, mean: "An Area Director should make no technical contribution to the discussion of a working group on the matters before it?"? >For any issue that needs to be escalated to the area director, when there is a >debate about how to resolve it, how the heck can anyone expect "impartiality" >from an area director who has been an advocate? Under most circumstances, the working group process avoids this. There are points at which the working group process calls consensus and if a technical contributor's public opinion is in the "rough" or "rough consensus", it's pretty obvious. It's certainly happened to me as a technical contributor both before and after becoming an AD, in Lemonade as one example. If you get to one of the disputes envisioned in RFC 2026, section 6.5.1, it gets escalated to the Area Director(s) for the area in which the WG is chartered--that is, both of them. Having both involved is a check to ensure impartiality, and there are further backstops from there. In any case, silence does not equate to impartiality or lack thereof. Silence could simply mean that the Area Director did not contribute an opinion, not that the AD didn't have one. And if that opinion isn't made public so that it can be commented on and, if necessary, rejected, aren't we a lot worse off? >I will also note that active participation by the cognizant area director can >create some confusion, not the least of which is by that area director, >themself. > >It is not too difficult to imagine that a directly contributing cognizant AD >could fail to distinguish when they should turn something to the group to >decide, versus when it is appropriate for the AD to make a decision directly. > >Oops. That's the process point of the current appeal. For what it's worth, I think the John's is a good use of the right to appeal. There were changes between 02 and 04, and the authors and IESG made a judgement call on whether they were clarifications or substantive. The IESG makes judgement calls on that all the time--sometime it's easy (moved a reference, made the BNF compile); sometimes it's not so clear. The appeals process is there to make sure there is a recourse when someone in the community disagrees, and I think John's using it well. I may still disagree with him at the end of the day, but I believe he's asking a good question. But that doesn't go to individual participation of the Area Director on the mailing list. John's document makes several technical arguments about how X- headers are understood in this document. Going through that, I think he's starting from a position that describing the gateway function's behavior for x- headers creates an imposition on non-gateway Internet MTAs and MUAs. I don't agree with that, as my reading is that the behavior for non-gateway Internet M*s is that everything stays the same--they get to apply local policy. Stating that opinion in response to Mark's produced what was to my view a useful technical exchange and helped expose where our assumptions differ. Not stating that opinion would have left us with less data. > An AD that wants to directly participate must >not have direct oversight for that activity. > And I believe that the current practice is that an AD who wants to run a working group or edit its document should not have direct oversight, but that ADs do make technical contributions to their working groups by participating in them. In ECRIT, where I am not the cognizant area director, for example, I have seen Jon give technical advice based on his knowledge of the formats in use (he was the document author for PIDF-LO). He's also asked questions, had disagreements with contributors, and lost some arguments. He's been, in other words, a technical contributor. If you think differently, I believe you need to write a document that amends 2026. It doesn't spell out "ADs cannot contribute technical comments to mailing lists of working groups for which they are Area Advisor". It *does* say that ADs are expected to be technical contributors to the IETF, and the base technical contribution in the IETF is mailing list participation. regards, Ted Hardie _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 13 18:13:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhxBS-0005gK-7w; Mon, 13 Jun 2005 18:13:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhxBP-0005fh-RL for lemonade@megatron.ietf.org; Mon, 13 Jun 2005 18:13:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12363 for ; Mon, 13 Jun 2005 18:13:25 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhxXl-0000m8-EM for lemonade@ietf.org; Mon, 13 Jun 2005 18:36:34 -0400 Received: from bbprime (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11/8.12.11) with SMTP id j5DMDlu1016162; Mon, 13 Jun 2005 15:13:47 -0700 From: Dave Crocker To: Ted Hardie X-Mailer: PocoMail 3.4 (2130) - Licensed Version X-URL: bbiw.net Date: Mon, 13 Jun 2005 15:12:57 -0700 Message-ID: <2005613151257.513782@bbprime> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable Cc: lemonade@ietf.org, brc@zurich.ibm.com Subject: [lemonade] Re: AD as technical contributor (was Re: Let's fix a process issue quickly) X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave Crocker List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Ted, > Does the phrase "speaking as an Area Director" in my statement above > still hold for you, or do you, in fact, mean: "An Area Director should > make no technical contribution to the discussion of a working group > on the matters before it?"? Again, you seem to be entirely missing my point. You have been taking= positions of active advocacy. That is a very, very long way indeed, from making 'no technical contribution'. A cognizant area director must not be an active contributor to the technical= discussion and, in particlar, must not take advocacy positions, unless they= recuse themselves from being cognizant ad. There is nothing particularly subtle, complex or unusual about such a= stricture. > > For any issue that needs to be escalated to the area director, when > > there is a debate about how to resolve it, how the heck can anyone > > expect "impartiality" from an area director who has been an advocate? > > > Under most circumstances, the working group process avoids this. Right. No one participating in the working group process is going to worry= about statements from the cognizant AD, as indications of clear biases the cognizant AD is likely to later show during a management intervention by= them... > In any case, silence does not equate to impartiality or lack thereof. No kidding. But it sure does lock down biases. > But that doesn't go to individual participation of the Area Director on > the mailing list. John's document makes several technical arguments= about > how X- headers are understood in this document. Going through that, I Ted, you really don't get it, do you? A cognizant area director has an authority rolein the process. An authority= role does not permit "equal" participation, no matter how differentially the= participation might be labeled. So, please stop attempting to sway the group's technical discussion. If you have so little faith in the working group's technical and discussion= skills, to believe that it can reasonably resolve these issues, then there= are larger process issues to discuss. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 13 19:57:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhynn-0001wU-6F; Mon, 13 Jun 2005 19:57:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhynk-0001vr-M8 for lemonade@megatron.ietf.org; Mon, 13 Jun 2005 19:57:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22496 for ; Mon, 13 Jun 2005 19:57:07 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhzA7-0005vq-2V for lemonade@ietf.org; Mon, 13 Jun 2005 20:20:16 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5DNusCK000994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Jun 2005 16:56:54 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5DNuo5O012945; Mon, 13 Jun 2005 16:56:52 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <2005613151257.513782@bbprime> References: <2005613151257.513782@bbprime> Date: Mon, 13 Jun 2005 16:56:50 -0700 To: Dave Crocker From: Ted Hardie Subject: [lemonade] Re: AD as technical contributor (was Re: Let's fix a process issue quickly) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: lemonade@ietf.org, Dave Crocker , brc@zurich.ibm.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 3:12 PM -0700 6/13/05, Dave Crocker wrote: > >Ted, you really don't get it, do you? > >A cognizant area director has an authority rolein the process. An authority >role does not permit "equal" participation, no matter how differentially the >participation might be labeled. No, Dave, I get it and *I disagree*. The extension of your argument is that no AD can have "equal" participation, since they can cast a DISCUSS and no IAB member can have "equal" participation, since they will eventually hear any appeals. There has to be some line between "Anything goes" and the reductio ad absurdam, and I believe it is placed at: no direct working group chair/AD overlap and no document overlap/document sponsorship. I think saying that the Area Advisor can't have and express a technical opinion doesn't work. It's "advocacy" or "swaying" just as much as any other technical comment, and I believe as long as it is in the technical realm it is both okay and a contribution to transparency. Pushing it past the working group over objections would not be advocacy, that would be abuse. And, since you've skipped this point several times, I'll repeat. I don't think your point of view is justified in our documents. If you think it should be, you should get them changed. regards, Ted _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 13 20:13:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhz3C-0005lf-SA; Mon, 13 Jun 2005 20:13:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhz3A-0005lX-EF for lemonade@megatron.ietf.org; Mon, 13 Jun 2005 20:13:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23819 for ; Mon, 13 Jun 2005 20:13:03 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhzPX-0006f5-4H for lemonade@ietf.org; Mon, 13 Jun 2005 20:36:12 -0400 Received: from bbprime (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11/8.12.11) with SMTP id j5E0DSYZ024202; Mon, 13 Jun 2005 17:13:28 -0700 From: Dave Crocker To: Ted Hardie X-Mailer: PocoMail 3.4 (2130) - Licensed Version X-URL: bbiw.net Date: Mon, 13 Jun 2005 17:12:38 -0700 Message-ID: <2005613171238.737823@bbprime> In-Reply-To: Subject: Re: [lemonade] Re: AD as technical contributor (was Re: Let's fix a process issue quickly) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: lemonade@ietf.org, brc@zurich.ibm.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave Crocker List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Ted, > No, Dave, I get it and *I disagree*. The extension of your argument is > that no AD can have "equal" participation, since they can cast a DISCUSS > and no IAB member can have "equal" participation, since they will > eventually hear any appeals. Unless they recuse themselves, which is what they do. But the cognizant AD can't do that. So please stop your own efforts at arguing ad absurdum. My statements have= been formulated carefully. Your responses are tenaciously eliminating that= care. > And, since you've skipped this point several times, I'll repeat. I= don't > think your point of view is justified in our documents. If you think > it should be, you should get them changed. I've been trying to focus on a core issues about reasonable behavior by a cognizant area director. the amount of ietf common behavior that is not documented is legion. the= amount that IS documented but is ignored is too. we don't document that area directors are prohibited from shooting working= group chairs. does that make it ok to shoot them? d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 13 20:36:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhzQI-0004V6-Bl; Mon, 13 Jun 2005 20:36:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhzQG-0004Uy-MF for lemonade@megatron.ietf.org; Mon, 13 Jun 2005 20:36:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25382 for ; Mon, 13 Jun 2005 20:36:55 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dhzmd-0007gR-EZ for lemonade@ietf.org; Mon, 13 Jun 2005 21:00:04 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5E0agCK004990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Jun 2005 17:36:43 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5E0ad5O018309; Mon, 13 Jun 2005 17:36:40 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <2005613171238.737823@bbprime> References: <2005613171238.737823@bbprime> Date: Mon, 13 Jun 2005 17:36:38 -0700 To: Dave Crocker From: Ted Hardie Subject: Re: [lemonade] Re: AD as technical contributor (was Re: Let's fix a process issue quickly) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 1.0 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: lemonade@ietf.org, Dave Crocker , brc@zurich.ibm.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 5:12 PM -0700 6/13/05, Dave Crocker wrote: >the amount of ietf common behavior that is not documented is legion. >the amount >that IS documented but is ignored is too. > >we don't document that area directors are prohibited from shooting >working group >chairs. > >does that make it ok to shoot them? > > Dave, if we documented that every participant could shoot working group chairs and explicitly said Area Directors were participants, but really meant they could only shoot working group chairs in other areas, we would need to document that too. Have a pleasant evening, Dave, regards, Ted _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 14 19:34:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiKvi-0006eX-O9; Tue, 14 Jun 2005 19:34:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiKvh-0006dT-4L for lemonade@megatron.ietf.org; Tue, 14 Jun 2005 19:34:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18490 for ; Tue, 14 Jun 2005 19:34:46 -0400 (EDT) Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiLIG-00038X-1B for lemonade@ietf.org; Tue, 14 Jun 2005 19:58:09 -0400 Received: from [10.10.1.242] (vpn-10-50-0-53.qualcomm.com [10.50.0.53]) by warlock.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5ENYQ9f023216; Tue, 14 Jun 2005 16:34:26 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Tue, 14 Jun 2005 16:32:36 -0700 To: Mark Crispin , Ted Hardie From: Randall Gellens Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 1.0 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 3:17 PM -0700 6/10/05, Mark Crispin wrote: > I contend that you greatly underestimate the problem of individuals > who will take text from an RFC out of context and demand that their > resulting interpretation is the One True Way, notwithstanding > explicit text elsewhere in the same RFC to the contrary. But this argument is not helpful, since there is no way to satisfy such people since by definition they are not reasonable. > >>> There are three ways out of the predicament. Pick your favorite poison: >>> 1) Do as John says, and give them a real name. >> As I said before, I think that makes it much harder to let people know that >> they are *not* Internet headers. > > Such arguments would be more convincing if there was a compelling > reason to believe that they are not headers. They certainly appear > to be perfectly good informational headers to me. Giving such headers a official name *would* be standardizing them, which would be confusing, I think. > >>> 2) Require that these headers be dropped. >> I believe that allowing the headers to be dropped is sufficient, but I >> would prefer requiring they be dropped to giving them Internet semantics >> by dropping the X-. I don't think we can *require* that the headers be dropped, since we can't demonstrate any interoperabuility problems by retaining them. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- There is a life-size picture of a dogcow conveniently located in the Finder. Look under "Page Setup..." Now look under "Options." Like any talented dog, it can do flips. Like any talented cow, it can do precision bitmap alignment. --Apple Tech Note #31 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 14 19:58:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiLIo-00036U-V0; Tue, 14 Jun 2005 19:58:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiLIn-00036K-6i for lemonade@megatron.ietf.org; Tue, 14 Jun 2005 19:58:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19760 for ; Tue, 14 Jun 2005 19:58:40 -0400 (EDT) Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiLfK-0004cm-G4 for lemonade@ietf.org; Tue, 14 Jun 2005 20:22:01 -0400 Received: from [10.10.1.242] (vpn-10-50-0-53.qualcomm.com [10.50.0.53]) by warlock.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5ENwQ9f026189; Tue, 14 Jun 2005 16:58:26 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Tue, 14 Jun 2005 16:53:49 -0700 To: Mark Crispin , Ted Hardie From: Randall Gellens Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 1.0 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 4:27 PM -0700 6/10/05, Mark Crispin wrote: > What if I start polluting the Internet with X-MMS-* headers that > are completely bogus and would cause harm if inserted into the MMS > world? Then, when the MMS world complains, I point at that bit in > RFC 2822 that says that X-* headers are experimental and I can put > whatever crap in such headers that I desire? Regardless of what the gateway specification says or does not say, you are able to do this today. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Algol was a great improvement on most of its successors. --C.A.R Hoare _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 14 19:58:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiLIp-00036t-5Z; Tue, 14 Jun 2005 19:58:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiLIn-00036P-QE for lemonade@megatron.ietf.org; Tue, 14 Jun 2005 19:58:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19763 for ; Tue, 14 Jun 2005 19:58:40 -0400 (EDT) Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiLfO-0004cn-2l for lemonade@ietf.org; Tue, 14 Jun 2005 20:22:02 -0400 Received: from [10.10.1.242] (vpn-10-50-0-53.qualcomm.com [10.50.0.53]) by warlock.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5ENwQ9h026189; Tue, 14 Jun 2005 16:58:29 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Tue, 14 Jun 2005 16:55:37 -0700 To: Mark Crispin , Ted Hardie From: Randall Gellens Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 1.0 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 4:27 PM -0700 6/10/05, Mark Crispin wrote: > That's because, prior to now, no specification stipulates that such > headers are to be generated. This document now says that such > headers are to be generated under such-and-such conditions. Now, > there are meaningful X-* headers with defined semantics. I'm confused. The existing wording says nothing about *generating* x-mms- headers. It also says nothing about semantics of such headers. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- For best results, be sure to double clutch when you paradigm shift. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 14 20:00:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiLKQ-0003Iq-Cg; Tue, 14 Jun 2005 20:00:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiLKO-0003GE-US for lemonade@megatron.ietf.org; Tue, 14 Jun 2005 20:00:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19878 for ; Tue, 14 Jun 2005 20:00:19 -0400 (EDT) Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiLgx-0004mx-0J for lemonade@ietf.org; Tue, 14 Jun 2005 20:23:41 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout7.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5F00CPR012092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Jun 2005 17:00:12 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5F00CUc027729 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Jun 2005 17:00:12 -0700 Date: Tue, 14 Jun 2005 17:00:13 -0700 (Pacific Daylight Time) From: Mark Crispin To: Randall Gellens Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Ted Hardie , lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Tue, 14 Jun 2005, Randall Gellens wrote: >> I contend that you greatly underestimate the problem of individuals who >> will take text from an RFC out of context and demand that their resulting >> interpretation is the One True Way, notwithstanding explicit text elsewhere >> in the same RFC to the contrary. > But this argument is not helpful, since there is no way to satisfy such > people since by definition they are not reasonable. Nevertheless, if there are obvious protocol/document fixes that preempt even an out-of-context quote from being interpreted wrongly, those fixes should be made. I spent extravagant amounts of time on the IMAP specification doing just that, because I had to do so. >>>> There are three ways out of the predicament. Pick your favorite poison: >>>> 1) Do as John says, and give them a real name. >>> As I said before, I think that makes it much harder to let people know that >>> they are *not* Internet headers. >> Such arguments would be more convincing if there was a compelling reason >> to believe that they are not headers. They certainly appear to be >> perfectly good informational headers to me. > Giving such headers a official name *would* be standardizing them, which > would be confusing, I think. Defining such headers in a document which is purportedly standards-track is standardizing them. The only way to prevent that is to remove them from the document. In RFC 822 (RFC 2822 is silent on the matter) X-* headers are a "protected set of names" for "user-defined fields". RFC 822 is still technically the standard........ Headers gatewayed from MMS do not constitute a "user-defined field". >>>> 2) Require that these headers be dropped. >>> I believe that allowing the headers to be dropped is sufficient, but I >>> would prefer requiring they be dropped to giving them Internet semantics >>> by dropping the X-. > I don't think we can *require* that the headers be dropped, since we can't > demonstrate any interoperabuility problems by retaining them. The interoperability problem is created the instant any client interprets them for any reason whatsoever. As these are X-* headers, anybody can send non-MMS email filled with such headers and containing any crap I want (but designed to cause torment to any entity which attempts to interpret them). I suspect that when the MMS community fully comprehends what this means, this mailing list will be filled with their voluable protests. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 14 20:02:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiLMH-0003Vx-Mj; Tue, 14 Jun 2005 20:02:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiLMG-0003Vs-LY for lemonade@megatron.ietf.org; Tue, 14 Jun 2005 20:02:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19953 for ; Tue, 14 Jun 2005 20:02:15 -0400 (EDT) Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiLip-0004ov-TU for lemonade@ietf.org; Tue, 14 Jun 2005 20:25:37 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout5.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5F02D5V021077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Jun 2005 17:02:13 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5F02DGs028083 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Jun 2005 17:02:13 -0700 Date: Tue, 14 Jun 2005 17:02:14 -0700 (Pacific Daylight Time) From: Mark Crispin To: Randall Gellens Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Ted Hardie , lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Tue, 14 Jun 2005, Randall Gellens wrote: >> What if I start polluting the Internet with X-MMS-* headers that are >> completely bogus and would cause harm if inserted into the MMS world? Then, >> when the MMS world complains, I point at that bit in RFC 2822 that says >> that X-* headers are experimental and I can put whatever crap in such >> headers that I desire? > Regardless of what the gateway specification says or does not say, you are > able to do this today. Yes...but... If I start spewing forth MMS-* headers that cause pain and suffering to some program that cares, a case can be made that I am an abusive sender; and consequently administrative and other sanctions should be taken against me. No such case can be made about X-* headers. By definition, they're the user's playground/jungle. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 14 20:08:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiLSe-000515-IN; Tue, 14 Jun 2005 20:08:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiLSc-000510-SP for lemonade@megatron.ietf.org; Tue, 14 Jun 2005 20:08:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20355 for ; Tue, 14 Jun 2005 20:08:49 -0400 (EDT) Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiLpC-0005Kv-4S for lemonade@ietf.org; Tue, 14 Jun 2005 20:32:11 -0400 Received: from [10.10.1.242] (vpn-10-50-0-53.qualcomm.com [10.50.0.53]) by warlock.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5F08Q9f028527; Tue, 14 Jun 2005 17:08:28 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <42AD511E.6020400@teamware.com> References: <42AD511E.6020400@teamware.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Tue, 14 Jun 2005 17:02:34 -0700 To: Antony Bowesman , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 11:25 AM +0200 6/13/05, Antony Bowesman wrote: > I don't understand the benefit of defining a standardised way of > achieving mapping using non standardised headers. > > The MIXER approach to use X400-* headers to tunnel private > information seems a more sensible approach than adding X- headers. > It seems clearer (and cleaner), if I want to add some MMS specific > handling to my gateway, to extract semantic significance from a > MMS- header than an X- one. The existing MMS system uses X-MMS-* headers. This is not something we can change. The question is how to treat such headers when a message is received from an MMS system. The existing text says almost all such headers SHOULD or MAY be dropped. The exception is X-MMS-Message-Id, where it says SHOULD be retained. Please see section 2.1.3.2 Conversion of messages from MMS to Internet format -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- What is mind? No matter. What is matter? Never mind. --Thomas Hewitt Key, 1799-1875 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 14 20:09:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiLSm-00053Y-Ps; Tue, 14 Jun 2005 20:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiLSm-00051Z-1O for lemonade@megatron.ietf.org; Tue, 14 Jun 2005 20:09:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20404 for ; Tue, 14 Jun 2005 20:08:55 -0400 (EDT) Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiLpI-0005L1-1Y for lemonade@ietf.org; Tue, 14 Jun 2005 20:32:17 -0400 Received: from [10.10.1.242] (vpn-10-50-0-53.qualcomm.com [10.50.0.53]) by warlock.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5F08Q9h028527; Tue, 14 Jun 2005 17:08:42 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <42AD6FAC.3080401@att.com> References: <42AD511E.6020400@teamware.com> <42AD6FAC.3080401@att.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Tue, 14 Jun 2005 17:03:40 -0700 To: Tony Hansen From: Randall Gellens Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 7:36 AM -0400 6/13/05, Tony Hansen wrote: > IMHO, x- headers should never be standardized. I don't think we are standardizing them. The existing MMS system uses X-MMS-* headers. This is not something we can change. The question is how to treat such headers when a message is received from an MMS system. The existing text says almost all such headers SHOULD or MAY be dropped. The exception is X-MMS-Message-Id, where it says SHOULD be retained. Please see section 2.1.3.2 Conversion of messages from MMS to Internet format -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- All true wisdom is found on T-shirts. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 14 20:13:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiLX8-0005q4-GR; Tue, 14 Jun 2005 20:13:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiLX5-0005oi-TH for lemonade@megatron.ietf.org; Tue, 14 Jun 2005 20:13:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20694 for ; Tue, 14 Jun 2005 20:13:26 -0400 (EDT) Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiLtg-0005Yc-6G for lemonade@ietf.org; Tue, 14 Jun 2005 20:36:48 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5F0DPfQ023451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Jun 2005 17:13:25 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5F0DPTw029559 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Jun 2005 17:13:25 -0700 Date: Tue, 14 Jun 2005 17:13:26 -0700 (Pacific Daylight Time) From: Mark Crispin To: Randall Gellens Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping In-Reply-To: Message-ID: References: <42AD511E.6020400@teamware.com> <42AD6FAC.3080401@att.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Tue, 14 Jun 2005, Randall Gellens wrote: > The existing text says almost all such headers SHOULD or MAY be dropped. The > exception is X-MMS-Message-Id, where it says SHOULD be retained. There's also (at a quick glance) X-Mms-Message-Class and X-Priority. The text should say that all should headers MUST be dropped or converted into headers that do not start with "X-". -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 14 20:10:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiLTx-0005NX-2Q; Tue, 14 Jun 2005 20:10:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiLTw-0005NO-Ce for lemonade@megatron.ietf.org; Tue, 14 Jun 2005 20:10:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20508 for ; Tue, 14 Jun 2005 20:10:11 -0400 (EDT) Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiLqV-0005Md-F9 for lemonade@ietf.org; Tue, 14 Jun 2005 20:33:32 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5F0A8SH023030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Jun 2005 17:10:09 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5F0A8V0029200 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Jun 2005 17:10:08 -0700 Date: Tue, 14 Jun 2005 17:10:09 -0700 (Pacific Daylight Time) From: Mark Crispin To: Randall Gellens Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Ted Hardie , lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Tue, 14 Jun 2005, Randall Gellens wrote: >> That's because, prior to now, no specification stipulates that such >> headers are to be generated. This document now says that such headers are >> to be generated under such-and-such conditions. Now, there are meaningful >> X-* headers with defined semantics. > I'm confused. The existing wording says nothing about *generating* x-mms- > headers. It also says nothing about semantics of such headers. The generation is by the gateway, in producing a message for the Internet mail infrastructure. The semantics are section 2.1.3.2 of the document, e.g.: An 'X-Mms-Message-Id:' header, if present, SHOULD be retained. The effective meaning of this statement is: when encountering an X-Mms-Message-Id header in an MMS message, you SHOULD generate an Internet header line with field name of "X-Mms-Message-Id" and field contents from the X-Mms-Message-Id header in the MMS message. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 14 20:26:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiLjE-0008SW-73; Tue, 14 Jun 2005 20:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiLjC-0008SR-UX for lemonade@megatron.ietf.org; Tue, 14 Jun 2005 20:25:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21301 for ; Tue, 14 Jun 2005 20:25:57 -0400 (EDT) Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiM5m-0006Gt-FN for lemonade@ietf.org; Tue, 14 Jun 2005 20:49:19 -0400 Received: from [10.10.1.242] (vpn-10-50-0-53.qualcomm.com [10.50.0.53]) by warlock.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5F0Pj9f000879 for ; Tue, 14 Jun 2005 17:25:46 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Tue, 14 Jun 2005 17:25:38 -0700 To: lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 1.0 (+) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 5:00 PM -0700 6/14/05, Mark Crispin wrote: > Defining such headers in a document which is purportedly > standards-track is standardizing them. The only way to prevent > that is to remove them from the document. > > In RFC 822 (RFC 2822 is silent on the matter) X-* headers are a > "protected set of names" for "user-defined fields". RFC 822 is > still technically the standard........ The problem is that the MMS community has already standardized such headers for their own use. If a gateway specification makes no mention of such headers it won't be very useful. The gateway specification must deal with the reality of MMS. Note that the current text says "MAY" or "SHOULD" drop all such headers except for X-MMS-Message-ID. If the group feels that this header, too, should say "SHOULD drop" I won't object. But if you are saying there can't be any mention of X- headers then we are really at an impasse. > > Headers gatewayed from MMS do not constitute a "user-defined field". The headers exist. The question is what to do with them. Currently, the text allows a gateway to retain or drop, with a preference to retain, and does not assign any semantics. I don't see that as standardizing such headers. >> I don't think we can *require* that the headers be dropped, since >> we can't demonstrate any interoperabuility problems by retaining >> them. > > The interoperability problem is created the instant any client > interprets them for any reason whatsoever. As these are X-* > headers, anybody can send non-MMS email filled with such headers > and containing any crap I want (but designed to cause torment to > any entity which attempts to interpret them). This is the case with any header, X- or not. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- All probabilities are 50%. Either a thing will happen or it won't. This is especially true when dealing with someone you're attracted to. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 14 20:32:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiLpj-00011j-Ol; Tue, 14 Jun 2005 20:32:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiLpi-00011e-Ig for lemonade@megatron.ietf.org; Tue, 14 Jun 2005 20:32:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21621 for ; Tue, 14 Jun 2005 20:32:41 -0400 (EDT) Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiMCG-0006m3-4n for lemonade@ietf.org; Tue, 14 Jun 2005 20:56:03 -0400 Received: from [10.10.1.242] (vpn-10-50-0-53.qualcomm.com [10.50.0.53]) by warlock.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5F0WQ9f001865; Tue, 14 Jun 2005 17:32:26 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Tue, 14 Jun 2005 17:27:13 -0700 To: Mark Crispin , Randall Gellens From: Randall Gellens Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 1.0 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Ted Hardie , lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 5:02 PM -0700 6/14/05, Mark Crispin wrote: > If I start spewing forth MMS-* headers that cause pain and > suffering to some program that cares, a case can be made that I am > an abusive sender; and consequently administrative and other > sanctions should be taken against me. > > No such case can be made about X-* headers. By definition, they're > the user's playground/jungle. I find it difficult to believe any ISP or organization would take this stance. I suspect that if you start spewing headers designed to cause grief, your organization/ISP will take the same action regardless of the X- prefix. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The only problem with being a man of leisure is that you can never stop and take a rest. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 14 20:32:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiLpn-00012D-1w; Tue, 14 Jun 2005 20:32:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiLpl-000128-JC for lemonade@megatron.ietf.org; Tue, 14 Jun 2005 20:32:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21624 for ; Tue, 14 Jun 2005 20:32:44 -0400 (EDT) Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiMCM-0006m4-5o for lemonade@ietf.org; Tue, 14 Jun 2005 20:56:06 -0400 Received: from [10.10.1.242] (vpn-10-50-0-53.qualcomm.com [10.50.0.53]) by warlock.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5F0WQ9h001865; Tue, 14 Jun 2005 17:32:30 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Tue, 14 Jun 2005 17:28:37 -0700 To: Mark Crispin , Randall Gellens From: Randall Gellens Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 1.0 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Ted Hardie , lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 5:10 PM -0700 6/14/05, Mark Crispin wrote: > The generation is by the gateway, in producing a message for the > Internet mail infrastructure. > > The semantics are section 2.1.3.2 of the document, e.g.: > > An 'X-Mms-Message-Id:' header, if present, SHOULD be retained. > > The effective meaning of this statement is: when encountering an > X-Mms-Message-Id header in an MMS message, you SHOULD generate an > Internet header line with field name of "X-Mms-Message-Id" and > field contents from the X-Mms-Message-Id header in the MMS message. So your argument is that passing a header through is the same as generating it? I hadn't realized that, which is why I was confused. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Look Bruce, the bat signal!!! _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 14 20:37:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiLub-0001Fr-IV; Tue, 14 Jun 2005 20:37:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiLua-0001Fm-Ef for lemonade@megatron.ietf.org; Tue, 14 Jun 2005 20:37:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21879 for ; Tue, 14 Jun 2005 20:37:43 -0400 (EDT) Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiMHA-0006yE-3s for lemonade@ietf.org; Tue, 14 Jun 2005 21:01:05 -0400 Received: from [10.10.1.242] (vpn-10-50-0-53.qualcomm.com [10.50.0.53]) by warlock.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5F0bR9f002553 for ; Tue, 14 Jun 2005 17:37:28 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <42AD511E.6020400@teamware.com> <42AD6FAC.3080401@att.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Tue, 14 Jun 2005 17:36:57 -0700 To: lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 5:13 PM -0700 6/14/05, Mark Crispin wrote: > On Tue, 14 Jun 2005, Randall Gellens wrote: >> The existing text says almost all such headers SHOULD or MAY be >> dropped. The exception is X-MMS-Message-Id, where it says SHOULD >> be retained. > > There's also (at a quick glance) X-Mms-Message-Class and X-Priority. The text says: The 'X-Mms-Message-Class:' header MAY be retained. There's not much difference between 'MAY be retained' and 'MAY be discarded'. I agree the wording does convey a slight preference, but that's all. > The text should say that all should headers MUST be dropped or > converted into headers that do not start with "X-". I think converting into non-X headers is worse than allowing the headers to stay or be dropped. To convert into non-X headers would be standardizing the semantics of such headers. It also creates new problems, since we will undoubtedly see messages that have both the X- and the non-X versions of the headers, with different values. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Windows users often swear at their PC's whereas Mac users often swear by their Macs. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 14 20:41:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiLyX-0002ap-K9; Tue, 14 Jun 2005 20:41:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiLyW-0002ae-1o for lemonade@megatron.ietf.org; Tue, 14 Jun 2005 20:41:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22152 for ; Tue, 14 Jun 2005 20:41:46 -0400 (EDT) Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiML5-0007JY-Fo for lemonade@ietf.org; Tue, 14 Jun 2005 21:05:09 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5F0fgVO003358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Jun 2005 17:41:42 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5F0ffLV032532 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Jun 2005 17:41:42 -0700 Date: Tue, 14 Jun 2005 17:41:43 -0700 (Pacific Daylight Time) From: Mark Crispin To: Randall Gellens Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Tue, 14 Jun 2005, Randall Gellens wrote: > The problem is that the MMS community has already standardized such headers > for their own use. If a gateway specification makes no mention of such > headers it won't be very useful. The gateway specification must deal with > the reality of MMS. That's irrelevant. MMS is not Internet email. Their specifications, standards, and requirements are of no concern to us except for how it affects a gateway between MMS and Internet email. If the MMS specification stated that all messages contained: Reply-to: president@whitehouse.gov you would consider it absurd to say that MMS requires that all messages gateways to the Internet must be replied to George Bush. Clearly, in such a case, the meaning of that header has to be understood *in the MMS context*, and a header with equivalent meaning *in the Internet context* has to be generated in its place. Apparently, X-Mms-Message-Id does not have the meaning of "user defined field" in the MMS context. If the data from that header is to be passed to the Internet, it should not be passed as data that has the meaning of "user defined field" in the Internet context. > Note that the current text says "MAY" or "SHOULD" drop all such headers > except for X-MMS-Message-ID. If the group feels that this header, too, > should say "SHOULD drop" I won't object. But if you are saying there can't > be any mention of X- headers then we are really at an impasse. I guess that you'll have to break the impass, because there is going to be a howl of protest at any standardization of X- headers for anything other than "user-defined field"; and that is what the document as currently constituted does. > The headers exist. The question is what to do with them. Convert it from X-Mms-Message-Id to Mms-Message-Id. Or, if you prefer, MMS-X-Mms-Message-Id. Or even Mark-Crispin-is-a-crackpot-X-Mms-Message-Id. Just don't inflict a document which defines *Internet* messages with X- headers that are anything other than "user-defined fields". >> The interoperability problem is created the instant any client interprets >> them for any reason whatsoever. As these are X-* headers, anybody can send >> non-MMS email filled with such headers and containing any crap I want (but >> designed to cause torment to any entity which attempts to interpret them). > This is the case with any header, X- or not. No, because it's abuse to generate a non X- header with that purpose, and sanctions can be imposed on the abuser. It is not abuse to do so with an X- header. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 14 20:46:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiM3S-000432-Gg; Tue, 14 Jun 2005 20:46:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiM3Q-00042x-Tx for lemonade@megatron.ietf.org; Tue, 14 Jun 2005 20:46:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22360 for ; Tue, 14 Jun 2005 20:46:51 -0400 (EDT) Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiMQ0-0007WU-DM for lemonade@ietf.org; Tue, 14 Jun 2005 21:10:13 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout7.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5F0kn3o018206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Jun 2005 17:46:49 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5F0knl9000546 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Jun 2005 17:46:49 -0700 Date: Tue, 14 Jun 2005 17:46:50 -0700 (Pacific Daylight Time) From: Mark Crispin To: Randall Gellens Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Ted Hardie , lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Tue, 14 Jun 2005, Randall Gellens wrote: >> If I start spewing forth MMS-* headers that cause pain and suffering to >> some program that cares, a case can be made that I am an abusive sender; >> and consequently administrative and other sanctions should be taken against >> me. >> No such case can be made about X-* headers. By definition, they're the >> user's playground/jungle. > I find it difficult to believe any ISP or organization would take this > stance. I suspect that if you start spewing headers designed to cause grief, > your organization/ISP will take the same action regardless of the X- prefix. In doing so, that organization/ISP would open itself up to a very expensive lawsuit. It is difficult enough for ISPs to get rid of spammers that they inadvertantly acquired as customers, even when there are TOS and AUP forbidding it. How well can an ISP can take punitive action against someone who uses a protocol according to the protocol specification?? It says right here, "user-defined field". I'm a user, I defined it. What's the problem? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 14 20:54:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiMB6-0004v0-85; Tue, 14 Jun 2005 20:54:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiMB4-0004uq-WF for lemonade@megatron.ietf.org; Tue, 14 Jun 2005 20:54:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23044 for ; Tue, 14 Jun 2005 20:54:45 -0400 (EDT) Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiMXe-00083y-Kb for lemonade@ietf.org; Tue, 14 Jun 2005 21:18:08 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5F0shqZ004774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Jun 2005 17:54:44 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5F0shsb024193 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Jun 2005 17:54:43 -0700 Date: Tue, 14 Jun 2005 17:54:44 -0700 (Pacific Daylight Time) From: Mark Crispin To: Randall Gellens Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Ted Hardie , lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Tue, 14 Jun 2005, Randall Gellens wrote: > So your argument is that passing a header through is the same as generating > it? I hadn't realized that, which is why I was confused. Of course it is. MMS and Internet mail each have their own standards and specifications. Consequently, a gateway between the two must accept a source message, and use that message as data to generate a destination message. A null transformation of a datum by the gateway is permissible only when that datum is identical with identical semantics in both. In Internet mail, X-* headers have the semantics of "user-defined field". They therefore can not be used to represent MMS headers which have different sematics. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 14 21:01:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiMHA-0005et-VY; Tue, 14 Jun 2005 21:01:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiMH9-0005e1-DA for lemonade@megatron.ietf.org; Tue, 14 Jun 2005 21:01:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23531 for ; Tue, 14 Jun 2005 21:01:01 -0400 (EDT) Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiMdi-0008Sl-0X for lemonade@ietf.org; Tue, 14 Jun 2005 21:24:24 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5F10wtS029062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Jun 2005 18:00:59 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5F10w19024649 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Jun 2005 18:00:58 -0700 Date: Tue, 14 Jun 2005 18:00:59 -0700 (Pacific Daylight Time) From: Mark Crispin To: Randall Gellens Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping In-Reply-To: Message-ID: References: <42AD511E.6020400@teamware.com> <42AD6FAC.3080401@att.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Tue, 14 Jun 2005, Randall Gellens wrote: > The text says: The 'X-Mms-Message-Class:' header MAY be retained. Stating that thereby defines, as an exception to the long-establish rule of X-* headers being "user-defined field", that the "X-Mms-Message-Class" field name identifies data in an MMS-origin message which was conveyed in the X-Mms-Message-Class header. That is the problem. > There's not much difference between 'MAY be retained' and 'MAY be > discarded'. I agree the wording does convey a slight preference, but > that's all. The problem is the MAY, not "retained" or "discarded". > I think converting into non-X headers is worse than allowing the headers to > stay or be dropped. Allowing the headers to stay is a non-starter. Therefore, you are saying that the headers must be dropped. Fine. Make that change. > To convert into non-X headers would be standardizing the > semantics of such headers. An example of those semantics would be: The MMS-X-Mms-Message-Class header in Internet mail identifies data in an MMS-origin message which was conveyed in the X-Mms-Message-Class header. There's nothing wrong with that. Someone may even appreciate having such a header. > It also creates new problems, since we will > undoubtedly see messages that have both the X- and the non-X versions of the > headers, with different values. Not if you add a prefix instead of removing the X-. If MMS-X-Mms-Message-Class doesn't work, then how about From-MMS-X-Mms-Message-Class? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 14 23:45:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiOqN-0002ow-Ee; Tue, 14 Jun 2005 23:45:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiOqM-0002or-Py for lemonade@megatron.ietf.org; Tue, 14 Jun 2005 23:45:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02699 for ; Tue, 14 Jun 2005 23:45:32 -0400 (EDT) Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiPCy-0000WG-2e for lemonade@ietf.org; Wed, 15 Jun 2005 00:08:57 -0400 Received: from [10.10.1.242] (vpn-10-50-16-46.qualcomm.com [10.50.16.46]) by warlock.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5F3jE9f028937 for ; Tue, 14 Jun 2005 20:45:16 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Tue, 14 Jun 2005 20:44:13 -0700 To: lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 1.0 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 5:46 PM -0700 6/14/05, Mark Crispin wrote: > On Tue, 14 Jun 2005, Randall Gellens wrote: >>> If I start spewing forth MMS-* headers that cause pain and >>> suffering to some program that cares, a case can be made that I >>> am an abusive sender; and consequently administrative and other >>> sanctions should be taken against me. >>> No such case can be made about X-* headers. By definition, >>> they're the user's playground/jungle. >> I find it difficult to believe any ISP or organization would take >> this stance. I suspect that if you start spewing headers designed >> to cause grief, your organization/ISP will take the same action >> regardless of the X- prefix. > > In doing so, that organization/ISP would open itself up to a very > expensive lawsuit. > > It is difficult enough for ISPs to get rid of spammers that they > inadvertantly acquired as customers, even when there are TOS and > AUP forbidding it. > > How well can an ISP can take punitive action against someone who > uses a protocol according to the protocol specification?? It says > right here, "user-defined field". I'm a user, I defined it. > What's the problem? I don't think you'd win that lawsuit, just as I don't think the ISP cares about an X- prefix. If you are crafting messages to cause harm, waving the RFCs doesn't strike me as likely to be of much use. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The first ninety percent of the task takes ninety percent of the time, and the last ten percent takes the other ninety percent. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 15 00:03:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiP7S-0005k7-EE; Wed, 15 Jun 2005 00:03:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiP7P-0005jt-C7 for lemonade@megatron.ietf.org; Wed, 15 Jun 2005 00:03:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03627 for ; Wed, 15 Jun 2005 00:03:08 -0400 (EDT) Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiPU0-0001WL-Aw for lemonade@ietf.org; Wed, 15 Jun 2005 00:26:33 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout1.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5F437m3017826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Jun 2005 21:03:07 -0700 Received: from Shimo-Tomobiki.panda.com (panda.com [206.124.149.114]) (authenticated authid=mrc) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5F436s9011133 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Jun 2005 21:03:07 -0700 Date: Tue, 14 Jun 2005 21:03:01 -0700 From: Mark Crispin To: Randall Gellens Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Tue, 14 Jun 2005, Randall Gellens wrote: > I don't think you'd win that lawsuit, just as I don't think the ISP cares > about an X- prefix. If you are crafting messages to cause harm, waving the > RFCs doesn't strike me as likely to be of much use. I'm sending a perfectly standards-compliant Internet message, it's not spam (perhaps it's to a mailing list that I have ever right to use), some crank at some other site says that it crashes his MUA, and my ISP terminates me based upon the say-so of that crank? I don't think so. ISPs have a hard enough time getting rid of spammers without cancelling legitimate customers just because someone doesn't like that customer's MUA's use of X-* field names in headers. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 15 04:51:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiTcR-0008IV-Rr; Wed, 15 Jun 2005 04:51:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiTcP-0008II-L6 for lemonade@megatron.ietf.org; Wed, 15 Jun 2005 04:51:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23556 for ; Wed, 15 Jun 2005 04:51:27 -0400 (EDT) Received: from dsl-217-155-137-62.zen.co.uk ([217.155.137.62] helo=gw2.gestalt.entity.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiTz3-0000IJ-7j for lemonade@ietf.org; Wed, 15 Jun 2005 05:14:54 -0400 Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id BE2B0154009; Wed, 15 Jun 2005 08:51:01 +0000 (UTC) Date: Wed, 15 Jun 2005 09:39:18 +0100 Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" References: In-Reply-To: MIME-Version: 1.0 Message-Id: <3722.1118824758.928295@localhost.localdomain> From: Dave Cridland To: Mark Crispin Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: lemonade@ietf.org, Randall Gellens X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Wed Jun 15 05:03:01 2005, Mark Crispin wrote: > On Tue, 14 Jun 2005, Randall Gellens wrote: >> I don't think you'd win that lawsuit, just as I don't think the >> ISP cares about an X- prefix. If you are crafting messages to >> cause harm, waving the RFCs doesn't strike me as likely to be of >> much use. > > I'm sending a perfectly standards-compliant Internet message, it's > not spam (perhaps it's to a mailing list that I have ever right to > use), some crank at some other site says that it crashes his MUA, > and my ISP terminates me based upon the say-so of that crank? Another argument, and one possibly more to the point, is that if a mail filter program or MTA chooses to drop, or worse, replace the header with a private use field (Perhaps it's Mark's Message System, and it deploys its own internal message id to avoid duplicates), then someone will raise a bug report against it. Are they right to do so? The same argument applies to X-Priority and X-Mailer, of course. The question is whether introducing another essentially standard "X-" header - and this document does appear to do so - is making the problem worse or not. Ted made the assertion that the X-MMS-Message-Id header can never mean anything to an internet recipient - I'd like to see, for my own peace of mind, whether this is really the case. My suspicion is that an MMS-aware Internet MUA may well find a use for it, but my knowledge of the MMS standards is precisely zero. Given the opportunity to change the specification such that it maps the X-MMS-Message-Id MMS header onto an MMS-Message-Id Internet header, my inclination would be to do so, likewise with X-MMS-Message-Class. My inclination would also be to drop the references to X-Priority. While there's no point in pretending it doesn't exist, the Importance header is the standard one. I'd see no problem in referring to X-Priority/Importance mappings in a non-normative Appendix, of course. Dave. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 15 13:01:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DibGg-0000qJ-DM; Wed, 15 Jun 2005 13:01:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DibGe-0000qD-Sk for lemonade@megatron.ietf.org; Wed, 15 Jun 2005 13:01:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03425 for ; Wed, 15 Jun 2005 13:01:30 -0400 (EDT) Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DibdM-0004LQ-Ju for lemonade@ietf.org; Wed, 15 Jun 2005 13:25:02 -0400 Received: from [10.10.1.242] (vpn-10-50-16-16.qualcomm.com [10.50.16.16]) by warlock.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5FH139h007349; Wed, 15 Jun 2005 10:01:08 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <3722.1118824758.928295@localhost.localdomain> References: <3722.1118824758.928295@localhost.localdomain> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Wed, 15 Jun 2005 09:59:00 -0700 To: Dave Cridland , Mark Crispin From: Randall Gellens Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 1.0 (+) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: lemonade@ietf.org, Randall Gellens X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 9:39 AM +0100 6/15/05, Dave Cridland wrote: > Another argument, and one possibly more to the point, is that if a > mail filter program or MTA chooses to drop, or worse, replace the > header with a private use field (Perhaps it's Mark's Message > System, and it deploys its own internal message id to avoid > duplicates), then someone will raise a bug report against it. > > Are they right to do so? > > The same argument applies to X-Priority and X-Mailer, of course. > The question is whether introducing another essentially standard > "X-" header - and this document does appear to do so - is making > the problem worse or not. > > Ted made the assertion that the X-MMS-Message-Id header can never > mean anything to an internet recipient - I'd like to see, for my > own peace of mind, whether this is really the case. My suspicion is > that an MMS-aware Internet MUA may well find a use for it, but my > knowledge of the MMS standards is precisely zero. > > Given the opportunity to change the specification such that it maps > the X-MMS-Message-Id MMS header onto an MMS-Message-Id Internet > header, my inclination would be to do so, likewise with > X-MMS-Message-Class. I'd be fine with changing the text to say "MAY drop" X-Mms-Message-ID and X-Mms-Message-Class, which would make them the same as the other X-Mms-* headers. > My inclination would also be to drop the references to X-Priority. > While there's no point in pretending it doesn't exist, the > Importance header is the standard one. I'd see no problem in > referring to X-Priority/Importance mappings in a non-normative > Appendix, of course. I'd be fine with moving all mention of X-Priority to an informative Appendix. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- It is by the fortune of God that, in this country, we have three benefits: freedom of speech, freedom of thought, and the wisdom never to use either. --Mark Twain _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 15 15:31:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Didbk-00045D-Fo; Wed, 15 Jun 2005 15:31:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Didbh-000458-TG for lemonade@megatron.ietf.org; Wed, 15 Jun 2005 15:31:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19588 for ; Wed, 15 Jun 2005 15:31:24 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DidyR-0005co-Ae for lemonade@ietf.org; Wed, 15 Jun 2005 15:54:56 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5FJV9CK022978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Jun 2005 12:31:09 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5FJV6uo010920; Wed, 15 Jun 2005 12:31:07 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 15 Jun 2005 12:31:06 -0700 To: Mark Crispin , Randall Gellens From: Ted Hardie Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 5:54 PM -0700 6/14/05, Mark Crispin wrote: >A null transformation of a datum by the gateway is permissible only >when that datum is identical with identical semantics in both. In >Internet mail, X-* headers have the semantics of "user-defined >field". They therefore can not be used to represent MMS headers >which have different sematics. > But is this a null transformation? The view of X- headers in the two systems is such that I think it's reasonably to read it as a transformation from "semantically valid" to "semantically null". As long as the X-MMS header is on the Internet side of the gateway, it is semantically null because there is no user definition of the field. True, it got made "semantically null" by being copied verbatim into a system which treats strings starting X- in a s pecial way, but it still got transformed as a result, didn't it? I'm also somewhat confused about what you think "user defined" implies in the current Internet case. I see lots of X- headers that are clearly parts of larger systems or are otherwise non-individual user defined headers (brightmail poetry, for example). Why are OMA-defined headers different here? regards, Ted Hardie _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 15 16:05:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Die8Q-000260-2R; Wed, 15 Jun 2005 16:05:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Die8O-00025e-4N for lemonade@megatron.ietf.org; Wed, 15 Jun 2005 16:05:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21914 for ; Wed, 15 Jun 2005 16:05:09 -0400 (EDT) Received: from dsl-217-155-137-62.zen.co.uk ([217.155.137.62] helo=gw2.gestalt.entity.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DieV5-0007gr-Cx for lemonade@ietf.org; Wed, 15 Jun 2005 16:28:43 -0400 Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 090F0154009; Wed, 15 Jun 2005 20:04:48 +0000 (UTC) Date: Wed, 15 Jun 2005 20:52:49 +0100 Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" References: <3722.1118824758.928295@localhost.localdomain> In-Reply-To: MIME-Version: 1.0 Message-Id: <28160.1118865169.416553@peirce> From: Dave Cridland To: Randall Gellens Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: lemonade@ietf.org, Randall Gellens , Mark Crispin X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Wed Jun 15 17:59:00 2005, Randall Gellens wrote: > At 9:39 AM +0100 6/15/05, Dave Cridland wrote: >> Given the opportunity to change the specification such that it >> maps the X-MMS-Message-Id MMS header onto an MMS-Message-Id >> Internet header, my inclination would be to do so, likewise with >> X-MMS-Message-Class. > > I'd be fine with changing the text to say "MAY drop" > X-Mms-Message-ID and X-Mms-Message-Class, which would make them the > same as the other X-Mms-* headers. > > Are there any problems with mapping them to MMS-* that I've overlooked? It would seem to be a change that's likely to either leave technical problems the same, or lower them, but not raise them. I don't see how it would alter the complexity of an implementation to rename the headers, nor do I see how it could cause any technical problems. I do see some slim chance of interoperability problems by retaining the "X-" prefix, however. >> My inclination would also be to drop the references to >> X-Priority. While there's no point in pretending it doesn't exist, >> the Importance header is the standard one. I'd see no problem in >> referring to X-Priority/Importance mappings in a non-normative >> Appendix, of course. > > I'd be fine with moving all mention of X-Priority to an informative > Appendix. I think that would improve the specification, and my impression is that it would satisfy Mark, John, etc, on this point at least. Dave. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 15 17:08:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dif7e-0008Cl-8L; Wed, 15 Jun 2005 17:08:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dif7d-0008Ca-7R for lemonade@megatron.ietf.org; Wed, 15 Jun 2005 17:08:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06919 for ; Wed, 15 Jun 2005 17:08:26 -0400 (EDT) Received: from dsl-217-155-137-62.zen.co.uk ([217.155.137.62] helo=gw2.gestalt.entity.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DifUM-0006cm-GK for lemonade@ietf.org; Wed, 15 Jun 2005 17:32:01 -0400 Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 28BB1154009; Wed, 15 Jun 2005 21:08:13 +0000 (UTC) Date: Wed, 15 Jun 2005 21:56:13 +0100 Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" References: In-Reply-To: MIME-Version: 1.0 Message-Id: <28856.1118868973.056825@peirce> From: Dave Cridland To: Ted Hardie Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: lemonade@ietf.org, Mark Crispin , Randall Gellens X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Wed Jun 15 20:31:06 2005, Ted Hardie wrote: > At 5:54 PM -0700 6/14/05, Mark Crispin wrote: >> A null transformation of a datum by the gateway is permissible >> only when that datum is identical with identical semantics in >> both. In Internet mail, X-* headers have the semantics of >> "user-defined field". They therefore can not be used to represent >> MMS headers which have different sematics. >> >> > But is this a null transformation? The view of X- headers in the > two systems is > such that I think it's reasonably to read it as a transformation > from > "semantically valid" to "semantically null". As long as the X-MMS > header > is on the Internet side of the gateway, it is semantically null > because there > is no user definition of the field. True, it got made > "semantically null" by > being copied verbatim into a system which treats strings starting > X- in a s > pecial way, but it still got transformed as a result, didn't it? > > You appear to be agreeing that the semantics were changed, which is, I think, Mark's point. > I'm also somewhat confused about what you think "user defined" > implies > in the current Internet case. I see lots of X- headers that are > clearly > parts of larger systems or are otherwise non-individual user defined > headers (brightmail poetry, for example). None are defined by a standards-track IETF document, in as much as I'm aware. I believe Mark was referring, by "user-defined field", to section 4.7.5 of RFC822, which uses this term. (Admittedly, it's actually "user-defined-field[s]", but I'm willing to forgive Mark his missing hyphen.) I don't think he intended to suggest that all X-* headers were defined by individual users of network mail, even if that's the language used elswhere in that section, but merely that from a standards compliance perspective, they can be. > Why are OMA-defined headers > different here? They're different because they don't exist. To the best of my very limited knowledge of the OMA, they have not defined any Internet message header fields at all. Assuming you're referring to the X-MMS-* fields, however, those are different because they're not defined by the OMA, but by the IETF, and, in particular, this working group. Dave. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 15 17:17:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DifGS-0001c2-52; Wed, 15 Jun 2005 17:17:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DifGR-0001bu-9O for lemonade@megatron.ietf.org; Wed, 15 Jun 2005 17:17:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07463 for ; Wed, 15 Jun 2005 17:17:32 -0400 (EDT) Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DifdB-0007DM-Q2 for lemonade@ietf.org; Wed, 15 Jun 2005 17:41:07 -0400 Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (EIMS X 3.3d13); Wed, 15 Jun 2005 16:17:18 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 7.0a12] Date: Wed, 15 Jun 2005 16:17:15 -0500 To: Mark Crispin From: Pete Resnick Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: lemonade@ietf.org Subject: [lemonade] 822/2822 on X-* header fields (Was: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail") X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On 6/14/05 at 5:00 PM -0700, Mark Crispin wrote: >In RFC 822 (RFC 2822 is silent on the matter) X-* headers are a >"protected set of names" for "user-defined fields". Just for information: The reason 2822 is silent on the matter is because the DRUMS working group could not come to consensus on whether X-* header fields (a) are good for non-standardizable experimental purposes and should be encouraged or (b) should never be used because of transition costs and the possibility of leakage in non-experimental contexts. Nobody thought that X-* names should ever be standardized. (And I will deftly avoid the question that is being appealed, whether they should appear in a standards track document at all.) pr -- Pete Resnick QUALCOMM Incorporated _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 15 17:42:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Difex-0007RN-K9; Wed, 15 Jun 2005 17:42:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Difev-0007RI-L2 for lemonade@megatron.ietf.org; Wed, 15 Jun 2005 17:42:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08765 for ; Wed, 15 Jun 2005 17:42:51 -0400 (EDT) Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dig1g-000067-Dk for lemonade@ietf.org; Wed, 15 Jun 2005 18:06:25 -0400 Received: from [10.10.1.242] (vpn-10-50-0-63.qualcomm.com [10.50.0.63]) by warlock.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5FLge9f018109 for ; Wed, 15 Jun 2005 14:42:41 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <28160.1118865169.416553@peirce> References: <3722.1118824758.928295@localhost.localdomain> <28160.1118865169.416553@peirce> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Wed, 15 Jun 2005 14:37:51 -0700 To: lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 1.0 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 8:52 PM +0100 6/15/05, Dave Cridland wrote: >> I'd be fine with changing the text to say "MAY drop" >> X-Mms-Message-ID and X-Mms-Message-Class, which would make them >> the same as the other X-Mms-* headers. >> > Are there any problems with mapping them to MMS-* that I've overlooked? I am concerned that doing so will lead to more problems than just dropping them. I could be wrong, of course. But it seems to me that if we say to drop them, what will likely happen in reality is that a lot of implementations will leave them alone. If we say to map X-Mms-Message-Class to Mms-X-Mms-Message-Class, in reality some implementations will do so, some will drop them, some will leave them in, and some will do both, and probably manage to change the value of one of the two nearly identical headers. I suspect that will cause more problems should such messages make it through the Internet and into another MMS system. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Squad Helps Dog Bite Victim --Newspaper headline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 15 18:49:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DighU-0004Lw-33; Wed, 15 Jun 2005 18:49:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DighS-0004L6-2u for lemonade@megatron.ietf.org; Wed, 15 Jun 2005 18:49:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13841 for ; Wed, 15 Jun 2005 18:49:31 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dih4D-0003i4-Ei for lemonade@ietf.org; Wed, 15 Jun 2005 19:13:06 -0400 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j5FMnLAn013744; Wed, 15 Jun 2005 17:49:21 -0500 (CDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 15 Jun 2005 17:48:57 -0500 Message-ID: <54E40201497DF142B06B27255953F79715BDD702@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Dave Cridland Subject: RE: [lemonade] Fwd: Appeal of decision to standardize "Mapping Be tween the Multimedia Messaging Service (MMS) and Internet Mail" Date: Wed, 15 Jun 2005 17:48:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org I suspect there is some confusion here. OMA has defined RFC822 headers for use within the MMS domain. OMA designed MMS as an extenion of Internet email, and extended it in some weird ways for tactical business reasons. (like wanting read receipts two years before the MDN work finished) In general, MMS and Internet email are plug-compatible... as in, I can plug my PC in a socket in the UK or the US, and it pretty much works. Not all features work, and it may not be safe in all circumstances. The protocols are sooo similar, that using the same user agent for mobile internet email and MMS will be common. (it is a detail that one message was retrieved via WAP/HTTP and the other via POP) I will mix MMS messages and Internet messages in the same client-side inbox. They are both RFC822 message, with MIME body structure. It is very likely that MMS extenson header fields show up in the wild today, largely because you can resend an MMS message to an Internet submission server... and it just works. For these reasons, I preferred to keep X-MMS as defined by the OMA for MMS messages gatewayed to the Internet. In that case, there are that many fewer headers I need to understand as a recipient UA. I will have to parse the X-MMS version since I get them from the MMS message store, and I will likely get "escapee" MMS messages with X-MMs headers from my Internet message store. Adding a parser to also look for MMS- headers is not a big deal, it just seems unnecessary. I am just trying to avoid the current situation where a client needs to look for X-priority, X-MS-priority, and Importance to maximize the odds that the recipients sees what the sender intended. If protocol purity is the order of the day, then by all means, define MMS-headers to replace X-MMS-headers. This can be enforced in the gateways. It won't do too much for the other paths of leakage between the domains. In the same appendix discussing X-priority, please mention that X-MMS headers can also be expected to show up in the wild, and if seen, they probably mean the same as MMS-headers. Greg V. -----Original Message----- From: Dave Cridland [mailto:dave@cridland.net] Sent: Wednesday, June 15, 2005 4:56 PM To: Ted Hardie Cc: lemonade@ietf.org; Mark Crispin; Randall Gellens Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" On Wed Jun 15 20:31:06 2005, Ted Hardie wrote: > At 5:54 PM -0700 6/14/05, Mark Crispin wrote: >> A null transformation of a datum by the gateway is permissible >> only when that datum is identical with identical semantics in >> both. In Internet mail, X-* headers have the semantics of >> "user-defined field". They therefore can not be used to represent >> MMS headers which have different sematics. >> >> > But is this a null transformation? The view of X- headers in the > two systems is > such that I think it's reasonably to read it as a transformation > from > "semantically valid" to "semantically null". As long as the X-MMS > header > is on the Internet side of the gateway, it is semantically null > because there > is no user definition of the field. True, it got made > "semantically null" by > being copied verbatim into a system which treats strings starting > X- in a s > pecial way, but it still got transformed as a result, didn't it? > > You appear to be agreeing that the semantics were changed, which is, I think, Mark's point. > I'm also somewhat confused about what you think "user defined" > implies > in the current Internet case. I see lots of X- headers that are > clearly > parts of larger systems or are otherwise non-individual user defined > headers (brightmail poetry, for example). None are defined by a standards-track IETF document, in as much as I'm aware. I believe Mark was referring, by "user-defined field", to section 4.7.5 of RFC822, which uses this term. (Admittedly, it's actually "user-defined-field[s]", but I'm willing to forgive Mark his missing hyphen.) I don't think he intended to suggest that all X-* headers were defined by individual users of network mail, even if that's the language used elswhere in that section, but merely that from a standards compliance perspective, they can be. > Why are OMA-defined headers > different here? They're different because they don't exist. To the best of my very limited knowledge of the OMA, they have not defined any Internet message header fields at all. Assuming you're referring to the X-MMS-* fields, however, those are different because they're not defined by the OMA, but by the IETF, and, in particular, this working group. Dave. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 16 05:21:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiqYs-0007jh-35; Thu, 16 Jun 2005 05:21:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiqYq-0007jc-SH for lemonade@megatron.ietf.org; Thu, 16 Jun 2005 05:21:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29980 for ; Thu, 16 Jun 2005 05:21:15 -0400 (EDT) Received: from dsl-217-155-137-62.zen.co.uk ([217.155.137.62] helo=gw2.gestalt.entity.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Diqvh-00063s-It for lemonade@ietf.org; Thu, 16 Jun 2005 05:44:59 -0400 Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 1C479154009; Thu, 16 Jun 2005 09:20:56 +0000 (UTC) Date: Thu, 16 Jun 2005 10:08:38 +0100 Subject: RE: [lemonade] Fwd: Appeal of decision to standardize "Mapping Be tween the Multimedia Messaging Service (MMS) and Internet Mail" References: <54E40201497DF142B06B27255953F79715BDD702@il0015exch007u.ih.lucent.com> In-Reply-To: <54E40201497DF142B06B27255953F79715BDD702@il0015exch007u.ih.lucent.com> MIME-Version: 1.0 Message-Id: <28856.1118912918.876764@peirce> From: Dave Cridland To: "Vaudreuil, Greg M (Greg)" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Thanks for the explanation. On Wed Jun 15 23:48:57 2005, Vaudreuil, Greg M (Greg) wrote: > If protocol purity is the order of the day, then by all means, > define MMS-headers to replace X-MMS-headers. This can be enforced > in the gateways. It won't do too much for the other paths of > leakage between the domains. In the same appendix discussing > X-priority, please mention that X-MMS headers can also be expected > to show up in the wild, and if seen, they probably mean the same as > MMS-headers. I think it's the "probably" that's raising objections. This isn't a purity issue, at least not for me. This is a question of whether renaming the headers (or mapping them to different names, depending on your viewpoint) is better than not doing so. Dave. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 16 08:55:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ditu1-0006BQ-CT; Thu, 16 Jun 2005 08:55:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dittz-0006Ao-BO for lemonade@megatron.ietf.org; Thu, 16 Jun 2005 08:55:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16531 for ; Thu, 16 Jun 2005 08:55:18 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiuGt-0005c3-3g for lemonade@ietf.org; Thu, 16 Jun 2005 09:19:03 -0400 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j5GCtBMc017841; Thu, 16 Jun 2005 07:55:11 -0500 (CDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 16 Jun 2005 07:55:11 -0500 Message-ID: <54E40201497DF142B06B27255953F79715BDD8E1@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Dave Cridland Subject: RE: [lemonade] Fwd: Appeal of decision to standardize "Mapping Be tween the Multimedia Messaging Service (MMS) and Internet Mail" Date: Thu, 16 Jun 2005 07:55:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org I agree we should be looking for least damage. Given: - X-MMS headers will leak, and will usually, likely, probably have the intended semantics. As to probably, I can't really imagine folks inserting X-MMS headers with different semantics. The odds of accuracy are high enough that if you see one, it is best to interpret it per the OMA specifications. Resending or forwarding an MMS message with these headers does not make them semantically inconsistent any more than resending a message with an X-mailer or standard message-id makes them inconsistent. - We should not standardize X-headers. If we standardize, we should use non-X headers. So, if we standardize, we will likely have both forms of headers in the wild. As Randy, I believe, stated, we may likely get into situations where gateways leave the X-MMs header for the benefit of legacy MMS clients that may receive the message and then add the non-X header equivalent per this standard. Now we have the same situation as with X-priority and importance... send both, interpret both with a hiearchy of trust in case they are inconsistent. It seems to do least damage to have just a single header. Curse OMA for taking a short-cut. Lament the sucess of MMS, but deal with the reality in a practical engineering sense. Don't standardize the X-MMs headers, but formally recognise that they exist... such as in an informational appendix, and offer guidance to ensure consistant and predictable reaction to them. Maybe we start a document on the use of X-headers, and require registration for any header with expected persistant use. We have enough cases where X-headers become useful and get widely implemented, but live in on in the undocumented lore required to make an interoperable client. Greg V. -----Original Message----- From: Dave Cridland [mailto:dave@cridland.net] Sent: Thursday, June 16, 2005 5:09 AM To: Vaudreuil, Greg M (Greg) Cc: lemonade@ietf.org Subject: RE: [lemonade] Fwd: Appeal of decision to standardize "Mapping Be tween the Multimedia Messaging Service (MMS) and Internet Mail" Thanks for the explanation. On Wed Jun 15 23:48:57 2005, Vaudreuil, Greg M (Greg) wrote: > If protocol purity is the order of the day, then by all means, > define MMS-headers to replace X-MMS-headers. This can be enforced > in the gateways. It won't do too much for the other paths of > leakage between the domains. In the same appendix discussing > X-priority, please mention that X-MMS headers can also be expected > to show up in the wild, and if seen, they probably mean the same as > MMS-headers. I think it's the "probably" that's raising objections. This isn't a purity issue, at least not for me. This is a question of whether renaming the headers (or mapping them to different names, depending on your viewpoint) is better than not doing so. Dave. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 16 14:36:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DizE3-0006oC-AS; Thu, 16 Jun 2005 14:36:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DizE0-0006o7-Uj for lemonade@megatron.ietf.org; Thu, 16 Jun 2005 14:36:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23447 for ; Thu, 16 Jun 2005 14:36:20 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dizaw-0003mi-4n for lemonade@ietf.org; Thu, 16 Jun 2005 15:00:08 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5GIZxCK010487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Jun 2005 11:36:00 -0700 (PDT) Received: from [192.168.1.4] (vpn-10-50-16-6.qualcomm.com [10.50.16.6]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5GIZut1002325; Thu, 16 Jun 2005 11:35:57 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <28856.1118868973.056825@peirce> References: <28856.1118868973.056825@peirce> Date: Thu, 16 Jun 2005 11:35:54 -0700 To: Dave Cridland From: Ted Hardie Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: lemonade@ietf.org, Mark Crispin , Randall Gellens X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 9:56 PM +0100 6/15/05, Dave Cridland wrote: >On Wed Jun 15 20:31:06 2005, Ted Hardie wrote: >>At 5:54 PM -0700 6/14/05, Mark Crispin wrote: >>>A null transformation of a datum by the gateway is permissible >>>only when that datum is identical with identical semantics in >>>both. In Internet mail, X-* headers have the semantics of >>>"user-defined field". They therefore can not be used to represent >>>MMS headers which have different sematics. >>> >>But is this a null transformation? The view of X- headers in the >>two systems is >>such that I think it's reasonably to read it as a transformation from >>"semantically valid" to "semantically null". As long as the X-MMS header >>is on the Internet side of the gateway, it is semantically null because there >>is no user definition of the field. True, it got made "semantically null" by >>being copied verbatim into a system which treats strings starting X- in a s >>pecial way, but it still got transformed as a result, didn't it? >> >You appear to be agreeing that the semantics were changed, which is, >I think, Mark's point. I am agreeing that the semantics on the two sides of the gateway are different. What I'm asking a question about is whether Mark (or others) feel that a transformation to something that is semantically null is different from others. I guess I'm first asking if folks believe that the transformation is to something that is semantically null, and then, if they do, whether that sort of transformation should be a special case? Speaking without any hats on, Ted _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Jun 16 18:38:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj30b-0001lP-Mo; Thu, 16 Jun 2005 18:38:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj30a-0001lK-CI for lemonade@megatron.ietf.org; Thu, 16 Jun 2005 18:38:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22440 for ; Thu, 16 Jun 2005 18:38:42 -0400 (EDT) Received: from dsl-217-155-137-62.zen.co.uk ([217.155.137.62] helo=gw2.gestalt.entity.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj3NZ-0004O5-31 for lemonade@ietf.org; Thu, 16 Jun 2005 19:02:33 -0400 Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id D200C154009; Thu, 16 Jun 2005 22:38:33 +0000 (UTC) Date: Thu, 16 Jun 2005 23:25:58 +0100 Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" References: <28856.1118868973.056825@peirce> In-Reply-To: MIME-Version: 1.0 Message-Id: <3042.1118960758.077051@peirce> From: Dave Cridland To: Ted Hardie Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: lemonade@ietf.org, Mark Crispin , Randall Gellens X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Thu Jun 16 19:35:54 2005, Ted Hardie wrote: > I am agreeing that the semantics on the two sides of the gateway > are different. > What I'm asking a question about is whether Mark (or others) feel > that > a transformation to something that is semantically null is > different from > others. I guess I'm first asking if folks believe that the > transformation > is to something that is semantically null, and then, if they do, > whether > that sort of transformation should be a special case? From where I'm sitting, a transformation to semantically null ought to be identical - semantically, that is - with discarding the information. I'm not too concerned about that, although discarding information without discarding octets does seem wasteful. However, if you're accepting that such a transformation is occuring, then you must admit the reverse sounds quite worrying. It means you're mandating that gateways should take a bunch of octets that are semantically null, and imbue them with semantics. Now, I appreciate that anyone can invent X-* headers, and these are well known to work fine in practise, but in most cases, the semantics are reapplied by a human (X-Mailer), a tightly coupled system (MTA/SIEVE reading SpamAssassin headers), or else the octets are chosen so as to minimize the chances of inadvertantly applying semantics to the wrong octets (Brightmail poetry). Dave. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 17 12:53:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjK5v-0002he-JN; Fri, 17 Jun 2005 12:53:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjK5r-0002d9-Qa for lemonade@megatron.ietf.org; Fri, 17 Jun 2005 12:53:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03946 for ; Fri, 17 Jun 2005 12:53:20 -0400 (EDT) Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjKSz-0002No-FL for lemonade@ietf.org; Fri, 17 Jun 2005 13:17:18 -0400 Received: from [216.9.46.202] (vpn-10-50-0-181.qualcomm.com [10.50.0.181]) by warlock.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5HGr99f029573; Fri, 17 Jun 2005 09:53:10 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <2005613125223.428378@bbprime> References: <2005613125223.428378@bbprime> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 17 Jun 2005 09:52:48 -0700 To: Dave Crocker , Ted Hardie From: Randall Gellens Subject: Re: Let's fix a process issue quickly (was: Re: [lemonade] Fwd: Appeal of decision...) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 1.0 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: lemonade@ietf.org, brc@zurich.ibm.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 12:52 PM -0700 6/13/05, Dave Crocker wrote: > the IETF history is to have the > cognizant AD not be a direct contributor to the working group effort. I can see how there might be a risk that other members or the chairs would place improper emphasis or consideration on technical comments made in a capacity as a WG member by the area adviser. But in my experience, I don't think such comments have been that rare, and I'm not sure they've been actually a problem. I think the same issue applies to the chairs as well. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- DEFINITION: Computer -- A device designed to speed and automate errors. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 20 07:52:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkKpE-0005VM-Ok; Mon, 20 Jun 2005 07:52:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhx8i-0004b3-Fw for lemonade@megatron.ietf.org; Mon, 13 Jun 2005 18:10:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12040 for ; Mon, 13 Jun 2005 18:10:37 -0400 (EDT) Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhxV3-0000ed-U1 for lemonade@ietf.org; Mon, 13 Jun 2005 18:33:47 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout5.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5DMAV1w021441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Jun 2005 15:10:32 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5DMAVp3018589 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 13 Jun 2005 15:10:31 -0700 Date: Mon, 13 Jun 2005 15:10:32 -0700 (Pacific Daylight Time) From: Mark Crispin To: Ted Hardie Subject: Re: [lemonade] AD as technical contributor (was Re: Let's fix a process issue quickly) In-Reply-To: Message-ID: References: <2005613134948.454076@bbprime> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-Mailman-Approved-At: Mon, 20 Jun 2005 07:52:22 -0400 Cc: lemonade@ietf.org, Dave Crocker , Dave Crocker , brc@zurich.ibm.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Ted - For me, the problem in this case is that you appear to be wearing your AD hat when you disagreed with my post regarding the X- prefix for MMS headers. I felt very much like you were an AD ruling against me, rather than a mere WG participant. As far as I can tell, other individuals have expressed the same objections to using the X- prefix for MMS headers; and (also AFAICT) you are the only individual who has expressed support for using the X- prefix. But you're the AD, which makes it much harder to argue against. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 20 07:52:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkKpF-0005Vl-0N; Mon, 20 Jun 2005 07:52:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhySC-0004Fv-4d for lemonade@megatron.ietf.org; Mon, 13 Jun 2005 19:34:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20921 for ; Mon, 13 Jun 2005 19:34:49 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhyoY-0004ur-Eb for lemonade@ietf.org; Mon, 13 Jun 2005 19:57:59 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5DNYaCK028704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Jun 2005 16:34:36 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5DNYWuo021473; Mon, 13 Jun 2005 16:34:33 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <2005613134948.454076@bbprime> Date: Mon, 13 Jun 2005 16:34:32 -0700 To: Mark Crispin From: Ted Hardie Subject: Re: [lemonade] AD as technical contributor (was Re: Let's fix a process issue quickly) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Mon, 20 Jun 2005 07:52:22 -0400 Cc: lemonade@ietf.org, Dave Crocker , Dave Crocker , brc@zurich.ibm.com X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 3:10 PM -0700 6/13/05, Mark Crispin wrote: >Ted - > >For me, the problem in this case is that you appear to be wearing >your AD hat when you disagreed with my post regarding the X- prefix >for MMS headers. I felt very much like you were an AD ruling >against me, rather than a mere WG participant. > >As far as I can tell, other individuals have expressed the same >objections to using the X- prefix for MMS headers; and (also AFAICT) >you are the only individual who has expressed support for using the >X- prefix. > >But you're the AD, which makes it much harder to argue against. > >-- Mark -- I don't think you're doing too poorly :). But smileys aside, the "speaking as a technical contributor" and "my personal opinion" are common ways people say "not wearing AD hat". If you would like me to add Rob Austein's , I can certainly do so. Ted _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 20 07:52:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkKpF-0005WA-6z; Mon, 20 Jun 2005 07:52:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DifkN-0007f1-JG for lemonade@megatron.ietf.org; Wed, 15 Jun 2005 17:48:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09041 for ; Wed, 15 Jun 2005 17:48:29 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dig79-0000P9-Bl for lemonade@ietf.org; Wed, 15 Jun 2005 18:12:03 -0400 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j5FLmIGW004040; Wed, 15 Jun 2005 16:48:18 -0500 (CDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 15 Jun 2005 16:48:17 -0500 Message-ID: <54E40201497DF142B06B27255953F79715BDD689@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Dave Cridland , Ted Hardie Subject: RE: [lemonade] Fwd: Appeal of decision to standardize "Mapping Be tween the Multimedia Messaging Service (MMS) and Internet Mail" Date: Wed, 15 Jun 2005 16:48:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-Mailman-Approved-At: Mon, 20 Jun 2005 07:52:22 -0400 Cc: lemonade@ietf.org, Mark Crispin , Randall Gellens X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org I suspect there is some confusion here. OMA has defined RFC822 headers for use within the MMS domain. OMA designed MMS as an extenion of Internet email, and extended it in some weird ways for tactical business reasons. (like wanting read receipts two years before the MDN work finished) In general, MMS and Internet email are plug-compatible... as in, I can plug my PC in a socket in the UK or the US, and it pretty much works. Not all features work, and it may not be safe in all circumstances. The protocols are sooo similar, that using the same user agent for mobile internet email and MMS will be common. (it is a detail that one message was retrieved via WAP/HTTP and the other via POP) I will mix MMS messages and Internet messages in the same client-side inbox. They are both RFC822 message, with MIME body structure. It is very likely that MMS extenson header fields show up in the wild today, largely because you can resend an MMS message to an Internet submission server... and it just works. For these reasons, I preferred to keep X-MMS as defined by the OMA for MMS messages gatewayed to the Internet. In that case, there are that many fewer headers I need to understand as a recipient UA. I will have to parse the X-MMS version since I get them from the MMS message store, and I will likely get "escapee" MMS messages with X-MMs headers from my Internet message store. Adding a parser to also look for MMS- headers is not a big deal, it just seems unnecessary. I am just trying to avoid the current situation where a client needs to look for X-priority, X-MS-priority, and Importance to maximize the odds that the recipients sees what the sender intended. If protocol purity is the order of the day, then by all means, define MMS-headers to replace X-MMS-headers. This can be enforced in the gateways. It won't do too much for the other paths of leakage between the domains. In the same appendix discussing X-priority, please mention that X-MMS headers can also be expected to show up in the wild, and if seen, they probably mean the same as MMS-headers. Greg V. -----Original Message----- From: Dave Cridland [mailto:dave@cridland.net] Sent: Wednesday, June 15, 2005 4:56 PM To: Ted Hardie Cc: lemonade@ietf.org; Mark Crispin; Randall Gellens Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" On Wed Jun 15 20:31:06 2005, Ted Hardie wrote: > At 5:54 PM -0700 6/14/05, Mark Crispin wrote: >> A null transformation of a datum by the gateway is permissible >> only when that datum is identical with identical semantics in >> both. In Internet mail, X-* headers have the semantics of >> "user-defined field". They therefore can not be used to represent >> MMS headers which have different sematics. >> >> > But is this a null transformation? The view of X- headers in the > two systems is > such that I think it's reasonably to read it as a transformation > from > "semantically valid" to "semantically null". As long as the X-MMS > header > is on the Internet side of the gateway, it is semantically null > because there > is no user definition of the field. True, it got made > "semantically null" by > being copied verbatim into a system which treats strings starting > X- in a s > pecial way, but it still got transformed as a result, didn't it? > > You appear to be agreeing that the semantics were changed, which is, I think, Mark's point. > I'm also somewhat confused about what you think "user defined" > implies > in the current Internet case. I see lots of X- headers that are > clearly > parts of larger systems or are otherwise non-individual user defined > headers (brightmail poetry, for example). None are defined by a standards-track IETF document, in as much as I'm aware. I believe Mark was referring, by "user-defined field", to section 4.7.5 of RFC822, which uses this term. (Admittedly, it's actually "user-defined-field[s]", but I'm willing to forgive Mark his missing hyphen.) I don't think he intended to suggest that all X-* headers were defined by individual users of network mail, even if that's the language used elswhere in that section, but merely that from a standards compliance perspective, they can be. > Why are OMA-defined headers > different here? They're different because they don't exist. To the best of my very limited knowledge of the OMA, they have not defined any Internet message header fields at all. Assuming you're referring to the X-MMS-* fields, however, those are different because they're not defined by the OMA, but by the IETF, and, in particular, this working group. Dave. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 20 07:55:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkKry-0005jQ-9f; Mon, 20 Jun 2005 07:55:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkKrx-0005iu-3N for lemonade@megatron.ietf.org; Mon, 20 Jun 2005 07:55:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18673 for ; Mon, 20 Jun 2005 07:55:12 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkLFe-0007AJ-2S for lemonade@ietf.org; Mon, 20 Jun 2005 08:19:43 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j5KBrwAA011445 for ; Mon, 20 Jun 2005 07:53:58 -0400 (EDT) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Jun 2005 07:49:07 -0400 Message-ID: From: Eric Burger To: lemonade@ietf.org Date: Mon, 20 Jun 2005 07:49:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [lemonade] Jet Lagged Moderator X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org A few messages got stuck in queue as they had too many recipients. I just unjammed them. Given they were 3 out of 64, I hope I didn't accidentally delete a message that should have been sent. Best thing to do is check how many folks are on a reply-all. Remember, if you got the message, they probably are on the list... _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 20 09:31:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkMMo-0000dr-7S; Mon, 20 Jun 2005 09:31:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkMMm-0000dm-Ar for lemonade@megatron.ietf.org; Mon, 20 Jun 2005 09:31:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27303 for ; Mon, 20 Jun 2005 09:31:06 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkMkU-0001L0-BZ for lemonade@ietf.org; Mon, 20 Jun 2005 09:55:39 -0400 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j5KDUomK020115; Mon, 20 Jun 2005 08:30:51 -0500 (CDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 20 Jun 2005 08:30:50 -0500 Message-ID: <54E40201497DF142B06B27255953F79715CA0FEE@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Mark Crispin , Ted Hardie Subject: RE: [lemonade] AD as technical contributor (was Re: Let's fix a p rocess issue quickly) Date: Mon, 20 Jun 2005 08:30:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org I have also expressed a preference for retaining the X-header as being simpler for implementations and less likely to result in inconsistent and redundant data in the reality of unified email/MMS clients. I believe Randy has made a similar argument. My waffling comes only from the tension between pragamatic engineering and protocol purity. My hope is to find a way to agree that OMA has defined X-MMS headers as "user defined fields", and further agree that this document recognises such and does not "standardize" such. Greg V. -----Original Message----- From: Mark Crispin [mailto:MRC@CAC.Washington.EDU] Sent: Monday, June 13, 2005 6:11 PM To: Ted Hardie Cc: lemonade@ietf.org; Dave Crocker; Dave Crocker; brc@zurich.ibm.com Subject: Re: [lemonade] AD as technical contributor (was Re: Let's fix a process issue quickly) Ted - For me, the problem in this case is that you appear to be wearing your AD hat when you disagreed with my post regarding the X- prefix for MMS headers. I felt very much like you were an AD ruling against me, rather than a mere WG participant. As far as I can tell, other individuals have expressed the same objections to using the X- prefix for MMS headers; and (also AFAICT) you are the only individual who has expressed support for using the X- prefix. But you're the AD, which makes it much harder to argue against. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jun 22 15:50:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlBEw-0007pq-7i; Wed, 22 Jun 2005 15:50:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlBEc-0007jp-P2; Wed, 22 Jun 2005 15:50:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23273; Wed, 22 Jun 2005 15:50:03 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlBcm-0000CO-Bm; Wed, 22 Jun 2005 16:15:04 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DlBEX-0004Wo-MI; Wed, 22 Jun 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 22 Jun 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-urlauth-07.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : Internet Message Access Protocol (IMAP) - URLAUTH Extension Author(s) : M. Crispin Filename : draft-ietf-lemonade-urlauth-07.txt Pages : 5 Date : 2005-6-22 This document describes the URLAUTH extension to the Internet Message Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme (IMAPURL) (RFC 2192). This extension provides a means by which an IMAP client can use URLs carrying authorization to access limited message data on the IMAP server. An IMAP server which supports this extension indicates this with a capability name of "URLAUTH". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-urlauth-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-urlauth-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-urlauth-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-22144641.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-urlauth-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-urlauth-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-22144641.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Thu Jun 23 23:55:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlfHa-0008Lu-3m; Thu, 23 Jun 2005 23:55:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlfHY-0008Lp-FZ for lemonade@megatron.ietf.org; Thu, 23 Jun 2005 23:55:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05798 for ; Thu, 23 Jun 2005 23:55:06 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dlffz-0000Gj-1y for lemonade@ietf.org; Fri, 24 Jun 2005 00:20:25 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j5O3rBo0000252; Thu, 23 Jun 2005 23:53:12 -0400 (EDT) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jun 2005 23:48:17 -0400 Message-ID: From: Eric Burger To: Randall Gellens Subject: RE: [lemonade] Fwd: Appeal of decision to standardize "Mapping Date: Thu, 23 Jun 2005 23:48:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org I have just one thing to say, extracted from Randy's usual posts: X-message-flag: Using Outlook? Upgrade to Eudora: :) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 24 00:25:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlfkZ-0006XR-KR; Fri, 24 Jun 2005 00:25:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlfkY-0006XH-FR for lemonade@megatron.ietf.org; Fri, 24 Jun 2005 00:25:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08719 for ; Fri, 24 Jun 2005 00:25:03 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dlg90-0001dv-7h for lemonade@ietf.org; Fri, 24 Jun 2005 00:50:23 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j5O4KQdL001839 for ; Fri, 24 Jun 2005 00:20:26 -0400 (EDT) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Jun 2005 00:15:33 -0400 Message-ID: From: Eric Burger To: lemonade@ietf.org Date: Fri, 24 Jun 2005 00:15:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [lemonade] Are X-MMS Headers Important? X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Why are we keeping X-MMS headers at all? If they are of some use to an Internet MTA or MUA, then I think we need to translate them to Internet standard headers. I *believe* this is NOT the case, which is why Randy proposed them and Ted supported them. However, I'd like to confirm this assertion. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 24 00:30:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlfpK-0007IO-Jr; Fri, 24 Jun 2005 00:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlfpJ-0007I2-6B for lemonade@megatron.ietf.org; Fri, 24 Jun 2005 00:30:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09041 for ; Fri, 24 Jun 2005 00:29:58 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlgDm-0001s4-2f for lemonade@ietf.org; Fri, 24 Jun 2005 00:55:18 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j5O4PmdL002082 for ; Fri, 24 Jun 2005 00:25:48 -0400 (EDT) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Jun 2005 00:20:54 -0400 Message-ID: From: Eric Burger To: lemonade@ietf.org Date: Fri, 24 Jun 2005 00:20:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [lemonade] Why are we keeping X-MMS headers? X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Are we keeping X-MMS headers because they are of use *ONLY* to a MMS MTA or MUA? That is, do we want to tunnel the X-MMS header from MMS land through Internet land back to MMS land? Conversely, do we want to enable an Internet MUA the ability to set a MMS header that gets appropriately translated into MMS land? Do we want an Internet MUA or MTA to take special action based on a X-MMS header? If the former, I would offer that X-MMS is probably, IMHO, not speaking as the Chair, speaking just a participant, OK. This is just a weird set of octets starting with an X-, with no special meaning. However, we then MUST include a note in the security considerations that MMS land absolutely, positively cannot trust the contents of the header. See the headers in any of Randy's messages (X-message-flag). If the latter, then I would offer that we are creating an Internet header, and thus MUST NOT start with X-. Note that for the former case (only MMS gateways care and it is OK to lose the information), we addressed precisely the "private" or "User-Defined", yet standard label, problem in the SIP world by using P- headers. P- headers are documented, but have no meaning in the global Internet world. IANA manages the name space, so there are no collisions. However, the values of the headers are opaque objects as far as the Internet is concerned. The Internet infrastructure can feel free to drop or ignore P- headers. Entities that care about MMS, like a MMS-Internet e-mail gateway or an MMS-aware Internet Mail MUA, know about the well-defined P- headers. Note that if there is specified behavior for anything other than an MMS gateway, by definition you have an Internet header. In this case, the particular header cannot be X- or P- headers. Thoughts? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 24 00:30:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlfpO-0007K1-IN; Fri, 24 Jun 2005 00:30:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlfpM-0007J9-AY; Fri, 24 Jun 2005 00:30:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09049; Fri, 24 Jun 2005 00:30:01 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlgDn-0001s4-Rp; Fri, 24 Jun 2005 00:55:21 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j5O4RSdL002110; Fri, 24 Jun 2005 00:27:28 -0400 (EDT) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Jun 2005 00:22:34 -0400 Message-ID: From: Eric Burger To: lemonade@ietf.org, speechsc@ietf.org Date: Fri, 24 Jun 2005 00:22:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [lemonade] FW: An interesting sub-note for all of you using the xml tool for drafts X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org > Carl Malamud wrote: > > Randall's method works, or you can do what the readme suggests: > > > > > > > > see: > > > > http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html#ipr > > A number of us, including the IETF Chair, have discovered > this experimentally. It's not illogical - if your source file > says you get exactly what you asked > for, i.e. the obsolete boilerplate. The id-nits tool will > warn you - it is well worth running that before submitting > *any* I-D, whether produced by xml2rfc or another method. > > See http://ietf.levkowetz.com/tools/idnits/idnits.pyht > > Brian _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 24 00:44:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlg2x-0001Rd-03; Fri, 24 Jun 2005 00:44:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlg2v-0001RY-B1 for lemonade@megatron.ietf.org; Fri, 24 Jun 2005 00:44:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09919 for ; Fri, 24 Jun 2005 00:44:02 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlgRN-0002SO-4m for lemonade@ietf.org; Fri, 24 Jun 2005 01:09:22 -0400 Received: from bbprime (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11/8.12.11) with SMTP id j5O4iXjq023695 for ; Thu, 23 Jun 2005 21:44:34 -0700 From: Dave Crocker To: X-Mailer: PocoMail 3.4 (2130) - Licensed Version X-URL: bbiw.net Date: Thu, 23 Jun 2005 21:40:21 -0700 Message-ID: <2005623214345.833839@bbprime> In-Reply-To: <2005623214021.279376@bbprime> Subject: RE: [lemonade] Fwd: Appeal of decision to standardize "Mapping Be tween the Multimedia Messaging Service (MMS) and Internet Mail" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Folks, No doubt I'm misunderstanding something pretty basic. Here's with I *think*= is going on: > OMA has defined RFC822 headers for use within the MMS domain. "within the *MMS* domain" is the key point. The Mapping document is a gateway specification between the MMS domain and= the Internet mail domain. >OMA > designed MMS as an extenion of Internet email, and extended it in some > weird ways for tactical business reasons. That's fine. Folks can do anything they want... in *their* own domain. That does not mean that we should make de jure standards of their decisions,= in our own domain, if the choices they made in their domain are not compatible= with our own. Exactly as the document is titled, the job of a gateway is to *map* between heterogeneous services. If the MMS folks had decided to use exclamation marks to separate between= the global host reference and the local mailbox reference, would be adopt that? = No. We would map it to the Internet mail conventions for addressing. If the MMS folks had decided that all message data -- both control and= content -- was to be in Unicode, would we adopt that? No. We would map it to the Internet mail conventions for data representation and encoding. So it is difficult to understand why MMS-specific header conventions that= are not compatible with Internet mail conventions should not also get mapped to= a form that *is* compatible with Internet mail. > In general, MMS and Internet email > are plug-compatible... as in, I can plug my PC in a socket in the UK or > the US, and it pretty much works. Not all features work, and it may not > be safe in all circumstances. In general, English and American are plug-compatible. Just be careful how= you use the word stuffed, since the English will take offense, or say that= something should be tabled, since it means exactly opposite things. In the early days of Internet products, some companies advertised that= their products were "based on" Internet standards. Of course, that really meant= that their products were proprietary. "In general" is dangerous language. > The protocols are sooo similar, that using the same user agent for= mobile > internet email and MMS will be common. That's great, but it is not a basis for letting the MMS folks impose change fundamental Internet mail standards. > For these reasons, I preferred to keep X-MMS as defined by the OMA for= MMS > messages gatewayed to the Internet. Oh. So this really is NOT trying to "map" MMS into Internet Mail? It is= trying to *encapsulate* MMS in Internet mail, for use by a specialized community. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 24 02:48:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlhzD-00069G-Iw; Fri, 24 Jun 2005 02:48:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlhzB-000691-RY for lemonade@megatron.ietf.org; Fri, 24 Jun 2005 02:48:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09277 for ; Fri, 24 Jun 2005 02:48:20 -0400 (EDT) Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DliNe-0008Ff-Kf for lemonade@ietf.org; Fri, 24 Jun 2005 03:13:40 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout2.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5O6mGsj013481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Jun 2005 23:48:16 -0700 Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5O6mDSh024492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Jun 2005 23:48:15 -0700 Date: Thu, 23 Jun 2005 23:48:12 -0700 (PDT) From: Mark Crispin To: Eric Burger Subject: Re: [lemonade] Why are we keeping X-MMS headers? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-2022-JP; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Fri, 24 Jun 2005, Eric Burger wrote: > Are we keeping X-MMS headers because they are of use *ONLY* to a MMS MTA or > MUA? That is, do we want to tunnel the X-MMS header from MMS land through > Internet land back to MMS land? I don't think that you are asking the right question. A better question is: What harm is caused by requiring that all X-MMS headers be removed? If there is no harm, then why haven't we required the removal of these headers? > Conversely, do we want to enable an Internet MUA the ability to set a MMS > header that gets appropriately translated into MMS land? Do we want an > Internet MUA or MTA to take special action based on a X-MMS header? The first question is OK. The second question needs to be rephrased as the following two questions: Do we want to permit an Internet MUA or MTA to take special action based upon an MMS header? If a hacker decides to generate X-MMS headers for the private use of the My Magic Service mailer, is there the slightest possibility that this will cause a problem for another Internet MUA or MTA? I contend that: if there is any harm caused by removing MMS headers OR if we want to permit an Internet MUA or MTA to take special action based upon an MMS header OR if we want to allow an Internet MUA or MTA to set an MMS header that can be passed to MMS land OR if our hacker using X- headers for the My Magic Service will create the slightest possibility of grief for an Internet MUA or MTA then we MUST define non-experimental named (e.g. MMS) headers to represent these headers, and we MUST NOT use X-MMS headers. Corrolary: If there is no harm caused by removing MMS headers, then they MUST be removed because retaining them causes harm. This is because: . if a header is defined, some hacker will decide to take special action based upon it. . some entity will presently to want to create an Internet->MMS gateway and define headers that go to MMS land. . there will presently be a hacker who uses X-MMS for the My Magic Service mailer. [If challenged on this point, I hereby volunteer to be that hacker.] If it is absolutely vital for debugging purposes that the MMS headers be passed, but NOT interpreted by Internet software, then use the existing comment mechanism of RFC 2822: Comment: The following lines are from MMS for debugging purposes. This data MUST NOT be used to take any special action. X-MMS-blurdybloop: 234 X-MMS-sarasoop: owatagusiam X-MMS-Rena: a puppy rabbit, a twirly girl, a Missy Muddy-Paws X-MMS-MRC: this guy is freaking nuts E$B+)(Bnd of MMS debugging da. Conclusion: I see no place for X-MMS headers in the Internet world. Either the headers are of value (their removal causes harm) and need real names of their own, or they are truly useless and their preservation causes harm. I also don't understand why we are even discussing this point. Whether or not you think that X-MMS is a problem, the fact that some people consider it to be a problem should suffice to deploy one of the presented alternatives which will silence our objections and allow us to move on to problems where there is no clear alternative. Stubbornness in defense of something that is necessary may be a virtue. Stubbornness in defense of something that is unnecessary is not. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 24 09:16:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlo2Z-0003lB-3e; Fri, 24 Jun 2005 09:16:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlo2X-0003l3-1z for lemonade@megatron.ietf.org; Fri, 24 Jun 2005 09:16:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07405 for ; Fri, 24 Jun 2005 09:16:11 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DloR3-0000ch-8V for lemonade@ietf.org; Fri, 24 Jun 2005 09:41:34 -0400 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j5ODFtwf015714; Fri, 24 Jun 2005 08:15:56 -0500 (CDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 24 Jun 2005 08:15:55 -0500 Message-ID: <54E40201497DF142B06B27255953F79715EDB3A9@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Dave Crocker , lemonade@ietf.org Subject: RE: [lemonade] Fwd: Appeal of decision to standardize "Mapping Be tween the Multimedia Messaging Service (MMS) and Internet Mail" Date: Fri, 24 Jun 2005 08:15:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Dave, I think you understand, but are falling to the wrong conclusion based on your desire to avoid suggesting a possible precident rather than the facts in this matter. OMA did not redefine existing headers in non-standard ways. Your address example below does not apply to the problem at hand, but if you believe it did, I can see why it would drive you to different conclusion. OMA adopted X-mms headers as private extensions. Extensions that are not understood are ignored by "pure" non-internet components. I can drop a standard MMS message into MS outlook, or eudora, and it renders fine, even if some enhanced capabilities are not exposed. The world of MMS and email are hybridizing. There are, and will be more client and MTA's that live in both worlds, but are not formal gateways. (informal in that they can forward, resend, or reply to one form with another form). You clearly see MMS as an Island, I see them as adjacent bodies of water. The goals as *I* see are the following: 1) Map MMS message semantics to email semantics to the extent there is a mapping. This allows MMS messages to be delivered to Internet endpoints with maximum fidelity. 2) Tunnel information that can't be mapped in a way that it can be predictably reveresed by a gateway when the message passes back into a separate MMS island. We have lots of precedent for this, most of which is real but non-standard. (X-MS-priority ect) 3) Minimize confusion for hybrid clients that operate on both Internet and MMS headers by minimizing redundancy and avoiding silly states. This goal is in tension with #1 above. I understand the general danger and warning to avoid the three-gateway problem, where MMS may have the concept of ambient odor, and blatmail may have the concept of ambient odor, but there is no standard representation. MMS-ambient-odor won't then map to blatmail room-smell. We can't solve that general problem here, and I don't consider it a goal. Greg V. -----Original Message----- From: Dave Crocker [mailto:dhc@dcrocker.net] Sent: Friday, June 24, 2005 12:40 AM To: lemonade@ietf.org Subject: RE: [lemonade] Fwd: Appeal of decision to standardize "Mapping Be tween the Multimedia Messaging Service (MMS) and Internet Mail" Folks, No doubt I'm misunderstanding something pretty basic. Here's with I *think* is going on: > OMA has defined RFC822 headers for use within the MMS domain. "within the *MMS* domain" is the key point. The Mapping document is a gateway specification between the MMS domain and the Internet mail domain. >OMA > designed MMS as an extenion of Internet email, and extended it in some > weird ways for tactical business reasons. That's fine. Folks can do anything they want... in *their* own domain. That does not mean that we should make de jure standards of their decisions, in our own domain, if the choices they made in their domain are not compatible with our own. Exactly as the document is titled, the job of a gateway is to *map* between heterogeneous services. If the MMS folks had decided to use exclamation marks to separate between the global host reference and the local mailbox reference, would be adopt that? No. We would map it to the Internet mail conventions for addressing. If the MMS folks had decided that all message data -- both control and content -- was to be in Unicode, would we adopt that? No. We would map it to the Internet mail conventions for data representation and encoding. So it is difficult to understand why MMS-specific header conventions that are not compatible with Internet mail conventions should not also get mapped to a form that *is* compatible with Internet mail. > In general, MMS and Internet email > are plug-compatible... as in, I can plug my PC in a socket in the UK or > the US, and it pretty much works. Not all features work, and it may not > be safe in all circumstances. In general, English and American are plug-compatible. Just be careful how you use the word stuffed, since the English will take offense, or say that something should be tabled, since it means exactly opposite things. In the early days of Internet products, some companies advertised that their products were "based on" Internet standards. Of course, that really meant that their products were proprietary. "In general" is dangerous language. > The protocols are sooo similar, that using the same user agent for mobile > internet email and MMS will be common. That's great, but it is not a basis for letting the MMS folks impose change fundamental Internet mail standards. > For these reasons, I preferred to keep X-MMS as defined by the OMA for MMS > messages gatewayed to the Internet. Oh. So this really is NOT trying to "map" MMS into Internet Mail? It is trying to *encapsulate* MMS in Internet mail, for use by a specialized community. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 24 09:29:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DloEz-0005qj-E3; Fri, 24 Jun 2005 09:29:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DloEx-0005qS-EU for lemonade@megatron.ietf.org; Fri, 24 Jun 2005 09:29:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08167 for ; Fri, 24 Jun 2005 09:29:02 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlodU-000133-UP for lemonade@ietf.org; Fri, 24 Jun 2005 09:54:25 -0400 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j5ODSpcl025986; Fri, 24 Jun 2005 08:28:52 -0500 (CDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 24 Jun 2005 08:28:51 -0500 Message-ID: <54E40201497DF142B06B27255953F79715EDB3E3@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Mark Crispin Subject: RE: [lemonade] Why are we keeping X-MMS headers? Date: Fri, 24 Jun 2005 08:28:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-2022-JP" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Mark, You are arguing an extreme point. You are effectively arguing that X- headers in general are bad, cause damage, and should be removed. That may be perfectly true, but is a separate debate. X-MMS headers are no more dangerous to the infrastructure than X-mailer and X-MS-priority. Heck, by the time your message hit my UA, four X-headers were added. When Randy sends messages, I seem to get a half-dozen or so X-headers. It is hard to argue in the face of widespread use that these things are inherently useless or inherently dangerous. For those X-headers who's insertion would cause harm, we need to write security considerations. Fundamentally, I don't know why it is more harmful for a evil guy to add malicious X-headers than malicious regular headers. If MMS has specific formatting, and getting it wrong would cause a problem, then the gateway should check before accepting... If a header indicates "A rely to this is free", it would be reasonable advise not to honor it unless you have other means to know it is trustworth. This may even be a good case to suggest just dropping the reverse-charging header it since you can't trust anything sent over Internet email. Good text for an implementation note or security consideration. Greg V. -----Original Message----- From: Mark Crispin [mailto:mrc@CAC.Washington.EDU] Sent: Friday, June 24, 2005 2:48 AM To: Eric Burger Cc: lemonade@ietf.org Subject: Re: [lemonade] Why are we keeping X-MMS headers? On Fri, 24 Jun 2005, Eric Burger wrote: > Are we keeping X-MMS headers because they are of use *ONLY* to a MMS MTA or > MUA? That is, do we want to tunnel the X-MMS header from MMS land through > Internet land back to MMS land? I don't think that you are asking the right question. A better question is: What harm is caused by requiring that all X-MMS headers be removed? If there is no harm, then why haven't we required the removal of these headers? > Conversely, do we want to enable an Internet MUA the ability to set a MMS > header that gets appropriately translated into MMS land? Do we want an > Internet MUA or MTA to take special action based on a X-MMS header? The first question is OK. The second question needs to be rephrased as the following two questions: Do we want to permit an Internet MUA or MTA to take special action based upon an MMS header? If a hacker decides to generate X-MMS headers for the private use of the My Magic Service mailer, is there the slightest possibility that this will cause a problem for another Internet MUA or MTA? I contend that: if there is any harm caused by removing MMS headers OR if we want to permit an Internet MUA or MTA to take special action based upon an MMS header OR if we want to allow an Internet MUA or MTA to set an MMS header that can be passed to MMS land OR if our hacker using X- headers for the My Magic Service will create the slightest possibility of grief for an Internet MUA or MTA then we MUST define non-experimental named (e.g. MMS) headers to represent these headers, and we MUST NOT use X-MMS headers. Corrolary: If there is no harm caused by removing MMS headers, then they MUST be removed because retaining them causes harm. This is because: . if a header is defined, some hacker will decide to take special action based upon it. . some entity will presently to want to create an Internet->MMS gateway and define headers that go to MMS land. . there will presently be a hacker who uses X-MMS for the My Magic Service mailer. [If challenged on this point, I hereby volunteer to be that hacker.] If it is absolutely vital for debugging purposes that the MMS headers be passed, but NOT interpreted by Internet software, then use the existing comment mechanism of RFC 2822: Comment: The following lines are from MMS for debugging purposes. This data MUST NOT be used to take any special action. X-MMS-blurdybloop: 234 X-MMS-sarasoop: owatagusiam X-MMS-Rena: a puppy rabbit, a twirly girl, a Missy Muddy-Paws X-MMS-MRC: this guy is freaking nuts E$B!&(Jnd of MMS debugging da. Conclusion: I see no place for X-MMS headers in the Internet world. Either the headers are of value (their removal causes harm) and need real names of their own, or they are truly useless and their preservation causes harm. I also don't understand why we are even discussing this point. Whether or not you think that X-MMS is a problem, the fact that some people consider it to be a problem should suffice to deploy one of the presented alternatives which will silence our objections and allow us to move on to problems where there is no clear alternative. Stubbornness in defense of something that is necessary may be a virtue. Stubbornness in defense of something that is unnecessary is not. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 24 12:15:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlqqC-00006g-81; Fri, 24 Jun 2005 12:15:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlqqA-00006U-Fc for lemonade@megatron.ietf.org; Fri, 24 Jun 2005 12:15:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21382 for ; Fri, 24 Jun 2005 12:15:35 -0400 (EDT) Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlrEi-00087g-2P for lemonade@ietf.org; Fri, 24 Jun 2005 12:41:01 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout7.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5OGFYvm026207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Jun 2005 09:15:34 -0700 Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5OGFHUf013646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Jun 2005 09:15:33 -0700 Date: Fri, 24 Jun 2005 09:15:16 -0700 (PDT) From: Mark Crispin To: "Vaudreuil, Greg M (Greg)" Subject: RE: [lemonade] Why are we keeping X-MMS headers? In-Reply-To: <54E40201497DF142B06B27255953F79715EDB3E3@il0015exch007u.ih.lucent.com> Message-ID: References: <54E40201497DF142B06B27255953F79715EDB3E3@il0015exch007u.ih.lucent.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Fri, 24 Jun 2005, Vaudreuil, Greg M (Greg) wrote: > X-MMS headers are no > more dangerous to the infrastructure than X-mailer and X-MS-priority. You have just made my point. We are under considerable pressure to support (not just generate, but process and make decisions based upon) X-Mailer and the various forms of X-Priority. Because these are "standard", that's why; and we are being [pick your favorite slur] for not following this "standard". The Lemonade WG, for the first time, proposes to define some X- headers as real IETF standards. Rather than shore up the dyke, you want to bulldoze huge holes in it. This is not progress. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 24 12:58:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlrVp-0008Es-AT; Fri, 24 Jun 2005 12:58:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlrVn-0008Eb-O9 for lemonade@megatron.ietf.org; Fri, 24 Jun 2005 12:58:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24857 for ; Fri, 24 Jun 2005 12:58:37 -0400 (EDT) Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlruM-0001TE-Qa for lemonade@ietf.org; Fri, 24 Jun 2005 13:24:03 -0400 Received: from [192.168.1.13] (vpn-10-50-0-106.qualcomm.com [10.50.0.106]) by warlock.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5OGwHVm009545; Fri, 24 Jun 2005 09:58:22 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 24 Jun 2005 09:55:57 -0700 To: Eric Burger , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] Why are we keeping X-MMS headers? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 12:20 AM -0400 6/24/05, Eric Burger wrote: > Are we keeping X-MMS headers because they are of use *ONLY* to a MMS MTA or > MUA? That is, do we want to tunnel the X-MMS header from MMS land through > Internet land back to MMS land? That was the original intent, yes, but it only applied to two of the many x-mms-* headers, and I've already agreed that we can drop this special treatement of these two. > > Conversely, do we want to enable an Internet MUA the ability to set a MMS > header that gets appropriately translated into MMS land? Do we want an > Internet MUA or MTA to take special action based on a X-MMS header? No, this was never the intent, and I am not aware of any wording in any version of the document that ever could have been interpreted in that way. > > If the former, I would offer that X-MMS is probably, IMHO, not speaking as > the Chair, speaking just a participant, OK. This is just a weird set of > octets starting with an X-, with no special meaning. However, we then MUST > include a note in the security considerations that MMS land absolutely, > positively cannot trust the contents of the header. See the headers in any > of Randy's messages (X-message-flag). > > If the latter, then I would offer that we are creating an Internet header, > and thus MUST NOT start with X-. > > Note that for the former case (only MMS gateways care and it is OK to lose > the information), we addressed precisely the "private" or "User-Defined", > yet standard label, problem in the SIP world by using P- headers. P- > headers are documented, but have no meaning in the global Internet world. > IANA manages the name space, so there are no collisions. However, the > values of the headers are opaque objects as far as the Internet is > concerned. The Internet infrastructure can feel free to drop or ignore P- > headers. > > Entities that care about MMS, like a MMS-Internet e-mail gateway or an > MMS-aware Internet Mail MUA, know about the well-defined P- headers. Note > that if there is specified behavior for anything other than an MMS gateway, > by definition you have an Internet header. In this case, the particular > header cannot be X- or P- headers. > > Thoughts? > > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- There are things that are so serious that you can only joke about them --Heisenberg _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 24 12:58:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlrVp-0008FH-HN; Fri, 24 Jun 2005 12:58:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlrVn-0008Eg-UF for lemonade@megatron.ietf.org; Fri, 24 Jun 2005 12:58:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24855 for ; Fri, 24 Jun 2005 12:58:36 -0400 (EDT) Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlruM-0001T3-Od for lemonade@ietf.org; Fri, 24 Jun 2005 13:24:03 -0400 Received: from [192.168.1.13] (vpn-10-50-0-106.qualcomm.com [10.50.0.106]) by warlock.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5OGwHVk009545; Fri, 24 Jun 2005 09:58:18 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 24 Jun 2005 09:54:04 -0700 To: Eric Burger , lemonade@ietf.org From: Randall Gellens Subject: Re: [lemonade] Are X-MMS Headers Important? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 12:15 AM -0400 6/24/05, Eric Burger wrote: > Why are we keeping X-MMS headers at all? If they are of some use to an > Internet MTA or MUA, then I think we need to translate them to Internet > standard headers. Version -04 says to drop all x-mms-* headers, except for two, which it says MAY or SHOULD be retained. I've previously agreed to changing the wording so that these two headers are treated like the rest of them. So, I am not sure what purpose is served by continuing to beat this greasy spot that may have once been a horse. The mapping document maps between x-mms-headers and Internet mail facilities to the extent possible and safe. However, in answer to your question (as I've tried to say many times but I must be getting very bad at communicating), there was never, and I want to repeat this, *never*, any attempt to create semantics for x-mms-* headers in the Internet world. It's true that -04 does have text that permits or advises gateways to not delete two specific headers, in the interest of letting this opaque string stay in a message in case it hits another MMS system. This text also makes it painfully clear that MMS systems can't trust this information, that it can be stripped or altered in transit within the Internet. Since there are those are feel that allowing an x-mms-* header to remain in a message is tantamount to specifying semantics for it and hence standardizing it within Internet mail, I agreed many messages ago to change these two headers to match the rest of them. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- One's need for loneliness is not satisfied if one sits at a table alone. There must be empty chairs as well. --Karl Kraus _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 24 13:11:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlriE-0001ti-Fv; Fri, 24 Jun 2005 13:11:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlriC-0001td-U2 for lemonade@megatron.ietf.org; Fri, 24 Jun 2005 13:11:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25735 for ; Fri, 24 Jun 2005 13:11:26 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dls6k-0001wa-Ft for lemonade@ietf.org; Fri, 24 Jun 2005 13:36:52 -0400 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j5OHBAoF001522; Fri, 24 Jun 2005 12:11:11 -0500 (CDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 24 Jun 2005 12:11:10 -0500 Message-ID: <54E40201497DF142B06B27255953F79715EDB7F5@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Mark Crispin , "Vaudreuil, Greg M (Greg)" Subject: RE: [lemonade] Why are we keeping X-MMS headers? Date: Fri, 24 Jun 2005 12:11:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org The fact that functionality does not wait for standards is hugely inconvenient. The alternative is largely unacceptable. Staying with the formal processes was the approach taken by VPIM. "look ma, no X-headers!" It was an eight to ten year effort due to the number of individual enhancements and dependencies.... that for following that path, we really missed the market window. Most folks are less purist, and launch products when the market demandeds. If their innovations meet a need, they get adopted. OMA took that typical path. I don't see market pressure to adopt a sucessful X-header as damage... inconvenient, expensive, less than desired, maybe, but not infrastructure damage. Can we focus on containing the true negatives you see, by say, formalizing a registry for X-headers to at least avoid clashes? Greg V. -----Original Message----- From: Mark Crispin [mailto:mrc@CAC.Washington.EDU] Sent: Friday, June 24, 2005 12:15 PM To: Vaudreuil, Greg M (Greg) Cc: lemonade@ietf.org Subject: RE: [lemonade] Why are we keeping X-MMS headers? On Fri, 24 Jun 2005, Vaudreuil, Greg M (Greg) wrote: > X-MMS headers are no > more dangerous to the infrastructure than X-mailer and X-MS-priority. You have just made my point. We are under considerable pressure to support (not just generate, but process and make decisions based upon) X-Mailer and the various forms of X-Priority. Because these are "standard", that's why; and we are being [pick your favorite slur] for not following this "standard". The Lemonade WG, for the first time, proposes to define some X- headers as real IETF standards. Rather than shore up the dyke, you want to bulldoze huge holes in it. This is not progress. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 24 13:13:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlrkK-0002lv-Jq; Fri, 24 Jun 2005 13:13:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlrkI-0002lm-Ug for lemonade@megatron.ietf.org; Fri, 24 Jun 2005 13:13:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25962 for ; Fri, 24 Jun 2005 13:13:36 -0400 (EDT) Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dls8s-00028j-3V for lemonade@ietf.org; Fri, 24 Jun 2005 13:39:02 -0400 Received: from [192.168.1.13] (vpn-10-50-0-106.qualcomm.com [10.50.0.106]) by warlock.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5OHDJVm011424 for ; Fri, 24 Jun 2005 10:13:26 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <54E40201497DF142B06B27255953F79715EDB3E3@il0015exch007u.ih.lucent.com > X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 24 Jun 2005 10:10:55 -0700 To: lemonade@ietf.org From: Randall Gellens Subject: RE: [lemonade] Why are we keeping X-MMS headers? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 9:15 AM -0700 6/24/05, Mark Crispin wrote: > We are under considerable pressure to support (not just generate, > but process and make decisions based upon) X-Mailer and the various > forms of X-Priority. Because these are "standard", that's why; and > we are being [pick your favorite slur] for not following this > "standard". Those headers have widely-implemented semantics within Internet mail. More importantly, those headers have nothing to do with the x-mms- headers in question. Even more importantly, the proponents agreed many messages ago to change the treatment of the two x-mms- headers to match the rest of them. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- (1) Alexander the Great was a great general. (2) Great generals are forewarned. (3) Forewarned is forearmed. (4) Four is an even number. (5) Four is certainly an odd number of arms for a man to have. (6) The only number that is both even and odd is infinity. Therefore, Alexander the Great had an infinite number of arms. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 24 13:13:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlrkK-0002mK-QY; Fri, 24 Jun 2005 13:13:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlrkI-0002ll-UV for lemonade@megatron.ietf.org; Fri, 24 Jun 2005 13:13:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25964 for ; Fri, 24 Jun 2005 13:13:36 -0400 (EDT) Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dls8s-00028f-3Z for lemonade@ietf.org; Fri, 24 Jun 2005 13:39:02 -0400 Received: from [192.168.1.13] (vpn-10-50-0-106.qualcomm.com [10.50.0.106]) by warlock.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5OHDJVk011424; Fri, 24 Jun 2005 10:13:21 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <2005623214345.833839@bbprime> References: <2005623214345.833839@bbprime> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 24 Jun 2005 10:06:14 -0700 To: Dave Crocker , From: Randall Gellens Subject: RE: [lemonade] Fwd: Appeal of decision to standardize "Mapping Be tween the Multimedia Messaging Service (MMS) and Internet Mail" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 1.0 (+) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 9:40 PM -0700 6/23/05, Dave Crocker wrote: > That does not mean that we should make de jure standards of their > decisions, in > our own domain, if the choices they made in their domain are not > compatible with > our own. I don't believe the document attempted or proposed the standardization of anything that was incompatible with Internet mail. Yes, in version -04 there are two x-mms-* headers that the text says MAY or SHOULD be retained. Yes, we've debated if that somehow constituted standardizing semantics for x-mms- headers in Internet mail, but many messages ago the proponents of retaining these two exceptions relented. > If the MMS folks had decided to use exclamation marks to separate between the > global host reference and the local mailbox reference, would be > adopt that? No. > We would map it to the Internet mail conventions for addressing. This is a straw man. The document had nothing that could in any fair way be equated to altering fundamental infrastructure of Internet mail. I apologize, but I find the comparison ludicrous. > If the MMS folks had decided that all message data -- both control > and content > -- was to be in Unicode, would we adopt that? No. We would map it to the > Internet mail conventions for data representation and encoding. This is another straw man. I repeat: the document had nothing that could in any fair way be equated to altering fundamental infrastructure of Internet mail. I find this comparison ludicrous as well. > So it is difficult to understand why MMS-specific header conventions that are > not compatible with Internet mail conventions should not also get mapped to a > form that *is* compatible with Internet mail. The mapping document does this, to the extent possible and safe, for *all* x-mms- headers. In addition, version -04 says to drop all x-mms-* headers, except for two, which it says MAY or SHOULD be retained. I've previously agreed to changing the wording so that these two headers are treated like the rest of them. By all means, let's continue to beat this greasy mark. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- ... But as records of courts and justice are admissible, it can easily be proved that powerful and malevolent magicians once existed and were a scourge to mankind. The evidence (including confession) upon which certain women were convicted of witchcraft and executed was without a flaw; it is still unimpeachable. The judges' decisions based on it were sound in logic and in law. Nothing in any existing court was ever more thoroughly proved than the charges of witchcraft and sorcery for which so many suffered death. If there were no witches, human testimony and human reason are alike destitute of value. --Ambrose Bierce, "The Devil's Dictionary" _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 24 13:29:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlrzo-0005WE-8L; Fri, 24 Jun 2005 13:29:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlrzm-0005W9-KZ for lemonade@megatron.ietf.org; Fri, 24 Jun 2005 13:29:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27091 for ; Fri, 24 Jun 2005 13:29:35 -0400 (EDT) Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlsOL-0002mr-0U for lemonade@ietf.org; Fri, 24 Jun 2005 13:55:02 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout1.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5OHTZCT007208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Jun 2005 10:29:35 -0700 Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j5OHTTKM005046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Jun 2005 10:29:34 -0700 Date: Fri, 24 Jun 2005 10:29:27 -0700 (PDT) From: Mark Crispin To: "Vaudreuil, Greg M (Greg)" Subject: RE: [lemonade] Why are we keeping X-MMS headers? In-Reply-To: <54E40201497DF142B06B27255953F79715EDB7F5@il0015exch007u.ih.lucent.com> Message-ID: References: <54E40201497DF142B06B27255953F79715EDB7F5@il0015exch007u.ih.lucent.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Fri, 24 Jun 2005, Vaudreuil, Greg M (Greg) wrote: > I don't see market pressure to adopt a sucessful X-header as damage... > inconvenient, expensive, less than desired, maybe, but not > infrastructure damage. If that is the case, then why do we bother having an IETF? Why not just let the market decide everything without the extreme expense and bureaucracy of the IETF process? This sounds crazy, but I can assure you that there are people who think that way. > Can we focus on containing the true negatives you > see, by say, formalizing a registry for X-headers to at least avoid > clashes? X- headers are supposed to be jungle space; to be used for experimental and private purposes. I consider any erosion of this jungle to be a true negative. The instant that an IETF standard defines X-MMS within the Internet context, Mark's Magic System has lost swamp that it thought that it owned. Yes, this is the slippery slope argument. But the fact that an argument is trite and rather dog-eared doesn't make it invalid. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 24 14:51:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DltHH-0002UL-9e; Fri, 24 Jun 2005 14:51:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DltHF-0002UE-1r for lemonade@megatron.ietf.org; Fri, 24 Jun 2005 14:51:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02403 for ; Fri, 24 Jun 2005 14:51:43 -0400 (EDT) Received: from dsl-217-155-137-62.zen.co.uk ([217.155.137.62] helo=gw2.gestalt.entity.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dltfo-0005eb-6x for lemonade@ietf.org; Fri, 24 Jun 2005 15:17:09 -0400 Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id A6BA5154009; Fri, 24 Jun 2005 18:51:16 +0000 (UTC) Date: Fri, 24 Jun 2005 19:34:16 +0100 Subject: RE: [lemonade] Fwd: Appeal of decision to standardize "Mapping Be tween the Multimedia Messaging Service (MMS) and Internet Mail" References: <54E40201497DF142B06B27255953F79715EDB3A9@il0015exch007u.ih.lucent.com> In-Reply-To: <54E40201497DF142B06B27255953F79715EDB3A9@il0015exch007u.ih.lucent.com> MIME-Version: 1.0 Message-Id: <15685.1119638056.665131@peirce> From: Dave Cridland To: "Vaudreuil, Greg M (Greg)" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Fri Jun 24 14:15:52 2005, Vaudreuil, Greg M (Greg) wrote: > The world of MMS and email are hybridizing. There are, and will be > more client and MTA's that live in both worlds, but are not formal > gateways. If, by "not formal gateways", I'm to assume that they do not, and will not, follow this specification, then why are we bothering to produce it, as a working group? Why not just sit back and let things happen? Why make a Proposed Standard, when an Informational at best would do? If you mean they're not purpose built gateways, but they still do follow this specification, then what does it matter what the header field names are? > 1) Map MMS message semantics to email semantics to the extent > there is a mapping. This allows MMS messages to be delivered to > Internet endpoints with maximum fidelity. Which is trivial. > 2) Tunnel information that can't be mapped in a way that it can be > predictably reveresed by a gateway when the message passes back > into a separate MMS island. Indeed, and we have lots of precedent for this, such as the MIXER specification, which defined new headers for those semantics which previously didn't exist in the Internet domain. The "predictably reversed" statement suggests that we should not use X-* headers in this instance, as the resultant reversal of the mapping would be less reliable. The mere fact that it begins with "X-*" is, to me at least, a moot point. The effect of that, however, is that it becomes a less reliable method for gatewaying from the Internet to the MMS domain. > 3) Minimize confusion for hybrid clients that operate on both > Internet and MMS headers by minimizing > redundancy and avoiding silly states. This goal is in tension > with #1 above. I fail to understand this. Any UA, if it understands two messaging domains, must act as a formal gateway using whatever formal gateway specification exists, to transform messages between domains as required. Any message store must be in one messaging domain only. Whichever it is in, if it is capable of receiving messages from multiple message domains, it must gateway according the relevant specification. Is the purpose of this document to provide a standard for performing some interoperable action, or is it purely an informational document for explaining what these odd headers you might see are? Dave. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 24 15:50:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DluCO-0005TE-6G; Fri, 24 Jun 2005 15:50:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DluCA-0005J7-DK for lemonade@megatron.ietf.org; Fri, 24 Jun 2005 15:50:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08849 for ; Fri, 24 Jun 2005 15:50:32 -0400 (EDT) Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dluai-0007yA-8i for lemonade@ietf.org; Fri, 24 Jun 2005 16:15:59 -0400 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.74.75]) by warlock.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5OJoDVk027616 for ; Fri, 24 Jun 2005 12:50:14 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <15685.1119638056.665131@peirce> References: <54E40201497DF142B06B27255953F79715EDB3A9@il0015exch007u.ih.lucent.com > <15685.1119638056.665131@peirce> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 24 Jun 2005 12:25:35 -0700 To: lemonade@ietf.org From: Randall Gellens Subject: RE: [lemonade] Fwd: Appeal of decision to standardize "Mapping Be tween the Multimedia Messaging Service (MMS) and Internet Mail" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 1.0 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 7:34 PM +0100 6/24/05, Dave Cridland wrote: > Is the purpose of this document to provide a standard for > performing some interoperable action, or is it purely an > informational document for explaining what these odd headers you > might see are? The purpose is to have an interoperable specification to map information elements between the MMS and Internet mail worlds to allow messages to be exchanged while retaining as much semantic content as possible. The Abstract and Introduction and Scope sections should make this clear. If you believe they fail to do so, please point out what is confusing, incorrect, or omitted. The document already contains such mappings, and in all cases maps x-mms-* headers to equivalent Internet mail information elements: either header fields, SMTP envelope fields, or specifies that the functionality cannot be mapped, such as for reply charging. The argument about x-mms- headers, as I understand it, has been over two specific x-mms- headers that -04 says SHOULD or MAY be retained. The proponents of that view have since acquiesced and agreed that they can be made the same as the others. There was an additional argument over the mention of X-Priority, and it was agreed that any such mention should be moved to an informational appendix. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Vous etes ici _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 24 15:53:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DluEz-000630-4I; Fri, 24 Jun 2005 15:53:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DluEx-00062v-UK for lemonade@megatron.ietf.org; Fri, 24 Jun 2005 15:53:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09431 for ; Fri, 24 Jun 2005 15:53:26 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DludW-0008Ew-Uf for lemonade@ietf.org; Fri, 24 Jun 2005 16:18:53 -0400 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j5OJrDIv005310; Fri, 24 Jun 2005 14:53:13 -0500 (CDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 24 Jun 2005 14:53:13 -0500 Message-ID: <54E40201497DF142B06B27255953F79715F97757@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Dave Cridland Subject: RE: [lemonade] Fwd: Appeal of decision to standardize "Mapping Be tween the Multimedia Messaging Service (MMS) and Internet Mail" Date: Fri, 24 Jun 2005 14:53:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org After a side-bar conversation with Randy Gellens, I am now convinced that tunnelling between MMS systems through the Internet is not a goal of this document. As such, I agree that dropping the un-mappable headers is a reasonable course forward. Greg V. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 24 17:02:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlvJp-0004Pq-T3; Fri, 24 Jun 2005 17:02:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlvJm-0004N8-D7 for lemonade@megatron.ietf.org; Fri, 24 Jun 2005 17:02:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24786 for ; Fri, 24 Jun 2005 17:02:28 -0400 (EDT) Received: from dsl-217-155-137-62.zen.co.uk ([217.155.137.62] helo=gw2.gestalt.entity.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlviL-0005Ho-Ui for lemonade@ietf.org; Fri, 24 Jun 2005 17:27:56 -0400 Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 991B1154009; Fri, 24 Jun 2005 21:02:16 +0000 (UTC) Date: Fri, 24 Jun 2005 22:02:16 +0100 Subject: RE: [lemonade] Fwd: Appeal of decision to standardize "Mapping Be tween the Multimedia Messaging Service (MMS) and Internet Mail" References: <54E40201497DF142B06B27255953F79715F97757@il0015exch007u.ih.lucent.com> In-Reply-To: <54E40201497DF142B06B27255953F79715F97757@il0015exch007u.ih.lucent.com> MIME-Version: 1.0 Message-Id: <15685.1119646936.616686@peirce> From: Dave Cridland To: "Vaudreuil, Greg M (Greg)" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Fri Jun 24 20:53:11 2005, Vaudreuil, Greg M (Greg) wrote: > > After a side-bar conversation with Randy Gellens, I am now > convinced that tunnelling between MMS systems through the Internet > is not a goal of this document. As such, I agree that dropping the > un-mappable headers is a reasonable course forward. If it's not a goal, then yes, indeed, they should be dropped - currently, section 2.1.3.2 states that: An 'X-Mms-Message-Id:' header, if present, SHOULD be retained in order to facilitate the case where an MMS message traverses the Internet prior to returning to an MMS system. Such systems should be aware that X-headers might be removed during transit through Internet MTAs. Perhap's that's why I'm so confused about this. Dave. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 24 17:24:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlvfD-0001Rs-Cr; Fri, 24 Jun 2005 17:24:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlvfB-0001Rh-Ff for lemonade@megatron.ietf.org; Fri, 24 Jun 2005 17:24:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26498 for ; Fri, 24 Jun 2005 17:24:35 -0400 (EDT) Received: from dsl-217-155-137-62.zen.co.uk ([217.155.137.62] helo=gw2.gestalt.entity.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dlw3m-0005vZ-8L for lemonade@ietf.org; Fri, 24 Jun 2005 17:50:03 -0400 Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 2BA0D154009; Fri, 24 Jun 2005 21:24:27 +0000 (UTC) Date: Fri, 24 Jun 2005 22:24:27 +0100 Subject: RE: [lemonade] Fwd: Appeal of decision to standardize "Mapping Be tween the Multimedia Messaging Service (MMS) and Internet Mail" References: <54E40201497DF142B06B27255953F79715EDB3A9@il0015exch007u.ih.lucent.com > <15685.1119638056.665131@peirce> In-Reply-To: MIME-Version: 1.0 Message-Id: <15685.1119648267.127122@peirce> From: Dave Cridland To: Randall Gellens Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Fri Jun 24 20:25:35 2005, Randall Gellens wrote: > At 7:34 PM +0100 6/24/05, Dave Cridland wrote: >> Is the purpose of this document to provide a standard for >> performing some interoperable action, or is it purely an >> informational document for explaining what these odd headers you >> might see are? > > The purpose is to have an interoperable specification to map > information elements between the MMS and Internet mail worlds to > allow messages to be exchanged while retaining as much semantic > content as possible. Why do I bother asking rhetorical questions if people are going to answer them? ;-) > The argument about x-mms- headers, as I understand it, has been > over two specific x-mms- headers that -04 says SHOULD or MAY be > retained. That's not been the point of my argument, nor, as I understood it, Mark's. It's the reverse that causes me concern - retaining X-* headers from an Internet message when transforming it into an MMS message. I can see how easy it is to get confused over this, because the bulk of the proposed solutions for avoiding that transformation relate to the reverse - that is, in order to avoid the problems in the Internet->MMS end, the solutions are mainly centered around the MMS->Internet end. But please don't confuse the two issues - you're more than welcome to put any X-* headers in your message (or indeed part) headers you like, and I'll defend your right to do so, however, semantic interpretation of those headers is something that should not be done if it can be avoided, and in this case I believe it can be avoided, and moreover it is simple to do so. Moreover, there's the purist viewpoint that even mentioning them in a normative section of a standards-track document is a bad idea, but that alone wouldn't cause me to object so strongly to it - I like dogma, but I prefer pragma. Dave. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 24 18:16:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlwTP-000674-T8; Fri, 24 Jun 2005 18:16:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlwTO-00066z-JJ for lemonade@megatron.ietf.org; Fri, 24 Jun 2005 18:16:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00860 for ; Fri, 24 Jun 2005 18:16:28 -0400 (EDT) Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dlwrz-0007Ms-QK for lemonade@ietf.org; Fri, 24 Jun 2005 18:41:57 -0400 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.74.75]) by warlock.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5OMGBVk012687 for ; Fri, 24 Jun 2005 15:16:13 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <15685.1119648267.127122@peirce> References: <54E40201497DF142B06B27255953F79715EDB3A9@il0015exch007u.ih.lucent.co m > <15685.1119638056.665131@peirce> <15685.1119648267.127122@peirce> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 24 Jun 2005 15:10:06 -0700 To: lemonade@ietf.org From: Randall Gellens Subject: RE: [lemonade] Fwd: Appeal of decision to standardize "Mapping Be tween the Multimedia Messaging Service (MMS) and Internet Mail" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 10:24 PM +0100 6/24/05, Dave Cridland wrote: > It's the reverse that causes me concern - retaining X-* headers > from an Internet message when transforming it into an MMS message. There's no mention anywhere in the document that I am aware of which mentions retaining x-headers when going from Internet mail to MMS. (There is mention of mapping X-Priority, which clearly says it is a non-standard header, but it was agreed that this should be moved to an informative appendix.) -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The challenge of computer science is: How NOT to make a mess of it. -Edsger W. Dijkstra _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 24 19:34:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlxh6-00025p-5K; Fri, 24 Jun 2005 19:34:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlxh4-00025j-Nh for lemonade@megatron.ietf.org; Fri, 24 Jun 2005 19:34:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08466 for ; Fri, 24 Jun 2005 19:34:39 -0400 (EDT) Received: from dsl-217-155-137-62.zen.co.uk ([217.155.137.62] helo=gw2.gestalt.entity.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dly5g-0001Zt-EH for lemonade@ietf.org; Fri, 24 Jun 2005 20:00:09 -0400 Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 26696154009; Fri, 24 Jun 2005 23:34:22 +0000 (UTC) Date: Sat, 25 Jun 2005 00:34:17 +0100 Subject: RE: [lemonade] Fwd: Appeal of decision to standardize "Mapping Be tween the Multimedia Messaging Service (MMS) and Internet Mail" References: <54E40201497DF142B06B27255953F79715EDB3A9@il0015exch007u.ih.lucent.co m > <15685.1119638056.665131@peirce> <15685.1119648267.127122@peirce> In-Reply-To: MIME-Version: 1.0 Message-Id: <15685.1119656062.522145@peirce> From: Dave Cridland To: Randall Gellens Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Fri Jun 24 23:10:06 2005, Randall Gellens wrote: > At 10:24 PM +0100 6/24/05, Dave Cridland wrote: > >> It's the reverse that causes me concern - retaining X-* headers >> from an Internet message when transforming it into an MMS message. > > There's no mention anywhere in the document that I am aware of > which mentions retaining x-headers when going from Internet mail to > MMS. I refer the honourable gentleman to the answer I gave some moments ago: [...] currently, section 2.1.3.2 states that: An 'X-Mms-Message-Id:' header, if present, SHOULD be retained in order to facilitate the case where an MMS message traverses the Internet prior to returning to an MMS system. Such systems should be aware that X-headers might be removed during transit through Internet MTAs. Perhaps I'm being really very confused here, but doesn't that paragraph directly imply that those headers should be directly remapped - or retained if you will - when going from Internet mail to MMS? It's stated as the point of keeping them about at all, so perhaps I'm reading too much, but it certainly looks like a mention which mentions retaining those headers. Moreover, if we're not going to apply MMS semantics to those headers, why are you so intent on keeping them? Dave. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 24 19:53:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlxzV-0006Bm-Qd; Fri, 24 Jun 2005 19:53:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlxzU-0006Bh-LD for lemonade@megatron.ietf.org; Fri, 24 Jun 2005 19:53:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09666 for ; Fri, 24 Jun 2005 19:53:43 -0400 (EDT) Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlyO4-0001zp-Og for lemonade@ietf.org; Fri, 24 Jun 2005 20:19:12 -0400 Received: from [192.168.1.13] (vpn-10-50-0-57.qualcomm.com [10.50.0.57]) by warlock.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5ONrOVk022365 for ; Fri, 24 Jun 2005 16:53:25 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <15685.1119656062.522145@peirce> References: <54E40201497DF142B06B27255953F79715EDB3A9@il0015exch007u.ih.lucent.co m > <15685.1119638056.665131@peirce> <15685.1119648267.127122@peirce> <15685.1119656062.522145@peirce> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 24 Jun 2005 16:51:15 -0700 To: From: Randall Gellens Subject: RE: [lemonade] Fwd: Appeal of decision to standardize "Mapping Be tween the Multimedia Messaging Service (MMS) and Internet Mail" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 12:34 AM +0100 6/25/05, Dave Cridland wrote: > On Fri Jun 24 23:10:06 2005, Randall Gellens wrote: >> At 10:24 PM +0100 6/24/05, Dave Cridland wrote: >> >>> It's the reverse that causes me concern - retaining X-* headers >>> from an Internet message when transforming it into an MMS message. >> >> There's no mention anywhere in the document that I am aware of >> which mentions retaining x-headers when going from Internet mail >> to MMS. > > I refer the honourable gentleman to the answer I gave some moments ago: > > [...] currently, section 2.1.3.2 states that: > > An 'X-Mms-Message-Id:' header, if present, SHOULD be retained in > order to facilitate the case where an MMS message traverses the > Internet prior to returning to an MMS system. Such systems should > be aware that X-headers might be removed during transit through > Internet MTAs. > > Perhaps I'm being really very confused here, but doesn't that > paragraph directly imply that those headers should be directly > remapped - or retained if you will - when going from Internet mail > to MMS? It's stated as the point of keeping them about at all, so > perhaps I'm reading too much, but it certainly looks like a mention > which mentions retaining those headers. Now that you point it out, I can see how that text could be interpreted as implying that such headers should be retained when going from Internet mail to MMS. But, that text appears only in the section on going from MMS to Internet mail. In the section on Internet mail to MMS there is no mention of retaining such headers. However, we already agreed to delete the text you quote by agreeing that the x-mms-message-id header should no longer be treated specially, so I think it has become moot. > > Moreover, if we're not going to apply MMS semantics to those > headers, why are you so intent on keeping them? I'm "so intent on keeping them"? I admit to having argued for keeping them, but quite some messages ago I agreed that we can delete them. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- To die for an idea is unquestionably noble. But how much nobler it would be if men died for ideas that were true! --H.L. Mencken _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Jun 24 20:13:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlyIu-0003Wl-Ln; Fri, 24 Jun 2005 20:13:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlyIu-0003Wg-3b for lemonade@megatron.ietf.org; Fri, 24 Jun 2005 20:13:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11907 for ; Fri, 24 Jun 2005 20:13:47 -0400 (EDT) Received: from dsl-217-155-137-62.zen.co.uk ([217.155.137.62] helo=gw2.gestalt.entity.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlyhW-0002kI-9x for lemonade@ietf.org; Fri, 24 Jun 2005 20:39:15 -0400 Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 005BC154009; Sat, 25 Jun 2005 00:13:37 +0000 (UTC) Date: Sat, 25 Jun 2005 01:13:37 +0100 Subject: RE: [lemonade] Fwd: Appeal of decision to standardize "Mapping Be tween the Multimedia Messaging Service (MMS) and Internet Mail" References: <54E40201497DF142B06B27255953F79715EDB3A9@il0015exch007u.ih.lucent.co m > <15685.1119638056.665131@peirce> <15685.1119648267.127122@peirce> <15685.1119656062.522145@peirce> In-Reply-To: MIME-Version: 1.0 Message-Id: <15685.1119658417.662638@peirce> From: Dave Cridland To: Randall Gellens Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Sat Jun 25 00:51:15 2005, Randall Gellens wrote: > At 12:34 AM +0100 6/25/05, Dave Cridland wrote: >> [...] currently, section 2.1.3.2 states that: >> >> An 'X-Mms-Message-Id:' header, if present, SHOULD be retained in >> order to facilitate the case where an MMS message traverses the >> Internet prior to returning to an MMS system. Such systems >> should >> be aware that X-headers might be removed during transit through >> Internet MTAs. > Now that you point it out, I can see how that text could be > interpreted as implying that such headers should be retained when > going from Internet mail to MMS. But, that text appears only in > the section on going from MMS to Internet mail. In the section on > Internet mail to MMS there is no mention of retaining such headers. > > No, but there's no mention of not keeping them either. > However, we already agreed to delete the text you quote by agreeing > that the x-mms-message-id header should no longer be treated > specially, so I think it has become moot. Okay, so I'm to understand that gateways for Internet->MMS MUST drop all X-MMS-* headers? I think text to that effect should be in this document if that's the intent. >> Moreover, if we're not going to apply MMS semantics to those >> headers, why are you so intent on keeping them? > > I'm "so intent on keeping them"? I admit to having argued for > keeping them, but quite some messages ago I agreed that we can > delete them. Okay, so are we agreed that X-MMS-* headers MUST be dropped? Or are you saying that SHOULD be dropped, or MAY be dropped, or MAY be retained? I don't see any argument left standing for keeping them at this point, but maybe I'm missing something. Dave. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 27 18:35:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn2Ck-00014U-He; Mon, 27 Jun 2005 18:35:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn2Ci-00011K-Ms for lemonade@megatron.ietf.org; Mon, 27 Jun 2005 18:35:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04461 for ; Mon, 27 Jun 2005 18:35:45 -0400 (EDT) Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn2bw-0002nN-7o for lemonade@ietf.org; Mon, 27 Jun 2005 19:01:53 -0400 Received: from [192.168.1.13] (vpn-10-50-0-77.qualcomm.com [10.50.0.77]) by warlock.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5RMZSVk028601 for ; Mon, 27 Jun 2005 15:35:30 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <15685.1119658417.662638@peirce> References: <54E40201497DF142B06B27255953F79715EDB3A9@il0015exch007u.ih.lucent.co m > <15685.1119638056.665131@peirce> <15685.1119648267.127122@peirce> <15685.1119656062.522145@peirce> <15685.1119658417.662638@peirce> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Mon, 27 Jun 2005 15:33:09 -0700 To: lemonade@ietf.org From: Randall Gellens Subject: RE: [lemonade] Fwd: Appeal of decision to standardize "Mapping Be tween the Multimedia Messaging Service (MMS) and Internet Mail" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 1.0 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 1:13 AM +0100 6/25/05, Dave Cridland wrote: > Okay, so are we agreed that X-MMS-* headers MUST be dropped? Or are > you saying that SHOULD be dropped, or MAY be dropped, or MAY be > retained? > > I don't see any argument left standing for keeping them at this > point, but maybe I'm missing something. I don't have any argument to make for keeping them either. I think we should say "SHOULD be dropped". -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Politics offers yesterday's answers to today's problems. --Marshall McLuhan _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jun 27 21:36:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn520-0004w9-UU; Mon, 27 Jun 2005 21:36:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn51z-0004vy-7R for lemonade@megatron.ietf.org; Mon, 27 Jun 2005 21:36:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21281 for ; Mon, 27 Jun 2005 21:36:52 -0400 (EDT) Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn5RE-00028N-A5 for lemonade@ietf.org; Mon, 27 Jun 2005 22:03:01 -0400 Received: from [192.168.1.13] (vpn-10-50-0-77.qualcomm.com [10.50.0.77]) by warlock.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5S1abVk017350 for ; Mon, 27 Jun 2005 18:36:38 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <54E40201497DF142B06B27255953F79715EDB3A9@il0015exch007u.ih.lucent.co m > <15685.1119638056.665131@peirce> <15685.1119648267.127122@peirce> <15685.1119656062.522145@peirce> <15685.1119658417.662638@peirce> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Mon, 27 Jun 2005 18:30:55 -0700 To: lemonade@ietf.org From: Randall Gellens Subject: RE: [lemonade] Fwd: Appeal of decision to standardize "Mapping Be tween the Multimedia Messaging Service (MMS) and Internet Mail" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 1.0 (+) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org At 3:33 PM -0700 6/27/05, Randall Gellens wrote: > I don't have any argument to make for keeping them either. It may be worth having a brief informational mention of why it is not a goal of the document. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Lansing Residents Can Drop Off Trees --Newspaper headline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jun 28 04:57:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnBup-0007L7-Nt; Tue, 28 Jun 2005 04:57:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnBun-0007L2-GW for lemonade@megatron.ietf.org; Tue, 28 Jun 2005 04:57:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14255 for ; Tue, 28 Jun 2005 04:57:55 -0400 (EDT) Received: from dsl-217-155-137-62.zen.co.uk ([217.155.137.62] helo=gw2.gestalt.entity.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnCK6-0006Dj-EO for lemonade@ietf.org; Tue, 28 Jun 2005 05:24:07 -0400 Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 559F5154009; Tue, 28 Jun 2005 08:57:31 +0000 (UTC) Date: Tue, 28 Jun 2005 09:57:31 +0100 Subject: RE: [lemonade] Fwd: Appeal of decision to standardize "Mapping Be tween the Multimedia Messaging Service (MMS) and Internet Mail" References: <54E40201497DF142B06B27255953F79715EDB3A9@il0015exch007u.ih.lucent.co m > <15685.1119638056.665131@peirce> <15685.1119648267.127122@peirce> <15685.1119656062.522145@peirce> <15685.1119658417.662638@peirce> In-Reply-To: MIME-Version: 1.0 Message-Id: <2884.1119949051.389333@peirce> From: Dave Cridland To: Randall Gellens Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Mon Jun 27 23:33:09 2005, Randall Gellens wrote: > At 1:13 AM +0100 6/25/05, Dave Cridland wrote: > >> Okay, so are we agreed that X-MMS-* headers MUST be dropped? Or >> are you saying that SHOULD be dropped, or MAY be dropped, or MAY >> be retained? >> >> I don't see any argument left standing for keeping them at this >> point, but maybe I'm missing something. > > I don't have any argument to make for keeping them either. I think > we should say "SHOULD be dropped". I'm fine with a "SHOULD be dropped" for MMS->Internet, but I'd like a "MUST be dropped" for Internet->MMS. Dave. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade