rfc2229.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,684 行 · 第 1/4 页

Network Working Group                                           R. Faith
Request for Comments: 2229                U. North Carolina, Chapel Hill
Category: Informational                                        B. Martin
                                                     Miranda Productions
                                                            October 1997

                      A Dictionary Server Protocol


Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1997).  All Rights Reserved.

Abstract

   The Dictionary Server Protocol (DICT) is a TCP transaction based
   query/response protocol that allows a client to access dictionary
   definitions from a set of natural language dictionary databases.

Table of Contents

   1.      Introduction .........................................    2
   1.1.    Requirements .........................................    3
   2.      Protocol Overview ....................................    3
   2.1.    Link Level ...........................................    3
   2.2.    Lexical Tokens .......................................    3
   2.3.    Commands .............................................    4
   2.4.    Responses ............................................    5
   2.4.1.  Status Responses .....................................    5
   2.4.2.  General Status Responses .............................    6
   2.4.3.  Text Responses .......................................    6
   3.      Command and Response Details .........................    7
   3.1.    Initial Connection ...................................    7
   3.2.    The DEFINE Command ...................................    9
   3.3.    The MATCH Command ....................................   10
   3.4.    A Note on Virtual Databases ..........................   12
   3.5.    The SHOW Command .....................................   13
   3.5.1.  SHOW DB ..............................................   13
   3.5.2.  SHOW STRAT ...........................................   13
   3.5.3.  SHOW INFO ............................................   14
   3.5.4.  SHOW SERVER ..........................................   14
   3.6.    The CLIENT Command ...................................   15



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


   3.7.    The STATUS Command ...................................   15
   3.8.    The HELP Command .....................................   15
   3.9.    The QUIT Command .....................................   16
   3.10.   The OPTION Command ...................................   16
   3.10.1. OPTION MIME ..........................................   16
   3.11.   The AUTH Command .....................................   18
   3.12.   The SASLAUTH Command .................................   18
   4.      Command Pipelining ...................................   20
   5.      URL Specification ....................................   20
   6.      Extensions ...........................................   22
   6.1.    Experimental Command Syntax ..........................   22
   6.2.    Experimental Commands and Pipelining .................   22
   7.      Summary of Response Codes ............................   23
   8.      Sample Conversations .................................   23
   8.1.    Sample 1 - HELP, DEFINE, and QUIT commands ...........   24
   8.2.    Sample 2 - SHOW commands, MATCH command ..............   25
   8.3.    Sample 3 - Server downtime ...........................   26
   8.4.    Sample 4 - Authentication ............................   26
   9.      Security Considerations ..............................   26
   10.     References ...........................................   27
   11.     Acknowledgements .....................................   29
   12.     Authors' Addresses ...................................   29
   13.     Full Copyright Statement .............................   30

1.  Introduction

   For many years, the Internet community has relied on the "webster"
   protocol for access to natural language definitions.  The webster
   protocol supports access to a single dictionary and (optionally) to a
   single thesaurus.  In recent years, the number of publicly available
   webster servers on the Internet has dramatically decreased.

   Fortunately, several freely-distributable dictionaries and lexicons
   have recently become available on the Internet.  However, these
   freely-distributable databases are not accessible via a uniform
   interface, and are not accessible from a single site.  They are often
   small and incomplete individually, but would collectively provide an
   interesting and useful database of English words.  Examples include
   the Jargon file [JARGON], the WordNet database [WORDNET], MICRA's
   version of the 1913 Webster's Revised Unabridged Dictionary
   [WEB1913], and the Free Online Dictionary of Computing [FOLDOC].
   Translating and non-English dictionaries are also becoming available
   (for example, the FOLDOC dictionary is being translated into
   Spanish).







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


   The webster protocol is not suitable for providing access to a large
   number of separate dictionary databases, and extensions to the
   current webster protocol were not felt to be a clean solution to the
   dictionary database problem.

   The DICT protocol is designed to provide access to multiple
   databases.  Word definitions can be requested, the word index can be
   searched (using an easily extended set of algorithms), information
   about the server can be provided (e.g., which index search strategies
   are supported, or which databases are available), and information
   about a database can be provided (e.g., copyright, citation, or
   distribution information).  Further, the DICT protocol has hooks that
   can be used to restrict access to some or all of the databases.

