


Western TLCF Link Protocol V2.00
       by William Bell
(c) 1993 All Rights Reserved




Private Whispers:

    PVT:<BBSNAME_FROM>:<USER_FROM>:<USER_TO> <TEXT>
          - might want to add channel for reply ONLY

    ACKPVT:<BBSNAME_TO>:<USER_TO>:<TEXT>

Action like .hug:

    ACTION:<CHANNEL>:<BBSNAME_FROM>:<USER_FROM>:<USER_CHECK>:<ACTION>
         If cannot find the user_to locally.

    REPACK:<CHANNEL>:<BBSNAME_TO>:<USER_CHECK>:<USERNAME AT BBS>:<ACTION>
         Reply acknowlegdement for action commands to check name
         so a .hug will check the username. Sends back to bbs.
         When received displayed msg.

The .post:

    POST:<USER_FROM>:<MSG>

The .netwho:

    NETWHO:<USER_FROM>:<BBS_NAME | ALL>

    PVT2:<BBSNAME_FROM>:<USER_FROM>:<USER_TO>:<TEXT>
        This one does not reply with ACK.

User enters TLCF Channel:

    JOIN:<CHANNEL#>:<BBSNAME_FROM>:<USER_FROM>

User leaves TLCF Channel:

    LEVE:<CHANNEL#>:<BBSNAME_FROM>:<USER_FROM>

User types regular message in Channel 1000-1099:

    XMSGX:<CHANNEL#>:<TEXT>

THe .netpage:

    NETPAGE:<BBSNAME_FROM>:<USER_FROM>:<USER_TO> <TEXT>

    ACKPVT:<BBSNAME_TO>:<USER_TO>:<TEXT>

When BBS Links:

    HELLO:<BBS_NAME>

    PVT3:<BBSNAME_TO>:<BBSNAME_FROM>:<CHANNEL>:<USER_NAME>
        Not working yet


------------------

  Future Spec for CRC-16, Western TLCF only. Maybe V3.0??
  <142><142><142><142><150><NUM><HI#bytes><LO#bytes>JOIN:<CHANNEL#>:<BBSNAME_FROM>:<USER_FROM><CR><CRC-16HI><CRC-16LO>

  The reason for the four <142> is that Western will start looping when it
  see's <142> and when next digit is non-142 then it will stop looping. In
  theory only one <142> is needed on a clean line. I just want to
  make sure a <142> is received on bad lines too.
  The <NUM> number is a 'unique' number from last 'hop' on link. Number of bytes
  signifies where is the block is supposed to end. CRC-16 is calculated,
  if ok then good. Otherwise if CRC is wrong then request <NUM> from system
  again. This also happens if a <142> is received before number of bytes
  are used up. The <142> means start another block.  Last system
  can resend up to 3 blocks backward.

  For failure ONLY:  (keep these in a counter)

  <142><142><142><142><150><NUM>FIX:<NUM><CR>

  No fixes to failures.

  Couple flaws here. On real bad lines <NUM> will be screwed up and
  requesting <NUM> would mean nothing.  What happens when the fix
  is screwed up? SHould I send another fix? When should I stop requesting
  fixes - what if I am requesting wrong number??  The numbers will be
  consecutive so we should know what to expect. This solves the most
  blatant flaw. Notice that no ACK/NAK are sent! Works similar to ZMODEM.

