[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Lessons Learned from a Foreign Culture
I don't know how people on this list perceive me.
At Rice they sometimes think of me as "a mainframe guy" even though
I've been supporting UNIX (and it's all-or-nothing at this shop)
for a long time. But I used to support Rice's VM system. I'm not
a mainframe guy; I'm not a UNIX guy; I'm a multi-platform guy.
Always have been; always will be.
So when I finally learned TCP/IP ... wow! Such a wonderful
open door of opportunity! Previously, the only networking we had on
academic VM systems was BITNET. Now BITNET is fine and good for what
it offers, but it's not as flexible as IP. Most of the services I've
encountered on IP are quite platform independent. I haven't run
statitics, but I think it's a corollary: the more popular services
are those which are most free local platform specifics. We've been
kicking files around with FTP for a long long time. This is great!
Say you've got something on your VAX and you need it on your Pr1me:
no problem. Just FTP it.
Then came MIME. If TCP/IP was good, MIME was better.
Notice that we no longer refer to Content-Type values as MIME types;
they're now media types, because everyone is embracing the beauty of MIME.
And MIME goes beyond even just the SMTP/IP world. Hmmm... MIME gets
gatewayed back into things like BITNET. Cool!
Here's where I'm trying to sell you: there are two main things
that go across the TCP wire, binary and plain text. Plain text is
sometimes referred to as ASCII, though on an EBCDIC system like VM
(or MVS, or VSE) that's a lie. But we live with that lie because it's
too much trouble to explain the difference to the users. There's no
reason why CMS (the main thing on VM) can't process ASCII, in fact,
it happens all the time, but it's most efficient if we can translate
the ASCII (CR/LF) into EBCDIC ("lines" delimited out of band).
On Thu, 27 Oct 1994, Jim Conklin wrote:
> At 11:51 AM 10/26/94 -0400, Steve Dorner wrote:
> > And so the final option is to turn off
> >word wrap, turn off quoted-printable, and trust to luck that the long lines
> >will make it.
> As one of those customers, after I finally discovered that this was the
> way to send RTF to folks who couldn't get it as a MIME attachment (or by
> ftp...), I must agree that it's been useful.
This is a real problem for me. If you had labled it text/plain
then I could handle it on CMS w/o going through hoops. Remember, we're
trying to make life simple for the users; I'm a systems programmer.
If I get an RTF file in "binary" form I'll just FTP it in binary or
otherwise convert it. But what are my users to do? They're going to
call me on the phone at 2AM (probably page me, actually) crying about
this corrupted RTF when they've got an assignment due by 8.
Don't send RTF as binary. It's plain text. It may have long
lines, but it's still plain text. If the problem is line truncation,
I would think that CT text/plain and CTE base64 should fly. No?
I think I should explain what happens on VM (CMS) with the
various CTE's too. Three work: <none>, Base64, Quoted-Printable.
Note that <none> does not mean binary, it means "assume that this
was ASCII plain text and it's now EBCDIC plain text". There's no room
for "CTE binary" at all. It just won't fly. The SMTP server will
have translated what-it-thinks-is ASCII plain text (basically NVT,
but loose on the CR/LF -vs- LF alone point) into EBCDIC plain text.
Trailing blanks might have been (probably were) dropped; TABs might have
been expanded; CR/LF or LF were all translated into an out-of-band EOR.
CTs text/plain, text/enriched, and as far as I can tell text/*,
all work fine with CTE <none>. A lot of application CTs work with
CTE <none> too: application/postscript, /x-tcl, /x-tex, all work.
Other application CTs DON'T work with CTE <none>, such as /zip
or /x-dvi. These need CTE q-p or (better) Base64. This is all
intuitively obvious. Now if you happen to send CT text/plain to me
with CTE base64, I'll be able to see it after an extra conversion,
but I'd prefer if you just send CT text/plain without any CTE.
Image/gif, audio/basic, and a number of application/whatevers
will have to be in base64. (avoid q-p)
But remember that even q-p and base64 have plain text
characteristics. I'm record oriented. (and I'm not alone)
If you leave off that last CR/LF, then I'll see the boundary
(if any) as part of the base64 object. (quoted-printable is
just plain weird when it comes through a gateway; there's no telling
about that line-end; and it's not just EBCDIC gateways that munge it)
And "stamp out content-length headers in our lifetime".
Is this making sense? I'm communicationally dysfunctional.
I'm sure I've left out an important point, something missing that would
help the light turn on for some of you.
Rick Troth <firstname.lastname@example.org>, Rice University, Information Systems
"People respond, then they fall away. Just want your help for a day"
-- Bob and Jayne