Beijing Paradise BBS Backup/PARADISE.ISO/software/BBSDOORW/UFG_103.ZIP/UUCPMAP.DES

Text File | 1989-01-03 | 13.8 KB | 353 lines

The remainder of this file describes the format of the UUCP map data.
Revision History:
    original July 9, 1985 by Erik E. Fair <ucbvax!fair>
    updated July 12, 1985 by Mark Horton <stargate!mark>
    updated April 4, 1988 by Erik E. Fair <ucbvax!fair>

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 (that is, it ignores them),
however the UUCP Project has defined a set of these comment lines
to have specific format so that a complete database can be built,
containing such additional information as site contact, postal
address and so on.

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 assume that blank lines delimit individual
map entries.

#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    remark
#U    netnews neighbors
#W    who last edited the entry ; date edited
#
sitename    .domain
sitename=    alias1, alias2
sitename    remote1(FREQUENCY), remote2(FREQUENCY),
    remote3(FREQUENCY)

Example of a completed entry:

#N    ucbvax
#S    DEC VAX-11/750 ; 4.3 BSD UNIX
#O    University of California at Berkeley
#C    Robert W. Henry
#E    ucbvax!postmaster
#T    [phone]
#P    573 Evans Hall, Berkeley, CA 94720
#L    37 52 29 N / 122 13 44 W
#R
#U    decvax ames ucsfcgl pasteur agate hplabs
#W    ucbvax!fair (Erik E. Fair) ; Mon Apr  4 17:53:54 PDT 1988
#
# ucbvax is the gateway to anything in .berkeley.edu
ucbvax    .berkeley.edu
#
# some other names ucbvax is known by
ucbvax=    ucbvax.berkeley.edu, ucb-vax.arpa
#
# our UUCP connections
ucbvax    decvax(DAILY/4), ihnp4(DAILY/2),
    sun(POLLED)

Please note that ".UUCP" is not a real domain and as such,
please don't use a line of the form:

site    .site.UUCP

in your map entry; the astute UUCP map maintainers will remove it
before it sees publication in the UUCP maps. The ".UUCP" stuff is
a hack used in sendmail configuration files to make UUCP addresses
parse correctly according to RFC822 ("@" first, always). Unfortunately,
it is a side effect of this hack that "[e-mail]" is also
acceptable (although you really have to be using the UUCP maps and
pathalias to generate a path to any arbitrary UUCP site).

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 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.

Names should consist of lower case alphanumeric characters. Dashes
"-" (but not underscores "_") are also allowed, except at the
beginning or end of a name.

At present, the most severe restriction on UUCP names is that the
name must be network-wide unique somewhere in the first six
characters, because of a poor software design decision made by AT&T
in UUCP for the original System V release of UNIX. When that version
of UUCP is eradicated from the network (replaced presumably by the
superior HoneyDanBer UUCP a.k.a. Basic Networking Utilities), we
will be able to relax this restriction.

This does not mean that your site name has to be six characters or
less in length. Just unique within that length. Also, when giving
connectivity data, don't truncate the names of your neighbors,
because mail(1) will use and propagate the full length name.

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 VAX-11/785 ; 4.3 BSD UNIX
    DEC VAX-8800 ; Ultrix 1.2
    DEC PDP-11/70 ; 2.9 BSD UNIX
    DEC PDP-11/45 ; Version 7 UNIX
    Sun 3/260 ; SunOS 3.5
    Pyramid 90x ; OSx 2.1
    CoData 3300 ; Version 7 UniPlus+
    IBM PC/AT ; Xenix 3.0
    IBM PS/2 model 80 ; OS/2
    AT&T 3b2 ; System V.3 UNIX

#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
"ucbvax!postmaster". It should not be a full path, since we should
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 (e.g. the contact receives mail on another
machine at your site), so long as that site is also in UUCP maps.

Also, it's a good idea to give a generic address or alias (if your
mail system is capable of providing aliases) like "postmaster" or
"usenet", 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 the Internet, for example, all sites are *required* to
accept mail for "postmaster" and have that pointed at the person at
that site who is responsible for the electronic mail system.

In a perfect world, people would send notice to the UUCP Project
when some element of their UUCP map entry changes, but in practice,
many sites don't, so the UUCP maps 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: +<country code><space><area code><space><prefix><space><number>

Example:

#T    [phone]

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 directory.

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    [phone] x37

Multiple phone numbers should be separated by commas, and all of them
should be completely specified as described above to prevent confusion.

#P      organization's address

This field should be filled with whatever else is needed after it
is concatenated with #C and #O, to form a postal 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 (NN), 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). Decimal minutes or degrees are NOT allowed.

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.)

deg  cos  deg  cos  deg  cos  deg  cos  deg  cos  deg  cos
 0  1.000  5  0.996 10  0.985 15  0.966 20  0.940 25  0.906
30  0.866 35  0.819 40  0.766 45  0.707 50  0.643 55  0.574
60  0.500 65  0.423 70  0.342 75  0.259 80  0.174 85  0.087

The Prime Meridian runs from the North Pole to the South Pole
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. If you send news.announce to any of your UUCP neighbors,
list their names here, delimited by spaces. Example:

#U    ihnp4 decvax mcvax seismo

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

#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(1) program.
Example:

#W    ucbvax!fair (Erik E. Fair) ; Sat Jun 22 03:35:16 PDT 1985

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 ageing 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
values of the symbols are:

    LOCAL        25    local area network
    DEDICATED    95    high speed dedicated
    DIRECT        200    local call
    DEMAND          300     normal call (long distance, anytime)
    HOURLY        500    hourly poll
    EVENING        1800    time restricted call
    DAILY        5000    daily poll
    WEEKLY        30000    irregular poll
    DEAD            a very high number - not usable path

Additionally, HIGH and LOW (used like DAILY+HIGH) are -5 and +5
respectively, for baud-rate or other quality bonuses/penalties.
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"
(i.e. lower cost is better).

The numbers are intended to represent cost of transferring mail
over the link, measured very rougly in elapsed time, which seems
to be far more important than baud rates for this type of traffic.
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...).

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.1 manual page.

WHAT TO DO WITH THIS STUFF

Once you have finished constructing your pathalias entry, mail it
off to any of

[e-mail]
{ames,hplabs,purdue,ihnp4,ucsd,okstate,clyde}!rutgers!uucpmap
uunet!uucpmap
ucbvax!uucpmap

(the latter two point to rutgers) which will reach the meta-map
coordinator (he who coordinates the map coordinators). He, in turn,
will send the map entry to the appropriate regional map coordinator.
They are volunteers who maintain assigned geographic sections of
the map (they change site names and links, delete sites whose data
is too old, and try to keep the data for their area consistent).
The entire map is posted periodically in the USENET newsgroup
comp.mail.maps as shar files.

Questions or comments about this specification should also be
directed at [e-mail].