Initial revision
This commit is contained in:
Ken Bowley
417
html/ftsc/fsc-0048.html
Executable file
417
html/ftsc/fsc-0048.html
Executable file
@@ -0,0 +1,417 @@
|
||||
<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>
|
||||
|
||||
Reference in New Issue
Block a user