Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15780; 6 Jul 95 16:19 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15774; 6 Jul 95 16:19 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa16598; 6 Jul 95 16:19 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id PAA24489 for ietf-822-list; Thu, 6 Jul 1995 15:22:18 -0400 Received: from gateway.ssw.com (gateway.ssw.com [192.80.11.5]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id PAA24484 for ; Thu, 6 Jul 1995 15:22:09 -0400 Received: from jfox.ssw.com by gateway.ssw.com (5.4.1/SSW204.0) id AA19081; Thu, 6 Jul 1995 15:14:10 -0400 Date: Thu, 6 Jul 1995 15:14:10 -0400 Message-Id: <9507061914.AA19081@gateway.ssw.com> X-Sender: jfox@spyder.ssw.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-822@dimacs.rutgers.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jason Fox Subject: draft-eastlake-internet-payment-00.txt Cc: "Donald E. Eastlake" I have submitted draft-eastlake-internet-payment-00.txt to internet-drafts and made it available as ftp.cybercash.com:pub/draft-eastlake-internet-payment-00.txt (note: this server is configured so that you can not enumerate this directory). This draft suggests the addition of a Telnet option code and the addition of SMTP reply codes and a new SMTP command. I'd be interested in any feedback. I'm on the rfc-822 list but not currently on the telnet list. If anyone knows of an ftp mailing list, I'd appreciate a pointer to it so I can post a notice there also. Thanks, Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20259; 6 Jul 95 19:23 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa20254; 6 Jul 95 19:23 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa20316; 6 Jul 95 19:22 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id SAA28088 for ietf-822-list; Thu, 6 Jul 1995 18:18:38 -0400 Received: from HUGBOX.SZTAKI.HU (hugbox.sztaki.hu [192.84.225.6]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id SAA28085 for ; Thu, 6 Jul 1995 18:18:36 -0400 Date: Thu, 6 Jul 1995 18:18:36 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mailgate@frodo.tii.matav.hu Message-Id: <199507062218.SAA28085@dimacs.rutgers.edu> Received: from htmvax.tii.matav.hu ([145.236.48.3]) by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Fri, 07 Jul 1995 00:18:54 gmt+2 Received: from frodo.tii.matav.hu by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Fri, 07 Jul 1995 00:17:08 MET_DST Subject: Error delivering mail Apparently-To: Cannot deliver mail to `dee' Returned mail follows. ---------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21044; 6 Jul 95 20:17 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa21040; 6 Jul 95 20:17 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa21039; 6 Jul 95 20:17 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id SAA28094 for ietf-822-list; Thu, 6 Jul 1995 18:18:58 -0400 Received: from HUGBOX.SZTAKI.HU (hugbox.sztaki.hu [192.84.225.6]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id SAA28091 for ; Thu, 6 Jul 1995 18:18:57 -0400 Date: Thu, 6 Jul 1995 18:18:57 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mailgate@frodo.tii.matav.hu Message-Id: <199507062218.SAA28091@dimacs.rutgers.edu> Received: from htmvax.tii.matav.hu ([145.236.48.3]) by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Fri, 07 Jul 1995 00:18:49 gmt+2 Received: from frodo.tii.matav.hu by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Fri, 07 Jul 1995 00:17:03 MET_DST Subject: Error delivering mail Apparently-To: Cannot deliver mail to `dee' Returned mail follows. ---------------------------------   Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06264; 8 Jul 95 14:47 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08337; 8 Jul 95 14:47 EDT Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06242; 8 Jul 95 14:47 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06129; 8 Jul 95 14:44 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08285; 8 Jul 95 14:44 EDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06123; 8 Jul 95 14:44 EDT To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-822@dimacs.rutgers.edu Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: The IESG Subject: Protocol Action: The Content-MD5 Header Field to Draft Standard Date: Sat, 08 Jul 95 14:44:03 -0400 X-Orig-Sender: scoya@CNRI.Reston.VA.US Message-ID: <9507081444.aa06123@IETF.CNRI.Reston.VA.US> The IESG has approved the Internet-Draft "The Content-MD5 Header Field" as a Draft Standard. This document is the product of the Internet Message Extensions Working Group. The IESG contact persons are John Klensin and Harald Alvestrand. Technical Summary This protocol defines a mechanism for computing an integrity check on a MIME body part and then provides a header for recording that integrity check in the message. Working Group Summary RFC 1544 was published as a Proposed Standard in November 1993 with input from the then RFC822 Extensions WG (822ext). The protocol has been implemented, is deployed and in use, and no significant problems have been found with the protocol definition in RFC 1544. There are four known independent interoperating implementations of this protocol. They are: 1. mpack/munpack, by John Gardiner Meyers, both generates and verifies the header 2. MH 6.8.3, both generates and verifies the header 3. PMDF (as-yet unreleased), by Innosoft, both generates and verifies the header 4. dtmail, by Sun, generates the header Marshall Rose, the author of RFC 1544, reports that he has not received any comments on the document. Protocol Quality The protocol was reviewed for IESG by John Klensin, Applications Area Director. The protocol is in active use and there are, as noted above, at least four implementations which have been shown to interoperate. Note: Since RFC1544 was published, a minor grammatical problem in the text was noted by one person: not been modified during transport. Message relays and gateways are expressly forbidden to alter its processing based on the presence of the Content-MD5 field. However, a message gateway is allowed to the word "its" should instead be "their". In approving this document as a Draft Standard, IESG concluded that the RFC should be reissued with the following editorial/clarifying changes: (i) In the first line of section 2, change "only by" to "by only". (ii) In the third paragraph of section 2, change "canonical form of the data." to "canonical form of the MIME body part. The MIME body part definition appears in the MIME definition [1]." (iii) In section 3, change "forbidden to alter its" to forbidden to alter their". (iv) Add to the end of section 5 "The IESG made clarifying and editorial changes to the earlier RFC 1544 in advancing this document to Draft Standard."   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08303; 8 Jul 95 17:54 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08299; 8 Jul 95 17:54 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10616; 8 Jul 95 17:54 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08292; 8 Jul 95 17:54 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08288; 8 Jul 95 17:54 EDT Received: from venera.isi.edu by CNRI.Reston.VA.US id aa10611; 8 Jul 95 17:54 EDT Received: from PO4.ANDREW.CMU.EDU by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 8 Jul 1995 14:55:50 -0700 Received: (from postman@localhost) by po4.andrew.cmu.edu (8.6.12/8.6.12) id RAA01293; Sat, 8 Jul 1995 17:55:41 -0400 Received: via switchmail; Sat, 8 Jul 1995 17:55:37 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sat, 8 Jul 1995 17:54:04 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sat, 8 Jul 1995 17:53:59 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Sat, 8 Jul 1995 17:53:53 -0400 (EDT) Message-Id: Date: Sat, 8 Jul 1995 17:53:53 -0400 (EDT) X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Gardiner Myers To: iesg@isi.edu Subject: Re: Protocol Action: The Content-MD5 Header Field to Draft Standard Cc: rfc-editor@isi.edu, ietf-822@dimacs.rutgers.edu In-Reply-To: <9507081444.aa06123@IETF.CNRI.Reston.VA.US> References: <9507081444.aa06123@IETF.CNRI.Reston.VA.US> Beak: is Not The IESG writes: > (ii) In the third paragraph of section 2, change "canonical form of > the data." to "canonical form of the MIME body part. The MIME body > part definition appears in the MIME definition [1]." This change is technically incorrect. The MIME "body part", as defined by RFC 1521, contains both headers and the transfer-encoded form of the data. It is not what the MD5 algorithm is computed on. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10014; 8 Jul 95 21:16 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10010; 8 Jul 95 21:16 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa12964; 8 Jul 95 21:16 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id VAA14899 for ietf-822-list; Sat, 8 Jul 1995 21:10:51 -0400 Received: from mail1.reston.mci.net (mail1.Reston.mci.net [204.70.128.52]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id VAA14895 for ; Sat, 8 Jul 1995 21:10:47 -0400 Received: from klensin (klensin.Reston.mci.net) by MAIL1.RESTON.MCI.NET (PMDF V5.0-3 #8388) id <01HSN3W2A0XC0000XF@MAIL1.RESTON.MCI.NET>; Sat, 08 Jul 1995 21:10:13 -0400 (EDT) Date: Sat, 08 Jul 1995 21:09:57 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John C Klensin Subject: Re: Protocol Action: The Content-MD5 Header Field to Draft Standard X-Sender: klensin@mail1.reston.mci.net To: John Gardiner Myers Cc: iesg@isi.edu, rfc-editor@isi.edu, ietf-822@dimacs.rutgers.edu Message-id: <01HSN3W3JYSI0000XF@MAIL1.RESTON.MCI.NET> MIME-version: 1.0 X-Mailer: Windows Eudora Version 2.1.1b7 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7BIT >This change is technically incorrect. The MIME "body part", as >defined by RFC 1521, contains both headers and the transfer-encoded >form of the data. It is not what the MD5 algorithm is computed on. Would you please supply the exact text you want in its stead? Several IESG members insisted that this not go forward without a definition of what the MD5 is being computed over and, from history, I assumed that was it. john   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02326; 10 Jul 95 9:41 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02322; 10 Jul 95 9:41 EDT Received: from [128.6.75.16] by CNRI.Reston.VA.US id aa06822; 10 Jul 95 9:41 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id IAA04065 for ietf-822-list; Mon, 10 Jul 1995 08:58:07 -0400 Received: from domen.uninett.no (domen.uninett.no [129.241.131.10]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id IAA04062 for ; Mon, 10 Jul 1995 08:57:42 -0400 Received: from troms4.or.uninett.no by domen.uninett.no with SMTP (PP) id <21314-0@domen.uninett.no>; Mon, 10 Jul 1995 14:57:01 +0200 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.9) with ESMTP id LAA01514; Mon, 10 Jul 1995 11:15:15 +0200 Message-Id: <199507100915.LAA01514@dale.uninett.no> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Harald.T.Alvestrand@uninett.no To: John Gardiner Myers cc: iesg@isi.edu, rfc-editor@isi.edu, ietf-822@dimacs.rutgers.edu Subject: Re: Protocol Action: The Content-MD5 Header Field to Draft Standard In-reply-to: Your message of "Sat, 08 Jul 1995 17:53:53 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1511.805367712.1@dale.uninett.no> Date: Mon, 10 Jul 1995 11:15:13 +0200 X-Orig-Sender: hta@dale.uninett.no John is right. The text should be changed to read "canonical form of the body of the MIME body part. The MIME body part definition appears in the MIME definition [1]." Harald A   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07728; 10 Jul 95 11:14 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07717; 10 Jul 95 11:14 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa12829; 10 Jul 95 11:13 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id JAA05345 for ietf-822-list; Mon, 10 Jul 1995 09:59:17 -0400 Received: from riptide.aimnet.com (riptide.aimnet.com [204.247.0.109]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id JAA05333 for ; Mon, 10 Jul 1995 09:59:06 -0400 Received: from aimnet.com (aimnet.aimnet.com [204.247.0.100]) by riptide.aimnet.com (8.6.12/8.6.9) with ESMTP id GAA02495 for ; Mon, 10 Jul 1995 06:31:22 -0700 Received: from [204.118.88.59] (dial-cup2-5.iway.aimnet.com [204.118.88.35]) by aimnet.com (8.6.12/8.6.12) with SMTP id GAA05198; Mon, 10 Jul 1995 06:27:59 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 10 Jul 1995 06:30:07 -0700 To: ruth@muswell.demon.co.uk Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Crocker Subject: Re: EDI X.400/MIME conversions Cc: ietf-mixer@innosoft.com, ietf-822@dimacs.rutgers.edu, info-mime@cs.utk.edu, ruth@muswell.demon.co.uk At 5:55 AM 7/10/95, Ruth Moulton wrote: >The question I have for these mail lists is if anyone knows of any work >being done (or already done) in this area, i.e. specifying conversion >between X.435 other EDI formats, or X.435 and MIME ? You might also wish to query the edi working group mailing list (ietf-edi) and the more general edil-l list. d/ -------------------- Dave Crocker Brandenburg Consulting +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Page: +1 408 581 1174 USA dcrocker@brandenburg.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09147; 10 Jul 95 12:43 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09143; 10 Jul 95 12:43 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa16490; 10 Jul 95 12:42 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id KAA06360 for ietf-822-list; Mon, 10 Jul 1995 10:54:27 -0400 Received: from HUGBOX.SZTAKI.HU (hugbox.sztaki.hu [192.84.225.6]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id KAA06351 for ; Mon, 10 Jul 1995 10:54:17 -0400 Date: Mon, 10 Jul 1995 10:54:17 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mailgate@frodo.tii.matav.hu Message-Id: <199507101454.KAA06351@dimacs.rutgers.edu> Received: from htmvax.tii.matav.hu ([145.236.48.3]) by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Mon, 10 Jul 1995 16:52:58 gmt+2 Received: from frodo.tii.matav.hu by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Mon, 10 Jul 1995 16:51:04 MET_DST Subject: Error delivering mail Apparently-To: Cannot deliver mail to `rfc-editor' Returned mail follows. ---------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09305; 10 Jul 95 12:54 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09301; 10 Jul 95 12:54 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa16680; 10 Jul 95 12:54 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id HAA03727 for ietf-822-list; Mon, 10 Jul 1995 07:58:10 -0400 Received: from muswell.demon.co.uk (muswell.demon.co.uk [158.152.10.120]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id HAA03721 for ; Mon, 10 Jul 1995 07:57:21 -0400 Date: Mon, 10 Jul 95 12:55:54 GMT Message-Id: <4147@muswell.demon.co.uk> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ruth Moulton Reply-To: ruth@muswell.demon.co.uk To: ietf-mixer@innosoft.com, ietf-822@dimacs.rutgers.edu, info-mime@cs.utk.edu Cc: ruth@muswell.demon.co.uk Subject: EDI X.400/MIME conversions Lines: 25 X-Mailer: PCElm 3.1 (1.6 DIS) Hi, I have been looking at the issues involved in enhancing a MIME/X.400 gateway to do conversions between MIME and X.435 (X.435 is MHS:Electronic Data Interchange Messaging System, i.e EDI over X.400 P1) There are various possibilities for the MIME side, as described in RFC 1767 (application/EDIFACT, applicaton/EDI-X12 or application/EDI-Consent) So in this case EDI-Consent could be the BER encoded X.435 message with no conversion as such, or conversion could be done to EDIFACT, X.12 etc. The question I have for these mail lists is if anyone knows of any work being done (or already done) in this area, i.e. specifying conversion between X.435 other EDI formats, or X.435 and MIME ? Also are there other mail lists that I should be asking on ? thanks for your help Ruth Moulton -- Ruth Moulton ruth@muswell.demon.co.uk Consultant, 65 Tetherdown, London N10 1NH, UK. Tel: +44 181 883 5823   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09345; 10 Jul 95 12:56 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09341; 10 Jul 95 12:55 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa16726; 10 Jul 95 12:55 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id KAA06376 for ietf-822-list; Mon, 10 Jul 1995 10:56:08 -0400 Received: from HUGBOX.SZTAKI.HU (hugbox.sztaki.hu [192.84.225.6]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id KAA06348 for ; Mon, 10 Jul 1995 10:52:30 -0400 Date: Mon, 10 Jul 1995 10:52:30 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mailgate@frodo.tii.matav.hu Message-Id: <199507101452.KAA06348@dimacs.rutgers.edu> Received: from htmvax.tii.matav.hu ([145.236.48.3]) by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Mon, 10 Jul 1995 16:53:01 gmt+2 Received: from frodo.tii.matav.hu by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Mon, 10 Jul 1995 16:51:09 MET_DST Subject: Error delivering mail Apparently-To: Cannot deliver mail to `ietf-822' Returned mail follows. ---------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09592; 10 Jul 95 13:10 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09580; 10 Jul 95 13:10 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa17119; 10 Jul 95 13:10 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id EAA03003 for ietf-822-list; Mon, 10 Jul 1995 04:35:58 -0400 Received: from sztaki.hu (sztaki.hu [192.84.225.1]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id EAA02999 for ; Mon, 10 Jul 1995 04:35:47 -0400 Received: by sztaki.hu with SMTP (5.67a8/SZTAKI-3.13) id cL10306; Mon, 10 Jul 1995 10:35:24 +0200 Date: Mon, 10 Jul 1995 10:35:24 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mailgate@frodo.tii.matav.hu Message-Id: <199507100835.cL10306@sztaki.hu> Received: from frodo.tii.matav.hu by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Mon, 10 Jul 1995 10:35:08 MET_DST Subject: Error delivering mail Apparently-To: X-Charset: US X-Char-Esc: 0 Cannot deliver mail to `ietf-822' Returned mail follows. ---------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10822; 10 Jul 95 14:14 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10818; 10 Jul 95 14:14 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa18461; 10 Jul 95 14:14 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id IAA03753 for ietf-822-list; Mon, 10 Jul 1995 08:01:25 -0400 Received: from muswell.demon.co.uk (muswell.demon.co.uk [158.152.10.120]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id IAA03750 for ; Mon, 10 Jul 1995 08:01:19 -0400 Date: Mon, 10 Jul 95 12:59:17 GMT Message-Id: <4152@muswell.demon.co.uk> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ruth Moulton Reply-To: ruth@muswell.demon.co.uk To: ietf-822@dimacs.rutgers.edu Subject: EDI X.400/MIME conversions (fwd) Lines: 43 X-Mailer: PCElm 3.1 (1.6 DIS) Forwarded message follows: > From ruth@muswell.demon.co.uk Mon Jul 10 12:56:49 1995 > Received: from muswell.demon.co.uk by muswell.demon.co.uk with SMTP > id AA4151 ; Mon, 10 Jul 95 12:56:48 GMT > Date: Mon, 10 Jul 95 12:55:54 GMT > Message-Id: <4149@muswell.demon.co.uk> > From: ruth@muswell.demon.co.uk (Ruth Moulton) > Reply-To: ruth@muswell.demon.co.uk > To: ietf-mixer@innosoft.com , ietf-822@dimacs.rutgers.edu , info-mime@cs.utk.edu > Cc: ruth@muswell.demon.co.uk > Subject: EDI X.400/MIME conversions > Lines: 25 > X-Mailer: PCElm 3.1 (1.6 DIS) Status: R Hi, I have been looking at the issues involved in enhancing a MIME/X.400 gateway to do conversions between MIME and X.435 (X.435 is MHS:Electronic Data Interchange Messaging System, i.e EDI over X.400 P1) There are various possibilities for the MIME side, as described in RFC 1767 (application/EDIFACT, applicaton/EDI-X12 or application/EDI-Consent) So in this case EDI-Consent could be the BER encoded X.435 message with no conversion as such, or conversion could be done to EDIFACT, X.12 etc. The question I have for these mail lists is if anyone knows of any work being done (or already done) in this area, i.e. specifying conversion between X.435 other EDI formats, or X.435 and MIME ? Also are there other mail lists that I should be asking on ? thanks for your help Ruth Moulton -- Ruth Moulton ruth@muswell.demon.co.uk Consultant, 65 Tetherdown, London N10 1NH, UK. Tel: +44 181 883 5823   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11090; 10 Jul 95 14:21 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11086; 10 Jul 95 14:21 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18672; 10 Jul 95 14:21 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11079; 10 Jul 95 14:21 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11074; 10 Jul 95 14:21 EDT Received: from venera.isi.edu by CNRI.Reston.VA.US id aa18667; 10 Jul 95 14:21 EDT Received: from PO7.ANDREW.CMU.EDU by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 11:22:28 -0700 Received: (from postman@localhost) by po7.andrew.cmu.edu (8.6.12/8.6.12) id OAA14335; Mon, 10 Jul 1995 14:22:23 -0400 Received: via switchmail; Mon, 10 Jul 1995 14:22:20 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 10 Jul 1995 14:20:58 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 10 Jul 1995 14:20:55 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Mon, 10 Jul 1995 14:20:52 -0400 (EDT) Message-Id: <8k0Ky4i00WBw54dtB5@andrew.cmu.edu> Date: Mon, 10 Jul 1995 14:20:52 -0400 (EDT) X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Gardiner Myers To: ietf-822@dimacs.rutgers.edu, John C Klensin Subject: Re: Protocol Action: The Content-MD5 Header Field to Draft Standard Cc: iesg@isi.edu, rfc-editor@isi.edu, ietf-822@dimacs.rutgers.edu In-Reply-To: <01HSN3W3JYSI0000XF@MAIL1.RESTON.MCI.NET> References: <01HSN3W3JYSI0000XF@MAIL1.RESTON.MCI.NET> Beak: is Not To be consistent with the rest of MIME terminology, I would suggest the term "object", even though that term is not given an explicit definition in 1521. Something like "...the MD5 algorithm is computed on the canonical form of the MIME entity's object." A more substantial rewrite of the paragraph would be: To generate the value of the Content-MD5 field, the MD5 algorithm is computed on the canonical form of the MIME entity's object. In particular, this means that the sender applies the MD5 algorithm on the data immediately after conversion to canonical form, before applying any content-transfer-encoding, and that the receiver also applies the MD5 algorithm on the canonical form, after undoing any content-transfer-encoding. For textual data, this means the MD5 algorithm must be computed on data in which the canonical form for newlines applies, that is, in which each newline is represented by a CR-LF pair. The canonical encoding model of MIME is described in Appendix G of [1]. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03435; 11 Jul 95 2:30 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03429; 11 Jul 95 2:30 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02042; 11 Jul 95 2:30 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03422; 11 Jul 95 2:30 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03418; 11 Jul 95 2:30 EDT Received: from venera.isi.edu by CNRI.Reston.VA.US id aa02037; 11 Jul 95 2:30 EDT Received: from sci1.sri.ucl.ac.be (ns1.sri.ucl.ac.be) by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 10 Jul 1995 23:31:39 -0700 Received: from [130.104.10.52] (macaf.sri) by sci1.sri.ucl.ac.be (5.0/pde-2.95) id AA28989; Tue, 11 Jul 1995 08:31:30 --100 X-Sender: fontaine@pops1.sri.ucl.ac.be Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 11 Jul 1995 08:31:24 +0200 To: John Gardiner Myers , ietf-822@dimacs.rutgers.edu, John C Klensin X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Alain Fontaine (Post master, UCL" MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Subject: Re: Protocol Action: The Content-MD5 Header Field to Draft Standard Cc: iesg@isi.edu, rfc-editor@isi.edu, ietf-822@dimacs.rutgers.edu Content-Length: 479 >To be consistent with the rest of MIME terminology, I would suggest >the term "object", even though that term is not given an explicit >definition in 1521. Something like "...the MD5 algorithm is computed >on the canonical form of the MIME entity's object." Why object ? Is not the MD5 computed on the BODY of the entity ? >A more substantial rewrite of the paragraph would be: Nice. Just replace 'object' by body. /AF   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00786; 11 Jul 95 4:27 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00782; 11 Jul 95 4:27 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa01185; 11 Jul 95 4:27 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id EAA29278 for ietf-822-list; Tue, 11 Jul 1995 04:09:51 -0400 Received: from HUGBOX.SZTAKI.HU (hugbox.sztaki.hu [192.84.225.6]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id EAA29275 for ; Tue, 11 Jul 1995 04:09:39 -0400 Date: Tue, 11 Jul 1995 04:09:39 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mailgate@frodo.tii.matav.hu Message-Id: <199507110809.EAA29275@dimacs.rutgers.edu> Received: from htmvax.tii.matav.hu ([145.236.48.3]) by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Tue, 11 Jul 1995 10:11:04 gmt+2 Received: from frodo.tii.matav.hu by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Tue, 11 Jul 1995 10:09:08 MET_DST Subject: Error delivering mail Apparently-To: Cannot deliver mail to `iesg' Returned mail follows. ---------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab01361; 11 Jul 95 5:22 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01357; 11 Jul 95 5:22 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa01819; 11 Jul 95 5:22 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id EAA29285 for ietf-822-list; Tue, 11 Jul 1995 04:10:24 -0400 Received: from HUGBOX.SZTAKI.HU (hugbox.sztaki.hu [192.84.225.6]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id EAA29281 for ; Tue, 11 Jul 1995 04:10:06 -0400 Date: Tue, 11 Jul 1995 04:10:06 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mailgate@frodo.tii.matav.hu Message-Id: <199507110810.EAA29281@dimacs.rutgers.edu> Received: from htmvax.tii.matav.hu ([145.236.48.3]) by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Tue, 11 Jul 1995 10:11:15 gmt+2 Received: from frodo.tii.matav.hu by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Tue, 11 Jul 1995 10:09:19 MET_DST Subject: Error delivering mail Apparently-To: Cannot deliver mail to `ietf-822' Returned mail follows. ---------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01650; 11 Jul 95 5:37 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01646; 11 Jul 95 5:37 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa02012; 11 Jul 95 5:37 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id EAA29288 for ietf-822-list; Tue, 11 Jul 1995 04:10:30 -0400 Received: from HUGBOX.SZTAKI.HU (hugbox.sztaki.hu [192.84.225.6]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id EAA29282 for ; Tue, 11 Jul 1995 04:10:07 -0400 Date: Tue, 11 Jul 1995 04:10:07 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mailgate@frodo.tii.matav.hu Message-Id: <199507110810.EAA29282@dimacs.rutgers.edu> Received: from htmvax.tii.matav.hu ([145.236.48.3]) by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Tue, 11 Jul 1995 10:11:11 gmt+2 Received: from frodo.tii.matav.hu by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Tue, 11 Jul 1995 10:09:14 MET_DST Subject: Error delivering mail Apparently-To: Cannot deliver mail to `rfc-editor' Returned mail follows. ---------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07222; 11 Jul 95 10:42 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07218; 11 Jul 95 10:42 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08667; 11 Jul 95 10:42 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07202; 11 Jul 95 10:42 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07196; 11 Jul 95 10:42 EDT Received: from venera.isi.edu by CNRI.Reston.VA.US id aa08657; 11 Jul 95 10:41 EDT Received: from PO7.ANDREW.CMU.EDU by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 07:43:00 -0700 Received: (from postman@localhost) by po7.andrew.cmu.edu (8.6.12/8.6.12) id KAA07245; Tue, 11 Jul 1995 10:42:55 -0400 Received: via switchmail; Tue, 11 Jul 1995 10:42:54 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 11 Jul 1995 10:42:27 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 11 Jul 1995 10:42:21 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Tue, 11 Jul 1995 10:42:16 -0400 (EDT) Message-Id: Date: Tue, 11 Jul 1995 10:42:16 -0400 (EDT) X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Gardiner Myers To: ietf-822@dimacs.rutgers.edu, John C Klensin Subject: Re: Protocol Action: The Content-MD5 Header Field to Draft Standard Cc: iesg@isi.edu, rfc-editor@isi.edu, ietf-822@dimacs.rutgers.edu In-Reply-To: References: Beak: Is fontaine@sri.ucl.ac.be (Alain Fontaine (Post master, UCL)) writes: > Why object ? Is not the MD5 computed on the BODY of the entity ? No, the "body" is the result of applying the content transfer encoding to the "object". The MD5 is computed *before* the content transfer encoding is applied. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10227; 11 Jul 95 12:50 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10223; 11 Jul 95 12:50 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11461; 11 Jul 95 12:50 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10216; 11 Jul 95 12:50 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10196; 11 Jul 95 12:50 EDT Received: from venera.isi.edu by CNRI.Reston.VA.US id aa11433; 11 Jul 95 12:49 EDT Received: from THOR.INNOSOFT.COM by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 09:49:21 -0700 Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.0-4 #2001) id <01HSQM80SX0G8ZEJS1@INNOSOFT.COM>; Tue, 11 Jul 1995 09:49:11 -0700 (PDT) Date: Tue, 11 Jul 1995 09:44:34 -0700 (PDT) X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ned Freed Subject: Re: Protocol Action: The Content-MD5 Header Field to Draft Standard In-Reply-To: "Your message dated Tue, 11 Jul 1995 10:42:16 -0400 (EDT)" To: John Gardiner Myers Cc: ietf-822@dimacs.rutgers.edu, John C Klensin , iesg@isi.edu, rfc-editor@isi.edu Message-Id: <01HSQMZUR82W8ZEJS1@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT References: > fontaine@sri.ucl.ac.be (Alain Fontaine (Post master, UCL)) writes: > > Why object ? Is not the MD5 computed on the BODY of the entity ? > No, the "body" is the result of applying the content transfer encoding > to the "object". The MD5 is computed *before* the content transfer > encoding is applied. Another way to say it would be "the body prior to the application of the content transfer encoding". But regardless of what term you happen to pick to describe the material inside, its crucial that we emphasize the order in which the operations are performed. Its unfortunate that content-md5 has to be separate from the primary MIME documents -- it would be both simplest and best to tie it into the canonical encoding model at the proper place. Ned   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14938; 11 Jul 95 15:53 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14933; 11 Jul 95 15:53 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15387; 11 Jul 95 15:53 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14924; 11 Jul 95 15:53 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14920; 11 Jul 95 15:53 EDT Received: from venera.isi.edu by CNRI.Reston.VA.US id aa15382; 11 Jul 95 15:53 EDT Received: from PO4.ANDREW.CMU.EDU by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 11 Jul 1995 12:54:17 -0700 Received: (from postman@localhost) by po4.andrew.cmu.edu (8.6.12/8.6.12) id PAA02510; Tue, 11 Jul 1995 15:54:04 -0400 Received: via switchmail; Tue, 11 Jul 1995 15:54:01 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 11 Jul 1995 15:53:36 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 11 Jul 1995 15:53:27 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Tue, 11 Jul 1995 15:53:25 -0400 (EDT) Message-Id: Date: Tue, 11 Jul 1995 15:53:25 -0400 (EDT) X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Gardiner Myers To: ietf-822@dimacs.rutgers.edu Subject: Re: Protocol Action: The Content-MD5 Header Field to Draft Standard Cc: John C Klensin , iesg@isi.edu, rfc-editor@isi.edu In-Reply-To: <01HSQMZUR82W8ZEJS1@INNOSOFT.COM> References: <01HSQMZUR82W8ZEJS1@INNOSOFT.COM> Beak: is Not Ned Freed writes: > Another way to say it would be "the body prior to the application of the > content transfer encoding". Being a formalist, I would say that prior to the application of the content transfer encoding, it's not the body. It's like talking about "the message prior to the addition of the headers". RFC 1521 uses the term "object" consistently to refer to the thing that the MD5 digest is applied to. > Its unfortunate that content-md5 has to be separate from the primary MIME > documents -- it would be both simplest and best to tie it into the canonical > encoding model at the proper place. If the timing permits, I'd like to see content-md5 merged into the the primary MIME documents by the time they go to Standard. Content-MD5 is a great example of why one has to get the canonical encoding model correct. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02924; 12 Jul 95 8:23 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02920; 12 Jul 95 8:23 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa04022; 12 Jul 95 8:22 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id HAA23863 for ietf-822-list; Wed, 12 Jul 1995 07:18:45 -0400 Received: from sci1.sri.ucl.ac.be (ns1.sri.ucl.ac.be [130.104.1.1]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id HAA23860 for ; Wed, 12 Jul 1995 07:18:43 -0400 Received: from [130.104.10.52] (macaf.sri) by sci1.sri.ucl.ac.be (5.0/pde-2.95) id AA10087; Wed, 12 Jul 1995 13:18:36 --100 X-Sender: fontaine@pops1.sri.ucl.ac.be Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Jul 1995 13:18:31 +0200 To: John Gardiner Myers , ietf-822@dimacs.rutgers.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Alain Fontaine (Post master, UCL" MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Subject: Re: Protocol Action: The Content-MD5 Header Field to Draft Standard Cc: John C Klensin content-length: 642 At 15:53 11/07/95, John Gardiner Myers wrote: >RFC 1521 uses the term "object" consistently to refer to the thing >that the MD5 digest is applied to. > >Content-MD5 >is a great example of why one has to get the canonical encoding model >correct. It would have been possible to refine the set of definitions in 1521 to include term to designate, without ambiguity, the canonical content of the body and the body as actually sent, with encoding applied. But since I do not agree at all with the way the definitions are modified in the latest drafts, I'm not going to make a proposal. /AF   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06634; 12 Jul 95 11:19 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06630; 12 Jul 95 11:19 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa07737; 12 Jul 95 11:19 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id LAA27344 for ietf-822-list; Wed, 12 Jul 1995 11:09:34 -0400 Received: from HUGBOX.SZTAKI.HU (hugbox.sztaki.hu [192.84.225.6]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id LAA27341 for ; Wed, 12 Jul 1995 11:09:30 -0400 Date: Wed, 12 Jul 1995 11:09:30 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mailgate@frodo.tii.matav.hu Message-Id: <199507121509.LAA27341@dimacs.rutgers.edu> Received: from htmvax.tii.matav.hu ([145.236.48.3]) by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Wed, 12 Jul 1995 17:10:42 gmt+2 Received: from frodo.tii.matav.hu by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Wed, 12 Jul 1995 17:08:43 MET_DST Subject: Error delivering mail Apparently-To: Cannot deliver mail to `klensin' Returned mail follows. ---------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13947; 18 Jul 95 15:32 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13943; 18 Jul 95 15:32 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa16093; 18 Jul 95 15:32 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id PAA23440 for ietf-822-list; Tue, 18 Jul 1995 15:03:59 -0400 Received: from warren.banyan.com (warren.banyan.com [131.100.182.40]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id PAA23435 for ; Tue, 18 Jul 1995 15:03:41 -0400 Received: from kilsythe.banyan.com by warren.banyan.com with SMTP (1.38.193.4/16.2) id AA06739; Tue, 18 Jul 1995 15:10:09 -0400 Received: from aberdeen.banyan.com by kilsythe.banyan.com (5.0/SMI-SVR4) id AA09627; Tue, 18 Jul 1995 15:04:45 +0500 Received: by aberdeen.banyan.com (5.0/SMI-SVR4) id AA02769; Tue, 18 Jul 1995 15:08:46 +0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Terry Crowley Message-Id: Reply-To: Terry Crowley Date: Tue, 18 Jul 1995 15:08:44 -0500 To: ietf-822@dimacs.rutgers.edu Subject: Multipart/Alternative Compatibility Issue Content-Length: 2067 I've run across a compatibility issue between clients when trying to make use of the multipart/alternative format. I was wondering whether anyone else has run across this or has comments on the problem. My mail client uses a custom format to represent rich text, embedded OLE and extended attribute information. Under configuration control, we support two different ways of encoding a message that contains this extended information: 1) Using multipart/alternative multipart/mixed multipart/alternative text/plain application/x-beyondmail ... other attachments ... 2) Using multipart/mixed alone multipart/mixed text/plain application/x-beyondmail ... other attachments ... Our client can accept either format and assumes that, even in the second case, the data in the application/x-beyondmail object completely contains and overrides the body of the text. The multipart/alternative format clearly more correctly encodes the semantics of the message. However, the problems we are encountering make it painful to use this encoding, even with clients that support MIME. I've seen problems with two clients, Sun's mailtool and NetManage's bundled mail client. I assume other mail clients might also have problems. In Sun's mailtool, a received message in format 1 comes in with an empty text body. The user must then double-click on the icon in the attachment box indicating the multipart/alternative object. That causes a second window to appear with the text body showing and the x-beyondmail format appearing as an attachment in that window's attachment box. No information is lost, but the two-level interaction just to see a simple message is painful. The NetManage client behaves even worse. It also shows the multipart/alternative object as an attachment, but it only does a single level of parsing, so opening this attachment results in a body that contains both the text and x-beyondmail contents running together. Neither behavior is acceptable. Anybody else run into problems like this? Terry   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00393; 20 Jul 95 23:19 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00388; 20 Jul 95 23:19 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa00723; 20 Jul 95 23:19 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id JAA29623 for ietf-822-list; Thu, 20 Jul 1995 09:11:08 -0400 Received: from warren.banyan.com (warren.banyan.com [131.100.182.40]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id JAA29620 for ; Thu, 20 Jul 1995 09:11:01 -0400 Received: from kilsythe.banyan.com by warren.banyan.com with SMTP (1.38.193.4/16.2) id AA21478; Thu, 20 Jul 1995 09:17:33 -0400 Received: from aberdeen.banyan.com by kilsythe.banyan.com (5.0/SMI-SVR4) id AA10517; Thu, 20 Jul 1995 09:12:08 +0500 Received: by aberdeen.banyan.com (5.0/SMI-SVR4) id AA03539; Thu, 20 Jul 1995 09:16:11 +0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Terry Crowley Message-Id: In-Reply-To: <01HT2BTZ7TRWASBNL0@SIGURD.INNOSOFT.COM> Reply-To: Terry Crowley Date: Thu, 20 Jul 1995 09:16:10 -0500 Subject: Re: Multipart/Alternative Compatibility Issue To: Ned Freed Cc: ietf-822@dimacs.rutgers.edu Content-Length: 1817 > I use a couple of different MIME clients, none of which have any problems with > getting at the data in multipart/alternative. The worst I've seen is where > multipart/alternative is treated as multipart/mixed, and this just isn't that > bad. It depends on what you mean by "bad". ("Imagine every atom in your body exploding at the speed of light...OK, good safety tip, don't cross the beams.") OK, not that bad if you get one of these messages every couple days, but imagine you have 150 messages in your inbox, every one of which requires that you go through this multi-step process just to look at what might be a two sentence message. I think that's worse than bad, that's horrible. And I can guarantee it would be sufficient to be a deal-breaker in many cases. I'm sure you're familiar enough with the commercial market to know that pointing fingers and saying "it's their fault!" doesn't get you very far with a customer who just wants things to work. The MIME spec says that "Receiving user agents should pick and display the last format they are capable of displaying." I'd argue that by just showing the multipart/alternative object, those user agents have not done any picking. From a practical point of view, this behavior, if typical of MIME user agents, makes multipart/alternative significantly less useful. These aren't abstractions. We give the customer a choice of what format to use, and they are choosing to use the multipart/mixed form since they find that it introduces less problems (e.g. users complaining to the mail administrator) in real day-to-day heterogeneous message exchange. That's a fact, and no amount of explaining the advantages of semantic accuracy will make them happy. They just want to read the damn message (and probably delete it). Terry   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00402; 20 Jul 95 23:19 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00398; 20 Jul 95 23:19 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa00729; 20 Jul 95 23:19 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id HAA28633 for ietf-822-list; Thu, 20 Jul 1995 07:01:01 -0400 Received: from HUGBOX.SZTAKI.HU (hugbox.sztaki.hu [192.84.225.6]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id HAA28630 for ; Thu, 20 Jul 1995 07:00:54 -0400 Date: Thu, 20 Jul 1995 07:00:54 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mailgate@frodo.tii.matav.hu Message-Id: <199507201100.HAA28630@dimacs.rutgers.edu> Received: from htmvax.tii.matav.hu ([145.236.48.3]) by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Thu, 20 Jul 1995 13:02:09 gmt+2 Received: from frodo.tii.matav.hu by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Thu, 20 Jul 1995 12:59:42 MET_DST Subject: Error delivering mail Apparently-To: Cannot deliver mail to `ietf-822' Returned mail follows. ---------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00412; 20 Jul 95 23:19 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00408; 20 Jul 95 23:19 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa00735; 20 Jul 95 23:19 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id DAA28016 for ietf-822-list; Thu, 20 Jul 1995 03:37:54 -0400 Received: from domen.uninett.no (domen.uninett.no [129.241.131.10]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id DAA28012 for ; Thu, 20 Jul 1995 03:37:46 -0400 Received: from dale.ietf33.nordu.net by domen.uninett.no with SMTP (PP) id <15809-0@domen.uninett.no>; Thu, 20 Jul 1995 09:37:05 +0200 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.9) with ESMTP id CAA00347; Thu, 20 Jul 1995 02:16:37 +0200 Message-Id: <199507200016.CAA00347@dale.uninett.no> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Harald.T.Alvestrand@uninett.no To: Terry Crowley cc: ietf-822@dimacs.rutgers.edu Subject: Re: Multipart/Alternative Compatibility Issue In-reply-to: Your message of "Tue, 18 Jul 1995 15:08:44 CDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <344.806199397.1@dale.uninett.no> Date: Thu, 20 Jul 1995 02:16:37 +0200 X-Orig-Sender: hta@dale.uninett.no Terry, it is clear to me that both NetManage and Sun Mailtool is buggy. (as if that helped....) You didn't quote version numbers; I would suggest that any owners of NetManage or Sun Mailtool on the list contact you for a sample message, and report the bug to their respective vendors. After all, commercial software should give you the right to complain about it to the vendor when it doesn't support the standard that it claims to support. Wednesday night, in Stockholm, noticing that nobody else answered your mail on the list, and just wanting to make supportive noises. Harald T. Alvestrand   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00422; 20 Jul 95 23:20 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00418; 20 Jul 95 23:19 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa00741; 20 Jul 95 23:19 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id CAA27599 for ietf-822-list; Thu, 20 Jul 1995 02:32:16 -0400 Received: from HUGBOX.SZTAKI.HU (hugbox.sztaki.hu [192.84.225.6]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id CAA27596 for ; Thu, 20 Jul 1995 02:32:12 -0400 Date: Thu, 20 Jul 1995 02:32:12 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mailgate@frodo.tii.matav.hu Message-Id: <199507200632.CAA27596@dimacs.rutgers.edu> Received: from htmvax.tii.matav.hu ([145.236.48.3]) by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Thu, 20 Jul 1995 08:33:59 gmt+2 Received: from frodo.tii.matav.hu by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Thu, 20 Jul 1995 08:10:46 MET_DST Subject: Error delivering mail Apparently-To: Cannot deliver mail to `ietf-822' Returned mail follows. ---------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00434; 20 Jul 95 23:20 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00430; 20 Jul 95 23:20 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa00747; 20 Jul 95 23:20 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id WAA25838 for ietf-822-list; Wed, 19 Jul 1995 22:57:32 -0400 Received: from sigurd.innosoft.com (SIGURD.INNOSOFT.COM [192.160.253.70]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id WAA25835 for ; Wed, 19 Jul 1995 22:57:30 -0400 Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V5.1-0 #8790) id <01HT1ZE8Z4FKASBNL0@SIGURD.INNOSOFT.COM>; Wed, 19 Jul 1995 18:39:23 -0700 (PDT) Date: Wed, 19 Jul 1995 18:32:03 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ned Freed Subject: Re: Multipart/Alternative Compatibility Issue In-reply-to: "Your message dated Tue, 18 Jul 1995 15:08:44 -0500" To: tcrowley@kilsythe.banyan.com Cc: ietf-822@dimacs.rutgers.edu Message-id: <01HT2BTZ7TRWASBNL0@SIGURD.INNOSOFT.COM> X-Envelope-to: ietf-822@dimacs.rutgers.edu MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > I've run across a compatibility issue between clients when trying to make use > of the multipart/alternative format. I was wondering whether anyone else has > run across this or has comments on the problem. > My mail client uses a custom format to represent rich text, embedded OLE and > extended attribute information. Under configuration control, we support two > different ways of encoding a message that contains this extended information: > 1) Using multipart/alternative > multipart/mixed > multipart/alternative > text/plain > application/x-beyondmail > ... other attachments ... This represents a collection of independent objects, where the first object is available in two different formats: text/plain and application/x-beyondmail. > 2) Using multipart/mixed alone > multipart/mixed > text/plain > application/x-beyondmail > ... other attachments ... This represents a collection of objects, where the first is text/plain and the second is application/x-beyondmail. > Our client can accept either format and assumes that, even in the second case, > the data in the application/x-beyondmail object completely contains and > overrides the body of the text. It shouldn't. The specifications are quite clear on this -- the parts in a multipart/mixed are all independent and distinct entities that happen to have been collected into a bundle. > The multipart/alternative format clearly more correctly encodes the semantics > of the message. However, the problems we are encountering make it painful to > use this encoding, even with clients that support MIME. I've seen problems > with two clients, Sun's mailtool and NetManage's bundled mail client. I > assume other mail clients might also have problems. I use a couple of different MIME clients, none of which have any problems with getting at the data in multipart/alternative. The worst I've seen is where multipart/alternative is treated as multipart/mixed, and this just isn't that bad. > In Sun's mailtool, a received message in format 1 comes in with an empty text > body. The user must then double-click on the icon in the attachment box > indicating the multipart/alternative object. That causes a second window to > appear with the text body showing and the x-beyondmail format appearing as an > attachment in that window's attachment box. No information is lost, but the > two-level interaction just to see a simple message is painful. Frankly, this doesn't sound like much of a problem to me. > The NetManage client behaves even worse. It also shows the > multipart/alternative object as an attachment, but it only does a single level > of parsing, so opening this attachment results in a body that contains both > the text and x-beyondmail contents running together. This is a bug. Plain and simple. It needs to be fixed. Nothing more and nothing less. Screwing around with structures and using constructs illegally is not an acceptable alternative -- your proposed cure is much worse than the disease. Ned   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12791; 21 Jul 95 21:36 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12787; 21 Jul 95 21:36 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa21470; 21 Jul 95 21:36 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id UAA05090 for ietf-822-list; Fri, 21 Jul 1995 20:47:16 -0400 Received: from HUGBOX.SZTAKI.HU (hugbox.sztaki.hu [192.84.225.6]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id UAA05085 for ; Fri, 21 Jul 1995 20:46:37 -0400 Date: Fri, 21 Jul 1995 20:46:37 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mailgate@frodo.tii.matav.hu Message-Id: <199507220046.UAA05085@dimacs.rutgers.edu> Received: from htmvax.tii.matav.hu ([145.236.48.3]) by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Sat, 22 Jul 1995 02:48:14 gmt+2 Received: from frodo.tii.matav.hu by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Sat, 22 Jul 1995 02:16:30 MET_DST Subject: Mail delivery error Apparently-To: Note: This message was generated automagically. An error was detected, while processing the enclosed message. --> Error description: No such local user --> Error for: ietf-822@dimacs.rutgers.edu Returned mail follows. --------------------------------- X-Envelope-To: gyurik@frodo.tii.matav.hu Return-Path: Received: from htmvax.tii.matav.hu ([145.236.48.3]) by frodo.tii.matav.hu (SMTPSRV); Sat 22 Jul 1995 01:56 Received: from HUGBOX.SZTAKI.HU by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Thu, 20 Jul 1995 16:18:28 MET_DST Received: from dimacs.rutgers.edu by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Thu, 20 Jul 1995 16:20:04 gmt+2 Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id JAA29623 for ietf-822-list; Thu, 20 Jul 1995 09:11:08 -0400 Received: from warren.banyan.com (warren.banyan.com [131.100.182.40]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id JAA29620 for ; Thu, 20 Jul 1995 09:11:01 -0400 Received: from kilsythe.banyan.com by warren.banyan.com with SMTP (1.38.193.4/16.2) id AA21478; Thu, 20 Jul 1995 09:17:33 -0400 Received: from aberdeen.banyan.com by kilsythe.banyan.com (5.0/SMI-SVR4) id AA10517; Thu, 20 Jul 1995 09:12:08 +0500 Received: by aberdeen.banyan.com (5.0/SMI-SVR4) id AA03539; Thu, 20 Jul 1995 09:16:11 +0500 From: tcrowley@kilsythe.banyan.com (Terry Crowley) Message-ID: In-Reply-To: <01HT2BTZ7TRWASBNL0@SIGURD.INNOSOFT.COM> Reply-To: Terry Crowley Date: Thu, 20 Jul 1995 09:16:10 -0500 Subject: Re: Multipart/Alternative Compatibility Issue To: Ned Freed CC: ietf-822@dimacs.rutgers.edu Content-Length: 1817 > I use a couple of different MIME clients, none of which have any problems with > getting at the data in multipart/alternative. The worst I've seen is where > multipart/alternative is treated as multipart/mixed, and this just isn't that > bad. It depends on what you mean by "bad". ("Imagine every atom in your body exploding at the speed of light...OK, good safety tip, don't cross the beams.") OK, not that bad if you get one of these messages every couple days, but imagine you have 150 messages in your inbox, every one of which requires that you go through this multi-step process just to look at what might be a two sentence message. I think that's worse than bad, that's horrible. And I can guarantee it would be sufficient to be a deal-breaker in many cases. I'm sure you're familiar enough with the commercial market to know that pointing fingers and saying "it's their fault!" doesn't get you very far with a customer who just wants things to work. The MIME spec says that "Receiving user agents should pick and display the last format they are capable of displaying." I'd argue that by just showing the multipart/alternative object, those user agents have not done any picking. From a practical point of view, this behavior, if typical of MIME user agents, makes multipart/alternative significantly less useful. These aren't abstractions. We give the customer a choice of what format to use, and they are choosing to use the multipart/mixed form since they find that it introduces less problems (e.g. users complaining to the mail administrator) in real day-to-day heterogeneous message exchange. That's a fact, and no amount of explaining the advantages of semantic accuracy will make them happy. They just want to read the damn message (and probably delete it). Terry From ITUDOC.ITUDOC@ITU.CH Sat 22 Jul 1995 02:16   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07525; 23 Jul 95 14:13 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07521; 23 Jul 95 14:13 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa11141; 23 Jul 95 14:13 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id NAA05162 for ietf-822-list; Sun, 23 Jul 1995 13:29:41 -0400 Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id NAA05157 for ; Sun, 23 Jul 1995 13:29:06 -0400 Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.0-4 #2001) id <01HT6H116N288ZFTD0@INNOSOFT.COM>; Sun, 23 Jul 1995 10:27:59 -0700 (PDT) Date: Sun, 23 Jul 1995 10:11:48 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ned Freed Subject: Re: Multipart/Alternative Compatibility Issue In-reply-to: "Your message dated Thu, 20 Jul 1995 09:16:10 -0500" To: tcrowley@kilsythe.banyan.com Cc: ietf-822@dimacs.rutgers.edu Message-id: <01HT7FU4EXI08ZFTD0@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT References: <01HT2BTZ7TRWASBNL0@SIGURD.INNOSOFT.COM> > > I use a couple of different MIME clients, none of which have any problems with > > getting at the data in multipart/alternative. The worst I've seen is where > > multipart/alternative is treated as multipart/mixed, and this just isn't > > that bad. > It depends on what you mean by "bad". ("Imagine every atom in your body > exploding at the speed of light...OK, good safety tip, don't cross the > beams.") OK, not that bad if you get one of these messages every couple days, > but imagine you have 150 messages in your inbox, every one of which requires > that you go through this multi-step process just to look at what might be a > two sentence message. I think that's worse than bad, that's horrible. And I > can guarantee it would be sufficient to be a deal-breaker in many cases. I'm > sure you're familiar enough with the commercial market to know that pointing > fingers and saying "it's their fault!" doesn't get you very far with a > customer who just wants things to work. Say what? What you've effectively done here is argue against your own chosen approach! You're the one that has chosen to package multipart/alternative as multipart/mixed, not me! By packaging things as multipart/mixed instead of using multipart/alternative properly you guarantee that everyone with a *compliant* MIME agent has to go through the very process you deplore. Were you to choose to package things properly you would only have this problem with clients that treat multipart/alternative as multipart/mixed, and no choice you make is going to fix this behavior, so you'd best stop trying. > The MIME spec says that "Receiving user agents should pick and display the > last format they are capable of displaying." I'd argue that by just showing > the multipart/alternative object, those user agents have not done any picking. I completely agree. But so what? You've made a choice that at best is no worse that multipart/alternative but at worst is considerably less useful. > From a practical point of view, this behavior, if typical of MIME user agents, > makes multipart/alternative significantly less useful. These aren't > abstractions. We give the customer a choice of what format to use, and they > are choosing to use the multipart/mixed form since they find that it > introduces less problems (e.g. users complaining to the mail administrator) in > real day-to-day heterogeneous message exchange. My experience has been exactly the opposite. I too sell MIME software and the preference thus far has been strongly in favor of multipart/alternative. But even if my experience agreed with yours, letting one broken agent dictate a highly suboptimal strategy is only a good idea in the short term. Eventually that agent will be fixed and then you will have angry customers all over asking you why you encouraged them to do the wrong thing. > That's a fact, and no amount > of explaining the advantages of semantic accuracy will make them happy. They > just want to read the damn message (and probably delete it). Semantic accuracy is not the issue. I could not care less about it. Standards and expected behavior are. Compliant agents exist and will do the right thing with properly formatted messages. Eventually these agents will dominate and your sop to one broken agent will change from a small and problematic asset into a big liability. Explaining this to a customer as a sematic issue is pointless as well. It needs to be explained as an issue where compliance with the standards provides major benefits. Show the customer how well it works with software that does support the standard and explain that this one agent is broken. See if they cannot get the vendor to fix it based on this explanation. And if they cannot, well, it sounds to me like a golden opportunity to sell them some agents that do work! Ned   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08607; 23 Jul 95 19:27 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08603; 23 Jul 95 19:27 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa14787; 23 Jul 95 19:27 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id SAA06786 for ietf-822-list; Sun, 23 Jul 1995 18:17:49 -0400 Received: from HUGBOX.SZTAKI.HU (hugbox.sztaki.hu [192.84.225.6]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id SAA06783 for ; Sun, 23 Jul 1995 18:17:46 -0400 Date: Sun, 23 Jul 1995 18:17:46 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mailgate@frodo.tii.matav.hu Message-Id: <199507232217.SAA06783@dimacs.rutgers.edu> Received: from htmvax.tii.matav.hu ([145.236.48.3]) by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 00:18:12 gmt+2 Received: from frodo.tii.matav.hu by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 00:12:12 MET_DST Subject: Mail delivery error Apparently-To: Note: This message was generated automagically. An error was detected, while processing the enclosed message. --> Error description: No such local user --> Error for: ietf-822@dimacs.rutgers.edu Returned mail follows. --------------------------------- X-Envelope-To: gyurik@frodo.tii.matav.hu Return-Path: Received: from htmvax.tii.matav.hu ([145.236.48.3]) by frodo.tii.matav.hu (SMTPSRV); Sun 23 Jul 1995 23:34 Received: from HUGBOX.SZTAKI.HU by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Sun, 23 Jul 1995 20:32:09 MET_DST Received: from dimacs.rutgers.edu by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Sun, 23 Jul 1995 20:33:35 gmt+2 Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id NAA05162 for ietf-822-list; Sun, 23 Jul 1995 13:29:41 -0400 Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id NAA05157 for ; Sun, 23 Jul 1995 13:29:06 -0400 Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.0-4 #2001) id <01HT6H116N288ZFTD0@INNOSOFT.COM>; Sun, 23 Jul 1995 10:27:59 -0700 (PDT) Date: Sun, 23 Jul 1995 10:11:48 -0700 (PDT) From: Ned Freed Subject: Re: Multipart/Alternative Compatibility Issue In-reply-to: "Your message dated Thu, 20 Jul 1995 09:16:10 -0500" To: tcrowley@kilsythe.banyan.com CC: ietf-822@dimacs.rutgers.edu Message-ID: <01HT7FU4EXI08ZFTD0@INNOSOFT.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT References: <01HT2BTZ7TRWASBNL0@SIGURD.INNOSOFT.COM> > > I use a couple of different MIME clients, none of which have any problems with > > getting at the data in multipart/alternative. The worst I've seen is where > > multipart/alternative is treated as multipart/mixed, and this just isn't > > that bad. > It depends on what you mean by "bad". ("Imagine every atom in your body > exploding at the speed of light...OK, good safety tip, don't cross the > beams.") OK, not that bad if you get one of these messages every couple days, > but imagine you have 150 messages in your inbox, every one of which requires > that you go through this multi-step process just to look at what might be a > two sentence message. I think that's worse than bad, that's horrible. And I > can guarantee it would be sufficient to be a deal-breaker in many cases. I'm > sure you're familiar enough with the commercial market to know that pointing > fingers and saying "it's their fault!" doesn't get you very far with a > customer who just wants things to work. Say what? What you've effectively done here is argue against your own chosen approach! You're the one that has chosen to package multipart/alternative as multipart/mixed, not me! By packaging things as multipart/mixed instead of using multipart/alternative properly you guarantee that everyone with a *compliant* MIME agent has to go through the very process you deplore. Were you to choose to package things properly you would only have this problem with clients that treat multipart/alternative as multipart/mixed, and no choice you make is going to fix this behavior, so you'd best stop trying. > The MIME spec says that "Receiving user agents should pick and display the > last format they are capable of displaying." I'd argue that by just showing > the multipart/alternative object, those user agents have not done any picking. I completely agree. But so what? You've made a choice that at best is no worse that multipart/alternative but at worst is considerably less useful. > From a practical point of view, this behavior, if typical of MIME user agents, > makes multipart/alternative significantly less useful. These aren't > abstractions. We give the customer a choice of what format to use, and they > are choosing to use the multipart/mixed form since they find that it > introduces less problems (e.g. users complaining to the mail administrator) in > real day-to-day heterogeneous message exchange. My experience has been exactly the opposite. I too sell MIME software and the preference thus far has been strongly in favor of multipart/alternative. But even if my experience agreed with yours, letting one broken agent dictate a highly suboptimal strategy is only a good idea in the short term. Eventually that agent will be fixed and then you will have angry customers all over asking you why you encouraged them to do the wrong thing. > That's a fact, and no amount > of explaining the advantages of semantic accuracy will make them happy. They > just want to read the damn message (and probably delete it). Semantic accuracy is not the issue. I could not care less about it. Standards and expected behavior are. Compliant agents exist and will do the right thing with properly formatted messages. Eventually these agents will dominate and your sop to one broken agent will change from a small and problematic asset into a big liability. Explaining this to a customer as a sematic issue is pointless as well. It needs to be explained as an issue where compliance with the standards provides major benefits. Show the customer how well it works with software that does support the standard and explain that this one agent is broken. See if they cannot get the vendor to fix it based on this explanation. And if they cannot, well, it sounds to me like a golden opportunity to sell them some agents that do work! Ned From owner-winnews@microsoft.nwnet.com Mon 24 Jul 1995 00:17   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06253; 24 Jul 95 3:50 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06249; 24 Jul 95 3:50 EDT Received: from services.Bunyip.COM by CNRI.Reston.VA.US id aa04349; 24 Jul 95 3:50 EDT Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id DAA20021 for uri-out; Mon, 24 Jul 1995 03:19:49 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id DAA20016 for ; Mon, 24 Jul 1995 03:19:45 -0400 Received: from domen.uninett.no by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA06696 (mail destined for uri@services.bunyip.com); Mon, 24 Jul 95 03:19:41 -0400 Received: from troms2.or.uninett.no by domen.uninett.no with SMTP (PP) id <25021-0@domen.uninett.no>; Mon, 24 Jul 1995 09:18:59 +0200 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.9) with ESMTP id WAA00170; Sun, 23 Jul 1995 22:08:53 +0200 Message-Id: <199507232008.WAA00170@dale.uninett.no> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Harald.T.Alvestrand@uninett.no To: drums@cs.utk.edu, ietf-822@dimacs.rutgers.edu, uri@bunyip.com Subject: An idea for MID and CID URsomethings Reply-To: drums@cs.utk.edu Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-Id: <166.806530098.0@dale.uninett.no> Date: Sun, 23 Jul 1995 22:08:52 +0200 X-Orig-Sender: owner-uri@bunyip.com Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <166.806530098.1@dale.uninett.no> I talked to some people briefly about this during IETF. Since it points out some problems with "what does an ID identify" in both MIME and RFC 822, I think "drums" may be a nice "home list" to discuss it on; I've set reply-to accordingly. I don't know whether it is either best or appropriate for me to continue editing this; does anyone feel like taking responsibility? (Ed Levinson had a previous document on CID URLs, but I've lost my copy of it, and he seems to have shelved the idea for the moment) Comments? Harald A ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <166.806530098.2@dale.uninett.no> draft MID and CID URLs July 95 Message-ID and Content-ID URLs Sun Jul 23 19:16:56 MET DST 1995 Harald Tveit Alvestrand UNINETT Harald.T.Alvestrand@uninett.no Status of this Memo This document specifies two classes of URsomethings, MID and CID. The intention is to allow reference to messages and message components using a syntax that looks much like that used for URLs in the Web. This draft document is being circulated for comment. Please send comments to the author, or to..... The following text is required by the Internet-draft rules: This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. The file name of this version is draft-alvestrand-not-submitted- at-all.txt Alvestrand Expires Jan 96 [Page 1] draft MID and CID URLs July 95 1. Introduction When writing information resources, it would sometimes be nice to have a reasonably unique way of referring to mail and news messages. In some cases, like when you are sending a message coded in HTML, it is also nice to be able to refer to parts of a message by content-id. These references are not Uniform Resource Locators, since they do not encode the location of their objects, neither are they Uniform Resource Names, since they do not fulfil all requirements of RFC 1737; for lack of a better idea, I call them Reasonably Unique Identifying Names; this term obviously does not have a four-letter abbreviation. 2. The Message-ID UR? 2.1. Syntax The syntax of the message-ID locator is mid = "mid:" message-id where message-id is imported from STD 12, "Internet Mail", RFC 822. When it is used in protocols which do not allow the full character set of RFC 822, it must be encoded using the %-convention. 2.2. The identified object The message-ID locator resolves to an Internet message. This identifies a message header and a message body conformant to RFC 822 and (possibly) MIME; due to the history of Internet messages, the following differences must be expected between different copies of the same message: (1) Variable number of "Received:" lines in the header (2) Randomized order of other header lines Alvestrand Expires Jan 96 [Page 2] draft MID and CID URLs July 95 (3) Addition of "Resent-*" headers (4) Addition/subtraction of other non-standard headers like "X- Listproc-version", "Old-Received" or "PP-Warning" (5) Changes of content-transfer-encoding for MIME messages (6) Changes of wrapping for multiline headers An object is still considered the same object after undergoing these changes. The following changes may arise because of errors or misfeatures that are known to occur in Internet mailers, but represent erroneous representations of the message: (1) Changes to, addition of or removal of standard headers like "To:", "Subject:" or "Content-type:" (2) Substituting tabs for spaces or vice versa (3) Adding or deleting blank lines at the end of the message (4) Breaking of lines without using a MIME content-transfer- encoding 2.3. Resolution No specific resolution mechanism is defined by this document. Possible resolution mechanisms include: (1) Searching through a database of MIDs for messages seen at this UA (2) Searching publicly accessible message archives for messages with this MID (3) Sending mail to the author of the referencing document to ask which message he intended to point to Alvestrand Expires Jan 96 [Page 3] draft MID and CID URLs July 95 3. The Content-ID UR? 3.1. Syntax cidref = "cid:" content-id where content-ID is imported from RFC 1541 (MIME). Percent encoding must be used when the cid is used in a protocol that does not allow the full set of CID characters. 3.2. The identified object The CID references a MIME entity, consisting of headers and body. The following changes can be applied to a CID-referenced object without considering the object to be different: (1) Change of content-transfer-encoding, including recoding of quoted-printable (2) Addition or deletion of headers that do not begin with "content-"; this is necessary to allow the existence of two messages with the same content-id, but with different message headers (These should naturally have different message-ids) 3.3. Resolution The same resolution mechanisms as for message-ids can be applied to cids. 4. Security considerations Security issues are not consiered in this memo. 5. REFERENCES Alvestrand Expires Jan 96 [Page 4] draft MID and CID URLs July 95 [DUMMY REFERENCE] Here is the title of the reference Alvestrand Expires Jan 96 [Page 5] ------- =_aaaaaaaaaa0--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08946; 24 Jul 95 10:25 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08942; 24 Jul 95 10:25 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa10403; 24 Jul 95 10:25 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id JAA17474 for ietf-822-list; Mon, 24 Jul 1995 09:55:56 -0400 Received: from warren.banyan.com (warren.banyan.com [131.100.182.40]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id JAA17471 for ; Mon, 24 Jul 1995 09:55:54 -0400 Received: from kilsythe.banyan.com by warren.banyan.com with SMTP (1.38.193.4/16.2) id AA22427; Mon, 24 Jul 1995 10:02:19 -0400 Received: from aberdeen.banyan.com by kilsythe.banyan.com (5.0/SMI-SVR4) id AA11799; Mon, 24 Jul 1995 09:56:53 +0500 Received: by aberdeen.banyan.com (5.0/SMI-SVR4) id AA04191; Mon, 24 Jul 1995 10:01:01 +0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Terry Crowley Message-Id: In-Reply-To: <01HT7FU4EXI08ZFTD0@INNOSOFT.COM> Reply-To: Terry Crowley Date: Mon, 24 Jul 1995 10:01:00 -0500 Subject: Re: Multipart/Alternative Compatibility Issue To: Ned Freed Cc: ietf-822@dimacs.rutgers.edu Content-Length: 4243 >> It depends on what you mean by "bad". ("Imagine every atom in your body >> exploding at the speed of light...OK, good safety tip, don't cross the >> beams.") OK, not that bad if you get one of these messages every couple days, >> but imagine you have 150 messages in your inbox, every one of which requires >> that you go through this multi-step process just to look at what might be a >> two sentence message. I think that's worse than bad, that's horrible. And I >> can guarantee it would be sufficient to be a deal-breaker in many cases. I'm >> sure you're familiar enough with the commercial market to know that pointing >> fingers and saying "it's their fault!" doesn't get you very far with a >> customer who just wants things to work. > Say what? What you've effectively done here is argue against your own chosen > approach! You're the one that has chosen to package multipart/alternative as > multipart/mixed, not me! > By packaging things as multipart/mixed instead of using multipart/alternative > properly you guarantee that everyone with a *compliant* MIME agent has to go > through the very process you deplore. Were you to choose to package things > properly you would only have this problem with clients that treat > multipart/alternative as multipart/mixed, and no choice you make is going to > fix this behavior, so you'd best stop trying. Hmm, well this conversation is definitely resulting in diminishing returns, but I'll try to clarify one point and keep it short. I haven't argued against my approach. The painful process described above results from multipart/alternative embedded in multipart/mixed. If multipart/mixed is sent alone, then the text shows up right where it should, the problem is that this "useless" attachment, which can be ignored, also shows up. The reader of the message is forced to look upon an attachment indicator, but doesn't need to take any extra steps to actually see the message body. Perhaps we should attempt to shed some light on this topic. How about some reports from the field about how different clients are actually handling multipart/alternative. Does your client force you to make an explicit choice about which alternative you want to see on every multipart/alternative message you receive or do you configure it once? Does it treat multipart/alternative as multipart/mixed? If the message contains a nested hierarchy, are you forced to go through a two-step interaction to see embedded elements? Maybe I'm not getting my real point across. From a UI perspective, multipart/alternative and nested hierarchies are difficult to handle in a real clean way. I'd say virtually every mail client that's being modified to handle MIME started off with no model of alternative content or of hierarchical structure. Therefore, the MIME implementor needs to make a choice about how to handle it. By far the simplest approach is to just treat mp/alternative as mp/mixed. Another approach is to query the user, but I consider that a total mistake. The best approach is to make a choice based on configuration information, perhaps provide some subtle indication that a choice was made, and then provide a way for the user to examine the choices and possibly make a different one explicitly. I haven't seen any system that actually does this (Slate came close, but it wasn't always completely clear what part of the document the alternatives were tied to.) Making these decisions consistently across clients is critical to interoperability. As an analogy, look at the issue of line lengths. Everyone's read those virtually unreadable messages from someone writing in a window that lets them put 85 characters on a line. Sure its 822 compliant, but that doesn't make it easy to read. Anyone want to add some case histories to this discussion? One example: A side conversation with Ray Langford from Frontier Technologies indicates that their SuperTCP mail client flattens hierarchy and treats mp/alternative as mp/mixed. It also treats the first inline text part as the message body that is presented to the user. The result of these choices is that both our encodings result in the same appearance to the user. Terry   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09490; 24 Jul 95 11:29 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09486; 24 Jul 95 11:29 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa12685; 24 Jul 95 11:29 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id KAA17580 for ietf-822-list; Mon, 24 Jul 1995 10:02:26 -0400 Received: from HUGBOX.SZTAKI.HU (hugbox.sztaki.hu [192.84.225.6]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id KAA17568 for ; Mon, 24 Jul 1995 10:01:16 -0400 Date: Mon, 24 Jul 1995 10:01:16 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mailgate@frodo.tii.matav.hu Message-Id: <199507241401.KAA17568@dimacs.rutgers.edu> Received: from htmvax.tii.matav.hu ([145.236.48.3]) by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 16:02:23 gmt+2 Received: from frodo.tii.matav.hu by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 16:00:46 MET_DST Subject: Mail delivery error Apparently-To: Note: This message was generated automagically. An error was detected, while processing the enclosed message. --> Error description: No such local user --> Error for: drums@cs.utk.edu,ietf-822@dimacs.rutgers.edu,uri@bunyip.com Returned mail follows. --------------------------------- X-Envelope-To: gyurik@frodo.tii.matav.hu Return-Path: Received: from htmvax.tii.matav.hu ([145.236.48.3]) by frodo.tii.matav.hu (SMTPSRV); Mon 24 Jul 1995 15:21 Received: from HUGBOX.SZTAKI.HU by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 11:05:58 MET_DST Received: from dimacs.rutgers.edu by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 11:07:15 gmt+2 Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id DAA15178 for ietf-822-list; Mon, 24 Jul 1995 03:19:53 -0400 Received: from domen.uninett.no (domen.uninett.no [129.241.131.10]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id DAA15175 for ; Mon, 24 Jul 1995 03:19:51 -0400 Received: from troms2.or.uninett.no by domen.uninett.no with SMTP (PP) id <25021-0@domen.uninett.no>; Mon, 24 Jul 1995 09:18:59 +0200 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.9) with ESMTP id WAA00170; Sun, 23 Jul 1995 22:08:53 +0200 Message-ID: <199507232008.WAA00170@dale.uninett.no> From: Harald.T.Alvestrand@uninett.no To: drums@cs.utk.edu, ietf-822@dimacs.rutgers.edu, uri@bunyip.com Subject: An idea for MID and CID URsomethings Reply-To: drums@cs.utk.edu MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <166.806530098.0@dale.uninett.no> Date: Sun, 23 Jul 1995 22:08:52 +0200 Sender: hta@dale.uninett.no ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <166.806530098.1@dale.uninett.no> I talked to some people briefly about this during IETF. Since it points out some problems with "what does an ID identify" in both MIME and RFC 822, I think "drums" may be a nice "home list" to discuss it on; I've set reply-to accordingly. I don't know whether it is either best or appropriate for me to continue editing this; does anyone feel like taking responsibility? (Ed Levinson had a previous document on CID URLs, but I've lost my copy of it, and he seems to have shelved the idea for the moment) Comments? Harald A ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <166.806530098.2@dale.uninett.no> draft MID and CID URLs July 95 Message-ID and Content-ID URLs Sun Jul 23 19:16:56 MET DST 1995 Harald Tveit Alvestrand UNINETT Harald.T.Alvestrand@uninett.no Status of this Memo This document specifies two classes of URsomethings, MID and CID. The intention is to allow reference to messages and message components using a syntax that looks much like that used for URLs in the Web. This draft document is being circulated for comment. Please send comments to the author, or to..... The following text is required by the Internet-draft rules: This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. The file name of this version is draft-alvestrand-not-submitted- at-all.txt Alvestrand Expires Jan 96 [Page 1] draft MID and CID URLs July 95 1. Introduction When writing information resources, it would sometimes be nice to have a reasonably unique way of referring to mail and news messages. In some cases, like when you are sending a message coded in HTML, it is also nice to be able to refer to parts of a message by content-id. These references are not Uniform Resource Locators, since they do not encode the location of their objects, neither are they Uniform Resource Names, since they do not fulfil all requirements of RFC 1737; for lack of a better idea, I call them Reasonably Unique Identifying Names; this term obviously does not have a four-letter abbreviation. 2. The Message-ID UR? 2.1. Syntax The syntax of the message-ID locator is mid = "mid:" message-id where message-id is imported from STD 12, "Internet Mail", RFC 822. When it is used in protocols which do not allow the full character set of RFC 822, it must be encoded using the %-convention. 2.2. The identified object The message-ID locator resolves to an Internet message. This identifies a message header and a message body conformant to RFC 822 and (possibly) MIME; due to the history of Internet messages, the following differences must be expected between different copies of the same message: (1) Variable number of "Received:" lines in the header (2) Randomized order of other header lines Alvestrand Expires Jan 96 [Page 2] draft MID and CID URLs July 95 (3) Addition of "Resent-*" headers (4) Addition/subtraction of other non-standard headers like "X- Listproc-version", "Old-Received" or "PP-Warning" (5) Changes of content-transfer-encoding for MIME messages (6) Changes of wrapping for multiline headers An object is still considered the same object after undergoing these changes. The following changes may arise because of errors or misfeatures that are known to occur in Internet mailers, but represent erroneous representations of the message: (1) Changes to, addition of or removal of standard headers like "To:", "Subject:" or "Content-type:" (2) Substituting tabs for spaces or vice versa (3) Adding or deleting blank lines at the end of the message (4) Breaking of lines without using a MIME content-transfer- encoding 2.3. Resolution No specific resolution mechanism is defined by this document. Possible resolution mechanisms include: (1) Searching through a database of MIDs for messages seen at this UA (2) Searching publicly accessible message archives for messages with this MID (3) Sending mail to the author of the referencing document to ask which message he intended to point to Alvestrand Expires Jan 96 [Page 3] draft MID and CID URLs July 95 3. The Content-ID UR? 3.1. Syntax cidref = "cid:" content-id where content-ID is imported from RFC 1541 (MIME). Percent encoding must be used when the cid is used in a protocol that does not allow the full set of CID characters. 3.2. The identified object The CID references a MIME entity, consisting of headers and body. The following changes can be applied to a CID-referenced object without considering the object to be different: (1) Change of content-transfer-encoding, including recoding of quoted-printable (2) Addition or deletion of headers that do not begin with "content-"; this is necessary to allow the existence of two messages with the same content-id, but with different message headers (These should naturally have different message-ids) 3.3. Resolution The same resolution mechanisms as for message-ids can be applied to cids. 4. Security considerations Security issues are not consiered in this memo. 5. REFERENCES Alvestrand Expires Jan 96 [Page 4] draft MID and CID URLs July 95 [DUMMY REFERENCE] Here is the title of the reference Alvestrand Expires Jan 96 [Page 5] ------- =_aaaaaaaaaa0-- From owner-winnews@microsoft.nwnet.com Mon 24 Jul 1995 16:09   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10979; 24 Jul 95 14:27 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10975; 24 Jul 95 14:27 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa16351; 24 Jul 95 14:27 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id NAA26236 for ietf-822-list; Mon, 24 Jul 1995 13:52:35 -0400 Received: from smi.Stanford.EDU (root@SMI.Stanford.EDU [171.65.32.101]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id NAA26233 for ; Mon, 24 Jul 1995 13:52:32 -0400 Received: from ssrg-ss2-2.Stanford.EDU (mtm@ssrg-ss2-2.Stanford.EDU [171.65.32.100]) by smi.Stanford.EDU (8.6.10/8.6.10) with SMTP id KAA05395; Mon, 24 Jul 1995 10:31:18 -0700 Date: Mon, 24 Jul 1995 10:39:07 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mike Macgirvin X-Orig-Sender: mtm@ssrg-ss2-2.stanford.edu Reply-To: Mike Macgirvin Subject: Re: Multipart/Alternative Compatibility Issue To: Terry Crowley cc: Ned Freed , ietf-822@dimacs.rutgers.edu In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 > How about some reports from the field about how different clients are > actually handling multipart/alternative. Does your client force you > to make an explicit choice about which alternative you want to see on > every multipart/alternative message you receive or do you configure it > once? Does it treat multipart/alternative as multipart/mixed? If the > message contains a nested hierarchy, are you forced to go through a > two-step interaction to see embedded elements? OK, I'll bite. From a user perspective, my client (ML) acts pretty much the same as the Frontier Technologies example. The part hierarchy is "flattened" into a linear list but with indentation to display the hierarchy. If the first "child" of the top-level multipart is text, it's presented. The user has random access to any individual part without negotiating hierearchy. (message/rfc822 is an exception because I display it recursively). I make no distinction between multipart/mixed and multipart/foobar. They're just folders. As you noted, this is an artifact of evolution. Future evolution will see some parsing of the subtype, with special handling of parallel as the only thing planned currently. These discussions might affect that evolution. As a real world example, let's say I've got a mp/alternative with two components, message/external-body and message/external-body, where the subtypes are further broken down into access=mail-server and access=anon-ftp. (Look familiar?) What is the "preferred" access method? I handle both of them. The answer is "it depends". Sometimes I want the message directed at my mailbox so it doesn't get lost in my filespace. Sometimes, I want the results _right now_ and don't want to wait for a mail responder. Throwing in an automated "decider" is going to result in the wrong choice half the time. Now let's say I've got another message, with text/plain and app/postscript parts. The ps version is probably going to be prettier. So do I make that choice automatically for somebody? In this case my client defers the ps file to an external handler. That handler might be a printer, it might be ghostview, and it might be decided at invocation (yes, this is a choice too). You would think that ps would be the preferred embodiment, but this might be a "sensitive" message, and if a printer is the default destination, the person might not want it going there. OK, they have a choice of outputs, no big deal. Oh, but ghostview isn't running on this machine. It's either printer or save-to-file. What now? The user has to go through a couple of steps to cancel the "external viewer" and also the resulting "save-to-file" query. Maybe that's a bad design for me, but that's how it is today. All they really wanted to do was have a quick look at the message. THEY wanted the text part, and have to jump through hoops to get it. Next example, same document. The text version is a few kbytes. The ps version has graphics, is several megabytes, and we're connected over a slip line from home. Here again, a printer default could be devastating if it's directed at an office printer. But downloading the ps file to display locally could take an hour or two. If we were at work, we'd want the ps version. At home, it's out of the question. All of this is a long way of justifying my current implementation, which is to let the user decide which embodiment they want. But this is all a design philosophy. Many designers regard users as incompetent to make choices, and unable to handle complexity. In some markets that's the prudent design. But it locks you out of markets where folks don't like to be spoon-fed. My audience is generally a bit more sophisticated and I _try_ to let them make decisions which I feel aren't absolutely clear cut. The challenge for me is to present the choices in a meaningful way. mike PS> I *do* lock the compose window at 80 columns, and get a never ending string of complaints from my "sophisticated audience" that it can't be resized. To me it's not an option. It's the law. I guess this points out that no matter what you do, you can't please everybody.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11858; 24 Jul 95 16:19 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11854; 24 Jul 95 16:19 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa01792; 24 Jul 95 16:19 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id OAA26785 for ietf-822-list; Mon, 24 Jul 1995 14:27:17 -0400 Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id OAA26782 for ; Mon, 24 Jul 1995 14:27:12 -0400 Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.0-4 #2001) id <01HT7VI6UHCW8ZDVGG@INNOSOFT.COM>; Mon, 24 Jul 1995 10:56:02 -0700 (PDT) Date: Mon, 24 Jul 1995 10:18:37 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ned Freed Subject: Re: Multipart/Alternative Compatibility Issue In-reply-to: "Your message dated Mon, 24 Jul 1995 10:01:00 -0500" To: tcrowley@kilsythe.banyan.com Cc: ietf-822@dimacs.rutgers.edu Message-id: <01HT8V47KLVC8ZDVGG@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT References: <01HT7FU4EXI08ZFTD0@INNOSOFT.COM> > Hmm, well this conversation is definitely resulting in diminishing returns, > but I'll try to clarify one point and keep it short. I haven't argued against > my approach. The painful process described above results from > multipart/alternative embedded in multipart/mixed. If multipart/mixed is sent > alone, then the text shows up right where it should, the problem is that this > "useless" attachment, which can be ignored, also shows up. The reader of the > message is forced to look upon an attachment indicator, but doesn't need to > take any extra steps to actually see the message body. Perhaps you don't see this as arguing against your own approach, but I most certainly do. You apparently have a problem with one client's handling of multipart/alternative, so instead of dealing with that clients problem somehow you use a structure that is very suboptimal on compliant clients. For me the question boils down to whether you do something that's really bad for one or something that's somewhat bad for everyone. You have chosen the latter. I would choose the former. > Perhaps we should attempt to shed some light on this topic. How about some > reports from the field about how different clients are actually handling > multipart/alternative. Does your client force you to make an explicit choice > about which alternative you want to see on every multipart/alternative message > you receive or do you configure it once? Does it treat multipart/alternative > as multipart/mixed? If the message contains a nested hierarchy, are you > forced to go through a two-step interaction to see embedded elements? My experience has been that most clients handle such things tolerably -- they either handle multipart/alternative correctly or else they flatten everything so that your two approaches are equivalent. > Maybe I'm not getting my real point across. From a UI perspective, > multipart/alternative and nested hierarchies are difficult to handle in a real > clean way. On the contrary, since proper handling of multipart/alternative effectively eliminates the heirarchy, none of these presentation issues arise. If they do arise there's something wrong with multipart/alternative handling. Let me put this another way. If what you're arguing for is that if a client cannot handle multipart/alternative, it should at least flatten out the structure around it to prevent even more problems, I would tend to agree. But all the standards can do is define compliance -- the behavior of incompliant software (and support for multipart/alternative *is* required). > I'd say virtually every mail client that's being modified to > handle MIME started off with no model of alternative content or of > hierarchical structure. Depends on how the mods are done. If MetaMail is used as a basis for the mods (and it often is) you end up with alternative handling from the beginning. > Therefore, the MIME implementor needs to make a > choice about how to handle it. By far the simplest approach is to just treat > mp/alternative as mp/mixed. Another approach is to query the user, but I > consider that a total mistake. The best approach is to make a choice based on > configuration information, perhaps provide some subtle indication that a > choice was made, and then provide a way for the user to examine the choices > and possibly make a different one explicitly. I haven't seen any system that > actually does this (Slate came close, but it wasn't always completely clear > what part of the document the alternatives were tied to.) The first MIME client that was released, MetaMail, seems to handle this just fine. And MetaMail works with practically every existing user agent around. Oddly enough, the one thing MetaMail doesn't do well is default to handling unknown subtypes of multipart as mixed! > Making these decisions consistently across clients is critical to > interoperability. As an analogy, look at the issue of line lengths. > Everyone's read those virtually unreadable messages from someone writing in a > window that lets them put 85 characters on a line. Sure its 822 compliant, > but that doesn't make it easy to read. > Anyone want to add some case histories to this discussion? > One example: A side conversation with Ray Langford from Frontier Technologies > indicates that their SuperTCP mail client flattens hierarchy and treats > mp/alternative as mp/mixed. It also treats the first inline text part as the > message body that is presented to the user. The result of these choices is > that both our encodings result in the same appearance to the user. But in this case it doesn't matter which of your two approaches you use. Its a no-win situation either way. If anything this demonstrates a preference for multipart/alternative -- you lose nothing by using it now, but should Frontier ever fix their agent old messages will then be handled properly. Ned   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12769; 24 Jul 95 17:43 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12765; 24 Jul 95 17:43 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa04267; 24 Jul 95 17:43 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id PAA27762 for ietf-822-list; Mon, 24 Jul 1995 15:34:15 -0400 Received: from HUGBOX.SZTAKI.HU (hugbox.sztaki.hu [192.84.225.6]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id PAA27755 for ; Mon, 24 Jul 1995 15:33:52 -0400 Date: Mon, 24 Jul 1995 15:33:52 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mailgate@frodo.tii.matav.hu Message-Id: <199507241933.PAA27755@dimacs.rutgers.edu> Received: from htmvax.tii.matav.hu ([145.236.48.3]) by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 21:34:09 gmt+2 Received: from frodo.tii.matav.hu by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 21:01:33 MET_DST Subject: Mail delivery error Apparently-To: Note: This message was generated automagically. An error was detected, while processing the enclosed message. --> Error description: No such local user --> Error for: NED@innosoft.com Returned mail follows. --------------------------------- X-Envelope-To: gyurik@frodo.tii.matav.hu Return-Path: Received: from htmvax.tii.matav.hu ([145.236.48.3]) by frodo.tii.matav.hu (SMTPSRV); Mon 24 Jul 1995 20:57 Received: from HUGBOX.SZTAKI.HU ([192.84.225.6]) by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 17:07:02 MET_DST Received: from dimacs.rutgers.edu by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 17:08:12 gmt+2 Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id JAA17474 for ietf-822-list; Mon, 24 Jul 1995 09:55:56 -0400 Received: from warren.banyan.com (warren.banyan.com [131.100.182.40]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id JAA17471 for ; Mon, 24 Jul 1995 09:55:54 -0400 Received: from kilsythe.banyan.com by warren.banyan.com with SMTP (1.38.193.4/16.2) id AA22427; Mon, 24 Jul 1995 10:02:19 -0400 Received: from aberdeen.banyan.com by kilsythe.banyan.com (5.0/SMI-SVR4) id AA11799; Mon, 24 Jul 1995 09:56:53 +0500 Received: by aberdeen.banyan.com (5.0/SMI-SVR4) id AA04191; Mon, 24 Jul 1995 10:01:01 +0500 From: tcrowley@kilsythe.banyan.com (Terry Crowley) Message-ID: In-Reply-To: <01HT7FU4EXI08ZFTD0@INNOSOFT.COM> Reply-To: Terry Crowley Date: Mon, 24 Jul 1995 10:01:00 -0500 Subject: Re: Multipart/Alternative Compatibility Issue To: Ned Freed CC: ietf-822@dimacs.rutgers.edu Content-Length: 4243 >> It depends on what you mean by "bad". ("Imagine every atom in your body >> exploding at the speed of light...OK, good safety tip, don't cross the >> beams.") OK, not that bad if you get one of these messages every couple days, >> but imagine you have 150 messages in your inbox, every one of which requires >> that you go through this multi-step process just to look at what might be a >> two sentence message. I think that's worse than bad, that's horrible. And I >> can guarantee it would be sufficient to be a deal-breaker in many cases. I'm >> sure you're familiar enough with the commercial market to know that pointing >> fingers and saying "it's their fault!" doesn't get you very far with a >> customer who just wants things to work. > Say what? What you've effectively done here is argue against your own chosen > approach! You're the one that has chosen to package multipart/alternative as > multipart/mixed, not me! > By packaging things as multipart/mixed instead of using multipart/alternative > properly you guarantee that everyone with a *compliant* MIME agent has to go > through the very process you deplore. Were you to choose to package things > properly you would only have this problem with clients that treat > multipart/alternative as multipart/mixed, and no choice you make is going to > fix this behavior, so you'd best stop trying. Hmm, well this conversation is definitely resulting in diminishing returns, but I'll try to clarify one point and keep it short. I haven't argued against my approach. The painful process described above results from multipart/alternative embedded in multipart/mixed. If multipart/mixed is sent alone, then the text shows up right where it should, the problem is that this "useless" attachment, which can be ignored, also shows up. The reader of the message is forced to look upon an attachment indicator, but doesn't need to take any extra steps to actually see the message body. Perhaps we should attempt to shed some light on this topic. How about some reports from the field about how different clients are actually handling multipart/alternative. Does your client force you to make an explicit choice about which alternative you want to see on every multipart/alternative message you receive or do you configure it once? Does it treat multipart/alternative as multipart/mixed? If the message contains a nested hierarchy, are you forced to go through a two-step interaction to see embedded elements? Maybe I'm not getting my real point across. From a UI perspective, multipart/alternative and nested hierarchies are difficult to handle in a real clean way. I'd say virtually every mail client that's being modified to handle MIME started off with no model of alternative content or of hierarchical structure. Therefore, the MIME implementor needs to make a choice about how to handle it. By far the simplest approach is to just treat mp/alternative as mp/mixed. Another approach is to query the user, but I consider that a total mistake. The best approach is to make a choice based on configuration information, perhaps provide some subtle indication that a choice was made, and then provide a way for the user to examine the choices and possibly make a different one explicitly. I haven't seen any system that actually does this (Slate came close, but it wasn't always completely clear what part of the document the alternatives were tied to.) Making these decisions consistently across clients is critical to interoperability. As an analogy, look at the issue of line lengths. Everyone's read those virtually unreadable messages from someone writing in a window that lets them put 85 characters on a line. Sure its 822 compliant, but that doesn't make it easy to read. Anyone want to add some case histories to this discussion? One example: A side conversation with Ray Langford from Frontier Technologies indicates that their SuperTCP mail client flattens hierarchy and treats mp/alternative as mp/mixed. It also treats the first inline text part as the message body that is presented to the user. The result of these choices is that both our encodings result in the same appearance to the user. Terry   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13696; 24 Jul 95 19:26 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13692; 24 Jul 95 19:26 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa06091; 24 Jul 95 19:26 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id PAA27752 for ietf-822-list; Mon, 24 Jul 1995 15:33:31 -0400 Received: from HUGBOX.SZTAKI.HU (hugbox.sztaki.hu [192.84.225.6]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id PAA27748 for ; Mon, 24 Jul 1995 15:33:21 -0400 Date: Mon, 24 Jul 1995 15:33:21 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mailgate@frodo.tii.matav.hu Message-Id: <199507241933.PAA27748@dimacs.rutgers.edu> Received: from htmvax.tii.matav.hu ([145.236.48.3]) by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 21:34:15 gmt+2 Received: from frodo.tii.matav.hu by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 21:01:39 MET_DST Subject: Mail delivery error Apparently-To: Note: This message was generated automagically. An error was detected, while processing the enclosed message. --> Error description: No such local user --> Error for: ietf-822@dimacs.rutgers.edu Returned mail follows. --------------------------------- X-Envelope-To: gyurik@frodo.tii.matav.hu Return-Path: Received: from htmvax.tii.matav.hu ([145.236.48.3]) by frodo.tii.matav.hu (SMTPSRV); Mon 24 Jul 1995 20:57 Received: from HUGBOX.SZTAKI.HU ([192.84.225.6]) by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 17:07:02 MET_DST Received: from dimacs.rutgers.edu by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 17:08:12 gmt+2 Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id JAA17474 for ietf-822-list; Mon, 24 Jul 1995 09:55:56 -0400 Received: from warren.banyan.com (warren.banyan.com [131.100.182.40]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id JAA17471 for ; Mon, 24 Jul 1995 09:55:54 -0400 Received: from kilsythe.banyan.com by warren.banyan.com with SMTP (1.38.193.4/16.2) id AA22427; Mon, 24 Jul 1995 10:02:19 -0400 Received: from aberdeen.banyan.com by kilsythe.banyan.com (5.0/SMI-SVR4) id AA11799; Mon, 24 Jul 1995 09:56:53 +0500 Received: by aberdeen.banyan.com (5.0/SMI-SVR4) id AA04191; Mon, 24 Jul 1995 10:01:01 +0500 From: tcrowley@kilsythe.banyan.com (Terry Crowley) Message-ID: In-Reply-To: <01HT7FU4EXI08ZFTD0@INNOSOFT.COM> Reply-To: Terry Crowley Date: Mon, 24 Jul 1995 10:01:00 -0500 Subject: Re: Multipart/Alternative Compatibility Issue To: Ned Freed CC: ietf-822@dimacs.rutgers.edu Content-Length: 4243 >> It depends on what you mean by "bad". ("Imagine every atom in your body >> exploding at the speed of light...OK, good safety tip, don't cross the >> beams.") OK, not that bad if you get one of these messages every couple days, >> but imagine you have 150 messages in your inbox, every one of which requires >> that you go through this multi-step process just to look at what might be a >> two sentence message. I think that's worse than bad, that's horrible. And I >> can guarantee it would be sufficient to be a deal-breaker in many cases. I'm >> sure you're familiar enough with the commercial market to know that pointing >> fingers and saying "it's their fault!" doesn't get you very far with a >> customer who just wants things to work. > Say what? What you've effectively done here is argue against your own chosen > approach! You're the one that has chosen to package multipart/alternative as > multipart/mixed, not me! > By packaging things as multipart/mixed instead of using multipart/alternative > properly you guarantee that everyone with a *compliant* MIME agent has to go > through the very process you deplore. Were you to choose to package things > properly you would only have this problem with clients that treat > multipart/alternative as multipart/mixed, and no choice you make is going to > fix this behavior, so you'd best stop trying. Hmm, well this conversation is definitely resulting in diminishing returns, but I'll try to clarify one point and keep it short. I haven't argued against my approach. The painful process described above results from multipart/alternative embedded in multipart/mixed. If multipart/mixed is sent alone, then the text shows up right where it should, the problem is that this "useless" attachment, which can be ignored, also shows up. The reader of the message is forced to look upon an attachment indicator, but doesn't need to take any extra steps to actually see the message body. Perhaps we should attempt to shed some light on this topic. How about some reports from the field about how different clients are actually handling multipart/alternative. Does your client force you to make an explicit choice about which alternative you want to see on every multipart/alternative message you receive or do you configure it once? Does it treat multipart/alternative as multipart/mixed? If the message contains a nested hierarchy, are you forced to go through a two-step interaction to see embedded elements? Maybe I'm not getting my real point across. From a UI perspective, multipart/alternative and nested hierarchies are difficult to handle in a real clean way. I'd say virtually every mail client that's being modified to handle MIME started off with no model of alternative content or of hierarchical structure. Therefore, the MIME implementor needs to make a choice about how to handle it. By far the simplest approach is to just treat mp/alternative as mp/mixed. Another approach is to query the user, but I consider that a total mistake. The best approach is to make a choice based on configuration information, perhaps provide some subtle indication that a choice was made, and then provide a way for the user to examine the choices and possibly make a different one explicitly. I haven't seen any system that actually does this (Slate came close, but it wasn't always completely clear what part of the document the alternatives were tied to.) Making these decisions consistently across clients is critical to interoperability. As an analogy, look at the issue of line lengths. Everyone's read those virtually unreadable messages from someone writing in a window that lets them put 85 characters on a line. Sure its 822 compliant, but that doesn't make it easy to read. Anyone want to add some case histories to this discussion? One example: A side conversation with Ray Langford from Frontier Technologies indicates that their SuperTCP mail client flattens hierarchy and treats mp/alternative as mp/mixed. It also treats the first inline text part as the message body that is presented to the user. The result of these choices is that both our encodings result in the same appearance to the user. Terry   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04935; 25 Jul 95 0:16 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04931; 25 Jul 95 0:16 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa01561; 25 Jul 95 0:16 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id XAA06554 for ietf-822-list; Mon, 24 Jul 1995 23:34:56 -0400 Received: from ns.frontiertech.com (root@ns.frontiertech.com [192.104.32.5]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id XAA06551 for ; Mon, 24 Jul 1995 23:34:55 -0400 Received: by FrontierTech.COM (8.6.9/8.6.9) with SMTP id WAA11301; Mon, 24 Jul 1995 22:29:32 -0500 X-Mailer: SuperTCP Pro for Windows Version 1.1 (Mailer Version 1.02) Message-ID: <3014655A-00000001@rock105.FrontierTech.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ray Langford Date: Mon, 24 Jul 1995 22:30:33 cdt Subject: Re: Multipart/Alternative Compatibility Issue To: Terry Crowley , Ned Freed Cc: ietf-822@dimacs.rutgers.edu Reply-To: Ray@frontiertech.com MIME-Version: 1.0 Content-Type: Text/Plain; Charset=US-ASCII >One example: A side conversation with Ray Langford from Frontier >Technologies indicates that their SuperTCP mail client flattens hierarchy >and treats mp/alternative as mp/mixed. It also treats the first inline >text part as the message body that is presented to the user. The result >of these choices is that both our encodings result in the same appearance >to the user. > >Terry Yes, this is the way our Email works. We chose to do this because our mail system is MAPI compliant. The MAPI structures define a notetext and flat (no hierarchy) attachments. We currently treat a MIME message as an equal collection of parts (attachments) and attempt to find a notetext (the first text part). I agree that mp/alternative could be handled better by only keeping and showing one alternative (of the users choice through configuration) but there are a number of reasons why this could be problematic in our current MAPI compliant mail system. We are looking into this and also Content-Disposition as ways to address these issues. However, in retrospect, SuperTCP MIME Email has been shipping now for over 21/2 years (over 200,000 copies) and we haven't received a single complaint about how we handle mp/alternative :-). I also don't think that there are many people (programs) that create mp/alternative messages... yet :-). [Sorry to readers if I have wandered too far off the topic (I am on vacation and actually have time to read and respond to the list).] ======================================== Ray C. Langford Engineering Manager, Advanced Products Frontier Technologies Corp. Email: Ray@FrontierTech.com Voice: (414) 241-4555 x205 ========================================   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05182; 25 Jul 95 1:18 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05178; 25 Jul 95 1:18 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa02511; 25 Jul 95 1:18 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id XAA06470 for ietf-822-list; Mon, 24 Jul 1995 23:11:54 -0400 Received: from HUGBOX.SZTAKI.HU (hugbox.sztaki.hu [192.84.225.6]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id XAA06467 for ; Mon, 24 Jul 1995 23:11:51 -0400 Date: Mon, 24 Jul 1995 23:11:51 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mailgate@frodo.tii.matav.hu Message-Id: <199507250311.XAA06467@dimacs.rutgers.edu> Received: from htmvax.tii.matav.hu ([145.236.48.3]) by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Tue, 25 Jul 1995 05:12:16 gmt+2 Received: from frodo.tii.matav.hu by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Tue, 25 Jul 1995 05:04:22 MET_DST Subject: Mail delivery error Apparently-To: Note: This message was generated automagically. An error was detected, while processing the enclosed message. --> Error description: No such local user --> Error for: drums@cs.utk.edu,ietf-822@dimacs.rutgers.edu,uri@bunyip.com Returned mail follows. --------------------------------- X-Envelope-To: gyurik@frodo.tii.matav.hu Return-Path: Received: from htmvax.tii.matav.hu ([145.236.48.3]) by frodo.tii.matav.hu (SMTPSRV); Tue 25 Jul 1995 04:50 Received: from HUGBOX.SZTAKI.HU by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 11:05:58 MET_DST Received: from dimacs.rutgers.edu by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 11:07:15 gmt+2 Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id DAA15178 for ietf-822-list; Mon, 24 Jul 1995 03:19:53 -0400 Received: from domen.uninett.no (domen.uninett.no [129.241.131.10]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id DAA15175 for ; Mon, 24 Jul 1995 03:19:51 -0400 Received: from troms2.or.uninett.no by domen.uninett.no with SMTP (PP) id <25021-0@domen.uninett.no>; Mon, 24 Jul 1995 09:18:59 +0200 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.9) with ESMTP id WAA00170; Sun, 23 Jul 1995 22:08:53 +0200 Message-ID: <199507232008.WAA00170@dale.uninett.no> From: Harald.T.Alvestrand@uninett.no To: drums@cs.utk.edu, ietf-822@dimacs.rutgers.edu, uri@bunyip.com Subject: An idea for MID and CID URsomethings Reply-To: drums@cs.utk.edu MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <166.806530098.0@dale.uninett.no> Date: Sun, 23 Jul 1995 22:08:52 +0200 Sender: hta@dale.uninett.no ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <166.806530098.1@dale.uninett.no> I talked to some people briefly about this during IETF. Since it points out some problems with "what does an ID identify" in both MIME and RFC 822, I think "drums" may be a nice "home list" to discuss it on; I've set reply-to accordingly. I don't know whether it is either best or appropriate for me to continue editing this; does anyone feel like taking responsibility? (Ed Levinson had a previous document on CID URLs, but I've lost my copy of it, and he seems to have shelved the idea for the moment) Comments? Harald A ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <166.806530098.2@dale.uninett.no> draft MID and CID URLs July 95 Message-ID and Content-ID URLs Sun Jul 23 19:16:56 MET DST 1995 Harald Tveit Alvestrand UNINETT Harald.T.Alvestrand@uninett.no Status of this Memo This document specifies two classes of URsomethings, MID and CID. The intention is to allow reference to messages and message components using a syntax that looks much like that used for URLs in the Web. This draft document is being circulated for comment. Please send comments to the author, or to..... The following text is required by the Internet-draft rules: This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. The file name of this version is draft-alvestrand-not-submitted- at-all.txt Alvestrand Expires Jan 96 [Page 1] draft MID and CID URLs July 95 1. Introduction When writing information resources, it would sometimes be nice to have a reasonably unique way of referring to mail and news messages. In some cases, like when you are sending a message coded in HTML, it is also nice to be able to refer to parts of a message by content-id. These references are not Uniform Resource Locators, since they do not encode the location of their objects, neither are they Uniform Resource Names, since they do not fulfil all requirements of RFC 1737; for lack of a better idea, I call them Reasonably Unique Identifying Names; this term obviously does not have a four-letter abbreviation. 2. The Message-ID UR? 2.1. Syntax The syntax of the message-ID locator is mid = "mid:" message-id where message-id is imported from STD 12, "Internet Mail", RFC 822. When it is used in protocols which do not allow the full character set of RFC 822, it must be encoded using the %-convention. 2.2. The identified object The message-ID locator resolves to an Internet message. This identifies a message header and a message body conformant to RFC 822 and (possibly) MIME; due to the history of Internet messages, the following differences must be expected between different copies of the same message: (1) Variable number of "Received:" lines in the header (2) Randomized order of other header lines Alvestrand Expires Jan 96 [Page 2] draft MID and CID URLs July 95 (3) Addition of "Resent-*" headers (4) Addition/subtraction of other non-standard headers like "X- Listproc-version", "Old-Received" or "PP-Warning" (5) Changes of content-transfer-encoding for MIME messages (6) Changes of wrapping for multiline headers An object is still considered the same object after undergoing these changes. The following changes may arise because of errors or misfeatures that are known to occur in Internet mailers, but represent erroneous representations of the message: (1) Changes to, addition of or removal of standard headers like "To:", "Subject:" or "Content-type:" (2) Substituting tabs for spaces or vice versa (3) Adding or deleting blank lines at the end of the message (4) Breaking of lines without using a MIME content-transfer- encoding 2.3. Resolution No specific resolution mechanism is defined by this document. Possible resolution mechanisms include: (1) Searching through a database of MIDs for messages seen at this UA (2) Searching publicly accessible message archives for messages with this MID (3) Sending mail to the author of the referencing document to ask which message he intended to point to Alvestrand Expires Jan 96 [Page 3] draft MID and CID URLs July 95 3. The Content-ID UR? 3.1. Syntax cidref = "cid:" content-id where content-ID is imported from RFC 1541 (MIME). Percent encoding must be used when the cid is used in a protocol that does not allow the full set of CID characters. 3.2. The identified object The CID references a MIME entity, consisting of headers and body. The following changes can be applied to a CID-referenced object without considering the object to be different: (1) Change of content-transfer-encoding, including recoding of quoted-printable (2) Addition or deletion of headers that do not begin with "content-"; this is necessary to allow the existence of two messages with the same content-id, but with different message headers (These should naturally have different message-ids) 3.3. Resolution The same resolution mechanisms as for message-ids can be applied to cids. 4. Security considerations Security issues are not consiered in this memo. 5. REFERENCES Alvestrand Expires Jan 96 [Page 4] draft MID and CID URLs July 95 [DUMMY REFERENCE] Here is the title of the reference Alvestrand Expires Jan 96 [Page 5] ------- =_aaaaaaaaaa0--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05411; 25 Jul 95 2:22 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05407; 25 Jul 95 2:22 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa03307; 25 Jul 95 2:22 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id BAA07146 for ietf-822-list; Tue, 25 Jul 1995 01:22:19 -0400 Received: from HUGBOX.SZTAKI.HU (hugbox.sztaki.hu [192.84.225.6]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id BAA07143 for ; Tue, 25 Jul 1995 01:22:15 -0400 Date: Tue, 25 Jul 1995 01:22:15 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mailgate@frodo.tii.matav.hu Message-Id: <199507250522.BAA07143@dimacs.rutgers.edu> Received: from htmvax.tii.matav.hu ([145.236.48.3]) by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Tue, 25 Jul 1995 07:22:07 gmt+2 Received: from frodo.tii.matav.hu by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Tue, 25 Jul 1995 07:19:56 MET_DST Subject: Mail delivery error Apparently-To: Note: This message was generated automagically. An error was detected, while processing the enclosed message. --> Error description: No such local user --> Error for: ietf-822@dimacs.rutgers.edu Returned mail follows. --------------------------------- X-Envelope-To: gyurik@frodo.tii.matav.hu Return-Path: Received: from htmvax.tii.matav.hu ([145.236.48.3]) by frodo.tii.matav.hu (SMTPSRV); Tue 25 Jul 1995 07:06 Received: from HUGBOX.SZTAKI.HU by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Tue, 25 Jul 1995 06:34:06 MET_DST Received: from dimacs.rutgers.edu by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Tue, 25 Jul 1995 06:35:31 gmt+2 Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id XAA06554 for ietf-822-list; Mon, 24 Jul 1995 23:34:56 -0400 Received: from ns.frontiertech.com (root@ns.frontiertech.com [192.104.32.5]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id XAA06551 for ; Mon, 24 Jul 1995 23:34:55 -0400 Received: by FrontierTech.COM (8.6.9/8.6.9) with SMTP id WAA11301; Mon, 24 Jul 1995 22:29:32 -0500 X-Mailer: SuperTCP Pro for Windows Version 1.1 (Mailer Version 1.02) Message-ID: <3014655A-00000001@rock105.FrontierTech.com> From: Ray Langford Date: Mon, 24 Jul 1995 22:30:33 cdt Subject: Re: Multipart/Alternative Compatibility Issue To: Terry Crowley , Ned Freed CC: ietf-822@dimacs.rutgers.edu Reply-To: Ray@frontiertech.com MIME-Version: 1.0 Content-Type: Text/Plain; Charset=US-ASCII >One example: A side conversation with Ray Langford from Frontier >Technologies indicates that their SuperTCP mail client flattens hierarchy >and treats mp/alternative as mp/mixed. It also treats the first inline >text part as the message body that is presented to the user. The result >of these choices is that both our encodings result in the same appearance >to the user. > >Terry Yes, this is the way our Email works. We chose to do this because our mail system is MAPI compliant. The MAPI structures define a notetext and flat (no hierarchy) attachments. We currently treat a MIME message as an equal collection of parts (attachments) and attempt to find a notetext (the first text part). I agree that mp/alternative could be handled better by only keeping and showing one alternative (of the users choice through configuration) but there are a number of reasons why this could be problematic in our current MAPI compliant mail system. We are looking into this and also Content-Disposition as ways to address these issues. However, in retrospect, SuperTCP MIME Email has been shipping now for over 21/2 years (over 200,000 copies) and we haven't received a single complaint about how we handle mp/alternative :-). I also don't think that there are many people (programs) that create mp/alternative messages... yet :-). [Sorry to readers if I have wandered too far off the topic (I am on vacation and actually have time to read and respond to the list).] ======================================== Ray C. Langford Engineering Manager, Advanced Products Frontier Technologies Corp. Email: Ray@FrontierTech.com Voice: (414) 241-4555 x205 ======================================== From "HTMVAX::MX%\"XUM%NIHCU.BITNET@HUEARN.sztaki.hu\""@tiiv04.tii.matav.hu Tue 25 Jul 1995 07:26   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06257; 25 Jul 95 6:19 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06253; 25 Jul 95 6:19 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa06178; 25 Jul 95 6:19 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id FAA08903 for ietf-822-list; Tue, 25 Jul 1995 05:25:36 -0400 Received: from domen.uninett.no (domen.uninett.no [129.241.131.10]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id FAA08900 for ; Tue, 25 Jul 1995 05:25:34 -0400 Received: from troms2.or.uninett.no by domen.uninett.no with SMTP (PP) id <12691-0@domen.uninett.no>; Tue, 25 Jul 1995 11:24:29 +0200 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.9) with ESMTP id AAA01853; Tue, 25 Jul 1995 00:02:46 +0200 Message-Id: <199507242202.AAA01853@dale.uninett.no> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Harald.T.Alvestrand@uninett.no To: Ned Freed cc: tcrowley@kilsythe.banyan.com, ietf-822@dimacs.rutgers.edu Subject: Re: Multipart/Alternative Compatibility Issue In-reply-to: Your message of "Mon, 24 Jul 1995 10:18:37 PDT." <01HT8V47KLVC8ZDVGG@INNOSOFT.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1850.806623365.1@dale.uninett.no> Date: Tue, 25 Jul 1995 00:02:46 +0200 X-Orig-Sender: hta@dale.uninett.no EXMH actually implements multipart/alternative by showing the "best" part and prefacing it with a line saying "use right button to view alternatives"; the right button brings up the list of alternatives and lets you try to view one of the others. EXMH also is the only mailer I've seen (apart from Andrew, which I haven't seen, it seems) that follows a pure "everything is inline" strategy, so I *do* know that the stuff I was looking at was a multipart/alternative for the second part of a multipart/mixed. Hint: The IETF internet-drafts announcements are examples of this structure. Harald A   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09588; 25 Jul 95 12:38 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09584; 25 Jul 95 12:38 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa13273; 25 Jul 95 12:38 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id LAA12500 for ietf-822-list; Tue, 25 Jul 1995 11:18:09 -0400 Received: from HUGBOX.SZTAKI.HU (hugbox.sztaki.hu [192.84.225.6]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id LAA12497 for ; Tue, 25 Jul 1995 11:18:05 -0400 Date: Tue, 25 Jul 1995 11:18:05 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mailgate@frodo.tii.matav.hu Message-Id: <199507251518.LAA12497@dimacs.rutgers.edu> Received: from htmvax.tii.matav.hu ([145.236.48.3]) by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Tue, 25 Jul 1995 17:19:02 gmt+2 Received: from frodo.tii.matav.hu by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Tue, 25 Jul 1995 17:01:51 MET_DST Subject: Mail delivery error Apparently-To: Note: This message was generated automagically. An error was detected, while processing the enclosed message. --> Error description: No such local user --> Error for: Gateway Returned mail follows. --------------------------------- X-Envelope-To: gyurik@frodo.tii.matav.hu Return-Path: Received: from htmvax.tii.matav.hu ([145.236.48.3]) by frodo.tii.matav.hu (SMTPSRV); Tue 25 Jul 1995 16:22 Received: from HUGBOX.SZTAKI.HU by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Tue, 25 Jul 1995 08:54:05 MET_DST Received: from dimacs.rutgers.edu by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Tue, 25 Jul 1995 08:52:45 gmt+2 Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id BAA07146 for ietf-822-list; Tue, 25 Jul 1995 01:22:19 -0400 Received: from HUGBOX.SZTAKI.HU (hugbox.sztaki.hu [192.84.225.6]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id BAA07143 for ; Tue, 25 Jul 1995 01:22:15 -0400 Date: Tue, 25 Jul 1995 01:22:15 -0400 From: Mailgate@frodo.tii.matav.hu Message-ID: <199507250522.BAA07143@dimacs.rutgers.edu> Received: from htmvax.tii.matav.hu ([145.236.48.3]) by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Tue, 25 Jul 1995 07:22:07 gmt+2 Received: from frodo.tii.matav.hu by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Tue, 25 Jul 1995 07:19:56 MET_DST Subject: Mail delivery error Apparently-To: Note: This message was generated automagically. An error was detected, while processing the enclosed message. --> Error description: No such local user --> Error for: ietf-822@dimacs.rutgers.edu Returned mail follows. --------------------------------- X-Envelope-To: gyurik@frodo.tii.matav.hu Return-Path: Received: from htmvax.tii.matav.hu ([145.236.48.3]) by frodo.tii.matav.hu (SMTPSRV); Tue 25 Jul 1995 07:06 Received: from HUGBOX.SZTAKI.HU by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Tue, 25 Jul 1995 06:34:06 MET_DST Received: from dimacs.rutgers.edu by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Tue, 25 Jul 1995 06:35:31 gmt+2 Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id XAA06554 for ietf-822-list; Mon, 24 Jul 1995 23:34:56 -0400 Received: from ns.frontiertech.com (root@ns.frontiertech.com [192.104.32.5]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id XAA06551 for ; Mon, 24 Jul 1995 23:34:55 -0400 Received: by FrontierTech.COM (8.6.9/8.6.9) with SMTP id WAA11301; Mon, 24 Jul 1995 22:29:32 -0500 X-Mailer: SuperTCP Pro for Windows Version 1.1 (Mailer Version 1.02) Message-ID: <3014655A-00000001@rock105.FrontierTech.com> From: Ray Langford Date: Mon, 24 Jul 1995 22:30:33 cdt Subject: Re: Multipart/Alternative Compatibility Issue To: Terry Crowley , Ned Freed CC: ietf-822@dimacs.rutgers.edu Reply-To: Ray@frontiertech.com MIME-Version: 1.0 Content-Type: Text/Plain; Charset=US-ASCII >One example: A side conversation with Ray Langford from Frontier >Technologies indicates that their SuperTCP mail client flattens hierarchy >and treats mp/alternative as mp/mixed. It also treats the first inline >text part as the message body that is presented to the user. The result >of these choices is that both our encodings result in the same appearance >to the user. > >Terry Yes, this is the way our Email works. We chose to do this because our mail system is MAPI compliant. The MAPI structures define a notetext and flat (no hierarchy) attachments. We currently treat a MIME message as an equal collection of parts (attachments) and attempt to find a notetext (the first text part). I agree that mp/alternative could be handled better by only keeping and showing one alternative (of the users choice through configuration) but there are a number of reasons why this could be problematic in our current MAPI compliant mail system. We are looking into this and also Content-Disposition as ways to address these issues. However, in retrospect, SuperTCP MIME Email has been shipping now for over 21/2 years (over 200,000 copies) and we haven't received a single complaint about how we handle mp/alternative :-). I also don't think that there are many people (programs) that create mp/alternative messages... yet :-). [Sorry to readers if I have wandered too far off the topic (I am on vacation and actually have time to read and respond to the list).] ======================================== Ray C. Langford Engineering Manager, Advanced Products Frontier Technologies Corp. Email: Ray@FrontierTech.com Voice: (414) 241-4555 x205 ======================================== >From "HTMVAX::MX%\"XUM%NIHCU.BITNET@HUEARN.sztaki.hu\""@tiiv04.tii.matav.hu Tue 25 Jul 1995 07:26 From owner-effector@eff.org Tue 25 Jul 1995 17:06   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14697; 25 Jul 95 18:24 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14693; 25 Jul 95 18:24 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa20645; 25 Jul 95 18:23 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id RAA23498 for ietf-822-list; Tue, 25 Jul 1995 17:19:55 -0400 Received: from HUGBOX.SZTAKI.HU (hugbox.sztaki.hu [192.84.225.6]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id RAA23494 for ; Tue, 25 Jul 1995 17:19:51 -0400 Date: Tue, 25 Jul 1995 17:19:51 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mailgate@frodo.tii.matav.hu Message-Id: <199507252119.RAA23494@dimacs.rutgers.edu> Received: from htmvax.tii.matav.hu ([145.236.48.3]) by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Tue, 25 Jul 1995 23:20:56 gmt+2 Received: from frodo.tii.matav.hu by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Tue, 25 Jul 1995 23:15:48 MET_DST Subject: Mail delivery error Apparently-To: Note: This message was generated automagically. An error was detected, while processing the enclosed message. --> Error description: No such local user --> Error for: ietf-822@dimacs.rutgers.edu Returned mail follows. --------------------------------- X-Envelope-To: gyurik@frodo.tii.matav.hu Return-Path: Received: from htmvax.tii.matav.hu ([145.236.48.3]) by frodo.tii.matav.hu (SMTPSRV); Tue 25 Jul 1995 22:36 Received: from HUGBOX.SZTAKI.HU by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Tue, 25 Jul 1995 12:37:58 MET_DST Received: from dimacs.rutgers.edu by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Tue, 25 Jul 1995 12:37:54 gmt+2 Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id FAA08903 for ietf-822-list; Tue, 25 Jul 1995 05:25:36 -0400 Received: from domen.uninett.no (domen.uninett.no [129.241.131.10]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id FAA08900 for ; Tue, 25 Jul 1995 05:25:34 -0400 Received: from troms2.or.uninett.no by domen.uninett.no with SMTP (PP) id <12691-0@domen.uninett.no>; Tue, 25 Jul 1995 11:24:29 +0200 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.9) with ESMTP id AAA01853; Tue, 25 Jul 1995 00:02:46 +0200 Message-ID: <199507242202.AAA01853@dale.uninett.no> From: Harald.T.Alvestrand@uninett.no To: Ned Freed CC: tcrowley@kilsythe.banyan.com, ietf-822@dimacs.rutgers.edu Subject: Re: Multipart/Alternative Compatibility Issue In-reply-to: Your message of "Mon, 24 Jul 1995 10:18:37 PDT." <01HT8V47KLVC8ZDVGG@INNOSOFT.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1850.806623365.1@dale.uninett.no> Date: Tue, 25 Jul 1995 00:02:46 +0200 Sender: hta@dale.uninett.no EXMH actually implements multipart/alternative by showing the "best" part and prefacing it with a line saying "use right button to view alternatives"; the right button brings up the list of alternatives and lets you try to view one of the others. EXMH also is the only mailer I've seen (apart from Andrew, which I haven't seen, it seems) that follows a pure "everything is inline" strategy, so I *do* know that the stuff I was looking at was a multipart/alternative for the second part of a multipart/mixed. Hint: The IETF internet-drafts announcements are examples of this structure. Harald A From Mailgate@frodo.tii.matav.hu Tue, 25 Jul 1995 22:43:09 CET   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15518; 25 Jul 95 19:28 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15514; 25 Jul 95 19:28 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa21805; 25 Jul 95 19:27 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id RAA23502 for ietf-822-list; Tue, 25 Jul 1995 17:19:59 -0400 Received: from HUGBOX.SZTAKI.HU (hugbox.sztaki.hu [192.84.225.6]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id RAA23499 for ; Tue, 25 Jul 1995 17:19:56 -0400 Date: Tue, 25 Jul 1995 17:19:56 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mailgate@frodo.tii.matav.hu Message-Id: <199507252119.RAA23499@dimacs.rutgers.edu> Received: from htmvax.tii.matav.hu ([145.236.48.3]) by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Tue, 25 Jul 1995 23:21:03 gmt+2 Received: from frodo.tii.matav.hu by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Tue, 25 Jul 1995 23:15:44 MET_DST Subject: Mail delivery error Apparently-To: Note: This message was generated automagically. An error was detected, while processing the enclosed message. --> Error description: No such local user --> Error for: tcrowley@kilsythe.banyan.com Returned mail follows. --------------------------------- X-Envelope-To: gyurik@frodo.tii.matav.hu Return-Path: Received: from htmvax.tii.matav.hu ([145.236.48.3]) by frodo.tii.matav.hu (SMTPSRV); Tue 25 Jul 1995 22:36 Received: from HUGBOX.SZTAKI.HU by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Tue, 25 Jul 1995 12:37:58 MET_DST Received: from dimacs.rutgers.edu by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Tue, 25 Jul 1995 12:37:54 gmt+2 Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id FAA08903 for ietf-822-list; Tue, 25 Jul 1995 05:25:36 -0400 Received: from domen.uninett.no (domen.uninett.no [129.241.131.10]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id FAA08900 for ; Tue, 25 Jul 1995 05:25:34 -0400 Received: from troms2.or.uninett.no by domen.uninett.no with SMTP (PP) id <12691-0@domen.uninett.no>; Tue, 25 Jul 1995 11:24:29 +0200 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.9) with ESMTP id AAA01853; Tue, 25 Jul 1995 00:02:46 +0200 Message-ID: <199507242202.AAA01853@dale.uninett.no> From: Harald.T.Alvestrand@uninett.no To: Ned Freed CC: tcrowley@kilsythe.banyan.com, ietf-822@dimacs.rutgers.edu Subject: Re: Multipart/Alternative Compatibility Issue In-reply-to: Your message of "Mon, 24 Jul 1995 10:18:37 PDT." <01HT8V47KLVC8ZDVGG@INNOSOFT.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1850.806623365.1@dale.uninett.no> Date: Tue, 25 Jul 1995 00:02:46 +0200 Sender: hta@dale.uninett.no EXMH actually implements multipart/alternative by showing the "best" part and prefacing it with a line saying "use right button to view alternatives"; the right button brings up the list of alternatives and lets you try to view one of the others. EXMH also is the only mailer I've seen (apart from Andrew, which I haven't seen, it seems) that follows a pure "everything is inline" strategy, so I *do* know that the stuff I was looking at was a multipart/alternative for the second part of a multipart/mixed. Hint: The IETF internet-drafts announcements are examples of this structure. Harald A From Mailgate@frodo.tii.matav.hu Tue, 25 Jul 1995 22:43:09 CET   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10964; 27 Jul 95 8:35 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10960; 27 Jul 95 8:35 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa10197; 27 Jul 95 8:35 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id HAA25854 for ietf-822-list; Thu, 27 Jul 1995 07:30:29 -0400 Received: from domen.uninett.no (domen.uninett.no [129.241.131.10]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id HAA25851 for ; Thu, 27 Jul 1995 07:30:27 -0400 Received: from troms4.or.uninett.no by domen.uninett.no with SMTP (PP) id <06527-0@domen.uninett.no>; Thu, 27 Jul 1995 13:29:46 +0200 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.9) with ESMTP id OAA04636; Wed, 26 Jul 1995 14:10:53 +0200 Message-Id: <199507261210.OAA04636@dale.uninett.no> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Harald.T.Alvestrand@uninett.no To: Ray@frontiertech.com cc: Terry Crowley , Ned Freed , ietf-822@dimacs.rutgers.edu Subject: Re: Multipart/Alternative Compatibility Issue In-reply-to: Your message of "Mon, 24 Jul 1995 22:30:33 CDT." <3014655A-00000001@rock105.FrontierTech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4633.806760653.1@dale.uninett.no> Date: Wed, 26 Jul 1995 14:10:53 +0200 X-Orig-Sender: hta@dale.uninett.no Your comment about MAPI is interesting. Is this full MAPI or restricted MAPI that only allows "attachments"? Does it allow enclosed messages and full manipulation of body parts within them, so that a solution that looks like the RFC 1495 definition for X.400 is possible, or is it a lost cause? (new gateway document: the MIME to MAPI gateway....AARRGGHHHH....) Harald A   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11482; 27 Jul 95 9:34 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11474; 27 Jul 95 9:34 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa11873; 27 Jul 95 9:34 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id IAA26019 for ietf-822-list; Thu, 27 Jul 1995 08:05:48 -0400 Received: from HUGBOX.SZTAKI.HU (hugbox.sztaki.hu [192.84.225.6]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id IAA26014 for ; Thu, 27 Jul 1995 08:05:42 -0400 Date: Thu, 27 Jul 1995 08:05:42 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mailgate@frodo.tii.matav.hu Message-Id: <199507271205.IAA26014@dimacs.rutgers.edu> Received: from htmvax.tii.matav.hu ([145.236.48.3]) by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Thu, 27 Jul 1995 14:06:33 gmt+2 Received: from frodo.tii.matav.hu by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Thu, 27 Jul 1995 13:10:24 MET_DST Subject: Mail delivery error Apparently-To: Note: This message was generated automagically. An error was detected, while processing the enclosed message. --> Error description: No such local user --> Error for: NED@innosoft.com Returned mail follows. --------------------------------- X-Envelope-To: gyurik@frodo.tii.matav.hu Return-Path: Received: from htmvax.tii.matav.hu ([145.236.48.3]) by frodo.tii.matav.hu (SMTPSRV); Thu 27 Jul 1995 12:30 Received: from HUGBOX.SZTAKI.HU ([192.84.225.6]) by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 17:07:02 MET_DST Received: from dimacs.rutgers.edu by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 17:08:12 gmt+2 Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id JAA17474 for ietf-822-list; Mon, 24 Jul 1995 09:55:56 -0400 Received: from warren.banyan.com (warren.banyan.com [131.100.182.40]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id JAA17471 for ; Mon, 24 Jul 1995 09:55:54 -0400 Received: from kilsythe.banyan.com by warren.banyan.com with SMTP (1.38.193.4/16.2) id AA22427; Mon, 24 Jul 1995 10:02:19 -0400 Received: from aberdeen.banyan.com by kilsythe.banyan.com (5.0/SMI-SVR4) id AA11799; Mon, 24 Jul 1995 09:56:53 +0500 Received: by aberdeen.banyan.com (5.0/SMI-SVR4) id AA04191; Mon, 24 Jul 1995 10:01:01 +0500 From: tcrowley@kilsythe.banyan.com (Terry Crowley) Message-ID: In-Reply-To: <01HT7FU4EXI08ZFTD0@INNOSOFT.COM> Reply-To: Terry Crowley Date: Mon, 24 Jul 1995 10:01:00 -0500 Subject: Re: Multipart/Alternative Compatibility Issue To: Ned Freed CC: ietf-822@dimacs.rutgers.edu Content-Length: 4243 >> It depends on what you mean by "bad". ("Imagine every atom in your body >> exploding at the speed of light...OK, good safety tip, don't cross the >> beams.") OK, not that bad if you get one of these messages every couple days, >> but imagine you have 150 messages in your inbox, every one of which requires >> that you go through this multi-step process just to look at what might be a >> two sentence message. I think that's worse than bad, that's horrible. And I >> can guarantee it would be sufficient to be a deal-breaker in many cases. I'm >> sure you're familiar enough with the commercial market to know that pointing >> fingers and saying "it's their fault!" doesn't get you very far with a >> customer who just wants things to work. > Say what? What you've effectively done here is argue against your own chosen > approach! You're the one that has chosen to package multipart/alternative as > multipart/mixed, not me! > By packaging things as multipart/mixed instead of using multipart/alternative > properly you guarantee that everyone with a *compliant* MIME agent has to go > through the very process you deplore. Were you to choose to package things > properly you would only have this problem with clients that treat > multipart/alternative as multipart/mixed, and no choice you make is going to > fix this behavior, so you'd best stop trying. Hmm, well this conversation is definitely resulting in diminishing returns, but I'll try to clarify one point and keep it short. I haven't argued against my approach. The painful process described above results from multipart/alternative embedded in multipart/mixed. If multipart/mixed is sent alone, then the text shows up right where it should, the problem is that this "useless" attachment, which can be ignored, also shows up. The reader of the message is forced to look upon an attachment indicator, but doesn't need to take any extra steps to actually see the message body. Perhaps we should attempt to shed some light on this topic. How about some reports from the field about how different clients are actually handling multipart/alternative. Does your client force you to make an explicit choice about which alternative you want to see on every multipart/alternative message you receive or do you configure it once? Does it treat multipart/alternative as multipart/mixed? If the message contains a nested hierarchy, are you forced to go through a two-step interaction to see embedded elements? Maybe I'm not getting my real point across. From a UI perspective, multipart/alternative and nested hierarchies are difficult to handle in a real clean way. I'd say virtually every mail client that's being modified to handle MIME started off with no model of alternative content or of hierarchical structure. Therefore, the MIME implementor needs to make a choice about how to handle it. By far the simplest approach is to just treat mp/alternative as mp/mixed. Another approach is to query the user, but I consider that a total mistake. The best approach is to make a choice based on configuration information, perhaps provide some subtle indication that a choice was made, and then provide a way for the user to examine the choices and possibly make a different one explicitly. I haven't seen any system that actually does this (Slate came close, but it wasn't always completely clear what part of the document the alternatives were tied to.) Making these decisions consistently across clients is critical to interoperability. As an analogy, look at the issue of line lengths. Everyone's read those virtually unreadable messages from someone writing in a window that lets them put 85 characters on a line. Sure its 822 compliant, but that doesn't make it easy to read. Anyone want to add some case histories to this discussion? One example: A side conversation with Ray Langford from Frontier Technologies indicates that their SuperTCP mail client flattens hierarchy and treats mp/alternative as mp/mixed. It also treats the first inline text part as the message body that is presented to the user. The result of these choices is that both our encodings result in the same appearance to the user. Terry From "HTMVAX::MX%\"4AD-L@AMERICAN.EDU\""@tiiv04.tii.matav.hu Thu 27 Jul 1995 13:20   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12034; 27 Jul 95 10:30 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12030; 27 Jul 95 10:30 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa13143; 27 Jul 95 10:30 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id IAA26012 for ietf-822-list; Thu, 27 Jul 1995 08:05:37 -0400 Received: from HUGBOX.SZTAKI.HU (hugbox.sztaki.hu [192.84.225.6]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id IAA26009 for ; Thu, 27 Jul 1995 08:05:30 -0400 Date: Thu, 27 Jul 1995 08:05:30 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mailgate@frodo.tii.matav.hu Message-Id: <199507271205.IAA26009@dimacs.rutgers.edu> Received: from htmvax.tii.matav.hu ([145.236.48.3]) by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Thu, 27 Jul 1995 14:06:37 gmt+2 Received: from frodo.tii.matav.hu by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Thu, 27 Jul 1995 13:10:34 MET_DST Subject: Mail delivery error Apparently-To: Note: This message was generated automagically. An error was detected, while processing the enclosed message. --> Error description: No such local user --> Error for: ietf-822@dimacs.rutgers.edu Returned mail follows. --------------------------------- X-Envelope-To: gyurik@frodo.tii.matav.hu Return-Path: Received: from htmvax.tii.matav.hu ([145.236.48.3]) by frodo.tii.matav.hu (SMTPSRV); Thu 27 Jul 1995 12:30 Received: from HUGBOX.SZTAKI.HU ([192.84.225.6]) by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 17:07:02 MET_DST Received: from dimacs.rutgers.edu by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 17:08:12 gmt+2 Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id JAA17474 for ietf-822-list; Mon, 24 Jul 1995 09:55:56 -0400 Received: from warren.banyan.com (warren.banyan.com [131.100.182.40]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id JAA17471 for ; Mon, 24 Jul 1995 09:55:54 -0400 Received: from kilsythe.banyan.com by warren.banyan.com with SMTP (1.38.193.4/16.2) id AA22427; Mon, 24 Jul 1995 10:02:19 -0400 Received: from aberdeen.banyan.com by kilsythe.banyan.com (5.0/SMI-SVR4) id AA11799; Mon, 24 Jul 1995 09:56:53 +0500 Received: by aberdeen.banyan.com (5.0/SMI-SVR4) id AA04191; Mon, 24 Jul 1995 10:01:01 +0500 From: tcrowley@kilsythe.banyan.com (Terry Crowley) Message-ID: In-Reply-To: <01HT7FU4EXI08ZFTD0@INNOSOFT.COM> Reply-To: Terry Crowley Date: Mon, 24 Jul 1995 10:01:00 -0500 Subject: Re: Multipart/Alternative Compatibility Issue To: Ned Freed CC: ietf-822@dimacs.rutgers.edu Content-Length: 4243 >> It depends on what you mean by "bad". ("Imagine every atom in your body >> exploding at the speed of light...OK, good safety tip, don't cross the >> beams.") OK, not that bad if you get one of these messages every couple days, >> but imagine you have 150 messages in your inbox, every one of which requires >> that you go through this multi-step process just to look at what might be a >> two sentence message. I think that's worse than bad, that's horrible. And I >> can guarantee it would be sufficient to be a deal-breaker in many cases. I'm >> sure you're familiar enough with the commercial market to know that pointing >> fingers and saying "it's their fault!" doesn't get you very far with a >> customer who just wants things to work. > Say what? What you've effectively done here is argue against your own chosen > approach! You're the one that has chosen to package multipart/alternative as > multipart/mixed, not me! > By packaging things as multipart/mixed instead of using multipart/alternative > properly you guarantee that everyone with a *compliant* MIME agent has to go > through the very process you deplore. Were you to choose to package things > properly you would only have this problem with clients that treat > multipart/alternative as multipart/mixed, and no choice you make is going to > fix this behavior, so you'd best stop trying. Hmm, well this conversation is definitely resulting in diminishing returns, but I'll try to clarify one point and keep it short. I haven't argued against my approach. The painful process described above results from multipart/alternative embedded in multipart/mixed. If multipart/mixed is sent alone, then the text shows up right where it should, the problem is that this "useless" attachment, which can be ignored, also shows up. The reader of the message is forced to look upon an attachment indicator, but doesn't need to take any extra steps to actually see the message body. Perhaps we should attempt to shed some light on this topic. How about some reports from the field about how different clients are actually handling multipart/alternative. Does your client force you to make an explicit choice about which alternative you want to see on every multipart/alternative message you receive or do you configure it once? Does it treat multipart/alternative as multipart/mixed? If the message contains a nested hierarchy, are you forced to go through a two-step interaction to see embedded elements? Maybe I'm not getting my real point across. From a UI perspective, multipart/alternative and nested hierarchies are difficult to handle in a real clean way. I'd say virtually every mail client that's being modified to handle MIME started off with no model of alternative content or of hierarchical structure. Therefore, the MIME implementor needs to make a choice about how to handle it. By far the simplest approach is to just treat mp/alternative as mp/mixed. Another approach is to query the user, but I consider that a total mistake. The best approach is to make a choice based on configuration information, perhaps provide some subtle indication that a choice was made, and then provide a way for the user to examine the choices and possibly make a different one explicitly. I haven't seen any system that actually does this (Slate came close, but it wasn't always completely clear what part of the document the alternatives were tied to.) Making these decisions consistently across clients is critical to interoperability. As an analogy, look at the issue of line lengths. Everyone's read those virtually unreadable messages from someone writing in a window that lets them put 85 characters on a line. Sure its 822 compliant, but that doesn't make it easy to read. Anyone want to add some case histories to this discussion? One example: A side conversation with Ray Langford from Frontier Technologies indicates that their SuperTCP mail client flattens hierarchy and treats mp/alternative as mp/mixed. It also treats the first inline text part as the message body that is presented to the user. The result of these choices is that both our encodings result in the same appearance to the user. Terry From "HTMVAX::MX%\"4AD-L@AMERICAN.EDU\""@tiiv04.tii.matav.hu Thu 27 Jul 1995 13:20   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12250; 27 Jul 95 10:48 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12245; 27 Jul 95 10:48 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa13620; 27 Jul 95 10:48 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id IAA26023 for ietf-822-list; Thu, 27 Jul 1995 08:05:56 -0400 Received: from HUGBOX.SZTAKI.HU (hugbox.sztaki.hu [192.84.225.6]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id IAA26020 for ; Thu, 27 Jul 1995 08:05:50 -0400 Date: Thu, 27 Jul 1995 08:05:50 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mailgate@frodo.tii.matav.hu Message-Id: <199507271205.IAA26020@dimacs.rutgers.edu> Received: from htmvax.tii.matav.hu ([145.236.48.3]) by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Thu, 27 Jul 1995 14:06:41 gmt+2 Received: from frodo.tii.matav.hu by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Thu, 27 Jul 1995 13:10:18 MET_DST Subject: Mail delivery error Apparently-To: Note: This message was generated automagically. An error was detected, while processing the enclosed message. --> Error description: No such local user --> Error for: drums@cs.utk.edu,ietf-822@dimacs.rutgers.edu,uri@bunyip.com Returned mail follows. --------------------------------- X-Envelope-To: gyurik@frodo.tii.matav.hu Return-Path: Received: from htmvax.tii.matav.hu ([145.236.48.3]) by frodo.tii.matav.hu (SMTPSRV); Thu 27 Jul 1995 12:25 Received: from HUGBOX.SZTAKI.HU by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 11:05:58 MET_DST Received: from dimacs.rutgers.edu by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 11:07:15 gmt+2 Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id DAA15178 for ietf-822-list; Mon, 24 Jul 1995 03:19:53 -0400 Received: from domen.uninett.no (domen.uninett.no [129.241.131.10]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id DAA15175 for ; Mon, 24 Jul 1995 03:19:51 -0400 Received: from troms2.or.uninett.no by domen.uninett.no with SMTP (PP) id <25021-0@domen.uninett.no>; Mon, 24 Jul 1995 09:18:59 +0200 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.9) with ESMTP id WAA00170; Sun, 23 Jul 1995 22:08:53 +0200 Message-ID: <199507232008.WAA00170@dale.uninett.no> From: Harald.T.Alvestrand@uninett.no To: drums@cs.utk.edu, ietf-822@dimacs.rutgers.edu, uri@bunyip.com Subject: An idea for MID and CID URsomethings Reply-To: drums@cs.utk.edu MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <166.806530098.0@dale.uninett.no> Date: Sun, 23 Jul 1995 22:08:52 +0200 Sender: hta@dale.uninett.no ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <166.806530098.1@dale.uninett.no> I talked to some people briefly about this during IETF. Since it points out some problems with "what does an ID identify" in both MIME and RFC 822, I think "drums" may be a nice "home list" to discuss it on; I've set reply-to accordingly. I don't know whether it is either best or appropriate for me to continue editing this; does anyone feel like taking responsibility? (Ed Levinson had a previous document on CID URLs, but I've lost my copy of it, and he seems to have shelved the idea for the moment) Comments? Harald A ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <166.806530098.2@dale.uninett.no> draft MID and CID URLs July 95 Message-ID and Content-ID URLs Sun Jul 23 19:16:56 MET DST 1995 Harald Tveit Alvestrand UNINETT Harald.T.Alvestrand@uninett.no Status of this Memo This document specifies two classes of URsomethings, MID and CID. The intention is to allow reference to messages and message components using a syntax that looks much like that used for URLs in the Web. This draft document is being circulated for comment. Please send comments to the author, or to..... The following text is required by the Internet-draft rules: This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. The file name of this version is draft-alvestrand-not-submitted- at-all.txt Alvestrand Expires Jan 96 [Page 1] draft MID and CID URLs July 95 1. Introduction When writing information resources, it would sometimes be nice to have a reasonably unique way of referring to mail and news messages. In some cases, like when you are sending a message coded in HTML, it is also nice to be able to refer to parts of a message by content-id. These references are not Uniform Resource Locators, since they do not encode the location of their objects, neither are they Uniform Resource Names, since they do not fulfil all requirements of RFC 1737; for lack of a better idea, I call them Reasonably Unique Identifying Names; this term obviously does not have a four-letter abbreviation. 2. The Message-ID UR? 2.1. Syntax The syntax of the message-ID locator is mid = "mid:" message-id where message-id is imported from STD 12, "Internet Mail", RFC 822. When it is used in protocols which do not allow the full character set of RFC 822, it must be encoded using the %-convention. 2.2. The identified object The message-ID locator resolves to an Internet message. This identifies a message header and a message body conformant to RFC 822 and (possibly) MIME; due to the history of Internet messages, the following differences must be expected between different copies of the same message: (1) Variable number of "Received:" lines in the header (2) Randomized order of other header lines Alvestrand Expires Jan 96 [Page 2] draft MID and CID URLs July 95 (3) Addition of "Resent-*" headers (4) Addition/subtraction of other non-standard headers like "X- Listproc-version", "Old-Received" or "PP-Warning" (5) Changes of content-transfer-encoding for MIME messages (6) Changes of wrapping for multiline headers An object is still considered the same object after undergoing these changes. The following changes may arise because of errors or misfeatures that are known to occur in Internet mailers, but represent erroneous representations of the message: (1) Changes to, addition of or removal of standard headers like "To:", "Subject:" or "Content-type:" (2) Substituting tabs for spaces or vice versa (3) Adding or deleting blank lines at the end of the message (4) Breaking of lines without using a MIME content-transfer- encoding 2.3. Resolution No specific resolution mechanism is defined by this document. Possible resolution mechanisms include: (1) Searching through a database of MIDs for messages seen at this UA (2) Searching publicly accessible message archives for messages with this MID (3) Sending mail to the author of the referencing document to ask which message he intended to point to Alvestrand Expires Jan 96 [Page 3] draft MID and CID URLs July 95 3. The Content-ID UR? 3.1. Syntax cidref = "cid:" content-id where content-ID is imported from RFC 1541 (MIME). Percent encoding must be used when the cid is used in a protocol that does not allow the full set of CID characters. 3.2. The identified object The CID references a MIME entity, consisting of headers and body. The following changes can be applied to a CID-referenced object without considering the object to be different: (1) Change of content-transfer-encoding, including recoding of quoted-printable (2) Addition or deletion of headers that do not begin with "content-"; this is necessary to allow the existence of two messages with the same content-id, but with different message headers (These should naturally have different message-ids) 3.3. Resolution The same resolution mechanisms as for message-ids can be applied to cids. 4. Security considerations Security issues are not consiered in this memo. 5. REFERENCES Alvestrand Expires Jan 96 [Page 4] draft MID and CID URLs July 95 [DUMMY REFERENCE] Here is the title of the reference Alvestrand Expires Jan 96 [Page 5] ------- =_aaaaaaaaaa0-- From "HTMVAX::MX%\"info@ivory.educom.edu\""@tiiv04.tii.matav.hu Thu 27 Jul 1995 12:28   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12712; 27 Jul 95 11:34 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12708; 27 Jul 95 11:34 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa14384; 27 Jul 95 11:33 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id IAA26339 for ietf-822-list; Thu, 27 Jul 1995 08:43:34 -0400 Received: from HUGBOX.SZTAKI.HU (hugbox.sztaki.hu [192.84.225.6]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id IAA26336 for ; Thu, 27 Jul 1995 08:43:24 -0400 Date: Thu, 27 Jul 1995 08:43:24 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mailgate@frodo.tii.matav.hu Message-Id: <199507271243.IAA26336@dimacs.rutgers.edu> Received: from htmvax.tii.matav.hu ([145.236.48.3]) by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Thu, 27 Jul 1995 14:43:14 gmt+2 Received: from frodo.tii.matav.hu by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Thu, 27 Jul 1995 14:41:17 MET_DST Subject: Mail delivery error Apparently-To: Note: This message was generated automagically. An error was detected, while processing the enclosed message. --> Error description: No such local user --> Error for: info-mime@CS.UTK.EDU Returned mail follows. --------------------------------- X-Envelope-To: gyurik@frodo.tii.matav.hu Return-Path: Received: from htmvax.tii.matav.hu ([145.236.48.3]) by frodo.tii.matav.hu (SMTPSRV); Thu 27 Jul 1995 14:32 Received: from HUGBOX.SZTAKI.HU by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Tue, 25 Jul 1995 01:26:43 MET_DST Received: from dimacs.rutgers.edu by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Tue, 25 Jul 1995 01:28:04 gmt+2 Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id PAA27762 for ietf-822-list; Mon, 24 Jul 1995 15:34:15 -0400 Received: from HUGBOX.SZTAKI.HU (hugbox.sztaki.hu [192.84.225.6]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id PAA27755 for ; Mon, 24 Jul 1995 15:33:52 -0400 Date: Mon, 24 Jul 1995 15:33:52 -0400 From: Mailgate@frodo.tii.matav.hu Message-ID: <199507241933.PAA27755@dimacs.rutgers.edu> Received: from htmvax.tii.matav.hu ([145.236.48.3]) by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 21:34:09 gmt+2 Received: from frodo.tii.matav.hu by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 21:01:33 MET_DST Subject: Mail delivery error Apparently-To: Note: This message was generated automagically. An error was detected, while processing the enclosed message. --> Error description: No such local user --> Error for: NED@innosoft.com Returned mail follows. --------------------------------- X-Envelope-To: gyurik@frodo.tii.matav.hu Return-Path: Received: from htmvax.tii.matav.hu ([145.236.48.3]) by frodo.tii.matav.hu (SMTPSRV); Mon 24 Jul 1995 20:57 Received: from HUGBOX.SZTAKI.HU ([192.84.225.6]) by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 17:07:02 MET_DST Received: from dimacs.rutgers.edu by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 17:08:12 gmt+2 Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id JAA17474 for ietf-822-list; Mon, 24 Jul 1995 09:55:56 -0400 Received: from warren.banyan.com (warren.banyan.com [131.100.182.40]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id JAA17471 for ; Mon, 24 Jul 1995 09:55:54 -0400 Received: from kilsythe.banyan.com by warren.banyan.com with SMTP (1.38.193.4/16.2) id AA22427; Mon, 24 Jul 1995 10:02:19 -0400 Received: from aberdeen.banyan.com by kilsythe.banyan.com (5.0/SMI-SVR4) id AA11799; Mon, 24 Jul 1995 09:56:53 +0500 Received: by aberdeen.banyan.com (5.0/SMI-SVR4) id AA04191; Mon, 24 Jul 1995 10:01:01 +0500 From: tcrowley@kilsythe.banyan.com (Terry Crowley) Message-ID: In-Reply-To: <01HT7FU4EXI08ZFTD0@INNOSOFT.COM> Reply-To: Terry Crowley Date: Mon, 24 Jul 1995 10:01:00 -0500 Subject: Re: Multipart/Alternative Compatibility Issue To: Ned Freed CC: ietf-822@dimacs.rutgers.edu Content-Length: 4243 >> It depends on what you mean by "bad". ("Imagine every atom in your body >> exploding at the speed of light...OK, good safety tip, don't cross the >> beams.") OK, not that bad if you get one of these messages every couple days, >> but imagine you have 150 messages in your inbox, every one of which requires >> that you go through this multi-step process just to look at what might be a >> two sentence message. I think that's worse than bad, that's horrible. And I >> can guarantee it would be sufficient to be a deal-breaker in many cases. I'm >> sure you're familiar enough with the commercial market to know that pointing >> fingers and saying "it's their fault!" doesn't get you very far with a >> customer who just wants things to work. > Say what? What you've effectively done here is argue against your own chosen > approach! You're the one that has chosen to package multipart/alternative as > multipart/mixed, not me! > By packaging things as multipart/mixed instead of using multipart/alternative > properly you guarantee that everyone with a *compliant* MIME agent has to go > through the very process you deplore. Were you to choose to package things > properly you would only have this problem with clients that treat > multipart/alternative as multipart/mixed, and no choice you make is going to > fix this behavior, so you'd best stop trying. Hmm, well this conversation is definitely resulting in diminishing returns, but I'll try to clarify one point and keep it short. I haven't argued against my approach. The painful process described above results from multipart/alternative embedded in multipart/mixed. If multipart/mixed is sent alone, then the text shows up right where it should, the problem is that this "useless" attachment, which can be ignored, also shows up. The reader of the message is forced to look upon an attachment indicator, but doesn't need to take any extra steps to actually see the message body. Perhaps we should attempt to shed some light on this topic. How about some reports from the field about how different clients are actually handling multipart/alternative. Does your client force you to make an explicit choice about which alternative you want to see on every multipart/alternative message you receive or do you configure it once? Does it treat multipart/alternative as multipart/mixed? If the message contains a nested hierarchy, are you forced to go through a two-step interaction to see embedded elements? Maybe I'm not getting my real point across. From a UI perspective, multipart/alternative and nested hierarchies are difficult to handle in a real clean way. I'd say virtually every mail client that's being modified to handle MIME started off with no model of alternative content or of hierarchical structure. Therefore, the MIME implementor needs to make a choice about how to handle it. By far the simplest approach is to just treat mp/alternative as mp/mixed. Another approach is to query the user, but I consider that a total mistake. The best approach is to make a choice based on configuration information, perhaps provide some subtle indication that a choice was made, and then provide a way for the user to examine the choices and possibly make a different one explicitly. I haven't seen any system that actually does this (Slate came close, but it wasn't always completely clear what part of the document the alternatives were tied to.) Making these decisions consistently across clients is critical to interoperability. As an analogy, look at the issue of line lengths. Everyone's read those virtually unreadable messages from someone writing in a window that lets them put 85 characters on a line. Sure its 822 compliant, but that doesn't make it easy to read. Anyone want to add some case histories to this discussion? One example: A side conversation with Ray Langford from Frontier Technologies indicates that their SuperTCP mail client flattens hierarchy and treats mp/alternative as mp/mixed. It also treats the first inline text part as the message body that is presented to the user. The result of these choices is that both our encodings result in the same appearance to the user. Terry   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12740; 27 Jul 95 11:36 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12736; 27 Jul 95 11:36 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa14459; 27 Jul 95 11:36 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id JAA27397 for ietf-822-list; Thu, 27 Jul 1995 09:42:04 -0400 Received: from HUGBOX.SZTAKI.HU (hugbox.sztaki.hu [192.84.225.6]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id JAA27360 for ; Thu, 27 Jul 1995 09:41:14 -0400 Date: Thu, 27 Jul 1995 09:41:14 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mailgate@frodo.tii.matav.hu Message-Id: <199507271341.JAA27360@dimacs.rutgers.edu> Received: from htmvax.tii.matav.hu ([145.236.48.3]) by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Thu, 27 Jul 1995 15:41:11 gmt+2 Received: from frodo.tii.matav.hu by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Thu, 27 Jul 1995 15:09:05 MET_DST Subject: Mail delivery error Apparently-To: Note: This message was generated automagically. An error was detected, while processing the enclosed message. --> Error description: No such local user --> Error for: ietf-822@dimacs.rutgers.edu Returned mail follows. --------------------------------- X-Envelope-To: gyurik@frodo.tii.matav.hu Return-Path: Received: from htmvax.tii.matav.hu ([145.236.48.3]) by frodo.tii.matav.hu (SMTPSRV); Thu 27 Jul 1995 15:08 Received: from HUGBOX.SZTAKI.HU by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 23:02:41 MET_DST Received: from dimacs.rutgers.edu by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 23:04:08 gmt+2 Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id OAA26785 for ietf-822-list; Mon, 24 Jul 1995 14:27:17 -0400 Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id OAA26782 for ; Mon, 24 Jul 1995 14:27:12 -0400 Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.0-4 #2001) id <01HT7VI6UHCW8ZDVGG@INNOSOFT.COM>; Mon, 24 Jul 1995 10:56:02 -0700 (PDT) Date: Mon, 24 Jul 1995 10:18:37 -0700 (PDT) From: Ned Freed Subject: Re: Multipart/Alternative Compatibility Issue In-reply-to: "Your message dated Mon, 24 Jul 1995 10:01:00 -0500" To: tcrowley@kilsythe.banyan.com CC: ietf-822@dimacs.rutgers.edu Message-ID: <01HT8V47KLVC8ZDVGG@INNOSOFT.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT References: <01HT7FU4EXI08ZFTD0@INNOSOFT.COM> > Hmm, well this conversation is definitely resulting in diminishing returns, > but I'll try to clarify one point and keep it short. I haven't argued against > my approach. The painful process described above results from > multipart/alternative embedded in multipart/mixed. If multipart/mixed is sent > alone, then the text shows up right where it should, the problem is that this > "useless" attachment, which can be ignored, also shows up. The reader of the > message is forced to look upon an attachment indicator, but doesn't need to > take any extra steps to actually see the message body. Perhaps you don't see this as arguing against your own approach, but I most certainly do. You apparently have a problem with one client's handling of multipart/alternative, so instead of dealing with that clients problem somehow you use a structure that is very suboptimal on compliant clients. For me the question boils down to whether you do something that's really bad for one or something that's somewhat bad for everyone. You have chosen the latter. I would choose the former. > Perhaps we should attempt to shed some light on this topic. How about some > reports from the field about how different clients are actually handling > multipart/alternative. Does your client force you to make an explicit choice > about which alternative you want to see on every multipart/alternative message > you receive or do you configure it once? Does it treat multipart/alternative > as multipart/mixed? If the message contains a nested hierarchy, are you > forced to go through a two-step interaction to see embedded elements? My experience has been that most clients handle such things tolerably -- they either handle multipart/alternative correctly or else they flatten everything so that your two approaches are equivalent. > Maybe I'm not getting my real point across. From a UI perspective, > multipart/alternative and nested hierarchies are difficult to handle in a real > clean way. On the contrary, since proper handling of multipart/alternative effectively eliminates the heirarchy, none of these presentation issues arise. If they do arise there's something wrong with multipart/alternative handling. Let me put this another way. If what you're arguing for is that if a client cannot handle multipart/alternative, it should at least flatten out the structure around it to prevent even more problems, I would tend to agree. But all the standards can do is define compliance -- the behavior of incompliant software (and support for multipart/alternative *is* required). > I'd say virtually every mail client that's being modified to > handle MIME started off with no model of alternative content or of > hierarchical structure. Depends on how the mods are done. If MetaMail is used as a basis for the mods (and it often is) you end up with alternative handling from the beginning. > Therefore, the MIME implementor needs to make a > choice about how to handle it. By far the simplest approach is to just treat > mp/alternative as mp/mixed. Another approach is to query the user, but I > consider that a total mistake. The best approach is to make a choice based on > configuration information, perhaps provide some subtle indication that a > choice was made, and then provide a way for the user to examine the choices > and possibly make a different one explicitly. I haven't seen any system that > actually does this (Slate came close, but it wasn't always completely clear > what part of the document the alternatives were tied to.) The first MIME client that was released, MetaMail, seems to handle this just fine. And MetaMail works with practically every existing user agent around. Oddly enough, the one thing MetaMail doesn't do well is default to handling unknown subtypes of multipart as mixed! > Making these decisions consistently across clients is critical to > interoperability. As an analogy, look at the issue of line lengths. > Everyone's read those virtually unreadable messages from someone writing in a > window that lets them put 85 characters on a line. Sure its 822 compliant, > but that doesn't make it easy to read. > Anyone want to add some case histories to this discussion? > One example: A side conversation with Ray Langford from Frontier Technologies > indicates that their SuperTCP mail client flattens hierarchy and treats > mp/alternative as mp/mixed. It also treats the first inline text part as the > message body that is presented to the user. The result of these choices is > that both our encodings result in the same appearance to the user. But in this case it doesn't matter which of your two approaches you use. Its a no-win situation either way. If anything this demonstrates a preference for multipart/alternative -- you lose nothing by using it now, but should Frontier ever fix their agent old messages will then be handled properly. Ned   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13513; 27 Jul 95 12:29 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13506; 27 Jul 95 12:29 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa15529; 27 Jul 95 12:28 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id JAA27359 for ietf-822-list; Thu, 27 Jul 1995 09:41:12 -0400 Received: from HUGBOX.SZTAKI.HU (hugbox.sztaki.hu [192.84.225.6]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id JAA27356 for ; Thu, 27 Jul 1995 09:41:06 -0400 Date: Thu, 27 Jul 1995 09:41:06 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mailgate@frodo.tii.matav.hu Message-Id: <199507271341.JAA27356@dimacs.rutgers.edu> Received: from htmvax.tii.matav.hu ([145.236.48.3]) by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Thu, 27 Jul 1995 15:41:18 gmt+2 Received: from frodo.tii.matav.hu by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Thu, 27 Jul 1995 15:08:59 MET_DST Subject: Mail delivery error Apparently-To: Note: This message was generated automagically. An error was detected, while processing the enclosed message. --> Error description: No such local user --> Error for: tcrowley@kilsythe.banyan.com Returned mail follows. --------------------------------- X-Envelope-To: gyurik@frodo.tii.matav.hu Return-Path: Received: from htmvax.tii.matav.hu ([145.236.48.3]) by frodo.tii.matav.hu (SMTPSRV); Thu 27 Jul 1995 15:08 Received: from HUGBOX.SZTAKI.HU by htmvax.tii.matav.hu (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 23:02:41 MET_DST Received: from dimacs.rutgers.edu by HUGBOX.SZTAKI.HU (MX V4.1 VAX) with SMTP; Mon, 24 Jul 1995 23:04:08 gmt+2 Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id OAA26785 for ietf-822-list; Mon, 24 Jul 1995 14:27:17 -0400 Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id OAA26782 for ; Mon, 24 Jul 1995 14:27:12 -0400 Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.0-4 #2001) id <01HT7VI6UHCW8ZDVGG@INNOSOFT.COM>; Mon, 24 Jul 1995 10:56:02 -0700 (PDT) Date: Mon, 24 Jul 1995 10:18:37 -0700 (PDT) From: Ned Freed Subject: Re: Multipart/Alternative Compatibility Issue In-reply-to: "Your message dated Mon, 24 Jul 1995 10:01:00 -0500" To: tcrowley@kilsythe.banyan.com CC: ietf-822@dimacs.rutgers.edu Message-ID: <01HT8V47KLVC8ZDVGG@INNOSOFT.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT References: <01HT7FU4EXI08ZFTD0@INNOSOFT.COM> > Hmm, well this conversation is definitely resulting in diminishing returns, > but I'll try to clarify one point and keep it short. I haven't argued against > my approach. The painful process described above results from > multipart/alternative embedded in multipart/mixed. If multipart/mixed is sent > alone, then the text shows up right where it should, the problem is that this > "useless" attachment, which can be ignored, also shows up. The reader of the > message is forced to look upon an attachment indicator, but doesn't need to > take any extra steps to actually see the message body. Perhaps you don't see this as arguing against your own approach, but I most certainly do. You apparently have a problem with one client's handling of multipart/alternative, so instead of dealing with that clients problem somehow you use a structure that is very suboptimal on compliant clients. For me the question boils down to whether you do something that's really bad for one or something that's somewhat bad for everyone. You have chosen the latter. I would choose the former. > Perhaps we should attempt to shed some light on this topic. How about some > reports from the field about how different clients are actually handling > multipart/alternative. Does your client force you to make an explicit choice > about which alternative you want to see on every multipart/alternative message > you receive or do you configure it once? Does it treat multipart/alternative > as multipart/mixed? If the message contains a nested hierarchy, are you > forced to go through a two-step interaction to see embedded elements? My experience has been that most clients handle such things tolerably -- they either handle multipart/alternative correctly or else they flatten everything so that your two approaches are equivalent. > Maybe I'm not getting my real point across. From a UI perspective, > multipart/alternative and nested hierarchies are difficult to handle in a real > clean way. On the contrary, since proper handling of multipart/alternative effectively eliminates the heirarchy, none of these presentation issues arise. If they do arise there's something wrong with multipart/alternative handling. Let me put this another way. If what you're arguing for is that if a client cannot handle multipart/alternative, it should at least flatten out the structure around it to prevent even more problems, I would tend to agree. But all the standards can do is define compliance -- the behavior of incompliant software (and support for multipart/alternative *is* required). > I'd say virtually every mail client that's being modified to > handle MIME started off with no model of alternative content or of > hierarchical structure. Depends on how the mods are done. If MetaMail is used as a basis for the mods (and it often is) you end up with alternative handling from the beginning. > Therefore, the MIME implementor needs to make a > choice about how to handle it. By far the simplest approach is to just treat > mp/alternative as mp/mixed. Another approach is to query the user, but I > consider that a total mistake. The best approach is to make a choice based on > configuration information, perhaps provide some subtle indication that a > choice was made, and then provide a way for the user to examine the choices > and possibly make a different one explicitly. I haven't seen any system that > actually does this (Slate came close, but it wasn't always completely clear > what part of the document the alternatives were tied to.) The first MIME client that was released, MetaMail, seems to handle this just fine. And MetaMail works with practically every existing user agent around. Oddly enough, the one thing MetaMail doesn't do well is default to handling unknown subtypes of multipart as mixed! > Making these decisions consistently across clients is critical to > interoperability. As an analogy, look at the issue of line lengths. > Everyone's read those virtually unreadable messages from someone writing in a > window that lets them put 85 characters on a line. Sure its 822 compliant, > but that doesn't make it easy to read. > Anyone want to add some case histories to this discussion? > One example: A side conversation with Ray Langford from Frontier Technologies > indicates that their SuperTCP mail client flattens hierarchy and treats > mp/alternative as mp/mixed. It also treats the first inline text part as the > message body that is presented to the user. The result of these choices is > that both our encodings result in the same appearance to the user. But in this case it doesn't matter which of your two approaches you use. Its a no-win situation either way. If anything this demonstrates a preference for multipart/alternative -- you lose nothing by using it now, but should Frontier ever fix their agent old messages will then be handled properly. Ned   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19123; 27 Jul 95 19:21 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa19119; 27 Jul 95 19:21 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa07392; 27 Jul 95 19:21 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id SAA10018 for ietf-822-list; Thu, 27 Jul 1995 18:20:58 -0400 Received: from osison.osiware.bc.ca (osison.osiware.bc.ca [134.87.18.1]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id SAA10014 for ; Thu, 27 Jul 1995 18:20:46 -0400 Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16350; Thu, 27 Jul 95 15:20:05 PDT Date: 27 Jul 95 15:12 PDT X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:12 PDT Action: Relayed Priority: urgent Ua-Content-Id: 950727346 P1-Message-Id: ca*infonet*iss;9507271512091629017 Original-Encoded-Information-Types: IA5-Text Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Wong To: awon@osison.osiware.bc.ca Cc: ietf-mixer@innosoft.com, ietf-822@dimacs.rutgers.edu, info-mime@cs.utk.edu, ruth@muswell.demon.co.uk Message-Id: <950727346*wong@vancouver.osiware.bc.ca> Subject: Re: EDI X.400/MIME conversions Importance: High At 5:55 AM 7/10/95, Ruth Moulton wrote: >The question I have for these mail lists is if anyone knows of any work >being done (or already done) in this area, i.e. specifying conversion >between X.435 other EDI formats, or X.435 and MIME ? You might also wish to query the edi working group mailing list (ietf-edi) and the more general edil-l list. d/ -------------------- Dave Crocker Brandenburg Consulting +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Page: +1 408 581 1174 USA dcrocker@brandenburg.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19522; 28 Jul 95 17:37 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa19518; 28 Jul 95 17:37 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa20085; 28 Jul 95 17:37 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id RAA03966 for ietf-822-list; Fri, 28 Jul 1995 17:04:25 -0400 Received: (from jak@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id RAA03962; Fri, 28 Jul 1995 17:04:24 -0400 Date: Fri, 28 Jul 95 17:04:23 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Jennifer A. Katinsky" To: ietf-smtp@dimacs.rutgers.edu, ietf-822@dimacs.rutgers.edu Subject: 822,smtp mailing lists Message-ID: Due to various constraints, I can no longer maintain the ietf-822 and ietf-smtp mailing lists. Therefore, as of August 9, 1995 the two above mentioned lists will be discontinued on dimacs.rutgers.edu. In an attempt to see these lists continue, I am asking your help with locating another site. If there is another site which is willing to house and maintain these mailing lists, along with their archive sites, I will help to make the transition a smooth one. Thank you for you help with this matter. All help is greatly appreciated. Jennifer Jennifer A. Katinsky (908)445-4592 jak@dimacs.rutgers.edu N2RDU Center for Discrete Mathematics & Theoretical Computer Science (DIMACS) Rutgers - The State University of New Jersey Systems Programmer P.O. Box 1179 CoRE Building - Busch Campus Piscataway, N.J. 08855-1179   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12602; 30 Jul 95 10:22 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12598; 30 Jul 95 10:22 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa10288; 30 Jul 95 10:22 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id KAA29906 for ietf-822-list; Sun, 30 Jul 1995 10:08:25 -0400 Received: from dkuug.dk (dkuug.dk [193.88.44.89]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id KAA29903; Sun, 30 Jul 1995 10:08:18 -0400 Received: by dkuug.dk id AA24664 (5.65c8/IDA-1.4.4j); Sun, 30 Jul 1995 16:08:03 +0200 Message-Id: <199507301408.AA24664@dkuug.dk> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keld J|rn Simonsen Date: Sun, 30 Jul 1995 16:08:02 +0200 In-Reply-To: "Jennifer A. Katinsky" "822,smtp mailing lists" (Jul 28, 23:44) X-Charset: ASCII X-Char-Esc: 29 Mime-Version: 1.0 Content-Type: Text/Plain; Charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Mnemonic-Intro: 29 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: "Jennifer A. Katinsky" , ietf-smtp@dimacs.rutgers.edu, ietf-822@dimacs.rutgers.edu Subject: Re: 822,smtp mailing lists "Jennifer A. Katinsky" writes: > > Due to various constraints, I can no longer maintain the ietf-822 and > ietf-smtp mailing lists. Therefore, as of August 9, 1995 the two above > mentioned lists will be discontinued on dimacs.rutgers.edu. > > In an attempt to see these lists continue, I am asking your help with > locating another site. If there is another site which is willing to house > and maintain these mailing lists, along with their archive sites, I > will help to make the transition a smooth one. > > Thank you for you help with this matter. All help is greatly appreciated. As said we can do it here. Just a few more remarks on our service: We run email lists for a number of standardisation groups in ISO/IEC JTC1, and our system has automatic archiving, with ftp and email access. We do maintenance of lists - chase errors and we have 3 people surveying and correcting errors. Our software do a number of things to keep the mail clean, such that error messages are not distributed to the list - etc. Keld   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28952; 31 Jul 95 20:20 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa28948; 31 Jul 95 20:20 EDT Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa27561; 31 Jul 95 20:20 EDT Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id UAA10575 for ietf-822-list; Mon, 31 Jul 1995 20:03:03 -0400 Received: from ns.frontiertech.com (root@ns.frontiertech.com [192.104.32.5]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id UAA10571 for ; Mon, 31 Jul 1995 20:02:46 -0400 Received: by FrontierTech.COM (8.6.9/8.6.9) with SMTP id TAA04169; Mon, 31 Jul 1995 19:02:08 -0500 X-Mailer: SuperTCP Pro for Windows Version 1.1 (Mailer Version 1.02) Message-ID: <301D6F2A-00000001@rock105.FrontierTech.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ray Langford Date: Mon, 31 Jul 1995 19:02:48 cdt Subject: Re: Multipart/Alternative Compatibility Issue To: Harald.T.Alvestrand@uninett.no Cc: Terry Crowley , Ned Freed , ietf-822@dimacs.rutgers.edu Reply-To: Ray@frontiertech.com MIME-Version: 1.0 Content-Type: Text/Plain; Charset=US-ASCII >Your comment about MAPI is interesting. >Is this full MAPI or restricted MAPI that only allows "attachments"? >Does it allow enclosed messages and full manipulation of body parts >within them, so that a solution that looks like the RFC 1495 definition >for X.400 is possible, or is it a lost cause? > >(new gateway document: the MIME to MAPI gateway....AARRGGHHHH....) > > Harald A Sorry for not getting back to you right away. We support the Simple MAPI interface so Windows applications can send Internet email via MAPI, so our concentration was towards that. All the internal modules (address book, message store, spooler, etc.) are based on MAPI APIs and we have a MAPI <-> RFC-822/MIME conversion that takes place at the lower levels when a message is sent/recieved. I would think that a RFC-1495 type document could be attempted. [...Isn't someone at Microsoft working on one now for their MIME/MAPI Internet email that is going to be in Win95? :-)] ======================================== Ray C. Langford Engineering Manager, Advanced Products Frontier Technologies Corp. Email: Ray@FrontierTech.com Voice: (414) 241-4555 x205 ========================================