-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, 1 Apr 1999 18:22:47 +1000, Hamish Moffatt wrote:
>On Tue, Mar 30, 1999 at 08:45:09PM -0800, Steve Lamb wrote:
>> This is the proper thing to do since it then lets the other end decide
>> not only *IF* they want the file, but *when* then want the file.
>If the sending user is on a dialup connection, how on earth can this work?
>Think about it.
Your homework assignment, should you choose to accept it, Hamish, is
this. To figure out ways for people on dial-up connections to allow people
to download files from an embedded URL. Your tools are the following:
A local FTP client so the person can upload the file to one of the following
An ISP/company/orignization run HTTP server.
An ISP/company/originzation run FTP server.
*Steve plays dramatic music and waits for Hamish to get a clue.*
*Several hours later he gives up and stops the tape.*
You see, Hamish, if a person can send out email they can also, 99% of
the time, place any large files on an anonymous FTP server or on a web site
somewhere so the embedded URL will work. This works with all corporations
that I am aware of, most government sites, nearly all ISP and even for
people, such as myself, who operate their own, albiet small connection. For
the "select" few who are on networks managed by brain-dead IT people (read:
NT advocates) who would not provide such services... TOUGH. That is a
problem with their IT department and not something that the rest of the
world should allow a Denial of Service attack.
Before people should complain that they shouldn't have to do that they
are WRONG. 100%, totally and utterly WRONG. FTP, which stands for *F*ile
*T*ransfer *P*rotocol was designed, oddly enough, with the transfering of
files in mind. It is a technology which is, IIRC, *older* than POP3, SMTP
and IMAP4rev2, the current crop of mail protocols as well as HTTP in any
incarnation. People should learn and use the appropriate protocols as well
as the standards and conventions surrounding them. One of which is the
embedded HTTP defiled URL inside an email message sent and received by a
combonation of SMTP and POP3/IMAP4rev2 to direct them to a proper FTP
location.
The standards have adapted so people don't even need to know how to open
an FTP client to retrieve the file. I think that is far enough, thank you,
considering the alternative is *STILL* considered a Denial of Service, can
still *BE* a DoS and is *NOT* supported by the standards of the day. That
would be, uhm, RFC821 IIRC which says that only 64k is supported by the mail
protocols. Anything beyond that is NOT. It isn't forbidden as I had
previously mistakenly thought, but it is NOT supported.
For internal corporate use, the sharing of files was, again, built into
the systems of yesteryear. That would be what *GROUPS* are for on the
system we all know and love, Unix. It is so a GROUP of people would have
access to read and or change files so that said GROUP of people could
cooperate on a project.
It is because these people have not taken the MINIMAL time it takes to
understand the standards, procedures, conventions and TECHNOLOGY given to
them do they demand that the few that they have a minimialistic understand
of be pervereted and DESTOYED for their use.
And you.... defend that?
So, uh, Hamish, without being to provocotive for you... How, EXACTLY,
would you take it to some upstart developer *demanding* changes in the way
Debian does things even though there are clear procedures, conventions and
techology to allow him to do exactly what he wants if he only took the time
to learn it?
I'll let the archives bear my leading question to its conclusion. For
you have taken the same defensive stance I take now on the whole issue of
files through email in several discussions with me about Debian procedures
and policy. Not to be too provocotive, mind you.
Oh, and, yeah, upon hindsight, I was wrong on most of those. But hope
this provides a little food for thought for you.
- --
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
ICQ: 5107343 | main connection to the switchboard of souls.
- -------------------------------+---------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.0 (C) 1997 Pretty Good Privacy, Inc
iQA/AwUBNwMxMHpf7K2LbpnFEQKANQCg6uLL6m881yWFpRN4y6dIyAKsUgYAn1KG
JHztm3ZC+OOUGWwMCR6a9KA7
=zVNR
-----END PGP SIGNATURE-----
