mike@BRL.ARPA (Mike Muuss) (09/10/86)
I though there was general agreement that tab stops were every 8 characters? I don't know if this is official NETASCII, but since TOPS-20, UNIX, and VMS all do it this way, most systems go along. -Mike
MRC@SIMTEL20.ARPA (Mark Crispin) (09/10/86)
Vint - So far as I know Multics is the only operating system in common use on the Internet which does not use tab stops at every 8th character. My experience suggests that it is basically hopeless in a true heterogenous environment to use tab stops at any other position due to the large number of terminals which do not offer settable tab stops. I admit that "8 tabs" are hopelessly hacker oriented and probably aren't santioned by any standard, but c'est la vie. Many of the Internet protocols are hopelessly hacker oriented. I'm sure ISO will "improve" this situation; I have no way of telling if ISO will do anything to improve it though. If you read your mail at A.ISI.EDU (as opposed to having some agent pick it up and pass it on to your real mailbox), you should know that A.ISI.EDU is a TOPS-20 system and TOPS-20 uses 8 tabs exclusively. Tenex had programmable tabs, but this functionality was deleted in TOPS-20. Therefore, it is correct that any terminal connected to a TOPS-20 system should use 8 tabs. I think the same is true for Unix and VAX/VMS. If not I'm sure I'll receive 1000 messages telling me what an idiot I am... -- Mark -- -------
Walker@RADC-MULTICS.ARPA ("Robert K. Walker 'Bob'") (09/11/86)
Date: 9 September 1986 20:22 edt From: Mike Muuss <mike at BRL> Subject: Re: Formatting Query I though there was general agreement that tab stops were every 8 characters? I don't know if this is official NETASCII, but since TOPS-20, UNIX, and VMS all do it this way, most systems go along. -Mike Tab stops every 8 characters may be the convention for DEC equipment, which was what was mentioned. However, the Multics convention is every 10 characters. I have FTP'ed files from DEC machines with the tab codes present, only to get a very ragged looking format when it is interpretted by Multics. This is a nuisance. -Bob Walker-
Ata@RADC-MULTICS.ARPA ("John G. Ata") (09/11/86)
I think the point is being missed here with regard to tab stops. If everyone on the network interpreted tabs the same way, this transaction would never have been started. Since there is variation on tab interpretation, it would seem that if the SMTP mailers expanded the tabs to the appropiate number of spaces, then compatability would be assured. The only negative effect of this might be to people who FTP files via mail, and who might not get exactly the same file on the other side. However, they might wish to to use FTP instead... John G. Ata
jordan@UCBARPA.BERKELEY.EDU (Jordan Hayes) (09/11/86)
From: "John G. Ata" <Ata@RADC-MULTICS.ARPA> Since there is variation on tab interpretation, it would seem that if the SMTP mailers expanded the tabs to the appropiate number of spaces, then compatability would be assured. Wow, did this come out of left field or am I really missing something? I don't really think you want to do this ... /jordan ps: maybe a better way of looking at tabs is like those stupid vt100 escape sequences that lock up my terminal, but give an vt100'er double width characters ... pss: all you UNIX'ers out there using Mail can do a ~|expand just before hitting ^D to end your message ... I did this for this message -- how does it look to you Multics'ers?
root@BU-CS.BU.EDU (Ra) (09/12/86)
To add my 2c: 1. I am not sure about the definition of "commonly used" but IBM Mainframes (EBCDIC) generally do not interpret tabs the way full-duplex systems use them (not that you can't simulate them, but it tends to be more variable in interpretation, if at all, software application dependant.) 2. Sending files through mail via heterogenous systems is fraught with peril although it usually works well enough if it's just text meant to be used as text (eg. a fortran program with embedded tabs may not compile at all when sent to an IBM system, I don't remember for sure, but I wouldn't be in the slightest bit shocked, and fixing it wouldn't take that much sophistication on the part of the user.) A solution is the UUENCODE/UUDECODE program distributed with UNIX (there are public domain versions) which encodes files in a very conservative way (more or less 026 character subset, 40 chars/line.) For example, I have a version of it running on our IBM mainframe and it seems to work, particularly for cases as above (yes, I expand tabs to every eight, perhaps that should be an option, but at least it's all at the user level rather than a decision made by the SMTP daemon.) Obviously with binary files there's not much you can do, but you could pass one THROUGH an incompatible system with little risk of problems using an encoding, hey, caveat usor.) In re SMTP, I would vote conservative, change nothing unless you have a good reason to (eg. ASCII->EBCDIC, there is an EBCDIC tab character.) It should be easy enough to provide software to do minor conversions once the the file has arrived (if it is intact, expanding tabs for example discards information which seems to violate some basic principle of design.) -Barry Shein, Boston University
Kevin_Crowston@XV.MIT.EDU (09/12/86)
Just to add to the confusion... My system (a Xerox Star) displays mail in a proportionally spaced font, making all diagrams hard to read without changing the font. I'm not sure if this is a bug or a feature, however. In general, I think that having the mailer expand the tabs would be a bad idea. There might be reasons for wanting the tabs in the message and it shouldn't be impossible to do this. The user mail agent might do that sort of processing by default, however. For example, if I try to send a message that includes font changes, etc. the mailer asks if I really want to send formatted text, and strips the formatting if I don't. Kevin Crowston MIT Sloan School of Management kevin@xv.mit.edu
PALLAS@SUSHI.STANFORD.EDU (Joseph I. Pallas) (09/13/86)
RFC821 says: The mail data may contain any of the 128 ASCII character codes. This clearly makes it illegal for SMTP mailers to expand tabs. On the other hand, RFC822 says: Writers of mail-sending (i.e., header-generating) programs should realize that there is no network-wide definition of the effect of ASCII HT (horizontal-tab) characters on the appear- ance of text at another network host; therefore, the use of tabs in message headers, though permitted, is discouraged. This clearly suggests that mail-agents expand tabs before submitting them to mailers. Meanwhile, if you use tabs in formatting such that the width of a tab stop affects the content of your message (e.g., in drawing pictures), other people will get what you deserve. joe -------
DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer) (09/16/86)
Tabs should be expanded at the source; not by any heuristic in some program that has no chance of guessing right. This is preferably the user's mail composition program, perhaps by a user profile switch, but it should not be done by the SMTP user side, or the SMTP sending side, or any other mail delivery program (SMTP isn't the only one that exists (surprise!!)). If the user's composition program doesn't have this feature, then the user should do the conversion if tabs are significant. You simply cannot send data from one place to the other unless you /know/ that both sides agree on how to interpret the characters. I believe the /only/ set of characters we all agree on are the 95 ascii characters space through tilde, plus NVT newline. I would have italicized /know/ but only other Lisp Machines would be able to see it without garbage characters...
Ata@RADC-MULTICS.ARPA ("John G. Ata") (09/16/86)
Yes, you are correct...when I said SMTP mailer, I meant the mail composition program that submits mail to the SMTP mailer. Sorry for the confusion. I strongly believe that mail composition programs, should for the most part, expand tabs to spaces unless overridden by another command or control argument. This is because, in the vast majority of cases, tabs are used to merely position the next character in a particular column, so that tab expanding is then the right thing to do given that there isn't a standard definition of tabstops over the network. Of course, for those cases where tabs mean something else, the user can override this, perhaps with a command/control argument. The bottom line is that, in most cases, tabs will be vastly reduced in SMTP message text. As a matter of record, the standard Multics mail system does not allow tabs at all whether local or network. Therefore, the mail program will expand tabs BEFORE submitting to the SMTP mailer, just like it will expand before submission into another local mailbox. Given that tab characters are not allowed in messages, the server SMTP does also expand tabs to maintain compatability with the rest of the mail system. John G. Ata