rfc1835.txt

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

Deutsch, et al              Standards Track                    [Page 19]

RFC 1835          Architecture of the WHOIS++ service        August 1995


2.3.1.  Required Constraints

   The following CONSTRAINTS must be supported in all conforming WHOIS++
   servers.

     ------------------------------------------------------------------

      Format                                           LOCAL/GLOBAL
      ------                                           -------------

     SEARCH=   {exact | lstring }                      LOCAL/GLOBAL

     FORMAT=   {full | abridged | handle | summary }   GLOBAL

     MAXHITS=  { 1-<max-allowed> }                     GLOBAL

     Table III - Required WHOIS++ constraints.

     ------------------------------------------------------------------
































Deutsch, et al              Standards Track                    [Page 20]

RFC 1835          Architecture of the WHOIS++ service        August 1995


2.3.2.  Optional CONSTRAINTS

   The following CONSTRAINTS and constraint values are not required of a
   conforming WHOIS++ server, but may be supported. If supported, their
   names and supported values must be returned in the response to the
   CONSTRAINTS command.

  ---------------------------------------------------------------------

   Format                                                  LOCAL/GLOBAL
   ------                                                  -------------

  SEARCH=       { regex | fuzzy | substring | <X-format> } LOCAL/GLOBAL

  CASE=         { ignore | consider }                      LOCAL/GLOBAL

  FORMAT=       { server-to-ask | <X-format> }             GLOBAL

  MAXFULL=      { 1-<max-allowed> }                        GLOBAL

  AUTHENTICATE= password                                   GLOBAL

  NAME=         <string>                                   GLOBAL

  PASSWORD=     <string>                                   GLOBAL

  INCHARSET=    { us-ascii | iso-8859-* }                  GLOBAL

  LANGUAGE=     <As defined in ISO 639:1988>               GLOBAL

  HOLD                                                     GLOBAL

  IGNORE=       {attributelist}                            GLOBAL

  INCLUDE=      {attributelist}                            GLOBAL

                Table IV - Optional WHOIS++ constraints.

  ----------------------------------------------------------------------












Deutsch, et al              Standards Track                    [Page 21]

RFC 1835          Architecture of the WHOIS++ service        August 1995


2.3.2.1.  The SEARCH Constraint

   The SEARCH constraint is used for specifying the method that is to be
   used for the search. The default method is "exact". Following is a
   definition of each search method.


   exact           The search will succeed for a word that exactly
                   matches the search string.

   substring       The search will succeed for a word that matches
                   a part of a word.

   regex           The search will succeed for a word when a regular
                   expression matches the searched data. Regular
                   expression is built up by using constructions of
                   '*', '.', '^', '$', and '[]'. For use of
                   regular expressions see Appendix G.

   fuzzy           The search will succeed for words that matches the
                   search string by using an algorithm designed to catch
                   closely related names with different spelling, e.g.
                   names with the same pronounciation.  The server
                   chooses which algorithm to use, but it may vary
                   depending on template name, attribute name and
                   language used (see Constraint Language above).

   lstring         The search will succed for words that begins
                   with the search string.

2.3.2.2.  The FORMAT Constraint

   The FORMAT constraint describes what format the result will be in.
   Default format is FULL. For a description of each format, see Server
   Response Modes below.

2.3.2.3.  The MAXFULL Constraint

   The MAXFULL constraint sets the limit of the number of matching
   records the server allows before it enforces SUMMARY responses.  The
   client may attempt to override this value by specifying another value
   to that constraint. Example: If, for privacy reasons, the server will
   return the response in SUMMARY format if the number of hits exceeds
   2, the MAXFULL constraint is set to 2 by the server.

   Regardless of what format the client did or did not ask for, the
   server will change the response format to SUMMARY when the number of
   matching records equals or exceeds this value.



Deutsch, et al              Standards Track                    [Page 22]

RFC 1835          Architecture of the WHOIS++ service        August 1995


2.3.2.4.  The MAXHITS Constraint

   The MAXHITS constraint sets the maximum number of records the client
   can get in a search respone.

2.3.2.5.  The CASE Constraint

   The CASE constraint defines if the search should be done case
   sensistive or not. Default value is to have case ignored.

