Trailing-Edge - PDP-10 Archives - SRI_NIC_PERM_SRC_1_19910112 - 6-1-monitor/domain.req
There are no other files named domain.req in the archive.
 4-Apr-88 16:20:27-PDT,24656;000000000001
Return-Path: <>
Received: from by SRI-NIC.ARPA with TCP; Mon 4 Apr 88 16:17:29-PDT
Received: from by (5.54/5.51)
	id AA16783; Mon, 4 Apr 88 16:17:55 PDT
Date: Mon, 4 Apr 88 16:17:29 PDT
Posted-Date: Mon, 4 Apr 88 16:17:29 PDT
Message-Id: <>
Received: by (3.2/5.51)
	id AA00258; Mon, 4 Apr 88 16:17:29 PDT
Subject: How I Hacked Your Good Words

Hi. I glued together your words on UDP, mail, and domains, into an outline
of the proposed format. I also did a (little) editorial messing about.
Please let me know it you think I screwed it up, or if you dislike
something I did to your words.

Hey, thanks, guys!

Bob Braden



An Internet host will have interfaces to one or more of  the
networks  that  constitute  the  Internet.  A host which has
direct interfaces to more than one network  is  said  to  be
"multihomed".   A  network  to which a host is interfaced is
often known as the  "local  network"  or  the  "sub-network"
relative  to  that host; however, both these terms can cause
confusion, and therefore we will  use  the  term  "connected
network" or "constituent network".

The requirements for  interfacing  a  host  to  any  of  the
commonly-used  network  media  will be found in Chapter 3 of
RFC-1009 (since at the network level, the  requirements  are
identical for a host and a gateway).


((To be supplied))

                           - 2 -


There are two standard transport protocols used in the  ARPA
Internet  are the Transmission Control Protocol TCP, and the
User Datagram  Protocol  UDP.  TCP  provides  reliable,  in-
sequence  delivery  of a stream of octets (8-bit bytes). UDP
offers non-guaranteed delivery of datagrams.

TCP  is  used  by  those  applications   needing   reliable,
connection-oriented transport service, e.g., mail (SMTP, see
section 5.1), bulk file transfers (FTP,  see  section  5.2),
and virtual terminal service (TELNET, see section 5.3)..

UDP provides a minimal transport service, designed  to  give
applications direct access to the datagram service of the IP
layer.  UDP is used by applications that do not require  the
level  of  service of TCP or wish to use communications ser-
vices (e.g. multicast or broadcast delivery)  not  available
from TCP.


Military Standard Documents

*    MIL-STD-1778 - "Transmission Control  Protocol"  -  Aug

