    Document: FSC-0048
    Version:  002
    Date:     21-Oct-90

                       A Proposed Type-2 Packet Extension
                                  Jan Vroonhof
                               2:281/1.12@fidonet
                                  Oct 21, 1990

         Status of this document
         =======================

         This  FSC  suggests  a proposed  protocol  for  the  FidoNet(r)
         community,   and   requests  discussion  and  suggestions   for
         improvements. Distribution of this document is unlimited.

         Fido and FidoNet are registered marks of Tom Jennings and  Fido
         Software.

         Purpose
         =======

         The  final  goal of this document is to become  a  widely  used
         standardised  extension to FTS-0001,  like FTS-0006,  0007  and
         0008  are,  and  provide  an elegant way to  switch  to  a  new
         bundling  method  without requiring major  effort  or  breaking
         anything.

         Prologue
         ========

         The  main  thing  that needs stressing is  that  the  additions
         covered  by this document are FULLY (I repeat FULLY)  BACKWARDS
         COMPATIBLE  with  FTS-0001 (and other  existing  standards  and
         practices  in  FidoNet and WhatEverOtherNets that I  know  of).
         When I say "backwards compatible" I mean that problems it would
         create  already  exist  in the current  FTS-0001  system  (e.g.
         zone  conflicts when dealing with a non compliant  system).  In
         short   it  only  corrects  some  flaws  in  FTS-0001   WITHOUT
         generating new ones.

         In  this document I have tried to stay as much as  possible  on
         the   paths   of  existing   practices.   Therefore   I   think
         implementation  of  the additions it proposes will not  be  too
         hard.

    !    Prologue to revision 2
    !    ======================

    !    Revision   2   of  this  document  reserves  a   bit   in   the
    !    CapabilityWord  for one bundle type already in use  outside  of
    !    FidoNet,  RFC-822.  A small change was made to the  "receiving"
    !    flowchart  in order to ensure compatibility with  FSC-0039.004.
    !    In  the process a lot of errors and omissions in the  spelling,
    !    credits etc. were corrected.

         ===============

    !    All  references in the following to FSC-0039 are to Revision  1
    !    of that document.

         My thoughts on FSC-0039 and FTS-0001 rev 12
         ===========================================

         First,  revision  12  of FTS-0001 introduced  the  term  "(some
         impls)"  to indicate that some implementations used  their  own
    !    extensions  to FTS-0001 (Note that in later revisions this  was
    !    changed to "optional"). The problem is that this info cannot be
         relied upon,  because there is no way to actually validate  the
         data. One can only check whether the values of these fields are
         in the range of valid values and hope for the best.

         Second,  FSC-0039  introduced  the idea of  having  a  bitfield
         (called the Capability Word) indicating whether extension  data
         was  valid.  Through  the  Capability Word,  it  also  made  it
         possible to indicate the ability to support other,  non type 2,
         packets,  thus allowing for flexible migration towards type  3.
         It  also documented the addressing extensions used  by  various
         programs.

         However, FSC-0039 has two flaws:

         1. One  cannot  be  sure the bitfield  is  zero  because  other
            implementations might use this field for their own purposes.
            Therefore  this document includes a second  validation  copy
            for the Capability Word (CW hereafter). This copy allows the
            FSC-xxxx compliant software to validate the CW by  comparing
            the two.  The chance of some junk portraying itself as a  CW
            is significantly reduced by this.

    !       Please  note  that  the  validation  copy  is  byte  swapped
    !       compared to the normal capability word.  While this  started
    !       out  as a typo,  I decided to leave it in as  it  introduces
    !       some extra safety, without requiring much extra code effort.
    !       In later revisions of FSC-0039,  Mark adopted this idea of a
    !       validation copy too and eliminated the problem.

         2. Although  FSC-0039 provides a way to make packet headers  4D
            it  is not backwards compatible.  It cannot be used in  FTS-
            0001 sessions to unknown systems,  making FidoNet still  not
            totally 4D capable.  Although it implements fields for  zone
            and point number,  an FTS-0001 compliant application is  not
            required to look at these fields.  When a point mails  using
            these  fields  to implement its 4D address,  a  system  only
            looking  at the net/node info,  as is required by  FTS-0001,
            still sees it as a boss node, causing the obvious problems.

            This document provides a way for transparent point handling,
            using   a  technique  already  exploited  by  many   mailers
            internally.  It  will allow this document to be  implemented
            and used by mailers not supporting it.  At the same time the
            danger that a point is seen as the boss node is eliminated.

            It does NOT provide full inter-zone backwards compatibility,
            but that is not needed as badly, as problems are not yet too
            great.  Any  measures to ensure backwards  compatibility  in
            this  area  might  harm  communication  with  non-supporting
            programs, when the old system could handle the situation.

         Packet Header
         =============

         The "|" character is used to indicate extensions documented  in
         FTS-0001  revision  12,   the  ":"  character  indicates  those
         documented here and in FSC-0039.

           Offset
          dec hex
                  .-----------------------------------------------------.
            0   0 | origNode     (low order) | origNode    (high order) |
                  +--------------------------+--------------------------+
            2   2 | destNode     (low order) | destNode    (high order) |
                  +--------------------------+--------------------------+
            4   4 | year         (low order) | year        (high order) |
                  +--------------------------+--------------------------+
            6   6 | month        (low order) | month       (high order) |
                  +--------------------------+--------------------------+
            8   8 | day          (low order) | day         (high order) |
                  +--------------------------+--------------------------+
           10   A | hour         (low order) | hour        (high order) |
                  +--------------------------+--------------------------+
           12   C | minute       (low order) | minute      (high order) |
                  +--------------------------+--------------------------+
           14   E | second       (low order) | second      (high order) |
                  +--------------------------+--------------------------+
           16  10 | baud         (low order) | baud        (high order) |
                  +--------------------------+--------------------------+
           18  12 |      0      |      2     |      0      |      0     |
                  +--------------------------+--------------------------+
           20  14 | origNet      (low order) | origNet     (high order) |
    :             |               Set to -1 if from point               |
                  +--------------------------+--------------------------+
           22  16 | destNet      (low order) | destNet     (high order) |
                  +--------------------------+--------------------------+
    |      24  18 | ProductCode  (low order) | Revision         (major) |
    |             +--------------------------+--------------------------+
    |      26  1A |                      password                       |
    |             |               8 bytes, null padded                  |
    |             +--------------------------+--------------------------+
    |:     34  22 | origZone     (low order) | origZone    (high order) | }
    |             +--------------------------+--------------------------+ } As in
    |:     36  24 | destZone     (low order) | destZone    (high order) | } QMail
    :             +--------------------------+--------------------------+
    :      38  26 | AuxNet       (low order) | AuxNet      (high order) |
    :             +--------------------------+--------------------------+
    :      40  28 | CWvalidationCopy  (high) | CWvalidationCopy   (low) |
    :             +--------------------------+--------------------------+
    :      42  2A | ProductCode (high order) | Revision         (minor) |
    :             +--------------------------+--------------------------+
    :      44  2C | CapabilWord  (low order) | CapabilWord (high order) |
    :             +--------------------------+--------------------------+
    :      46  2E | origZone     (low order) | origZone    (high order) | }
    :             +--------------------------+--------------------------+ } As in
    :      48  30 | destZone     (low order) | destZone    (high order) | } FD etc
    :             +--------------------------+--------------------------+
    :      50  32 | origPoint    (low order) | origPoint   (high order) | }
    :             +--------------------------+--------------------------+ } As in
    :      52  34 | destPoint    (low order) | destPoint   (high order) | } FD etc
    :             +--------------------------+--------------------------+
    :      54  46 |                 Product Specific Data               |
    :             +                                                     +
    :             |                       4 Bytes                       |
                  +--------------------------+--------------------------+
           58  3A |                     zero or more                    |
                  ~                        packed                       ~
                  |                       messages                      |
                  +--------------------------+--------------------------+
                  |      0      |      0     |      0      |      0     |
                  '-----------------------------------------------------'

        Packet       = PacketHeader  { PakdMessage }  00H 00H

        PacketHeader = origNode       (* of packet, not of messages in packet   *)
                       destNode       (* of packet, not of messages in packet   *)
                       year           (* of packet creation, e.g. 1986          *)
                       month          (* of packet creation, 0-11 for Jan-Dec   *)
                       day            (* of packet creation, 1-31               *)
                       hour           (* of packet creation, 0-23               *)
                       minute         (* of packet creation, 0-59               *)
                       second         (* of packet creation, 0-59               *)
                       baud           (* max baud rate of orig and dest         *)
                       PacketType     (* old type-1 packets now obsolete        *)
                       origNet        (* of packet, not of messages in packet
                                         set to -1 if orig=point                *)
                       destNet        (* of packet, not of messages in packet   *)
    +                  productCode Lo (* 0 for Fido, write to FTSC for others   *)
    |+                 serialNo Maj   (* binary serial number (otherwise null)  *)
    |                  password       (* session pasword  (otherwise null)      *)
    |                  origZone       (* zone of pkt sender (otherwise null)    *)
    |                  destZone       (* zone of pkt receiver (otherwise null)  *)
    |                  auxNet         (* contains Orignet if Origin is a point  *)
    +!        Bytesw.  CWvalidationCopy (* Must be equal to CW to be valid      *)
    +                  ProductCode Hi
    +                  revision Minor
    +                  origZone       (* zone of pkt sender (otherwise null)    *)
    +                  destZone       (* zone of pkt receiver (otherwise null)  *)
    +                  ProdData       (* Product specific filler                *)

         When  the two copies of the CW match they can be asumed  to  be
         valid and used.

         Stone-Aged: Old FTS-0001
         Type-2+   : Old FTS-0001 plus changes indicated by "|" and  ":"
                     are valid

         A  Type-N Bundle will always advertise its capabilities in  the
         CW regardless of the type being sent.   As shown in the example
         below,  the CW allows Type-N processors to automatically  track
         the capability of your system.   Again, in cases where a stone-
         age processor is being used, this field will be ignored, and in
         the  unusual  event  that it is not  ignored,  and  is  somehow
         harmful  to  the  far  system,  the  Type-N  processor  can  be
         configured to send a CW of 0.

         The format of the Capability Word is designed to support up  to
         15  future bundle types,  and is bit-mapped to  facilitate  the
         easy  determination  of  the  maximum  common  level  supported
         between two nodes:

                        msb           Capability Word               lsb
         Node Supports  ------------FTSC Type Supported **)------------

                         U 16 15 14 13 12 11 10  9  8  7  6  5  4  3 2+

         2+,3, and 7     0  0  0  0  0  0  0  0  0  0  1  0  0  0  1  1
         2+,3, and 5     0  0  0  0  0  0  0  0  0  0  0  0  1  0  1  1
         2+ (this Doc)   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  1
         Stone Age       0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0

    !                    ^-- "U" Indicates nodes able to process RFC-822
    !                        bundles.
                        ** - In the example bit definitions only type 2,
                             and  the Stone-Age type,  are defined  now.
                             The rest are to be concidered "reserved  by
                             FTSC".

         The receiving Type-N bundler would AND the two words, obtaining
         a  word  expressing  the Types which are  common  to  both  the
         receiving  and the sending system.   The most significant  Type
         will be used for future sessions,  by default. Please note that
         this assumes that new bundling Types will be increasingly  more
         efficient or in some way more beneficial.  Because this may not
         always  be  the  case,  there should be a  method  provided  to
         override the automatic upgrade,  as illustrated  above,  should
         this ever happen.

    !    N.B. The  one bit left over (Msb) is now used as indicator  for
    !         RFC-822 type bundles. For info on RFC-822 please check out
    !         the relevant documents themselves.

    !         For  a more explanatory text on using the CW to  its  full
    !         potential,  refer  to  the FSC-0039 text by  Mark  Howard.
    !         Mark also gives some more rationale for the origional idea
    !         of the CW.

         Generating Type-2+ bundles
         ==========================

          Do we have a CW              Does CW indicate
         stored for dest?  YES ---->   higher packets  YES ---> Generate higher
               NO                       we support?                packet
               |                            NO
              \|/                           |
               +-----<----------------------+
               |
          Fill header with all info
               |
              \|/
               |
          Are we sending from a point? (origPoint != 0) YES --+
               |                                              |
              NO                                              |
               |                                             \|/
               |                                    set AuxNet = OrigNet
              \|/                                  set OrigNet = -1
               |                                              |
               +-----<----------------------------------------+
               |
          Add Messages
               |
          Terminate packet
               |
           Send packet

         Receiving Type-2+ bundles
         =========================

           Receive Packet
               |
           Packettype = 2  NO  -------------> Process Type-Other
              YES
               |
               |
           CWcopies match  NO --------+------> Treat as normal Stone-Age packet
              YES                     |     |
               |                      |     |
           Store CW                  /|\    |
               |                      |    /|\
           CW is 0 YES  --------------+     |
              NO                            |
               |                            |
               |                            |
           CW indicates support for 2+ NO --+
              YES
               |
               |
    !      OrigPoint is not 0 and OrigNet = -1 YES -------+
               NO                                         |
               |                                         \|/
    !         \|/                            Set OrigNet is AuxNet
               |                                          |
               +------<-----------------------------------+
               |
            Process using added info

         Credits
         =======

         To Mark Howard,  for introducing the idea of a CW in his  FSC-
         0039  document and quite rightly pointing out one big  omision
         in revision 1 of this document.

         To  Rick Moore,  for doing a good job in processing all  these
         revisions by Mark and myself, and for his work for the FTSC in
         general.

         To  Joaquim  Homrighausen,  for his contributions  to  FidoNet
         software  in general,  and especially for his time devoted  to
         reading,  discussing  and  implementing the ideas Mark  and  I
         introduced.

         To  Andre van de Wijdeven,  for producing and letting me  beta
         test his TS-MM software, which in my opinion is the best point
         software around.  (I'm not saying available,  because it isn't
         :-()

         To john lots, for shipping this stuff to the US.

         To  Jon  Webb,  for doing a much needed grammar  and  spelling
         check.

         To Bob Hartman, Vince Periello, Tom Jennings, Eelco de Graaff,
         aXel Horst,  Arjen van Loon,  jim nutt,  Odinn Sorensen, David
         Nugent,  Peter  Janssens and many others,  for making  FidoNet
         what it is now, for me and for everybody.

         Epilog
         ======

         So  this it,  now it's up to you to decide whether or  not  to
         implement  it.  A  small  change was  made  in  the  receivers
         flowchart and a small incompatibility with the later revisions
         of  FSC-0039 was removed.  That will ensure that FSC-0048  and
         FSC-0039 mailers can happily talk to each other....

         The best way to implement this would be to always support FSC-
         0048  on inbound trafic and generate FSC-0048 on  outbound  by
         default. A switch on a per-node basis will force your software
         to be FSC-0039 or even FSC-0001 only,  and you will cover  all
         bases.

         This can be done easily, as FSC-0048 is a superset of FSC-0039
         (The -1 thing on points being the difference) which in turn is
         a superset of FTS-0001 (CW). I'd be glad to get some feedback.
         You can put it in NET_DEV or netmail me.

                                  Jan Vroonhof (2:281/1.12@fidonet)

Go Back