| Document: FSC-0062 | Version: 003 | Date: April 14, 1996 | Author: David J. Thomas A Proposed Nodelist flag indicating Online Times of a Node David J. Thomas 2:442/600@fidonet.org 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 marks of Tom Jennings and Fido Software. Note ---- Changes in content between the previous edition of this document, and this edition, are signified by bars (|) in the left margin, except where otherwise specified. I have changed the format of the document slightly to allow this. Where the format of the document has changed, but the actual text has not, bars are not present. Purpose ------- There are currently several systems within FidoNet that offer file request or mail holding capabilities but are not continuously online. The only time during which these nodes can be contacted with reference to the nodelist is currently the Zone Mail Hour of the zone to which the systems belong. In theory, mailers can only use the zone mail hour(s) specified by the system in question to contact these nodes, which does not provide for any method of file requesting or calling for echomail that does not conflict with the Policy requirement that no echomail or files be transferred during the zone mail hour. This means that, in practice, if it is known that a particular node is online for more time than ZMH alone, but less than 24 hours a day, it is necessary to "kludge," or set this up as a special situation, in most mailers whenever a node has to be contacted a number of times, whether regularly or irregularly. The proposed flag would benefit the mailers in such a way as to provide for them the online times that the node is usually online for, thus cutting on the costs of calling a non-continuous mail node, only to find that it is not available; and also, hopefully preventing annoyance for a sysop whose mailer is being called whilst it is not online, for example in the case of a voice/data shared line. Compatibility ------------- Since the current nodelist format is always being extended and nodelist processors look only for the flags that they know about, there are no expected compatibility problems with the suggestion outlined below. Format of additional nodelist flag ---------------------------------- The proposed nodelist flag has the following form: Txy where x represents the startup time, and y the end time, in the following format: +------+----+ +------+----+ +------+----+ +------+----+ +------+----+ |Letter|Time| |Letter|Time| |Letter|Time| |Letter|Time| |Letter|Time| +------+----+ +------+----+ +------+----+ +------+----+ +------+----+ | A |0000| | F |0500| | K |1000| | P |1500| | U |2000| | a |0030| | f |0530| | k |1030| | p |1530| | u |2030| | B |0100| | G |0600| | L |1100| | Q |1600| | V |2100| | b |0130| | g |0630| | l |1130| | q |1630| | v |2130| | C |0200| | H |0700| | M |1200| | R |1700| | W |2200| | c |0230| | h |0730| | m |1230| | r |1730| | w |2230| | D |0300| | I |0800| | N |1300| | S |1800| | X |2300| | d |0330| | i |0830| | n |1330| | s |1830| | x |2330| | E |0400| | J |0900| | O |1400| | T |1900| | | | | e |0430| | j |0930| | o |1430| | t |1930| | | | +------+----+ +------+----+ +------+----+ +------+----+ +------+----+ | This flag is not intended to be a user flag. The flag is intended to provide | information to computerised mailer processes, and is not easily read by | human beings (although they can of course interpret the meaning of the | flag); most mailers however do not attempt to interpret any information that | is specified as a user flag, assuming that it is there for the benefit of | human beings. Such mailers would not be able to make use of the information | provided, which is the purpose of the flag. | This flag is of course not specified in FTS-0005 at the time of writing, but | this is not regarded by FidoNet as a problem because other flags in current | use are not specified in FTS-0005. The case of the letter could be relevant. Whereas the case is currently not used by any flags in the document describing the current format of the nodelist, there exists the potential for the case of a letter to have relevant meaning. The case has to be correct for the CRC check calculation to prove correct, and this would be a good use for the case of the letter. If it is necessary to ignore the case, then the upper on-the-hour time should be used, i.e. the time that is listed after the upper-case letter. | These times are expressed in UTC so that the flag is useful for systems all around the world, without the need for specific time zone information to be included in the nodelist. They do not adjust with daylight saving time for a similar reason. Note the section on daylight saving time for information about handling adjustments without changing the flag; this is important. Where necessary, the times can wrap around midnight, so for example, for a | node that is online between the hours of 1800 and 0600 UTC, the flag TSG would be a valid indication of this time. This nodelist entry is not required by any node. It is supplementary to the #01, #02, #08, #09, #18, #20 flags and their !xx counterparts, though its meaning is different. It has been suggested to me about the possibility of an additional flag with the same meaning, but having a W as the first letter, indicating that the node is also available for all hours during weekends; however, I believe that the simple inclusion of the single flag indicated above will solve most problems, as it does indicate a period for non-CM nodes during which the node is available, which is all that is really required. Daylight saving time -------------------- If a node changes online times with respect to UTC when daylight saving time becomes effective (which would be the case with most part time nodes), then this is to be taken into account when assigning this flag. An online times flag assigned to a node should not be altered for the specific purpose of adjusting due to daylight saving time, since large difference files (NODEDIFF's) would result if every node was allowed to do this, e.g. my node used to be online from 2300 to 0800 in local time, which in winter | is UTC, but in the summer it becomes BST (British Summer Time). This is one | hour ahead of UTC, and the corresponding availability times of my node | during the summer period were 2200 to 0700 UTC. Therefore my online times flag would have indicated availability between the hours of 2300 and 0700 | UTC, the daily time period encompassing both times, so the flag would be TXH. Policy considerations --------------------- This is a technical document. However, since the flag could make for an increase in the size of difference files, the author feels that the following guidelines should be adopted concerning the use of the flag. The online times flag does not replace the requirement for exclusivity of zone mail hour to be maintained. It is still annoying behaviour to have this flag and be unavailable during ZMH, just as it is annoying behaviour to have the CM (continuous mail) flag in one's entry, and disregard ZMH. Except for during ZMH, the sysop of a node using this flag finding that they need to take their mailer offline during the specified times to perform system maintenance, or for any other reason, would not be acting in an annoying manner to do so, unless the practice is found to be continuous, in which case the flag's times could be reduced, or the flag itself could be removed from their node entry. It should be noted that this flag is present for the benefit of mailers, not human beings. This means that the flag should be used only to indicate when a mailer is ready to receive calls. A system that uses a FidoNet- technology mailer in ZMH, and a human-access only system during other period(s) of the day that cannot receive mail, should not use this flag. This flag does not explicitly specify online times of a public access BBS, although for presumably most nodes with FidoNet-capable software, a public access BBS will be available during the times indicated. Where the flag is used, it should not often be changed. If a situation exists, for example, where a node uses a certain set of times during the first two weeks of a month, and a different set of times during the remainder period, the flag should be set to a time during each day of the month when the node is online. For example, if a node is online during 1800-0800 for the first two weeks, and then during 2200-1000 for the remainder, the time flag should specify 2200-0800 only. If there is no such time (other than ZMH) then no flag should be used. Of course, any permanent changes, and any necessary reductions in the times, should be permitted at any time, but changes owing only to daylight saving time should certainly be expressly forbidden. File requests and user access are of course permitted during the online times indicated (except ZMH). The above list may seem rather frightening! Please note that they are guidelines rather than rules, unless FidoNet policy has included them as rules. In the vast majority of situations where a node is online for a fixed set of hours per day, the only thing to watch out for is that you get the daylight saving time period right. Then you don't have to worry about changing it at any time, except when your own online times change. Example ------- With regard to time zones now; this is a complicated topic, so I wish to express an example. Imagine a node in Indiana, USA. It is online for the time period beginning 6 o'clock pm (1800) and ending 8 o'clock am (0800). This changes with daylight saving time, so the times expressed effectively | become an hour earlier with respect to UTC during daylight saving time. | Indiana is in the Central time zone, which is 6 hours behind UTC. Therefore, | the online times in UTC can be expressed as 0000-1400 UTC during winter. | During daylight saving time, however, the local time for Indiana is 5 hours | behind UTC. The online times during this period are 0100-1500 UTC. The | subset should be used, so that the online times flag for the node should | indicate availability between 0100 and 1400 UTC, which is indicated | by the flag TBO. | (Thanks to a few people for pointing out that the previous example was in | error; it assumed that Indiana was ahead of UTC, and not behind as is | actually the case.) ANSI C routines to Calculate the Online Times Flag -------------------------------------------------- These were not provided in the first edition. Change bars will not be used here, since they would interfere with the syntax of the presented routines. The first program calculates the online times flag from the user's entry of the online times of a system, expressed in the local time zone, and the offset to UTC used by the user's country. It takes into account that the clock is put forward and back once a year by reducing the end time by one hour. The program should work on any platform, and has been tested. === start of code === /* TIMEFLAG.C Calculates FSC-0062 time flag requirement from user input */ #include char *onlineflag(char *on, char *off, int utc_diff); void main() { char on[6], off[6]; int utc_diff; printf("\nPlease specify the time you come online [HH:MM]: "); scanf("%s", on); printf("\nPlease specify the time you come offline [HH:MM]: "); scanf("%s", off); printf("\nSpecify the difference between your local time zone in winter\n" "time and UTC (e.g. if your time zone is 6 hours behind UTC,\n" "enter 6): "); scanf("%d", &utc_diff); printf("\nYour online time flag is %s\n\n", onlineflag(on, off, utc_diff)); } char *onlineflag(char *ontime, char *offtime, int utcdiff) { int onhour, onmin, offhour, offmin; static char flag[4]="T "; sscanf(ontime, "%d:%d", &onhour, &onmin); sscanf(offtime, "%d:%d", &offhour, &offmin); if(onmin>30) ++onhour; --offhour; /* to correct for daylight saving time */ onhour = (onhour+24+utcdiff) % 24; offhour = (offhour+24+utcdiff) % 24; flag[1]='A'+onhour; flag[2]='A'+offhour; if(onmin>0 && onmin<31) flag[1] += 'a'-'A'; if(offmin>29) flag[2] += 'a'-'A'; return flag; } === end of code === The second program calculates the online times from the time flag, input as a pointer to char to the routine (this being of the format "Txy"). It returns a pointer to a structure which contains the on- and off-times in UTC. This is not a complete program; it is designed to be used by mailers to determine the valid online times. It has also been tested. === start of code === /* INTFLAG.C Interprets online time flags and converts them to a set of UTC times */ struct TIMES { int on_hour; int on_min; int off_hour; int off_min; }; struct TIMES *interpret_flag(char *time_flag); struct TIMES *interpret_flag(char *timeflag) { static struct TIMES times; times.on_min=0; times.off_min=0; times.on_hour=timeflag[1]-'A'; if(times.on_hour>23) { times.on_hour -= 'a'-'A'; times.on_min=30; } times.off_hour=timeflag[2]-'A'; if(times.off_hour>23) { times.off_hour -= 'a'-'A'; times.off_min=30; } return × } === end of code === | The above routines can be copied and re-used as desired. I am now an | amazing C programmer, but I still make no guarantees about them! :-) Summary ------- I believe this to be a neat and compact solution to, what is in my opinion, one of the gravest problems currently facing FidoNet. In FidoNet, most nodes are continuous mail, but it is important for the growth and popularity of FidoNet that non-CM nodes do not receive many mailer calls at times when they are off line. Users are bad enough in this respect. It is also useful for people wishing to contact hubs that are non-CM with mail for a downlink, and for people wishing to file request from a node that is not CM. There is no need for systems that are only online in zone mail hour to adopt this flag; also, there is no need for CM systems to adopt this flag. Contacting the Author --------------------- My board is now online continuously, except for periods of down time during | which the board is maintained (few and far between now that Linux is used). Netmail contact is therefore possible at any time. I went CM because of a certain number of nodes calling at the wrong times, and also users. Users weren't too bad, but I dislike 0600 am wake-up calls, repeated at regular three-minute intervals for an hour, by mailers, rather intensely :-) End of document.