rfc830.txt

RFC 相关的技术文档

with the DNS and the application processes.


3.2  Databases for Name Resolution

     There is a database associated with each resolution module.  The
database associated with an endpoint domain contains name-to-address



                                   5

RFC 830                                                       October 1982



correspondences for the top-level domains, first-generation descendents
of the naming universe.  It facilitates the endpoint DNS resolving the
right-most simple name of a fully-qualified domain specification.

     The database associated with an intermediate domain contains name-
to-address correspondences for the first-generation subdomains of this
domain.  Thus, the required database contents among the intermediate DNS
databases are disjoint, and updates are local.

     It is also noticed that with the implementation of the SINS, there
is no need for database format standardization.


3.3  Caching

     The component processes and resolution databases constitute the
basic System for Internet Name Service.  The distributed components are
related according to the domain hierarchy.  The databases associated
with the endpoint domains are all identical.  Containing only name-to-
address correspondence for top-level domains, the endpoint database
should be rather small in size.  The disjoint nature of intermediate DNS
databases allows easy local updates.

     However, communications will be very inefficient if the Internet
name service is called for the establishment of every transaction.  A
standard solution to aleviate such inefficiency is the use of caching.

     Caching is a mechanism reusing previous resolution results.  To
expedite establishment of communication, the resolution results are
stored for future reference.  We do not incorporate caching as a
standard feature of the SINS.  However, we assume the use of caching for
efficient operations at individual implementor's discretion.



4   INTER-COMPONENT COMMUNICATIONS (THE INTERNET NAME SERVICE PROTOCOLS)

     In this section, we present a format specification for
correspondences between various component pairs.  For co-located
components, communication becomes interprocess, and the exact format
less important.  For inter-host communication, the format specification
here defines a name service protocol.

     The communicating component pairs of concern here are application
process/AIP, AIP/DNS, and AIP/AIP.  The communications employ
request/response commands.  A single command structure is adopted for
all three pairs; while communications between a particular pair may
employ a subset of the commands.  Such uniformity allows minimum
processing and maximum code sharing for implementation.




                                   6

RFC 830                                                       October 1982

4.1  Command Structure

     The basic command structure begins with two octets indicating
command type and the number of items in the command.  They are followed
by the indicated number of items.  The type of an item is indicated in
its first octet, followed by a one-octet content length, and then the
item content.  Required presence or absence and order of the items for
each component pair are specified in this section.

	Command Type   Number of Items

	Item Indicator   Content Length   Item Content
          .
          .

Command Type

     This type coded in binary number indicates whether this command is
a request, an affirmative response, or some other type of response (see
Appendix A for the command types and their corresponding code).  This
type specification implies the presence or absence and order of the
following items.

Number of Items

     This number is expressed in binary number.  It specifies the number
of following items.  Owing to the possibility of a multiple response,
this number may vary for a particular command.

Item Indicator

     This indicator defines the item type.  The possible types include:
service, name, address, and comment.  The type of an item implies its
content structure.

Content Length

     This length specification, in binary, indicates the length of the
following content in octets.  The maximum can be specified is 255, thus
the maximum length of the content.  However, this maximum may also be
constrained by the total length of the command (Section 4.3).

Item Content

     The contents for different items are:
     Service -- Transport protocol/service protocol/service type
                (ASCII). (See Appendix A for standard identifiers for
                service specifications.)
     Name -- Whole or partial name string according to Internet Naming
             Convention [1] (ASCII).
     Address -- The address is presented in binary form.  In this
                writeup, double quotes, " ", are used around decimal
                values separated by a space to represent octets of the
                binary form.

                                   7

RFC 830                                                       October 1982



                Parsing of the address is implied by the specified
                transport protocol.  In the case of TCP, the first
                four octets gives the 32-bit IP address, the 5th octet
                the IP-specific protocol number, and the 6th the TCP or
                UDP port number for the application service.

     Comment -- The item is mostly optional.  Its presence may allow
                an intermediate server passing comment to the end user.
                Error comments explaining resolution failure is an
                example of its use.


4.2  Command Specification

     In this section, we define the name service commands for the
various communication pairs.


4.2.1 Application Process/AIP Communication

     From the name service point of view, there is no need for
