418 lines
20 KiB
HTML
418 lines
20 KiB
HTML
|
<HTML>
|
||
|
|
<HEAD>
|
||
|
|
<TITLE>A Proposed Type-2 Packet Extension.</TITLE>
|
||
|
|
</HEAD>
|
||
|
|
|
||
|
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||
|
|
<BODY
|
||
|
|
BGCOLOR="#FFFFFF"
|
||
|
|
TEXT="#000000"
|
||
|
|
LINK="#0000FF"
|
||
|
|
VLINK="#000080"
|
||
|
|
ALINK="#FF0000"
|
||
|
|
>
|
||
|
|
<PRE>
|
||
|
|
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)
|
||
|
|
|
||
|
|
</PRE>
|
||
|
|
|
||
|
|
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
|
||
|
|
|
||
|
|
</BODY>
|
||
|
|
</HTML>
|
||
|
|
|