1.1.  Requirements

   In this document, we adopt the convention discussed in Section 1.3.2
   of [RFC1122] of using the capitalized words MUST, REQUIRED, SHOULD,
   RECOMMENDED, MAY, and OPTIONAL to define the significance of each
   particular requirement specified in this document.

   In brief: "MUST" (or "REQUIRED") means that the item is an absolute
   requirement of the specification; "SHOULD" (or "RECOMMENDED") means
   there may exist valid reasons for ignoring this item, but the full
   implications should be understood before doing so; and "MAY" (or
   "OPTIONAL") means that his item is optional, and may be omitted
   without careful consideration.

2.  Protocol Overview

2.1.  Link Level

   The DICT protocol assumes a reliable data stream such as provided by
   TCP.  When TCP is used, a DICT server listens on port 2628.

   This server is only an interface between programs and the dictionary
   databases.  It does not perform any user interaction or
   presentation-level functions.

2.2.  Lexical Tokens

   Commands and replies are composed of characters from the UCS
   character set [ISO10646] using the UTF-8 [RFC2044] encoding.  More
   specifically, using the grammar conventions from [RFC822]:







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


                                               ; (  Octal, Decimal.)
   CHAR        =  <any UTF-8 character (1 to 6 octets)>
   CTL         =  <any ASCII control           ; (  0- 37,  0.- 31.)
                   character and DEL>          ; (    177,     127.)
   CR          =  <ASCII CR, carriage return>  ; (     15,      13.)
   LF          =  <ASCII LF, linefeed>         ; (     12,      10.)
   SPACE       =  <ASCII SP, space>            ; (     40,      32.)
   HTAB        =  <ASCII HT, horizontal-tab>   ; (     11,       9.)
   <">         =  <ASCII quote mark>           ; (     42,      34.)
   <'>         =  <ASCII single quote mark>    ; (     47,      39.)
   CRLF        =  CR LF
   WS          =  1*(SPACE / HTAB)

   dqstring    =  <"> *(dqtext/quoted-pair) <">
   dqtext      =  <any CHAR except <">, "\", and CTLs>
   sqstring    =  <'> *(dqtext/quoted-pair) <'>
   sqtext      =  <any CHAR except <'>, "\", and CTLs>
   quoted-pair =  "\" CHAR

   atom        =  1*<any CHAR except SPACE, CTLs, <'>, <">, and "\">
   string      =  *<dqstring / sqstring / quoted-pair>
   word        =  *<atom / string>
   description =  *<word / WS>
   text        =  *<word / WS>

2.3.  Commands

   Commands consist of a command word followed by zero or more
   parameters.  Commands with parameters must separate the parameters
   from each other and from the command by one or more space or tab
   characters.  Command lines must be complete with all required
   parameters, and may not contain more than one command.

   Each command line must be terminated by a CRLF.

   The grammar for commands is:

             command     = cmd-word *<WS cmd-param>
             cmd-word    = atom
             cmd-param   = database / strategy / word
             database    = atom
             strategy    = atom

   Commands are not case sensitive.







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


   Command lines MUST NOT exceed 1024 characters in length, counting all
   characters including spaces, separators, punctuation, and the
   trailing CRLF.  There is no provision for the continuation of command
   lines.  Since UTF-8 may encode a character using up to 6 octets, the
   command line buffer MUST be able to accept up to 6144 octets.

2.4.  Responses

   Responses are of two kinds, status and textual.

2.4.1.  Status Responses

   Status responses indicate the server's response to the last command
   received from the client.

   Status response lines begin with a 3 digit numeric code which is
   sufficient to distinguish all responses.  Some of these may herald
   the subsequent transmission of text.

   The first digit of the response broadly indicates the success,
   failure, or progress of the previous command (based generally on
   [RFC640,RFC821]):

       1yz - Positive Preliminary reply
       2yz - Positive Completion reply
       3yz - Positive Intermediate reply
       4yz - Transient Negative Completion reply
       5yz - Permanent Negative Completion reply

   The next digit in the code indicates the response category:

       x0z - Syntax
       x1z - Information (e.g., help)
       x2z - Connections
       x3z - Authentication
       x4z - Unspecified as yet
       x5z - DICT System (These replies indicate the status of the
             receiver DICT system vis-a-vis the requested transfer
             or other DICT system action.)
       x8z - Nonstandard (private implementation) extensions

   The exact response codes that should be expected from each command
   are detailed in the description of that command.

   Certain status responses contain parameters such as numbers and
   strings.  The number and type of such parameters is fixed for each
   response code to simplify interpretation of the response.  Other
   status responses do not require specific text identifiers.  Parameter



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


   requirements are detailed in the description of relevant commands.
   Except for specifically detailed parameters, the text following
   response codes is server-dependent.

   Parameters are separated from the numeric response code and from each
   other by a single space.  All numeric parameters are decimal, and may
   have leading zeros.  All string parameters MUST conform to the "atom"
   or "dqstring" grammar productions.

   If no parameters are present, and the server implementation provides
   no implementation-specific text, then there MAY or MAY NOT be a space
   after the response code.

   Response codes not specified in this standard may be used for any
   installation-specific additional commands also not specified.

   These should be chosen to fit the pattern of x8z specified above.
   The use of unspecified response codes for standard commands is
   prohibited.

