🚀 go-pugleaf

 KP> Thanks for writing. If you're having trouble sending a
 KP> binary file over the Internet, your file probably has some
 KP> non-printing characters in it. Internet mail only transfers
 KP> standard ASCII characters, so it encodes the file if it
 KP> discovers special control characters, characters with
 KP> accents on them, special symbols like line-drawing
 KP> characters or paragraph marks, or if line noise has
 KP> corrupted the file during transfer. This will cause the file
 KP> to appear corrupted, or make it impossible for you to open
 KP> the file at all.
 KP>
 KP> The best way to solve this problem is to get Base64 encoding
 KP> and decoding programs like uuencode and uudecode. When you
 KP> pass the file through such a program, it automatically
 KP> translates it to and from ASCII. If you and your friend both
 KP> have these programs, you should be able to exchange binary
 KP> files without problems. Check the Internet SIG for more
 KP> information and to download encoders and decoders.

I _understand_ all of that.  Really I do.

We're talking about FTP, not mail.

Your GET/MGET BINARY MODE _DOES_ WORK -- why can't your company make
BINARY MODE for PUT/MPUT work the very same way?  This question was not
answered -- you side-stepped it by saying to uuencode my binaries, and I
already told you I had to do that to get around Delphi's software
problems.

IN A NUTSHELL, ONE MORE TIME:

The problem exists with Delphi's FTP software in BINARY MODE.  Delphi's
BINARY MODE for its PUT/MPUT command is *not* Internet standard.  That
problem is in Delphi's software for PUT/MPUT only; GET/MGET in binary
mode WORKS.

If Delphi intends _not_ to support Internet's BINARY MODE FTP protocol,
then remove it from your command line options because it is totally
misleading and bogus.  'PUT /IMAGE' is a BOGUS OPTION -- it should be an
INVALID OPTION.  Change the Help text to say users must use an encoding
utility supported by the _receiving_ end and to send it in 100% ASCII
mode.  This includes the UPLOADING part from a home computer _to_ the
user's private storage area on Delphi, and to use FTP ASCII MODE 'PUT'.

As of that weekend when I wrote you originally, none of this was
described _anywhere_.

We also think Delphi's software has a bug in the MPUT command, too.  I
can testify that I *was* in ASCII mode when I went to reFTP those files
in uuencoded fashion to Cabrales.  I used MPUT in ASCII mode to do this
in a quick & efficient manner.  Guess what?  The copies on the other end
turned up to be in the _same_ BINARY MODE that we saw earlier.  These
files were uploaded to my private storage in ASCII MODE (via ZModem).
These files were specified to be MPUT'd in ASCII mode.  These files turned
out being copied in Delphi's non-standard binary protocol.  When these
same files were sent one-at-a-time with PUT in ASCII MODE, everything
looked good on the other end.

Delphi has TWO PROBLEMS:  (1) Get rid of your binary mode option for
PUT/MPUT if you do not intend to support the Internet FTP standards (e.g.
auto-uuencode etc.), and change your Help texts to document what we
_must_ do e.g. uuencode the file ourselves etc.  (2) Fix the MPUT ASCII
MODE so it won't send files in Delphi's BINARY MODE.

Delphi has a THIRD OLD PROBLEM I documented 2 years ago: the word-wrap
bug (see below).

 KP> Unfortunately, there is no way to increase the 10MB limit.
 KP> There is a limit of 10mb on file transfers over the Internet
 KP> to DELPHI, which isn't related to the allotted storage space
 KP> in your Workspace. The primary intent of the 10MB allocation
 KP> is to prevent abuse of our Internet connection, and it
 KP> applies to all Internet traffic: e-mail in, e-mail out, ftp
 KP> "gets", ftp "puts", and telnet sessions.

When I got Chris Strunk's CS-TeX 4.0 package, that added up to probably
one-third of my monthly Internet i/o (or "keystroke") account, all in one
sitting.  When one or two files didn't come across cleanly, that added
more.  When I needed extra fonts & files etc., that added even more.
Some of us on the Info-TeX list currently are trying to figure out why a
font or two isn't looking very good at 180dpi.  I decided to download
the entire MF directory at SHSU and to join two more TeX lists to try
getting answers.  That adds _more_ to my i/o account.

