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. Atajordan@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