From "Greg Vaudreuil " Thu Dec 27 18:17:02 1990 Flags: 000000000001 Received: from NRI.RESTON.VA.US by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA15468; Thu, 27 Dec 90 18:16:06 EST From: Greg Vaudreuil Date: Thu, 27 Dec 90 16:08:41 EST Org: Corp. for National Research Initiatives Phone: (703) 620-8990 ; Fax: (703) 620-0913 X-Mailer: Mail User's Shell (6.5 4/17/89) To: ietf-smtp@dimacs.rutgers.edu Subject: Minutes of the IETF 8bit meeting Message-Id: <9012271608.aa09951@NRI.NRI.Reston.VA.US> Below is a draft charter and the minutes for the meeting at IETF. Please send me any changes or additions as soon as possible so I can submitt them to the proceedings editor. Charte SMTP Extentions (smtpext) Charter Chair(s): Gregory Vaudreuil, gvaudre@nri.reston.va.us Mailing Lists: General Discussion: ietf-smtp@dimacs.rutgers.edu To Subscribe: ietf-smtp-request@dimacs.rutgers.edu Description of Working Group: The SMTP extentions working group is chartered to develop extentions to the base SMTP protocol Among the extentions to be considered are 1) elimination of the line length and 7 bit restrictions to allow the sending of binary information, and 2) the definition of specific body parts. Body parts are intended to allow the use of international character sets, the sending of arbitrary binary files. Goals and Milestones: March 90 Rewrite RFC 1154 to include specific types of body parts and encodings. March 90 Write a document for the sending of 8 bit character sets through 7 bit mailers with the TEX-HEX encoding scheme. March 90 Write a document specifying the elimination of line length restrictions and eliminating the 7 bit restrictions in SMTP. July 90 Submit the edited documents as Internet-Drafts December 90 Submit the documents as RFC's 1 CURRENT_MEETING_REPORT_ Reported by Greg Vaudreuil/ CNRI Minutes of December 4, 1990 This meeting began as a Birds of a Feather session to discuss a proposal from Jan Michael Rynning and Jonny Eriksson but soon widened to include broader enhansements to 822 to allow for body barts. Rynning and Eriksson's proposal suggested a mechanism to transmit 8 bit character sets through SMTP. The proposal consisted of 1) eliminating the 7bit restriction in SMTP, and in cases where 8 bit SMTP is not implimented 2) proposing a 7 but encoding for non-8 bit systems called TEX-HEX. The group found the proposal interesting, but primarily as a starting point for a re-examination of several SMTP issues. There was a consensus that the group should work to eliminate the 7 bit and 1000 character per line restrictions in SMTP. This will allow easier sending of binary files. Tom Kessler convinced the group that there was only minor code changes required for sendmail to accept 8 bit ASCII. Kessler further volunteered to author a document describing the changes to the SMTP protocol. A command "ebit" was proposed in the document by Rynning and Eriksson to identify new mailers. The group agreed that this extension should be considered for SMTP. An alternate HELO command could be defined to query a mailer for 8 bit compatibility, such as HELO8. The working group looked at RFC 1154 for encodings. Some felt that the document has short-comings in not differentiating between content and the encoding scheme. Greg Vaudreuil took an action to contact the author as inquire about the state of that document. The working group felt that establishing body parts for 822 mail would be a good thing. An outstanding issue remained concerning the interaction between the various encoding schemes as the 7 or 8 bit transmission systems. Rynning and Eriksson took an action to re-write their proposal for TEX-HEX as a specific encoding and body part to be used with the encoding document. Actions Tom Kessler: Write a document amending RFC 821 to eliminate the line length restriction and the 7 bit restriction. Greg Vaudreuil: Determine the state of RFC 1154, and encourage the author to join in this effort. Johnny Eriksson and Jan Michael Rynning: Rewrite the TEX HEX encoding document as a specific instance of an RFC 1154 body part. 1 Attendees Robert Braden braden@isi.edu Cyrus Chow cchow@orion.arc.nasa.gov Johnny Eriksson bygg@sunet.se Phillip Gross pgross@nri.reston.va.us Russell Hobby rdhobby@ucdavis.edu Tom Kessler kessler@sun.com Brad Parker brad@cayman.com Michael Roberts roberts@educom.edu Bernhard Stockman boss@sunet.se Jan Rynning jmr@nada.kth.se Dean Throop throop@dg-rtp.dg.com Gregory Vaudreuil gvaudre@nri.reston.va.us David Zimmerman dpz@dimacs.rutgers.edu 2 From "Phillip G. Gross " Fri Dec 28 16:11:42 1990 Flags: 000000000001 Received: from NRI.RESTON.VA.US by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA05905; Fri, 28 Dec 90 16:10:51 EST Date: Fri, 28 Dec 90 16:09:52 EST X-Mailer: Mail User's Shell (6.5 4/17/89) From: "Phillip G. Gross" To: Greg Vaudreuil , ietf-smtp@dimacs.rutgers.edu Subject: Re: Minutes of the IETF 8bit meeting Cc: pgross@nri.reston.va.us Message-Id: <9012281609.aa08878@NRI.NRI.Reston.VA.US> Greg, Thanks for getting the minutes out. Good job, although I have a couple small nits below (like leaving me out as the convenor of the BOF! :-) You might want to check with Tom Kessler to make sure I correctly characterized his comments about checking the possibly of distributing the SUN Sendmail binaries, and if he is willing to have these comments made available outside the WG (ie, in the Proceedings). BTW, in the future, please review your writing more carefully! "7 but", indeed! Thanks, Phill > Charter > > SMTP Extentions (smtpext) [Perhaps "Internet Mail Extentions" or "RFC 821/822 Extentions" would be more appropriate, since the most interesting aspect of the WG's goals (IMHO) deal with RFC 822, not just SMTP.] > > Chair(s): > Gregory Vaudreuil, gvaudre@nri.reston.va.us > > Mailing Lists: > General Discussion: ietf-smtp@dimacs.rutgers.edu > To Subscribe: ietf-smtp-request@dimacs.rutgers.edu > > Description of Working Group: > > The SMTP extentions working group is chartered to develop > extentions to the base SMTP protocol Among the extentions to be extentions to the basic SMTP protocol (RFC 821) and the format of Internet mail (as defined in RFC 822 "..title..", and proposed to be extended in RFC 1049 "..title.." and RFC 1154 "..title.."). > considered are 1) elimination of the line length and 7 bit > restrictions to allow the sending of binary information, and 2) > the definition of specific body parts. Body parts are intended > to allow the use of international character sets, the sending > of arbitrary binary files. Among the extentions to be considered to SMTP are the elimination of the line length and 7 bit restrictions to allow the sending of binary information. Among the extensions to RFC 822 are the definition of specific standard body parts. Body parts are intended to allow the sending of arbitrary binary files, the sending of structured mail, and the use of alternate encoding of international character sets for mailers that do not understand eight bit characters. > > Goals and Milestones: > > March 90 Rewrite RFC 1154 to include specific types of body parts > and encodings. > March 90 Write a document for the sending of 8 bit character sets > through 7 bit mailers with the TEX-HEX encoding scheme. > March 90 Write a document specifying the elimination of line > length restrictions and eliminating the 7 bit > restrictions in SMTP. > July 90 Submit the edited documents as Internet-Drafts > December 90 Submit the documents as RFC's [How about a bit more detail (eg to include implementations) and to have a slightly different priority (like doing the work next year, instead of last year :-).] 1. By March 91 IETF meeting a. Write a document specifying the elimination of line length restrictions and eliminating the 7 bit restrictions in SMTP. b. Consider revising RFC 1154 to include specific types of body parts and encodings. c. Write a document defining a body part for the sending of 8 bit character sets through 7 bit mailers with the TEX-HEX encoding scheme. 2. By May 1991 Submit the 3 edited documents as Internet-Drafts 3. By (and at) July 1991 IETF Meeting Encourage distribution and deployment of mailers complying with Goal 1a above. Encourage distribution and deployment of mail readers complying with Goals 1b. and 1c. above. 4. By (or at) December 1991 IETF Meeting Finalize the 3 above documents. Submit a recommendation to the IESG to forward the 3 above documents to the IAB and RFC Editor as Proposed Internet Standards. > > 1 > > > CURRENT_MEETING_REPORT_ > > Reported by Greg Vaudreuil/ CNRI > > Minutes of December 4, 1990 > > This meeting began as a Birds of a Feather session to discuss a > proposal from Jan Michael Rynning and Jonny Eriksson but soon widened > to include broader enhansements to 822 to allow for body barts. This meeting began as a Birds-of-a-Feather session organized by Phill Gross (CNRI) to discuss a proposal from Jan Michael Rynning (NORDUnet) and Jonny Eriksson (NORDUnet) for utilizing international character sets in Internet mail (ie, RFC 821/822 mail). Gross had become aware of the Rynning/Eriksson proposal by way of interaction with the Nordic Engineering Task Force (NETF). Rynning and Eriksson in Sweden joined the discussion in Boulder by speakerphone. This speakerphone exercise was interesting to explore a possible way to allow more international participation in IETF WG sessions. Although use of a speakerphone is not optimal for large meetings, it at least enables some level of participation by folks who are unable to attend the meeting, and who would therefore not be able to participate at all. In this case, the speakerphone interaction went fairly smoothly, and we were very pleased to have Rynning and Eriksson join the meeting in this way. The discussion soon widened to include broader enhancements to RFC 822 to allow for general body parts. It was clear that there was enough interest and enthusiam to evolve this BOF into an IETF WG. Greg Vaudreuil (CNRI) kindly volunteered to chair the WG. Gross gladly turned over the gavel. > Rynning and Eriksson's proposal suggested a mechanism to transmit 8 > bit character sets through SMTP. The proposal consisted of 1) > eliminating the 7bit restriction in SMTP, and in cases where 8 bit > SMTP is not implimented 2) proposing a 7 but encoding for non-8 bit SMTP is not implemented 2) proposing a 7 bit encoding for non-8 bit - - > systems called TEX-HEX. > > The group found the proposal interesting, but primarily as a starting > point for a re-examination of several SMTP issues. There was a > consensus that the group should work to eliminate the 7 bit and 1000 > character per line restrictions in SMTP. This will allow easier > sending of binary files. Tom Kessler convinced the group that there sending of binary files. Tom Kessler (SUN) convinced the group that there > was only minor code changes required for sendmail to accept 8 bit > ASCII. Kessler further volunteered to author a document describing the > changes to the SMTP protocol. A command "ebit" was proposed in the changes to the SMTP protocol. A command "EBIT" was proposed in the > document by Rynning and Eriksson to identify new mailers. The group > agreed that this extension should be considered for SMTP. An alternate > HELO command could be defined to query a mailer for 8 bit > compatibility, such as HELO8. compatibility, such as "HELO8". Kessler had already made changes to the SUN Sendmail to eliminate the line length and 7 bit restrictions. He was willing to consider adding whichever of the proposed "EBIT" or "HELO8" SMTP commands that the WG finally decided on. He was also willing to investigate the possibility of SUN allowing the binary distribution of this new version of Sendmail. This was a very exciting prospect because it opened up the possibility fairly rapid deployment of the proposed changes to SMTP (at least for those folks who still use Sendmail). At future meetings, the WG may want to investigate sources of revised versions of other popular mailers, like MMDF. > > The working group looked at RFC 1154 for encodings. Some felt that > the document has short-comings in not differentiating between content > and the encoding scheme. Greg Vaudreuil took an action to contact the > author as inquire about the state of that document. The working group > felt that establishing body parts for 822 mail would be a good thing. > An outstanding issue remained concerning the interaction between the > various encoding schemes as the 7 or 8 bit transmission systems. > > Rynning and Eriksson took an action to re-write their proposal for > TEX-HEX as a specific encoding and body part to be used with the > encoding document. > > Actions > > > Tom Kessler: Write a document amending RFC 821 to eliminate the line > length restriction and the 7 bit restriction. > Greg Vaudreuil: Determine the state of RFC 1154, and encourage the > author to join in this effort. > Johnny Eriksson and Jan Michael Rynning: Rewrite the TEX HEX encoding > document as a specific instance of an RFC 1154 body part. > > 1 > > > > Attendees > > Robert Braden braden@isi.edu > Cyrus Chow cchow@orion.arc.nasa.gov > Johnny Eriksson bygg@sunet.se > Phillip Gross pgross@nri.reston.va.us > Russell Hobby rdhobby@ucdavis.edu > Tom Kessler kessler@sun.com > Brad Parker brad@cayman.com > Michael Roberts roberts@educom.edu > Bernhard Stockman boss@sunet.se > Jan Rynning jmr@nada.kth.se > Dean Throop throop@dg-rtp.dg.com > Gregory Vaudreuil gvaudre@nri.reston.va.us > David Zimmerman dpz@dimacs.rutgers.edu > > > > 2 > From "kessler@hacketorium.eng.sun.com (Tom Kessler)" Wed Jan 2 16:26:44 1991 Flags: 000000000001 Received: from SUN.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA17577; Wed, 2 Jan 91 16:25:48 EST Received: from Eng.Sun.COM (exodus-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA03538; Wed, 2 Jan 91 13:25:40 PST Received: from hacketorium.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA19588; Wed, 2 Jan 91 13:25:39 PST Received: by hacketorium.Eng.Sun.COM (4.1/SMI-4.1) id AA00363; Wed, 2 Jan 91 13:24:42 PST Date: Wed, 2 Jan 91 13:24:42 PST From: kessler@hacketorium.eng.sun.com (Tom Kessler) Message-Id: <9101022124.AA00363@hacketorium.Eng.Sun.COM> To: "Phillip G. Gross" Cc: Greg Vaudreuil , ietf-smtp@dimacs.rutgers.edu, pgross@nri.reston.va.us In-Reply-To: <9012281609.aa08878@NRI.NRI.Reston.VA.US> Subject: Re: Minutes of the IETF 8bit meeting I think it would be best to drop the mention of Sun making the binaries available outside of the working group. My management is allowing me to spend a little time to do the same changes to the generic berkeley sendmail release. I believe that I will be able to make the diffs to the Berkeley source publicly available. I probably will not be able to make a release of the Sun binaries available widely do to hassle of having to go through the sun release process plus the usual liability issues. --Tom From "Phillip G. Gross " Wed Jan 2 22:32:42 1991 Flags: 000000000001 Received: from NRI.RESTON.VA.US by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA26050; Wed, 2 Jan 91 22:30:59 EST Date: Wed, 2 Jan 91 22:30:03 EST X-Mailer: Mail User's Shell (6.5 4/17/89) From: "Phillip G. Gross" To: Tom Kessler , "Phillip G. Gross" Subject: Re: Minutes of the IETF 8bit meeting Cc: Greg Vaudreuil , ietf-smtp@dimacs.rutgers.edu Message-Id: <9101022230.aa14982@NRI.NRI.Reston.VA.US> Tom, Thanks. I think that what you suggest is just as effective. My thanks to SUN for allowing you the time to do that. We should see that SUN gets some kudos for that, if that is agreeable to SUN. Thanks, Phill From "Jan Michael Rynning " Thu Jan 10 09:54:37 1991 Flags: 000000000001 Received: from cyklop.nada.kth.se by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA04490; Thu, 10 Jan 91 09:53:45 EST Received: by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA02196; Thu, 10 Jan 91 15:53:15 +0100 Date: Thu, 10 Jan 91 15:53:14 +0100 From: Jan Michael Rynning To: Greg Vaudreuil Cc: ietf-smtp@dimacs.rutgers.edu Subject: Re: Minutes of the IETF 8bit meeting In-Reply-To: Your message of Thu, 27 Dec 90 16:08:41 EST Message-Id: Greg Vaudreuil writes in his minutes: > ... A command "ebit" was proposed in the > document by Rynning and Eriksson to identify new mailers. The group > agreed that this extension should be considered for SMTP. An alternate > HELO command could be defined to query a mailer for 8 bit > compatibility, such as HELO8. RFC 821 specifies the command syntax like this: > 4.1.1. COMMAND SEMANTICS > > The SMTP commands define the mail transfer or the mail system > function requested by the user. SMTP commands are character > strings terminated by . The command codes themselves are > alphabetic characters terminated by if parameters follow > and otherwise. The syntax of mailboxes must conform to > receiver site conventions. The SMTP commands are discussed > below. The SMTP replies are discussed in the Section 4.2. Consequently, we can't have commands with non-alphabetic characters, like HELO8, unless we change the syntax. On second thought, it may be a good idea to generalize the proposed EBIT into a do-you-support- this-feature command, let's call it FEAT. To inquire if the receiver can handle 8-bit data, the SMTP sender would then say FEAT EIGHTBIT. Greg Vaudreuil writes in his minutes: > Rynning and Eriksson's proposal suggested a mechanism to transmit 8 > bit character sets through SMTP. The proposal consisted of 1) > eliminating the 7bit restriction in SMTP, and in cases where 8 bit > SMTP is not implimented 2) proposing a 7 but encoding for non-8 bit > systems called TEX-HEX. TEXT-HEX. It's a mixture of plain TEXT and HEX encoded characters. I'm curious: To me ``Rynning and Eriksson's proposal'' means the same as ``Eriksson's proposal and Rynning''. I would have used ``Rynning's and Eriksson's proposal''. Are they both correct English? Is there any difference in meaning? Greg Vaudreuil writes in his minutes: > Jan Rynning jmr@nada.kth.se Jan Michael Rynning jmr@nada.kth.se Some people call me by both my given names. Most people call me by my first name or my initials. From "Greg Vaudreuil " Tue Jan 15 13:49:27 1991 Flags: 000000000001 Received: from NRI.RESTON.VA.US by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA02821; Tue, 15 Jan 91 13:46:33 EST From: Greg Vaudreuil Date: Tue, 15 Jan 91 13:45:34 EST Org: Corp. for National Research Initiatives Phone: (703) 620-8990 ; Fax: (703) 620-0913 X-Mailer: Mail User's Shell (6.5 4/17/89) To: ietf-smtp@dimacs.rutgers.edu Subject: Welcome and Mail Issues Message-Id: <9101151345.aa11729@NRI.NRI.Reston.VA.US> Howdy. For those folks who have recently joined the mailing list, I am resending the minutes from the first organizational meeting of this group at the last IETF in Boulder. The group focused on two main points, 1) Extensions of SMTP to allow binary files, 2) and standardizing a mechanism for including body parts. At the first meeting, the group discussed the RFC 1154 method for encoding body parts. At the meeting I took an action to contact the authors of 1154 and discuss the mail extensions effort and specifically the encoding method of RFC 1154. I contacted David Robinson, one of the authors of RFC 1154. During the working group meeting, many felt that the RFC 1154 approach was seriously flawed by not specifying a content-type field along with encoding field. The group recognized that a single body type can be encoded several different ways and did not see how to reconcile that with the document. Robinson responded that a basic assumption in RFC 1154 was that SMTP would continue to have a 7 bit restriction, and all body parts would use a 7 bit encodings. In this case, a particular encoding type would imply a content type. The working group has begun with a different assumption, that eight bit smtp implementations will be intermixed with seven bit systems. In this situation, there are at least two different encoding schemes necessary, one for 7 bit and one for 8 bit systems. After by announcement to tcp-ip and IETF, I have received several comments about the specific approach of this working group to multi-media mail and the groups relationship to various X.400 efforts. I encourage a discussion on this topic. My main objective is to standardize on a format and several encodings so user-agents can be deployed. I have heard of 7+ Multi-media mail implementations, a number sufficient to demonstrate a real pent up need. This group would not exist if X.400 was widely deployed or likely to be within the near term. However, I would like to facilitate easy interoperation between the two systems. Comments? Below I have a preliminary list of issues this group should focus on: 1) To what extent should we follow X.400's efforts in currently defined body parts? With whom should the group interact? 2) Should a message encoding imply a content type, or can these be independent axis. Implementation is easier with fewer options. A single encoding with a standard 7bit to 8bit conversion process may be possible, but the conversion may render text unreadable to unmodified UA. Other encoding mechanisms like TEX-HEX maintain at least limited utility between conversions. 3) Some have folks have expressed an interest in maintaining the 7 bit restriction on text, but allowing a binary mode. I personally feel this is doing a disservice to international network users who's character sets are not 7 bit ascii. 4) Should the SMTP extensions include a general purpose option negotiation sequence? Currently the group is talking about a single new command to detect modified 8bit, no line length restricted mailers. Personally I don't see other options needed and would like to avoid the option negotiation. Enough for starters. Greg V. CURRENT_MEETING_REPORT_ Reported by Greg Vaudreuil/ CNRI SMTPEXT Minutes of December 4, 1990 This meeting began as a Birds of a Feather session called by Phill Gross (CNRI) to discuss two SMTP related proposals. Jan Michael Rynning (NORDUnet) and Johnny Eriksson (NORDUnet), participating by telephone, presented a method for transmitting eight bit character sets over SMTP. A proposal for a standard List-Service syntax for the Internet was made by Greg Vaudreuil (CNRI). The discussion broadened a bit and resulted in the formation of a working group to consider enhancements to SMTP and RFC 822 to allow for body parts. Rynning's and Eriksson's proposal suggested a mechanism to transmit 8 bit character sets through SMTP. The proposal consisted of 1) eliminating the 7bit restriction in SMTP, and in cases where 8 bit SMTP is not implemented 2) proposing a 7 bit encoding for non-8 bit systems called TEX-HEX. TEX-HEX is a mixture of plain ASCII TEXT and HEX encoded characters. The group found the proposal interesting, but primarily as a starting point for a re-examination of several SMTP issues. There was a consensus that the group should work to eliminate the 7 bit and 1000 character per line restrictions in SMTP. This will allow easier sending of binary files. Tom Kessler (SUN) convinced the group that there was only minor code changes required for sendmail to accept 8 bit ASCII. Kessler further volunteered to author a document describing the changes to the SMTP protocol. A command "EBIT" was proposed in the document by Rynning and Eriksson to identify new mailers. The group agreed that this extension should be considered for SMTP. An alternate HELO command could be defined to query a mailer for 8 bit compatibility, such as HELO8. The working group looked at RFC 1154 for defining encodings of specific body parts. Some felt that the document has short-comings in not differentiating between content and the encoding scheme. Greg Vaudreuil took an action to contact the author as inquire about the state of that document. The working group felt that establishing body parts for 822 mail would be a good thing. An outstanding issue remained concerning the interaction between the various encoding schemes as the 7 or 8 bit transmission systems. 1 Rynning and Eriksson took an action to re-write their proposal for TEX-HEX as a specific encoding and body part to be used with the encoding document. John Veizadez (Apple) stopped in to the meeting to brief the group about Unicos, a universal text encoding scheme developed at Zerox and Apple. This scheme used 2 octets to represent all known characters. Chris Myers (U-Wash) explained the list service offered by Washington University, and explained may of the features of Bitnet's ListServ. Myers took an action to distribute the listserv document to those in the group who had an interest. The group did not come to a consensus on whether to pursue this topic at this time. Actions Tom Kessler Write a document amending RFC 821 to eliminate the line length restriction and the 7 bit restriction. Greg Vaudreuil Determine the state of RFC 1154, and encourage the author to join in this effort. Johnny Eriksson and Jan Michael Rynning Rewrite the TEX HEX encoding document as a specific instance of an RFC 1154 body part. From "Ned Freed, Postmaster " Tue Jan 15 14:57:57 1991 Flags: 000000000001 Received: from CBROWN.CLAREMONT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA05163; Tue, 15 Jan 91 14:55:54 EST Date: Tue, 15 Jan 1991 11:55 PST From: "Ned Freed, Postmaster" Subject: RFC1154 To: ietf-smtp@dimacs.rutgers.edu Message-Id: X-Envelope-To: ietf-smtp@dimacs.rutgers.edu X-Vms-To: IN%"ietf-smtp@dimacs.rutgers.edu" My big problem with RFC1154 is not in what headers it specifies or what encodings it uses. Stuff like this is of less concern than the fundamental approach that RFC1154 advocates to encapsulation; you can always fix the lack of a particular piece of information by adding it later (and RFC822 certainly is extensible enough to allow such additions). I think the major problem with RFC1154 is that it employs line counting as a strategy for encapsulation. This is a terrible idea. The world is full of mailers that do all kinds of things to message text, including all sorts of different forms of line wrapping. The single most prevalent example of widespread line wrapping is BITNET, where inherent format limitations often force wrapping as the only means of converting messages to an acceptable format (we're talking 80 columns here). There are countless other examples, of course, including all those word processors out there that reformat documents automatically and often without the user noticing. Thus, I believe that if we start using line counting as a common strategy for encapsulation, we're buying into a nightmare situation of obscure bugs, processing problems, and trashed messages. We're also buying into the need to write code that hunts around for shifting boundaries in messages. I for one have better things to do with my development time! The alternative to line counts to delimit bodyparts is the use of special delimiters and character stuffing, aka RFC934. Now, I'm not especially fond of the particular approach that RFC934 advocates. It also needs to have some details tightened up insofar as bodypart-specific header lines (mandatory or optional -- the seem to be mandatory, but the spec never comes out and says so) are concerned. However, it does have the advantage of current widespread use, several other RFCs depend on it (RFC987 is one), and I know of no real technical problems with it. RFC934 tolerates line wrapping quite nicely in most cases. (There are some cases where it will get confused, and these do need to be looked at.) Anyway, if this community thinks that line counting is really the way to go, or has a real positivie reason for wanting to use it, I'll follow along. But I do want to see some discussion of this point before we all buy into RFC1154's approach. Ned From "kessler@hacketorium.eng.sun.com (Tom Kessler)" Wed Jan 16 13:33:33 1991 Flags: 000000000001 Received: from Sun.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA00617; Wed, 16 Jan 91 13:30:04 EST Received: from Eng.Sun.COM (exodus-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA09986; Wed, 16 Jan 91 10:29:55 PST Received: from hacketorium.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA00848; Wed, 16 Jan 91 10:29:51 PST Received: by hacketorium.Eng.Sun.COM (4.1/SMI-4.1) id AA03023; Wed, 16 Jan 91 10:28:42 PST Date: Wed, 16 Jan 91 10:28:42 PST From: kessler@hacketorium.eng.sun.com (Tom Kessler) Message-Id: <9101161828.AA03023@hacketorium.Eng.Sun.COM> To: Greg Vaudreuil In-Reply-To: <9101161148.aa07847@NRI.NRI.Reston.VA.US> Subject: SMTP changes stuff Cc: ietf-smtp@dimacs.rutgers.edu I've held off doing the work for a bit in part to see what sort of discussion(s) cranked up. I wonder whether we might want to implement something like an EXTHELO or OPTHELO or HELOOPT command. This command could take as arguments options or extensions which you might wish to support. E.g. you might get something like OPTHELO BINARY BATCH FUNKYOPTION hostname.domain.name A reply could contain information about which options you support (or unknown command if you don't support any). The tricky part being that this would make host names which are the same as any options we define because it's amibguous as to whether BATCH is your name or BATCH is an option. The main advantage to loading the option(s) into the hello command is that you save an extra round trip when you setup the connection. Is it worth going to the trouble to do this, or would folks rather see something like a seperate BINARY (or EBIT or whatever) command. I am interested in what people think about this. --Tom Kessler From "Greg Vaudreuil " Wed Jan 16 14:49:26 1991 Flags: 000000000001 Received: from NRI.RESTON.VA.US by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA03415; Wed, 16 Jan 91 14:45:55 EST Received: from NRI by NRI.NRI.Reston.VA.US id aa12867; 16 Jan 91 14:36 EST To: Tom Kessler Cc: Greg Vaudreuil , ietf-smtp@dimacs.rutgers.edu Subject: Re: SMTP changes stuff In-Reply-To: Your message of Wed, 16 Jan 91 10:28:42 -0800. <9101161828.AA03023@hacketorium.Eng.Sun.COM> Date: Wed, 16 Jan 91 14:36:01 -0500 From: Greg Vaudreuil Message-Id: <9101161436.aa12867@NRI.NRI.Reston.VA.US> >The main advantage to loading the option(s) into the hello command is that >you save an extra round trip when you setup the connection. Is it worth >going to the trouble to do this, or would folks rather see something like >a seperate BINARY (or EBIT or whatever) command. I would prefer not to do option negotiation, and instead define a set of helo commands that accomplish the same ends. HELO (7 bit mail) HELOBINARY (8 bit mail, no line restriction) HELOBATCH (Batched mail jobs, 8 bit, no line restriction)) All modified mailer doing batch mail should also be modified to accept binary mail at the same time. If a command unrecognized results from any of these commands, a fallback to HELO is reasonable. This is in fact negotiation without the overhead of parsing a line of n options. By eliminating certian non-sensical, or non-optimal combinations the number of HELO commands can be sufficiently small. Greg V. From "kessler@hacketorium.eng.sun.com (Tom Kessler)" Wed Jan 16 16:44:20 1991 Flags: 000000000001 Received: from Sun.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA07306; Wed, 16 Jan 91 16:41:07 EST Received: from Eng.Sun.COM (exodus-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA06886; Wed, 16 Jan 91 13:40:59 PST Received: from hacketorium.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AB25652; Wed, 16 Jan 91 13:40:56 PST Received: by hacketorium.Eng.Sun.COM (4.1/SMI-4.1) id AA03479; Wed, 16 Jan 91 13:39:49 PST Date: Wed, 16 Jan 91 13:39:49 PST From: kessler@hacketorium.eng.sun.com (Tom Kessler) Message-Id: <9101162139.AA03479@hacketorium.Eng.Sun.COM> To: Greg Vaudreuil Cc: Tom Kessler , Greg Vaudreuil , ietf-smtp@dimacs.rutgers.edu In-Reply-To: <9101161436.aa12867@NRI.NRI.Reston.VA.US> Subject: Re: SMTP changes stuff That sounds reasonable to me. That will certainly keep things simple. From stef@nma.com Wed Jan 16 17:39:38 1991 Flags: 000000000001 Received: from RUTGERS.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA09143; Wed, 16 Jan 91 17:35:17 EST Received: from nrtc.northrop.com by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA16942; Wed, 16 Jan 91 17:35:05 EST Received: from nma.com by nrtc.nrtc.northrop.com id aa25645; 16 Jan 91 14:34 PST Received: from localhost by nma.com id aa10167; 16 Jan 91 13:38 PST To: ietf-smtp@dimacs.rutgers.edu Subject: Re: SMTP changes stuff In-Reply-To: Your message of Wed, 16 Jan 91 10:28:42 -0800. <9101161828.AA03023@hacketorium.Eng.Sun.COM> Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Wed, 16 Jan 91 13:38:22 -0800 Message-Id: <10162.664061902@nma> Sender: stef@nma.com It should be trivial to avoid confusion with host names in the arg list by just using some characters in the args that are illegal in any host name.domain...\Stef From "Mark Crispin " Wed Jan 16 17:46:03 1991 Flags: 000000000001 Received: from akbar.cac.washington.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA09358; Wed, 16 Jan 91 17:41:50 EST Received: from tomobiki-cho.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.21 ) id AA02583; Wed, 16 Jan 91 14:41:40 -0800 Date: Wed, 16 Jan 1991 14:18:47 -0800 (PST) From: Mark Crispin Sender: Mark Crispin Subject: re: SMTP changes stuff To: kessler@hacketorium.eng.sun.com Cc: Greg Vaudreuil , ietf-smtp@dimacs.rutgers.edu In-Reply-To: <9101161828.AA03023@hacketorium.Eng.Sun.COM> Message-Id: I don't care for the idea of fooling around with the HELO command on the grounds that too many sites get it wrong as it is. I believe that SMTP commands should continue to be four characters, for the possible benefit of implementations that use this fact. I also feel that we should use the right tool for the right task. To wit, we should not overload a functionality unnecessarily. We should separate the function of specifying data characteristics from other functionalities which belong at the control level. I propose that we do something along these lines: 1. Control-level functions should be handled by new SMTP commands. I'm not really sure how many of these there are. I don't, for example, understand what the need is for an explicit BATCH control command. 2. Functionalities which identify the form of SMTP data should be options to a new XDAT command. XDAT is similar to DATA, except: a) it takes one or more subcommands identifying the form of the data (e.g. BINARY, 8BIT) b) the data follows such a form. If XDATA is rejected, then the DATA command is used and the message is transmitted as 7-bit data as before. We'll need some encoding scheme and add some magic cookie into the header to identify such a transformation. A smart SMTP server or mailer, upon seeing the magic cookie, will transform it back and flush the cookie before passing it on. It is important to know that the structure of the data is beyond the scope of SMTP. All we're dealing with here is binary vs. text (with possible newline convention differences) and with 7-bit vs. 8-bit (ISO). We're not saying what the data will look like. 3) The structure of data will be specified by a successor to RFC-1154. As an implementor of RFC-1154, I would like to see some extensions here, specifically in the areas of more defined types, more information for things like UUENCODE (is the file Unix compressed? tared? What is the file name without looking at the data??), and a less ambiguous definition of the boundaries between segments. The problem with using "lines" is that a "line" means different things on different operating systems. There is no way on Unix, for example, to distinguish between a bare LF and a new line. I would like the definition of an RFC-1154 "line" to explicitly state that a CR *or* an LF constitute a "line", with the exception that an LF immediately following a CR is not counted. Hopefully this will let texts with possible bare LF's or CR's get transferred without getting line counts messed up. I would also like to see some explicit cookie in the message body between segments, as opposed to a blank line. This is to allow an application to resynchronize in case it finds that a line count is messed up. Regards, -- Mark -- From stef@nma.com Wed Jan 16 23:59:06 1991 Flags: 000000000001 Received: from RUTGERS.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA18443; Wed, 16 Jan 91 23:55:11 EST Received: from nrtc.northrop.com by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA07222; Wed, 16 Jan 91 23:55:02 EST Received: from nma.com by nrtc.nrtc.northrop.com id aa27056; 16 Jan 91 20:54 PST Received: from localhost by nma.com id aa10635; 16 Jan 91 19:52 PST To: ietf-smtp@dimacs.rutgers.edu Subject: Re: SMTP changes stuff In-Reply-To: Mark Crispin's message of Wed, 16 Jan 91 14:18:47 -0800. Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Wed, 16 Jan 91 19:52:03 -0800 Message-Id: <10630.664084323@nma> Sender: stef@nma.com I realize that this may receive an unfavorable greeting, but here it is anyway. I suggest that any SMTP extensions take full account of X.400 standards and allow for the carriage of X.400 P2 BodyParts (84 or 88) and allow for some form of faithful carriage of all the Service Elements from P1 in an appropriate way such that they can be reconstructed for reentry into an X.400 P1 transfer service at the receiving end of an SMTP transfer. I believe that this is simply done by making it easy to use, carry, and recognize X.409/ASN.1 encoded objects. The only requirements that I see are to allow 8bit transmission, and allow for X.400 X.409/ASN.1 objects to be labeled as such, without conflicting with the labeling and encoding of other objects. I see no reason to do anything at this point that would hinder carriage of ASN.1/X.409 objects, when no SMTP Extension encoding decisions have yet been made, and we agree that new encodings and labeling are both needed. It might, but is not a requirement of mine, be useful to consider using ASN.1 encoding for all the new 8bit objects, using the X.400(88) standards. I am not sure I see good reasons to develop and adopt yet another set of encoding rules, unless they are demonstrably better in really significant ways. Whatever is done, it will be a great tragedy if SMTP Extensions are deliberately "hostile" to interworking with X.400. Best...\Stef From "Mark Crispin " Thu Jan 17 00:24:35 1991 Flags: 000000000001 Received: from akbar.cac.washington.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA18936; Thu, 17 Jan 91 00:21:08 EST Received: from tomobiki-cho.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.21 ) id AA11869; Wed, 16 Jan 91 21:21:03 -0800 Date: Wed, 16 Jan 1991 21:14:51 -0800 (PST) From: Mark Crispin Sender: Mark Crispin Subject: Re: SMTP changes stuff To: Stef@ics.uci.edu Cc: ietf-smtp@dimacs.rutgers.edu In-Reply-To: <10630.664084323@nma> Message-Id: Stef - I'm sure that doing something like this is intended. Actually, in some ways RFC-1154 already does much of this. Please take a look at the RFC; it's a good first stab at the problem. I've written an RFC-1154 implementation. I think you might engender some controversy in forcing ASN.1 encoding for all 8-bit transmission though... -- Mark -- From stef@nma.com Thu Jan 17 04:59:02 1991 Flags: 000000000001 Received: from RUTGERS.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA24397; Thu, 17 Jan 91 04:55:28 EST Received: from nrtc.northrop.com by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA25945; Thu, 17 Jan 91 04:55:17 EST Received: from nma.com by nrtc.nrtc.northrop.com id ac27765; 17 Jan 91 1:54 PST Received: from localhost by nma.com id aa11277; 17 Jan 91 1:38 PST To: Mark Crispin Cc: ietf-smtp@dimacs.rutgers.edu Subject: Re: SMTP changes stuff In-Reply-To: Your message of Wed, 16 Jan 91 21:14:51 -0800. Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Thu, 17 Jan 91 01:38:15 -0800 Message-Id: <11272.664105095@nma> Sender: stef@nma.com Status: O Hi Mark -- I will be reviewing RFC1154 carefully, since it seems to be what some of you are pushing to upgrade RFC821/RFC822. If you reread my message, you will see that I am very carefully saying that I want to be able to carry ASN.1 encoded objects without complication, but not saying anything about exclusivity for ASN.1. I do suggest however, that you give serious thought to ways to be sure that you have unique identifiers, and it will be important to allow use of the regularly defined and registered X.400 object OIDs. This should be done without requiring a rewrite of the new RFCsmtp for every new oobject that is to be allowed carriage. Best...\Stef From "Robert Ullmann " Thu Jan 17 11:25:56 1991 Flags: 000000000001 Received: from RUTGERS.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA02253; Thu, 17 Jan 91 11:21:33 EST Received: from Relay.Prime.COM by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA00719; Thu, 17 Jan 91 11:21:26 EST Message-Id: <9101171621.AA00719@rutgers.edu> Received: (from user ARIEL) by Relay.Prime.COM; 17 Jan 91 11:23:53 EST To: IETF SMTP list From: Robert Ullmann Subject: comments on the SMTP session protocol Date: 17 Jan 91 11:23:54 EST Hi, I think there are a number of aspects of SMTP that have contributed to its success, but are poorly understood by most users and implementors. It worries me to see proposals that add to or modify the protocol in ways that break some of the (IMHO) most important characteristics. In attempting to explain, I will use a few terms from OSI. (Of course I have studied OSI: I have to know it in order to point out is deficiencies with some credibility :-) Like "SPDU": Session Protocol Data Unit. In internet terms: the "packet" used at the session layer. STMP and RFC822 are both defined in terms of a simple SPDU: a line of ASCII text. SMTP uses a half-duplex exchange of these protocol units, while RFC822 defines an object consisting of an ordered set of the same protocol units. This definition has a number of very clear advantages over, say, ASN.1 or some other encoding: * It is machine-independent: ASCII is the ANSI Standard Code for Information Interchange. "Interchange" being the operative word. Systems using other character sets define conversions to ASCII. * each "packet" is a bounded object, known to fit in a record or buffer that is 1000+n octets for some small, fixed, value of n. [need I repeat that the world is not Unix at this point? OK, I won't :-] * The content and representation of each packet or SPDU is human-readable. Where appropriate (almost everywhere) the actual value of the content is readable. Remember, the machines are here to serve the humans, not the other way around! * The SPDUs are self delimiting (if you count the CRLF as included in the end of the "packet"), both in the protocol and in the objects being moved. The combination of these factors make SMTP implementable in a real sense on any hardware and software architechture. They contribute directly to the simple, easy addition of user interfaces and other application interfaces. I would recommend NOT un-bounding line lengths. This will make implementation substantially more difficult in some (most?) environments, and is not upward compatible with current implementations. I don't think "text" with "lines" that are not bounded is real text anyway: it should probable be encoded somehow. (see later, as-yet-unwritten, messages to this discussion :-) RFC1154 takes the definition of a mail message as an ordered set of SPDUs, (lines, remember?) and specifies a rigorous method of identifying the parts that are each contained object. This does not necessitate changes to the MTAs (Mail Transfer Agents, another ISOmorphism :-). This is crucial in my opinion: we aren't going to get any MTA change rolled out anytime in the 1990's to anything approaching universality; and the MTA should not care (read "MUST NOT interfere with") what is being sent anyway. The only useful change I can see making to the MTAs (and to the definition of the SPDUs) is to define the character code used as ISO8859/1 aka ASCII-8. This will not take as long to roll out: some implementations are "compliant" already, while others are trivial to fix. ("sendmail" can be fixed by the simple deletion of two lines of code.) After all: why clear the "high" bit if you don't have to? This has already been done by some vendors, and has been proven to NOT cause interoperability problems. Messages that go through a 7-bit mailer get the bit cleared, but get delivered. After a while, such mailers will be viewed as broken. Encodings that do a complete transform of the input object (uuencode, btoa, hex, FS, LZJU90 (see another future message ;-)) produce a 6 or 7 bit encoding known to survive various gates and conversions, and thus will survive such "broken" mailers. Best Regards, Rob Ullmann +1 508 620 2800 x1736 Ariel@Relay.Prime.COM From "Nathaniel Borenstein " Thu Jan 17 11:50:50 1991 Flags: 000000000001 Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA02917; Thu, 17 Jan 91 11:47:06 EST Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for IETF-SMTP@dimacs.rutgers.edu; Thu, 17 Jan 91 11:47:02 EST Received: by greenbush.bellcore.com (4.12/4.7) id for IETF-SMTP@dimacs.rutgers.edu; Thu, 17 Jan 91 11:49:31 est Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.greenbush.mouseclub.sun4.40 via MS.5.6.greenbush.mouseclub.sun4_40; Thu, 17 Jan 1991 11:49:28 -0500 (EST) Message-Id: Date: Thu, 17 Jan 1991 11:49:28 -0500 (EST) From: Nathaniel Borenstein To: IETF SMTP list Subject: Re: comments on the SMTP session protocol In-Reply-To: <9101171621.AA00719@rutgers.edu> References: <9101171621.AA00719@rutgers.edu> I think Robert is right -- unbounding line lengths will be a major amount of work, and it is really unncessary. Why? Because one can define a special RFC 1049 content-type for multi-part messages, in which multiple parts are encapsulated in the body using some structure that is NOT sensitive to the line length problems. (Andrew is an existence proof that this can be done.) Obviously we can all live with RFC1154 if and when all the mailers are upgraded to deal with the line length problem, but it seems like a lot of unnecessary work when simpler solutions are available. -- Nathaniel From "Ole Bj|rn Hessen " Thu Jan 17 11:51:13 1991 Flags: 000000000001 Received: from ifi.uio.no by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA02921; Thu, 17 Jan 91 11:47:40 EST Received: from roftaty.ifi.uio.no by ifi.uio.no with SMTP id ; Thu, 17 Jan 1991 17:47:28 +0100 From: Ole Bj|rn Hessen Received: by roftaty.ifi.uio.no ; Thu, 17 Jan 1991 17:47:25 +0100 Message-Id: <9101171647.AAroftaty03383@roftaty.ifi.uio.no> Subject: Re: comments on the SMTP session protocol To: Ariel@relay.prime.com (Robert Ullmann) Date: Thu, 17 Jan 1991 17:47:23 +0100 Cc: IETF-SMTP@dimacs.rutgers.edu In-Reply-To: <9101171621.AA00719@rutgers.edu>; from "Robert Ullmann" at Jan 17, 91 11:23 am I have debugged X.400 messages and transmission between MTAs. I find X.400 an order of magnitude more difficult to debug than RFC822/RFC821. It is hard to find out what's broken and where. I have no problem with transmission of binary *body* parts though. As long as the header and envelope fields are line based. Ole Bjorn. From Rudy.Nedved@rudy.fac.cs.cmu.edu Thu Jan 17 14:22:21 1991 Flags: 000000000001 Received: from RUDY.FAC.CS.CMU.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA07686; Thu, 17 Jan 91 14:13:30 EST Received: from rudy.fac.cs.cmu.edu by RUDY.FAC.CS.CMU.EDU id aa01308; 17 Jan 91 14:12:47 EST To: Greg Vaudreuil Cc: ietf-smtp@dimacs.rutgers.edu Subject: Re: SMTP changes stuff In-Reply-To: <9101161436.aa12867@NRI.NRI.Reston.VA.US> Date: Thu, 17 Jan 91 14:12:41 EST Message-Id: <1304.664139561@RUDY.FAC.CS.CMU.EDU> From: Rudy.Nedved@rudy.fac.cs.cmu.edu Greg, I suspect it would not be wise to use the HELO command since most of the command were design using the first 4 characters and it is quite possible that implementations blindly assume it can ignore anything after the first 4 characters. A new command is less dangerous since if the implementation does not understand it then it would give some 500 serious command or worst yet say nothing or die. We have to recognize the diverse implementations from poorly configured sendmails to VMS to "old" mainframes like IBM 3083 to MMDF. -Rudy From "Neil W. Rickert " Thu Jan 17 14:31:11 1991 Flags: 000000000001 Received: from mp.cs.niu.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA08066; Thu, 17 Jan 91 14:27:03 EST Received: from localhost by mp.cs.niu.edu with SMTP id AA22930 (5.65a/IDA-1.4.2.5 for ietf-smtp@dimacs.rutgers.edu); Thu, 17 Jan 91 13:26:59 -0600 Message-Id: <9101171926.AA22930@mp.cs.niu.edu> To: ietf-smtp@dimacs.rutgers.edu Organization: Northern Illinois University, CS department. Subject: Extended SMTP. Date: Thu, 17 Jan 91 13:26:58 -0600 From: "Neil W. Rickert" Has anyone considered using the '.' character for these extensions. The '.' character as the first character of a line is already special. If followed only by white space, it is an EOF marker. If followed by another '.' the the '..' should be replaced by '.' In principle .x at the beginning of a line is illegal for any other values of x. An extended SMTP could define meanings for other values of x. For example: First byte - . second byte - 8 third byte - a count could be used as a code that 8 bit binary data is in use. The count would give the number of bytes of binary data. The CR LF at the end of the line is therefore not part of the 8 bit data. Note that this allows long binary streams to be sent as short records for mail software which requires this. Some escaping of internal CR or LF characters would be needed, but is easy to define. -Neil Rickert From "Timo Lehtinen " Thu Jan 17 15:27:22 1991 Flags: 000000000001 Received: from fuug.fi by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA09590; Thu, 17 Jan 91 15:24:07 EST Received: from sti.UUCP by fuug.fi with UUCP id AA10951 (5.65+/IDA-1.3.5 for ietf-smtp@dimacs.rutgers.edu); Thu, 17 Jan 91 22:21:38 +0200 Received: by sti.fi (5.57/smail2.2/03-05-90) id AA21234; Thu, 17 Jan 91 21:35:10 +0200 Message-Id: <9101171935.AA21234@sti.fi> To: ietf-smtp@dimacs.rutgers.edu Cc: ttl@fuug.fi Subject: A spec on TEX-HEX encoding Date: Thu, 17 Jan 91 21:35:09 O From: Timo Lehtinen > Mar 1991 Write a document for the sending of 8 bit character sets > through 7 bit mailers with the TEX-HEX encoding scheme. Could somebody send me a description of the TEX-HEX encoding algorithm ? Preferable via mail. Thank you in advance ! Timo Lehtinen From "brian@ucsd.edu (Brian Kantor)" Thu Jan 17 15:30:40 1991 Flags: 000000000001 Received: from ucsd.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA09675; Thu, 17 Jan 91 15:26:33 EST Received: by ucsd.edu; id AA00111 sendmail 5.64/UCSD-2.1-sun Thu, 17 Jan 91 12:26:20 -0800 for ietf-smtp@dimacs.rutgers.edu Date: Thu, 17 Jan 91 12:26:20 -0800 From: brian@ucsd.edu (Brian Kantor) Message-Id: <9101172026.AA00111@ucsd.edu> To: ietf-smtp@dimacs.rutgers.edu Subject: Re: SMTP changes One idea I've been stewing on for a while is to split out the header and the several parts of a message in this way: HELO wombats.edu MAIL FROM: RCPT TO: HEAD multiple lines of header . PART 1 multiple lines of text . PART 2,1033 1033 bytes of text or image or whatever PART 3 more text . QUIT In the header there would be Part: lines that described the processing and presentation of the various parts of the message. The PART commands have a numeric parameter that counts the parts being sent, and optionally a bytecount. If the doesn't appear, the stuff following is assumed to be sent like current SMTP text, terminated by a '.' on a line by itself, whereas if the bytecount is present, exactly that many bytes of data are sucked off the stream as that part of the message. Thus you could send mail that has text, stereo sound, images, spreadsheet data, and printer output (for example) all in one message. Presumably the header lines for each part would specify the intended presentation order and method. You could even send a narrated slide show this way. - Brian From "Mark Crispin " Thu Jan 17 15:41:59 1991 Flags: 000000000001 Received: from akbar.cac.washington.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA10215; Thu, 17 Jan 91 15:38:41 EST Received: from tomobiki-cho.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.21 ) id AA01465; Thu, 17 Jan 91 12:38:34 -0800 Date: Thu, 17 Jan 1991 12:32:59 -0800 (PST) From: Mark Crispin Subject: Re: SMTP changes stuff To: Stef@ics.uci.edu Cc: Mark Crispin , ietf-smtp@dimacs.rutgers.edu In-Reply-To: <11272.664105095@nma> Message-Id: Hi Stef -- this all sounds good to me. My concern on RFC1154 is strictly as an implementor; I would like to see the spec tightened up a little bit, and support some additional information and types. But I have no particular religious feelings about what form it should take other than it be readily implementable with reasonably-sized code. From "Ned Freed, Postmaster " Thu Jan 17 15:56:27 1991 Flags: 000000000001 Received: from CBROWN.CLAREMONT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA10649; Thu, 17 Jan 91 15:53:32 EST Date: Thu, 17 Jan 1991 12:52 PST From: "Ned Freed, Postmaster" Subject: Re: comments on the SMTP session protocol To: Ariel@relay.prime.com Cc: ietf-smtp@dimacs.rutgers.edu Message-Id: <82AD12A19680063A@HMCVAX.CLAREMONT.EDU> X-Envelope-To: ietf-smtp@dimacs.rutgers.edu X-Vms-To: IN%"Ariel@relay.prime.com" X-Vms-Cc: IN%"ietf-smtp@dimacs.rutgers.edu" Robert Ullmann writes: > I think there are a number of aspects of SMTP that have contributed > to its success, but are poorly understood by most users and > implementors. > ... > This does not necessitate changes to the MTAs (Mail Transfer Agents, > another ISOmorphism :-). This is crucial in my opinion: we aren't > going to get any MTA change rolled out anytime in the 1990's to > anything approaching universality; and the MTA should not care (read > "MUST NOT interfere with") what is being sent anyway. Yes! Any change made in all this needs to be transparent to existing SMTP implementations. They may not know what to do with the new material they are given, but they should be able to pass it on to the next guy that *does* know without any trouble. Adhering to this rule means that line lengths cannot be extended directly, but some encoding can be applied that has the effect of extending the line length, for those sites that understand the encoding. BITNET already does this in some BSMTP encoding by placing a major cookie character in the last available column. I'm not advocating this exact approach, but it does work. If changes made here are not transparent to existing SMTP implementations, I agree that there's little chance of them being widely adopted. Thus, however tempting it is to extend the HELO command, or add new commands to the SMTP dialogue, or add new interpretations of the character following a single dot at the end of the DATA segement, these things should be avoided because they necessitate too many changes to existing implementations. In fact, what we're really talking about extending here should be RFC822, not RFC821. While I don't especially like RFC1154 because of its use of line counting (which doesn't survive line wrapping mailers very well -- I prefer RFC934 conventions), I'd much rather see it used than extend SMTP. > The only useful change I can see making to the MTAs (and to the > definition of the SPDUs) is to define the character code used as > ISO8859/1 aka ASCII-8. This will not take as long to roll out: some > implementations are "compliant" already, while others are trivial to > fix. ("sendmail" can be fixed by the simple deletion of two lines of > code.) After all: why clear the "high" bit if you don't have to? Agreed. This is the right thing to do. It is pretty easy to convert the various national and vendor-specific character sets to ISO8859, and standardizing on ISO8859 as a common-denominator on-wire character set makes a lot of sense. Note that ISO8859 includes 7-bit ASCII as a subset; it would not be appropriate to use it if it did not. > This has already been done by some vendors, and has been proven to > NOT cause interoperability problems. Messages that go through a 7-bit > mailer get the bit cleared, but get delivered. After a while, such > mailers will be viewed as broken. My experience indicates that this is certainly true of PMDF. Removing code to clear the high bit was requested by various European sites and has caused no problems that I know of. I also find that a lot of sites either have vendors that have implemented these changes, or they've hacked them in themselves. > Encodings that do a complete transform of the input object (uuencode, > btoa, hex, FS, LZJU90 (see another future message ;-)) produce a 6 or > 7 bit encoding known to survive various gates and conversions, and > thus will survive such "broken" mailers. RFC1113 offers another encoding, but the better of these encodings all share the basic concept of stuffing 3 8 bit characters of input into 4 6 bit characters of output. The only minor differences are in the output character set and the handling of trailing material (because of the 3x chunking implied by the input processing). Since they are all pretty much equivalent, I don't really care which ones are eventually used. RFC1113 has the advantage of being nicely written up already, but that's about it. > Rob Ullmann Ned Freed From "Ole Bj|rn Hessen " Thu Jan 17 16:21:59 1991 Flags: 000000000001 Received: from ifi.uio.no by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA11274; Thu, 17 Jan 91 16:17:42 EST Received: from baaleyg.ifi.uio.no by ifi.uio.no with SMTP id ; Thu, 17 Jan 1991 22:17:29 +0100 From: Ole Bj|rn Hessen Received: by baaleyg.ifi.uio.no ; Thu, 17 Jan 1991 22:17:26 +0100 Message-Id: <9101172117.AAbaaleyg02909@baaleyg.ifi.uio.no> Subject: Extension to SMTP. To: ietf-smtp@dimacs.rutgers.edu Date: Thu, 17 Jan 1991 22:17:24 +0100 Dan Oscarsson (Dan@DNA.LTH.Se) is working on extensions to IDA sendmail to support ISO character sets. His idea is to extend the SMTP protocol with a new command ISOC [character-set] (ie. ISOC 8859-1). If responding access point do not respond with 250 ok to this command, it is assumed to be a 7 bit old mailer In Norway, we need support for ISO 8859-1 or something stronger. As soon as Dan is finished with his patches, we will try this version at our Universities. I don't know if Dan is listening here. Anyway I'll mail him and give him a hint. Ole Bjorn. [Sorry if you got this letter twice] From "Greg Vaudreuil " Thu Jan 17 16:37:01 1991 Flags: 000000000001 Received: from NRI.RESTON.VA.US by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA11873; Thu, 17 Jan 91 16:32:40 EST Received: from NRI by NRI.NRI.Reston.VA.US id aa13914; 17 Jan 91 16:30 EST To: "Ned Freed, Postmaster" Cc: Ariel@relay.prime.com, ietf-smtp@dimacs.rutgers.edu Subject: Re: comments on the SMTP session protocol In-Reply-To: Your message of Thu, 17 Jan 91 12:52:00 -0800. <82AD12A19680063A@HMCVAX.CLAREMONT.EDU> Date: Thu, 17 Jan 91 16:30:29 -0500 From: Greg Vaudreuil Message-Id: <9101171630.aa13914@NRI.NRI.Reston.VA.US> Folks Let me state some of the basic assumptions I have about this effort. Hopefull I can start to get a framework from which a solution may emerge. 1) SMTP should be modified to allow for 8 bit character sets. Not having an 8 bit path is a flaw in the origional RCC 821 specification that I do not want to see remain, especially when it is so easy to correct. To make this work, some mechanism must be defined to allow mailers to detect other mailers capable of handling 8 bits. This most simply can be by defining a synonym for HELO, recognized only by mailers that are 8 bit compliant. Other options are playing with the DATA command, but that wastes several exchanges before recognizing that the receiving mailer cannot accept the message as encoded. 2) Given that there are 7 bit systems that need to interoperate with 8 bit systems, I proposed a single standard encoding be adopted. If you are a 8 bit system, and you want to send to a 7 bit, line limited system, then uuencode, or somesuch, but allow the UA to retrieve the origional 8 bit message without trying to figure out n different formats. If a standard format is adopted, I can, without updating my mailer or reader, put in a script to detect non-ascii text and convert it before my mail-reader looks at it. If my mail-reader can't deal with the 8 bit data, I have not lost anything, I just fail to get aditional functionality. 3) Provisions needs to me made to 822 to allow for easy interoperation of multimedia mail. I don't care whether it is RFC1154 based or RFC934 based, or whatever. It would be useful to be able to use currently defined OSI body parts, including G3 FAX, and ISO8859/1. To the extent that this requires binary transmission capabilities, I would like to see the elimination of line length in RFC 821. This concern is secondary to allowing 8 bit transmission... and I'm not advocating unlimited line lengths for 7 bit systems. I understand that line lengths are harder to modify than striping bits. It this is seen as a difficult change, that a good alternative needs to be proposed. I do not like the idea of uuencoding, or hexifying (?) everything when a 8 bit path is available! Greg Vaudreuil From "Ittai Hershman " Thu Jan 17 16:55:55 1991 Flags: 000000000001 Received: from SHEMESH.GBA.NYU.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA12446; Thu, 17 Jan 91 16:52:55 EST Received: by shemesh.gba.nyu.edu (4.1/1.34) id AA14018; Thu, 17 Jan 91 16:49:43 EST Date: Thu, 17 Jan 91 16:49:42 EST From: Ittai Hershman To: "Ned Freed, Postmaster" Cc: ietf-smtp@dimacs.rutgers.edu Office-Phone: 212-285-6080 Subject: Re: comments on the SMTP session protocol In-Reply-To: Your message of Thu, 17 Jan 1991 12:52 PST Message-Id: If changes made here are not transparent to existing SMTP implementations, I agree that there's little chance of them being widely adopted. It seems to me that is not a big problem. One solution off the top of my head is that we could assign a new port number to the new SMTP. If a connection is established to that port, it could use a new set of semantics, and if not it could fall back to port 25 and use the old SMTP semantics (and decide what PART's (using Brian's terminology) to transmit. Since only a new SMTP would try to connect to the new port number the semantics problem goes away... By the way, here are my initial contributions to the inevitable naming contest: MCMTP = More Complicated Mail Transfer Protocol or MMTP = Multimedia Mail Transfer Protocol -Ittai From Rudy.Nedved@rudy.fac.cs.cmu.edu Thu Jan 17 18:00:09 1991 Flags: 000000000001 Received: from RUDY.FAC.CS.CMU.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA14260; Thu, 17 Jan 91 17:57:06 EST Received: from rudy.fac.cs.cmu.edu by RUDY.FAC.CS.CMU.EDU id aa01691; 17 Jan 91 17:56:49 EST To: Ittai Hershman Cc: ietf-smtp@dimacs.rutgers.edu Subject: Re: comments on the SMTP session protocol In-Reply-To: Date: Thu, 17 Jan 91 17:56:43 EST Message-Id: <1686.664153003@RUDY.FAC.CS.CMU.EDU> From: Rudy.Nedved@rudy.fac.cs.cmu.edu >It seems to me that is not a big problem. One solution off the top of >my head is that we could assign a new port number to the new SMTP. If >a connection is established to that port, it could use a new set of >semantics, and if not it could fall back to port 25 and use the old >SMTP semantics (and decide what PART's (using Brian's terminology) to >transmit. Since only a new SMTP would try to connect to the new port >number the semantics problem goes away... I agree. Instead of overloading some service like SMTP and then having arguments about what this SMTP service should be doing or not doing, lets have a new service which we can clearly say "hey your XXX service does not conform to spec!" Also the 8-bit versus 7-bit issue is not a big thing, the line issue is the significant one. Alot of systems do line wrapping because of other systems that have small line buffers. I am continually amazed at the occasional pieces of mail that I received that can not be returned because the outgoing line buffers are larger then the incoming line buffers. A few comments on a new specification if destined. 1) SMTP was easy to sell to other places. During the intial deployment, implementations were created for DECNET that worked better then the current systems and it even was reincarnated as BSMTP for BITNET. 2) SMTP tended to keep to the exchange of mail. Improvements for performance were made by smarted SMTP receivers and senders not but increasing the complexity of the protocol. 3) The simple and direct manner of command line and response line, minimal states for each command, clear state interaction between the various commands and plain expectations of what would happen helped immensely. Now with the Internet be much much larger any significant protocol must be extremely easy to sell to the harassed system manager or programmer, must have a poor man's implementations "free" for those people who have PCs and the like and above all be mature enough for people to install it once and forget it. -Rudy From "Ned Freed, Postmaster " Thu Jan 17 22:46:53 1991 Flags: 000000000001 Received: from CBROWN.CLAREMONT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA22589; Thu, 17 Jan 91 22:43:01 EST Date: Thu, 17 Jan 1991 16:33 PST From: "Ned Freed, Postmaster" Subject: Re: comments on the SMTP session protocol To: ietf-smtp@dimacs.rutgers.edu Message-Id: X-Envelope-To: ietf-smtp@dimacs.rutgers.edu X-Vms-To: IN%"ietf-smtp@dimacs.rutgers.edu" Using a different TCP port makes the problem much, much worse! It will virtually guarantee that this extension is never used! For one thing, how do you determine which port to use when sending to a given system? Checking one and then another wastes a great deal of time. You're seeing the Internet as a tightly interconnected set of systems all accessible via TCP. I don't see it that way at all, especially when it comes to e-mail. The use of MX records in the DNS has made it possible for many, many systems to interoperate with the Internet at least as far as e-mail is concerned. If you fail to include these systems in these extensions, you've automatically eliminated much of their utility. By adding extensions at the SMTP level, you're forcing the MX gateways to upgrade their software before the benefit of the extensions can reach the machines the gateway serves. Many gateways simply will not do this in a timely fashion. If you add the requirement of an additional server on a different port, things get even more unlikely. If going to a second port is seriously considered, I'm afraid I have to say that then we might as well use X.400 on it. Ned From "Nathaniel Borenstein " Fri Jan 18 09:38:11 1991 Flags: 000000000001 Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA13370; Fri, 18 Jan 91 09:31:53 EST Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-smtp@dimacs.rutgers.edu; Fri, 18 Jan 91 09:31:47 EST Received: by greenbush.bellcore.com (4.12/4.7) id for ietf-smtp@dimacs.rutgers.edu; Fri, 18 Jan 91 09:34:18 est Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.greenbush.mouseclub.sun4.40 via MS.5.6.greenbush.mouseclub.sun4_40; Fri, 18 Jan 1991 09:34:15 -0500 (EST) Message-Id: Date: Fri, 18 Jan 1991 09:34:15 -0500 (EST) From: Nathaniel Borenstein To: ietf-smtp@dimacs.rutgers.edu Subject: Re: comments on the SMTP session protocol In-Reply-To: References: Status: O Excerpts from internet.ietf: 17-Jan-91 Re: comments on the SMTP se.. Ned Freed@hmcvax.claremo (1169) > If going to a second port is seriously considered, I'm afraid I have to > say that then we might as well use X.400 on it. Bingo. The standard excuses for not switching to X.400 (I've offered both of these many times) are that it is not yet mature and that it is too big and complex. How much sense does it make to design a new (=immature) protocol to extend (=make more complex) SMTP? The world HAS a standard, and it is X.400. The Internet can still make a pretty good case that it isn't worth switching to X.400, but the heart of that case is that we have SMTP and it works well enough to satisfy us. Making a case for an SMTP replacement, however, fatally undermines the arguments against X.400. My recommendation: minor tweaks to SMTP and the relevant RFC's where absolutely necessary to support multimedia mail or other badly needed functionality. Otherwise, if it ain't broke, don't fix it, and if it is broke, hold our collective noses and replace it with the fast-maturing international standard that was designed to replace it. From "Robert Ullmann " Fri Jan 18 16:10:54 1991 Flags: 000000000001 Received: from RUTGERS.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA08987; Fri, 18 Jan 91 16:06:06 EST Received: from Relay.Prime.COM by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA16460; Fri, 18 Jan 91 16:05:58 EST Message-Id: <9101182105.AA16460@rutgers.edu> Received: (from user ARIEL) by Relay.Prime.COM; 18 Jan 91 16:09:48 EST To: IETF SMTP list From: Robert Ullmann Subject: notes on mailing binary objects Date: 18 Jan 91 16:09:49 EST Status: O Hi, There is a common misconception being repeated here: that 8 bit text is the same thing as binary, and now you can mail anything. This is simply not correct. Firstly, text still consists of lines, of some limited length, terminated by CRLF; the set of symbols available is not 256 in any sequence. Much more important is the reliability of the data transfer. Prime has several years of experience with mailing binary objects around our network. The following is not theory or speculation, but is based on hard experience. Consider the error rate on the net. Specifically, consider the rate at which /undetected/ errors occur. If we get one undetected error in 1 million bytes transferred, i.e. a BER of 10^-7 (using "BER" loosely), this is acceptable for text messages, but utterly unacceptable for a binary object. 1 million bytes is maybe 500 text messages, our hypothetical 1 error will cause a typographical error in /one/ of those messages; it will likely go un-noticed. Binary messages tend to be larger. The favorite object in binary mail is an executable, with binary messages averaging closer to 1 MB per message. Our hypothetical 1 error in 1 MB is now an error in /every/ message. Suppose the message was an executable: the result is, at best, a core dump when run; more likely a subtle failure that might happen a long time later. Even if you postulate a different actual error rate, it is still true that binary is 5-6 orders of magnitude more sensitive to errors in transmission. The way to move a binary object is for the sender to compute a checksum (CRC), compress the data, and encode it for transmission. The receiver decodes, de-compresses, and verifies the size and checksum. The object transmitted is normally significantly smaller than the original binary object, instead of the typical 4/3 expansion from (e.g.) uuencode. No changes to MTA's are required: the data is the business of the MUA's and the users, not the MTA's. Which is as it should be. It also provides an end-to-end check on the data integrity, which is crucial to the transmission of binary data. As I said, Prime has a lot of operational experience with mailing binaries. The real problem is that it is much too popular; people mail any object at any time, often regardless of cost ... I will be sending out a draft of a good algorithm for this (the LZJU90 I referred to previously) sometime in the next week or so. Best Regards, Robert Ullmann +1 508 620 2800 x1736 Ariel@Relay.Prime.COM From "Terry Crowley " Fri Jan 18 17:22:28 1991 Flags: 000000000001 Received: from DILITHIUM.BBN.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA11124; Fri, 18 Jan 91 17:16:31 EST Received: by dilithium.BBN.COM (AA14154); Fri, 18 Jan 91 17:16:08 EST Message-Id: <9101182216.AA14154@dilithium.BBN.COM> From: "Terry Crowley" Date: Fri, 18 Jan 91 17:16:06 EDT Subject: Re: notes on mailing binary objects To: ariel@relay.prime.com Cc: ietf-smtp@dimacs.rutgers.edu X-Translated: From BBN/Slate multimedia format (version 1.2). Status: O >> The way to move a binary object is for the sender to compute a >> checksum (CRC), compress the data, and encode it for transmission. >> The receiver decodes, de-compresses, and verifies the size and >> checksum. By the way, this is exactly the procedure BBN/Slate uses for transmitting multimedia documents through standard text mail paths (although the compression and checksum calculation are done in the same step). And the size of the transmitted document is almost always smaller than the uncompressed size of the original document. Terry From "kessler@hacketorium.eng.sun.com (Tom Kessler)" Fri Jan 18 18:22:50 1991 Flags: 000000000001 Received: from Sun.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA12870; Fri, 18 Jan 91 18:17:20 EST Received: from Eng.Sun.COM (exodus-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA19419; Fri, 18 Jan 91 15:17:15 PST Received: from hacketorium.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA12178; Fri, 18 Jan 91 15:17:13 PST Received: by hacketorium.Eng.Sun.COM (4.1/SMI-4.1) id AA07176; Fri, 18 Jan 91 15:16:07 PST Date: Fri, 18 Jan 91 15:16:07 PST From: kessler@hacketorium.eng.sun.com (Tom Kessler) Message-Id: <9101182316.AA07176@hacketorium.Eng.Sun.COM> To: Mark Crispin In-Reply-To: Subject: re: SMTP changes stuff Cc: ietf-smtp@dimacs.rutgers.edu Status: O There are couple of good points in Mark C's message. XDAT has some definite advantages here. A seperate BATC command (if we decide we want to do a batching command) would also be acceptable at least as far as I'm concerned. I also like the way XDAT clarifies that we're talking about data (not headers, or whatever else...). The question of what we do when we hit a machine that doesn't do XDAT is one I'd like to see some discussion on. UUencoding is certainly the obvious solution that occurs to us Unix weenie types (the uuencode program is available in a public domain C implementation among other things) although I've never seen a document describing it's format (Actually this would make a good topic for another RFC). How do you folks feel about this? Should gateways between 7bit and binary capable mailers be required to encode the body? Should the form of the encoding be specified (somebody would have to document uuencode)? Or would it be preferable to allow mailers to return/forward and error message when they hit such a gateway? Unfortunately (at least for now) the Unix compress is under a cloud due to the recent action on the patent of the LZW compress algorithm. I'd like to avoid requiring (or even suggesting) that folks use something they might have to pay royalties on. I 100% agree with the structure of data being beyond SMTP's realm. That stuff belongs in an RFC1154 type document (I think we talked about this at the Boulder meeting and agreed on that much at least). --Tom Kessler From "Roger Fajman " Fri Jan 18 19:51:38 1991 Flags: 000000000001 Received: from alw.nih.gov by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA15545; Fri, 18 Jan 91 19:47:09 EST Received: from cu.nih.gov by alw.nih.gov (5.61/alw-2.1) id AA12417; Fri, 18 Jan 91 19:47:05 -0500 Message-Id: <9101190047.AA12417@alw.nih.gov> To: Ariel@relay.prime.com Cc: IETF-SMTP@dimacs.rutgers.edu From: "Roger Fajman" Date: Fri, 18 Jan 91 19:46:18 EST Subject: Re: notes on mailing binary objects Status: O I think that a network that gets one undetected error per million bytes transferred is in severe need of fixing. BITNET has lots of experience mailing binary files around with good results. Many people also send UUencoded binary files via SMTP, also with good results. UUencode has no builtin checksum. This isn't to say that I think that checksums for objects is necessarily a bad idea. I just think your argument is overstated. From "David Herron " Sat Jan 19 01:32:01 1991 Flags: 000000000001 Received: from TWG.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA22642; Sat, 19 Jan 91 01:25:57 EST Received: from Obelix.twg.com by twg.com with SMTP ; Fri, 18 Jan 91 22:14:38 PST Received: from obelix.twg.com by Obelix.TWG.COM id aa03331; 18 Jan 91 22:14 PST To: ietf-smtp@dimacs.rutgers.edu Subject: Re: SMTP changes stuff In-Reply-To: Your message of Fri, 18 Jan 91 15:16:07 -0800. <9101182316.AA07176@hacketorium.Eng.Sun.COM> Date: Fri, 18 Jan 91 22:14:16 -0800 From: David Herron Message-Id: <9101182214.aa03331@Obelix.TWG.COM> Status: O Gents, Hi.. just joined up so I'm wondering what's going on & if there's an archive-of-messages somewhere that'd be groovy. I have a couple of comments regardless.. There was a message earlier today about using a different "port" for the extended SMTP. Hmm.. I don't like that tooo much as I feel it would cause more work on administrators -- at the simplest they would have to _know_ which of their neighbors are able to do the extended SMTP & then splitting their neighbors into two lists, one pointing at the extended-smtp channel, and the other pointing at the normal-smtp channel. The (capital I) Internet being what it is, there's a heck of a lot of neighbors so these lists are going to be large. Maybe we could work in a new thing in the nameservers to keep that indication. But this seems like a slightly odd thing to add to the nameservers. On the other hand extending SMTP doesn't seem to be very hard. Add in some "capability negotion" as part of the startup. How about a new command "CAPB" (for CAPaBilities") sent by the initiator somewhere in the startup -- just after the HELO/response portion probably. The data part in the CAPB might be a list of capabilities or just one at a time. If it were a list then the data in the reply should tell which capabilities the responder is willing to support. However this doesn't fit the SMTP/FTP model where the reply data is soley for human (and not machine) consumption. Therefore it might be necessary for the initiator to ask for capabilities one at a time & the yes/no status of the response indicate whether that capability is acceptable. If the SMTP implementation is "only" RFC-821, then it won't recognize CAPB at all, but all it will do is natter back some negative responses. I don't recall if it is free to drop the connection or not, but I've never seen an SMTP which did that. Ergo -- very probable interoperation with old servers. > XDAT has some definite advantages here. A seperate BATC command (if we > decide we want to do a batching command) would also be acceptable at least as > far as I'm concerned. I also like the way XDAT clarifies that we're > talking about data (not headers, or whatever else...). "batching"?? eh?? Are you meaning BSMTP? But BSMTP doesn't _need_ any extra commands. (except that, for some reason, Alan Crosswell felt the need to add a "ticket number" command (TICK) so that the initiator could keep the original message around until the reply file came back & use the ticket number to connect the two). > UUencoding is certainly the > obvious solution that occurs to us Unix weenie types (the uuencode program is > available in a public domain C implementation among other things) although > I've never seen a document describing it's format (Actually this would > make a good topic for another RFC). > How do you folks feel about this? Mebbe I'm not a real Unix weenie after all. But uuencode isn't the obvious solution to me -- it's a rather wasteful encoding. There happens to be approximately 90-96 usable characters while uuencode only uses about 63-64 of them. Another encoding -- atob/btoa -- is also in the public domain and pretty widely available (tho not as available as uuencode). It also makes full use of the usable characters. It also happens to work through BITNET links, important since some sets of BITNET links step on even the printable characters. On the other hand -- the wide availability of uuencode is important because it carries a lot of intertia. I won't strenuously object ... SunOS (at least) includes a man page in section 5 describing uuencode. > Should gateways between 7bit and binary capable mailers be required to > encode the body? Should the form of the encoding be specified (somebody > would have to document uuencode)? Or would it be preferable to allow > mailers to return/forward and error message when they hit such a gateway? Yes, of course. I just see the shouting out in comp.mail.misc what with all them header purists there who get upset at gateways rewriting headers on internet<->uucp transitions. The form of the encoding can easily be carried in the message .. either in the header a la RFC-1154, or in the body with body parts encoded similarly to a digested message. That is, blocks like --------- (seperator) Header: lines Including: a line count like so: Lines: 54 ... 54 lines of encoded stuff ... I don't quite like the RFC-1154 method because it's not so obvious to uneducated users. I think it might also be harder to construct by hand (supposing you're at a site which doesn't have an 1154 compliant user agent, but you want to send that sort of mail). But what should happen if some particular body part translation cannot be done at a particular gateway. What the PP gents suggest in their manual is a "filter channel" which replaces that body part with an IA5 message saying "There was an xxx body part here, but it was deleted at site yyy". This isn't very friendly ... ;-). Hmm.. this was gonna be a short message. Sigh David From "backman@ftp.com (Larry Backman)" Sat Jan 19 06:33:39 1991 Flags: 000000000001 Received: from ftp.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA02293; Sat, 19 Jan 91 06:30:13 EST Received: by ftp.com id AA17661; Sat, 19 Jan 91 06:30:22 -0500 Date: Sat, 19 Jan 91 06:30:22 -0500 From: backman@ftp.com (Larry Backman) Message-Id: <9101191130.AA17661@ftp.com> To: ariel@relay.prime.com, tcrowley@diamond.bbn.com Subject: Re: notes on mailing binary objects Cc: ietf-smtp@dimacs.rutgers.edu Status: O >> The receiver decodes, de-compresses, and verifies the size and >> checksum. By the way, this is exactly the procedure BBN/Slate uses for transmitting multimedia documents through standard text mail paths (although the compression and checksum calculation are done in the same step). And the size of the transmitted document is almost always smaller than the uncompressed size of the original document. Pardon my changing the subject, but has anyone considered encryption of mail messages as part of the new standard? Larry Backman backman@ftp.com From "David Ascher " Sat Jan 19 14:11:33 1991 Flags: 000000000001 Received: from brownvm.brown.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA09198; Sat, 19 Jan 91 14:05:48 EST Message-Id: <9101191905.AA09198@dimacs.rutgers.edu> Received: from BROWNVM.BROWN.EDU by brownvm.brown.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 7622; Sat, 19 Jan 91 14:06:14 EST Received: by BROWNVM (Mailer R2.07) id 3835; Sat, 19 Jan 91 14:06:13 EST Date: Sat, 19 Jan 91 14:01:12 EST From: David Ascher Subject: Re: notes on mailing binary objects To: IETF-SMTP@dimacs.rutgers.edu Status: O Someone mentioned encryption as part of the SMTP extensions. A couple of thoughts: 1. It wouldn't be human readable, and therefore departs from the original thought of SMTP. (It wouldn't be Simple Anything afterwards). 2. What encryption? DES? (Can't send mail overseas). RSA? (expects that everyone have RSA keys -- won't happen for a long time, also costly). A new encryption scheme? I hope not. I'd say that encryption, along with signatures, timestamping, etc. are very necessary and should come soon, but I don't see them fitting into SMTP. We might as well start a brand new protocol (which If I'm correct is the subject of other RFC's, etc..) --david ascher brown university CIS dascher@brownvm.brown.edu From "Phillip G. Gross " Sat Jan 19 18:05:56 1991 Flags: 000000000001 Received: from NRI.RESTON.VA.US by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA13212; Sat, 19 Jan 91 17:59:14 EST Date: Sat, 19 Jan 91 17:58:12 EST X-Mailer: Mail User's Shell (6.5 4/17/89) From: "Phillip G. Gross" To: David Ascher , IETF-SMTP@dimacs.rutgers.edu Subject: Re: notes on mailing binary objects Message-Id: <9101191758.aa07977@NRI.NRI.Reston.VA.US> Status: O > Someone mentioned encryption as part of the SMTP extensions. There is an effort called "Privacy Enhanced Mail" (PEM) in progress in the Privacy and Security Research Group (PSRG) of the IRTF. There are several implementations now being tested. It would be interesting to look into how these efforts might be able to interact. However, for the reasons mentioned in the second message, it is probably not practical to include encryption in this effort. Phill From stef@nma.com Sat Jan 19 18:22:03 1991 Flags: 000000000001 Received: from RUTGERS.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA13501; Sat, 19 Jan 91 18:16:25 EST Received: from nrtc.northrop.com by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA29110; Sat, 19 Jan 91 18:16:18 EST Received: from nma.com by nrtc.nrtc.northrop.com id ab09123; 19 Jan 91 15:15 PST Received: from localhost by nma.com id aa14795; 19 Jan 91 13:46 PST To: "Ned Freed, Postmaster" Cc: ietf-smtp@dimacs.rutgers.edu Subject: Re: comments on the SMTP session protocol In-Reply-To: Your message of Thu, 17 Jan 91 16:33:00 -0800. Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Sat, 19 Jan 91 13:46:28 -0800 Message-Id: <14793.664321588@nma> Sender: stef@nma.com Status: O Hello Ned -- I have to agree with you. This discussion is taking an interesting path, from "lets make a few extensions", to "lets make some pretty radical extensions" to "lets just get a new port number and define a whole new protocol for multimedia multibodypart mail" Well, lets not do this (but say we did) and use X.400 instead. I am not the slightest bit amused by the idea of trying to create an entire new INTERNET standard to compete with SMTP and X.400, with the potential result of further messing up a big mess...\Stef From stef@nma.com Sat Jan 19 18:23:42 1991 Flags: 000000000001 Received: from RUTGERS.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA13506; Sat, 19 Jan 91 18:17:58 EST Received: from nrtc.northrop.com by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA29390; Sat, 19 Jan 91 18:17:50 EST Received: from nma.com by nrtc.nrtc.northrop.com id ae09123; 19 Jan 91 15:17 PST Received: from localhost by nma.com id aa14843; 19 Jan 91 13:53 PST To: David Ascher Cc: IETF-SMTP@dimacs.rutgers.edu Subject: Re: notes on mailing binary objects In-Reply-To: Your message of Sat, 19 Jan 91 14:01:12 -0500. <9101191905.AA09198@dimacs.rutgers.edu> Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Sat, 19 Jan 91 13:52:58 -0800 Message-Id: <14841.664321978@nma> Sender: stef@nma.com Status: O I think we should quickly note several things. 1. PEM-DEV@tis.com (subscription requests to pem-dev-request@tis.com) is a list related to an internet task force of some kind working on Privacy Enhanced Mail in the RFC822 connect, to be carried in the current RFC821 envelope without any mods to RFC821 or RFC822. PEM is deliberately designed to be independent of its means of carriage. PEM provides for public key encryption of keys and certificates and DES encryption of the body of messages. I don't see any reason for RFC821 to be modified for the intended purposes, so I suggest that ietf-smtp should not take this task in its scope. 2. If you are seeking a "secure-mail-transfer-system" then you will be designing yet another one to compete with the X.400(88) standard which does provide for security measures inside the P1 (or MTA level envelope handling). I strongly suggest that trying to start now to design, implement, and deploy an entirely new start on such a system is a generous waste of time and effort. 3. I note a considerable confusion in this list between extensions to RFC821 and extensions to RFC822. I think this group should come to grips with this issue soon, and resolve what its scope really is. For example, why should RCF821(ext) be concerned with the data types inside the body, as long as it has established that there is some 8bit data inside the body which must be protected and preserved in transfer. Is this task force concerned with RFC822 extensions, or is it limited to RFC821? I suggest that it be limited to RFC821. Any structural changes to be made to the internal structure of the body of a message should be dealt with as an extension of RFC822 (and its follow-on RFCs, of which there are several -- can someone identify all the related RFC822 RFCs, just for the record?). I know of RFC934 which defines an encapsulation format (with delimiter codes and bit-stuffing techniques) which is widely ( but not universally) used for forward messages and digests. RFC1154 provides a partially competing (with RFC934) scheme for placing multiple body parts inside a single "main" body part. I recall that there are some other minor extension RFCs, but I forget their numbers. Best...\Stef From "Ittai Hershman " Sat Jan 19 19:05:02 1991 Flags: 000000000001 Received: from SHEMESH.GBA.NYU.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA14131; Sat, 19 Jan 91 18:56:58 EST Received: by shemesh.gba.nyu.edu (4.1/1.34) id AA15675; Sat, 19 Jan 91 18:53:58 EST Date: Sat, 19 Jan 91 18:53:58 EST From: Ittai Hershman To: Stef@ics.uci.edu Cc: ietf-smtp@dimacs.rutgers.edu Office-Phone: 212-285-6080 Subject: Re: comments on the SMTP session protocol In-Reply-To: Your message of Sat, 19 Jan 91 13:46:28 -0800 Message-Id: Status: O Sigh. This is the second misrepresentation of my comment on selecting another port number. I was not advocating a third protocol (as Stef suggests). What I did say, was that there were ways by which changes could be made to SMTP to support MMM, and yet retain backward compatibility with existing SMTP implementations. This discussion is orthogonal to the X.400 issue. Two mechanisms have been mentioned to accomplish this: the first was to have the extended SMTP try a new port number first -- if successful, it would send the MMM message, if not, it would connect to the standard SMTP port and would deliver the message (perhaps in a manner similar to an AMS message which is delivered to a POS (plain old SMTP) implementation). The other suggestion to have a new transaction after the HELO to determine what extensions the server implementation will support, if the assigned keyword is not understood, the sender backs off to POS. Both ideas have problems, and no doubt there are better solutions, but they both demonstrate the key point that we can extend SMTP to have MMM capabilities without losing backward compatibility with those sites which are slow to make changes. We at NYU have been involved in the White Pages project since its exception, and I for one have always been interested in X.400/X.500. On the other hand, it would be nice if we could begin experimenting with MMM without having to deal with major network protocol suite changes and all the ramifications therein -- after all, moving to X.400 (and X.500) is far more complicated that extending SMTP. Why all this concern: if X.400 is so good, we'll end up using it anyway. There is no harm in exploring and implementing other options. You know full well that this has been how this community has done things for years. -Ittai From "Ittai Hershman " Sat Jan 19 19:10:54 1991 Flags: 000000000001 Received: from SHEMESH.GBA.NYU.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA14349; Sat, 19 Jan 91 19:02:31 EST Received: by shemesh.gba.nyu.edu (4.1/1.34) id AA15685; Sat, 19 Jan 91 18:59:32 EST Date: Sat, 19 Jan 91 18:59:32 EST From: Ittai Hershman To: Stef@ics.uci.edu Cc: ietf-smtp@dimacs.rutgers.edu Office-Phone: 212-285-6080 Subject: Re: comments on the SMTP session protocol In-Reply-To: Your message of Sat, 19 Jan 91 13:46:28 -0800 Message-Id: Status: O In the third paragraph of my note, the word "exception" should read "inception". I should also note that given the politics, I was rather surprised this IETF subrgroup was formed at all -- I assumed we would all move to X.400 someday. Now that it here however, I think we should proceed and explore all our options. -Ittai From "Phillip G. Gross " Sun Jan 20 10:17:16 1991 Flags: 000000000001 Received: from NRI.RESTON.VA.US by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA26436; Sun, 20 Jan 91 10:09:31 EST Date: Sun, 20 Jan 91 10:08:29 EST X-Mailer: Mail User's Shell (6.5 4/17/89) From: "Phillip G. Gross" To: Stef@ics.uci.edu, David Ascher Subject: Re: notes on mailing binary objects Cc: IETF-SMTP@dimacs.rutgers.edu Message-Id: <9101201008.aa14640@NRI.NRI.Reston.VA.US> > I think this group should come > to grips with this issue soon, and resolve what its scope really is... > > Is this task force concerned with RFC822 extensions, or is it > limited to RFC821? I suggest that it be limited to RFC821.... Stef, The charter for this group is available online in the IETF directories at NIC.DDN.MIL and NIC.NORDU.NET. The scope is at least two-fold. 1) We wish to make extensions to SMTP (RFC821) to allow 8 bit character sets and probably to eliminate line lengths (to facilitate passage of binary data). 2) We also wish to examine RFC 1154 for passing "body parts" inside SMTP. Finally, we may wish to look at the availablity of packages that implement the new features and encourage their deployment. This started as an effort to allow the passage of international character sets in SMTP mail, but once the 7 bit restriction is removed, it is very tempting to look at the broader issue of passing structured binary date. I agree with your basic point that we need to settle on the scope of the effort fairly quickly, and then stay focused until we have completed that initial effort. It is clear that there has been much work in this area already, and anything this WG does should carefully attempt to harmonize with these other ongoing efforts, rather than strike out in a totally different direction. I also agree that encryption and privacy should not be within the scope of this effort. This group will meet at the next IETF in St. Louis (March 11-15). Phill From stef@nma.com Sun Jan 20 10:42:48 1991 Flags: 000000000001 Received: from RUTGERS.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA26673; Sun, 20 Jan 91 10:36:02 EST Received: from [128.99.0.1] by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA11635; Sun, 20 Jan 91 10:35:55 EST Received: from nma.com by nrtc.nrtc.northrop.com id ac11540; 20 Jan 91 7:35 PST Received: from localhost by nma.com id aa15451; 19 Jan 91 23:29 PST To: Ittai Hershman Cc: ietf-smtp@dimacs.rutgers.edu Subject: Re: comments on the SMTP session protocol In-Reply-To: Your message of Sat, 19 Jan 91 18:53:58 -0500. Reply-To: Stef@ics.uci.edu From: Einar Stefferud Date: Sat, 19 Jan 91 23:29:20 -0800 Message-Id: <15449.664356560@nma> Sender: stef@nma.com My possible misinterpretation is only a matter of degree. What I am trying to convey is that it is very easy to start out with the idea of making a few experimental extensions, and wind up doing a whole new protocol. I liked the ideas of only extending SMTP(RFC821) to handle 8-bit data, and especially to handle the ISO8859-? character set. Handling other well defined 8-bit objects should also be covered by the same extensions if I understand what we are talking about. I would like to leave the issue of how these objects are identified inside the body of extended RFC822 message formats to an extension of RFC822, and not get RFC821(ext) involved with the content of the envelopes, beyond the issue of providing an 8-bit path. I am not happy with the RFC1154 technique of using line counts for object delineation. I would not like to use any kind of count, including character counts. (SHADES of HERMES and TOPS-20 MAIL where my files used to get out of whack every now and then, and I could not touch a message without breaking the whole folder of mail.) Especially when we operate in an environment where these counts can be changed by various transport servers. I would much prefer a methood like RFC934 which is independent of intermediate mungers, which are rampant around the internet "mail" community. Internet Mail is not limited to the IP connected SMTP servers, as we all should remember. I also note that there is a lot of talk here about how well this new design is going to be accepted and deployed across the entire network, so I don't think we are just talking about an isolated experiment. WE seem at times to be talking about a global development and deployment plan for a new mail system design. So, I suggest that we settle down to the task of agreeing on the real scope of this project. Cheers...\Stef From "John C Klensin " Sun Jan 20 13:33:39 1991 Flags: 000000000001 Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA28626; Sun, 20 Jan 91 13:22:47 EST Date: Sun 20 Jan 91 13:22:25-EST From: John C Klensin Subject: Re: notes on mailing binary objects To: pgross@nri.reston.va.us Cc: Stef@ics.uci.edu, DASCHER@brownvm.brown.edu, IETF-SMTP@dimacs.rutgers.edu Message-Id: <664395745.800937.KLENSIN@INFOODS.MIT.EDU> In-Reply-To: <9101201008.aa14640@NRI.NRI.Reston.VA.US> Mail-System-Version: >This started as an effort to allow the passage of international character >sets in SMTP mail, but once the 7 bit restriction is removed, it is very >tempting to look at the broader issue of passing structured binary date. Phil, From my perspective as someone who "gets to" spend a lot of time dealing with the consequences of using and gatewaying "internet mail" into and outside the Internet, I'm feeling a need to reinforce some of what I perceive Stef as saying, and to broaden it a bit. To a certain extent, I'm trying to provide a peek into a can of worms, either to discourage opening it or to make sure people (yourself and Greg especially) understand what is being opened before all the worms are let out. I think everyone should recall, as we go through this exercise, that the number of hosts that are not on the Internet that use "internet mail" (i.e., RFC822 formats and sometimes batch variations on RFC821 envelopes) is probably at least equal to the number of internet hosts that do so. If "users", rather than "hosts" are counted, the number is probably larger. Those systems are not isolated from the Internet: there are all sorts of applications-level gateways to and from them; many of those gateways, as already pointed out, are "hidden" by mechanisms we have explicitly and intentionally provided, notably the concept of MX DNS records. IMHO, we have an obligation to pay attention to the translation, header-munging, and similar needs of those hosts and networks. At a minimum, it will have an influence on the effectiveness with which a set of extensions will be broadly implemented and diffused. I think an important criterion for "success" should be that, as we try to make things better (e.g., to handle "eight-bit characters") we should avoid making them worse in terms of the ability to make invertible translations at the gateways. It is worth keeping in mind that some of those gateways perform character-set translations now, creating the concept of RFC822 headers that are not encoded in ASCII (7 bit or otherwise). As long as they know what is coming, these translations are easy and, with a few small idiosyncracies, reversable and unambiguous. Right now, they know (or are permitted to believe) that they are getting ASCII. The seven bit variety. As specified in a specific and identifiable document. Period. In part because of those other networks and users, the basis for forming a consensus about this should be broader than might be appropriate for, e.g., TCP or IP clarifications. In particular, it is not clear to me that "This group will meet at the next IETF in St. Louis" is an appropriate answer to any of a range of questions because, if IETF decides to make some explicit invitations (which I would encourage) the broader community might participate usefully by email, but is unlikely to be appropriately represented in St. Louis. Let me suggest a few things from experience in watching experiments in this area (some of them unintentional): o It is only a small step between supporting mail that consists [only] of seven bit ASCII characters and supporting mail that consists of ISO8859-1 (Latin-1) characters. While I have always been convinced that this requires envelope changes, rather than "hope the other guy doesn't discard any bits" approaches, the extensions are pretty straightforward one can easily think about translation gateways handling it without great difficulty, and there are lots of devices and systems on the market that can easily handle (including compose and display) ISO Latin-1 today. o It is a significantly larger step to make the jump from ASCII to ISO8859-n (for values of "n" potentially larger than 1). Use of nearly-arbitrary character sets will tend, in practice, to put pressure on systems and gateways to translate code positions between one that arrives from the network and one that is well-supported locally. This is not easy, since many of these character sets "nearly" translate and that leads to requirements to "stylize" graphics that don't quite appear locally. It also opens up the header/envelope problem considerably, because one can now move from something in the envelope with the semantics of "expect [eight-bit] ISO8859-1 instead of ASCII" to some combination of header and envelope that has the semantics of "expect ISO8859-n character sets, and I may change character sets mid-message". The latter might imply a requirement for some sort of encapsulation, with character-set-specification in the inner envelopes, but there are other ways to handle it that are more satisfactory for some purposes. This issue has been discussed at tedious lengths in other contexts; the lengthy discussions about extending the kermit protocol to deal with semi-arbitrary character sets that went on a year or so ago provide the best illustration I know of. At the same time, an extension to ISO8859-n still provides some nice simplifications relative to SMTP extensions. In particular, since all of those character sets preserve a close approximation to ASCII in columns 2 through 7 and prohibit graphic characters in columns 0 and 1 and in 8 and 9, it remains easy to recognize end-of-message (CRLF.CRLF) when it arrives, since it is the same sequence of bits in ASCII-with- leading-zero and, in practice, in all of the ISO8859 character sets. This simplification also makes it no more likely than it is today that mailing a well-formed message from one host will result in, e.g., terminal hangups on other hosts. As soon as, e.g., graphics are permitted in columns 8 and 9 (which some existing character sets permit) a new layer of robustness protection, probably in UAs, is required. o Another huge simplification occurs if one takes the position that message headers remain in ASCII, the variant character sets are acceptable only in message bodies. This position is usually not acceptable, under a principle that is sometimes enunciated as "I want to be able to spell my name correctly". However, it would be possible to go through RFC822 without too much effort and identify which fields and subfields must be confined to ASCII (e.g., anyone want to have ISO8859-7 names in the DNS?) and which ones really are free text. o The step to "mailing binary files" is another major one. It is major even relative to "mailing arbitrary one-octet character sets", since there are no obvious models --in the current RFC821 context-- for understanding where the message body ends. With arbitrary characters (but still characters), it is easy to think, e.g., of extending DATA >From DATA to DATA , where is some surrogate for "." in the extended character set. You have to do something like this, because "." might not, in principle, appear in all character sets. One could redefine "." as a particular sequence of bits (lots of CCITT stuff uses table positions, which amounts to the same thing). But, in binary files that are not organized into lines, while one can still clearly have character-doubling excape sequences they become a not-very- reliable pain in the neck. Personally, as someone else suggested, that set of arguments, as well as the already-posted argument for a higher standard of robustness, make me quite partial to bit or octet counts and checksums (or ECC) in preference to terminating characters. And, for better or worse, "internet mail" does get moved through and over networks that don't provide reliable transport. Identifying those networks as "broken" won't change the world very much, very quickly: it is nearly equivalent to expressing a preference that everyone simply connect to the Internet rather than using other arrangements. But, regardless of what one concludes about counts vs delimiters, the problems get more complex. o At a slightly different level, there are a large set of issues, on which "there has been much work done" that have been blocked, or where horrible kludges have been resorted to, because the Internet community has said for ten years "you don't get to mess with RFC821, you can make certain extensions to RFC822, but it is likely that no one else will interpret them the way you want". I'm not suggesting this has been an explicit policy, only that is has been the effect of a combination of policies and benign neglect. In many respects, that has been useful: having a standard that both fairly comprehensible and that has been completely stable for over a decade has probably contributed as much to its wide acceptance and implementation as it "Simple"-ness. But, if one of the targets of IETF and the working group is broad adoption and implementation --ideally, rapid replacement of SMTP by "extended SMTP"-- then there are, IMHO, extremely strong pragmatic arguments both for remaining as close to "simple" as possible and for an "open it once, then close it again for another ten years except for clearly upward-compatible extensions" philosophy. That may argue that an approach of defining "this effort" as narrowly as possible, getting on with it, and then coming back and doing other things may not be optimal. It may, instead, suggest that we should at least examine all of the possible pieces of this and figure out just where we are going, and how far in those directions we are willing to go and still consider it "SMTP" (as distinct from NSSMTP (Not-So-Simple...) or MCMPT (Moderately- Complex...), presumably as different services on different ports. o That leads to another argument, which I'd encourage people to think about before we jump off into "mailing binaries", which I've taken to mean transporting un-encoded arbitrary files as mail. I have no doubt that we can figure out a way to do that, there are lots of smart people participating in this. I do question whether, however obvious it might be as a thing to do, it is *desirable*. Don't think about it as "mail" for a moment, think about it as a transport mechanism for sender- initiated, password-free (and other potential kinds of sender validation mostly free), file transfer. The network environments in which mail-like mechanisms are most commonly used for transporting binaries (BITNET/EARN/ and the rest of the NJE family) treat them sufficiently differently from mail at the meta-envelope level that MUAs just don't see them. Many of the systems in those networks also handle such files, on receipt, in a way that is exempt from user disk quotas until read or flushed. To encourage the transfer of (typically larger, as was pointed out) binary files via mail means that we need to examine the robustness of potential receiving systems that impose disk quotas on users against the range of problems that often manifest themselves as "can't send a message to that user to tell him that he is out of space because he is out of space". [... I don't consider the NFS and DECNet models for writing files into someone else's file system to be mail-like. And they can provide a relatively high level of validation. ...] Speaking personally, if a file arrives at my system that I can't filter down to acceptable graphics (columns 1-7 and 9-15, less 7/15 and 15/15) in a UA and then type out and read, and I'm expected to execute that file or load it into a database system solely based on trusting the sender, I'd like to have a somewhat higher quality of sender validation available to me than we typically get out of SMTP systems. Granted, I'm a bit more paranoid than most, but I'd like to see someone from Dave Clark's committee comment on this issue before we change protocols to make the practice seem "easy" and "encouraged". At a minimum, I think this argues quite strongly that, if both "eight-bit characters" and "binary file transfers" are part of the program of work, they should be sufficiently distinct in the envelope that an SMTP server can accept the first and immediately reject the second and close the connection if local system integrity considerations argue for the latter. This should be able to be a system-wide decision, not something deferred to UA processing of headers. I'd even argue for language that an SMTP server "should" be configurable to disable acceptance of binary files if that feature were otherwise supported. We may well need a cleaner "push" mechanism for binary objects in the Internet than we have now, but it might be better to look at extensions or variations to FTP than using mail for this purpose. At least we should discuss that question, not blindly go off and extend mail. o Finally, let me suggest about a possibly-different way of thinking about the X.400 issue wrt SMPT extensions. Let's take it for granted that after some period of time, X.400 will replace Internet mail as we now know it, or at least "should do so" and "will be ready to do so". Some of us apparently think "some period of time" is a few months at most, others of us apparently think "a few lifetimes" would be a better estimate. Whatever one thinks of the timeframe, it is pretty clear to me that an extension to SMTP that (i) is needed and (ii) is quite likely to have a significant life expectancy between when it is widely available and whenever X.400 "takes over" is worth doing. Something that is as feature-laden and complex as X.400(88) will presumably take longer to implement and widely disseminate than X.400(88) because those folks presumably have a head start, at least on reading the documentation analogous to what we haven't started writing yet. That, to me, is a pretty strong argument for keeping the changes to SMTP pretty minimal if possible: the smaller they are, the more they will be implemented and the more rapidly those implementations will propagate, improving the payback period. Conversely, it seems to be that it is also a strong argument for those who think that X.400 is right around the corner to define a WKS for X.400 mail seeing how rapidly X.400 implementations can propagate on the Intenet, and then arguing against particular SMTP changes on the grounds that the facilities already exist, are implemented and demonstrated in the Internet-profile X.400 environment, and the particular feature is not worth tampering with SMTP in that environment. That becomes a sensible engineering tradeoff argument, not a religious discussion about how, since utopia (or, if you prefer, the end of the world) is right around the corner, one should do little or nothing in the interim. john ------- From "Phillip G. Gross " Sun Jan 20 14:43:50 1991 Flags: 000000000001 Received: from NRI.RESTON.VA.US by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA29725; Sun, 20 Jan 91 14:38:36 EST Date: Sun, 20 Jan 91 14:37:36 EST X-Mailer: Mail User's Shell (6.5 4/17/89) From: "Phillip G. Gross" To: John C Klensin , pgross@nri.reston.va.us Subject: Re: notes on mailing binary objects Cc: ietf-smtp@dimacs.rutgers.edu Message-Id: <9101201437.aa16736@NRI.NRI.Reston.VA.US> John, Thanks for laying out a wide set of issues in a very comprehensive way. There were many thoughts therein that will form the basis of much continuing discussion. I was very interested in your comments about previous "blocking" and/or "benign neglect". I'm not sure what you are referring to (and maybe don't need to get into details), but let me assure you that there will be no "blocking" at this time of any technical work that the community approves of. (If you were suggesting that the community *itself* blocked previous efforts by not being able to come to closure, then that is a different matter we might have to face.) Again, let me remind everyone that this effort started as an attempt to carry interenational cahracter sets (probably ISO 8859-1 only) in SMTP mail. *Every* other proposal (eg, ISO 8859-n, binary mail, structured binary mail, etc) has been suggested after the original meeting. I agree that we have to carfully consider our program of work, and not bow to the temptation of creeping featurism. At the same time, I think you are quite correct in stating that once we close the hood on this effort, we don't want to re-open again too soon. Therefore, if there *are* other issues we could consider while the hood is up, well, then I think we should at least consider them. This has been a hot mail discussion, and the contributions of the participants in the list will obviously have a strong impact on the final outcome. However, as in all such efforts, at some point some decisions have to get made -- and these decisions are unlikely to have 100% agreement in the group, but hopefully will represent a consensus. Then some documents need to get written. I would very much like to see the general target date of the IETF meeting in March used as an implicit deadline for reaching some consensus. Thanks, Phill From "Jan Engvald LDC " Sun Jan 20 20:28:16 1991 Flags: 000000000001 Received: from Pollux.lu.se by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA06030; Sun, 20 Jan 91 20:21:55 EST Received: from Castor.ldc.lu.se by pollux.lu.se with SMTP (5.61-bind 1.4+ida/IDA-1.2.8) id AA28186; Mon, 21 Jan 91 02:21:47 +0100 Received: from gemini.ldc.lu.se by castor.ldc.lu.se; Mon, 21 Jan 91 01:43 +0100 Date: Mon, 21 Jan 91 01:42 +0100 From: Jan Engvald LDC Subject: Outlines for new functionality To: ietf-smtp@dimacs.rutgers.edu Message-Id: X-Vms-To: XJELDC,IN::"ietf-smtp@dimacs.rutgers.edu" Status: O >This is the way RFC1113-1115 handles encryption. The functionality is >a subset of X.506 and X.411 (?) and is consciously designed to inter- >operate with these ISO protocols. It is also designed not to require >any changes to the UA, although it is desired for ease of use. >I see no reason not to use these RFCs for encryption in the SMTP world >and our proposal should not conflict with it. Ooops, I forgot. There is one thing that I would like to see changed in RFC1113-15: The common character set that they convert to should be the same common set that we will use for nonencrypted mail. As a side effect bit 8 cannot be used to denote non-text (=padding), so some other algorithm should be used for this. A common aproach to all the extended functionality is desired and feels natural. Jan E LDC From "Jan Engvald LDC " Sun Jan 20 20:28:18 1991 Flags: 000000000001 Received: from Pollux.lu.se by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA06032; Sun, 20 Jan 91 20:21:58 EST Received: from Castor.ldc.lu.se by pollux.lu.se with SMTP (5.61-bind 1.4+ida/IDA-1.2.8) id AA28189; Mon, 21 Jan 91 02:21:55 +0100 Received: from gemini.ldc.lu.se by castor.ldc.lu.se; Mon, 21 Jan 91 01:24 +0100 Date: Mon, 21 Jan 91 01:23 +0100 From: Jan Engvald LDC Subject: Outlines for new functionality To: ietf-smtp@dimacs.rutgers.edu Message-Id: X-Vms-To: IN::"ietf-smtp@dimacs.rutgers.edu" X-Vms-Cc: XJELDC Status: O I think more attention should be payed on what functionality we want, then we can discuss means of implementation. Some wishes on mail from our users that affects this discussion: - Want correct characters displayed even if the source mail was written in another character set. - Want to be able to include arbitrary files (formatted documents, illustrations, programs,...) in a mail without hassle. - Want to be able to encrypt mail. - Still want to be able to exchange mail with anybody in the world. Some additional whishes from system managers and program writers: - Big files should be split into several mail items. - It should not require AI for a user agent program to automatically do necessary conversion and packing/unpacking for the user. - Conversion to/from X.400 should not be unnecessary hard for the gateway. I think we should try to extend mail functionality without REQUIRING changes to the mail transport network. This way the new functionality can be spread to the community much quicker. However, I also think we should make some change to the transport. The aim of this is not functionality, but efficiency and ease of debugging. It is much easier for a human to read the characters themselves compared to reading quoted representations of them. And of course conversion increases the load on a mail gateway. The functionality extensions does not require any changes to RFC821/822. What is needed are new headers that informs the UA what conversion it should do and what the syntax and contents of the mail body is. This is the way RFC1113-1115 handles encryption. The functionality is a subset of X.506 and X.411 (?) and is consciously designed to inter- operate with these ISO protocols. It is also designed not to require any changes to the UA, although it is desired for ease of use. I see no reason not to use these RFCs for encryption in the SMTP world and our proposal should not conflict with it. For including files I also think it is important that any user can unpack such files even if he does not have a new files-aware UA. This is best accomplished by using tools that already exist for this purpose. They usually also handle a CRC, so corrupt files can be discarded instead of causing damage. I would liked the standard to pick one of these, but I see no hope of common agreement, so the headers must tell which ones have been used. A fancy UA can look at these and then call the tools to unpack the coded files. Thus all of atob, uuencode, xxencode, uncompress, arc, lhz, zoo and zip have to be available. The headers should also tell the names and types of files that are included in the mail. It is important that the definition takes into consideration that an UA should be able to automatically extract a file even if it is split into several mail units. For the character set issue I think we should decide on a common set that is an union of all the sets we want to support. All mail exchange should use this set between partners that are extended. If one of them is not an extended implementation, a bidirectionally unique and human readable quoting to 7-bit ASCII should be performed. This way extended end systems can communicate through old non-extended systems. The conversion between the common character set and a local one can be done common to all users on a machine, but preferably be specific to each user depending on his display possibilites. The source character set should be noted in a header as an aid for the best conversion. There are some implementations along these lines that are in test within NORDunet, Dan Oscarsson (Dan@dna.lth.se) and some colleagues in the different countries have done a good job in this matter. They use one new command in the SMTP dialog: ISOC , if the recepient does not understand that, the mail is converted to plain old 7-bit ASCII. Summary: We should aim for much better functionality by defining new headers and defining the structure of the mail body when these headers are used. New user agents should use this information to do things automatically for the user, users with old UA should be able to participate doing things manually. A few extenstions to the transport for efficiency and ease of debugging should be done, but no changes to existing transport should be REQUIRED to support the new functionality. Jan Engvald, Lund University Computing Center ________________________________________________________________________ Address: Box 783 E-mail: Jan.Engvald@ldc.lu.se S-220 07 LUND Earn/Bitnet: xjeldc@seldc52 SWEDEN (Span/Hepnet: Sweden::Gemini::xjeldc) Office: Soelvegatan 18 VAXPSI: psi%2403732202020::xjeldc Telephone: +46 46 107458 (X.400: C=se; A=TeDe; P=Sunet; O=lu; Telefax: +46 46 138225 OU=ldc; S=Engvald; G=Jan) Telex: 33533 LUNIVER S From "Mark Crispin " Sun Jan 20 22:32:49 1991 Flags: 000000000001 Received: from akbar.cac.washington.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA08324; Sun, 20 Jan 91 22:28:08 EST Received: from tomobiki-cho.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.21 ) id AA06323; Sun, 20 Jan 91 19:28:05 -0800 Date: Sun, 20 Jan 1991 19:04:48 -0800 (PST) From: Mark Crispin Sender: Mark Crispin Subject: Re: comments on the SMTP session protocol To: ietf-smtp@dimacs.rutgers.edu In-Reply-To: <15449.664356560@nma> Message-Id: Status: O In <15449.664356560@nma>, Einar Stefferud writes: >I would like to leave the issue of how these objects are identified >inside the body of extended RFC822 message formats to an extension of >RFC822, and not get RFC821(ext) involved with the content of the >envelopes, beyond the issue of providing an 8-bit path. > >I am not happy with the RFC1154 technique of using line counts for >object delineation. I would not like to use any kind of count, >including character counts. > >I would much prefer a method like RFC934 which is independent of >intermediate mungers, which are rampant around the internet "mail" >community. Internet Mail is not limited to the IP connected SMTP >servers, as we all should remember. I believe that these three points that Stef has made are very important and I am mostly in agreement with them. [Line Counts] As an RFC-1154 implementor, I had problems with its use of line counts specifically because I had problems in deciding "what is a line?" This was easy on TOPS-20 which used the same newline conventions as SMTP. Unfortunately, UNIX has a different newline convention and by the time my application gets to the data CR's have been stripped from the stream. Two very different text streams in the Internet newline convention are identical once conve