home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / mail / maps / 6937 < prev    next >
Encoding:
Internet Message Format  |  1993-01-08  |  18.9 KB

  1. Path: sparky!uunet!spool.mu.edu!uwm.edu!rutgers!pleasant
  2. From: uucpmap@rutgers.rutgers.edu (UUCP Mapping Project)
  3. Newsgroups: comp.mail.maps
  4. Subject: UUCP map for README
  5. Message-ID: <Jan.8.06.07.14.1993.13274@rutgers.rutgers.edu>
  6. Date: 8 Jan 93 11:07:14 GMT
  7. Expires: 22 Feb 93 11:07:14 GMT
  8. Sender: pleasant@rutgers.rutgers.edu
  9. Lines: 515
  10. Approved: pleasant@rutgers.edu (Mel Pleasant)
  11. Supersedes: <Nov.13.19.03.33.1992.3044@rutgers.rutgers.edu>
  12.  
  13. :    This is a shell archive.
  14. :    Remove everything above this line and
  15. :    run the following text with /bin/sh to create:
  16. :    README
  17. : This archive created: Fri Jan  8 06:07:05 1993
  18. echo shar: extracting README
  19. cat << 'SHAR_EOF' > README
  20. # The UUCP map is posted to the newsgroup comp.mail.maps.
  21. #
  22. # From rn, the map can be easily unpacked with a command such as:
  23. #
  24. #    43-46w | (cd ~uucp/uumap ; sh)
  25. #
  26. # or you can use John Quarterman's script to automatically unpack the
  27. # files.  All files intended as pathalias input being with "d." and
  28. # "u.", thus:
  29. #
  30. #    pathalias Path.* uumap/[du].*
  31. # is a useful command to run.  (You supply Path.* with local additions.)
  32. #
  33. # The files are organized by country, using the ISO 3166 3 letter
  34. # country code for each country.  Each file has a name like
  35. # u.iso.r1.r2.s, where "iso" is the country code, r1, r2, etc are
  36. # regions and subregions (e.g. states in the USA, provinces in Canada,
  37. # etc.) and s is a sequence number (usually 1, but sometimes 2, 3, and
  38. # up may be provided to keep individual files down to a reasonable size,
  39. # thus, u.usa.ca is separated into two regions: [135] for southern,
  40. # [246] for northern.)
  41. # The map contains two types of files: u.* and d.* files.  The d.* files
  42. # are for domains registered in the UUCP Zone.  The u.* files are for
  43. # UUCP hosts that do not have officially registered domains.  Membership
  44. # in the UUCP Zone allows organizations and individuals to register
  45. # official, unique, domain names, recognized by all major academic
  46. # computing networks worldwide.  For more information about joining the
  47. # UUCP Zone, send electronic mail to the UUCP Project at one of the
  48. # addresses:
  49. #
  50. #    domain-request@uunet.uu.net
  51. #    {vucomp,halla,pyramid,rutgers,uiucuxc,rosevax}!uunet!domain-request
  52. # or, if you cannot send electronic mail, telephone
  53. #    +1 703 204 8000
  54. #
  55. # We strongly encourage you to send email if at all possible, since it
  56. # cuts down on telephone tag and is much more efficient on our volunteer
  57. # workforce.
  58. # This map can be used to generate mail routes with the pathalias
  59. # program.  The map is also useful to determine the person to contact
  60. # when a problem arises, and to find someone for a new site to connect
  61. # to.
  62. #
  63. # Pathalias was first posted to Usenet in January 1986.  It is posted
  64. # whenever a new release becomes available as well.  The sources are
  65. # posted in the comp.sources.unix newsgroup.  You may also ask the
  66. # comp.sources.unix moderators (unix-sources-moderators@pa.dec.com) to
  67. # send sources to you via email.
  68. # Please check the entry for your host (and any neighbors for whom you
  69. # know the information and have the time) for correctness and
  70. # completeness.  Please send corrections and additional information to
  71. # uucpmap@rutgers.UUCP or rutgers!uucpmap or uucpmap@rutgers.EDU.
  72. # This map is maintained by a group of volunteers who make up the UUCP
  73. # Mapping Project.  These people devote many hours of their own time to
  74. # helping out the UUCP community by keeping this map up to date.  The
  75. # volunteers include:
  76. #
  77. #
  78. # Tohru Asami - konish@kddlab.kddlabs.co.jp
  79. #   Japan: all regions
  80. #
  81. # Jesse Asher - homecare!jessea
  82. #   USA: Alabama, North Carolina, South Carolina, Tennessee
  83. #
  84. #
  85. # Stan Barber - texas-uucpmap@tmc.edu
  86. #   USA: Texas
  87. #
  88. #
  89. # Piet Beertema - Europe (piet@cwi.nl)
  90. #   Europe: all countries (unless otherwise noted)
  91. # Bill Blue - bblue@crash.cts.com
  92. #   USA: Arizona, California
  93. #
  94. # Kent Brodie - brodie@fps.mcw.edu
  95. #   USA: North Dakota, South Dakota, Wisconsin
  96. #
  97. #
  98. # Malcolm Carlock - uucpmap@unrvax.unr.edu
  99. #   USA: Nevada
  100. #
  101. #
  102. # Ken Herron - kherron@ms.uky.edu
  103. #   USA: Kentucky
  104. #
  105. # Haesoon Cho - dnmc@sorak.kaist.ac.kr
  106. #   Korea: all regions
  107. #
  108. # Christopher Vance - Christopher.Vance@adfa.oz.au
  109. #   Australia: all regions
  110. #
  111. # Paul Graham - pjg@acsu.buffalo.edu
  112. #   USA: Delaware, Maryland, New Jersey, New York, Virginia, Washington DC,
  113. #   West Virginia
  114. #
  115. # Hokey - hokey@plus5.com
  116. #   USA: Missouri
  117. #
  118. # Jeff Janock - nemap@harvard.edu
  119. #   USA: Connecticut, Maine, Massachusetts, New Hampshire, Pennsylvania, 
  120. #        Rhode Island, Vermont
  121. #
  122. #
  123. # Bob Leffler - uucpmap@vela.acs.oakland.edu
  124. #   USA: Michigan
  125. #
  126. #
  127. # Mikel Manitius - map-request@aaa.com
  128. #   USA: Florida
  129. #
  130. #
  131. # Doug McCallum - dougm@csn.org
  132. #   USA: Arkansas, Colorado, Iowa, Kansas, Louisiana, Mississippi, Nebraska,
  133. #        New Mexico, Oklahoma, Utah
  134. #
  135. # Ed Hew - path@cs.toronto.edu
  136. #   CANADA: All provinces
  137. #
  138. # Todd Ogasawara - todd@protege.pegasus.com
  139. #   USA: Hawaii
  140. #
  141. # Mel Pleasant - pleasant@rutgers.edu
  142. #   Singapore: all regions
  143. #   New Zealand: all regions
  144. # R. M. S. Ibrahim - indomap@indogtw.uucp
  145. #   Indonesia: all regions
  146. #
  147. #
  148. # David Schmidt - davids@isc-br.isc-br.com
  149. #   USA: Alaska, Idaho, Oregon, Montana, Washington, Wyoming
  150. # Larry Snyder - uucpmap@gator.rn.com
  151. #   USA: Illinois, Indiana
  152. #
  153. #
  154. # Aris Stathakis - uucpmap@tabbs.uucp
  155. #   South Africa
  156. #
  157. #
  158. # Gil Tene - devil@diablery.10a.com
  159. #   Israel: all regions
  160. #
  161. #
  162. # Tim Thompson - tgt@att.att.com
  163. #   USA: Ohio
  164. #
  165. #
  166. #   Jeff Wabik - jwabik@msc.umn.edu
  167. #   USA: Minnesota
  168. #
  169. # Charles Stephens - uucpmap@cowpas.waffle.atl.ga.us
  170. #   USA: Georgia
  171. # Please note that the purpose of this map is to allow mail routers
  172. # within UUCP to work properly.  The eventual direction is to make the
  173. # map smaller (through the use of domains), not larger.  As such, sites
  174. # with lots of local machines connected together are *strongly*
  175. # encouraged to join the UUCP Zone.  Through the use of a domain, you
  176. # need only register your domain gateway system(s) with the UUCP Mapping
  177. # Project.  Properly configured, all of your internal nodes will hide
  178. # behind the gateway(s).  We would prefer not to have information
  179. # listing the machines on your local area networks.  Helping us to
  180. # accomplish the goal of reducing the size of the map will take some
  181. # work on your part but it is well worth the effort.  Once done, you
  182. # will never need to register any new nodes acquired by you.
  183. # Instructions for contacting the UUCP Zone are given above.
  184. #
  185. # PLEASE NOTE - IF YOU HAVEN'T THE TIME OR MANPOWER TO ACQUIRE A DOMAIN
  186. # AND CONVERT YOUR SYSTEMS OVER TO USING IT, you are *strongly*
  187. # encouraged to publish all the names of those sites in your local area
  188. # network which can and do generate email messages or netnews articles.
  189. # Publishing the names of all systems not hiding behind a domain is the
  190. # only way to ensure that some other site will not register with the
  191. # same name that you have chosen and hence will ensure that mail routers
  192. # will generate uucp mail paths to your systems properly.  
  193. #
  194. #
  195. # The remainder of this file describes the format of the UUCP map data.
  196. # It was written July 9, 1985 by Erik E. Fair <ucbvax!fair>, and last
  197. # updated July 12, 1985 by Mark Horton <stargate!mark>.
  198. # The entire map is intended to be processed by pathalias, a program
  199. # that generates UUCP routes from this data.  All lines beginning in `#'
  200. # are comment lines to pathalias, however the UUCP Project has defined a
  201. # set of these comment lines to have specific format so that a complete
  202. # database could be built.
  203. # The generic form of these lines is
  204. # #<field id letter><tab><field data>
  205. # Each host has an entry in the following format.  The entry should
  206. # begin with the #N line, end with a blank line after the pathalias
  207. # data, and not contain any other blank lines, since there are ed, sed,
  208. # and awk scripts that use expressions like /^#N $1/,/^$/ for the
  209. # purpose of separating the map out into files, each containing one site
  210. # entry.
  211. # #N    UUCP name of site
  212. # #S    manufacturer machine model; operating system & version
  213. # #O    organization name
  214. # #C    contact person's name
  215. # #E    contact person's electronic mail address
  216. # #T    contact person's telephone number
  217. # #P    organization's address
  218. # #L    latitude / longitude
  219. # #R    remarks
  220. # #U    netnews neighbors
  221. # #W    who last edited the entry ; date edited
  222. # #
  223. # sitename    .domain
  224. # sitename    remote1(FREQUENCY), remote2(FREQUENCY),
  225. #     remote3(FREQUENCY)
  226. # Example of a completed entry:
  227. # #N    ucbvax
  228. # #S    DEC VAX-11/750; 4.3 BSD UNIX
  229. # #O    University of California at Berkeley
  230. # #C    Robert W. Henry
  231. # #E    ucbvax!postmaster
  232. # #T    +1 415 642 1024
  233. # #P    573 Evans Hall, Berkeley, CA 94720
  234. # #L    37 52 29 N / 122 13 44 W
  235. # #R    This is also UCB-VAX.BERKELEY.EDU [10.2.0.78] on the internet
  236. # #U    decvax ibmpa ucsfcgl ucbtopaz ucbcad
  237. # #W    ucbvax!fair (Erik E. Fair); Sat Jun 22 03:35:16 PDT 1985
  238. # #
  239. # ucbvax    berkeley.edu
  240. # ucbvax    = ucbvax.berkeley.edu
  241. # ucbvax    decvax(DAILY/4)
  242. #     sun(POLLED)
  243. # Specific Field Descriptions
  244. # #N    system name
  245. # Your system's UUCP name should go here. Either the uname(1) command
  246. # from System III or System V UNIX; or the uuname(1) command from
  247. # Version 7 UNIX will tell you what UUCP is using for the local UUCP
  248. # name.
  249. # One of the goals of the UUCP Project is to keep duplicate UUCP host
  250. # names from appearing because there exist mailers in the world which
  251. # assume that the UUCP name space contains no duplicates (and attempts
  252. # UUCP path optimization on that basis), and it's just plain confusing
  253. # to have two different sites with the same name.
  254. # At present, the most severe restriction on UUCP names is that the name
  255. # must be unique somewhere in the first six characters, because of a
  256. # poor software design decision made by AT&T for the System V release of
  257. # UNIX.
  258. # This does not mean that your site name has to be six characters or
  259. # less in length. Just unique within that length.
  260. # With regard to choosing system names, HARRIS'S LAMENT:
  261. #     ``All the good ones are taken.''
  262. # #S    machine type; operating system
  263. # This is a quick description of your equipment. Machine type should be
  264. # manufacturer and model, and after a semi-colon(;), the operating
  265. # system name and version number (if you have it). Some examples:
  266. #     DEC PDP-11/70; 2.9 BSD UNIX
  267. #     DEC PDP-11/45; ULTRIX-11
  268. #     DEC VAX-11/780; VMS 4.0
  269. #     SUN 2/150; 4.2 BSD UNIX
  270. #     Pyramid 90x; OSx 2.1
  271. #     CoData 3300; Version 7 UniPlus+
  272. #     Callan Unistar 200; System V UniPlus+
  273. #     IBM PC/XT; Coherent
  274. #     Intel 386; XENIX 3.0
  275. #     CRDS Universe 68; UNOS
  276. # #O    organization name
  277. # This should be the full name of your organization, squeezed to fit
  278. # inside 80 columns as necessary. Don't be afraid to abbreviate where
  279. # the abbreviation would be clear to the entire world (say a famous
  280. # institution like MIT or CERN), but beware of duplication (In USC the C
  281. # could be either California or Carolina).
  282. # #C    contact person
  283. # This should be the full name (or names, separated by commas) of the
  284. # person responsible for handling queries from the outside world about
  285. # your machine.
  286. # #E    contact person's electronic address
  287. # This should be just a machine name, and a user name, like
  288. # `ucbvax!fair'. It should not be a full path, since we will be able to
  289. # generate a path to the given address from the data you're giving us.
  290. # There is no problem with the machine name not being the same as the #N
  291. # field (i.e. the contact `lives' on another machine at your site).
  292. # Also, it's a good idea to give a generic address or alias (if your
  293. # mail system is capable of providing aliases) like `usenet' or
  294. # `postmaster', so that if the contact person leaves the institution or
  295. # is re-assigned to other duties, he doesn't keep getting mail about the
  296. # system. In a perfect world, people would send notice to the UUCP
  297. # Project, but in practice, they don't, so the data does get out of
  298. # date. If you give a generic address you can easily change it to point
  299. # at the appropriate person.
  300. # Multiple electronic addresses should be separated by commas, and all
  301. # of them should be specified in the manner described above.
  302. # #T    contact person's telephone number
  303. # Format: +<country code><space><area code><space><prefix><space><number>
  304. # Example:
  305. # #T    +1 415 642 1024
  306. # This is the international format for the representation of phone
  307. # numbers. The country code for the United States of America (and
  308. # Canada) is 1. Other country codes should be listed in your telephone
  309. # book.
  310. # If you must list an extension (i.e. what to ask the receptionist for,
  311. # if not the name of the contact person), list it after the main phone
  312. # number with an `x' in front of it to distinguish it from the rest of
  313. # the phone number.
  314. # Example:
  315. # #T    +1 415 549 3854 x37
  316. # Multiple phone numbers should be separated by commas, and all of them
  317. # should be completely specified as described above to prevent
  318. # confusion.
  319. # #P      organization's address
  320. # This field should be one line filled with whatever else anyone would
  321. # need after the contact person's name, and your organization's name
  322. # (given in other fields above), to mail you something by paper mail.
  323. # #L      latitude and longitude
  324. # This should be in the following format:
  325. # #L    DD MM [SS] "N"|"S" / DDD MM [SS] "E"|"W" ["city"]
  326. # Two fields, with optional third.
  327. # First number is Latitude in degrees (NN), minutes (MM), and seconds
  328. # (SS), and a N or S to indicate North or South of the Equator.
  329. # A Slash Separator.
  330. # Second number is Longitude in degrees (DDD), minutes (MM), and seconds
  331. # (SS), and a E or W to indicate East or West of the Prime Meridian in
  332. # Greenwich, England.
  333. # Seconds are optional, but it is worth noting that the more accurate
  334. # you are, the more accurate maps we can make of the network (including
  335. # blow-ups of various high density areas, like New Jersey, or the San
  336. # Francisco Bay Area).
  337. # If you give the coordinates for your city (i.e. without fudging for
  338. # where you are relative to that), add the word `city' at the end of the
  339. # end of the specification, to indicate that. If you know where you are
  340. # relative to a given coordinate for which you have longitude and
  341. # latitude data, then the following fudge factors can be useful:
  342. # 1 degree    =    69.2 miles    =    111 kilometers
  343. # 1 minute    =    1.15 miles    =    1.86 kilometers
  344. # 1 second    =    102 feet    =    30.9 meters
  345. #
  346. # For LONGITUDE, multiply the above numbers by the cosine of your
  347. # latitude.  For instance, at latitude 35 degrees, a degree of longitude
  348. # is 69.2*0.819 = 56.7 miles; at latitude 40 degrees, it is 69.2*0.766 =
  349. # 53.0 miles.  If you don't see why the measure of longitude depends on
  350. # your latitude, just think of a globe, with all those N-S meridians of
  351. # longitude converging on the poles.  You don't do this cosine
  352. # multiplication for LATITUDE.
  353. #
  354. # Here is a short cosine table in case you don't have a trig calculator
  355. # handy.  (But you can always write a short program in C.  The cosine
  356. # function in bc(1) doesn't seem to work as documented.)
  357. # deg  cos  deg  cos  deg  cos  deg  cos  deg  cos  deg  cos
  358. #  0  1.000  5  0.996 10  0.985 15  0.966 20  0.940 25  0.906
  359. # 30  0.866 35  0.819 40  0.766 45  0.707 50  0.643 55  0.574
  360. # 60  0.500 65  0.423 70  0.342 75  0.259 80  0.174 85  0.087
  361. # The Prime Meridian is through Greenwich, England, and longitudes run
  362. # from 180 degrees West of Greenwich to 180 East.  Latitudes run from
  363. # 90 degrees North of the Equator to 90 degrees South.
  364. # #R      remarks
  365. # This is for one line of comment. As noted before, all lines beginning
  366. # with a `#' character are comment lines, so if you need more than one
  367. # line to tell us something about your site, do so between the end of the
  368. # map data (the #?\t fields) and the pathalias data.
  369. # #U    netnews neighbors
  370. # The USENET is the network that moves netnews around, specifically,
  371. # news.announce.important. If you send news.announce.important to any of
  372. # your UUCP neighbors, list their names here, delimited by spaces.
  373. # Example:
  374. # #U    decvax mcvax seismo
  375. # Since some places have lots of USENET neighbors, continuation lines
  376. # should be just another #U and more site names.
  377. # #W      who last edited the entry and when
  378. # This field should contain an email address, a name in parentheses,
  379. # followed by a semi-colon, and the output of the date program.
  380. # Example:
  381. # #W    ucbvax!fair (Erik E. Fair); Sat Jun 22 03:35:16 PDT 1985
  382. # The same rules for email address that apply in the contact's email
  383. # address apply here also. (i.e. only one system name, and user name).
  384. # It is intended that this field be used for automatic aging of the
  385. # map entries so that we can do more automated checking and updating
  386. # of the entire map. See getdate(3) from the netnews source for other
  387. # acceptable date formats.
  388. # PATHALIAS DATA (or, documenting your UUCP connections & frequency of use)
  389. # The DEMAND, DAILY, etc., entries represent imaginary connect costs (see
  390. # below) used by pathalias to calculate lowest cost paths.  The cost
  391. # breakdown is:
  392. #     LOCAL        25    local area network
  393. #     DEDICATED    95    high speed dedicated
  394. #     DIRECT        200    local call
  395. #     DEMAND          300     normal call (long distance, anytime)
  396. #     HOURLY        500    hourly poll
  397. #     EVENING        1800    time restricted call
  398. #     DAILY        5000    daily poll
  399. #     WEEKLY        30000    irregular poll
  400. #     DEAD            a very high number - not usable path
  401. # Additionally, HIGH and LOW (used like DAILY+HIGH) are -5 and +5
  402. # respectively, for baud-rate or quality bonuses/penalties.  Arithmetic
  403. # expressions can be used, however, you should be aware that the results
  404. # are often counter-intuitive (e.g. (DAILY*4) means every 4 days, not 4
  405. # times a day).  This is because the numbers represent "cost of connection"
  406. # rather than "frequency of connection."
  407. # The numbers are intended to represent cost of transferring mail over
  408. # the link, measured very roughly in elapsed time, which seems to be
  409. # far more important than baud rates for this type of
  410. # traffic.  There is an assumed high overhead for each hop; thus,
  411. # HOURLY is far more than DAILY/24.
  412. # There are a few other cost names that sometimes appear in the map.
  413. # Some are synonyms for the preferred names above (e.g. POLLED is assumed
  414. # to mean overnight and is taken to be the same as DAILY), some are
  415. # obsolete (e.g.  the letters A through F, which are letter grades for
  416. # connections.) It is not acceptable to make up new names or spellings
  417. # (pathalias gets very upset when people do that...).
  418. # LOCAL AREA NETWORKS
  419. # We do not want local area network information in the published map.
  420. # If you want to put your LAN in your local Path.* files, read about
  421. # the LAN syntax in the pathalias.1 manual page.
  422. # WHAT TO DO WITH THIS STUFF
  423. # Once you have finished constructing your pathalias entry, mail it off
  424. # to {uunet|gatech|ucsd|ames}!rutgers!uucpmap, which will be sent to the
  425. # appropriate regional map coordinator.  They maintain assigned
  426. # geographic sections of the map, and the entire map is posted on a
  427. # rolling basis in the USENET newsgroups comp.mail.maps over the course
  428. # of a month.
  429. # Questions or comments about this specification should also be directed
  430. # at rutgers!uucpmap.
  431. SHAR_EOF
  432. :    End of shell archive
  433. exit 0
  434.