Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!apple!agate!ucbvax!hplabs!hp-ses!hp-ptp!toddp
From: toddp@hp-ptp.HP.COM (Todd_Poynor)
Newsgroups: comp.mail.misc
Subject: Re: Tab Expansion in E-mail
Message-ID: <1960004@hp-ptp.HP.COM>
Date: 7 Mar 90 05:09:47 GMT
References: <1960003@hp-ptp.HP.COM>
Organization: HP Pacific Technology Park - Sunnyvale, Ca.
Lines: 63

From: Craig_Everhart@transarc.com
  
>It seems a shame to burn (human) cycles on a minor problem when there
>are so many larger fish to fry.  I would refer the reader to RFC 1049
>for the description of a Content-Type: header in messages that reaches
>far beyond simple tab-stop specification.
  
RFC-1049 Content-Type syntax could indeed be used to specify tab
presentation, since the resource-ref allows a local-part to be given, which
in turn allows a quoted-string to be given.  I like this suggestion.  At
first I considered Content-Type inappropriate since it appeared to be
concerned only with "larger fish": the content-type identifiers mentioned in
the RFC are supposedly all that is needed to specify the desired appearance,
that is, the identifiers name standard formats for which the interpretation
should be clear.  The syntax is not really geared toward supplying a more
complex set of rules as required to interpret non-standardized "contents".
  
If the Content-Type field is to be used in this manner, then I suspect that
presentation software will need to handle more than one of these fields in a 
message header, such that one can specify the behavior of tabs within the
larger context of a document format, for example.  Failing this, we require
the screen appearance to be completely defined by a single
content-type/ver-num/resource-ref tuple, probably relegating the tab-stop
definition to an optional part of the resource-ref of a content-type named
"PLAIN-TEXT".  Perhaps this is sufficient for the tab-stop problem, but I
won't be surprised if instances arise where the contents of a message
require interpretation at both the text and overall organization levels.
  
And so on to the question of, "Are we analyzing to death a piddling little
detail when more important issues abound, like mailing POSTSCRIPT files?".
The final paragraph of my original posting anticipated such a viewpoint, and
I freely admit that the accusation has merit.  Part of my motivation to
discuss this problem was to see if concern over mismatched tab stops
would strike a responsive chord in the USENET community.  Such a reaction
is lacking thus far.  The issue is far closer to my heart than those
specifically tackled in RFC 1094 since I work on a computer where tab stops
are entirely a matter of user preference, and deal with the e-mail problem
regularly.  The issue has been brought up a number of times by various people
on Hewlett-Packard's private newsgroups due to the common use here of
systems to which the tab character is almost completely foreign.  I can hardly
believe such a situation is all that rare.  Does anyone else believe this
problem is worth discussing?
  
  
From: Makey@Logicon.COM (Jeff Makey)
  
>People (not autonomous programs acting on behalf of people!) could
>convert tabs to the appropriate number of spaces before they send
>their mail.
  
Not all users of mail systems are aware of the problem, and few of those who
are aware are diligent about either avoiding the tab key or performing such
a conversion.  The basenote mentioned this.  If relying on the user community
never to use tabs is the most feasible solution then many people must learn
to break a deeply ingrained habit.  I do agree, of course, that simple
abstinence is quite a clean solution from a technical standpoint, if not
from a behavioristic one.  The bulk of this discussion has been concerned
with doing the right thing if, alas, a tab character makes it through.
If complete avoidance is desired then the next step is to decide how best
to educate users of the problem, and how to encourage or enforce this
avoidance.
  
^todd