User Flags - Intents and Usage David Dodell, FidoNet International Coordinator, 1:114/15 Rick Moore, Chairperson, FidoNet Technical Standards, 1:115/333 Definition Of The USER FLAG ============================ The new FidoNet Technical Standards Committee publication, FSC- 0005, regarding the specification of the form and content of a FidoNet Nodelist added a new flag to the "flags" field. This flag was called the USER FLAG and was rather vague as to the intended purpose and application of the USER FLAG. It was defined as "Ux....x" wherein the x....x portion was representative of up to 32 alphanumeric characters and containing no space (ASCII decimal 32) characters. Additionally, if present, the USER FLAG must be the last item on the nodelist entry line. The Problem =========== One alarming possibility of the USER FLAG is that should all 5600 FidoNet nodes (the size of the FidoNet nodelist when USER FLAGS were first mentioned) decide to add 33 characters to their nodelist entries, then the distribution nodelist would grow by 180K overnight and that no real benefit to the net would be obtained from that growth. If we assume that the typical FidoNet Node has a 2400 baud modem, then the combined additional telephone time to transfer just the USER FLAGS portion of that week's NODEDIFF file would amount to over 1200 HOURS. Assuming that 10% of the NODEDIFF files are sent via toll calls, then 120 hours of long distance calls would be added to the normal (over)load. If a typical minute of toll call is $.20 (intrastate rates), then it would cost FidoNet participants about $1400 ADDITIONAL to distribute it. If hard disk storage costs $12.50/Megabyte, the cumulative storage costs on all of the 5600 nodes would amount to $12,600 of disk capacity. With no attempt at SOME standardization of the content, there is not much possibility of gaining any real benefits from the USER FLAG. Some Clarifications from FidoNet Administration =============================================== Due to confusion and lack of guidelines as to the purposes intended for application of the USER FLAG, the use of that flag was temporarily suspended until some clarification was available. The following guidelines regarding the new FidoNet Nodelist USER FLAG were developed jointly by the International Coordinator and the Chairman of the FTSC. General Intent of the USER FLAGS ================================ The nodelist is a list for the functional uses of fidonet mailers, it is not a BBS listing. Also the U flag was not intended as a replacement field for flags that were removed from the nodelist, i.e. "RE" which defines a BBS user limitation, does not belong in the nodelist, or in the U flag. The same goes for restricted hours, etc. A mailer only needs to know if a node is in ZMH mode, or CM mode. It doesn't care if a system comes up a 6 p.m. and goes down a 6 a.m. to be able to deliver mail. Some Specific Comments Regarding USER FLAGS =========================================== (1) The suggested uses from the *C structure need to be just that... not rigid specifications, but guidelines. (2) Anything after the U flag should be of a technical or administrative nature. Experimentation of new software functions using this flag should be encouraged. (3) Advertisement is strictly prohibited. (4) Mention of specific software is prohibited. It is not for the use of advertising the specific software you are running, or the size of your hard drive. (5) It should not be used for denoting alternative addresses, either in FidoNet or any other network. (6) The flag should be used to minimize duplicate listings in the nodelist, i.e. a node that has UNEC does not need a separate listing in his network. Since use of a USER FLAG for an NEC or an REC could serve to reduce the bulk of the nodelist, this use of the User Flag is the preferred method of denoting a *EC in the nodelist. (7) Any information found in the U flag should not duplicate information already found in that listing, or can be found any place else in the nodelist (i.e. A couple of nets had after the xxx/0 listing UNC). (8) It is not a total free form field for anything to appear. (9) The *C structure has the ultimate responsibility for what appears in the nodelist, including the USER FLAG. (10) By standardizing certain USER FLAGS, it may then be possible for software developers to put the USER FLAGS to some beneficial uses. A Standard (Defined) Set of Available USER FLAGS ================================================ The USER FLAGS which seem to offer the greatest possibilities for real benefit to the general network are: Established Software Distributors ================================= USDS for Software Distribution System nodes USDN for Shareware Distribution Network nodes UTDN for TBBS Distribution Network EchoMail Coordinators ===================== UNEC for Net Echo Coords UREC for Regional Echo Coords UZEC for Zone Echo Coords - Allows those both in and outside the net to scan the nodelist for Addressing information regarding EchoMail help. Assuming mailers can be made to use this information as well, some of the parts of a standard Zone:Net/Node address could be obtained from the *EC's location in the nodelist, or his "real" address could simply be substituted when outbound dialing is required. UPCP:x...x ========== - Potentially allows mailer software to glean PCP routing and dialing data from a USER FLAG. Example: UPCP:NJNEW UHUB ==== - Note that there are TWO kinds of hubs..... - Some HUBs are like mini-NC's since they do inbound mail routing and/or maintain a nodelist segment for the NC. They usually distribute the NODEDIFF and FNEWS files, as well. - The other type of hubs are only set up to pass along the NODEDIFF and FNEWS files, do not do any mail routing nor do they maintain any nodelist segments - The FIRST type of hub listed above NEEDS a separate (duplicate) nodelist entry, since it does mail routing service. The nodes which he serves are to be listed below his entry and before the next HUB (or end of the local net's segment) in the nodelist. His primary nodelist entry is also listed as "under" his HUB entry. His primary address should be set and the HUB address is set as his AKA address. The first kind of HUB does NOT get a UHUB flag. - The SECOND type of hub listed above DOES get a UHUB flag and the nodes to which he forwards the routine files should still be listed between his listing and the next hub (or end of the net segment) so that those nodes will know who to contact should there develop a problem with receipt of the files. This type of hub does NOT have an AKA address. UPNx..x ======= - This flag denotes the Host of a Private Net. - Only those Private Net Numbers assigned by the Zone Coordinator, or by his designate, should be used in this flag. - Don't use this flag unless there is a GOOD reason. There are many reasons, including the potential to become an unwitting "OutBound HOST" for the world, to not advertise too openly your private net host status. Suggested Implementation Method =============================== As always, the front line of the nodelist is the Net Coordinator. The Net Coordinators will make most of the USER FLAG assignments. The NC is authorized to employ any applicable USER FLAGS from the "defined set". If more than one USER FLAG is appropriate for a given node, they may be all placed in a single USER FLAG and separated by a comma. There is no implied order of precedence of one flag over another. Example - suppose a node is an NEC and is also an SDS node and is a nodediff and FNEWS distributor as well. His USER FLAG could look like one of these: USDS,NEC,HUB - or - UHUB,SDS,NEC - or - UNEC,HUB,SDS Non-Standard USER FLAGS ======================= There will be times when, for software development work, that one or more nodes may need a non-standard USER FLAG. Such flags SHOULD be allowed, as it is a goal of FidoNet to encourage the development of new and better telecommunications software. The Local Net Coordinator is authorized to assign such non- standard flags, provided they are not for trivial purposes. "Trivial purposes" include, but are not limited to, "vanity" listings, advertisements, and listing of baud rates not supported by the nodelist processors. The rest of the *C structure may from time to time examine non- standard flags and occasionally may request clarification of them from the NC. Since non-standardized USER FLAGS are intended for development and experimentation purposes, it expected that most of them will either eventually become a part of the standard set or else will disappear when the experimentation period is completed. Modifications to the Defined Set of USER FLAGS ============================================== The International Coordinator, or his designate, may add or remove USER FLAGS from the standard defined set as is deemed necessary. When a developer has successfully completed his experimentation and has implemented a useful USER FLAG, he should advise the IC, or his designate, that a new USER FLAG is available for general application by others. Upon satisfaction of purpose, it may then be added to the standard set of defined USER FLAGS.