rfc2167.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   An RWhois server can replicate (duplicate) data from another RWhois
   server on a per-authority area basis. Data replication makes the
   RWhois service more reliable. Further, it increases throughput by
   distributing queries to more than one server.

   There can be two types of servers serving an authority area: a master
   server and a slave server. A master server is where data is
   registered for an authority area. It answers authoritatively to
   queries in that authority area. There must be one and only one master
   server for an authority area. A master server is also called a
   primary server.

   A slave server is where data is replicated from the master server for
   an authority area. It also answers authoritatively to queries in that
   authority area. There may be one or more slave servers for an
   authority area. A slave server is also called a secondary server.
   Note that a slave server must not register data for an authority
   area.

   It is recommended that the master and slave servers for an authority
   area be geographically separate. Therefore, network unreachability at
   one site will not completely shut down the RWhois service for that
   authority area.



Williamson, et. al.          Informational                     [Page 13]

RFC 2167                    RWhois Protocol                    June 1997


2.6.1 Data to Replicate

   In RWhois, data is replicated on a per-authority area basis. The
   smallest type of data a slave server can replicate is an attribute of
   a class.  Therefore, a slave server can replicate data for all the
   classes, some classes, or some attributes of some classes.

   The amount of data a slave server can replicate each time is either
   all of the data or the data that has changed since the last
   replication. The process of replicating all of the data is called
   complete replication. The process of replicating the data that has
   changed since the last replication is called incremental replication.

2.6.2 Start Of Authority Variables

   Each authority area has some administrative variables, defined at the
   master server, to control data replication. These variables are
   called the Start Of Authority (SOA) variables. They are listed below.

    Serial-Number     This is the serial number of the data in an
                      authority area. The master server should update
                      this variable whenever the data in the authority
                      area is changed. Its value is a time/date stamp.

    Refresh-Interval  This is the time interval before a slave server
                      checks for complete replication. Its value is
                      specified in seconds.

    Increment-IntervalThis is the time interval before a slave server
                      checks for incremental replication. Its value is
                      specified in seconds.

    Retry-Interval    This is the time interval before a slave server
                      tries again to connect to a master server that
                      appears to be out-of-service. Its value is
                      specified in seconds.

    Time-To-Live      This is the default time to live for the data in
                      an authority area at a slave server. The slave
                      server should not answer authoritatively to
                      queries for such stale data. Its value is
                      specified in seconds.

    Admin-Contact     This is the email address of an individual or a
                      role account responsible for the data integrity in
                      an authority area at the master server.





Williamson, et. al.          Informational                     [Page 14]

RFC 2167                    RWhois Protocol                    June 1997


    Tech-Contact      This is the email address of an individual or a
                      role account responsible for the operation of the
                      master server for an authority area.

    Hostmaster        This is the email address of an individual or a
                      role account to whom email messages to update the
                      data in an authority area at the master server are
                      sent.

    Primary-Server    This is the location of the master server for an
                      authority area. Its value must contain both the
                      host name (or IP address) and port number of the
                      master server.

3. Protocol

3.1 Overview

   The above sections describe the directory service architecture based
   on the RWhois protocol. The remaining sections describe the syntax of
   the protocol; the sequence and syntax of the information exchanged
   between a server and a client. There are five types of information
   that may be exchanged during a client/server session: directive,
   response, query, result, and info.

3.1.1 Directive

   A directive is a command that a client sends to a server to set a
   control parameter for the session, get the meta-information (class
   definitions and SOA information) about an authority area, or get the
   data in an authority area. The first character of a directive must be
   a "-". The server must support the "-rwhois" directive; all other
   directives are optional. The server must indicate in the banner which
   directives are implemented (see Section 3.1.9).

3.1.2 Response

   A response is the information that a server returns to a client for a
   directive. It is comprised of one or more lines, and the last line
   always indicates the success or failure of the directive. The first
   character of each response line must be a "%". If a server runs a
   directive successfully, the last response line must be "%ok".
   Otherwise, it must be "%error <error-code> <error-text>". A line with
   the string "%ok" or "%error" in the first position must occur only
   once in a server response and must always be the last line. The
   server may send the "%info" response for special messages.





Williamson, et. al.          Informational                     [Page 15]

RFC 2167                    RWhois Protocol                    June 1997


   A client must understand the "%ok", "%error", and "%info" responses.
   The client must also understand directive specific responses, if it
   uses the related directives to communicate with the server. For
   example, if the client sends the "-schema" directive to the server,
   the client must understand the "%schema" response.

3.1.3 Query

   A query is a command that a client sends to a server to access the
   data in an authority area. The first character of a query must not be
   a "-", since the server checks the first character of each command
   from a client to determine whether it is a directive or a query.

3.1.4 Result

   A result is the information that a server returns to a client for a
   query.  It can be either the accessed data or referrals to other
   servers. It is comprised of one or more lines, and the last line
   always indicates the success or failure of the query. If a server
   returns either data or referrals for a query, the last result line
   must be "%ok". Otherwise, it must be "%error <error-code> <error-
   text>".

3.1.5 Info

   An info message contains miscellaneous information that a server
   sends to a client. The server may use it to send special messages,
   for example a "message of the day" (MOTD), to the client. The first
   info line must be "%info on", and the last info line must be "%info
   off".

