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 ^AORIG ^AROUTE 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. 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 is :
[@] Where
is the valid username/address in the network , and cannot have any '@' of '/'-characters in it, while
can. The reason why '/' characters are not allowed in the -field, is because they are necessary to recognize a FidoNet-style address, since 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 field, except when domain would contain a '/'-character. In that case, is the default domain, and
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
is made up like this: @ Where @ is mandatory and 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/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
, and not of the . 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% 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 : It could decide the
to be 'Wim Van Sebroeck' in '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. has the same restrictions as the . 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 | | | | | | @ from the | | | | | | | | |-----+----------+-------------------------+-------------------------+-----| | 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/852.0@Fidonet.Org Wim Van Sebroeck 2:292/862.0@Fidonet.Org --- End Of Proposal ---