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