communication between the AIP and an application process at the
destination.  Thus, here we discuss communications at the originating
domain.

     An application process initiates a dialogue by making a request for
name service to its local AIP.  It provides the requested application
service and a destination name for resolution.

REQUEST

   Command Type   Number of Items

   Service Indicator   Length   Transport Protocol/Service/Service Type

   Name Indicator   Name Length   Name String

Examples:

   1  2
   3 13 TCP/SMTP/mail
   1 21 [e-mail]

   1  2
   3 13 TCP/NIFTP/RFT
   1 12 TSC.SRI.ARPA

     The first example is a resolution request for the name
"[e-mail]".  It is 21 octets in length.  The requested
application service is TCP/SMTP/mail.  The second example is a
resolution request for application service NIFTP at TSC.SRI.ARPA.


                                   8

RFC 830                                                       October 1982



AFFIRMATIVE RESPONSE

   Command Type   Number of Items

   Service Indicator   Length   Transport Protocol/Service/Service Type

   Name Indicator   Name Length    Name String

   Address Indicator   Address Length   Address

Examples:

   2  3
   3 13 TCP/SMTP/mail
   1 21 [e-mail]
   2  6 "10  2  0 52  6 25"

   2  4
   3 13 TCP/NIFTP/RFT
   1 12 TSC.SRI.ARPA
   2  6 "10  3  0  2  6 47"
   2  6 "39  0  0  5  6 47"

     An affirmative response implies that the destination offers the
requested service.  The parsing of an address is implied by the
indicated transport protocol.  In the first example, the transport
protocol is TCP.  Thus, the address is composed of three fields: the
internet address ("10 2 0 52"), the protocol number ("6" for TCP [3]),
and the port number ("25" for SMTP [3]).  A multiple-address response in
the second example indicates that TSC is multi-homed via both ARPANET
(net  10), and SRINET (net  39).  A multiple-resolution response is
preferred.  It offers the source a choice.

NEGATIVE RESPONSE

   Command Type   Number of Items

   Service Indicator   Length   Transport Protocol/Service/Service Type

   Name Indicator   Name Length   Name String

   Name Indicator   Name Length   Partial Name String

   [Comment Indicator   Comment Length   Comment]

     This indicates difficulty in resolution.  Returned with this
command is the left-most portion of the specified name including the
difficulty encountered.  An optional comment item may be included.




                                   9

RFC 830                                                       October 1982


Examples:

   3  4
   3 13 TCP/SMTP/mail
   1 16 [e-mail]
   1 16 [e-mail]
   9 18 Resolution Failure

   3  4
   3 13 TCP/NIFTP/RFT
   1 13 TSC..SRI.ARPA
   1  5 TSC..
   9 17 Syntactic Anomaly

In the first example, the resolution failed because USC is not top-level
domain.  The syntactic error of adajacent dots in the second example is
obvious.

INCOMPATIBLE SERVICE

     This response indicates no compatible application and/or transport
service is available at the destination.  For example, the requested
application service may be SMTP, while only FTP-mail is available at the
destination.  Return with this command is the available corresponding
available service, if any, and its address.  If no service is available
for that service type, an empty string for service specification is
returned.

   Command Type   Number of Items

   Service Indicator   Length   Transport Protocol/Service/Service Type

   Name Indicator   Name Length   Name String

   Service Indicator   Length   Transport Protocol/Service/Service Type

   [Address Indicator   Address Length   Address]

Examples:

   9  3
   3 14 TCP/NIFTP/mail
   1 21 [e-mail]
   3  0

   9  5
   3 13 TCP/NIFTP/RFT
   1 12 TSC.SRI.ARPA
   3 11 TCP/FTP/RFT
   2  6 "10  3  0  2  6 21"
   2  6 "39  0  0  5  6 21"



                                   10

RFC 830                                                       October 1982



4.2.2 AIP/AIP Communication

     Communication between the AIPs accomplishes the "what-can-you-do-
for-me" negotiation.  Examples in this section correspond to those of
Section 4.2.1.

REQUEST

   Command Type   Number of Items

   Service Indicator   Length   Transport Protocol/Service/Service Type

Examples:

   1  1
   3 13 TCP/SMTP/mail

   1  1
   3 13 TCP/NIFTP/RFT