For your newsgroups file:

dfw.maps
UUCP mapping project in Dallas/Ft Worth, TX (Moderated)


CHARTER

Area of Coverage of dfw.maps

dfw.maps exists solely for the posting of maps for the UUCP mapping project.

All articles will be evaluated against the required posting format listed below. Any map not conforming will be returned to the sender for updates.

Any article that is not a UUCP mapping project format map will be returned to the sender, with a copy provided to the senders ISP, and the senders USENET news posting service.

Posting format for dfw.maps

The remainder of this file describes the format of the UUCP map data. It was written July 9, 1985 by Erik E. Fair , and last updated May 24, 1995 by Stan Barber .

The entire map is intended to be processed by pathalias, a program that generates UUCP routes from this data. All lines beginning in `#' are comment lines to pathalias, however the UUCP Mapping Project has defined a set of these comment lines to have specific format so that a complete database could be built.

The generic form of these lines is

    #<field id letter><tab><field data>

Each host has an entry in the following format. The entry should begin with the #N line, end with a blank line after the pathalias data, and not contain any other blank lines, since there are ed, sed, and awk scripts that use expressions like /^#N $1/,/^$/ for the purpose of separating the map out into files, each containing one site entry.

#N	UUCP name of site
#S	manufacturer machine model; operating system & version
#O	organization name
#C	contact person's name
#E	contact person's electronic mail address
#T	contact person's telephone number
#P	organization's address
#L	latitude / longitude
#R	remarks
#U	netnews neighbors
#W	who last edited the entry ; date edited
#
sitename	.domain
sitename	remote1(FREQUENCY), remote2(FREQUENCY),
	    remote3(FREQUENCY)

Example of a completed entry:

#N	academ,academ.houston.tx.us,academ.com
#S	Victor 486/50; BSDOS 1.1
#O	Academ Consulting Services
#C	Stan Barber
#E	sob@academ.com
#T	+1 713 790 9553
#P	P.O. Box 300481, Houston, Texas USA 77230-0481
#L	29 42 N / 95 23 W city
#U	news.sesqui.net cs.utexas.edu news.usis.com bcm
#W	academ!sob (Stan Barber); Fri May 12 19:26:27 CDT 1995
#R	academ is the primary uucp gateway for Academ Consulting Services

academ=academ.houston.tx.us
academ  .academ.com(LOCAL)
academ  nuchat(DIRECT),uhnix1(DIRECT),cyberlaw(POLLED)

Specific Field Descriptions

#N	system name

Your system's UUCP name should go here. Either the uname(1) command from System III or System V UNIX; or the uuname(1) command from Version 7 or BSD UNIX will tell you what UUCP is using for the local UUCP name.

One of the goals of the UUCP Project is to keep duplicate UUCP host names from appearing because there exist mailers in the world which assume that the UUCP name space contains no duplicates (and attempts UUCP path optimization on that basis), and it's just plain confusing to have two different sites with the same name.

At present, the most severe restriction on UUCP names is that the name must be unique somewhere in the first six characters, because of a poor software design decision made by AT&T for the System V release of UNIX.

This does not mean that your site name has to be six characters or less in length. Just unique within that length.

The UUCP Mapping Project does not accept hostnames that contain uppercase letters, or any punctuation other than dash or period. Periods may only be used if the site name is a fully qualified domain name in a domain registered with InterNIC Registration Services for the Internet.

Domains may be listed as well by putting a leading period. If you are listing both a domain and a uucp name, please put the uucpname FIRST in the list and the domain last.

With regard to choosing system names, HARRIS'S LAMENT:

``All the good ones are taken.''

#S	machine type; operating system

This is a quick description of your equipment. Machine type should be manufacturer and model, and after a semi-colon(;), the operating system name and version number (if you have it). Some examples:

DEC PDP-11/70; 2.9 BSD UNIX
DEC PDP-11/45; ULTRIX-11
DEC VAX-11/780; VMS 4.0
SUN 2/150; 4.2 BSD UNIX
Pyramid 90x; OSx 2.1
CoData 3300; Version 7 UniPlus+
Callan Unistar 200; System V UniPlus+
IBM PC/XT; Coherent
Intel 386; XENIX 3.0
CRDS Universe 68; UNOS

#O	organization name

This should be the full name of your organization, squeezed to fit inside 80 columns as necessary. Don't be afraid to abbreviate where the abbreviation would be clear to the entire world (say a famous institution like MIT or CERN), but beware of duplication (In USC the C could be either California or Carolina).

#C	contact person

This should be the full name (or names, separated by commas) of the person responsible for handling queries from the outside world about your machine.

#E	contact person's electronic address

This should be just a machine name, and a user name, like `academ!sob'. It should not be a full path, since we will be able to generate a path to the given address from the data you're giving us. There is no problem with the machine name not being the same as the #N field (i.e. the contact `lives' on another machine at your site).

