Subject: re: My first rough draft of my first I-D

From: "Curtis Kularski" <[email-masked]>
Date: Wed, 12 Sep 2001 23:00:09 -0400

I'm sorry, I forgot the attachment.  Here it is. 

--
Curtis M. Kularski
[email-masked]
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 
   “[email-masked]” 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) 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.  [email-masked] becomes [email-masked] 
                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 “[email-masked]” you would be able to 
   use “[email-masked]” 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:  [email-masked] 
   USA 
    KULARSKI            Informational-Expires March 2002            6

---

From: [email-masked] (Claus Färber)
Date: 13 Sep 2001 14:22:00 +0200

>           Additional Naming Conventions for End-user Convenience

[ ] You have read RFC 2142
[ ] You have read RFC 2219
[x] You should search for RFCs and IDs covering the same topic
    before writing your own.

Claus
-- 
-------------------------------------------------- http://www.faerber.muc.de/
OpenPGP: DSS 1024/639680F0 E7A8 AADB 6C8A 2450 67EA  AF68 48A5 0E63 6396 80F0