For those who have a connection to the Internet, but cannot FTP, there do exist a few alternatives to get those files you so desperately need. When requesting files, it's imperative that you keep in mind the size of your request_ odds are the other people who may be using your link won't be too receptive to sudden bursts of really heavy traffic on their normally sedate connection.
An alternative to the currently well over-used FTPmail system is taking advantage of the many archive servers that are presently being maintained. These are programs that receive email messages that contain commands, and act on them. For example, sending an archive server the command help will usually yield, in the form of a piece of email, information on how to use the various commands that the server has available.
One such archive server is service@nic.ddn.mil. Maintained by the Network Information Center (NIC) in Chantilly, VA, the server is set up to make all of the information at the NIC available for people who don't have access to FTP. This also includes the WHOIS service (see Chapter 6.4.1 [Whois]. Some sample Subject: lines for queries to the NIC server are:
Subject: help Describes available commands.
Subject: rfc 822 Sends a copy of RFC-822.
Subject: rfc index Sends an index of the available RFCs.
Subject: netinfo domain-template.txt Sends a domain application.
Subject: whois widener Sends WHOIS information on widener
More information on using their archive server can be obtained by writing
to their server address service@nic.ddn.mil with a Subject: of help.
There are different "brands" of archive server, each with its own set of commands and services. Among them there often exists a common set of commands and services (e.g. index, help, etc). Be that as it may, one should always consult the individual help for a specific server before assuming the syntax_100K surprises can be hard on a system.
Some systems offer people the ability to receive files through a mock-FTP interface via email. See Chapter 3.2.2 [Anonymous FTP], for a general overview of how to FTP. The effects of providing such a service varies, although a rule of thumb is that it will probably use a substantial amount of the available resources on a system.
The "original" FTP-by-Mail service, BITFTP, is available to BITNET users from the Princeton node PUCC. It was once accessible to anyone, but had to be closed out to non-BITNET users because of the heavy load on the system.
In response to this closure, Paul Vixie designed and installed a system called FTPmail on one of Digital's gateway computers, decwrl.dec.com. Write to ftpmail@decwrl.dec.com with help in the body of the letter for instructions on its use. The software is undergoing constant development; once it reaches a stable state, other sites will be encouraged to adopt it and provide the service also.
Everyone has the opportunity to make a Call For Votes on the Usenet and attempt to create a newsgroup that he/she feels would be of benefit to the general readership. The rules governing newsgroup creation have evolved over the years into a generally accepted method. They only govern the "world" groups; they aren't applicable to regional or other alternative hierarchies.
A discussion must first take place to address issues like the naming of the group, where in the group tree it should go (e.g. rec.sports.koosh vs rec.games.koosh?), and whether or not it should be created in the first place. The formal Request For Discussion (RFD) should be posted to news.announce.newgroups, along with any other groups or mailing lists at all related to the proposed topic. news.announce.newgroups is moder- ated. You should place it first in the Newsgroups: header, so that it will get mailed to the moderator only. The article won't be immediately posted to the other newsgroups listed; rather, it will give you the opportunity to have the moderator correct any inconsistencies or mistakes in your RFD. He or she will take care of posting it to the newsgroups you indicated. Also the Followup-To: header will be set so that the actual discussion takes place only in news.groups. If a user has difficulty posting to a moderated group, he or she may mail submissions intended for news.announce.newgroups to the address announce-newgroups@rpi.edu.
The final name and charter of the group, and whether it will be moderated or unmoderated, will be determined during the discussion period. If it's to be moderated, the discussion will also decide who the moderator will be. If there's no general agreement on these points among those in favor of a new group at the end of 30 days, the discussion will be taken into mail rather than continued posting to news.groups; that way, the proponents of the group can iron out their differences and come back with a proper proposal, and make a new Request For Discussion.
After the discussion period (which is mandatory), if it's been determined that a new group really is desired, a name and charter are agreed upon, and it's been determined whether the group will be moderated (and by whom), a Call For Votes (CFV) should be posted to news.announce.newgroups, along with any other groups that the original Request For Discussion was posted to. The CFV should be posted (or mailed to the news.announce.newgroups moderator) as soon as possible after the discussion ends (to keep it fresh in everyone's mind).
The Call for Votes should include clear instructions on how to cast a vote. It's important that it be clearly explained how to both vote for and against a group (and be of equivalent difficulty or ease). If it's easier for you or your administrator, two separate addresses can be used to mail yes and no votes to, providing that they're on the same machine. Regardless of the method, everyone must have a very specific idea of how to get his/her vote counted.
The voting period can last between 21 and 31 days, no matter what the preliminary results of the vote are. A vote can't be called off simply because 400 "no" votes have come in and only two "yes" votes. The Call for Votes should include the exact date that the voting period will end_only those votes arriving on the vote-taker's machine before this date can be counted.
To keep awareness high, the CFV can be repeated during the vote, pro- vided that it gives the same clear, unbiased instructions for casting a vote as the original; it also has to be the same proposal as was first posted. The char - ter can't change in mid-vote. Also, votes that're posted don't count_only those that were mailed to the vote-taker can be tallied.
Partial results should never be included; only a statement of the specific proposal, that a vote is in progress on it, and how to cast a vote. A mass acknowledgement ("Mass ACK" or "Vote ACK") is permitted; however, it must be presented in a way that gives no indication of which way a person voted. One way to avoid this is to create one large list of everyone who's voted, and sort it in alphabetical order. It should not be two sorted lists (of the yes and no votes, respectively).
Every vote is autonomous. The votes for or against one group can't be transferred to another, similar proposal. A vote can only count for the exact proposal that it was a response to. In particular, a vote for or against a newsgroup under one name can't be counted as a vote for or against another group with a different name or charter, a different moderated/unmoderated status, or, if it's moderated, a different moderator or set of moderators. Whew!
Finally, the vote has to be explicit; they should be of the form I vote for the group foo.bar as proposed or I vote against the group foo.bar as proposed The wording doesn't have to be exact, your inten- tion just has to be clear.
At the end of the voting period, the vote-taker has to post (to news.announce.newgroups) the tally and email addresses of the votes received. Again, it can also be posted to any of the groups listed in the original CFV. The tally should make clear which way a person voted, so the results can be verified if it proves necessary to do so.
After the vote result is posted to news.announce.newgroups, there is a mandatory five-day waiting period. This affords everyone the opportunity to correct any errors or inconsistencies in the voter list or the voting procedure ..
If, after the waiting period, there are no serious objections that might invalidate the vote, the vote is put to the "water test." If there were 100 more valid YES/create votes than NO/don't create votes, and at least two-thirds of the total number of votes are in favor of creation, then a newgroup control message can be sent out (often by the moderator of news.announce.newgroups). If the 100-vote margin or the two-thirds per- centage isn't met, the group has failed and can't be created.
If the proposal failed, all is not lost_after a six-month waiting period (a "cooling down"), a new Request For Discussion can be posted to news.groups, and the whole process can start over again. If after a couple of tries it becomes obvious that the group is not wanted or needed, the vote- taker should humbly step back and accept the opinion of the majority. (As life goes, so goes Usenet.)