2.4.2.  General Status Responses

   In response to every command, the following general status responses
   are possible:

             500 Syntax error, command not recognized
             501 Syntax error, illegal parameters
             502 Command not implemented
             503 Command parameter not implemented
             420 Server temporarily unavailable
             421 Server shutting down at operator request

2.4.3.  Text Responses

   Before text is sent a numeric status response line, using a 1yz code,
   will be sent indicating text will follow. Text is sent as a series of
   successive lines of textual matter, each terminated with a CRLF.  A
   single line containing only a period (decimal code 46, ".") is sent
   to indicate the end of the text (i.e., the server will send a CRLF at
   the end of the last line of text, a period, and another CRLF).

   If a line of original text contained a period as the first character
   of the line, that first period is doubled by the DICT server.
   Therefore, the client must examine the first character of each line
   received.  Those that begin with two periods must have those two
   periods collapsed into one period.  Those that contain only a single
   period followed by a CRLF indicate the end of the text response.




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


   If the OPTION MIME command has been given, all textual responses will
   be prefaced by a MIME header [RFC2045] followed by a single blank
   line (CRLF).  See section 3.10.1 for more details on OPTION MIME.

   Following a text response, a 2yz response code will be sent.

   Text lines MUST NOT exceed 1024 characters in length, counting all
   characters including spaces, separators, punctuation, the extra
   initial period (if needed), and the trailing CRLF.  Since UTF-8 may
   encode a character using up to 6 octets, the text line input buffer
   MUST be able to accept up to 6144 octets.

   By default, the text of the definitions MUST be composed of
   characters from the UCS character set [ISO10644] using the UTF-8
   [RFC2044] encoding.  The UTF-8 encoding has the advantage of
   preserving the full range of 7-bit US ASCII [USASCII] values.
   Clients and servers MUST support UTF-8, even if only in some minimal
   fashion.

3.  Command and Response Details

   Below, each DICT command and appropriate responses are detailed.
   Each command is shown in upper case for clarity, but the DICT server
   is case-insensitive.

   Except for the AUTH and SASLAUTH commands, every command described in
   this section MUST be implemented by all DICT servers.

3.1.  Initial Connection

   When a client initially connects to a DICT server, a code 220 is sent
   if the client's IP is allowed to connect:

             220 text capabilities msg-id

   The code 220 is a banner, usually containing host name and DICT
   server version information.

   The second-to-last sequence of characters in the banner is the
   optional capabilities string, which will allow servers to declare
   support for extensions to the DICT protocol.  The capabilities string
   is defined below:

             capabilities =  ["<" msg-atom *("." msg-atom) ">"]
             msg-atom     =  1*<any CHAR except SPACE, CTLs,
                                "<", ">", ".", and "\">





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


   Individual capabilities are described by a single msg-atom.  For
   example, the string <html.gzip> might be used to describe a server
   that supports extensions which allow HTML or compressed output.
   Capability names beginning with "x" or "X" are reserved for
   experimental extensions, and SHOULD NOT be defined in any future DICT
   protocol specification.  Some of these capabilities may inform the
   client that certain functionality is available or can be requested.
   The following capabilities are currently defined:

       mime        The OPTION MIME command is supported
       auth        The AUTH command is supported
       kerberos_v4 The SASL Kerberos version 4 mechanism is supported
       gssapi      The SASL GSSAPI [RFC2078] mechanism is supported
       skey        The SASL S/Key [RFC1760] mechanism is supported
       external    The SASL external mechanism is supported

   The last sequence of characters in the banner is a msg-id, similar to
   the format specified in [RFC822].  The simplified description is
   given below:

       msg-id       =  "<" spec ">"            ; Unique message id
       spec         =  local-part "@" domain
       local-part   =  msg-atom *("." msg-atom)