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)

