rfc830.txt

RFC 的详细文档！

AFFIRMATIVE RESPONSE

   Command Type   Number of Items

   Service Indicator   Length   Transport Protocol/Service/Service Type

   Address Indicator   Address Length   Address

Examples:

   2  2
   3 13 TCP/SMTP/mail
   2  6 "10  2  0 52  6 25"

   2  3
   3 14 TCP/NIFTP/RFT
   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
same service as that of the originator.  A multi-resolution response is
possible.  The parsing of an address is implied by the indicated
transport protocol.  In the second 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), and the port
number (25 for SMTP).  The returned address(es) is to be relayed to the
originating application process.






                                   11

RFC 830                                                       October 1982

INCOMPATIBLE SERVICE

   Command Type   Number of Items

   Service Indicator   Length   Transport Protocol/Service/Service Type

   Service Indicator   Length   Transport Protocol/Service/Service Type

   Address Indicator   Address Length   Address

     This response indicates no compatible application and/or transport
service available serving the destination.  For example, SMTP may be the
requested application service, while only NIFTP-mail is available
serving the destination.  Return with this command is the available
service of that type.  If no service available for that service type, a
empty text string is returned.

Examples:

   9  2
   3 14 TCP/NIFTP/mail
   3  0

   9  4
   3 13 TCP/NIFTP/RFT
   3 11 TCP/FTP/RFT
   2  6 "10  3  0  2  6 21"
   2  6 "39  0  0  5  6 21"

In the first example, the destination does not offer any kind of mail
service.  The second example indicates that there is no NIFTP, but FTP
available for remote file transfer service at the destination.


4.2.3 AIP/DNS Communication

     The source AIP presents its associated DNS with a fully qualified
domain specification for resolution.  The expected resolution result is
the network address for the destination endpoint DNS.  We assume no need
for communication between the DNS and AIP at the destination.

REQUEST

   Command Type   Number of Items

   Name Indicator   Name Length   Name String

Examples:

   1  1
   1 14 F.ISI.USC.ARPA

   1  1
   1 12 TSC.SRI.ARPA

                                   12

RFC 830                                                       October 1982



AFFIRMATIVE RESPONSE

   Command Type   Number of Items

   Name Indicator   Name Length    Name String

   Service Indicator   Service Length   Transport Protocol

   Address Indicator   Address Length   Address

Examples:

   2  3
   1 14 F.ISI.USC.ARPA
   3  3 UDP
   2  6 "10  2  0 52 17 42"

   2  4
   1  7 TSC.SRI.ARPA
   3  3 UDP
   2  6 "10  3  0  2 17 42"
   2  6 "39  0  0  5 17 42"

An affirmative response returns an address of the destination endpoint
DNS.  This returned address is that of the destination DNS.  The
destination transport service needs to be indicated for guiding the
parsing of the destination address.

NEGATIVE RESPONSE

   Command Type   Number of Items

   Name Indicator   Name Length   Name String

   Name Indicator   Name Length   Partial Name String

   [Comment Indicator  Comment Length   Comment]

     This response indicates that the domain name service is unable to
resolve the given destination domain name.  It could be caused by an
unknown simple name, which may result from, for example, misspelling.
Returned with this command is the left-most portion of the specified
name containing the cause of resolution failure.

Example:

     1  3
     1  9 F.ISI.USC
     1  9 F.ISI.USC
     9 18 Resolution Failure



                                   13

RFC 830                                                       October 1982


4.2.4 DNS/DNS Communication

     The domain name service is an application independent network
service.  It provides the resolution of domain names.  For the
specification of this service the reader is referred to [2].


4.3  Transport Protocol

     For generality, this specification is intentionally transport
protocol independent.  Implications for the use of TCP and UDP are
specifically considered.

     Typically, for distributed name service a server A makes a request
to a server B, server B may need to in turn contact other servers to
complete a resolution.  TCP is a connection-oriented protocol.  It
offers reliable transport, but also imposes certain amount of overhead
for connection establishment and maintenance.  For most cases, the use
of TCP is not recommended.

     UDP is a datagram service offering a transport capacity per
datagram in excess of 500 octets.  Such capacity should suffice most
conceivable commands within this specification.  However, it does impose
a limit on the total length of a command.  In order to enhance
reliability, the request is incorporated as part of every response
command.



                       5   NCP TO TCP TRANSITION

     The Internet Naming Convention, "<user>@<domain>.  ...  . <domain>"
[1], is a generalization of "<user>@<host>", the ARPANET Naming
Convention.  It is a generalization in the sense that the ARPANET Naming
Convention can be considered as a partially qualified form of the subset
"<user>@<host>.ARPANET".  (We assume here ARPANET is a top-level domain
name.)

     For the transition from NCP to TCP, we may initially treat each
host name entry in the current host table as a subdomain of the top-
level domain ARPANET.  Thus, initially there would be a very flat domain
structure.  This structure can be gradually changed after the transition
toward a hierarchical structure when more and more domains and
subdomains are defined and name servers installed.  In the process of
this change, the host table would be gradually converted into
distributed domain tables (databases).  For the newly created domain
tables, no standard format would be required.  Each individual domain
table may have its own format suitable to the design of its associated
domain name server.




                                   14

RFC 830                                                       October 1982



REFERENCES

[1]  Su, Z. and J. Postel, "The Domain Naming Convention for Internet
User Applications,"  RFC 819, SRI International (August 1982).

[2]  Postel, J., "Domains Name Server," RFC XXX, USC/Information
Sciences Institute (to appear).

[3]  Postel, J., "Assigned Numbers," RFC 790, USC/Information Sciences
Institute (September 1981).










































                                   15

RFC 830                                                       October 1982



                               Appendix A


			 CONVENTION ASSIGNMENTS

     Command Types

     Request              1
     Affirmative Response 2
     Negative Response    3
     Imcompatible Service 9


     INDICATORS

     Name Indicator       1
     Address Indicator    2
     Service Indicator    3
     Comment Indicator    9


     TRANSPORT PROTOCOLS:  TCP, UDP, NCP


     SERVICES

     Service Protocols                  Service Type

     MTP                                mail
     SMTP                               mail
     FTP    (FTP mail)                  mail
     NIFTP  (NIFTP mail)                mail
     MMDF                               mail

     FTP                                RFT (remote file transfer)

     Telnet                             RTA (remote terminal access)















                                   16