Document: FSC-0058 Version: 001 Date: 02-Feb-1992 A New Way Of Addressing In Fidonet(r) Wim Van.Sebroeck & Jan Spooren February 2, 1992 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.subject to the restrictions Fido and FidoNet are registered marks of Tom Jennings and Fido Software. A. Why a new proposal : ------------------------ FidoNet has grown from a few single BBS'es 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). Each time a new dimension or addressing-system is invented, not only to the packer-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 origination-address and the destination-addres. (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 minimise these kludges we suggest the following: ^ADEST ^AORIG ^AROUTE 1) The ^ADEST kludge: This kludge contains the address where the message has to go 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 127), and is only ended by the ending CR of the kludge-line. It is up to the mailprocessors of every domain (FidoNet compatible or not), to regard the address as case- sensitive or not. The FORMAT of is :
@ Where
is the valid username/address in the network , and may not have any @-characters in it, while
may. In other words: The domain is always the string coming after the last @ sign in the field. A without any '@'-signs (i.e., without any domain) is to be regareded as an address in the same domain. E.g.: ^ADEST 2:295/20.0@Fidonet.Org ^ADEST TE880714%BANUFS11@BITNET ^ADEST m2xenix!uunet!BANUFS11.BITNET!TE880714@uucp In this last example, the message will be sent to the uucp-gateway, with the destination-address: 'm2xenix!uunet!BANUFS.11BITNET!TE880714' Remark that when sending a message to a certain gateway, the @ has to be stripped. Remark as well that also this is a valid address: ^ADEST 2:295/69.0@FidoNet.Org@SIGnet.ftn The message will be sent to 2:295/69.0@FidoNet.Org, within SIGnet.ftn. SIGnet will then send the message back to 2:295/69.0 in FidoNet. The message will cross the domain-borders twice. Apart from the fact that it may seem an annoying practise, technically the address is 100 % OK. 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 as follows: [@] Where @ is optional, and is a fully (!) 4-D fidonet address. Eg.: ^ADEST Wim Van.sebroeck@2:295/69.0@FidoNet.Org will generate an outbound message for user 'Wim Van.sebroeck' at Fido-node 2:295/69.0 within FidoNet. Information in the DEST-kludge will always override information in the FTS- 0001 message header. Only if no username is specified in the kludge, the username will be taken from the message-header. Technically it is OK to send a message to ^ADEST 2:295/20.0 It will be sent to node 2:295/20.0 in the default network, and the username will be taken from the message header. But we seriously suggest not to use this kind of addressing. We suggest, if using a DEST kludge, to ALWAYS put the username into the DEST-kludge, in order to allow upward compatibility, in the time when (oh when) finally the FTS-0001 message-header will be thrown away. 2) The ^AORIG kludge: This kludge contains the origination-address. has the same restrictions as the . For example: ^AORIG Wim Van.sebroeck@2:295/69.0@Fidonet.Org or: ^AORIG Infomag.Dev@ITNet 3) The ^AROUTE kludge: This kludge contains the address of a gateway. This is useful when you are sending messages to other domains. For example: you are 999:99/1.11@TestNet.FTN and you want to write a netmail to Univ.Information@ITNet and you have to gateways: 998:1/2.0@TestNet.FTN (a quick one) and 999:100/200.300@TestNet.FTN (a slow one). You want your message to be delivered as guickly as possible. This means you want your netmail to be gated via 998:1/2.0@TestNet.FTN. The solution is as follows: ^ADEST Univ.Information@ITNet ^AORIG 999:99/1.11@TestNet.FTN ^AROUTE 998:1/2.0@TestNet.FTN must be an address in the same network of the . C. Advantages and Disadvantages : --------------------------------- a) Advantages: - The main advantage is that you only need two kludges to specify the origination- and the destination-address. (And that these kludges are always in your message). - The system is also very flexible because every address is possible. - Routing can be programmed when you use the ^AROUTE kludge. - Utilities must not be updated when there is a new dimension. - 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: - It's not easier for those people that have to write a packer. (is it ?) D. Questions : --------------- Questions may always be sent to: Jan Spooren Fidonet : 2:295/20.0@Fidonet.Org Wim Van Sebroeck Fidonet : 2:295/69.0@Fidonet.Org --- End Of Proposal ---