Also, it's a good idea to give a generic address or alias (if your mail system is capable of providing aliases) like `usenet' or `postmaster', so that if the contact person leaves the institution or is re-assigned to other duties, he doesn't keep getting mail about the system. In a perfect world, people would send notice to the UUCP Mapping Project, but in practice, they don't, so the data does get out of date. If you give a generic address you can easily change it to point at the appropriate person.

Multiple electronic addresses should be separated by commas, and all of them should be specified in the manner described above.

#T	contact person's telephone number

Format: +

Example:

#T	+1 713 798 6042

This is the international format for the representation of phone numbers. The country code for the United States of America (and Canada) is 1. Other country codes should be listed in your telephone book.

If you must list an extension (i.e. what to ask the receptionist for, if not the name of the contact person), list it after the main phone number with an `x' in front of it to distinguish it from the rest of the phone number.

Example:

#T	+1 415 549 3854 x37

Multiple phone numbers should be separated by commas, and all of them should be completely specified as described above to prevent confusion (in particular, you should avoid the use of "-").

#P      organization's postal address

This field should be one line filled with whatever else anyone would need after the contact person's name, and your organization's name (given in other fields above), to mail you something by paper mail. Please try to include the three-letter ISO country code as part of the address.

#L      latitude and longitude

This should be in the following format:

#L	DD MM [SS] "N"|"S" / DDD MM [SS] "E"|"W" ["city"]

Two fields, with optional third.

First number is Latitude in degrees (DD), minutes (MM), and seconds (SS), and a N or S to indicate North or South of the Equator.

A Slash Separator.

Second number is Longitude in degrees (DDD), minutes (MM), and seconds (SS), and a E or W to indicate East or West of the Prime Meridian in Greenwich, England.

Seconds are optional, but it is worth noting that the more accurate you are, the more accurate maps we can make of the network (including blow-ups of various high density areas, like New Jersey, or the San Francisco Bay Area).

If you give the coordinates for your city (i.e. without fudging for where you are relative to that), add the word `city' at the end of the end of the specification, to indicate that. If you know where you are relative to a given coordinate for which you have longitude and latitude data, then the following fudge factors can be useful:

1 degree=69.2 miles=111 kilometers
1 minute=1.15 miles=1.86 kilometers
1 second=102 feet=30.9 meters

For LONGITUDE, multiply the above numbers by the cosine of your latitude. For instance, at latitude 35 degrees, a degree of longitude is 69.2*0.819 = 56.7 miles; at latitude 40 degrees, it is 69.2*0.766 = 53.0 miles. If you don't see why the measure of longitude depends on your latitude, just think of a globe, with all those N-S meridians of longitude converging on the poles. You don't do this cosine multiplication for LATITUDE.

Here is a short cosine table in case you don't have a trig calculator handy. (But you can always write a short program in C. The cosine function in bc(1) doesn't seem to work as documented.)

degcosdegcosdegcos degcosdegcosdegcos
01.00050.996100.985150.966200.940250.906
300.866350.819400.766450.707500.643550.574
600.500650.423700.342750.259800.174850.087

The Prime Meridian is through Greenwich, England, and longitudes run from 180 degrees West of Greenwich to 180 East. Latitudes run from 90 degrees North of the Equator to 90 degrees South.

#R      remarks

This is for one line of comment. As noted before, all lines beginning with a `#' character are comment lines, so if you need more than one line to tell us something about your site, do so between the end of the map data (the #?\t fields) and the pathalias data.

#U	netnews neighbors

The USENET is the network that moves netnews around, specifically, news.announce.important. If you send news.announce.important to any of your UUCP neighbors, list their names here, delimited by spaces.

Example:

#U	academ rice cs.utexas.edu

Since some places have lots of USENET neighbors, continuation lines should be just another #U and more site names.

#W      who last edited the entry and when

This field should contain an email address, a name in parentheses, followed by a semi-colon, and the output of the date program. Example:

#W	bcm!sob (Stan Barber); Mon Aug 27 22:21:10 CDT 1990

