Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ac09144; 14 Aug 92 21:13 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa24025; 14 Aug 92 21:13 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA27578; Fri, 14 Aug 92 20:59:17 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA27574; Fri, 14 Aug 92 20:59:15 EDT Received: from INFOODS.MIT.EDU by INFOODS.MIT.EDU (PMDF #2603 ) id <01GNL36RTW9C0000RC@INFOODS.MIT.EDU>; Fri, 14 Aug 1992 20:58:56 EDT Date: 14 Aug 1992 20:58:55 -0400 (EDT) From: John C Klensin Subject: Last call on recommendation for 'proposed standard' To: ietf-smtp@dimacs.rutgers.edu Message-Id: <713840335.160166.KLENSIN@INFOODS.MIT.EDU> X-Envelope-To: ietf-smtp@dimacs.rutgers.edu Content-Transfer-Encoding: 7BIT Mail-System-Version: I just realized that this had not been posted to the WG list. My apologies to anyone who hasn't seen it already. There have been a small number of comments on the IETF list, mostly within the last 24 hours. The most significant of these were an outburst from Rob Ullman on the "this is wrong, declare 7bit broken" topic area and comments from Mark Lottor who, to my knowledge, has not participated in the WG at all, suggesting that the thing is bloated, unclear, a general disgrace to SMTP, etc., and that a simple TYPE verb would serve everyone better. Ullman has been responded to by several people; no one has yet taken on Lottor. --john --------------- Return-path: Received: from venera.isi.edu by INFOODS.MIT.EDU (PMDF #2603 ) id <01GNINYWGJY8000054@INFOODS.MIT.EDU>; Thu, 13 Aug 1992 03:21:57 EDT Received: by venera.isi.edu (5.65c/5.65+local-6) id ; Wed, 12 Aug 1992 10:08:43 -0700 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Wed, 12 Aug 1992 10:08:32 -0700 Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by quark.isi.edu (5.65c/5.61+local-6) id ; Wed, 12 Aug 1992 09:33:38 -0700 Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa05598; 12 Aug 92 12:23 EDT Date: 12 Aug 1992 12:23:49 -0400 From: IESG Secretary Subject: Last Call: SMTP Extensions for Transport of Enhanced Messages to Proposed Standard Sender: gvaudre@NRI.Reston.VA.US To: IETF Cc: IESG Message-id: <9208121223.aa05598@IETF.NRI.Reston.VA.US> X-Envelope-to: klensin MIME-version: 1.0 Content-type: text/plain; Charset="us-ascii" Content-transfer-encoding: 7BIT The IESG has received a request from the Internet Mail Extensions Working Group to publish the Internet Draft "SMTP Extensions for Transport of Enhanced Messages" as a Proposed Standard. The IESG plans to issue a recommendation in the next few weeks, and solicits final comments on this elevation. Please send any comments to the iesg@nri.reston.va.us, or ietf@isi.edu mailing lists by August 24th. Greg Vaudreuil IESG Secretary   Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03713; 15 Aug 92 21:44 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa16875; 15 Aug 92 21:45 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA05023; Sat, 15 Aug 92 21:39:55 EDT Received: from NETIX.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA05009; Sat, 15 Aug 92 21:35:00 EDT Received: from localhost.netix.com by netix.com (4.1/LLNL-1.18) id AA05131; Sat, 15 Aug 92 18:30:20 PDT Message-Id: <9208160130.AA05131@netix.com> To: ietf-smtp@dimacs.rutgers.edu, ietf-822@dimacs.rutgers.edu Subject: X.400 and MIME Date: Sat, 15 Aug 92 18:30:14 PDT From: "Mr. Shannon Yeh" Just like to let you gentlemen know that I have no major negative view on the MIME specification, although I did not like the message segamentation idea. We have taken look at the implementation. In my next major MH release, MIME will be supported. During the past, several (more than 20) people sent me SMTP/822 based internet messages asking for "more information" about X.400. In my reply to them, I have to tell them the truth of "Like you, I am still using SMTP to send my messages. I am not an expert on X.400". I am glad to see some MIME contributors voice their opinions on the commercial magazines such as CommunicationsWeek. Many directors on many campuses (more than 100, if you do not trust me, feel free to do a survey) feel that "X.400" is more familiar to them than SMTP, "because I just saw the name of "X.400/500" on a magazine not a while ago", although they are using SMTP to send messages everyday. Let me make my point clear: One one hand, SMTP was and still is a successful protocol because so many people are using it; one the other hand, SMTP fails on "selling" itself--many people are using it, but they do not know what it is (I understand that all the scientists know what it is). I wish MIME would be better "advertised". shannon -------   Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03808; 15 Aug 92 22:17 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa17294; 15 Aug 92 22:18 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA05014; Sat, 15 Aug 92 21:35:12 EDT Received: from NETIX.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA05009; Sat, 15 Aug 92 21:35:00 EDT Received: from localhost.netix.com by netix.com (4.1/LLNL-1.18) id AA05131; Sat, 15 Aug 92 18:30:20 PDT Message-Id: <9208160130.AA05131@netix.com> To: ietf-smtp@dimacs.rutgers.edu, ietf-822@dimacs.rutgers.edu Subject: X.400 and MIME Date: Sat, 15 Aug 92 18:30:14 PDT From: "Mr. Shannon Yeh" Just like to let you gentlemen know that I have no major negative view on the MIME specification, although I did not like the message segamentation idea. We have taken look at the implementation. In my next major MH release, MIME will be supported. During the past, several (more than 20) people sent me SMTP/822 based internet messages asking for "more information" about X.400. In my reply to them, I have to tell them the truth of "Like you, I am still using SMTP to send my messages. I am not an expert on X.400". I am glad to see some MIME contributors voice their opinions on the commercial magazines such as CommunicationsWeek. Many directors on many campuses (more than 100, if you do not trust me, feel free to do a survey) feel that "X.400" is more familiar to them than SMTP, "because I just saw the name of "X.400/500" on a magazine not a while ago", although they are using SMTP to send messages everyday. Let me make my point clear: One one hand, SMTP was and still is a successful protocol because so many people are using it; one the other hand, SMTP fails on "selling" itself--many people are using it, but they do not know what it is (I understand that all the scientists know what it is). I wish MIME would be better "advertised". shannon -------   Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02119; 18 Aug 92 9:13 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa05118; 18 Aug 92 9:14 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA22070; Tue, 18 Aug 92 08:58:33 EDT Received: from lancaster.xtel.co.uk by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA22065; Tue, 18 Aug 92 08:58:29 EDT Received: from xtel.co.uk (actually tornado.xtel.co.uk) by lancaster.xtel.co.uk with SMTP (PP); Tue, 18 Aug 1992 13:41:56 +0100 To: ietf-smtp@dimacs.rutgers.edu Subject: Another thread. X-Phone: +44 602 412648 Date: Tue, 18 Aug 92 13:41:50 +0100 Message-Id: <6107.714141710@xtel.co.uk> From: Julian Onions As a bit of light relief from the current raging arguments... can anyone provide some insight into the following. SMTP streaming - how do you do this? By streaming, I mean firing off as many SMTP verbs as you can and then waiting for the answers. Has anyone implemented this successfully and how effective is it? How much does it win you, and does it work against all implementations. Might this be a good thing to put in an RFC on extended SMTP to give some guide lines as to good things to do and bad choices that can be made implementing this. My first stab at it would be to fire off HELO MAIL all RCPT 's then wait for the replies before sending DATA. If you get a bad return from MAIL you need to send a RSET, a bad return from MAIL would require just marking it internally unless all RCPT's fail in which case you issue a RSET again. Its my guess without thinking about it further that you can't stream any more than this. Comments? Julian.   Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04496; 18 Aug 92 12:16 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa09885; 18 Aug 92 12:17 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA24241; Tue, 18 Aug 92 12:02:38 EDT Received: from mp.cs.niu.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA24237; Tue, 18 Aug 92 12:02:33 EDT Received: by mp.cs.niu.edu with SMTP id AA21939 (5.67a/IDA-1.5 for ); Tue, 18 Aug 1992 11:02:02 -0500 To: j.onions@xtel.co.uk Cc: ietf-smtp@dimacs.rutgers.edu Subject: Re: Another thread. Newsgroups: info.ietf.smtp In-Reply-To: <6107.714141710@xtel.co.uk> Organization: Northern Illinois University Date: Tue, 18 Aug 92 11:02:00 -0500 Message-Id: <3568.714153720@mp.cs.niu.edu> From: Neil W Rickert In article <6107.714141710@xtel.co.uk> j.onions@xtel.co.uk (Julian Onions) writes: >SMTP streaming - how do you do this? >By streaming, I mean firing off as many SMTP verbs as you can and then >waiting for the answers. Simple. You don't do it. It violates to protocol, which is based on a dialogue as a model. >How much does it win you, and does it work against all implementations. It probably wins you a lot of grief. Unless the design takes into account the buffering and forking assumptions of sendmail, it will surely not work with all implementations.   Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04824; 18 Aug 92 13:18 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa11411; 18 Aug 92 13:19 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA24728; Tue, 18 Aug 92 12:57:34 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA24724; Tue, 18 Aug 92 12:57:32 EDT Received: from INFOODS.MIT.EDU by INFOODS.MIT.EDU (PMDF #2603 ) id <01GNQ6R9GV4G0001ZF@INFOODS.MIT.EDU>; Tue, 18 Aug 1992 12:57:11 EDT Date: 18 Aug 1992 12:57:11 -0400 (EDT) From: John C Klensin Subject: Re: Another thread. In-Reply-To: <3568.714153720@mp.cs.niu.edu> To: rickert@cs.niu.edu Cc: ietf-smtp@dimacs.rutgers.edu Message-Id: <714157031.646166.KLENSIN@INFOODS.MIT.EDU> X-Envelope-To: ietf-smtp@dimacs.rutgers.edu Content-Transfer-Encoding: 7BIT Mail-System-Version: > It probably wins you a lot of grief. Unless the design takes into >account the buffering and forking assumptions of sendmail, it will surely >not work with all implementations. Neil, I don't understand this. Not only have I repeatedly heard about implementation that do a certain amount of streaming to minimize stop-and-wait behavior, but I see nothing in the protocol that requires that behavior. Now one much clearly keep careful track of the responses that come back to know what verbs they are associated with, but nothing in the protocol, as I read it, justifies sending those back out of order. I've heard debates about whether one has to stop and wait before sending DATA, or whether one send DATA and then wait for everything up to the 354, but those are most of the active debates I'm aware of. Now, if an implementation lost state completely (i.e., behaved as if an implicit RSET had been delivered) after sending a 5xx reply to something, there clearly might be a problem but, even then, I read 821 to imply that it would just have to keep sending "command out of sequence" replies to subsequent verbs until some real resetting action occurred. Of course, I am here taking into account the (non-existent) buffering and forking assumptions of RFC821, rather that those of any particular correct or incorrect implementation. --john   Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05514; 18 Aug 92 14:18 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa12803; 18 Aug 92 14:19 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA25928; Tue, 18 Aug 92 13:48:10 EDT Received: from mp.cs.niu.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA25923; Tue, 18 Aug 92 13:48:08 EDT Received: by mp.cs.niu.edu with SMTP id AA03032 (5.67a/IDA-1.5 for ); Tue, 18 Aug 1992 12:47:51 -0500 To: John C Klensin Cc: ietf-smtp@dimacs.rutgers.edu Subject: Re: Another thread. In-Reply-To: Your message of "18 Aug 92 12:57:11 EDT." <714157031.646166.KLENSIN@INFOODS.MIT.EDU> Date: Tue, 18 Aug 92 12:47:49 -0500 Message-Id: <4309.714160069@mp.cs.niu.edu> From: Neil W Rickert on command streaming: >> It probably wins you a lot of grief. Unless the design takes into >>account the buffering and forking assumptions of sendmail, it will surely >>not work with all implementations. >Neil, > I don't understand this. Not only have I repeatedly heard about >implementation that do a certain amount of streaming to minimize >stop-and-wait behavior, but I see nothing in the protocol that requires >that behavior. Now one much clearly keep careful track of the responses >that come back to know what verbs they are associated with, but nothing >in the protocol, as I read it, justifies sending those back out of >order. Firstly, let me make it clear that I am only a user of sendmail, not the designer. I believe the following is a fairly accurate picture of how it handles the protocol. As background, sendmail reads the TCP stream as a buffered stream. If you are not familiar with Unix, remember that in normal process creation, fork() creates a child in almost all respects identical to the parent - and, most important, that there is no shared memory between parent and child. MAIL: On receipt of this command, sendmail fork()s. Parent: wait for child. Child: continue processing the tcp/ip buffered stream. RSET and the '.' at the end of data, reset state by exiting from the child. Parent resumes. Now, if the dialogue model of RFC821 is strictly followed, this works quite correctly. While processing the MAIL command, there is nothing beyond that in sendmail's I/O buffer. Likewise, after the RSET of the end of the DATA phase, there is nothing left in the child's buffer. The parent thus resumes by reading the next item in the tcp/ip stream. However, if some kind of streaming is practised, then the following happens: Anything batched in the stream after the RSET might still be in the child's buffer. If so, it is forever lost when the child terminates, and will never be read or processed by the parent. Anything batched in the stream after MAIL may still be in the parent's buffer, and will be processed a second time by the parent after the child terminates. I am aware that many people accuse sendmail of protocol violations. Some of these criticisms are true, and in any case I don't lose any sleep over them, since it is not my program. If I were designing an MTA I would not do the forking in this manner, mainly because that is not my programming style. But that does not alter the fact that this buffering and forking behavior is not one of sendmail's protocol violations. RFC821 very clearly defines a dialogue, so it is quite valid for sendmail to be designed on the assumption that a new command is not sent before the reply to the previous command has been received. > Now, if an implementation lost state completely (i.e., behaved as if >an implicit RSET had been delivered) after sending a 5xx reply to >something, there clearly might be a problem but, even then, I read 821 >to imply that it would just have to keep sending "command out of >sequence" replies to subsequent verbs until some real resetting action >occurred. What can happen is that the truncated child buffer, which is lost, does not contain a complete command. Thus the next "verb" read by the parent is really the tail end of an operand to another command. Or, the residual data in the parent buffer might not end at a CR-LF, so that the next verb in the data stream is treated as if appended as if an operand to the verb from the parent's buffer being reprocessed. > Of course, I am here taking into account the (non-existent) buffering >and forking assumptions of RFC821, rather that those of any particular >correct or incorrect implementation. RFC821 specifies a dialogue. The sendmail buffering and forking assumptions work correctly for a dialogue. Right now we have people stating that: sending 8bits over a 7bit channel is broken because it violates RFC821, and implementations that do so deserve to be punished. We also have people (the same people perhaps) saying: We need the EHLO stuff so that my pet violation of the protocol (i.e. streaming) will work, and I refuse to acknowledge that my protocol "reinterpretation" is broken. What's broken for the goose is broken for the gander. The sad part about the whole thing is that EHLO adds a whole bunch of worthless garbage to the protocol, but it does not provide the flexibility that would allow client and server to negotiate such things as data streaming. -NWR   Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa10927; 18 Aug 92 16:19 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa16525; 18 Aug 92 16:20 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA27169; Tue, 18 Aug 92 15:54:11 EDT Received: from binky.arc.nasa.gov by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA27165; Tue, 18 Aug 92 15:54:09 EDT Received: from localhost.arc.nasa.gov by binky.arc.nasa.gov (4.1/1.34) id AA20755; Tue, 18 Aug 92 12:53:55 PDT Message-Id: <9208181953.AA20755@binky.arc.nasa.gov> To: Neil W Rickert Cc: ietf-smtp@dimacs.rutgers.edu Subject: Re: last call on smtp-8bittransport In-Reply-To: Your message of "Tue, 18 Aug 92 07:45:55 CDT." <12656.714141955@mp.cs.niu.edu> Date: Tue, 18 Aug 92 12:53:50 MDT From: Jim Knowles Hi Neil, (Per repeated requests, I'm moving this to the smtp list.) > SIZE provides worthless information. It specifies the message size. > But it is defined to specify it as an approximation. What is an > approximation? Is a 1000% error permitted? I did suggest earlier, but > to no avail, that the data to SIZE include either > > estimated size error bound > or > lower size bound upper size bound SIZE is an upper bound, so it equals estimated size + error. In addition, SIZE is given in kilobytes. It's hard (for me) to imagine a case where the addition of headers will make a meaningful difference. The case of a small message with an encyclopedia of headers doesn't really apply until their total exceeds 64K. The client should have a pretty good idea of a reasonable upper bound on the message (including headers it adds). The server should treat the estimate as correct. > The problem is that SIZE and EHLO (in the way implemented) are not > needed for 8bit, but they change RFC in a way that is ugly, needlessly > complex, and because of their poor design will seriously hinder future > enhancements. Could you please expand on how future enhancements are hindered? > To implement SIZE and EHLO as specified: Enormously costly. The cost > is not a $$ cost. It is the cost of creating and releasing software > of which I am personally ashamed. It is an offense to my standards of > quality and integrity. Since your client never needs to use SIZE, I guess your objection is to the server's response to SIZE. I think it's very clear that the server should base its response on a comparison of the SIZE arg and its own upper limit. Why is this so offensive? Jim   Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa11186; 18 Aug 92 16:47 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa17226; 18 Aug 92 16:49 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA27326; Tue, 18 Aug 92 16:29:55 EDT Received: from mp.cs.niu.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA27322; Tue, 18 Aug 92 16:29:52 EDT Received: by mp.cs.niu.edu with SMTP id AA09494 (5.67a/IDA-1.5 for ); Tue, 18 Aug 1992 15:29:41 -0500 To: Jim Knowles Cc: ietf-smtp@dimacs.rutgers.edu Subject: Re: last call on smtp-8bittransport In-Reply-To: Your message of "Tue, 18 Aug 92 12:53:50 MDT." <9208181953.AA20755@binky.arc.nasa.gov> Date: Tue, 18 Aug 92 15:29:40 -0500 Message-Id: <18877.714169780@mp.cs.niu.edu> From: Neil W Rickert >Hi Neil, > >(Per repeated requests, I'm moving this to the smtp list.) > >> SIZE provides worthless information. It specifies the message size. >> But it is defined to specify it as an approximation. What is an >> approximation? Is a 1000% error permitted? I did suggest earlier, but >> to no avail, that the data to SIZE include either >> >> estimated size error bound >> or >> lower size bound upper size bound > >SIZE is an upper bound, so it equals estimated size + error. But the error is not adequately defined. If it is not defined, an implementation is forced to either: (a) treat SIZE as a NOP, accept the full message, and take size based action only when the true size is known. or (b) use guesswork, and sometimes refuse mail which might actually be within range. Since I assume the purpose of email is to get the message through, rather than to play protocol games, I find option (b) as unacceptable. Thus my standards of software quality would force me to use option (a). This means that the LIMIT value in EHLO would have to be given as effectively 0 INFINITY, and the listing of SIZE in the command verb listing of EHLO would be completely bogus but required by the proposed standard. It offends my quality standards to be required to give such bogus responses. >> The problem is that SIZE and EHLO (in the way implemented) are not >> needed for 8bit, but they change RFC in a way that is ugly, needlessly >> complex, and because of their poor design will seriously hinder future >> enhancements. > >Could you please expand on how future enhancements are hindered? Because the obvious way to implement SIZE is, as I indicated above, to treat it as a NO-OP. Once you realize this forces your EHLO response to contain a bogus SIZE verb, the obvious implementation of EHLO is to just dump the internal verb table into the output stream, without worrying whether the support for some of the verbs is half-baked. Indeed the proposal can be read as requiring this type of implementation of EHLO. I can almost guarantee that there will be implementations of this kind, that they will be amongst the first available, and that they will be widely adopted because of their early availability. Now, a few years down the road, suppose somebody tries to do something useful with EHLO. Then they discover that there are hundreds of thousands of hosts with just such an implementation, so that the EHLO response is partially bogus. No amount of screaming. It will be back to the drawing board, to create something that works properly. In the meantime new software will still have to honor EHLO for backwards compatibility. You would be much better off with just EMAL, and dropping EHLO and SIZE. This is enough to handle 8bit mail, so meets the immediate needs. Leave EHLO and SIZE till the future when a more forward looking design can be found. -NWR   Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa12123; 18 Aug 92 18:46 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa19693; 18 Aug 92 18:47 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA27961; Tue, 18 Aug 92 18:40:24 EDT Received: from binky.arc.nasa.gov by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA27957; Tue, 18 Aug 92 18:40:22 EDT Received: from localhost.arc.nasa.gov by binky.arc.nasa.gov (4.1/1.34) id AA21100; Tue, 18 Aug 92 15:40:16 PDT Message-Id: <9208182240.AA21100@binky.arc.nasa.gov> To: ietf-smtp@dimacs.rutgers.edu Subject: Re: last call on smtp-8bittransport In-Reply-To: Your message of "Tue, 18 Aug 92 15:29:40 CDT." <18877.714169780@mp.cs.niu.edu> Date: Tue, 18 Aug 92 15:40:12 MDT From: Jim Knowles Hi Neil, > But the error is not adequately defined. If it is not defined, an > implementation is forced to either: > > (a) treat SIZE as a NOP, accept the full message, and take > size based action only when the true size is known. > or > (b) use guesswork, and sometimes refuse mail which might actually > be within range. Yes, you can call a best-faith estimate guesswork. Yes, mail may (very rarely, I think) be refused when it should not be. Of course, the client chose to use the SIZE verb in this case, which means the client considers the benefit of this usage to outweigh the possible cost. Well, we pretty clearly disagree on which option to choose here, except that "use guesswork" should be replaced by "accept what the client told you". Since I don't buy your choice of NOP, I can't accept your arguments about the uselessness of the EHLO response. I think John Klensin gave a pretty thorough answer when you first claimed that the EHLO response was useless. He specifically denied that it was in any way OK to just dump the internal verb table. Listing SIZE means that the server will make a decision based on the SIZE argument and its own known limit. I don't understand how this is meaningless. > Now, a few years down the road, suppose somebody tries to do something > useful with EHLO. Then they discover that there are hundreds of thousands > of hosts with just such an implementation, so that the EHLO response is > partially bogus. No amount of screaming. It will be back to the drawing > board, to create something that works properly. In the meantime new > software will still have to honor EHLO for backwards compatibility. Perhaps a line should be inserted into the draft: Do not just dump the internal verb table. There is already an explanation of meaningful support which I think is entirely reasonable. It can certainly be beefed up. I'm not sure that would satisfy you. > You would be much better off with just EMAL, and dropping EHLO and SIZE. > This is enough to handle 8bit mail, so meets the immediate needs. Leave > EHLO and SIZE till the future when a more forward looking design can be > found. A number of folks in the WG disagree and think SIZE is useful and EHLO is meaningful. These concepts have been part of WG discussion for at least a year, so dropping them now does not seem appropriate. Jim   Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa00597; 19 Aug 92 4:13 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa01748; 19 Aug 92 4:14 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA01536; Wed, 19 Aug 92 03:45:07 EDT Received: from lancaster.xtel.co.uk by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA01532; Wed, 19 Aug 92 03:45:05 EDT Received: from xtel.co.uk (actually tornado.xtel.co.uk) by lancaster.xtel.co.uk with SMTP (PP); Wed, 19 Aug 1992 08:43:57 +0100 To: Jim Knowles Cc: Neil W Rickert , ietf-smtp@dimacs.rutgers.edu Subject: Re: last call on smtp-8bittransport In-Reply-To: Your message of Tue, 18 Aug 92 12:53:50 -0700. <9208181953.AA20755@binky.arc.nasa.gov> X-Phone: +44 602 412648 Date: Wed, 19 Aug 92 08:43:46 +0100 Message-Id: <11907.714210226@xtel.co.uk> From: Julian Onions > Hi Neil, > > (Per repeated requests, I'm moving this to the smtp list.) > > > SIZE provides worthless information. It specifies the message size. > > But it is defined to specify it as an approximation. What is an > > approximation? Is a 1000% error permitted? I did suggest earlier, but > > to no avail, that the data to SIZE include either > > > > estimated size error bound > > or > > lower size bound upper size bound > > SIZE is an upper bound, so it equals estimated size + error. In addition, > SIZE is given in kilobytes. It's hard (for me) to imagine a case where > the addition of headers will make a meaningful difference. The case of > a small message with an encyclopedia of headers doesn't really apply until > their total exceeds 64K. The client should have a pretty good idea of a > reasonable upper bound on the message (including headers it adds). The > server should treat the estimate as correct. Just a comment on this - something that I've found from implementing PP. You can be quite easily fooled by the actual size of the message and the envelope. One of the X.400 conformance tests is to see if an implementation can handle 32767 recipients (I might say PP can given sufficient VM - it takes a while though!). However this testing broke a number of assumptions. If you have a 1K message with 32767 recipients then a back-of-the-envelope calculation shows that you whilst the DATA size is 1K (no one is going to type 32767 addresses into a To line - this has to be a DL doesn't it!), the actual information the server needs to store though is probably 1K + 32767*40 = 1.3Mb which is not what it was expecting. ------ To: London-Residents:; From: Greater London Council Subject: Party to celebrate the end of the GLC This message is to invite all London residents to a wind up party for the GLC on Tuesday next. Contact your local councillor for more details Ken ------- You can just see the server on a laptop saying "sure, 1K, no problem" then 30 minutes later "help - stored 1Mb and still no sign of the 1K real data yet!" Julian.   Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa00958; 19 Aug 92 6:43 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa03672; 19 Aug 92 6:44 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA02254; Wed, 19 Aug 92 06:41:49 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA02250; Wed, 19 Aug 92 06:41:47 EDT Received: from INFOODS.MIT.EDU by INFOODS.MIT.EDU (PMDF #2603 ) id <01GNR7NHRFF40002BP@INFOODS.MIT.EDU>; Wed, 19 Aug 1992 06:40:51 EDT Date: 19 Aug 1992 06:40:51 -0400 (EDT) From: John C Klensin Subject: Re: last call on smtp-8bittransport In-Reply-To: <11907.714210226@xtel.co.uk> To: j.onions@xtel.co.uk Cc: jknowles@binky.arc.nasa.gov, rickert@cs.niu.edu, ietf-smtp@dimacs.rutgers.edu Message-Id: <714220851.600166.KLENSIN@INFOODS.MIT.EDU> X-Envelope-To: ietf-smtp@dimacs.rutgers.edu Content-Transfer-Encoding: 7BIT Mail-System-Version: Julian, Your example is quite interesting. It is also a pretty interesting argument for certain designs for some designs of mail sending and receiving relative to others, one that a few people in the ietf-remmail discussion should probably contemplate as they think about remote-system sending vs sending to a local server that does the network sending. But... SIZE applies, unless I forgot what I wrote, to message size, not envelope size. No help here. If you intend that your sender take London-residents and expand it so that each recipient sees all of the others (the only place that message size, not envelope size, becomes relevant), your recipients are going to be *very* unhappy, as is your network. And, if I recall, the minimum value for imposing "max number of recipients" in RFC1123 and/or RFC821 is a lot lower than the 32K of X.400. If you exceed the listed limit by an order of magnitude or more, you will break, or be rejected by, a lot of systems and make yourself real unpopular. john   Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa06113; 19 Aug 92 15:49 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa17864; 19 Aug 92 15:50 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA06555; Wed, 19 Aug 92 15:33:07 EDT Received: from mp.cs.niu.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA06550; Wed, 19 Aug 92 15:33:01 EDT Received: by mp.cs.niu.edu with SMTP id AA01088 (5.67a/IDA-1.5 for ); Wed, 19 Aug 1992 14:32:57 -0500 To: ietf-smtp@dimacs.rutgers.edu Subject: Re: last call on smtp-8bittransport Date: Wed, 19 Aug 92 14:32:55 -0500 Message-Id: <1446.714252775@mp.cs.niu.edu> From: Neil W Rickert I am forwarding my reply to private correspondence from Ned Freed. I think the issue I am making is widely misunderstood, and I hope my comments here, particularly those on EHLO, will help to clarify this. My reply does include some quotes from Ned's letter. I don't believe I am quoting him out of context, but if I am, I invite Ned to set the record straight. ------- Forwarded Message Date: Wed, 19 Aug 92 11:46:54 -0600 From: Neil W Rickert To: Ned Freed cc: NED@INNOSOFT.COM Subject: Re: last call on smtp-8bittransport >> Such an implementation is technically BROKEN. > >I don't think so... I would say rather than the standards are neutral on this >point. I only know that there was a very strong desire expressed in the Workin g >Group to make sure that streaming implementations are not inconvenienced by th e >changes we made. And since it was fairly easy to not inconvenience such >implementations we chose not to do so. I hope that by now you have read my fairly detailed comments of the problems this will have interfacing with sendmail (on the IETF-SMTP mailing list). >As far as I know streaming is neither prohibited or allowed by the current >protocol specification. If there's a section of the specification that >addresses this I'd like to know what it is. FROM RFC821: 4.3. SEQUENCING OF COMMANDS AND REPLIES The communication between the sender and receiver is intended to be an alternating dialogue, controlled by the sender. Your streaming violates this assumption of a dialogue. The implementation of sendmail happens to be sensitive to this. Perhaps other implementations are too. >However, the specifications do say EXPLICITLY that SMTP is 7-bit. No ifs, no >ands, no buts. No ifs, ands, or buts about the dialogue either. >You can take whatever position you like on streaming, but the fact of the >matter is that it is not addressed by RFC821 whereas 8-bit definitely is. You >therefore cannot take conclusions drawn from the Working Group's decision to >not inconvenience streaming and apply them to 8-bit. If the purpose of EHLO is to "not inconvenience streaming" then it is a waste of time, since streaming violates the dialogue model which is not repealed in the new proposal. >There are clearly a lot of issues you have to deal with if you want to stream. >It may even need to be negotiated in the protocol. There are certainly efforts But EHLO is too imprecise a tool for this type of negotiation. That is my main objection to it. I specifically object to the wording which armtwists you into listing a verb you "support" without any adequate definition of support. If EHLO is to be useful, there needs to be a clear and precise specification of the minimum standards a verb must meet before the EHLO response lists it. By "clear and precise" I mean to suggest much more precision than is present in RFC821. I see EHLO as poorly considered and premature. It should be delayed until it is better defined. >You have made a very marginal aesthetic case here that SIZE should be optional . >It is so thin and so marginal that I don't see it overriding the reasons why i t >is currently mandatory. (See the archives for details.) But even if I agreed >with you about SIZE it would not be an argument against the concept of EHLO. When you effectively announce: Thou shalt implement SIZE, even if only as a dummy, and thou shalt list it as implemented in the EHLO response even if it is a dummy implementation you are thereby setting a standard of quality for EHLO responses. That standard is too low and threatens the usefulness of EHLO. The biggest problem with EHLO is that the WG has not properly considered what quality of support for a verb reported by EHLO is needed if EHLO is to be useful. There are too many things underspecified in RFC821, RFC1123, etc, so that one has to depend on folklore to find the real meaning. Folklore is not ideal, but tolerable when humans have to make the interpretation. EHLO is only of significant use if it is to be used by software rather than people. This needs a much stricter standard of specificity. >I agree that this should be more clearly specified, but there are plenty of >similar things in SMTP. For example, suppose you issue two RCPT TOs and the >second one gets an error. But the server chooses to treat this error as a >"reset state" and it forgets the first RCPT TO. This is not only a perfectly >legal interpretation of the standard, it is also a "feature" of at least one >server implementation I know of. This strongly supports my argument about EHLO. You could specify that a server behaving this way must not list RCPT in its EHLO response. The point I am making is that EHLO is a golden opportunity to clear up the confusion, and improve the reliability of SMTP. But this proposal blows that opportunity. Let me reiterate. It is not that EHLO cannot be implemented. My complaint is that you are almost guaranteeing that it will be implemented in such a way that it will not be very useful. >In any case, the intent is certainly not to let this detail slide. It is just >one of many things that need to get cleaned up in SMTP, and the Working Group >has plans to work on things of this sort. But this cannot happen until the >initial round of SMTP extensions are done. You will be forever locking the barn door after the EHLO horse has escaped. Just add EMAL for now. Then clean up the protocol. Then add EHLO for a cleaned up protocol. That will set a standard for the future. But adding EHLO now without the cleanup means that your cleanup will be too little too late. >And how about the non-streaming case? Surely you must agree with the notion of >the desireability of minimizing turnarounds in SMTP. EHLO lets you find out >precisely what commands are available so you can avoid using ones that are not >implemented. It also includes a very useful piece of extra information (SIZE). In what way does it minimize turnaround if EHLO reports that SIZE is implemented when the implementation is a dummy? This would seem to encourage the client to send SIZE, even though the server will not do anything useful with it. >There's no real difference between using EMAL directly versus EHLO and then >EMAL in terms of turnarounds. But what if you plan to use EVFY as well as EMAL ? >And what if negotiated (or announced) streaming capabilities are added? I think I have said enough for you to get my point. My long term objectives are probably similar to yours. I object to EHLO because it is premature and will be a serious hindrance to meeting those objectives. -NWR ------- End of Forwarded Message   Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa06730; 19 Aug 92 16:43 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa19364; 19 Aug 92 16:44 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA07224; Wed, 19 Aug 92 16:27:54 EDT Received: from dkuug.dk by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA07220; Wed, 19 Aug 92 16:27:51 EDT Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8) id AA22823; Wed, 19 Aug 92 22:27:40 +0200 Date: Wed, 19 Aug 92 22:27:40 +0200 From: Keld J|rn Simonsen Message-Id: <9208192027.AA22823@dkuug.dk> To: ietf-smtp@dimacs.rutgers.edu Subject: IANA registration X-Charset: ASCII X-Char-Esc: 29 Hello! As you may have noted, RFC 1345 (RFC-CHAR) contained a clause that the names in that document would be registered with IANA. I have asked IETF officers on how to do it but have not got a response. Could someone enlighten me on how to get in contact with IANA and how to register the names? Keld Simonsen   Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa07052; 19 Aug 92 17:12 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa19908; 19 Aug 92 17:13 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA07330; Wed, 19 Aug 92 16:38:07 EDT Received: from wolf.cisco.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA07326; Wed, 19 Aug 92 16:38:05 EDT Received: from regal.cisco.com by wolf.cisco.com with TCP; Wed, 19 Aug 92 13:37:59 -0700 Message-Id: <9208192037.AA23725@wolf.cisco.com> To: Neil W Rickert Cc: ietf-smtp@dimacs.rutgers.edu Subject: Re: last call on smtp-8bittransport In-Reply-To: Mail from Neil W Rickert dated Wed, 19 Aug 92 14:32:55 CDT <1446.714252775@mp.cs.niu.edu> Date: Wed, 19 Aug 92 13:37:58 PDT From: "Mark D. Baushke" I find Neil's arguments to be well reasoned. We might do well to elide all mention of the EHLO from this draft and try to lock down exact meanings for EHLO the next time around... -- Mark   Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ab07320; 19 Aug 92 17:42 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa20899; 19 Aug 92 17:43 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA07494; Wed, 19 Aug 92 17:02:02 EDT Received: from SGI.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA07490; Wed, 19 Aug 92 17:01:59 EDT Received: from relay.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for ietf-smtp@dimacs.rutgers.edu id AA08662; Wed, 19 Aug 92 14:01:49 -0700 Received: from yeager.corp.sgi.com by relay.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgi.sgi.com:rickert@cs.niu.edu id AA05754; Wed, 19 Aug 92 14:01:40 -0700 Received: by yeager.corp.sgi.com (920330.SGI/911001.SGI) for @sgi.com:ietf-smtp@dimacs.rutgers.edu id AA16210; Wed, 19 Aug 92 14:01:26 -0700 Date: Wed, 19 Aug 92 14:01:25 PDT From: Eliot Lear To: Neil W Rickert Cc: ietf-smtp@dimacs.rutgers.edu Subject: Re: last call on smtp-8bittransport In-Reply-To: Your message of Wed, 19 Aug 92 14:32:55 -0500 Message-Id: > Just add EMAL for now. Then clean up the protocol. Then add > EHLO for a cleaned up protocol. That will set a standard for the future. > But adding EHLO now without the cleanup means that your cleanup will be > too little too late. I'm sorry I didn't jump in sooner, but I've been out of the country, and I'm still in the process of catching up. However, Neil's statement above is asking us to make two consecutive protocol changes to SMTP. Forget it. It'll be hard enough getting one change out there. If there's a problem (and I'm still not decided if there is), let's fix it now and not have to go through numerous iterations of this protocol. The working assumption has been that once MIME made it out the door, there would be no drastic dire need to get something out the door really fast. More on your arguments as I catch up on my 5385 messages. Eliot Lear [lear@sgi.com]   Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ac07411; 19 Aug 92 18:12 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa21618; 19 Aug 92 18:14 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA07604; Wed, 19 Aug 92 17:26:24 EDT Received: from SGI.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA07600; Wed, 19 Aug 92 17:26:21 EDT Received: from relay.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for ietf-smtp@dimacs.rutgers.edu id AA11310; Wed, 19 Aug 92 14:26:18 -0700 Received: from yeager.corp.sgi.com by relay.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgi.sgi.com:ietf-smtp@dimacs.rutgers.edu id AA06103; Wed, 19 Aug 92 14:26:11 -0700 Received: by yeager.corp.sgi.com (920330.SGI/911001.SGI) for @sgi.com:ietf-smtp@dimacs.rutgers.edu id AA16534; Wed, 19 Aug 92 14:25:57 -0700 Date: Wed, 19 Aug 92 14:25:56 PDT From: Eliot Lear To: ietf-smtp@dimacs.rutgers.edu Subject: on buffering and sendmail Message-Id: Here's a short example of what Neil is talking about: 220 Argus.Stanford.EDU Sendmail 5.65/inc-1.0 ready at Wed, 19 Aug 92 14:24:16 -0700 mail from: rset mail from: rset mail from: rset mail from: rset 250 ... Sender ok 250 Reset state mail from: rset 250 ... Sender ok 250 Reset state mail from: rset 250 ... Sender ok 250 Reset state quit 221 Argus.Stanford.EDU closing connection Eliot Lear [lear@sgi.com]   Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa07561; 19 Aug 92 18:44 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa22379; 19 Aug 92 18:45 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA07767; Wed, 19 Aug 92 17:59:39 EDT Received: from [192.160.253.70] by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA07763; Wed, 19 Aug 92 17:59:35 EDT Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF #1339 ) id <01GNRPU1PE9C9BVHR9@SIGURD.INNOSOFT.COM>; Wed, 19 Aug 1992 14:59:30 PDT Date: 19 Aug 1992 14:59:30 -0700 (PDT) From: Ned Freed Subject: Re: last call on smtp-8bittransport To: mdb@cisco.com Cc: ietf-smtp@dimacs.rutgers.edu Message-Id: <01GNRPU1PE9E9BVHR9@SIGURD.INNOSOFT.COM> X-Envelope-To: ietf-smtp@dimacs.rutgers.edu X-Vms-To: IN%"mdb@cisco.com" X-Vms-Cc: IN%"ietf-smtp@dimacs.rutgers.edu" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT I can debate Neil's arguments point by point, but quite aside from that the notion of removing EHLO now is NOT acceptable to me. Consider: If we deploy some extensions now without EHLO, this means that implementations can (and will) exist with EMAL and no EHLO. Now, since the entire point of having EHLO is to be able to find out what extended capabilities exist in one go, this effectively makes EHLO useless both now and in the future for finding out about EMAL. And since EMAL is intended to meet the most pressing need we have for extension, this makes EHLO useless to most applications. In short, the problem with Neil's proposal to remove EHLO now and save it for later is that doing so renders EHLO useless in precisely the way that Neil claims is the problem now. His solution directly causes the problem we're trying to avoid, whereas not implementing his solution debatably causes a problem. In short, if we agree that there's a problem with EHLO by all means let's fix it. But removing it is no solution at all and in addition renders any attempt at a solution in the future largely a hopeless task. Rather than demanding that the extensions be crippled by the lack of a vital piece of functionality, how about we do something positive and repair that functionality? If you or Neil or whoever have a problem with the description of EHLO please suggest a change to make it something that will work. As for streaming, if there's a problem with doing it maybe we should seriously consider adding some support for negotiating it. Ned   Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ab08254; 19 Aug 92 21:12 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa24570; 19 Aug 92 21:14 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA08708; Wed, 19 Aug 92 20:54:54 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA08701; Wed, 19 Aug 92 20:54:51 EDT Received: from INFOODS.MIT.EDU by INFOODS.MIT.EDU (PMDF #2603 ) id <01GNS2HOQWE80002E0@INFOODS.MIT.EDU>; Wed, 19 Aug 1992 20:54:16 EDT Date: 19 Aug 1992 20:54:15 -0400 (EDT) From: KLENSIN@infoods.mit.edu Subject: EMAL and its definition To: ietf-smtp@dimacs.rutgers.edu, rdhobby@ucdavis.edu Message-Id: <01GNS2HOR61E0002E0@INFOODS.MIT.EDU> X-Envelope-To: ietf-smtp@dimacs.rutgers.edu Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT Ok, I think this has gone back and forth long enough, and no one is convincing anyone else. Consequently, if Russ approves, I'd like to try to partition the issues and make a constructive suggestion or two. First of all, I think we have two easily-confused discussions going on here. Let me categorize them (probably overdramatizing a bit) as: Group 1: EMAL is totally useless and aesthetically disgusting to boot. SIZE is in the same category, and the LIMIT component of EMAL is even more useless and disgusting than the rest of it. Group 2: EMAL would be fine if only the minimum requirements for claiming "support" for each and every one of the SMTP verbs--both "enhanced" and in 821--is laid out in comprehensive detail. The definition of SIZE also needs tightening and tuning. It is clearly logically possible to have Group 1 beliefs about EMAL and Group 2 beliefs about SIZE or vice versa. I haven't detected that on the list, but it may be out there. It does not make much difference operationally, but anyone who finds themselves in that situation will need to read what follows somewhat interpretatively. Now, group 1 folks: Take it up with IESG if you haven't already, using the IESG list, not the IETF one. It has been discussed, it has been discussed several times, and, as far as the WG's ability to make decisions is concerned, it is out of the WG's hands and you may be kicking a dead horse. Group 2 folks: I assert that it is logical and sensible to go ahead with trial implementations at the level appropriate to proposed standards without getting things written down much further than they are. If questions arise as to appropriate levels of support or implementation to constitute "supported", I'd encourage you to raise those on the list, ideally in "would this be adequate or do we need to insist on that" form. I volunteer, with some trepidation, to keep track and start putting together some text, either to enhance the specification as it is revised for "draft" or to construct a separate Applicability Statement draft RFC (that choice is, in the end, up to IESG). Perhaps even more than testing code and being sure things can be implemented, document testing against implementation and use experience is the only effective way I know to determine what is adequately specified so that people acting independently but in good faith come up with the same (or at least tolerably interoperable) results. While we might be able to catch a few, the general process of asserting to each other that things aren't tight enough just isn't going to be adequate. In addition to making that statement from general experience, I've scanned quickly through the discussion on this topic over the last week, and haven't been able to identify a single instance of a proposed fix to a specific section of the document. Lots of complaints, some more specific than others, but no fixes. But I haven't heard an assertion that things can't be fixed together with any set of comments that I would describe as being in group 2. Now, if we try to implement things, and we discover that more specification is needed to make them interoperable, and we can't figure out how to write good enough specifications... well, we have demonstrated non-interoperability, which is a very important result. But let's set up the demonstration, not continue to discuss whether or not it has been done yet. One additional observation from painful experience: I referred above to writing things so that they were good enough to make good-faith implementations interoperable. I've detected (perhaps erroneously) some concerns about making the definitions tight enough that they can make even bad-faith implementations interoperable; to so define and constrain things that any bad-faith implementation that can plausibly claim conformance is no worse operationally than a good-faith implementation. I won't claim that is impossible. I will claim that is is certainly not worth the effort. It may even be a threat to practical interoperability, since it tends to create documents so long and complex that the good-faith folks won't read them. I speak, unfortunately, from experience with a WG that tried (in a non-IETF context). If we appear to be accumulating things rapidly enough at the time a decision has to be made to make it worthwhile, I'll schedule a WG session in Washington to start hammering out a draft (I had not planned on the WG needing to meet then). Conversely, if there is no accumulation of definitional text before Washington, it will probably be possible for us pragmatists to conclude either that the text is adequate as is or that the "group 2" folks were really crypto-"group 1" folks. Or, of course, that no one cares about or has tried implementing this protocol. Russ: this suggestion involves taking a flying, if somewhat unintended, leap into the "SMTP requirements" part of the mail [conformance] requirements business. OK? --john   Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08494; 19 Aug 92 23:15 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa26117; 19 Aug 92 23:17 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA09976; Wed, 19 Aug 92 22:21:30 EDT Received: from mp.cs.niu.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA09972; Wed, 19 Aug 92 22:21:28 EDT Received: by mp.cs.niu.edu id AA27231 (5.67a/IDA-1.5 for ietf-smtp@dimacs.rutgers.edu); Wed, 19 Aug 1992 21:21:26 -0500 Date: Wed, 19 Aug 1992 21:21:26 -0500 From: Neil Rickert Message-Id: <199208200221.AA27231@mp.cs.niu.edu> To: ietf-smtp@dimacs.rutgers.edu Newsgroups: info.ietf.smtp Subject: Re: last call on smtp-8bittransport References: <01GNRPU1PE9E9BVHR9@SIGURD.INNOSOFT.COM> Organization: Northern Illinois University In article <01GNRPU1PE9E9BVHR9@SIGURD.INNOSOFT.COM> NED@sigurd.innosoft.com (Ned Freed) writes: > >As for streaming, if there's a problem with doing it maybe we should >seriously consider adding some support for negotiating it. If you think a little about negotiating streaming, you might see one of the limitations of EHLO. It is not extensible. You can add new verbs, but you probably wouldn't want to do that. But its reporting of internal parameters only allows the LIMIT parameters; there is no provision for extensibility here, say to report streaming support.   Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08397; 19 Aug 92 22:43 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa25683; 19 Aug 92 22:45 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA09996; Wed, 19 Aug 92 22:23:05 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA09992; Wed, 19 Aug 92 22:23:03 EDT Received: from INFOODS.MIT.EDU by INFOODS.MIT.EDU (PMDF #2603 ) id <01GNS58QBAG00002P0@INFOODS.MIT.EDU>; Wed, 19 Aug 1992 22:22:17 EDT Date: 19 Aug 1992 22:22:16 -0400 (EDT) From: John C Klensin Subject: EMAL (sic) and its definition To: ietf-smtp@dimacs.rutgers.edu Cc: rdhobby@ucdavis.edu Message-Id: <714277336.345166.KLENSIN@INFOODS.MIT.EDU> X-Envelope-To: ietf-smtp@dimacs.rutgers.edu Content-Transfer-Encoding: 7BIT Mail-System-Version: It was generously pointed to me that, in my earlier message, I meant to say--and be discussing--the questions about EHLO, not EMAL, although I referred to the latter in the text. sorry for any confusion. john   Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa00385; 20 Aug 92 2:45 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa00599; 20 Aug 92 2:46 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA11229; Thu, 20 Aug 92 02:26:11 EDT Received: from [192.160.253.66] by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA11224; Thu, 20 Aug 92 02:26:00 EDT Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF #1336 ) id <01GNS7RFRT5S94DWWP@INNOSOFT.COM>; Wed, 19 Aug 1992 23:25:47 PST Date: 19 Aug 1992 23:25:47 -0800 (PST) From: Ned Freed Subject: Re: last call on smtp-8bittransport To: rickert@cs.niu.edu Cc: ietf-smtp@dimacs.rutgers.edu Message-Id: <01GNS7RFS2SY94DWWP@INNOSOFT.COM> X-Vms-To: IN%"rickert@cs.niu.edu" X-Vms-Cc: IN%"ietf-smtp@dimacs.rutgers.edu" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > > As for streaming, if there's a problem with doing it maybe we should > > seriously consider adding some support for negotiating it. > If you think a little about negotiating streaming, you might see one of > the limitations of EHLO. Streaming isn't negotiated, really -- according to my current understanding it is something that a server would announce that it is capable of. A client would then use it or not as it chooses. > It is not extensible. You can add new verbs, > but you probably wouldn't want to do that. Not true. I can think of at least three new verbs right off that may make a lot of sense to have in the future. > But its reporting of internal > parameters only allows the LIMIT parameters; there is no provision for > extensibility here, say to report streaming support. I think adding such functionality would be a great idea. By all means let's fix this aspect of EHLO. Incidentally, while there's nothing in the document that explicitly allows such parameters I don't see text explicitly prohibiting them in so many words either. The text does say that you can only list standardized verbs (modulo X-verbs) and quite clearly a standardized verb if listed has to be used in manner in which the standard defining it specifies. I therefore don't see much point in distinguishing between parameters and verbs since you cannot capriciously use something on the list in an arbitrary way. In any case, I don't see any problem with explicitly allowing new standardized parameters as well. The only question is do we need a way to tell the difference between a verb and a parameter on the list. Ned   Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01693; 20 Aug 92 9:15 EDT Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa06456; 20 Aug 92 9:16 EDT Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA12888; Thu, 20 Aug 92 09:04:31 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA12884; Thu, 20 Aug 92 09:04:29 EDT Received: from INFOODS.MIT.EDU by INFOODS.MIT.EDU (PMDF #2603 ) id <01GNSQ0TJOG000024B@INFOODS.MIT.EDU>; Thu, 20 Aug 1992 09:03:46 EDT Date: 20 Aug 1992 09:03:45 -0400 (EDT) From: John C Klensin Subject: Re: last call on smtp-8bittransport In-Reply-To: <01GNS7RFS2SY94DWWP@INNOSOFT.COM> To: NED@innosoft.com Cc: rickert@cs.niu.edu, ietf-smtp@dimacs.rutgers.edu Message-Id: <714315825.752166.KLENSIN@INFOODS.MIT.EDU> X-Envelope-To: ietf-smtp@dimacs.rutgers.edu Content-Transfer-Encoding: 7BIT Mail-System-Version: >Incidentally, while there's nothing in the document that explicitly allows such >parameters I don't see text explicitly prohibiting them in so many words >either. Deliberate :-) >The text does say that you can only list standardized verbs (modulo >X-verbs) and quite clearly a standardized verb if listed has to be used in >... Registered, actually. If the word "standardized" crept into the final draft, it was a typo. My reading of the intent of the WG was clearly only to require registration and description of these things. Now it would be stupid to try to put a verb to any serious general use with standardizing it and documenting it, but one might register for use in a restricted community without wanting to standardize. This is particularly important for backward-looking toward things that are already floating around in SMTP and near-SMTP implementations, a few of which have proven to be not-good ideas. To give a handy example, as the things that sit on the BITNET/Internet boundary are upgraded to support these extensions, I would expect them to want to list TICK in the EHLO response: while TICK has turned out to be ill-advised, I don't see people removing support for it where that support exists. But one would certainly not want to "standardize" the thing; registration with a brief description and a note that its advice was advised against should be more than sufficient. >In any case, I don't see any problem with explicitly allowing new standardized >parameters as well. I don't either. It wasn't done for two reasons. One of them was clearly that it was just overlooked, probably due to general exhaustion. The other was that, having been [quite appropriately] beaten up by several people (including, I think, Neil) about being specific about what was to be listed, the registration issues, etc., I didn't have the energy, at least absent guidance and suggestions from a WG that seemed equally exhausted, to write similar rules for parameters. I don't think that would be particularly difficult, however, especially since, with the one-response-componet-per-line model, a client doesn't have to pay any real attention to any line it does not recognize. One must, of course, have sufficient registration/ definition/ standardization that a client that thinks it does recognize something can be confident about what it means and what its semantics are, but that is no different for parameters than it is for verbs. And the questions about optionality/requiredness of reporting may be a tad more complex for parameters than for verbs. But it probably isn't a big deal. >The only question is do we need a way to tell the >difference between a verb and a parameter on the list. I'd be surprised. It would have been much more important had we chosen a different syntax. --john   Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09547; 20 Aug 92 16:27 EDT Received: from ietf.NRI.Reston.Va.US by NRI.Reston.VA.US id aa18344; 20 Aug 92 16:28 EDT Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id ab09540; 20 Aug 92 16:26 EDT To: Keld J|rn Simonsen cc: ietf-smtp@dimacs.rutgers.edu, gvaudre@NRI.Reston.VA.US Subject: Re: IANA registration In-reply-to: Your message of "Wed, 19 Aug 92 22:27:40 +0200." <9208192027.AA22823@dkuug.dk> Date: Thu, 20 Aug 92 16:26:56 -0400 From: Greg Vaudreuil Message-ID: <9208201626.ab09540@IETF.NRI.Reston.VA.US> keld, Unless I am mistaken, the complete list of character sets listed in the charsets RFC are currently listed with IANA and are in the latest assigned numbers RFC. For more info, contact iana@isi.edu. Greg V.   Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa10940; 27 Aug 92 0:42 EDT Received: from NIC.DDN.MIL by NRI.Reston.VA.US id aa27558; 27 Aug 92 0:44 EDT Received: by nic.ddn.mil (4.1/SMI-4.1) id AA01900; Wed, 26 Aug 92 23:05:08 EDT Return-Path: Received: from netix.com by nic.ddn.mil (4.1/SMI-4.1) id AA01878; Wed, 26 Aug 92 23:05:01 EDT Received: from localhost.netix.com by netix.com (4.1/LLNL-1.18) id AA00859; Wed, 26 Aug 92 20:00:14 PDT Message-Id: <9208270300.AA00859@netix.com> To: tcp-ip@nic.ddn.mil, ietf-smtp@dimacs.rutgers.edu Cc: yeh@netix.com Subject: a problem with the POP3 implementation (not necessarily a bug) Date: Wed, 26 Aug 92 20:00:09 PDT From: "Mr. Shannon Yeh" when the user has many messages (say 100) in their mailbox, if he/she stops the message incorporating process when he/she is incorporating the 51th message (an example number), the mailbox status, in my view, should be updated. This is critical to those users who use the SLIP based mail program such as my Smail. shannon -------