(At _no_ time did my "disk allocation" even get close to reaching 10Mb.
Yet I'm being charged _more_ when I go past Delphi's INTERNET
"KEYSTROKE" i/o limit.  This month's bill is a prime example.)

All this i/o I had to do -- that is not "abuse".  That's trying to find
out what's going on with the software, and whether Internet/Delphi had
any line noise problems etc. (gladly it wasn't line noise, so I didn't
bother to send y'all a message about this).

It's also not "abuse" to be on a _few_ (a handful of) netlists to get
news & discuss things.  I want to capture/download the msgs and respond
off-line with a much fancier text editor than you have, to spell-check
things and try to make it as professional as possible.  (I don't
like/use your UseNet facilities for this very reason.  Besides, your
UseNet "selections" are sadly lacking the subjects & discussions I wish
to join.  Censorship?)

We cannot seem to be able to remove the "routing headers" in Internet
e-mail.  'EXTRACT /NOHEADER' removes the 'To:/From:' information -- not
the "routing headers".  The listservers don't have ways to remove this,
either.  I went & got REFCARDs and all kinds of info to try figuring out
how to do this, to no avail (which, again, increased my montly i/o
totals).

All of this adds up, Delphi.  Paying for high monthly i/o is almost as
if you don't want us to use your Internet connections.  I cannot strip
down those headers, so you're "billing" them to us.  I must always use
uuencode for binary files, adding 25% to the size of EACH of those
files, and if that's what your company requires (rather than making
BINARY MODE for PUT/MPUT work the same as your binary mode for GET/MGET
does work), then you are forcing us to "pay" that extra 25%.  Whether or
not I actually read my listserver mail, I'm being "charged" for it, mostly
because your UseNet selections don't have what I want.

 KP> Now, we realize
 KP> that you really don't have the tools you need to measure
 KP> your total transfer levels. Frankly, we don't either; we get
 KP> several usage reports that we can piece together to track
 KP> composite usage. There are only a few people who have ever
 KP> gone over this allocation. In those cases, we've sent them a
 KP> note asking them to reduce their use; to date we haven't
 KP> charged anyone for exceeding the limit.

I see the "allocation" you describe is for the Delphi private storage on
disk.  I just want to make it clear that the limit I'm talking about
above is strictly related to the i/o traffic thru Internet.  I _am_
being billed extra for _that_ (on top of the $3/month for Internet
access and $20/20 basic access plan).

You _must_ provide these tools if we are ever to try controlling useage
on _our_ end.

The fact that you say even Delphi doesn't have proper tools makes me
wonder just how _accurate_ my bill really is.

One of your highest priorities must be to develop & provide these
tools.  And to fix the problems.

 KP> If you use the gopher utilities to do transfers at our
 KP> standard connect speeds, you will almost certainly stay
 KP> below the limit and off of our "radar screens." They
 KP> eliminate the need to first "get" a file to your Workspace
 KP> before downloading it, so you won't risk forgetting about a
 KP> file in your Workspace and incurring storage charges for
 KP> it.

Problem with Gopher is that it's not "at" everywhere and doesn't "go"
everywhere.

I'm a system programmer for our state's D.O.T.  We've just begun to hook
up to the Internet.  I can see the same disk space and i/o traffic
problems are going to happen, believe me.

But like any honest government (state) employee, I'm going to use my
personal private Delphi account to do _my own_ projects etc.  (I'm
_sure_ there's going to be abuse from users of our D.O.T. mainframe.)

Regardless of what I'm doing, if I need a file somewhere, I'm going to
use FTP, not Gopher -- because I want to "see what I'm doing", see?
(That's also why I don't use/like WYSIWYG products, too.)

 KP> We will also be happy to credit your account for the
 KP> problems you experienced.

I appreciate that.  Judging from the bill I just got ($34+), it seems
y'all didn't do it in time for this billing period.   :)

 KP> Please let us know if you have other questions.

To wrap things up:

When is the word-wrap problem going to be fixed?  I documented this over
2 years ago.  I'm not satisfied with the answers I got (e.g. how to
adjust my "terminal width" etc.)  NO MATTER TO _WHAT_ VALUE MY TERMINAL
WIDTH IS SET, THERE ARE WORDS THAT 'HIT' THAT MARGIN JUST THE RIGHT WAY
TO CAUSE THE WORD TO BE SPLIT.  DELPHI HAS A BUG HERE.

Delphi also has problems splitting words at the oddest imbedded characters
-- after a '$', after a '/', after a '_', etc.

I'VE BEEN WAITING OVER TWO YEARS FOR THESE TO BE FIXED.

I expect Delphi to remove the FTP BINARY MODE option on PUT/MPUT before
other people have similar problems.  And to correct the Help texts to
specifically say what to do when sending binary files.

I also expect Delphi to fix the FTP MPUT problem when in ASCII mode -- it
actually sends all the files in your peculiar binary mode.

-- thx, Paul Seniura.