rfc2229.txt

中、英文RFC文档大全打包下载完全版 .


RFC 2229              A Dictionary Server Protocol          October 1997


3.8.1.  Description

   Provides a short summary of commands that are understood by this
   implementation of the DICT server.  The help text will be presented
   as a textual response, terminated by a single period on a line by
   itself.  All DICT servers MUST implement this command.

3.8.2.  Responses

             113 help text follows

   This response code requires no special parameters.

3.9.  The QUIT Command

   QUIT

3.9.1.  Description

   This command is used by the client to cleanly exit the server.  All
   DICT servers MUST implement this command.

3.9.2.  Responses

             221 Closing Connection

   This response code requires no special parameters.

3.10.  The OPTION Command

3.10.1.  OPTION MIME

   OPTION MIME

3.10.1.1.  Description

   Requests that all text responses be prefaced by a MIME header
   [RFC2045] followed by a single blank line (CRLF).

   If a client requests this option, then the client MUST be able to
   parse Content-Type and Content-transfer-encoding headers, and MUST be
   able to ignore textual responses which have an unsupported content or
   encoding.  A client MUST support the UTF-8 encoding [RFC2044], which
   minimally means that the client MUST recognize UTF-8 multi-octet
   encodings and convert these into some symbol that can be printed by
   the client.





Faith & Martin               Informational                     [Page 16]

RFC 2229              A Dictionary Server Protocol          October 1997


   If a client requests this option, then the server will provide a MIME
   header.  If the header is empty, the text response will start with a
   single blank line (CRLF), in which case a client MUST interpret this
   as a default header.  The default header for SASL authentication is:

             Content-type: application/octet-stream
             Content-transfer-encoding: base64

   The default header for all other textual responses is:

             Content-type: text/plain; charset=utf-8
             Content-transfer-encoding: 8bit

   If OPTION MIME is not specified by the client, then the server may
   restrict the information content provided to the client.  For
   example, a definition may be accompanied by an image and an audio
   clip, but the server cannot transmit this information unless the
   client is able to parse MIME format headers.

   Note that, because of the line length restrictions and end-of-
   response semantics, the "binary" content-transfer-encoding MUST NOT
   be used.  In the future, extensions to the protocol may be provided
   which allow a client to request binary encodings, but the default
   SHOULD always be that the client can look for a "CRLF . CRLF"
   sequence to locate the end of the current text response.  This allows
   clients to easily skip over text responses which have unsupported
   types or encodings.

   In the future, after significant experience with large databases in
   various languages has been gained, and after evaluating the need for
   specifying character sets and other encodings (e.g., compressed or
   BASE64 encoding), standard extensions to this protocol should be
   proposed which allow the client to request certain content types or
   encodings.  Care should be taken that these extensions do not require
   a handshake which defeats pipelining.  In the mean time, private
   extensions should be used to explore the parameter space to determine
   how best to implement these extensions.

   OPTION MIME is a REQUIRED server capability, all DICT servers MUST
   implement this command.

3.10.1.2.  Responses

             250 ok (optional timing information here)

   Note that some older server implementations, completed before this
   document was finalized, will return a status code 500 if this command
   is not implemented.  Clients SHOULD be able to accept this behavior,



Faith & Martin               Informational                     [Page 17]

RFC 2229              A Dictionary Server Protocol          October 1997


   making default assumptions.  Clients may also examine the
   capabilities string in the status code 220 header to determine if a
   server supports this capability.

3.11.  The AUTH Command

   AUTH username authentication-string

3.11.1.  Description

   The client can authenticate itself to the server using a username and
   password.  The authentication-string will be computed as in the APOP
   protocol discussed in [RFC1939].  Briefly, the authentication-string
   is the MD5 checksum of the concatenation of the msg-id (obtained from
   the initial banner) and the "shared secret" that is stored in the
   server and client configuration files.  Since the user does not have
   to type this shared secret when accessing the server, the shared
   secret can be an arbitrarily long passphrase.  Because of the
   computational ease of computing the MD5 checksum, the shared secret
   should be significantly longer than a usual password.

   Authentication may make more dictionary databases available for the
   current session.  For example, there may be some publicly
   distributable databases available to all users, and other private
   databases available only to authenticated users.  Or, a server may
   require authentication from all users to minimize resource
   utilization on the server machine.

   Authentication is an optional server capability.  The AUTH command
   MAY be implemented by a DICT server.

3.11.2.  Responses

             230 Authentication successful
             531 Access denied, use "SHOW INFO" for server information

   These response codes require no special parameters.