The same rules for email address that apply in the contact's email address apply here also. (i.e. only one system name, and user name). It is intended that this field be used for automatic aging of the map entries so that we can do more automated checking and updating of the entire map. See getdate(3) from the netnews source for other acceptable date formats.

PATHALIAS DATA

(or, documenting your UUCP connections & frequency of use)

The DEMAND, DAILY, etc., entries represent imaginary connect costs (see below) used by pathalias to calculate lowest cost paths. The cost breakdown is:

LOCAL25local area network
DEDICATED100high speed dedicated
DIRECT200local call
DEMAND300normal call (long distance, anytime)
HOURLY500hourly poll
EVENING2000time restricted call
DAILY5000daily poll
WEEKLY30000irregular poll
DEADa very high number - not usable path

NOTE: Please do not use DEAD in maps you send to the project. Just remove those sites from your map data. It generates much better maps.

Additionally, FAST, HIGH and LOW (used like DAILY+HIGH) are -80, -5 and +5 respectively, for baud-rate or quality bonuses/penalties, and FAST is -80 for adjusting links that use high-speed (i.e., 9600 bps or more) modems. Arithmetic expressions can be used; however, you should be aware that the results are often counter-intuitive (e.g. (DAILY*4) means every 4 days, not 4 times a day). This is because the numbers represent "cost of connection" rather than "frequency of connection", and reflect the ease with which your system can connect to another. For example, if a site cannot be called, it should be rated at a higher cost than one that can be dialed at any time. There is an assumed high overhead for each hop; thus, HOURLY is far more than DAILY/24.

There are a few other cost names that sometimes appear in the map. Some are synonyms for the preferred names above (e.g. POLLED is assumed to mean overnight and is taken to be the same as DAILY), some are obsolete (e.g. the letters A through F, which are letter grades for connections.) It is not acceptable to make up new names or spellings (pathalias gets very upset when people do that...).

If a site should not be used to route email through it (but email can be sent to it), surround the name with angle brackets to mark it as a terminal node:

     myhost  (DIRECT)

If you are using a registered domain name, you can express routing to local hosts by forwarding:

     myhost  = myhost.my.domain
     myhost  <.my.domain>(DEDICATED)

LOCAL AREA NETWORKS

We do not want local area network information in the published map. If you want to put your LAN in your local Path.* files, read about the LAN syntax in the pathalias manual page.

WHAT TO DO WITH THIS STUFF

Once you have finished constructing your pathalias entry, mail it off to academ!uucpmap, which will be sent to the appropriate regional map coordinator. They maintain assigned geographic sections of the map, and the entire map is posted on a rolling basis in the USENET newsgroups comp.mail.maps over the course of a month. If you wish, you can also mail your map directly to your regional coordinator for processing using the email addresses listed in this document.

Cross-posting guidelines for dfw.maps

Crossposting between dfw.maps and any other group is expressly prohibited.


Article Format

  1. Articles posted to dfw.maps MUST be flat-ASCII. This means:
    1. No Binary postings, uuencoded or base64.
    2. No MIME encoded messages. Posts SHOULD be readable by the simplest text-only newsreader.
    3. No HTML, although HTML-like emoticons are acceptable.
    4. No characters with a value greater than 127 in any part of the post.

  2. Posts SHOULD be shorter than 30K in size. Longer items SHOULD be made available for FTP or HTTP download and a pointer to that file posted.

  3. Posts MUST contain a valid From address, unless the ".invalid" domain is used (see RFC 1036). Spam blocks are acceptable. By definition USENET newsgroups are a broadcast medium. If you have a post that needs to be anonymous, it is not a valid topic for dfw.maps. Post this material elsewhere.

  4. ROT13 encoding SHOULD NOT be used on any field in the headers. Nor should any attempts, except minimal spam blocks, be made to obscure the origins of the posting.

  5. Posts MUST contain a "Abuse-Reports-To:" or "X-Complaints-To:" header with a valid email address. When RFC1036 is updated, this line SHOULD be adjusted to comply with the latest specifications. Adding or replacing this header is the responsibility of the news server where the article was injected.

Failing to follow the above formatting requirements could result in an article being canceled instantly and without warning by an authorized moderation device (human or otherwise) for the group in question. Articles cross-posted to other groups and dfw.maps must still follow the criteria of dfw.maps and be subject to these rules.



$Id: dfw.maps.html,v 1.3 1999/10/17 20:00:58 eric Stable $
Copyright 1999, DFW USENET cabal