grr@cbmvax.UUCP (02/19/87)
This may be a stupid question, but why havE the uucp project, domain registry
and Stargate suddenly become one and the same thing/organization?
Why are the domain registration dues so high? What expenses are being
covered and are any of these 'domain' dues actually going to cover Stargate
stuff?
I was willing willing to shell out $10-$20 out of my own pocket to cover
one-time filing fee for this domain stuff, and am shocked to find somebody
expects $50-150 a year! Now I've got to convince my company that this is
somehow a 'good' thing.
I have no objections to domains. I have no objection to Stargate. BUT
isn't it about time that some of the people involved take the time to
explain the policies, plans and dreams involved?
--
George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr
but no way officially representing arpa: cbmvax!grr@seismo.css.GOV
Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)page@ulowell.UUCP (02/20/87)
grr@cbmvax.UUCP (George Robbins) wrote: >This may be a stupid question, but why havE the uucp project, domain registry >and Stargate suddenly become one and the same thing/organization? For that matter, why have smail (pronounced 'sm-ail' :-)), a useful mail back end, bundled with a domain application, and comments in the code that says ".UUCP is temporary for testing, GET REGISTERED!" ?? Is it a Plot? (No smiley face here.) ..Bob -- Bob Page, U of Lowell CS Dept. ulowell!page, page@ulowell.CSNET
john@basser.UUCP (02/20/87)
In article <3368@cbosgd.ATT.COM> mark@cbosgd.ATT.COM (Mark Horton) writes: > Not all countries use the second level for the organization. In > particular, Australia and Britain have set up second level domains > AC.UK and OZ.AU for their academic communities, and put the > organization at the third level. I appreciate that Mark is probably deliberately oversimplifying here, in an attempt to speak to the layperson without becoming confusing. However, what he says is certainly not correct. No analogy can be drawn between ac.uk and oz.au. oz.au is one of the older-style names Mark mentions earlier in the article: the oz domain indicates a particular _network_, specifically ACSnet. In no sense is the oz domain comprised of only academic sites. There are many commercial and government sites on ACSnet; all these are in the oz domain. There are a few ACSnet sites that are not in Australia; these are not in the oz domain. However, not only is addressing these sites from outside Australia problematic, there is in every case a better way for anyone not in Australia to reach these machines rather than via ACSnet, so the point is moot. John Mackin, Basser Department of Computer Science, University of Sydney, Sydney, Australia john@basser.oz.AU (john%basser.oz@SEISMO.CSS.GOV) {seismo,hplabs,mcvax,ukc,nttlab}!munnari!basser.oz!john
mark@cbosgd.UUCP (02/20/87)
In article <1433@cbmvax.cbmvax.cbm.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >This may be a stupid question, but why havE the uucp project, domain registry >and Stargate suddenly become one and the same thing/organization? Because it costs a significant amount of money to start up an organization. Some some of us are involved in both projects, it was determined that it's more cost effective to do it once than twice. (The domain registry always was part of the UUCP Project; Stargate started out separately.) >Why are the domain registration dues so high? What expenses are being >covered and are any of these 'domain' dues actually going to cover Stargate >stuff? It costs $5000 to $30,000 per year to join CSNET; BITNET and ARPANET are even more. $150/year is a real bargain. We set the rates to cover our projected 1987 expenses with our projected 1987 income. The bulk of the money is budgeted for startup costs, telephone, and travel. The Stargate part has its own funding from Stargate subscribers, and the money is being kept separate. >I was willing willing to shell out $10-$20 out of my own pocket to cover >one-time filing fee for this domain stuff, and am shocked to find somebody >expects $50-150 a year! Now I've got to convince my company that this is >somehow a 'good' thing. We have 1 person consulting companies that are happy to pay $150/year to have a domain at the same level as AT&T. If Commodore is too impoverished to afford $.50/day to cover the ENTIRE COMPANY, they must be hurting pretty badly, in which case I'm afraid to buy their products. It was never intended for people to pay for this out of their own pockets. The whole company benefits from a consistent electronic mail interface to the outside world; the company should be happy to pay for that benefit. >I have no objections to domains. I have no objection to Stargate. BUT >isn't it about time that some of the people involved take the time to >explain the policies, plans and dreams involved? Very simply, we're trying to provide some higher quality services to the community at a low cost. I think we're succeeding. We've already done the most we possibly could on a cost-free basis (the UUCP map) and we've run up against a limit. If we are going to improve service any more, we have to spend time & money to do it. That money isn't going to come out of our own pockets. We do not have venture capital here. We don't have somebody paying the bills as a benefactor. The principles do not have spare cash to spend. This project has to pay its own way, from the beginning, or it won't even get off the ground. If you really think we're somehow evil, then conduct a smear campaign; we'll all get discouraged, give up, and UUCP can get on with collapsing under its enormous weight. If you want the UUCP Zone to succeed, show your support by signing up! Mark
hokey@plus5.UUCP (02/23/87)
Mark, What are the travel costs of which you speak? Why is the fee a yearly one? What ongoing costs justify a yearly fee? If a yearly fee is a "convenience" for companies who would rather pay a yearly fee instead of a fee on a per-change basis, or a "convenience" for your organization (I know there are costs associated with order processing and accounting), why don't you offer an "initial" fee and a "change" fee? (If one were to guess I have been going over the accounting and budgets here at Plus Five, one would be correct.) -- Hokey
mojo@micropro.UUCP (02/23/87)
In article <3380@cbosgd.ATT.COM> mark@cbosgd.ATT.COM (Mark Horton) writes: >We have 1 person consulting companies that are happy to pay $150/year to >have a domain at the same level as AT&T. If Commodore is too impoverished >to afford $.50/day to cover the ENTIRE COMPANY, they must be hurting >pretty badly, in which case I'm afraid to buy their products. Mark, MicroPro has been on the net for a couple years, using two old Pixel 100/AP machines, and three Cosmos Antares systems. Cosmos went out of business, and the machines are being retired. There is no support for using or having any UNIX systems in the company. One of the two Pixel systems is being canabalized to keep one Pixel in operating order. A few of us keep that Pixel running in our spare time. The only people in the company willing and able to attempt UNIX mail are about a half-dozen programmers. The rest of the company has switched to EtherMail (cough) or MCI mail. Unfortunately, this $50/year fee is going to mean that we pool together some personal money, or survive without an entry in the UUCP map. -- Mojo ... Morris Jones, MicroPro Int'l Corp., Product Development {lll-crg,ptsfa,dual,well,pyramid}!micropro!mp-mojo!mojo Not the opinion of MicroPro! Democracy: The bludgeoning of the people by the people for the people. -- John Galt
avolio@decuac.UUCP (02/24/87)
In article <284@micropro.UUCP>, mojo@micropro.UUCP (Morris Jones) writes: > The only people in the company willing and able to attempt UNIX mail are > about a half-dozen programmers. The rest of the company has switched to > EtherMail (cough) or MCI mail. > > Unfortunately, this $50/year fee is going to mean that we pool together > some personal money, or survive without an entry in the UUCP map. So pool together some money... You have to admit, $50 a year shared by 6 people is not bad. Perhaps Mark was a bit short, though. In a lot of places it is easier to justify $100K for equipment than it is to get someone to buy off on a small purchase (especailly if there are no forms to fit the request!). But, I htink that $50 for a year can be easily handled. Fred.
dyer@spdcc.UUCP (02/25/87)
>Unfortunately, this $50/year fee is going to mean that we pool together >some personal money, or survive without an entry in the UUCP map. I don't understand this. You pay to be registered in the UUCP zone. This gives you recognition by all the other folks in the Internet who use domain names (provided they support MX records.) If you don't pay, you'll "survive" just as you've been doing right now. As Mark Horton underscored, absolute UUCP paths will work as always. The UUCP map will continue to be compiled and distributed.
mark@Stargate.COM (Mark Horton) (05/21/87)
: "---- cut here ----"
: "This is a shell archive"
: "To unpack, remove all lines up to and including the 'cut here'"
: "line, save the result in a file /tmp/ip.shar, create an empty directory"
: "cd to that directory, and type: sh /tmp/ip.shar"
echo x - ip.README
cat >ip.README <<'!Funky!Stuff!'
READ ME FIRST
Updated 2/19/87
The UUCP Project offers members the registration of an ARPA sanctioned
domain name, and the publication of those names monthly on Usenet
newsgroup mod.map. We also offer a program "smail" which uses the
posted maps to deliver mail. Our membership dues, aimed only at
meeting expenses, are $150/year for medium or large organizations with
2nd level domains, and $50/year for tiny companies requiring only 3rd
level domains. The UUCP Project operates under the umbrella of
Stargate Information Services, which is not intended to be
profit-making.
This information packet contains information about membership in the
UUCP Zone. If you do not already have a copy of the smail software
(version 2.3 or later) you are urged to get a copy from the mod.sources
newsgroup or archives. (Version 2.3 was posted to mod.sources on 2/19/87)
If this is not practical, contact us for a copy. The smail software
supports the use of domains on most versions of the UNIX system,
including 4.2BSD and System V release 2, with or without sendmail. It
is primarily useful for hosts with only UUCP connections, or with UUCP
plus a small LAN with SMTP. Hosts in more complex environments will
need more complex solutions, of which smail may be a part.
Sometimes distributions are kept around on disks for a long time, and
become out of date. This package was prepared on the date above, and
is correct as of that date. If you are reading this more than a few
months after the date above, this information may be incorrect. In
this case, we urge you to contact us for more current information.
The files in this shell archive are:
ip.domains
A brief tutorial about what domains are.
ip.dues
The membership dues structure. Payment of these low annual
dues is necessary for us to register your domain. They help
us meet our expenses, so that our volunteers do not have to
pay these expenses out of their own pockets.
ip.form
The registration form. You can edit this file to create
your application to mail in electronically.
ip.form.ins
Instructions for filling out the registration form.
ip.forwarders
Information about ARPA forwarders. It is important that you
make arrangements with a forwarder, otherwise your domain cannot
be properly registered.
ip.parks
Information about "office parks", which allow you to register
a 3rd level domain at a reduced rate.
!Funky!Stuff!
echo x - ip.domains
cat >ip.domains <<'!Funky!Stuff!'
UUCP Zone Registry
12/6/86
To use smail, or other software supporting domain addresses, you need
to have a domain name registered in the domain tree. This name must be
unique in the world, and must be registered with the appropriate
registry. You also need to be in a domain that has a forwarder from
the ARPANET.
The exact structure of the domain tree is evolving. In 1984, the top
levels were network names (ARPA, CSNET, BITNET, UUCP, and so on) and
the second levels were hosts. The problem with this structure is that
machines connected to several networks have several names, and it's
difficult for users to predict the address of someone without knowing
their network connections.
In 1986, the domain tree in the USA has three major top level domains:
COM for companies, EDU for educational institutions, and GOV for
government entities. Three other top level names exist: MIL, NET, ORG,
but are somewhat specialized. For the most part, countries other than
the USA are using the ISO 3166 2 letter abbreviation for their country
as a top level.
Examples include US for USA, AU for Australia, JP for Japan, NL for
Netherlands. Abbreviations that are not ISO 3166 include CAN for
Canada and and UK for the United Kingdom.
One way of looking at the domain tree is that the top level is always
the country, where COM, EDU, and GOV are three pretend "countries" all
located in the USA. (This isn't quite strictly true, since some Canadian
organizations are registering under EDU or COM, intending to also register
under CAN later.)
The second level is generally the name of the organization, using the
shortest possible abbreviation that is clear and unique, thus ATT, DEC,
IBM, HP, etc. The choice of exact name is up to the organization, and
longer names, such as Berkeley.EDU or Tektronix.COM are perfectly
acceptable. Just remember that people must type the name, as well as
see it displayed.
Not all countries use the second level for the organization. In
particular, Australia and Britain have set up second level domains
AC.UK and OZ.AU for their academic communities, and put the
organization at the third level.
The third and subsequent levels, if used, should be organizational
units within the organization. Try to keep the number of levels to a
minimum, since people have to type the names. More than four total
levels (country, org, ou1, and ou2) should rarely be needed. The
actual organizational units to be used are up to you, for example, they
might be departments, or they might be machine names. For example,
Stargate has names like Base.Stargate.COM, where COM means a company,
Stargate is the organization (company) name, and Base is the name of
the machine within Stargate. A larger example: AT&T is using names
like cbpavo.MIS.OH.ATT.COM, where COM means AT&T is a company, ATT is
the organization, OH means Ohio, MIS stands for Medical Information
Systems, and cbpavo is a computer in the MIS project.
A "zone" is a registry of domains kept by a particular organization. A
zone registry is "authoritative", that is, the master copy of the
registry is kept by the zone organization, and this copy is, by
definition, always up-to-date. Copies of this registry may be
distributed to other places and kept in caches, but these caches are
not authoritative because they may be out of date. An authoritative
answer is required for certain decisions, such as "this mail cannot be
delivered because there is no such domain", or "the name you have
chosen is available and is now assigned uniquely to you."
In the USA, there are currently four zones: DDN (formerly called the
ARPANET), CSNET, BITNET, and UUCP. These zones all share the top level
domains COM, EDU, GOV, etc. The top level domains are administered by
the DDN (Defense Data Network) NIC (Network Information Center) at SRI
(SRI, Inc, formerly Stanford Research Institute, in Menlo Park, CA.)
The CSNET, BITNET, and UUCP registries serve as a go-between to avoid
swamping the NIC with individual registrations. It is possible for an
organization to be members of more than one of these networks, in which
case they register with each network, using the same name on all
networks.
The UUCP Project keeps a registry of members of the UUCP Zone. This
registry is different than the UUCP map, although the registry is posted
with the UUCP map. The UUCP Zone registry consists only of organizations
which are members of the UUCP Zone. To become a member, it is
necessary to explicitly join, just as one joins CSNET or BITNET. Just
being reachable via a bang path does not imply membership, nor does
appearance in the UUCP map.
To join the UUCP Zone, it is necessary to apply for membership. This
will involve paying a small membership fee to the project, deciding how to
structure your domain and where to put it into the global domain tree,
installing software such as smail, finding a forwarder, and doing some
electronic paperwork. Please contact us at one of these addresses and
ask for the membership kit; it will contain up-to-date information on
joining, including the fee structure, information about forwarders,
information about 3rd level domain "parks", and forms to fill out.
See the "Contact Information" below for instructions to contact us;
please use the "query" address for the initial query.
Organizational Registry
If you are registering your organization in the UUCP zone, you are in
effect creating another zone registry for your organization. Any
subdomains of your organizational domain must be registered with you.
(You need not keep us informed of all your subdomains, just the gateways.)
For the time being, unless you are ready to start organizing the machines
in your organization, don't worry about this. You can just set things up
to handle your one machine (or more if you like). Just keep in mind that
your machine is but one machine in your organization, so you should be
planning to have an address like fred@compsci.BigCorp.COM (where "fred" is
a login name on machine "compsci" owned by organization "BigCorp") rather
than fred@BigCorp.COM.
For example, if you are the first host in the University of North Dakota to
join, you are creating a subdomain UND.EDU (for example.) Your host might
have a name like undvax.UND.EDU. When other machines are joined in later,
they will also register under UND.EDU, for example, cs3b20.UND.EDU.
All subdomains of UND (this may mean all hosts in the UND domain) are
registered with the UND.EDU registry. Unless you create a campus organization
specifically to run this registry, this means you are the UND.EDU registry.
It is your job to keep track of everybody in the registry, hand out names
for subdomains, make sure there are no duplicates (you have to make sure there
aren't two machines called cs3b2.UND.EDU, for example) and know who to
contact if a problem arises. You have created the UND Zone, which is
similar to the UUCP Zone, but one level further down in the heirarchy.
At some point, you may decide that you want more layers of subdomains in
your zone. For example, if the CS, Math, and Stat departments at UND all
want to manage their own zones, you might use names like vax.CS.UND.EDU,
3b20.Math.UND.EDU, and so on. The UND Zone has delegated its naming
authority to the CS Zone, the Math Zone, and so on. The root delegates
to COM, COM delegates to UUCP, UUCP delegates to UND, UND delegates to CS.
Note that the names are given in upper or mixed case, but the exact
case doesn't matter, since the software ignores it. We recommend that
you choose your capitalization to look nice when printed.
Note also that "vax", "3b20", and the like are terrible host names,
because sooner or later you'll have more than one vax, or more than
one 3b20, and the names will be confusing. We recommend organizational
names, based on the department or project the machine is used for.
Of course, in order to keep the names reasonably short and to avoid
duplicating names in the heirarchy, some compromise will be needed.
For example, csvax.CS.UND.EDU is redundant, but RISC.CS.UND.EDU might
be a good name for the computer used by the RISC project in the CS
department.
Notes:
Organizations are encouraged to eventually support two kinds of electronic
mail addresses:
(1) Login name on machine: a string which is understood on a particular
machine, combined with a fully qualified domain name of a machine.
The string is often, although not always, a login name.
Example:
mrh@cbosgd.ATT.COM
(2) Personal name in organization: a string which is the name of a person,
understood by all gateway machines.
Example:
Mark.R.Horton@ATT.COM
This allows mail to be sent without knowing the full address
of the recipient, only their name and company. Implementations
should be as forgiving as possible of errors in the personal name.
For example, if possible, as many of the following as possible
should be accepted:
mark.r.horton@att.com (ignore case)
m.r.horton@ATT.COM (accept initials)
mark.horton@ATT.COM (don't require initials)
mark.randolph.horton@ATT.COM
m.horton@ATT.COM (if not ambiguous)
horton@ATT.COM (if not ambiguous)
mark.horton.sr@ATT.COM (allow generational qualifier)
However, it's perfectly fine to just support just one style.
Since the login name style (1) is easy to support, you may prefer to
just handle that one, especially at first. Style (1) is by far the
most commonly used method as this is written.
Please note that you should support both RFC 976 and the documents
it refers to, in particular RFC 822 and RFC 920. This means, for
example:
(a) The name "postmaster" on all machines visible to the outside
should be forwarded to the technical contact. This can be
easily done with an alias in /usr/lib/aliases, if your site
runs sendmail or smail 2.0. Please be sure to also support
Postmaster, PostMaster, and POSTMASTER, if you use sendmail.
(b) Your machine should not alter valid RFC 822 headers, such as
From:, of mail it generates or forwards. Many machines running
sendmail have a bug which adds uucpname! to the front of such
addresses. Installing smail will fix the bug, because mail
passed through the machine is not passed through sendmail.
We hope to make a fix to sendmail available, also, at a
later date.
Contact Information
We strongly encourage electronic mail for queries, updates, and
applications. This cuts down on our costs, and we can pass those
savings along to you. We currently do not have a telephone number
for queries, although we hope to have one in the near future. If
you are unable to send and receive electronic mail, you will have
to wait until we are prepared for telephone calls or postal mail.
For queries: uucp-query@Stargate.COM cbosgd!stargate!uucp-query
For updates: uucpmap@Stargate.COM cbosgd!stargate!uucpmap
For problems: uucp-problem@Stargate.COM cbosgd!stargate!uucp-problem
To register: registry@Stargate.COM cbosgd!stargate!registry
Billing/money: billing@Stargate.COM cbosgd!stargate!billing
!Funky!Stuff!
echo x - ip.dues
cat >ip.dues <<'!Funky!Stuff!'
Stargate UUCP Project Zone Membership Dues
Effective 1/1/87
Subject to change without notice
In order to provide services to the UUCP/Usenet/UNIX communities at a
low cost, an umbrella organization called Stargate Information Services
has been formed. This organization contains Project Stargate (for
satellite distribution of netnews-type materials) and the UUCP Project
(for administration of the UUCP Zone domains.) Dues and service fees
paid to the organization will be used to meet the expenses necessary to
provide these services. These expenses include telephone, equipment,
travel, legal, satellite usage, and the like. The organization is not
set up to make a profit, but to pay the expenses of the volunteers
running it. No money is budgeted for salaries for the volunteers at
this time.
This document describes the dues for belonging to the UUCP Zone,
for those UUCP organizations who wish to belong to the domain system.
Dues
Top level countries: no charge, if you run your own domain
2nd level domain: $150/year
2nd level non-UUCP domain (primary connection through ARPANET, CSNET,
BITNET, or other network that does not forward through UUCP, with
no UUCP forwarder involved):
No charge for a simple domain-only entry.
Otherwise, same as 3rd level domain.
3rd level park domain: contact the park for rates. We estimate
that basic 3rd level domains will be
available for about $50/year.
Reserving more than 5 uucp host names in the domain entry:
$1/year/host name, in addition to
membership dues. (Anything that
generates an extra line of pathalias
output counts as a host name here.)
As thanks to the organizations who have helped us work out the
initial bugs in the system, all registrations received before
December 1, 1986 are considered paid in full through June 30,
1987. Those whose applications were received in December 1986
are paid through January 1, 1987.
Send payment to:
The UUCP Project
Suite 252
4067 Hardwick St.
Lakewood, CA 90712
We accept checks and purchase orders (net 30 days). If you need
alternative billing arrangements, please contact us. Please send
notification of payment (purchase order number, amount, and billing
address; or that "the check is in the mail") electronically to
billing@stargate.com
so we may begin to process your registration.
We regret that we are not yet set up to handle telephone queries.
Please contact us by electronic mail if possible, (see the contact
information at the end of "ip.domains".) If that is not possible,
please send paper mail to the above address; if you enclose a telephone
number and a recommended time to call, we will endeavor to follow up
paper mail with a telephone call whenever possible.
Services covered by your dues (for 2nd level domain):
Membership in the UUCP Zone domain network.
Registration of 2nd level domain with the NIC.
Provision of redundant nameservers on the ARPANET,
as required by the NIC.
Monthly publication of your domain entry in a d.* file
on newsgroup mod.map.
The right to make unlimited updates to your domain entry.
Limited support* of smail.
Assistance in finding a mail forwarder from the ARPA Internet.
Services covered by your dues (for a typical 3rd level park subdomain):
Membership in the UUCP Zone domain network.
Registration of 3rd level domain with the park.
Provision of redundant nameservers on the ARPANET,
as required by the NIC, for the park.
Monthly publication of your domain entry in a d.* file
on newsgroup mod.map, depending on park policy.
The right to make unlimited updates to your domain entry.
Limited support* of smail.
Assistance in finding a mail forwarder for the park.
The following are available without charge.
The smail software package for routing mail.
Receiving the UUCP map, posted monthly to Usenet newsgroup mod.map.
Any organization, regardless of whether or not they elect to join the
UUCP Zone, may be able to receive a variety of services at low cost
directly from the community. These may include exchange of reasonable
amounts of mail and netnews via UUCP links, and gatewaying to other
networks where appropriate. While the UUCP Project can assist in the
establishment of such arrangements, it does not guarantee that these
services are available, or that they are merchantable or fit for any
particular purpose, nor do we provide these services directly.
In the future, the UUCP Project might provide services in addition to
those we presently offer. These extra-charge services could include
full support** of the smail software, UUCP access to a central machine
for mail, and other services which we do not currently provide.
* Limited support means that we will attempt to answer small numbers of
questions and fix bugs, as long as the questions and bug reports are
sent via electronic mail to the address given in the Contacts file.
**Full support means that a telephone line would be staffed during
business hours to answer questions.
!Funky!Stuff!
echo x - ip.form
cat >ip.form <<'!Funky!Stuff!'
UUCP Zone Membership Application (2nd level domain)
Updated 2/19/87
1) The name of the domain applied for.
Alpha-Beta.EDU
2) Forwarder
Foo.Bar.EDU has agreed to be our forwarder.
We will use the UUCP nameservers.
3) Type of Organization
Ph.D. granting university
4) The administrative head of the organization.
Administrator
Organization Alpha Beta University
Name John Smith
Title Department Head
Mail Address Dept of Computer Science
1234 Main St.
Hoople, ND. 90292-6695
Phone Number 213-555-1511
Net Mailbox smith@Alpha-Beta.EDU, smith@abu.uucp
NIC Handle <NEW>
5) Technical contacts.
Technical Contact
Organization Alpha Beta University
Name Jean Smith
Title Researcher
Mail Address Dept of Computer Science
1234 Main St.
Hoople, ND. 90292-6695
Phone Number 213-555-1511
Net Mailbox jean@Alpha-Beta.EDU, jean@abu.uucp
NIC Handle <NEW>
Alternate Technical Contact
Organization Alpha Beta University
Name Fred Rogers
Title Computing Staff
Mail Address Dept of Computer Science
1234 Main St.
Hoople, ND. 90292-6695
Phone Number 213-555-1511
Net Mailbox rogers@Alpha-Beta.EDU, rogers@abu.uucp
NIC Handle <NEW>
6) The zone technical contact
(same as domain technical contacts)
7) Gateway machines.
abu CS.Alpha-Beta.EDU
8) Technical contact person for each gateway.
abu, Jean Smith
9) Directory form. This is published monthly for contact
and routing information in your d.* file in mod.map.
#N .abu.edu
#F Foo.Bar.EDU
#O Alpha Beta University
#C Jean Smith, Fred Rogers
#E jean@Alpha-Beta.EDU, rogers@Alpha-Beta.EDU
#T 213-555-1511
#P Dept of Computer Science, 1234 Main St.; Hoople, ND 90292-6695
#L 35 04 05 N / 106 37 46 W city
#U dgu
#R applied
#W 10/20/86 MRH from abu!jean
#
abu .alpha-beta.edu
abu= abu.alpha-beta.edu
abu ihnp4(DEMAND), ucbvax(DAILY), dgu(DIRECT)
10) Please understand that this registration cannot be processed
without appropriate dues payment to the UUCP Project, and arrange for
dues to be paid, as described in "ip.dues".
Please understand also that it will take 2-6 weeks to fully process
this application, and that you cannot use your domain name as a return
address in outgoing mail until registration has been completed.
!Funky!Stuff!
echo x - ip.form.ins
cat >ip.form.ins <<'!Funky!Stuff!'
UUCP Zone Membership Application Instructions
Please fill out the "UUCP Zone Membership Application" form and
electronically mail it to the UUCP Domain Registrar (registry@Stargate.COM)
This document describes the form and how to fill it out. We
recommend that you edit the form, which is filled out as an example,
and change the information as appropriate for your domain.
This form is the appropriate form if you are applying for a 2nd level
domain under COM, EDU, GOV, MIL, NET, or ORG. If you are applying for
a 3rd level domain, you should check with the 2nd level domain under
which you are applying for instructions. If you are applying for a
top level domain (this option is only available to countries) check
with us directly.
1) The name of the domain applied for. This will be of the form
"yourorg.top", where "top" is one of EDU, COM, GOV, MIL, NET, or ORG.
These names are intended for organizations in the USA, although
organizations outside the USA (especially Canada) may choose to
register under one of these domains as well, if they are easily
reached via ordinary UUCP paths from well known USA hosts.
The top level domains are intended as follows:
EDU Educational institutions, especially universities and
colleges, but other schools also belong here.
COM Companies, both for-profit and non-profit. Large
companies and one-person consulting companies are
allowed here, although small companies may prefer
to use a less expensive "park" 3rd level domain.
GOV Government entities, including federal, state, and
local governments, but not military entities.
MIL Military entities. Since most military domains are
able to directly connect to DDN, special permission
from the NIC may be required for a UUCP MIL domain.
Check with the NIC at 800-235-3155 first.
NET Variously interpreted as the home for machines owned
by network information centers (such as CSNET's relay
and service hosts), physical network addresses, or
a "miscellaneous catchall". This domain is not fully
understood yet.
ORG Variously interpreted as a home for organizations to
parcel out 3rd level domains to their members, or for
nonprofit corporations. This domain is not fully
understood yet.
"yourorg" is the name of your 2nd level domain.
The name of the 2nd level domain may be up to 12 characters.
This is the name
that will be used in tables and lists associating the domain and the
domain server addresses. [While domain names can technically be
quite long (programmers beware), shorter names are easier for people
to cope with.]
You may mix upper and lower case, or use all upper or all lower case.
Software will ignore case, and most users will probably type all lower
or all upper case, depending on their terminals. You should capitalize
it as you wish it to appear in machine generated lists, such as the
return address generated in your outgoing electronic mail. Hyphens
to separate words are recommended. Legal characters are letters,
digits, and the hyphen, and upper and lower case are considered the
same. The name must be unique in its domain; thus it is not possible
for Ohio State and Oregon State to both choose OSU.EDU, but it is
possible for Times Mirror Corporation to choose TMC.COM while the
Texas Medical Center chooses TMC.EDU (watch out for possible human
confusion, however.)
For example:
> Alpha-Beta.EDU Hyphenated and spelled out
> Technical.COM Full name spelled out
> ABU.EDU Acronym in upper case.
> HighTech.COM Not recommended unless hyphen is added,
because sometimes case distinctions are
lost, and it can become hightech.com.
> Stargate.COM Stargate is one word.
2) Forwarder. Having a forwarder is not strictly required, if you
just want to reserve the name, or use it internally. However,
it is strongly recommended that you get a forwarder, otherwise
mail from DDN (the ARPANET) cannot get to you.
A forwarder is a host which is on both DDN and UUCP, which will
accept mail from DDN addressed to your domain, and forward it
via UUCP to you. Special software is required to do this; so
it is not possible for a random UNIX host on both networks to
serve as your forwarder unless they install software that
understand that a name ending in .COM or .EDU is not necessarily
on DDN. See the list of forwarders for possible contacts.
If your host is already on DDN, you should list your own host
here (if you have more than one, list your main gateway onto DDN.)
If your domain is already registered on CSNET, and you consider your
primary affiliation to be with CSNET, you should list RELAY.CS.NET
as your forwarder. Procedures for BITNET are not yet determined.
The intent is that you only need a forwarder if your primary network
is UUCP. (The "primary network" is the one via which mail from DDN
is delivered to you, if you are on more than one network, you should
choose which network to use for this.)
For example:
> Foo.Bar.EDU has agreed to be our forwarder.
DO NOT CHANGE THE NEXT LINE. This line indicates to the NIC that
mail to your COM domain should be handed off to the 3 nameservers
for UUCP: seismo.css.gov, harvard.harvard.edu, and brl.arpa. It
does not refer to nameservers on your local UUCP machines, nor to
UUCP forwarders. The ARPA nameservers are in essence 555-1212 type
services on DDN, redirecting mail and queries about domain names
to the proper DDN host. You should only change it if your primary
network is not UUCP (e.g. if it is CSNET - you would indicate that
the nameservers on RELAY.CS.NET are used) or if you really know
what you are doing.
> We will use the UUCP nameservers.
3) Type of Organization (commercial, educational, or government):
For example:
COM
> For-Profit Corporation
> Non-Profit Corporation
> For-Profit Partnership
> Proprietership
EDU
> Ph.D. granting university
> High School
GOV
> Federal Government Branch
> State Government
> City Government
MIL
> Military Branch
other
> Individual
[Note: there is currently no provision for
individuals with home computers; it is expected that
they will be handled by some sort of park with one or
two levels of subdomains, but this has not been
determined, and won't be until some demand surfaces.]
4) The administrative head of the organization.
The name, title, mailing address, phone number, and organization
of the administrative head of the organization. This is the contact
point for administrative and policy questions about the domain. In
the case of a research project, this should be the Principal
Investigator. The online mailbox and NIC Handle of this person should
also be included. We recommend you include both domain and UUCP
style addresses for everyone. This person will rarely be contacted,
and the primary reason we need this information is to know who to
contact if the technical contacts have left, so we recommend that
you choose someone you expect to be around and in a position of
authority for many years.
For example:
Administrator
> Organization Alpha Beta University
> Name John Smith
> Title Department Head
> Mail Address Dept of Computer Science
> 1234 Main St.
> Hoople, ND. 90292-6695
> Phone Number 213-555-1511
> Net Mailbox smith@Alpha-Beta.EDU, smith@abu.uucp
> NIC Handle <NEW>
5) Technical contacts.
The name, title, mailing address, phone number, and organization
of two domain technical contacts. The online mailbox and NIC Handle of
the domain technical contact should also be included. This is the
contact point for problems with the domain and for updating
information about the domain. Also, the domain technical contact may
be responsible for hosts in this domain.
Both technical contacts will be added to the domain-contacts mailing
list, to receive electronic mail about the project and about matters
related to domains. Don't list people who hate to get electronic mail.
It it not necessary that both people respond quickly to mail, but the
primary technical contact should be someone who reads their mail often
and can quickly respond should a problem arise. For very small companies,
it is permissible to have only one technical contact.
For example:
> Technical Contact
>
> Organization Alpha Beta University
> Name Jean Smith
> Title Researcher
> Mail Address Dept of Computer Science
> 1234 Main St.
> Hoople, ND. 90292-6695
> Phone Number 213-555-1511
> Net Mailbox jean@Alpha-Beta.EDU, jean@abu.uucp
> NIC Handle <NEW>
>
> Alternate Technical Contact
>
> Organization Alpha Beta University
> Name Fred Rogers
> Title Computing Staff
> Mail Address Dept of Computer Science
> 1234 Main St.
> Hoople, ND. 90292-6695
> Phone Number 213-555-1511
> Net Mailbox rogers@Alpha-Beta.EDU, rogers@abu.uucp
> NIC Handle <NEW>
6) The zone technical contact
The name, title, mailing address, phone number, and organization
of the zone technical contact is needed only if different from the
domain technical contact. The zone technical contact is the person
responsible for technical problems with the highest level zone of
authority in the domain; this zone is the same subtree of the global
naming tree as the domain, except that any subzones delegated to other
parts of the organization are not part of it. This person is almost
always the same as the domain technical contact, so leave this line
alone unless very special circumstances apply.
7) Gateway machines. Give the UUCP name and domain name of all
machines you intend to make general purpose gateways from UUCP into
your domain. These are the machines that will be running RFC 976
compatible software, such as smail, or other appropriate software,
through which mail can be sent from the outside. At first, one
gateway is probably all you'll need.
For example:
> abu CS.Alpha-Beta.EDU
8) Technical contact person for each gateway. Give the name (and
Title, Postal Address, Electronic Address, Telephone, and NIC
Handle, where different from above) of technical contact person for
each gateway.
> abu, Jean Smith
9) Directory form. This is published monthly for contact
and routing information in your d.* file in mod.map.
> #N .abu.edu
Give the name of the domain; note the leading dot. In order to make
lookup easier, by convention, all lower case is used in the #N line.
> #F Foo.Bar.EDU
This is the name of your forwarder. It should be the same as item 2 above.
If you do not have a forwarder, you should indicate either
(none) You have no forwarder and no preference
(Berkeley.EDU) A specific machine you would like to forward for
you, but which has not agreed to do so yet.
The parentheses indicate that you actually have no forwarder. If you
have more than one forwarder, use multiple #F lines.
> #O Alpha Beta University
This is the name of your organization, in human readable form.
> #C Jean Smith, Fred Rogers
The names of the technical contacts.
> #E jean@Alpha-Beta.EDU, rogers@Alpha-Beta.EDU
The electronic mail addresses, in new domain format, of the technical contacts,
in the same order as the #C line. It is permissable to use an address
such as postmaster@Alpha-Beta.EDU here. If only a postmaster address
is used, it should be forwarder to both technical contacts.
> #T 213-555-1511, 213-555-4321
The telephone numbers of the domain contacts, in the same order as the #C
line. If the same telephone number reaches both contacts, only a single
number need be given.
> #P Dept of Computer Science, 1234 Main St.; Hoople, ND 90292-6695
The paper mail address for the primary technical contact. Any paper mail
generated will use an address consisting of the #C, #O, and #P lines, thus
it is unnecessary to duplicate #C or #O information here. If you wish to
list a different postal address for the secondary contact (in the rare
case where it is different) you can use a #R line.
> #L 35 04 05 N / 106 37 46 W city
The Latitude/Longitude of the domain. (This can be taken as the location
of the gateway machine, or the headquarters, or the contact persons; usually
the gateway machine is used.) Give as much precision as you know; if you
can only determine the location to the nearest minute, or the nearest few
minutes, that's OK. Include "city" only if you are using the location of
your city center, for which information is often available in an atlas.
For more details, and heuristics for calculation of your coordinates from
nearby locations, see the README file posted to mod.map monthly. If you
are unable to determine this information, leave it blank. It is used to
draw geographic maps of the network.
> #U dgu
Machines with which your gateway has a Usenet (netnews) link. This is
rarely used, but is included for upward compatibility with the old Usenet map.
> #R applied
You can include any #R (remarks) lines you wish. The "applied" line
should be included verbatim with the application; it indicates the
status of your application, and will be changed by us to "inquiry",
"submitted", "registered", etc, as appropriate.
> #W jean@Alpha-Beta.EDU (Jean Smith); Thu Nov 20 14:51:53 CST 1986
Who last updated the line, and when. The "date" command should be used
to generate the date/time, this can easily be done from vi with, for example,
cc#W jean@Alpha-Beta.EDU (Jean Smith);ESC
:r !date
kJ
> #
This single # line is used to generate white space. Don't include blank
lines in the entry, as lookup scripts expect blank lines to separate entries.
Additional remarks can be made on lines beginning with # or #R.
The previous lines, beginning with #, are all comments to the pathalias
program. The information below is interpreted by that program, and its
format is more important. Watch out for missing commas and similar syntax
errors.
> abu .alpha-beta.edu
This line indicates that the host with UUCP name "abu" is a gateway
into the domain .alpha-beta.edu, literally, "abu can reach .alpha-beta.edu
with cost zero." You should include one of these lines for each gateway.
By convention, these are given in all lower case. If you have subdomains,
you may wish to use similar lines in internal routing distributions:
> abumath .math.alpha-beta.edu
> abu= abu.alpha-beta.edu
This line indicates that the UUCP name "abu" (also sometimes referred
to by the psuedo-domain name "abu.UUCP") and the domain name
"abu.alpha-beta.edu" are two names for the same host. Literally,
"abu.alpha-beta.edu is a nickname for abu" to pathalias. For a small
organization with only one machine (or only one machine visible to the
outside) no 3rd level name is needed, thus:
> stargate= stargate.com
If you have more than one machine, but only one gateway, you can choose
for the gateway's domain name to be either the 2nd level organizational
domain name, or a 3rd level name within the organization, thus, either
> stargate= stargate.com
or
> stargate= stargate.stargate.com
could have been used. Be sure this matches the way you've configured smail.
> abu ihnp4(DEMAND), ucbvax(DAILY),
> dgu(DIRECT), foovax(DEAD)
This is the pathalias routing information for the "abu" machine.
It lists all the direct UUCP neighbors of abu to which mail can
be sent using the host!address notation, thus, abu!ihnp4!user or
abu!ihnp4!cbosgd!user works, given the above information (plus other
information that ihnp4 can get to cbosgd.) Note the syntax rules:
commas after each ")" except that last one, lines beginning with a
tab are continuation lines. The words in parentheses describe the
"cost" to reach that host from yours, used by the pathalias "least
cost path" algorithm. Possible costs, from highest to lowest, include
DEAD A link that once worked and may work again, but not now
WEEKLY A phone call once a week
DAILY A phone call once a day
POLLED Same as DAILY; the other host polls you overnight
EVENING A phone call on demand, but only during the evening
HOURLY A phone call placed at most every hour
DEMAND A long distance phone call, placed at any time
DIRECT A local phone call, placed at any time
DEDICATED Hardwired 9600 baud link or equivalent
LOCAL A LAN, such as SMTP/Ethernet, not involving uux
A typical UUCP link is either DEMAND or DIRECT. If you use the -r option
to uux to delay calling, your UUCP links are no better than HOURLY.
There are a few variations on this involving arithmetic and preferences,
see the manual page for pathalias for more details.
10) Notices.
Please read and understand this section.
!Funky!Stuff!
echo x - ip.forwarders
cat >ip.forwarders <<'!Funky!Stuff!'
This is a list of current ARPA/UUCP mail forwarders. Only these sites
are currently set up to forward mail to UUCP COM/EDU/GOV domains. If
you prefer to use a different forwarder, please contact the postmaster
on that forwarder and inquire. If they are interested, have them
contact us (registry@stargate.com or stargate!registry) and we'll put
them in touch with a source of forwarding software. If your host is on
UUCP and DDN and you are interested in helping us out by forwarding
some traffic between UUCP and DDN, please contact us; you would be
doing the UUCP network a great service.
It is strongly recommended that UUCP domains get a forwarder. Lack of
a forwarder means that mail from the ARPANET to your domain address
will not work. If you do not have a forwarder, your alternatives
include temporarily using a subdomain of UUCP (some forwarders
translate this into a domain.UUCP!user@forwarder notation on the
ARPANET), not using your domain name, using a 3rd level domain under an
existing "park", or restricting your mail to UUCP.
There are currently only a limited number of forwarders available. We
expect to enlist several more in the next few months.
Once you select a forwarder, you should contact the forwarder directly
and inquire if they would be willing to forward for you. Remember that
they are under no obligation to do so. Once a forwarder has agreed to
forward for your domain, contact us and let us know who is forwarding
for you.
If you are not sure who to contact, we currently recommend as follows:
(1) If you are a country, or otherwise have an excellent link to seismo,
consider them.
(2) If you are near Silicon Valley, consider Sun.
(3) If you are in the Midwest, consider Illinois (either one).
(4) If you are in the Pacific Northwest, be aware that uw-beaver may
be able to start forwarding for some domains soon.
(5) If none of the above applies to you, it may be worthwhile to inquire
at a local ARPA/UUCP gateway. It is unlikely they will be able to
immediately set up the forwarding capability, but they may be able to
begin the process, allowing you to switch to them at a later date.
(6) If all else fails, consider uiucuxc and plan to move to another
forwarder when one becomes available.
-------------------------------------------------
Sun Microsystems (sun.com, sun.uucp)
Contact: Bill Nowicki (nowicki@sun.com, sun!nowicki)
1. Limited number with prior arangement.
A limit of about 20 UUCP sites per relay is reasonable to prevent
overloading. The UUCP sites should ask our permission before
registering us as their mail exchanger. If the UUCP project (e.g.
Mark Horton) gets a request to register us as the relay, they should
verify it with us before informing the NIC. We reserve the right to
terminate the relay service at any time, if, for example, the traffic
becomes too heavy.
2. Local calls only.
This limits the service to sites that are in the Palo Alto,
Mountain View, or Sunnyvale areas. Some exceptions may be granted
if the site polls us regularly instead of having us call them.
3. Preference to non-competitors.
This is purely subjective. We do our best to cooperate in a spirit
of open communication; however, we would like to avoid the awkward
situation of providing a service to our competition.
4. Preference to current direct UUCP neighbors.
We prefer to just unify the name format on our current UUCP partners
rather than add new UUCP load.
Eventually we should also provide this service for all Sun's world-wide field
offices and subsidiaries.
------------------------------------------------------------
University of Illinois, Computing Services Office
(uxc.cso.uiuc.edu, uiucuxc.uucp)
Contact: Paul Pomes (postmaster@uxc.cso.uiuc.edu, uiucuxc!postmaster)
1. Limited number with prior arangement.
A limited number of UUCP sites per relay is reasonable to prevent
overloading. The UUCP sites should ask our permission before
registering us as their mail exchanger. If the UUCP project (e.g.
Mark Horton) gets a request to register us as the relay, they should
verify it with us before informing the NIC. We reserve the right to
terminate the relay service at any time, if, for example, the traffic
becomes too heavy.
[Requesting permission can be simultaneous with sending your L.sys
information to uiucuxc!postmaster]
2. Direct UUCP connection with uiucuxc.
Any prospective MX clients should set up a bidirectional UUCP
connection with uiucuxc. Send your L.sys information to
uiucuxc!postmaster or postmaster@uxc.cso.uiuc.edu. We will install,
test the connection, and then fire a letter down the direct link with
our L.sys information.
For "L.sys Information", we want something along the lines of the
following. In particular, we want contact information. This must
include the full company or agency name, mailing address, and phone
number. Please use the format below.
# UIUC Computing Services Office (CSO), Gateway Machine, Urbana, IL
# UNIX Postmaster, UofI, CSO, 1304 W Springfield Ave, Urbana, IL 61801
# This machine is uiucuxc.uucp and "uxc.cso.uiuc.edu" on the DARPA Internet.
# Contact: uiucuxc!postmaster, postmaster@uxc.cso.uiuc.edu
# Paul Pomes, +1 217 333 6262
uiucuxc Any TCP 540 uxc.cso.uiuc.edu login: SIGNON Password: PASSWORD
uiucuxc Any ACU 2400 1-2172446290 "" \r ogin:--ogin: SIGNON word: PASSWORD
uiucuxc Any ACU 1200 1-2173334007 "" \r ogin:--ogin: SIGNON word: PASSWORD
uiucuxc Any ACU 300 1-2173334007 "" \r ogin:--ogin: SIGNON word: PASSWORD
N.B. The "" \r sequence (expect nothing, send CR) is needed to for
auto-bauding.
3. Clients may be required to poll uiucuxc
Depending on traffic levels, clients may be asked to poll uiucuxc
to pick up their mail. At first, we will deliver pending traffic
several times during the night.
4. We will route other traffic through your site.
If pathalias decides that going through your site is cheaper, we
will do it. This will defer any decisions, on an individual basis,
about requiring clients to poll uiucuxc.
------------------------------------------------------------
University of Illinois (a.cs.uiuc.edu, uiucdcs.uucp)
Contact: Ray Essick (postmaster@a.cs.uiuc.edu, uiucdcs!postmaster)
1. Limited number with prior arangement.
A limited number of UUCP sites per relay is reasonable to prevent
overloading. The UUCP sites should ask our permission before
registering us as their mail exchanger. If the UUCP project (e.g.
Mark Horton) gets a request to register us as the relay, they should
verify it with us before informing the NIC. We reserve the right to
terminate the relay service at any time, if, for example, the traffic
becomes too heavy.
[requesting permission can be simultaneous with sending your L.sys
information to uiucdcs!postmaster]
2. Direct UUCP connection with uiucdcs
Any prospective MX clients should set up a bidirectional UUCP
connection with uiucdcs. send your L.sys information to
uiucdcs!postmaster or postmaster@a.cs.uiuc.edu. we will
install & test the connection and then fire a letter down
the direct link with our L.sys information.
For "L.sys Information", we want something along the lines of
the following. in particular, we want contact information.
# UIUC CS Department, Gateway Machine, Urbana, IL
# this machine is "a.cs.uiuc.edu" on the DARPA Internet
# uiucdcs!postmaster, postmaster@a.cs.uiuc.edu
# Ruth Aydt, (217) 333-8924
uiucdcs Any TCP 540 a.cs.uiuc.edu login SIGNON password PASSWORD
uiucdcs Any ACU 2400 1-2173337866 ogin:--ogin: SIGNON word PASSWORD
uiucdcs Any ACU 1200 1-2173338267 ogin:--ogin: SIGNON word PASSWORD
uiucdcs Any ACU 300 1-2173338267 ogin:--ogin: SIGNON word PASSWORD
3. Clients may be required to poll uiucdcs
Depending on traffic levels, clients may be asked to poll uiucdcs
to pick up their mail. At first, we will deliver pending traffic
several times during the night.
4. We will route other traffic through your site.
If pathalias decides that going through your site is cheaper, we
will do it. This will defer any decisions, on an individiual basis,
about requiring clients to poll uiucdcs.
--------------------------------------------------------
Center for Seismic Studies (seismo.css.gov, seismo.uucp)
Contact: Rick Adams (rick@seismo.css.gov, seismo!rick)
Except in very special cases (i.e. a top level country domain)
seismo is not acting as mail forwarder for any additional sites.
If you feel you really must use seismo, contact registry@stargate.com
and explain why another forwarder is inappropriate. Seismo is
currently forwarding at capacity.
!Funky!Stuff!
echo x - ip.parks
cat >ip.parks <<'!Funky!Stuff!'
List of UUCP Corporate Research Parks
This is a list of organizations offering UUCP 3rd level domain
("park") services. By grouping several smaller companies under
a single 2nd level domain, only one forwarder for the entire park
is necessary, resulting in considerable cost savings. The COM
domain is shared among DDN, CSNET, UUCP, and BITNET, and each of
these domains must keep the others aware of their 2nd level domain
and how to reach each domain from each network. Often a small
company does not need to appear as a 2nd level domain, and can
benefit from the cost savings or any extra services offered by
the park.
The primary requirement for joining a park is that your domain
is entirely within UUCP. If you are on another network, in
addition to UUCP, or expect to be someday, then a park is not
for you. (If you do sign up for a park and, at a later date,
join another network, you can always change your domain name
at that time.)
----------------------------
This is a placeholder for information about specific parks.
The following people have indicated an interest in setting
up a park, but nothing official has been set up yet.
Rich $alz, rs@tmc.com, mirror!rs
Paul Vixie, hplabs!qantel!vixie!paul
Bill Blue, bblue@cts.com, cbosgd!crash!bblue
Russ Briggs, russ@11.das.com, sun!daslink!dasnet!11RUSS
!Funky!Stuff!