Re: Recipient is offline
2011-09-03 02:39:09
John C Klensin wrote:
A very significant and important improvement, IMO. Presumably,
if a telephone# still appears and is supported at both ends, it
continues to work.
It was from the standpoint it allowed Fidonet mailers to get away from
the FTN1 protocol (XMODEM, no error correction) constraints not
working under X.25 and TCP and use instead its more modern WAZOO
(Yoohoo / Yoohoo2) text based handshaking protocol to negotiate
capabilities, authentication with matching network addresses, and
selection of the data transfer protocol, ZMODEM was the default
designed specifically for X.25.
You might this reading interesting by Chuck Forberg of the early comm
issues, including UUCP, leading up to his development of ZMODEM:
http://www.omen.com/zmdmev.html
I recall really easily liking SMTP because it reminded me of
flexibility WAZOO provided and how much more power and flexibility
RFC822/821 had to offer.
SMTP (821/822) just simplified things:
- Design complexity for Queuing/Schedule reduce, less used and
even removed.
- Dynamic Delivery/Receiving benefits were immediate.
- Remove the need for error-correction protocols. TCP did that for us.
- RFC822 headers resolved major issues with Kludge lines (network
control lines) in the Fidonet mail format,
- RFC822 text base format allowed for expansion and growth,
- RFC821 was flexible, you can easily add more command line
mode commands,
and it was an added bonus the Internet had no "rules" unlike the FTSC
restrictions where non-compliancy got you (developer and operators)
off the Fidonet NodeList. :)
Why Dialup?
# 1, its one way to win a fast entry contract with the feds as
# the exception to HIPAA secured internet transfer requirements.
That application had not occurred to me. I find it fascinating
as well as worthwhile. The other two examples surprise me less.
I only mentioned this one because almost all the insurance companies,
providers, subcontractors and clearing houses do this. But would you
believe the CIA, FBI, DOD, DOE, State, Local law enforcement, many
Fire Departments, payroll, banks, many with end of day activities,
inventories (i.e. hand scanners), etc, that continue to use dialup to
avoid any security issues and/or cost?
But for many, its the demand of their clients. So even if network
security isn't the reason and secured internet portals are available,
many of their clients (any size) simply won't tolerate or budge on
having to increase their communication cost or, a biggy, have to
develop software or pay for an administrator, especially if its not a
24x7 need. Not many service providers will do this unless they have
special client software or offset the cost some how, so they just say
"Here are phone numbers, secured ftp, smtp, http addresses and you
choose how you want send/pickup stuff."
Anyway, I will note, and maybe that is what I am stuck with John, in
my view, the paradigm and of course, with variations, the model has
never really changed from:
CONNECT
SEND, IF ANYTHING
PICKUP, IF ANYTHING
DISCONNECT
What is a large part for us is:
CONNECT
PICKUP OUTPUT, if ANY
SEND --> BACKEND PROCESS --> OUTPUT
DISCONNECT
How client do the above was up to them. One Sessions, Two Sessions,
etc. FTP keeps that as one. SMTP/POP3 split it that into two. HTTP,
I guess from different POVs, one or two sessions. HTTP WebSockets
will make that one!
--
HLS
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: Recipient is offline, (continued)
- Re: Recipient is offline, John C Klensin
- Re: Recipient is offline, Tony Finch
- Re: Recipient is offline, John C Klensin
- Re: Recipient is offline, John Levine
- Re: Recipient is offline, Carl S. Gutekunst
- Re: Recipient is offline, Keith Moore
- RE: Recipient is offline, Murray S. Kucherawy
- RE: Recipient is offline, John C Klensin
- Re: Recipient is offline, Hector Santos
- Re: Recipient is offline, John C Klensin
- Re: Recipient is offline,
Hector <=
- Re: Recipient is offline, John C Klensin
- Re: Recipient is offline, Hector
- Re: Recipient is offline, Robert A. Rosenberg
- Re: Recipient is offline, Tony Finch
- Re: Recipient is offline, Dave CROCKER
- Re: Recipient is offline, Tony Finch
- Re: Recipient is offline, Dave CROCKER
- Re: Recipient is offline, John Levine
- Re: Recipient is offline, Tony Finch
- Re: Recipient is offline, Hector Santos
|
|
|