3.1.6 Client/Server Session

   A typical RWhois client/server session has the following sequence of
   messages.

      * The client connects to the server.
      * The server returns a banner identifying its protocol versions
        and capabilities.
      * The client sends one or more directives to the server.
      * The server returns the response to each directive.
      * The client finally sends a query to the server.
      * The server returns the query results.
      * The server closes the connection, unless the client has directed
        it not to close the connection.






Williamson, et. al.          Informational                     [Page 16]

RFC 2167                    RWhois Protocol                    June 1997


3.1.7 Examples

   This section gives some common examples of the client/server
   interaction.  The notation in the examples uses a prefix to indicate
   from where the information comes. A "C" indicates that the client
   sends the data to the server. An "S" indicates that the server sends
   the data to the client. The line is a comment when "#" is used. The
   space after the prefix is not part of the data.

   The following example illustrates a successful query.

   # The client connects to the server.
   # The server returns a banner identifying its protocol versions and
   # capabilities.
   S %rwhois V-1.5:00ffff:00 master.rwhois.net (Network Solutions V-1.5)
   # The client sends a directive to limit the number of search hits
   # to 20.
   C -limit 20
   # The server returns a successful response.
   S %ok
   # The client sends a query to search for rwhois.net domain.
   C domain rwhois.net
   # The server returns the data for rwhois.net domain.
   S domain:ID:dom-1.rwhois.net
   S domain:Auth-Area:rwhois.net
   S domain:Class-Name:domain
   S domain:Updated:19970107201111000
   S domain:Domain:rwhois.net
   S domain:Server;I:hst-1.rwhois.net
   S domain:Server;I:hst-2.rwhois.net
   S
   S %ok
   # The server closes the connection.

   The following example illustrates the link and punt referrals.

   # The client connects to the server.
   # The server returns a banner identifying its protocol versions and
   # capabilities.
   S %rwhois V-1.5:00ffff:00 master.rwhois.net (Network Solutions V-1.5)
   # The client sends a directive to hold the connection until it sends
   # a directive to close the connection.
   C -holdconnect on
   # The server returns a successful response.
   S %ok
   # The client sends a query to search for a.b.rwhois.net domain.
   C domain a.b.rwhois.net
   # The server returns a link referral to a server serving the



Williamson, et. al.          Informational                     [Page 17]

RFC 2167                    RWhois Protocol                    June 1997


   # b.rwhois.net authority area.
   S %referral rwhois://master.b.rwhois.net:4321/auth-area=b.rwhois.net
   S %ok
   # The client sends a query to search for internic.net domain.
   C domain internic.net
   # The server returns a punt referral to a server serving the root
   # authority area.
   S %referral rwhois://rs.internic.net:4321/auth-area=.
   S %ok
   # The client sends a directive to close the connection.
   C -quit
   S %ok
   # The server closes the connection.

   The following example illustrates a query error.

   # The client connects to the server.
   # The server returns a banner identifying its protocol versions and
   # capabilities.
   S %rwhois V-1.5:00ffff:00 master.rwhois.net (Network Solutions V-1.5)
   # The client sends a query to search for c.rwhois.net domain.
   C domain c.rwhois.net
   # The server returns an error, since neither data nor referrals for
   # c.rwhois.net domain are found within the rwhois.net authority area.
   S %error 230 No objects found
   # The server closes the connection.

3.1.8 Notation

   The following sections use the Augmented Backus-Naur Form (ABNF)
   notation to describe the syntax of the protocol. For further
   information, see Section 2 of [RFC822]. The notation in the examples
   uses a prefix to indicate from where the information comes. A "C"
   indicates that the client sends the data to the server. An "S"
   indicates that the server sends the data to the client. The line is a
   comment when "#" is used. The space after the prefix is not part of
   the data.

3.1.9 General ABNF definitions

   Lexical Tokens

   alpha = "a".."z" / "A".."Z"
   digit = "0".."9"
   hex-digit = digit / "a".."f" / "A".. "F"
   id-char = alpha / digit / "_" / "-"
   any-char = <ASCII 1..255,
              except LF (linefeed) and CR (carriage return)>



Williamson, et. al.          Informational                     [Page 18]

RFC 2167                    RWhois Protocol                    June 1997


   dns-char = alpha / digit / "-"
   email-char = <see [RFC 822]>
   space = " "
   tab = <ASCII TAB (tab)>
   lf = <ASCII LF (linefeed)>
   cr = <ASCII CR (carriage return)>
   crlf = cr lf

   Grammar

   year = 4digit
   month = 2digit
   day = 2digit
   hour = 2digit
   minute = 2digit
   second = 2digit
   milli-second = 3digit
   host-name = dns-char *(dns-char / ".")
   ip-address = 1*3digit "." 1*3digit "." 1*3digit "." 1*3digit
   email = 1*email-char "@" host-name
   authority-area = (dns-char / ".") *(dns-char / "." / "/")
   object-id = 1*id-char "." authority-area
   host-port = (host-name / ip-address) ":" 1*5digit
   class-name = 1*id-char
   attribute-name = 1*id-char
   attribute-value = 1*any-char
   time-stamp = year month day hour minute second milli-second
   on-off = "on" / "off"

   Note that the time-stamp must be in the Greenwich Mean Time (GMT)
   time zone.  Also note that since in the above any-char is 1..255
   ASCII that the RWhois protocol is an 8 bit protocol.

   Response

   The general response for every directive and query is either "%ok" or
   "%error". In addition, a "%info" response may be sent.

   response = ok-response crlf / error-response crlf / info-response