Date: Wed, 28 May 1997 09:54:01 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: cmsedore@mailbox.syr.edu (Christopher Sedore) Cc: terry@lambert.org, black@zen.cypher.net, rssh@cki.ipri.kiev.ua, FreeBSD-Hackers@FreeBSD.ORG Subject: Re: async socket stuff Message-ID: <199705281654.JAA01864@phaeton.artisoft.com> In-Reply-To: <Pine.SOL.3.95.970527233304.11962D-100000@rodan.syr.edu> from "Christopher Sedore" at May 27, 97 11:41:54 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > It's not generally useful, either. For instance, for POP3 and SMTP > > mail processing, "." quoting must take place. You have to adulterate > > the RFC's and *store* the data quoted (assuming that it will be going > > out on the same type of, or similar, transport it came in on) if you > > wish to use this facility for, for instance, POP3 lookup or SMTP > > forwarding. > > I was not aware that the RFC's required you to store the data in any > particular format on the hosts. I believe you are free to store it any > way you choose: quoted, not quoted, encrypted, rot13'd, XORed, compressed, > etc. See RFC 821 section "4.5.2. TRANSPARENCY". Quoting is required to take place on entering the transport, and unquoting is required to take place when leaving the transport. This is why I specifically referenced an operation involved with getting on and off the transport. Sure, you can store the data quoted, but you have to do it outside the transport data stream; the endpoint for the transport data stream is clearly (and rigidly) defined. I suppose you could use TransmitFile() on a socket with a line discipline that understood quoting and dequoting; but then we are putting even more crap in the kernel. > The real problem is with the protocol, not the transfer facilitiy. Any > transmission facility that requires in-band quoting will never be > high performance. If you want a fast POP server, store the messages in > transmission format. Same for SMTP. If you have to gateway, then > convert them on input and store them for relay. Technically, then, the data would be enqueued on the transport. So if you do an SMTP RCPT TO:, and then a POP RETR #, that would work. But say your RFC 821 MTA is capable of other things. Like storing in a mailbox not accessed via POP. This would require either a front end for all mail programs (elm, pine, mh, exmh, etc.) to do the unquoting from the potentially-POP-accessed mailbox. Routing to mailing lists and programs and transports that do not do quoting is even more problematic; consider an ISP with a CC:mail or MAPI gateway on an ISP box. > That this makes more sense in some cases than others I'll readily admit. > I still believe that this is primarily a protocol weakness, though. It's as much of a protocol weakness as protocols which require content transfer encoding on bit-stuffing as it is on protocols requiring byte stuffing. This pretty much covers all instances of in-band encapsulation which exist. 8-). > If you want to start talking about places for redesign, let's start with > the protocols--they're the main source of the problem. Transmitfile-like > APIs would be very general solutions if the protocols had been designed > for high-performance transfer in the first place. You would still need to encapsulate the file with a length-encoding header. Part of the problem with this is that some platforms are evilly unlike UNIX: the use <CR><LF> instead of <LF> for EOL marking, like God intended. This is a function of CICS terminal drivers, among other things, and means that line encapsulation must take place in order to transport the data. This throws off the encapsulation size. Do you store the mail file as <LF> or <CR><LF> terminated? Or do you store it as <CR> terminated, ala Macintosh? I think byte-stuffing protocols are perfectly reasonable; the cannonically correct place to deal with this is in the line discipline (heh -- in the cannonical processing code). We do it for HDLC, we might as well do it for this. Note that telnet, rlogin, rsh, exec, finger, and about any other inter-platform capable protocol does line cannonization, so you aren't going to escape the problem that easily. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705281654.JAA01864>