Document: FSC-0058
Version:  002 
Date:     01-Nov-1992

                   A New Way Of Addressing In FidoNet(r)

                       Wim Van Sebroeck & Jan Spooren
                             November 1st, 1992

            This document replaces the now obsolete version 001

    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 trademarks of Tom Jennings and Fido

A. Why a new Proposal :
FidoNet has grown from a few single BBSs to a worldwide network of nodes.
Because of that enormous growth, we have several kludge-lines just to write
to someone else. And for every extra dimension a new kludge is necessary.
(3D: ^AINTL ; 4D: ^AFMPT, ^ATOPT ; 5D: ^ADOMAIN). Every time a new
dimension or addressing-system is invented, not only the packer/router
software needs to be adjusted, but also the message editor and a whole
series of other utilities, being virtually the whole FidoNet software.

This is why we made this proposal:
1) to make life easier for programmers and developers.
2) to have a system that will have no problems with further
   backward-compatibility. (from this system on)
3) to have a system that is simple (in usage).
4) and to have a system that accepts every possible address.

B. Proposal :
To send a message one needs two things: the origin address and the
destination address. (And for routing inter-domain messages you also need
the address of the gateway). Until now, we needed four different
kludge-lines when we wanted to send a message to another domain (^ADOMAIN,
^AINTL, ^AFMPT, ^ATOPT). To minimize these kludges we suggest the

        ^ADEST <dest_address>
        ^AORIG <orig_address>
        ^AROUTE <route_via_address>

These kludges are *not* followed by a colon (':').

1) The ^ADEST kludge: this kludge contains the address where the message
   has to be sent to. In other words: it contains the destination address.
   <dest_address> is an ASCII string that may contain any readable
   character, (above and including 32 (space) and below ASCII 128), and is
   only terminated by the end-CR of the kludge-line. It is up to the
   mailprocessors of every domain (FidoNet compatible or not) if they
   regard the address as case-sensitive or not.

   The FORMAT of <dest_address> is :


   Where <Address> is the valid username/address in the network <Domain>,
   and <Domain> cannot have any '@' of '/'-characters in it, while
   <Address> can. The reason why '/' characters are not allowed in the
   <Domain>-field, is because they are necessary to recognize a
   FidoNet-style address, since <Domain> is optional for messages that
   won't be crossing domain- borders. (*)
   In other words:  The domain is always the string behind the last @ sign
   in the <dest_address> field, except when domain would contain a
   '/'-character. In that case, <Domain> is the default domain, and
   <Address> is the complete string behind the DEST-kludge.

   Concerning FidoNet-compatible addresses, there are some extra rules,
   since FidoNet is one of these rare networks that haven't got the
   username in the address.

   A valid FidoNet <Address> is made up like this:


   Where <Username>@ is mandatory and <Fido_Address> is a valid fidonet
   address. The FidoNet-address must contain at least the zone:net/node
   number. Point number is optional.

   Eg.: ^ADEST Wim Van Sebroeck@2:292/862.0@FidoNet.Org

   will generate an outbound message for user 'Wim Van Sebroeck' at
   Fido-node 2:292/862.0 within FidoNet. The domain name for FidoNet is
   'FidoNet.Org', and *not* just Fido, or FidoNet or whatever. This is not
   a waste of space, since the domain name can be omitted when the message
   remains in the default network. Only for messages crossing domain
   borders, the domain name is necessary. We opted for the '.org' and
   '.ftn' suffixes, in order to make interfacing to InterNet easier.
   Some more addressing-examples:
         ^ADEST Jan Spooren@2:292/852.0@Fidonet.Org
         ^ADEST 292/862-cosysops@2:292/850
         ^ADEST TE880714%BANUFS11@BITNET
         ^ADEST Jack@OS/
         ^ADEST m2xenix!uunet!BANUFS11.BITNET!TE880714@uucp
   The first example should be clear, since it will be the most frequently
   used addressing-style.
   The 4th example shows the kludge for a message to the address
   'Jack@OS/', within domain 'itnet'. There is no problem
   whatsoever with the '/' character, because it is part of the <Address>,
   and not of the <Domain>.
   In the last example, the message has to be sent to the uucp-gateway,
   wich will send it on within the internet-network, with the
   destination-address: 'm2xenix!uunet!BANUFS.11BITNET!TE880714'

   Also this is a valid address:

   ^ADEST Wim Van Sebroeck@2:292/862.0@FidoNet.Org@SIGnet.ftn

   The message will be sent to 2:292/862.0@FidoNet.Org, within SIGnet.ftn.
   SIGnet will then send the message back to 2:292/862.0 in FidoNet.
   The message will cross the domain-borders twice. Apart from the fact
   that it may seem an annoying practice, technically the address is 100%
   Information in the DEST-kludge will always override information in the
   FTS-0001 message header.


   For a proper understanding of this '/'-restriction, let's illustrate
   this by means of an example. If we send a message with a kludge like

   ^ADEST Wim Van Sebroeck@2:292/862

   Then the mailprocessor could wrongly interpret the <dest_address>:
   It could decide the <address> to be 'Wim Van Sebroeck' in <domain>
   '2:292/862'. But with the '/'-restriction it is now clear that the
   address is 'Wim Van Sebroeck@2:292/862' in the default domain.