3.12.  The SASLAUTH Command

   SASLAUTH mechanism initial-response
   SASLRESP response

3.12.1.  Description

   The Simple Authentication and Security Layer (SASL) is currently
   being developed [RFC2222].  The DICT protocol reserves the SASLAUTH
   and SASLRESP commands for this method of authentication.  The results



Faith & Martin               Informational                     [Page 18]

RFC 2229              A Dictionary Server Protocol          October 1997


   of successful authentication with SALSAUTH will be the same as the
   results of successful AUTH authentication: more dictionary databases
   may become available for the current session.

   The initial-response is an optional parameter for the SASLAUTH
   command, encoded using BASE64 encoding [RFC2045].  Some SASL
   mechanisms may allow the use of this parameter.  If SASL
   authentication is supported by a DICT server, then this parameter
   MUST also be supported.

   A typical SASL authentication will be initiated by the client using
   the SASLAUTH command.  The server will reply with status code 130,
   followed by a challenge.  The challenge will be followed by status
   code 330, indicating that the client must now send a response to the
   server.

   Depending on the details of the SASL mechanism currently in use, the
   server will either continue the exchange using status code 130, a
   challenge, and status code 330; or the server will use status code
   230 or 531 to indicate authentication was successful or has failed.

   The challenges sent by the server are defined by the mechanisms as
   binary tokens of arbitrary length, and should be sent using a
   standard DICT textual response, as described in section 2.4.3.  If
   OPTION MIME is not set, then BASE64 encoding MUST be used.  If

   OPTION MIME is set, then BASE64 is the default encoding, as specified
   in section 3.10.1.

   The client will send all responses using the SASLRESP command and a
   BASE64-encoded parameter.  The responses sent by the client are
   defined by the mechanisms as binary tokens of arbitrary length.
   Remember that DICT command lines may only be 1024 characters in
   length, so the response provided by a DICT client is limited.

   If the mechanism specified in the SASLAUTH command is not supported,
   then status code 532 will be returned.

   Authentication is an optional server capability.  The SASLAUTH
   command MAY be implemented by a DICT server.

3.12.2.  Responses

             130 challenge follows
             330 send response
             230 Authentication successful
             531 Access denied, use "SHOW INFO" for server information
             532 Access denied, unknown mechanism



Faith & Martin               Informational                     [Page 19]

RFC 2229              A Dictionary Server Protocol          October 1997


        These response codes require no special parameters.

4.  Command Pipelining

   All DICT servers MUST be able to accept multiple commands in a single
   TCP send operation.  Using a single TCP send operation for multiple
   commands can improved DICT performance significantly, especially in
   the face of high latency network links.

   The possible implementation problems for a DICT server which would
   prevent command pipelining are similar to the problems that prevent
   pipelining in an SMTP server.  These problems are discussed in detail
   in [RFC1854], which should be consulted by all DICT server
   implementors.

   The main implication is that a DICT server implementation MUST NOT
   flush or otherwise lose the contents of the TCP input buffer under
   any circumstances whatsoever.

   A DICT client may pipeline several commands and must check the
   responses to each command individually.  If the server has shut down,
   it is possible that all of the commands will not be processed.  For
   example, a simple DICT client may pipeline a CLIENT, DEFINE, and QUIT
   command sequence as it is connecting to the server.  If the server is
   shut down, the initial response code sent by the server may be 420
   (temporarily unavailable) instead of 220 (banner).  In this case, the
   definition cannot be retrieved, and the client should report and
   error or retry the command.  If the server is working, it may be able
   to send back the banner, definition, and termination message in a
   single TCP send operation.

5.  URL Specification

   The DICT URL scheme is used to refer to definitions or word lists
   available using the DICT protocol:


   dict://<user>;<auth>@<host>:<port>/d:<word>:<database>:<n>
   dict://<user>;<auth>@<host>:<port>/m:<word>:<database>:<strat>:<n>


   The "/d" syntax specifies the DEFINE command (section 3.2), whereas
   the "/m" specifies the MATCH command (section 3.3).








Faith & Martin               Informational                     [Page 20]

