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
    Software.



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
following:

       ^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 :

  <Address>[@<Domain>]

  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:

  <Username>@<Fido_Address>

  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/[email protected]

  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/[email protected]
        ^ADEST 292/862-cosysops@2:292/850
        ^ADEST TE880714%BANUFS11@BITNET
        ^ADEST Jack@OS/2.dev.itnet@itnet
        ^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/2.dev.itnet', 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/[email protected]@SIGnet.ftn

  The message will be sent to 2:292/[email protected], 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%
  OK.

  Information in the DEST-kludge will always override information in the
  FTS-0001 message header.



  FOOTNOTE:

  (*)

  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
  this:

  ^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/[email protected]
           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/[email protected]
               ^AROUTE 1:105/[email protected]
               ^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

SendMsg(Temporary_destination)

-----+----------+-------------------------+-------------------------+-----.
|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
 fsc-0058.
 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/[email protected]
   Wim Van Sebroeck        2:292/[email protected]



                     --- End Of Proposal ---

You are viewing proxied material from gopher.altexxanet.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.