I think I have a first pass at a solution to Wazoo protocol standardization¨
that solves all of our problems:

1. No or trivial change to existing programs
2. Existing programs will not become obsolete
3. No or little impact on new designs.

Also there is a simple way to choose amongst the many protocols potentially¨
available with this scheme. The bit definitions below are arbitrary, I just¨
chose them for my convenience in this document:

Y_DIETIFNA	0000 0000 0000 0001	XMODEM w/ TELINK block
Y_SEALINK	0000 0000 0000 0100	base-level SEALINK
ZED_ZAPPER	0000 0000 0000 1000	ZMODEM/8K blocks
DOES_IANUS	0000 0000 0001 0000
Y_ZMODEM	0000 0000 0010 0000	Forsberg ZMODEM
Y_SEA_OVD	0000 0000 0100 0000	SEALINK Overdrive

Change #1: Define DIETIFNA as XMODEM-with-a-TELINK-block, not as SEALINK.

Change #2: Make this bit MANDATORY for Wazoo compatibility.

This is the biggest change I'm proposing. Please bear with me -- this¨
enhances SEALINK not minimize it. It allows choosing SEALINK OVERDRIVE if¨
both systems support it (instead of only finding that out when you get the¨
bit set in the SEALINK block 0). It allows DIETIFNA/ZMODEM systems to¨
choose ZMODEM in that case.

These bits aren't PROTOCOLS, they are CAPABILITIES; what protocol module¨
you invoke in your program is another issue, as will become clear later.

Y_DIETIFNA: Defined as Telink-without-the-Modem7-filename, ie. the stuff in¨
FSC006. Xmodem-with-the-Telink-block. Since you need to have XMODEM to do¨
FSC001, this shouldn't be a problem.

Y_SEALINK: Defined separately because SEALINK does things above and beyond¨
DIETIFNA -- file update, file restart, etc. Upward compatible with SEALINK¨
OVERDRIVE.

Y_SEA_OVD: Full streaming SEALINK. 

ZED_ZAPPER: No change.

Y_ZMODEM: Simply Forsberg's "standard" Zmodem, ie. block size never goes¨
over 1024 bytes. Though it's not exactly "standard" because of the need to¨
be able to do a null session.

CHOOSING A PROTOCOL AT CONNECT TIME:

Here's where the separate DIETIFNA/SEALINK/SEALINK OVERDRIVE bits come in.¨
The procedure is, the calling node sends its Hello packet, which contains¨
the bits that say what it is capable of; the receiver responds with its own¨
Hello packet, which specifies which protocol will be used that session (and¨
it was here that the trouble happens if there is no protocol in common.) 

The idea is that the receiver should choose one protocol amongst the many.

If both our systems do DIETIFNA and ZEDZAP, the obvious choice is ZEDZAP¨
(assuming good performance is desired.) If mine does the above, but yours¨
DIETIFNA, SEALINK, SEALINK OVERDRIVE, then we have no choice but to choose¨
DIETIFNA. 

The actual protocol choice, done by the receiver, is by ANDing with a bit¨
mask that contains the protocols your program does, then choosing one of¨
the remaining bit(s) according to a method chosen by the programmer or¨
sysop. 

You could then also have a sensible way to refuse a connection -- say you¨
have a zillion byte file to send, and the receiver can only do DIETIFNA.

For example, a program that does SEALINK and it's variants will mask¨
incoming bits with (Y_DIETIFNA | Y_SEALINK | Y_SEA_OVD); my Fido/FidoNet¨
program would use (Y_DIETIFNA | Y_SEALINK | ZEDZAPPER | Y_ZMODEM). Then, in¨
my particular program, I would choose the left-most bit remaining and set¨
that in the returned Hello packet. Other programs could use other methods,¨
either an install-time option (ie. I want SEALINK over ZMODEM) or some¨
other criteria. (Fido doesn't do SEALINK yet but it will "soon".)

EXISTING PROGRAMS:

There is no impact in all four combinations of "new" vs. "old" programs --¨
if "new" programs simply tolerate more than one bit set when they receive¨
the (edited) Hello packet back from the receiver. For example, you could¨
get back both ZEDZAP and DIETIFNA bits set. Which bit you'd choose depends¨
on what protocols your program supports. For Fido, the choice would clearly¨
be ZEDZAP, as Fido doesn't support SEALINK OVERDRIVE. For SEADOG, the¨
choices would be reversed.

So this would be Change #3, if so desired. I think I read that Bink now¨
does this. I am going to make Fido do this also -- have the response Hello¨
packet contain only the protocol bit that will be used.

IMPORTANT (NOT SO) SUBTLETY:

Most implementations that do the xmodem variants do it all with one "smart"¨
module -- therefore most of this protocol switching doesn't really exist --¨
DIETIFNA, TELINK, SEALINK and SEALINK OVERDRIVE probably mean the same¨
module. For programs that do this, all that need be done is set the¨
capability bits and go.

Here are some sample scenarios for you.

Scenario #1: My Fido calls your Binkley. (Existing programs.) My hello¨
packet says DIETIFNA, ZEDZAP. Bink replies with DIETIFNA, ZEDZAP. Both¨
choose ZEDZAP.

Scenario #2: My Fido calls your Tabby. Tabby responds with DIETIFNA. We do¨
DIETIFNA.

Scenario #3: ProgramX calls a Binkley; it does DIETIFNA, SEALINK and¨
ZEDZAP. Existing Bink doesn't recognize SEALINK (bit set) so chooses¨
ZEDZAP. 

Scenario #4: "New" Binkley calls SEADOG. Bink does DIETIFNA, SEALINK,¨
SEALINK OVERDRIVE, ZEDZAP. SEADOG chooses SEALINK OVERDRIVE.

Scenario #5: "Old" SEADOG calls Binkley. DIETIFNA is the only bit set, and¨
so is chosen. In real life SEALINK, then SEALINK OVERDRIVE is used.

Scenario #6: "New" Binkley calls "new" Fido. Bink does ZEDZAP, SEALINK¨
OVERDRIVE, SEALINK, DIETIFNA. Fido does ZMODEM, ZEDZAP, SEALINK, DIETIFNA.¨
ZEDZAP is chosen.

---------- ON A DIFFERENT BUT RELATED SUBJECT: 

Though "more bits" is never a long-term solution (witness .MSG file¨
attribute bits...) more at least helps the short-term. Therefore: in the¨
definition of struct _Hello, in YOOHOO.DOC, make 'capabilities' a LONG, by¨
shortening 'reserved[12]' to 'reserved[10]'. They are not needed now -- and¨
by definition existing programs do not use any "features" specified by¨
those bits in the future. Hence it's fully compatible, backwards and¨
forwards.