2) The ^AORIG kludge: this kludge contains the origin address.
   <orig_address> has the same restrictions as the <dest_address>.

   For example: ^AORIG Wim Van Sebroeck@2:292/862.0@Fidonet.Org
            or: ^AORIG Infomag.Dev@ITNet

3) The ^AROUTE kludge: this is needed to point to the gateway address, when
   sending a message to another domain. Since not all gateways are listed
   in the nodelist and because possibly not all intermediate systems are
   aware of a particular domain-name, it is necessary to add the address of
   the gateway.
   The gateway is a system within the default domain, that can send the
   message to the desired domain. The kludge can also be used, however, to
   point to a zonegate between different zones in one domain. In any case,
   for every domain-border that will be crossed, there needs to be one
   ROUTE-kludge to indicate the gateway. It should be obvious, that a
   FidoNet-address in a ROUTE-kludge never carries a username.
   The ROUTE-kludge always overrides the DEST-kludge. A system receiving a
   message should ALWAYS send the message to the address specified by the
   ROUTE-kludge, and NOT to the destination address. In other words, the
   ROUTE-kludge is not to be interpreted as a hint to a possible gateway,
   but must be regarded as a new destination address, and the message will
   always have to reach the gateway. The gateway will then change the
   ^AROUTE to a ^AROUTD kludge, in order to indicate that the gateway
   received the message, and to see to it that the message won't travel
   back to the gateway. This absolute priority of the ROUTE-kludge above
   the DEST-kludge is necessary, since otherwise messages could be bouncing
   between two nodes that both prefer different gateways to send the
   message to.
   The ROUTE-kludge also has nothing to do with the actual routing itself.
   The ROUTE-kludge only defines an intermediate address that has to be
   reached before the message reaches its final destination. How the
   message gets to this intermediate address doesn't matter: it may be
   direct or it may be routed through other systems. Remember that FidoNet
   is an amateur network, with each system paying its own phone bills!

   For example: ^AORIG Wim Van Sebroeck@2:292/862.0@Fidonet.Org
                ^AROUTE 1:105/42.0@Fidonet.Org
                ^ADEST m2xenix!uunet!BANUFS11.BITNET!TE880714@uucp

C. Advantages and Disadvantages :
a) Advantages:
     - The main advantage is that one only needs two kludges to specify the
       origin and the destination address. (And that these kludges are
       always in a message).
     - The system is also very flexible because any address is possible.
     - Utilities must not be updated when a new address-dimension is created.
     - Inter-domain and inter-network messages are finally possible.
     - No limits are placed on both username and address-field length.
     - Perfect compatibility is ensured with future message and packet 
       formats that will override FTS-0001.