2.3.2.6.  The AUTHENTICATE Constraint

   The AUTHENTICATE constraint describes which authentication method to
   use when executing the search. By using a specific authentication
   method, some other constraints might be needed which is specified by
   the authentication method.

   The only authentication method described in this document is
   "password", if used, also the two other constraints "name" and
   "password" need to be set.

2.3.2.7.  The NAME Constraint

   The NAME constraint is only used together with some authentication
   method named by the constraint "authenticate". The only use described
   in this document is by sending a username as a string of characters
   which together with the string given as an argument to the "password"
   constraint is sent to the server. The server can use that pair of
   strings to do a simple authentication check, similar to the UNIX
   login program.

2.3.2.8.  The PASSWORD Constraint

   The PASSWORD constraint is only used together with some
   authentication method named by the constraint "authenticate". The
   only use described in this document is by sending a password as a
   string of characters which together with the string given as an
   argument to the "name" constraint is sent to the server. The server
   can use that pair of strings to do a simple authentication check,
   similar tothe UNIX login program.

2.3.2.9.  The LANGUAGE Constraint

   The LANGUAGE constraints can be used as an extra information to the
   fuzzy matching search method, and it might also be used to tell the
   server to give the system responses in another language, although
   this ability should be handled by the client. The language code
   defined in RFC 1766 [ALVE95] can be used as a value for the language



Deutsch, et al              Standards Track                    [Page 23]

RFC 1835          Architecture of the WHOIS++ service        August 1995


   constraint.  In these, the case of the letters are insignigicant.

2.3.2.10.  The INCHARSET Constraint

   The INCHARSET constraint tells the server in which character set the
   search string itself is given in. The default character set is ISO-
   8859-1.

2.3.2.11.  The IGNORE Constraint

   The IGNORE constraint specifies which attributes to NOT include in
   the result. All other attributes will be included (as if named
   explicitly by the "include" constraint).

   If an attribute is named both with the "include" and "ignore"
   constraint, the attribute is to be included in the result, but the
   system message must be "% 205 Requested constraint not fulfilled".

2.3.2.12.  The INCLUDE Constraint

   The INCLUDE constraint specifies which attributes to include in the
   result. All other attributes will be excluded (as if named explicitly
   by the "ignore" constraint).

   If an attribute is named both with the "include" and "ignore"
   constraint, the attribute is to be included in the result, but the
   system message must be "% 205 Requested constraint not fulfilled".

2.4.  Server Response Modes

   There are currently a total of five different response modes possible
   for WHOIS++ servers. These are FULL, ABRIDGED, HANDLE, SUMMARY and
   SERVER-TO-ASK. The syntax of each output format is specified in more
   detail in the following section.

     1) A FULL format response provides the complete contents of a
        template matching the specified query, including the template
        type, the server handle and an optional record handle.

     2) An ABRIDGED format response provides a brief summary, including
        (as a minimum) the server handle, the corresponding record handle
        and relevant information for that template.

     3) A HANDLE format response returns a line with information about
        the server handle and record handle for a record that matched
        the specified query.





Deutsch, et al              Standards Track                    [Page 24]

RFC 1835          Architecture of the WHOIS++ service        August 1995


     4) A SUMMARY response provides only a brief summary of information
        the number of matches and the list of template types in which the
        matches occured.

     5) A SERVER-TO-ASK response only returns pointers to other index
        servers which might possibly be able to answer the specified
        query.

   The server may respond with a null answer and may also respond with a
   null answer together with a correct system message to indicate that
   the query was too complex.

2.4.1.  Default Responses

   By default, a WHOIS++ server will provide FULL responses. This may be
   changed by the client with the use of the global constraint "format".

   The server is allowed to provide response in SUMMARY format if the
   number of hits exceeds the value of the global constraint "maxfull".

   The server will not respond with more matches than the value
   specified with the global constraint "maxhits"; Not in any response
   format. If the number of matches exceeds this value, the server will
   issues the system message 110 (maxhits value exceeded), but will
   still show the responses, up to the number of the "maxhits"
   constraint value.  This mechanism will allow the server to hide the
   number of possible matches to a search command.

   The server response modes are summarized in Table V.

2.4.2.  Format of Responses

   Each response consists of a numerical system generated message, which
   can be tagged with text, followed by an optional formatted response
   message, followed by a second system generated messages.

   That is:

        '%' <system messages> <nl>

        [ <formatted response> ]

        '%' <system messages> <nl>


   If there are no matches to a query, the system is not required to