Request For Comments (RFC's)

*    RFC-768 "User Datagram Protocol", J. Postel.

*    RFC-793 "Transmission Control Protocol", J. Postel.

*    RFC-813 "Window and Acknowledgement Strategy  in  TCP",
     D. Clark.

*    RFC-817 "Modularity and Efficiency in  Protocol  Imple-
     mentation", D. Clark.

*    RFC-889 "Internet Delay Experiments", D. Mills.

                           - 3 -

*    RFC-896 "Congestion Control in IP/TCP", J. Nagle.

*    RFC-970 "On Packet Switches With Infinite Storage",  J.
     Nagle.   (also IEEE Transactions on Communications V 35
     #4 April 1987)

*    RFC-1025 "TCP and IP Bake Off", J. Postel


*    "Divergence   of   Timeout   Algorithms   for    Packet
     Retransmissions",  Raj  Jain,  Proc 5th Annual Interna-
     tional Phoenix Conference on Computers  and  Communica-
     tions, 1986.

*    "A Timeout-Based Congestion Control Scheme  for  Window
     Flow-Controlled  Networks", Raj Jain, IEEE JSAC, SAC-4-
     7, Oct86.

*    "Fragmentation Considered Harmful", Chris Kent  &  Jeff
     Mogul, SIGCOMM 1987

*    "Round Trip Time Estimation", Phil Karn  &  Craig  Par-
     tridge, SIGCOMM 1987

*    "Why TCP Timers Don't Work Well", Lixia Zhang,  SIGCOMM

*    "An  Adaptive  Timeout  Algorithm  for   Retransmission
     Across   a  Packet  Switching  Network",  Steven  Edge,
     SIGCOMM 1983.

*    "On  Caching  Out-of-order  Packets  in  Window   Flow-
     controlled Networks", Raj Jain, DEC TR-342, Jan 1985.


4.2.1 UDP -- User Datagram Protocol

                           - 4 -

UDP adds only two services to IP: ports for addressing  dif-
ferent  application-level  processes,  and  checksums of the

There are no known errors in the specification of UDP.

There is, however, one very common error in UDP  implementa-
tions:  the  checksum  algorithm is mis-implemented.  Unlike
TCP, UDP  has  an  optional  checksum;  the  value  zero  is
transmitted  in  the checksum field of a UDP header to indi-
cate no checksum.  If the transmitter actually calculates  a
UDP  checksum of zero, it must instead transmit the checksum
as all-1's (65535).  No special action is  required  at  the
receiver,  since zero and all-1's are equivalent in 1's com-
plement arithmetic.

4.2.2 TCP -- Transmission Control Protocol

((To be supplied by Craig Partridge et al))

                           - 5 -



In the TCP/IP protocol suite, electronic mail  is  exchanged
using the Simple Mail Transfer Protocol (SMTP) in the format
specified by RFC-822.

Over the years,  while  SMTP  has  remained  unchanged,  the
Internet  community has made several changes in the way SMTP
is used.  In particular, changes in address formats and  the
way mail is routed have both been affected by the conversion
to domain names.

5.1.1 References

*    RFC-821 "Simple Mail Transfer Protocol", J. Postel.

*    RFC-822 "Standard For The Format of ARPA Internet  Text
     Messages.  D. Crocker.  (Obsoletes RFC-733).

*    RFC-974 "Mail Routing and the Domain System",  C.  Par-

*    RFC-1047 "Duplicate Messages and SMTP", C. Partridge.

5.1.2 Simple Mail Transfer Protocol -- SMTP Discussion of RFC-821

The SMTP specification in RFC-821 is quite  clear  and  con-
tains  numerous examples, so implementors should not find it
difficult to understand the specification.

This section simply updates or  annotates  portions  of  the
SMTP  specification to conform with current usage.  The fol-
lowing discussion is organized by section of RFC-821.

Section 2: The SMTP Model.

The text suggests that mail is delivered  to  a  user  at  a
host.   With  the  advent  of  the domain system and of mail
routing using mail-exchanger  (MX)  resource  records  (RR),

                           - 6 -

implementors  should  now think of delivering to a user at a
domain name, which may or may not be the name of a  particu-
lar  host.   This  *does not* change the fact that SMTP is a
host-to-host mail exchange protocol, and it has no important
effects on the correctness of the SMTP model.

o    RFC-821 Section 3.3: Verifying and Expanding

     While EXPN and VRFY are not required of minimum  imple-
     mentations,  many  users of SMTP do make regular use of
     the commands and implementors should make  some  effort
     to include them in any SMTP implementation.

     However, some people believe that their membership in a
     mailing  list  should be confidential, and so we recom-
     mend that mechanisms be provided to turn off  the  EXPN
     command  either  for  selective  addresses or on a per-
     system basis.

o    RFC-821 Section 3.4: Sending and Mailing

     The commands to send to a user's terminal (SEND,  SOML,
     and SAML) have never been implemented in most mail sys-
     tems and are not generally  considered  useful  in  the
     current Internet environment.

o    RFC-821 Section 3.6: Relaying

     This section  requires  the  use  of  a  separate  mail
     envelope.   Because SMTP supports the relaying of mail,
     and requires that the return path be passed along  with
     the message from relay to relay, mail relays keep track
     of the return path and forward path for  each  message.
     This information may not be kept in the message itself.

     Furthermore, it is generally considered bad practice to
     alter  the  fields of the message itself to reflect the
     path through which the message was delivered, except to
     add  the  appropriate  "Received:" lines to the message

     The major interconnected electronic  mail  environments
     (ARPA  Internet,  CSNET,  BITNET and UUCP) are actively
     trying to encourage the use of simpler mail headers, in
     which  the  To:,  and Cc:, From:  fields are all of the

                           - 7 -

     form user@domain, and dispense with  the  more  complex
     addressing  forms  which  are  permitted under RFC-822.
     Note that it is acceptable to rewrite the header fields
     when  messages  are crossing environment boundaries and
     there is reason to believe that the receiver  will  not
     be  able  to respond to the addresses in the To, Cc and
     From fields unless they are rewritten to use  a  source

     Mail relay host systems are required to  add  a  source
     route  to  the SMTP return path of each message passing
     through the relay.  For example, if a message sent from  passes  through relays:
     and before reaching a final  desti-
     nation:, the return path should be:,

     In  addition, there has been some controversy about the
     meaning of forward and return paths  at  network  boun-
     daries (i.e. at mail gateways between various cooperat-
     ing electronic mail networks).


     <<Need to discuss relationship between relaying and  MX
     RRs -- not a problem -- just needs clarification>>

o    RFC-821 Section 4.3: Sequencing Of Commands and Replies

     There has been a problem with  SMTP  systems  that  use
     reply  codes  that  are not listed in the Command-Reply
     Sequences in this  section,  although  they  are  legal
     according  to  the  theory  of reply codes explained in
     Appendix E.  Implementors shoulld avoid  such  problems
     by  writing  software  which only sends the reply codes
     listed in this section,  but  properly  recognizes  any
     reply code that conforms to Appendix E.

o    RFC-821 Section 4.5.2: Transparency

     Implementors should  confirm  that  their  mail  system
     always  properly  adds  and  deletes  periods to ensure

                           - 8 -

     message transparency in the  cases  described  in  this

     RFC-821 Appendix E

     See notes above on section 4.3. SMTP Implementation Issues

o    Timeouts in SMTP

     RFC-821 neither encourages nor  precludes  the  use  of
     timeouts.   In practice, timeouts are a key part of any
     SMTP implementation since it is not  uncommon  for  the
     communications link to fail between peer mailers or for
     one of the mailers to hang due to a software bug.

     There are two accepted approaches to timeouts: (1)  set
     a  time limit on the entire SMTP dialogue (for a single
     mail message), or (2) place a time limit on  each  SMTP
     command  separately.   There  are  advantages  to  both
     schemes.  Timing per-command generally catches problems
     faster,  but  often  times  out remote systems that are
     still functioning but simply take too long to  respond.
     Timing  per-message  accomodates slow systems but these
     timeouts must typically be set to  high  values  (often
     more  than  an hour to accomodate very large messages),
     causing problems  to  go  undetected  for  an  extended

     Finally, it is  important  to  note  that  the  timeout
     periods  should  be  scaled  based on the message size.
     Even in systems  that  time  individual  commands,  the
     timeout  for  the final period should be adjusted based
     on message length because part of the delay in replying
     to the final period is often the time taken to copy the
     message body from temporary storage into  a  more  per-
     manent space in the system mail queues.

o    Duplicate Messages in SMTP

     One problem with  all  timeout  schemes  is  that  they
     aggravate  a  problem  in  SMTP  that permits duplicate
     copies of a message to be generated.  The problem comes
     when  the  receiving  peer  waits  a  long  time before

                           - 9 -

     responding to the final period  that  ends  a  message.
     Details  of  the  problem  and a suggested solution are
     described in RFC-1047.

     5.1.3 RFC-822 Message Formats

     RFC-822 specifies  the  Internet  standard  format  for
     electronic  mail  messages.   This  format is logically
     independent of the protocol used to transfer  the  mes-
     sage,  and  in  fact this same standard is used in some
     non-Internet mail environments (e.g., BITNET and CSNET)
     which use a different mail transfer protocol than SMTP.

     RFC-822 supercedes an older standard,  RFC-733,  which,
     although  long  out of date, may still be used in a few
     places.  The two formats are often referred  to  simply
     by number (822 and 733).

     RFC-822 is a  long  and  very  dense  document.   As  a
     result,  incomplete  or  defective  implementations are
     common.  In particular, sites often have trouble  prop-
     erly  parsing  all 822 addresses.  Unfortunately, it is
     also true that all the available  address  formats  are
     used,  and thus a conforming implementation must recog-
     nize and interpret them properly.

     One general problem that the reader should be aware  of
     throughout  the text.  The BNF grammars within the text
     of the specification are wrong.  Use the BNF summary on
     the last two pages.

     Here are notes on RFC-822, organized by section of that

o    RFC-822 Section 5

     <<Recently there was note on header-people that  stated
     that  the  military  time zones were wrong -- I need to
     retrieve it>>

     There is also a general  trend  towards  using  numeric
     instead of alphabetic timezone indicators.

o    RFC-822 Section 6.1

                           - 10 -

     Errors in  formatting  or  parsing  822  addresses  are
     unfortunately quite common.  This section mentions only
     the most common errors.  The implementor should  ensure
     that  an  implementation accepts all 822 addresses, and
     should test more than the special cases mentioned here.

     Many systems use a route-addr, an address specification
     within  angle  brackets  such  as <>,
     without a leading phrase.  Of the following examples:

         From: "Craig Partridge" <>

         From: <>

     the first 'From' field is legal, but the second is not.

     Another common error is to  leave  out  the  semi-colon
     after a group identifier.

     Many systems fail to fully qualify domain names in mes-
     sages they send out.  Headers with 'From' fields like:

         From: user@cs

     instead of


     are unfortunately quite common.

     Finally, many systems mis-parse multiple source  routes
     such as:


     <<Ed: A question that has long puzzled me: what is  the
     function  of source routes in the 822 header vs. in the
     SMTP envelope? >>

o    RFC-822 Section 6.2.3

     Although  the  use  of  domain   literals   is   strong
     discouraged, they are used occasionally and at minimum,
     mailers must be able to parse them.

     <<ANYTHING ELSE??>>

                           - 11 -


((To be supplied))


((To be supplied))



Conversion of host names to IP addresses and vice-versa is a
required function of the host.  User programs such as TELNET
need to take a host name from the user and convert it to  an
IP  address.  Previously these conversions were done using a
global host table.  The table eventually became too large to
update and distribute in a timely manner, so the domain sys-
tem was invented.  The domain system is a distributed  data-
base  used  primarily  for  the translation of host names to
host numbers.

Name to address conversion and associated conversions should
be performed using the domain name system.  In some cases, a
host may not be connected to the Internet system  and  might
require a "host table" to be used instead.  A host table may
also be used as a backup function to the domain system.

The DDN Host Table, which is being phased out <<Ed:  CAN  WE
RFC-952.  The DDN Host Table can be retrieved from  the  DDN
Network  Information Center host using the Hostname protocol
described in  RFC-953.   Hosts  using  the  Hostname  server
should  use  the  VERSION  command to check if the table has
changed before requesting the entire table with the ALL com-

The domain system is a distributed database system and  con-
sists   of   two   logically  distinct  parts,  servers  and
resolvers.  Domain servers store  authoritative  data  about
certain  sections  of  the database and answer queries about

                           - 12 -

the data.  Domain resolvers query domain servers for data on
behalf  of user processes.  Every host therefore needs a way
to resolve host names.  Some host machines will also need to
run domain servers.

The rest of this section will be concerned with  the  domain


*    RFC-952

*    RFC-953

*    RFC-974

*    RFC-1032

*    RFC-1034 "Domain Names - Concepts and Facilities",   P.
     Mockapetris.  (Obsoletes RFC-882 "RFC-883 "RFC-973).

*    RFC-1035 "Domain Names - Implementation and  Specifica-
     tion",  P.  Mockapetris.   (Obsoletes RFC-882, RFC-883,


Hosts should provide an interface to the domain  system  for
all  programs  running on the host.  The interface typically
directs program requests to a system process which  performs
the resolver function described in RFCs 1034 and 1035.  At a
minimum, the interface should provide a method for the  pro-
gram  to  ask for all information of a specific type associ-
ated with a specific name,  and  should  return  either  the
requested  information,  a  hard error code, or a soft error
indication.  The interface should pass though  the  complete
information  without modification, deletion, or ordering, so
that the interface need not be changed to acomodate new data
types.   The  soft  error indication is an essential part of
the interface, since it may not always be possible to access

                           - 13 -

particular information.

Most hosts will provide other interfaces tailored to partic-
ular  functions.   These  functions transform the raw domain
data into formats more suited to particular  functions.   It
is recommended that special interfaces be provided to facil-
itate translation between host  addresses  and  host  names.
When  the  host  name  to host address function encounters a
host with multiple addresses, it should  rank  or  sort  the
addresses  using knowledge of the immediately connected net-
work number(s), and any other applicable performance or his-
tory information.

All interfaces should provide the ability to  use  user-  or
program-  specified  search lists in locating information so
that short hands can be used for commonly used names.   How-
ever,  it  is required that a request can be presented which
indicates that the name is complete and should not  use  the
search list mechanism.


The resolver process may be designed to operate  in  one  of
two modes, general and restricted.

A general-mode resolver is a complete implementation of  the
resolver  service, and is capable of dealing with communica-
tion failures, failure of individual name servers,  location
of the proper name server for a given name, etc.

*    The resolver must implement a local caching function to
     avoid  repeated  remote  access for identical requests,
     and must timeout information in the cache.

*    The resolver must implement retransmission controls  to
     insure  that it does not waste communication bandwidth,
     and should  be  especially  careful  to  impose  finite
     bounds  on  the  amount  of  transmissions generated in
     response to a single request.

*    The resolver should be configured with start-up  infor-
     mation  pointing  to at least two root name servers and
     two name servers for the local  domain.   This  insures
     that the resolver will be able to access the whole name
     space in normal cases, and will be able to access local

                           - 14 -

     domain  information  should  the  local  network become
     disconnected from the rest of the Internet.

*    they may use TCP services where available.

A resolver in the restricted mode is a stub which relies  on
the  services  of  a  recursive name server on the connected
network or a "nearby" network.  This scheme allows the  host
to  pass  on the burden of the resolver function to a server
on another host.  This mode  is  often  essential  for  less
capable  hosts,  such  as PC's, and is also recommended when
the host is one of several workstations on a local  network,
because it allows all of the workstations to share the cache
of the recursive name server and hence reduce the number  of
domain  requests  exported  by  the  local  network.   At  a
minimum, the local resolver function should  be  capable  of
directing  its requests to redundant recursive name servers.
Note that recursive name servers are allowed to restrict the
sources  of  requests  that  they  will  honor,  so the host
administrator must verify that the service will be provided.
Restricted-mode  resolvers  may  implement  caching  if they
choose, but if so, must timeout cached information.  TCP  is
preferred, though UDP may be used.

In either mode, the local resolver should be able to  multi-
plex  concurrent  requests  if  the host supports concurrent


Applications using domain services must be able to cope with
soft  error conditions.  Applications should not loop retry-
ing soft errors, since this will typically result in a  con-
tinuous sequence of useless traffic.

Mailers are required to implement the MX scheme described in
RFC  974.  Note that a mailer will typically need to be able
to requeue outgoing mail when soft  errors  are  encountered
and move on to other requests.


Domains must be registered and administered properly.  Hosts
must  be registered within their domain, and domains must be
registered within  their  parent  domain.   See  the  Domain
Administrators Guide, RFC-1032 for details.

                           - 15 -

  <<ED's NOTE: maybe 6.1.4 does not belong in this RFC...?>>