RFC 2229              A Dictionary Server Protocol          October 1997


   Some or all of "<user>;<auth>@", ":<port>", "<database>", "<strat>",
   and "<n>" may be omitted.

   "<n>" will usually be omitted, but when included, it specifies the
   nth definition or match of a word.  A method for extracting exactly
   this information from the server is not available using the DICT
   protocol.  However, a client using the URL specification could obtain
   all of the definitions or matches, and then select the one that is
   specified.

   If "<user>;<auth>@" is omitted, no authentication is done.  If
   ":<port>" is omitted, the default port (2628) SHOULD be used.  If
   "<database>" is omitted, "!" SHOULD be used (see section 3.2).  If
   "<strat>" is omitted, "." SHOULD be used (see section 3.3).

   "<user>;<auth>@" specifies the username and the type of
   authentication performed.  For "<auth>", the string "AUTH" indicates
   that APOP authentication using the AUTH command will be performed,
   whereas the string "SASLAUTH=<auth_type>" indicates that the SASLAUTH
   and SASLRESP commands will be used, with "<auth_type>" indicating the
   type of SASL authentication which will be used.  If "<auth_type>" is
   a star (decimal code 42, "*"), then the client will select some type
   of authentication.

   Whenever authentication is required, the client SHOULD request
   additional information (e.g., a passphrase) from the user.  In
   contrast to [RFC1738], clear text passwords are not permitted in the
   URL.

   Trailing colons may be omitted.  For example, the following URLs
   might specify definitions or matches:

             dict://dict.org/d:shortcake:
             dict://dict.org/d:shortcake:*
             dict://dict.org/d:shortcake:wordnet:
             dict://dict.org/d:shortcake:wordnet:1
             dict://dict.org/d:abcdefgh
             dict://dict.org/d:sun
             dict://dict.org/d:sun::1

             dict://dict.org/m:sun
             dict://dict.org/m:sun::soundex
             dict://dict.org/m:sun:wordnet::1
             dict://dict.org/m:sun::soundex:1
             dict://dict.org/m:sun:::






Faith & Martin               Informational                     [Page 21]

RFC 2229              A Dictionary Server Protocol          October 1997


6.  Extensions

   This protocol was designed so that flat text databases can be used
   with a server after a minimum of analysis and formatting.  Our
   experience is that merely constructing an index for a database may be
   sufficient to make it useful with a DICT server.  The ability to
   serve preformatted text is especially important since freely-
   available databases are often distributed as flat text files without
   any semantic mark-up information (and often contain "ASCII art" which
   precludes the automation of even simple formatting).

   However, given a database with sufficient mark-up information, it may
   be possible to generate output in a variety of different formats
   (e.g., simple HTML or more sophisticated SGML).  The specification of
   formatting is beyond the scope of this document.  The requirements
   for negotiation of format (including character set and other
   encodings) is complex and should be examined over time as more
   experience is gained.  We suggest that the use of different formats,
   as well as other server features, be explored as extensions to the
   protocol.

6.1.  Experimental Command Syntax

   Single-letter commands are reserved for debugging and testing, SHOULD
   NOT be defined in any future DICT protocol specification, and MUST
   NOT be used by any client software.

   Commands beginning with the letter "X" are reserved for experimental
   extensions, and SHOULD NOT be defined in any future DICT protocol
   specification.  Authors of client software should understand that
   these commands are not part of the DICT protocol and may not be
   available on all DICT servers.

6.2.  Experimental Commands and Pipelining

   Experimental commands should be designed so that a client can
   pipeline the experimental commands without knowing if a server
   supports the commands (e.g., instead of using feature negotiation).
   If the server does not support the commands, then a response code in
   the 5yz series (usually 500) will be given, notifying the client that
   the extension is not supported.  Of course, depending on the
   complexity of the extensions added, feature negotiation may be
   necessary.  To help minimize negotiation time, server-supported
   features may be announced in the banner (code 220) using the optional
   capabilities parameter.






Faith & Martin               Informational                     [Page 22]

RFC 2229              A Dictionary Server Protocol          October 1997


7.  Summary of Response Codes

   Below is a summary of response codes.  A star (*) in the first column
   indicates the response has defined arguments that must be provided.

      * 110 n databases present - text follows
      * 111 n strategies available - text follows
        112 database information follows
        113 help text follows
        114 server information follows
        130 challenge follows
      * 150 n definitions retrieved - definitions follow
      * 151 word database name - text follows
      * 152 n matches found - text follows
        210 (optional timing and statistical information here)
      * 220 text msg-id
        221 Closing Connection
        230 Authentication successful
        250 ok (optional timing information here)
        330 send response
        420 Server temporarily unavailable
        421 Server shutting down at operator request
        500 Syntax error, command not recognized
        501 Syntax error, illegal parameters
        502 Command not implemented