b) Disadvantages:
     - Please be so kind to write them to us. We can't figure what they
       could be?

D. Implementation Notes :

D.1. Processing an outgoing message.

|State| State    | Predicate(s)            | Action(s)               | Next|
|  #  | Name     |                         |                         | St  |
| O1  | MsgFound | Find DEST/ROUTE         | 1 Found fsc-58 kludge   | O2  |
|     |          | kludges in message      | 2 Fsc-58 kludge not fnd | S8  |
|     |          |                         | 3 Error occured         | exit|
|     |          |                         | 4 Dest is 1 of our AKAs | exit|
| O2  | ReadKldg |                         | Take only 1st ROUTE and | O3  |
|     |          |                         | 1st DEST-kludge         |     |
| O3  | ChkROUTE | Is there a ROUTE kludge | 1 Route kludge found    | O4  |
|     |          |                         | 2 No route kludge       | O10 |
| O4  | WeRoute? | Is ROUTE one of our     | 1 Yes                   | O5  |
|     |          | AKA's                   | 2 No                    | O9  |
| O5  | DsblROUT |                         | Change ROUTE into ROUTD | O6  |
|     |          |                         | and strip 'TOPT' and    |     |
|     |          |                         | 'INTL'-kludges to our   |     |
|     |          |                         | system.                 |     |
| O6  | WeGate?  | Are we a gateway to     | 1 Yes                   | O7  |
|     |          | another domain?         | 2 No                    | O2  |
| O7  | Needgate | Get next ROUTE/DEST-kldg| 1 Yes                   | O8  |
|     |          | Is it another domain?   | 2 No                    | O3  |
| O8  | Gateway  |                         | Do gatewaying-stuff     | exit|
|     |          |                         | Don't forget to strip   |     |
|     |          |                         | @<domain> from the      |     |
|     |          |                         | <dest_address>          |     |
| O9  | SndROUTE |                         | SendMsg to ROUTE        | S1  |
|     |          |                         | (Temp. Dest = ROUTE)    |     |
| O10 | SndDEST  |                         | SendMsg to DEST         | S1  |
|     |          |                         | (Temp. Dest = DEST)     |     |

D.2. Sending of an outgoing message


|State| State    | Predicate(s)            | Action(s)               | Next|
|  #  | Name     |                         |                         | St  |
| S1  | Looktabl |                         | Find node to route to   | S2  |
|     |          |                         | according to own routng |     |
|     |          |                         | scheme and msg-attribs. |     |
| S2  | IsFsc58  | Lookup in table if node | 1 No, not fsc-58 compl. | S3  |
|     |          | is fsc-58 compliant     | 2 YES! Fsc-58 compliant | S8  |
| S3  | FMPT     | Has ORIG-kludge point#  | 1 No                    | S4  |
|     |          |                         | 2 Yes: Insert FMPT-kldg |     |
|     |          |                         |   if not already present|     |
| S4  | TOPT     | Contains                | 1 No                    | S5  |
|     |          | temporary_destination   | 2 Yes: Insert TOPT-kldg |     |
|     |          | a point-address ?       |   if not already present|     |
| S5  | INTL     | Compare ORIG and        | 1 Zones equal           | S6  |
|     |          | temporary_destination   | 2 Not eq. : Make INTL-k |     |
|     |          |                         |   if not already present|     |
| S6  | DOMAIN   | Compare ORIG and        | 1 Domains equal         | S7  |
|     |          | temporary_destination   | 2 Not eq. : Domain-kldg |     |
|     |          |                         |   if not already present|     |
| S7  | Usernames|                         | Fill in FTS-1 dest and  | S8  |
|     |          |                         | orig usernames, accord. |     |
|     |          |                         | to ORIG and DEST except |     |
|     |          |                         | when ORIG/D names blank |     |
| S8  | XportMsg |                         | Export message          | Exit|

