F I D O N E W S Volume 16, Number 13 29 March 1999 +----------------------------+---------------------------------------+ | The newsletter of the | ISSN 1198-4589 Published by: | | FidoNet community | "FidoNews" | | _ | +27-41-581-5913 [5:5/23] | | / \ | | | /|oo \ | | | (_| /_) | | | _`@/_ \ _ | | | | | \ \\ | Editor: | | | (*) | \ )) | Henk Wolsink 5:7104/2 | | |__U__| / \// | | | _//|| _\ / | | | (_/(_|(____/ | | | (jm) | Newspapers should have no friends. | | | -- JOSEPH PULITZER | +----------------------------+---------------------------------------+ | Submission address: FidoNews Editor 5:5/23 | +--------------------------------------------------------------------+ | MORE addresses: | | | | submissions=> editor@fidonews.org | | hwolsink@catpe.alt.za | +--------------------------------------------------------------------+ | For information, copyrights, article submissions, | | obtaining copies of FidoNews or the internet gateway FAQ | | please refer to the end of this file. | +--------------------------------------------------------------------+ Table of Contents 1. EDITORIAL ................................................ 1 2. ARTICLES ................................................. 2 Internet newsgroup<>echomail ............................. 2 Packet type 2 ............................................ 3 3. COLUMNS .................................................. 21 What's Not Happening: Tag-Teams ......................... 21 4. NOTICES .................................................. 23 5. FIDONET BY INTERNET ...................................... 24 6. FIDONEWS INFORMATION ..................................... 28 FIDONEWS 16-13 Page 1 29 Mar 1999 ================================================================= EDITORIAL ================================================================= Greetings, Our summer is comming to an end, with temperatures back to normal. ;-) What is normal you may ask? Temperatures acceptable to us humans that is. Happy reading, ----------------------------------------------------------------- FIDONEWS 16-13 Page 2 29 Mar 1999 ================================================================= ARTICLES ================================================================= Internet newsgroup<>echomail gating service now available By Joe Jared (1:103/301@fidonet) joejared@webworldinc.com Special thanks to Remarq.com, (formerly supernews.com) for making control messages available to me for creation of newsgroups. If what I'm told is correct on this topic, newsgroups once added, are global in scope. TO ANY MODERATORS INTERESTED: Your echo can be gated to the internet on request. To initiate gating of your echo, simply send netmail or an email to one of my addresses as listed above and respond to the confirmation message. Once the echo has successfully be made global, the moderator may assume the gating duties assuming software is available to do so. The software I am currently using is compatable with most news servers and works with Windows 95/98/NT and is freeware. The key solutions however in performing this gateway are available from newsgate@webworldinc.com, a listserv open to all. The structure as the echo would appear on the internet would be fidonet.*, where the * is the name of your echo. In some cases, it may appear as fidonet.name.*, replacing the underscores '_' with dots if deemed appropriate to the heirarchy. For example: SIP_ACA would be mapped to fidonet.sip.aca, because it is a part of a group of echoes preceded with the keyword SIP. Your message as the moderator of an echo would need to include heirarchy if it's not readily visible as well as a request to have it added to internet distribution. I will then respond to the elisted moderator address for all cases except where the moderator is a known highjacker, in which case the recognized moderator will take precedence. No gated echo need be elisted but it would make things easier for me if you as moderator elisted the echo. If you are in contact with moderators of other newsgroups and would like your echomail conference merged with their newsgroup, a request from both moderators are required, and can be broken on request by either party. As a moderator the ONLY requests honored will be to add "known" spammers to the kill list, and to add and remove it from internet distribution. The object of this gateway is to improve the volume of traffic while minimizing some of the hazards (Spam, Viruses, trojans, twits etc). A gated echo will disappear from distribution if it is deemed to be a problematic echo (I.E. too much used cowfood involved in distributing it). This service is free and as such should have reasonable expectations. Initially this system will be limited in terms of echoes that can be gated (I'm using soon to be replaced and outdated tosser that only supports 2048 echoes), but I doubt this will FIDONEWS 16-13 Page 3 29 Mar 1999 be a problem for a few months. As a final note, once mail leaves or enters fidonet, it is no longer bound by policy4, nor can it be expected to, as it is no longer just fidonet mail. The gateway assumes no liablity for traffic whether it be legal or otherwise and will take prompt action once notified of an repeated offense, but it cannot be expected that all internet gated echoes will be free of clutter. One a positive note however, your echomail area will receive the exposure that it desperately needs to thrive and grow. ----------------------------------------------------------------- Packet type 2, draft 990328 by Goran Eriksson, 2:201/505, get@get.pp.se It seems to be the general opinion among FTSC members that packet type 2+ (and possibly others like packet type 2.2 and the packet type proposed by FSC-48) should receive FTS status. To prepare for this I have written a document describing packet type 2 as this is the basis for all of these other packet types. I do not expect this document to be included verbatim into a new FTS. Neither for packet type 2, nor for the other packet types. However, I hope that the FTSC will find my document useful enough to build the new FTS documents upon it. Therfore, I will post my latest draft in the following messages and invite you to comment on it in the NET_DEV echomail conference. English is a foreign language to me. Purely linguistic remarks are welcome, but please send them to me by netmail or e-mail. 1. General A packet file of type 2 has the following general layout --------------------- | Packet header | --------------------- | Packed message | --------------------- : : --------------------- | Packed message | --------------------- | Packet terminator | --------------------- The number of packed messages may be 0 or more. FIDONEWS 16-13 Page 4 29 Mar 1999 2. Packet header 2.1. General The packet header of a packet file of type 2 has the following general layout Relative byte offset Size in bytes ----------------------- 0 00H | Origin Node | 2 ----------------------- 2 02H | Destination Node | 2 ----------------------- 4 04H | Year | 2 ----------------------- 6 06H | Month | 2 ----------------------- 8 08H | Day | 2 ----------------------- 10 0AH | Hour | 2 ----------------------- 12 0CH | Minute | 2 ----------------------- 14 0EH | Second | 2 ----------------------- 16 10H | Baud Rate | 2 ----------------------- 18 12H | Packet Type | 1 ----------------------- 20 14H | Origin Net | 2 ----------------------- 22 16H | Destination Net | 2 ----------------------- 24 18H | Product Code | 1 ----------------------- 25 19H | Serial Number | 1 ----------------------- 26 1AH | Password | 8 ----------------------- 34 22H | Origin zone | 2 ----------------------- 36 24H | Destination zone | 2 ----------------------- 38 26H | Reserved | 20 ----------------------- The total size of the packet header is 58 bytes. 2.2. Origin Node This field contains information about the node number of the system having created the packet. The field contains a 16-bit binary unsigned integer in the range 0-65535. See notes 1 and 2. FIDONEWS 16-13 Page 5 29 Mar 1999 2.3. Destination Node This field contains information about the node number of the system for which the packet was created. The field contains a 16-bit binary unsigned integer in the range 0-65535. See notes 1 and 2. 2.4. Year This field contains information about the year when the packet was created. The field contains a 16-bit binary unsigned integer in the range 0-66535. See notes 2 and 3. 2.5. Month This field contains information about the month when the packet was created. The field contains an 8-bit binary unsigned integer in the range 0-11. The following representation is used: Month represented as January 0 February 1 March 2 April 3 May 4 June 5 July 6 August 7 September 8 October 9 November 10 December 11 See note 3. 2.6. Day This field contains information about the day when the packet was created. The field contains an 8-bit binary unsigned integer in the range 1-31. See note 3. 2.7. Hour This field contains information about the hour when the packet was created. The field contains an 8-bit binary unsigned integer in the range 0-23. See note 3. 2.8. Minute This field contains information about the minute when the packet was created. The field contains an 8-bit binary unsigned integer in the range 0-59. See note 3. FIDONEWS 16-13 Page 6 29 Mar 1999 2.9. Second This field contains information about the second when the packet was created. The field contains an 8-bit binary unsigned integer in the range 0-59. See note 3. 2.10. Baud Rate This field is filled with the 16-bit binary unsigned integer 0 by the system creating the packet. Any system receiving the packet may ignore the value of this field. For historical reasons this field is called Baud Rate. See note 2. 2.11. Packet Type This field is filled with the 16-bit binary unsigned integer 2 by the system creating the packet. Any system receiving the packet should check the contents of this field. If it does not contain the 16-bit binary unsigned integer 2 it is recommanded that the receiving system regards it unsafe to unpack this packet according to the format specification for packet type 2. Any further actions by the receiving system in this case are left to the implementation. See note 2. 2.12. Origin Net This field contains information about the net number of the system having created the packet. The field contains a 16-bit binary unsigned integer in the range 1-65535. See notes 1 and 2. 2.13. Destination Net This field contains information about the net number of the system for which the packet was created. The field contains a 16-bit binary unsigned integer in the range 1-65535. See notes 1 and 2. 2.14. Product Code This field contains information about the product code assigned to the programme creating the packet. The field contains an 8-bit binary unsigned integer in the range 0-255. Product codes are assigned to programmes by the FTSC. See FTA-1005. That document also contains information about what product codes to use by programmes which have not yet been assigned a product code by the FTSC. 2.15. Serial Number This field may contain information about the serial number of the programme creating the packet. The field contains a 8-bit binary unsigned integer in the range 0-255. If a programme does not want to assign any serial number to this field it should fill this field with the 8-bit binary unsigned integer 0. FIDONEWS 16-13 Page 7 29 Mar 1999 2.16. Password This field contains information about a packet level password. The field contains an array of 0-8 ASCII characters, each in the range '0'..'9', 'A'..'Z'. The programme creating the packet should fill all unused bytes in this field with the 8-bit binary unsigned value 0. Any programme receiving a packet should ignore any bytes in this field after the first occurence of an byte with the value 0. The comparison of passwords in a received packet file is done case insensitively. Any programme receiving a packet with a password differing from the password set up between the system having created the packet and the system receiving it (including the absence of a password when one has been agreed upon) should consider the information contained in the packet about the system that has created as unreliable. Any further actions by the receiving system in this case are left to each implementation. See note 5. 2.17. Origin Zone This field may contain information about the zone number of the system having created the packet. The field contains a 16-bit binary unsigned integer in the range 1-65535. If a programme does not wish to enter a zone number into this field it should fill it with the 16-bit binary unsigned value 0. See notes 1, 2 and 4. 2.18. Destination Zone This field may contain information about the zone number of the system for which the packet was created. The field contains a 16-bit binary unsigned integer in the range 1-65535. If a programme does not wish to enter a zone number into this field it should fill it with the 16-bit binary unsigned value 0. See notes 1, 2 and 4. 2.19. Reserved This field is filled by the programme creating the packet with an array of bytes with the 8-bit binary unsigned value 0. Any programme receiving a packet should ignore the contents of this field. 3. Packed message format 3.1. General The packed message in a packet file of type 2 has the following general layout Relative byte offset ----------------------- 0 00H | Packet Type | ----------------------- 2 02H | Origin Node | ----------------------- 4 04H | Destination Node | FIDONEWS 16-13 Page 8 29 Mar 1999 ----------------------- 6 06H | Origin Net | ----------------------- 8 08H | Destination Net | ----------------------- 10 0AH | Attribute | ----------------------- 12 0CH | Cost | ----------------------- 14 0EH | Date and Time | ----------------------- 34 22H | To-name | ----------------------- | From-name | ----------------------- | Subject | ----------------------- | Message body | ----------------------- The total size of the packed message is variable. 3.2. Packet Type This field is filled with the 16-bit binary unsigned integer 2 by the system creating the packet. Any system receiving the packet should check the contents of this field. If it does not contain the 16-bit binary unsigned integer 2 it is recommanded that the receiving system regards it unsafe to unpack this packet according to the format specification for packet type 2. Any further actions by the receiving system in this case are left to the implementation. See note 2. 3.3. Origin Node This field contains information about the node number of the system having created the message. The field contains a 16-bit binary unsigned integer in the range 0-65535. See notes 1 and 2. 3.4. Destination Node This field contains information about the node number of the system for which the message was created. The field contains a 16-bit binary unsigned integer in the range 0-65535. See notes 1 and 2. 3.5. Origin Net This field contains information about the net number of the system having created the message. The field contains a 16-bit binary unsigned integer in the range 1-65535. See notes 1 and 2. 3.6. Destination Net This field contains information about the net number of the system for FIDONEWS 16-13 Page 9 29 Mar 1999 which the message was created. The field contains a 16-bit binary unsigned integer in the range 1-65535. See notes 1 and 2. 3.7. Attribute This field contains information about the attributes assigned to the message in question. This field is treated as a 16-bit bit mapped flag field with the following assignments: Bit Meaning --- ------- 0 Private 1 Crash 4 File Attached 10 Reserved 11 File Request 12 Return Receipt Request 13 Is Return Receipt 14 Audit Request 15 File Update Request See note 2. 3.7.1. Private When this attribute is set the message is considered private and intended for the addressee only. See a separate document for the use of the Private attribute in echomail messages. 3.7.2. Crash When this attribute is set the message is considered high-priority. A system that encounters a message with the Crash attribute set normally makes an effort to speed the delivery of the message in question if it is not intended for the own system. However, the actions actually to be taken upon receipt of a message with the Crash attribute set is left to each implementation. 3.7.3. File Attached When this attribute is set it is supposed that one or more files are attached to the message. The files are transferred separately from the packet file in which the message with the File Attached attribute is contained. See also 3.12.1. A message with the File Attached attribute set may contain a message body. Normally a message with the File Attached attribute set must be sent directly to the destination system since ftn systems usually are not set up for the routing of non-mail files. 3.7.4. Reserved This attribute bit is reserved for future use. It should not be checked by a programme receiving a type 2 packet. 3.7.5. File Request When this attribute is set it is supposed that one or more files are FIDONEWS 16-13 Page 10 29 Mar 1999 requested from the desination system of to the message. See also 3.12.1. A message with the File Request attribute set may contain a message body. Normally a message with the File Request attribute set must be sent directly to the destination system since ftn systems usually are not set up for the routing of non-mail files. 3.7.6. Return Receipt Request When this attribute is set it is assumed that the sender of the message requests a return receipt. A Return Receipt in this connection means a receipt from the final destination system that the message has arrived there. It is left to each implementation what steps to take when a message with the Return Receipt Request attribute bit is received. 3.7.7. Is Return Receipt When this attribute is set it is assumed that the message in question is a return receipt. It is left to each implementation what steps to take when a message with the Is Return Receipt attribute bit is received. 3.7.8. Is Audit Request When this attribute is set it is assumed that the sender of the message requests audit receipts. An Atuidt Receipt in this connection means a receipt from each of the systems transporting the message in question on its way to the final destination that the message has passed there. It is left to each implementation what steps to take when a message with the Is Audit Request attribute bit is received. 3.7.9. File Update Request When this attribute is set it is supposed that a file update is requested from the desination system of to the message. See also 3.12.1. A message with the File Update Request attribute set may contain a message body. Normally a message with the File Update Request attribute set must be sent directly to the destination system since ftn systems usually are not set up for the routing of non-mail files. 3.7.10. Attribute bits 2-3, 5-9 Any programme creating a packet may set bits 2-3 and 5-9 in the message attribute field to 0. They should not be checked by a programme receiving a type 2 packet. These attribute bits are normally only used for information interchange between different programmes on the system where the message in question is created. 3.8. Cost This field is filled with the 16-bit binary unsigned integer 0 by the system creating the packet. Any system receiving the packet may ignore FIDONEWS 16-13 Page 11 29 Mar 1999 the value of this field. For historical reasons this field is called Cost. See note 2. 3.9. Date and Time This field is filled with a -terminated ASCII character string representing the date and the time when the message in question was created. The string has the following format DD " " Month " " YY " " " " HH ":" MM ":" SS where DD = "01" | "02" | "03" | ... | "31" Month = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" | "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec" YY = "01" | "02" | .. | "85" | "86" | ... | "99" | "00" HH = "00" | .. | "23" MM = "00" | .. | "59" SS = "00" | .. | "59" The representation of the year contains the two last digits of the year in question. E.g. the year 1999 is represented as "99" and the year 2000 as "00". Considering the time when packet type 2 was first put into use, values "80".."99" is assumed to represent 1980..1999 and values "00".."79" is assumed to represent 2000..2079. The length of the string is 20 characters including the termination. See note 3. 3.10. To-name This variable length field is filled with the -terminated character string representing the name of the addressee of the message in question. In the case the programme creating the packet does not want to put any actual name there, the field should be filled with a single character. The maximum length of the string is 36 characters including the termination. E.g. the name Jim Brown is represented as "Jim Brown". The character set used in this field is the same as given in the message body (see a separate document). If no character set is given there, the ASCII character set is used. Character codes 1..31 may not be used within this field. 3.11. From-name This variable length field is filled with the -terminated character string representing the name of the sender of the message in question. In the case the programme creating the packet does not want FIDONEWS 16-13 Page 12 29 Mar 1999 to put any actual name there, the field should be filled with a single character. The maximum length of the string is 36 characters including the termination. E.g. the name Jim Brown is represented as "Jim Brown". The character set used in this field is the same as given in the message body (see a separate document). If no character set is given there, the ASCII character set is used. Character codes 1..31 may not be used within this field. 3.12. Subject This variable length field is filled with the -terminated character string representing the subject of the message in question. In the case the programme creating the packet does not want to put any actual subject there, the field should be filled with a single character. The maximum length of the string is 72 characters including the termination. E.g. the subject "FTS-0001" is represented as "FTS-0001". The character set used in this field is the same as given in the message body (see a separate document). If no character set is given there, the ASCII character set is used. Character codes 1..31 may not be used within this field. 3.12.1. File specifications When the attribute field has bit 4, 11 and/or 15 set, the message subject field normally is replaced by a list of file specifications containing the file names the system where the message was created (directory, path and time information etc are discarded). These file specifications are transmitted to the receiving system according to separate documents. It should be noted that if the message is accompanied by an attached file which is to be routed via other systems before reaching the ultimate destination system, it may be essential for the intermediate systems that the message is indeed transmitted even if it is empty. By doing so, the intermediate systems will have a way of finding out the intended destination of the attached file. It should also be noted that especially in the case of routed file attaches it is essential that file names are chosen so that they can be directly and easily handled under the same names by the respective host operating systems at the intermediate systems. 3.13. Message body This variable length field is filled with the -terminated character string representing the message text of the message in question. In the case the programme creating the packet does not want to put any actual text there, the field should be filled with a single character. The maximum length of the string is unlimited. E.g. the text "FTS-0001" is represented as "FTS-0001". See note 7. FIDONEWS 16-13 Page 13 29 Mar 1999 The character set used in this field is the same as given in the message body (see a separate document). If no character set is given there, the ASCII character set is used. Character codes 2..9,11..12,14..31 may not be used within this field. Character code 141 may be used within this field irrespective of the character set used. Character code 1 may be used only for the purpose given below. Special considerations about certain character codes apply: 3.14. Character code 1, To include extra addressing and control information, the message body may contain so called kludges. Each kludge is contained within a separate paragraph of text as defined in 3.16. A paragraph containing a kludge may not contain any other message text. Each paragraph containing a kludge starts with character. The character must not appear in any other position of a paragraph. The general format of a paragraph containing a kludge is ": " where is some sort of value related to the kludge in question. If no such value is required for a certain kludge, the general format of a paragraph containing such a kludge is ":" Developers may introduce new kludges on an experimental basis as they see fit. Kludge tags which are documented in FTS documents must however not be used in any other way than according to those FTS documents. Kludge tags which are documented in FSP or FSC documents should not be used in any other way than according to those documents. Consequently each programme receiving a type 2 packet file should retain any unknown kludge verbatim and at an unchanged a position within the message body as possible. This is particularly essential for messages which are to be routed to another system. The ASCII character set is used in paragraphs containing kludges. This document describes three kludges: FMPT, TOPT and INTL. 3.14.1. FMPT The FMPT kludge is used to give information about the point number of the sender of a message if that point number is not 0. If the point number of the sender of a message is 0 that message should not contain any FMPT kludge. FIDONEWS 16-13 Page 14 29 Mar 1999 The format of a paragraph containing a FMPT kludge is "FMPT " where is the ASCII representation of the point number of the sender. The point number is an unsigned integer in the range 1-65535. See note 1. E.g. a message from point number 1 of a certain node contains the following FMPT kludge "FMPT 1" Note that the format of a paragraph containing a FMPT kludge deviates from the general format given above in that it does not contain any colon after the kludge tag. 3.14.2. TOPT The TOPT kludge is used to give information about the point number of the addressee of a message if that point number is not 0. If the point number of the addressee of a message is 0 that message should not contain any TOPT kludge. The format of a paragraph containing a TOPT kludge is "TOPT " where is the ASCII representation of the point number of the sender. The point number is an unsigned integer in the range 0-65535. See note 1. E.g. a message to point number 1 of a certain node contains the following TOPT kludge "TOPT 1" Note that the format of a paragraph containing a FMPT kludge deviates from the general format given above in that it does not contain any colon after the kludge tag. 3.14.3. INTL The INTL kludge is used to give information about the zone numbers of the sender and the addressee of a message. The format of a paragraph containing a INTL kludge is "INTL "" " where is the ASCII representation of the destination address and is the ASCII representation of the origin address of the message in question. These addresses is given on the form :/ where is the ASCII representation of the zone number, is the ASCII representation of the net number and is the ASCII representation of the node number. Any point number information is given in FMPT and TOPT kludges. FIDONEWS 16-13 Page 15 29 Mar 1999 E.g. a message from address 1:123/4.5 to 2:345/6.7 node contains the following INTL kludge "INTL 2:345/6 1:123/4" Note that the format of a paragraph containing a INTL kludge deviates from the general format given above in that it does not contain any colon after the kludge tag. INTL kludges are also often used even when both the originating and the destination systems are in the same zone. This gives both the originating system and the destination system as well as any intermediate routing systems unambiguous zone information even in a situation where one system may be active in a number of different zones. However, it is known that some programmes may route messages incorrectly if the INTL kludge is present in messages where both the originating and the destination systems are in the same zone. 3.15. Character code 10, Programmes creating packet files may put characters into the message body. These characters should be disregarded by any programmes displaying the message to a user. Instead text should be formatted according to local conditions such as user preferences and/or physical/logical constraints of display equipment. Use of characters in the message body is discouraged. However characters should not be removed from the message body of in-transit messages. 3.16. Character code 13, The character is used for the purpose of terminating paragraphs of text. Any programme displaying the message to a user should format the text accordingly. 3.17. Character code 141, soft- Programmes creating packet files may put soft- characters into the message body. These soft- characters are usually used to prescribe local formatting on the system where the message in question was created. These characters should be disregarded by any programmes displaying the message to a user. Use of soft- characters in the message body is discouraged. However soft- characters should not be removed from the message body of in-transit messages. In certain character sets, character code 141 may be used for a vital part of the character set. If it can be assumed that the message is written in such a character set, character code 141 may be used and displayed. 4. Packet file names The name of a packet file when transmitted to another system is of the form FIDONEWS 16-13 Page 16 29 Mar 1999 HHHHHHHH.PKT where HHHHHHHH is a string of 8 hexadecimal digits in the ASCII character set and .PKT is the literal ".PKT" also in the ASCII character set. The value for HHHHHHHH is chosen so as to minimize the risk of any system receiving several packet files with the same name before all the previously received files of that name have been processed. 5. Arcmail To minimize the storage requirements for packet files and the time and cost for their transmission from system to system, zero or more packet files may be aggregated into compressed archives (Arcmail bundles) using lossless compression programmes. This scheme is normally called Arcmail after the programme once produced by System Enhancement Associates. Such compression programmes are not specified by this standard but are generally available for a number of platforms. However, the availability of suitable decompression programmes on a certain system cannot be guaranteed. Therefore Arcmail should only be used after prior agreement between the operators of the two systems involved. When Arcmail bundles are to be used their file names when transmitted to another system is of the form HHHHHHHH.DDN where HHHHHHHH is a string of 8 hexadecimal digits in the ASCII character set and .DD is one of the following literals ".MO", ".TU", ".WE", ".TH", ".FR", ".SA", ".SU" in the ASCII character set and N is a the ASCII representation of decimal digit 0-9. See note 6. 7. Address interpretation Packet type 2 has been in use during a long period of time during which the number and the complexity of ftn networks have increased greatly. The addressing requirements during this period have increased. Some of these additional requirements have been met in packet type 2 by adding kludges as defined above. The following guidelines can be given for the interpretation of the ftn addresses of type 2 packet files: 1. The origin and destination zone numbers are given explicitly in the FIDONEWS 16-13 Page 17 29 Mar 1999 packet header if they are different from 0 and the packet is created by a programme that is known to put that information there. One such programme is QMail. 2. The origin net and node numbers are given explicitly in the packet header. 3. The destination net and node numbers are given explicitly in the packet header. 4. The origin and destination point numbers cannot be found in a type 2 packet. (For the case of Fakenets see section 8.) The following guidelines can be given for the interpretation of the ftn addresses of messages in type 2 packet files: 1. The origin and destination zone numbers are given explicitly in an INTL kludge in the message body if there is such a kludge. (For the case of Zone Gating see section 8.) 2. If there is no INTL kludge in the message body or there is an INTL kludge that is not conformant with this specification the missing zone numbers may be assumed to be equal to the originating zone number in the packet header if that information is available. (For the case of Zone Gating see section 8.) 3. If any zone number cannot be determined in steps 1 and 2 it may be assumed to be equal to the zone number of the main address of the own system. (For the case of Zone Gating see section 8.) 4. The origin net and node numbers are given explicitly in the message header. 5. The destination net and node numbers are given explicitly in the message header. (For the case of Zone Gating see section 8.) 6. The originating point number is given in the FMPT kludge in the message body if there is such a kludge. 7. If there is no FMPT kludge in the message body or there is a FMPT kludge that is not conformant with this specification the originating point number may be assumed to be 0. 8. The destination point number is given in the TOPT kludge in the message body if there is such a kludge. (For the case of Zone Gating see section 8.) 9. If there is no TOPT kludge in the message body or there is a TOPT kludge that is not conformant with this specification the destination point number may be assumed to be 0. (For the case of Zone Gating see section 8.) 8. Fakenets Some existing programmes have limited support for point addressing. In order to still allow for points when such programmes are in use, sometimes a system called Fakenets or Fakenet Addressing is used. The operator of a ftn node using Fakenets defines a special net number, not included in the general nodelist, for the points under that node. That ftn node itself assumes the role of host for that net, i.e. assumes the address /0. The point systems are then assigned node numbers within that Fakenet. These node numbers are usually equal to the point numbers which they have been assigned. There may or there may not be a zone number assigned to the Fakenet. If a zone number is FIDONEWS 16-13 Page 18 29 Mar 1999 assigned it usually is the zone number in which the ftn node itself is active. A ftn node operating a Fakenet should use programmes which do the readdressing of messages so that systems outside of the Fakenet need not be aware of the address allocations within the Fakenet. E.g. assume that node 1:234/5 operates a fakenet with net number 23450. Programmes at 1:234/5 are then expected to readdress any message to 1:234/5.1 to whatever node number that point system has within the fakenet (usually 1:23450/1). Likewise, programmes at 1:234/5 are expected to readdress any messages from 1:23450/1 to a destination outside the fakenet so that they appear to originate from 1:234/5.1 (providing that is the 4-dimensional point address which Fakenet node 1:23450/1 has). 9. Zone Gating When two zones cover different geographical areas such as two different continents the technical difficulties and costs of establishing direct communications between two systems, one in each of these zones, may be considered a problem. For that purpose there may by administrative decisions be appointed one or more zone gates for message traffic from one zone to the other. The zone gates are systems whose operators have taken on the task of collecting and transmitting message traffic from the own zone to the foreign zone. To allow for such zone gating the following addressing guidelines apply. The origin address and the final destination address is given with the help of INTL, FMPT och TOPT kludges in the message body. The message header contains the node and net numbers of the originating system and the node and network numbers of the zone gate. Notes Note 1 It may be noted that certain existing programmes may represent point, node, net and zone numbers as signed integers on the user interface level. E.g. node number 65535 may be represented as -1. Note 2 Big-endian byte order (also known as Intel byte order) is used for 16- bit binary integers. Each field containing a 16-bit binary integer is composed of two bytes O0 and O1: +----+----+ ! O0 ! O1 ! -----+----+ FIDONEWS 16-13 Page 19 29 Mar 1999 where O0 contains bits 0-7 and O1 bit 8-15 of the 16-bit binary integer. Bit 0 is the least significant bit and bit 15 is the most significant bit of the 16-bit binary integer. Note 3 It may be noted that this document does not contain any information about how to decide the time zone used in the fields for date and time in a packet. It is however expected that most programmes use the local system time in these fields. Note 4 It may be noted that certain existing programmes put additional restrictions on the range of valid zone numbers. E.g. the zone numbers may be restricted to 1-255 or 1-4095. Note 5 There are a number or programmes in current use which allow also non-ASCII characters to be entered into the packet level password. E.g. character codes 128-255. There is no way within the framework of this common ftn practice to tell what character set is used in this case. Therefore it is also not possible for a programme to implement a general case translation algorithm for such characters. Note 6 Certain existing programmes are known to produce Arcmail bundles with file names when transmitted where N may be an ASCII character in the range '0'..'9', 'A'..'F'. Certain other existing programmes are known to produce Arcmail bundles with file names when transmitted where N may be an ASCII character in the range '0'..'9', 'A'..'Z'. The capability of processing Arcmail bundles with such extended file names is not required by this specification and they should therefore only be used after prior agreement between the operators of the two systems involved. Note 7 This specification specifies the size of the message body as unlimited. For obvious reasons, each system has some maximum size for a message body and for a packet file. Furthermore the file transfer protocols specified for ftn sessions separately may also impose maximum sizes on files to be transferred from one ftn system to another. Finally some existing programmes/platforms may have their own limits as to the maximum size of a message and to the maximum size of a packet file. E.g. some computer architectures use segmented memory and then the developer of a certain existing programme may have chosen to see to it that each data structure fits within one such segment, e.g. 64 kilobytes. Other existing programmes may have internal limits to the size of the message body, e.g. 10 or 32 kilobytes. FIDONEWS 16-13 Page 20 29 Mar 1999 Procedures for splitting and recombining large messages are specified in other FTSC documents. ----------------------------------------------------------------- FIDONEWS 16-13 Page 21 29 Mar 1999 ================================================================= COLUMNS ================================================================= What's Not Happening: Tag-Teams .-- -- -- -- -- -- WHAT'S NOT HAPPENING -- -- -- -- -- --. | There isn't always something happening on Fidonet, but | | there's always something which isn't happening. This | | column is dedicated to the lost causes which make Fido | | what it isn't today. Published semi-occasionally... | `-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --' Tag-Teams Douglas Myers, 1:270/720 doug@mdtnbbs.com Occupying center ring in Fido's Circus of Lost Causes is Bob Morasvik's elaborate game of Tag. The objective is to find a game which is already being played, and then take over the game by declaring himself "it." The rank and file of Fidonet have countered this initiative by largely ignoring it. This demonstration of applied apathy seems to be prevailing despite loud "it-fits" cross-posted to multiple echoes by J. Kershaw, Defensive Coordinator for the Morasvik team. The game of Tag derives its name from the practice, mostly in Zone 1, of listing an echotag with the Elist Robot operated by Thom Lacosta as a prelude to distributing echomail throughout the zone. This elist is used by distribution systems (and anyone else interested) to identify the moderator of an echo and to help reduce the instance of duplicate echotags. Tag, the game, takes advantage of the fact that not all echotags are listed. Many echo areas are distributed by private arrangement with the nodes involved and don't need to be listed, and many more are listed, but not necessarily with Thom LaCosta's system. Thom's elist service is usually targeted by Tag players, though, because the North American Backbone uses this service. The game of Tag is played by searching for existing echoes which are either unlisted or listed elsewhere, and then listing the echotag with Thom's service, but naming oneself as moderator. The most common source of unlisted existing echoes is echoes which were previously listed, but where the moderator has failed to keep the listing current. Many moderators have found their echoes effectively "taken over" in this manner. In the past, Bob Morasvik has proven himself an adept player at this form of echo hijacking by such maneuvers as listing all of the Region 13 conferences, leaving the Region 13 coordinators the alternatives of either establishing new conferences or recognizing him as moderator of the existing conferences. In his latest attempt to retain top seed in the world of Tag FIDONEWS 16-13 Page 22 29 Mar 1999 players, Bob elisted ZCC-Public, an echo originating in Zone 2 but never elisted in Zone 1. After successfully listing the echo with Thom's robot, Bob attempted to control Zone 1 distribution of the echo on the basis that he was the elisted moderator. He's officially cut the echo from Z1B distribution, but John Souvestre (principle Z1B hub) simply distributes the Zone 2 echo. Bob's request to have his version of ZCC-Public carried on NAB distribution was denied on the basis that the tag is already in use by many of the hubs comprising the NAB. The net result is that Bob has been largely ignored. I'm not sure how this affects his standing as a Tag player, but Bob Morasvik is no longer "It," and heads the list of What's Not Happening on Fido. ----------------------------------------------------------------- FIDONEWS 16-13 Page 23 29 Mar 1999 ================================================================= NOTICES ================================================================= Future History 12 May 1999 12th Anniversary of Fido Operations in Zone 4; 10th Anniversary of the creation of FidoNet Zone 4. 14 - 16 May 1999 V. BBachCon in Bleichenbach, Germany. For further information see: www.bbachcon.de 24 Jul 1999 XIII Pan American Games [through 8 Aug 99]. 9 Jun 1999 Tenth Anniversary of the adoption of FidoNet Policy 4.07. 10 Sep 1999 10th anniversary of Zone 5 operations. 26 Oct 1999 Thirty years from release Abbey Road album by the Beatles. 31 Dec 1999 Hogmanay, Scotland. The New Year that can't be missed. 1 Jan 2000 The 20th Century, C.E., is still taking place thru 31 Dec. 1 Jun 2000 EXPO 2000 World Exposition in Hannover (Germany) opens. 15 Sep 2000 Sydney (Australia) Summer Olympiad opens. 21 Sep 2000 10 years of FidoNet in +7 (xUSSR) 1 Jan 2001 This is the actual start of the new millennium, C.E. -- If YOU have something which you would like to see in this Future History, please send a note to the FidoNews Editor. ----------------------------------------------------------------- FIDONEWS 16-13 Page 24 29 Mar 1999 ================================================================= FIDONET BY INTERNET ================================================================= This is a list of all FidoNet-related sites reported to the FidoNews Editor as of this issue; see the notice at the end. FidoNet: Homepage http://www.fidonet.org FidoNews http://www.fidonews.org [HTML] http://209.77.228.66/fidonews.html [ASCII] WWW sources http://travel.to/fidonet/ FTSC page http://www.ftsc.org/ Echomail [pending] General http://owls.com/~jerrys/fidonet.html http://www.nrgsys.com/orb/foti List servers: http://www.onelist.com/subscribe.cgi/fidonet-discussion ============ Zone 1: http://www.z1.fidonet.org Region 10: http://www.psnw.com/~net205/region10.html Region 11: http://oeonline.com/~garyg/region11/ Region 13: http://www.net264.org/r13.htm Net 264: http://www.net264.org/ Region 14: Net 282: http://www.rxn.com/~net282/ Region 17: http://www.nwstar.com/~region17/ Region 18: http://techshop.pdn.net/fido/ Region 19: http://members.home.net/hbh3/r19 Zone 1 Elist http://www.baltimoremd.com/elist/ Not sure where the following should be placed: http://www.angelfire.com/biz/snwvlly/fido.html ============ Zone 2: http://www.z2.fidonet.org ZEC2: Zone 2 Elist: http://www.fbone.ch/echolist/ Region 20: http://www.fidonet.pp.se (in Swedish) FIDONEWS 16-13 Page 25 29 Mar 1999 Region 23: http://www.fido.dk (in Danish) Region 24: http://www.swb.de/personal/flop/gatebau.html (German) Fido-IP: http://home.nrh.de/~lbehet/fido (English/German) Region 25: http://www.bsnet.co.uk/net2502/net/ Region 26: http://www.nemesis.ie REC 26: http://www.nrgsys.com/orb Region 27: http://telematique.org/ft/r27.htm Region 29: http://www.rtfm.be/fidonet/ (French) Region 30: http://www.fidonet.ch (German) Region 33: http://www.fidoitalia.net (Italian) Region 34: http://www.pobox.com/cnb/r34.htm (Spanish) REC34: http://pobox.com/~chr Region 36: http://www.geocities.com/SiliconValley/7207/ Region 38: http://public.st.carnet.hr/~blagi/bbs/adriam.html Region 41: http://www.fidonet.gr (Greek/English) Region 42: http://www.fido.cz Region 48: http://www.fidonet.org.pl Region 50: http://www.fido7.com/ (Russian) Net 5010: http://fido.tu-chel.ac.ru/ (Russian) Net 5015: http://www.fido.nnov.ru/ (Russian) Net 5030: http://kenga.ru/fido/ (Russian & English) Net 5073: http://people.weekend.ru/soa/ (Russian) ============ Zone 3: http://www.z3.fidonet.org ============ Zone 4: Region 90: http://visitweb.com/fidonet Net 903: http://www.playagrande.com/refugio Net 904: http://members.tripod.com/~net904 (Spanish) ============ Zone 5: http://www.eastcape.co.za/fidonet/index.htm ============ Zone 6: http://www.z6.fidonet.org FIDONEWS 16-13 Page 26 29 Mar 1999 Region 65: http://www.cfido.com/fidonet/cfidochina.html (Chinese) ============ Pages listed above are as submitted to the FidoNews Editor, and generally reflect Zone and Regional Web Page sites. If no Regional site is submitted, the first Network page from that Region is used in its place. Generally, Regional pages should list access points to all Networks within the Region. TCP/IP accessible node access information should be submitted to the FidoNews Editor for inclusion in their Region or Zone. -----------oOo------------- Fidonet Via Internet Hubs Node# | Operator | Facilities (*) | Speed | Basic Rate -----------+-------------------+----------------+-------+------------ 1:12/12 | Ken Wilson | FTP | T1 | $24mo. 1:13/25 | Jim Balcom | FTP | 56k | $20mo. 1:106/1 | Matt Bedynek | FTP,VMoT,UUE | 64k | $5/$15mo. 1:106/6018 | Lawrence Garvin | FTP,VMoT | 64k | $5/mo. 1:107/451 | Andy Knifel | FTP, VMoT, UUE | 33.6 | n/c 1:140/12 | Bob Seaborn | FTP | T1 | $5/$20 1:270/101 | George Peace | FTP | T1 | $30mo. 1:271/140 | Tom Barstow | UUE | T1 | n/c 1:275/1 | Joshua Ecklund | UUE | 28.8 | $10/yr. 1:280/169 | Brian Greenstreet | FTP | 33.6 | $2mo. 1:2401/305 | Peter Rocca | FTP,UUE | T1 | unkn 1:2424/10 | Alec Grynspan | FTP,UUE | T1 | n/c 1:2604/104 | Jim Mclaughlin | FTP,VMoT,UUE | 33.6 | $1mo. 1:2624/306 | D. Calafrancesco | VMoT | 33.6 | $15yr. 1:345/0 | Todd Cochrane | FTP | T1 | n/c 1:346/250 | Aran Spence | FTP,UUE | T1 | $10mo. 1:396/45 | Marc Lewis | UUE | 33.6 | $26/yr. 1:3651/9 | Jerry Gause | FTP,VMoT | 33.6 | $3/$6 1:396/1 | John Souvestre | FTP,VMoT | T1 | $15mo. 2:335/535 | Mario Mure | VMoT,UUE | 64k | n/c 2:254/175 | Alex Kemp | UUE | 56k | n/c 2:284/800 | Jeroen VanDeLeur | FTP,UUE | 64k | n/c 2:335/610 | Gino Lucrezi | UUE | 33.6 | n/c 2:469/84 | Max Masyutin | VMoT | 256k | n/c 2:2411/413 | Dennis Dittrich | UUE | 64k | n/c 2:2474/275 | Christian Emig | UUE | 64k | unkn 3:633/260 | Malcolm Miles | FTP | 33.6 | n/c 4:905/100 | Fabian Gervan | VMoT, UUE | ??? | n/c 5:7104/2 | Henk Wolsink | FTP | 28.8 | n/c -- * FTP = Internet File Transfer Protocol * VMoT = Virtual Mailer over Telnet (various) * UUE = uuencode<->email type transfers [I'm only cataloging transfer methods, eg, ftp, email, telnet. Specific programs using these protocols are no longer being listed. Contact the system operators for details of which programs they have available.] FIDONEWS 16-13 Page 27 29 Mar 1999 Compiled by C. Ingersoll, 1:2623/71, (609)814-1978, fbn@dandy.net Posted on the 1st of every month in FN_SYSOP, R13SYSOP and Fidonews. ----------------------------------------------------------------- FIDONEWS 16-13 Page 28 29 Mar 1999 ================================================================= FIDONEWS INFORMATION ================================================================= ------- FIDONEWS MASTHEAD AND CONTACT INFORMATION ------- Editor: Henk Wolsink Editors Emeriti: Tom Jennings, Thom Henderson, Dale Lovell, Vince Perriello, Tim Pozar, Sylvia Maxwell, Donald Tees, Christopher Baker, Zorch Frezberg "FidoNews Editor" FidoNet 5:5/23 BBS +27-41-581-5913, 2400/9600/V34 more addresses: Henk Wolsink -- 5:7104/2, hwolsink@catpe.alt.za (Postal Service mailing address) FidoNews Editor P.O. Box 12325 Port Elizabeth, 6006 South Africa ------------------------------------------------------ FidoNews is published weekly by and for the members of the FIDONET INTERNATIONAL AMATEUR ELECTRONIC MAIL system. It is a compilation of individual articles contributed by their authors or their authorized agents. The contribution of articles to this compilation does not diminish the rights of the authors. OPINIONS EXPRESSED in these articles ARE THOSE OF THE AUTHORS and not necessarily those of FidoNews and/or the Editor. Authors retain copyright on individual works; otherwise FidoNews is Copyright (C) 1999 Henk Wolsink. All rights reserved. Duplication and/or distribution permitted for noncommercial purposes only. For use in other circumstances, please contact the original authors, or the Editor. =*=*=*=*=*=*=*=*= OBTAINING COPIES: The most recent issue of FidoNews in electronic form may be obtained from the FidoNews Editor via manual download or file-request, or from various sites in FidoNet and the Internet. PRINTED COPIES may be obtained by sending SASE to the above postal address. File-request FIDONEWS for the current Issue. File-request FNEWS for the current month in one archive. Or file-request specific back Issue filenames in distribution format [FNEWSGnn.ZIP] for a particular Issue. Monthly Volumes are available as FNWSmmmy.ZIP where mmm = three letter month [JAN - DEC] and y = last digit of the current year [9], i.e., FNWSJAN9.ZIP for all the Issues from Jan 99. FIDONEWS 16-13 Page 29 29 Mar 1999 Annual volumes are available as FNEWSn.ZIP where n = the Volume number 1 - 16 for 1984 - 1999, respectively. Annual Volume archives range in size from 48K to 1.4M. INTERNET USERS: FidoNews is available via: http://www.fidonews.org ** http://www.fidonet.org/fidonews.htm ** ftp://ftp.fidonet.org/pub/fidonet/fidonews/ ftp://ftp.irvbbs.com/fidonews/ ftp://ftp.nwstar.com/Fidonet/Fidonews And in non-English formats via: ** http://www.hvc.ee/pats/fidonews (Estonian) http://www.fidonet.pp.se/sfnews (Swedish) ** LINK HAS NOT BEEN UPDATED *=*=* You may obtain an email subscription to FidoNews by sending email to: jbarchuk@worldnet.att.net with a Subject line of: subscribe fnews-edist and no message in the message body. To remove your name from the email distribution use a Subject line of: unsubscribe fnews-edist with no message to the same address above. * You may retrieve current and previous Issues of FidoNews via FTPMail by sending email to: ftpmail@fidonews.org with a Subject line of: help and FTPMail will immediately send a reply containing details and instructions. When you actually make a file request, FTPMail will respond in three stages. You find a link for this process on www.fidonews.org. *=*=* You can read the current FidoNews Issue in HTML format at: http://www.fidonews.org and http://www.fidonet.dynip.com/public/fidonews/default.htm and in the FIDONEWS echo. FIDONEWS 16-13 Page 30 29 Mar 1999 STAR SOURCE for ALL Past Issues via FTP and file-request - Available for FReq from 1:396/1 or by anonymous FTP from: ftp://ftp.sstar.com/fidonet/fnews/ Each yearly archive also contains a listing of the Table-of-Contents for that year's issues. The total set is currently about 13 Megs. =*=*=*= The current week's FidoNews are now also available almost immediately after publication on the FidoNews Editor homepage on the World Wide Web at: http://209.77.228.66/fidonews.html There are also links there to jim barchuk's HTML FidoNews source and to John Souvestre's FTP site for the archives. There is also an email link for sending in an article as message text. Drop on over. =*=*=*=*=*=*=*=*= SUBMISSIONS: You are encouraged to submit articles for publication in FidoNews. Article submission requirements are contained in the file ARTSPEC.DOC, available from the FidoNews Editor, or file-requestable from 5:5/23 [5:7104/2] as file "ARTSPEC.DOC". ALL Zone Coordinators should have copies of ARTSPEC.DOC. Please read it. "Fido", "FidoNet" and the dog-with-diskette are U.S. registered trademarks of Tom Jennings, P.O. Box 410923, San Francisco, CA 94141, and are used with permission. "Disagreement is actually necessary, or we'd all have to get in fights or something to amuse ourselves and create the requisite chaos." -Tom Jennings -----------------------------------------------------------------