I'm sorry, I forgot the attachment. Here it is.
--
Curtis M. Kularski
Curtis(_at_)Kularski(_dot_)net
http://PERSONAL.C-M-K.COM
http://TECH.C-M-K.COM
Microsoft Associate Expert
http://microsoft.com/windowsxp/expertzone
Ask Jeeves AnswerPoint Enthusiast (Bronze level)
http://answerpoint.ask.com
--
C. Kularski
Internet Draft
Document: draft-nameconventions-KULARSKI-00.txt
Expires: March 2002 September 2001
Additional Naming Conventions for End-user Convenience
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document will describe some naming conventions, that if
introduced as standards could make the Internet more user friendly.
These conventions will have very little impact on the Internet as a
whole, because many of these conventions are already in place.
Table of Contents (TODO: complete TOC once document finished)
Status of this Memo................................................1
Abstract...........................................................1
Overview...........................................................1
Formal Syntax.......................................................
Security Considerations.............................................
References..........................................................
Author's Addresses..................................................
Conventions for Convenience
Overview
This document contains recommended conventions for naming within the
DNS system. These conventions should be used to increase the
accessibility and overall ease-of-use for the end-user. In addition
to helping the end-user, this document is also to make domain
administration simpler for administrators, as well as substitute
administrators that may replace an organizations administrator.
Conventions used in this document
In this document, objectives, explanations, and most options are
numbered.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [1].
Conventions for Simplifying E-mail
1.1) ABUSE alias. The alias ?Abuse? used in the form of
?Abuse(_at_)Foo(_dot_)com? should be attached to every domain name. The
?abuse? alias should be directed to a person that is affiliated with
the organization that maintains the e-mail systems for the domain
name (ex. The Postmaster of Foo.com) or someone who has the power to
investigate hostile e-mail attacks that originate from the e-mail
system. If the managing party is a hosting provider, not affiliated
with the organization or persons that own the domain name, then the
?Abuse? alias should be forwarded to the hosting provider?s own
?abuse? address, or to their responsible party handling hostile
attacks. The reason for doing so is to decrease the amount of
hostile attacks that are originating from domains setup specifically
for the purpose of sending SPAM (unsolicited e-mail). As an
additional feature of the ?Abuse? alias, an auto-responder may be
added that contains additional information that can help the end-
user prevent SPAM attacks.
1.2) POSTMASTER alias. This document contains information about this
alias only to provide additional backing and support of RFC-822 [5].
1.3) WEBMASTER alias. To be used as a line of communication between
the end-users and a website?s development team or support staff. The
alias can be useful in receiving reports of system failures from
end-users. If other specialized aliases are not setup, then the
?WEBMASTER? alias should be used as a ?catch all? address for all
other inquiries from the website.
1.4) HOSTMASTER alias. To be used as a support alias for the DNS
(Domain Name System) Servers / Name Servers residing under the
domain name. If standardized Internet-wide, this alias could become
helpful in receiving problem reports when something doesn?t work
correctly, due to a DNS malfunction. The HOSTMASTER alias SHOULD NOT
be used for any purposes not affiliated with DNS management, due to
KULARSKI Informational-Expires March 2002 2
Conventions for Convenience
the alias?s long standing recognition as a support system for DNS
/NS servers. If the domain does not contain any name servers of its
own, then the alias SHOULD NOT be used, or should be used in
conjunction with an Auto-Responder, with a message stating that the
domain contains no name servers and the message should also include
additional contact information for how to communicate with the
domain?s support staff.
1.5) Banning the ?.? (dot) character in e-mail addresses. The dot
character is sometimes used to replace the ?(_at_)? (at) symbol in e-mail
addresses when they are stored in a file to be read by a machine. If
the dot character is used in the user-name portion of an e-mail
address, the part after the dot will be added AFTER the @ sybol.
Ex. John(_dot_)smith(_at_)mail(_dot_)foo(_dot_)com becomes
John(_at_)smith(_dot_)mail(_dot_)foo(_dot_)com
once converted back into normal text.
One of the systems that read e-mail addresses like that is ISC?s
BIND DNS, which serves as the DNS server software for some of the
Root-Zone servers. BIND is also in use by thousands of other DNS
servers which keep the Internet?s DNS system running.
When a request is received for an e-mail address that uses the dot
character, the request should be rejected. When the application is
rejected, a suitable alternative that may be suggested is the same
address, but with the dot character(s) being replaced with hyphen
character(s), if that type of mechanism is available.
In addition to the affect on machines already in place, removal of
the dot character from the ?username? (part before the @) will help
lower user confusion and prevent a small percentage of ?bounce-
backs? that are handled by SMTP servers.
Subdomain Usage Conventions
2.1) The WWW Subdomain. WWW is the most common subdomain used
currently on the Internet. The WWW subdomain should only be used for
data transmission on the Hyper Text Transport Protocol (HTTP) or
Gopher protocols. Normally the content should be produced in some
document standard that has been created by the Word Wide Web
Consortium (W3C). If a domain isn?t used for the purpose of
providing information on the HTTP or Gopher protocols, then the WWW
subdomain should exist as an index of services for the domain. The
index page should contain an organized list of services offered by
the domain, and instructions on how to access those resources. In
addition to an index of resources, the page should also contain some
type of contact information for the domain, if none is available,
then the data from the domain?s WHOIS record is acceptable. The
purpose of providing these resources on a domain that would not
normally be ?worthy? of a WWW subdomain is because most of the
Internet?s current audience (end-users) judge whether a domain is
?registered? or ?active? by visiting the WWW subdomain of that
domain.
KULARSKI Informational-Expires March 2002 3
Conventions for Convenience
2.2) The FTP subdomain. The FTP Subdomain should be the primary
access point for content available for transfer using the File
Transfer Protocol. If the FTP protocol is not utilized by the domain
it is not necessary to provide the FTP subdomain, because many web-
browsers and other software will only check access the FTP subdomain
using the FTP Protocol and port 21.
2.3) The MAIL subdomain. The MAIL subdomain should be used for
providing information about accessing e-mail, a CNAME record to the
POP or IMAP server, the actual IP address of the POP or IMAP server,
as the address of an E-mail Gateway, or as a location for additional
e-mail tools.
When used for providing information about accessing e-mail on the
domain, the HTTP protocol and TCP Port 80 should be used. The
information provided should include: incoming server address, port
and protocol; outgoing server address, port and protocol; the
correct format for UserID and Password entry; contact information of
the postmaster; and how to deal with any SPAM that may be received
on the account.
Using the MAIL subdomain as a CNAME record of the existing e-mail
servers is not the best utilization of the sub-domain, but it is
more useful than the sub-domain not existing.
The best way to utilize the MAIL subdomain is an e-mail gateway
service. Since most e-mail gateway services run on the HTTP
protocol, it is possible to use the sub-domain to provide
information for how to access the domain?s e-mail systems. The E-
mail Gateway itself should allow users to access their e-mail that
is on the POP or IMAP servers, without removing it. Some E-mail
Gateway software will also allow for the user to access e-mail on
other domains, without interfering with the operation of that
domain?s e-mail system. Using such as system gives end-users the
ability to not be tied to one e-mail client or computer for
accessing e-mail.
Additional e-mail tools that may be offered on the MAIL subdomain
can include tools for reporting SPAM that was received from that
domain. The additional e-mail tools should be accessible on the
HTTP protocol, allowing the ability to provide information about
accessing the e-mail servers.
2.4) The WAP subdomain. The WAP subdomain should be established and
maintained on any domain that offers access for cellular phones,
personal digital assistants (PDAs), and other devices that can
utilize ?The Wireless Web? with the WAP access protocols. The
subdomain should serve only documents that are readable by WAP
enabled devices. The subdomain hasn?t been necessary in previous
years, but now is with the growing number of WAP enabled devices
available and in current use.
2.5) The NEWS subdomain. The NEWS subdomain should be used and
established for use with NNTP and other Newsgroup servers.
Newsgroups and their predecessors (Bulletin Board Systems) are a big
KULARSKI Informational-Expires March 2002 4
Conventions for Convenience
part of the success of the Internet. Newsgroups are also a powerful
communication tool that is used by many of the developers and
administrators that help keep the Internet flowing, and it is
essential that the systems be easy to find and connect to.
Newsgroup servers are normally operated by Internet Service
Providers for their clients, but also by companies that use
newsgroups as a ?communication lifeline?.
2.6) The IPv6 subdomain. The subdomain of IPV6 is already in place
in some domains that have access to IPv6 hardware, 6BONE and an
IPv6 IP Address block. The IPv6 subdomain MUST only be used by IPv6
Address records (AAAA) attached to active IPv6 IP Addresses. This
subdomain can help to distinguish between IPv6 and IPv4 networks
during the transition to the new IPv6 system throughout the
Internet. This subdomain should contain subdomains below it for
HTTP (WWW), FTP, and other traffic. This part of this document
should be retired once IPv6 is the standard.
2.7) The LIST or Opt-In subdomain. The LIST or OPT-IN subdomain
should be used for Opt-In e-mailing lists. When using either of
these subdomains, you SHOULD make a CNAME to the one you plan to use
from the other. Establishing a LIST subdomain is simply a
convenience for users, it has no real impact on how the systems
operate. Most users are used to having all of an organization?s opt-
in lists operate in a similar manor. Using the LIST subdomain will
allow you to maintain all of the lists in an organized fashion.
Instead of creating many problems for the e-mail system by loading
it down with new aliases that support various lists, a separate
could be added to the LIST subdomain. Rather than having 50
addresses in the form of ?listA-post(_at_)foo(_dot_)org? you would be able
to
use ?A-POST(_at_)list(_dot_)foo(_dot_)org? therefore simplifying the process
for the
end-users.
Subdomain Usage as it applies to IP Addresses specified in RFC 1918
3.1) The LOCAL subdomain. The LOCAL subdomain should be used with
the IP Addresses that are covered in RFC1918, regarding IP Addresses
for Private Internets. All record types should be supported for use
on and under the LOCAL subdomain.
The purpose for such a convention is to allow easier access to
resources within an organization, by using the DNS system. For
organizations that share real IP address by using a NAT Router, or
other such IP address sharing systems; this is helpful because on
most devices, when an inside user tries to access a resource using
the outside address, the device?s HTML/HTTP based management system
is all that is accessible.
Using this subdomain can lower the amount of traffic going out on
the data lines, and can speed up access times for users within the
organization. For an average domain it takes less than 300MB of
transfer each year for DNS records, but those domains can use that
amount of transfer in a single day for HTTP, FTP, E-mail and other
servers. For data to be downloaded from a server to a workstation
that is sitting beside of it, it takes very little time when using
KULARSKI Informational-Expires March 2002 5
Conventions for Convenience
its internal address. However, when that same server is accessed by
that same workstation using its external IP address, that data MAY
have to go out of the building, down the road a few miles (to the
ISP) and then back again to the workstation, which takes more time.
Glossary
SPAM ? E-mail that is sent maliciously to many persons, whose e-mail
addresses were added to a list and distributed without their express
consent. This type of e-mail is normally generated for the purpose
of promoting a product or service, normally pornography.
Auto-Responder ? An auto-mated mechanism attached to an e-mail
system that receives messages and then immediately responds with a
pre-created document. The system may or may not save a copy of the
e-mail for human review.
Formal Syntax
The formal definition of RFC format is defined in RFC-2223 [2] and
Internet Draft instructions are available at [3].
Security Considerations
Because these conventions rely on existing technology, no additional
risk is added. Item 1.1 helps decrease the threat of a SPAM attack
to another domain, therefore improving security.
References
1 RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
2 RFC 2223
3 {I-D instruction page}
4 RFC 1918
5 RFC 822
Author's Address
Curtis M. Kularski
219 Best St Phone: 1-704-629-2498
Bessemer City, NC 28016 Email: curtis(_at_)kularski(_dot_)net
USA
KULARSKI Informational-Expires March 2002 6