D.3. Processing an incoming message:

| I1  | ChkKldg  | Find DEST/ROUTE/ORIG    | If found: store kludges | I2  |
|     |          | kludges in message      |                         |     |
| I2  | ChkFSC58 | Are DEST/ROUTE/ORIG     | 1 Yes, fsc-58 compliant | I3  |
|     |          | Kludges available?      | 2 No, not fsc-58 compl. | I4  |   
| I3  | ChkTable | Is originator of packet | If not in lookup-table  | I4  |
|     |          | in lookup-table? ^^^^^^ | and should be, then     |     |   
|     |          |      ( SEE SECTION E !) | add node to the table   |     |   
| I4  | ChkDEST  | Is message to us?       | 1 Yes: store message    | exit|
|     |          | (Are we DEST?)          | 2 No                    | I5  |
| I5  | KeepTrans| Do we keep a copy of in-| 1 Yes: Store msg and -->| O1  |
|     |          | transit mail ?  :-(     | 2 No:                   | O1  | 

E. Discussion of the Implementation Notes.

* O5, "DsblROUT" :

  It is clear that when a message travels through an intermediate system 
  which is mentioned in a ROUTE-kludge, this ROUTE-kludge will have to be 
  removed, because the message did arrive at this system.  Instead of just 
  deleting the whole kludge-line, the kludge will be changed in ROUTD.
  This is a much easier and faster process for a mailprocessor and it 
  enables the recipient of the message to have some information about the 
  route the message took.

  Because there is no FTS-0001 equivalent to the route-kludge, a system that 
  is in a route-kludge needs to be FSC-0058 compliant.  The intermediate 
  systems to this ROUTE-system need not to be FSC-0058 compliant: Our 
  implementation notes assume a list of fsc-0058 compliant nodes (the 
  'lookup table'), that is continuously updated, when messages arrive from 
  fsc-0058 systems.  When a message is to be send on to a non-fsc-0058 
  system, the message will be converted to the old FTS-0001 format, 
  including FMPT-, TOPT- and INTL-kludges.  The destination-address in this 
  (converted) message will then be the address of the first ROUTE-kludge.  

  There is one tricky point:  When such a message arrives at this ROUTE-
  system, the message can have TOPT (if the system is a pointsystem) and 
  INTL kludges in the messagebody, due to the conversion to the FTS-0001 
  format.  The ROUTE-system's mailprocessor will have to find these and 
  strip them from the message.

* S3 -> S7 :

  These stages perform the conversion to FTS-0001 format, in case the next 
  receiving system will be non-fsc-0058 compliant.

* I3, "ChkTable" :

  Care must be exercized:  If we find FTS-0058 information in a message 
  we don't know if the last system, or any of the previous systems the 
  message passed is fsc-0058 compliant.  We can only know for sure when the 
  message was sent directly to us.  That is (in FidoNet packet type 2) when 
  the packet-orig address is the same as the message orig-address, or when 
  the packet-orig address is the same as the last routd-kludge address.

  We are aware of the fact that the lookup-table won't be filled fast this 
  way.  But we don't want that:  We only have to know if our 'surrounding' 
  nodes, i.e., the nodes with which we have frequent connections, support 
  We also want to know if gateway systems are fsc-0058 compliant, because we 
  have to put them in a ROUTE-kludge.  But these should be just a few 
  systems and the fact of their fsc-0058 compliance will be known easily.  
  They can then be added manually.

  We do not even dare to suggest the use of a nodelist-flag, that could 
  simplify this whole system of investigating the fsc-0058 compliance, in 
  order to downgrade to the FTS-0001 level for non-compliant systems.

F. Questions :
Questions can always be sent to:

    Jan Spooren             2:292/852.0@Fidonet.Org
    Wim Van Sebroeck        2:292/862.0@Fidonet.Org

                      --- End Of Proposal ---