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.