DICT

El Protocolo de red de diccionario (inglés: DICTionary Network Protocol, o DICT para abreviar) es un protocolo transaccional de comando-respuesta sobre TCP que permite a un cliente acceder a definiciones de palabras en un diccionario, por medio de bases de datos de idiomas humanos.

Introducción

El protocolo DICT fue creado por el Grupo de desarrollo de DICT (DICT Development Group), y está descrito en el RFC 2229 (Solicitud de comentarios 2229). Su meta es sobrepasar el protocolo Webster y permitir a los clientes acceder a más diccionarios al mismo tiempo. Habitualmente los servidores DICT escuchan conexiones en el puerto TCP 2628.

Tokens utilizados

Los comandos (órdenes) y las respuestas están compuestos por caracteres del UCS ISO 10646 utilizando la codificación UTF-8 RFC 2044. Más concretamente, usando las convenciones gramaticales de RFC 822:

(Extraído del RFC 2229)

                                             ; (  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>

Comandos

La forma de ejecutar los comandos es la siguiente:

Se utiliza una palabra de comando, seguida opcionalmente de parámetros.
Los comandos con parámetros deben separar los parámetros entre sí en la línea mediante espacios o caracteres TAB.
Las líneas de comando deben estar completas (es decir, con todos los parámetros requeridos) y debe haber un solo comando por línea (no hay forma de poner varios comandos en una sola línea).
Cada línea de comando debe terminar con CRLF.

La gramática para los comandos es la siguiente:

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

No hay diferenciación entre mayúsculas y minúsculas.
Las líneas de comando no pueden exceder la longitud de 1024 caracteres, incluyendo espacios, separadores, caracteres de puntuación y la secuencia CRLF al final (es decir, el texto de la línea en sí no puede exceder 1022 caracteres).

Comandos definidos en la RFC 2229

DEFINE <base de datos> <palabra>: Solicita al servidor buscar la definición de una palabra en una base de datos específica. Se puede usar el comodín "!" (decimal 33) como nombre de base de datos para buscar definiciones en todas las bases de datos hasta encontrar la primera coincidencia, y luego mostrar todas las definiciones encontradas en esa base de datos; también se puede usar el comodín "*" (decimal 42) para mostrar todas las coincidencias en todas las bases de datos. Las bases de datos se deben consultar en el orden que muestra el comando SHOW DATABASES. Si no se usan los comodines, la base de datos especificada debe estar en la lista que muestra el comando SHOW DATABASES; de lo contrario, el servidor responderá con el código de estado 550, que indica que la base de datos no es válida. Si la palabra buscada no fue encontrada, el servidor responde con el código de estado 552, que indica que no se encontró ninguna coincidencia. Si la palabra buscada sí se encontró, el servidor enviará en una línea el código de estado 150, seguido del número de bloques de definición encontrados y, opcionalmente, más texto (p. ej.: la línea será "150 3 definiciones encontradas" o "150 3 entradas; sigue el texto"). Después, por cada bloque de definición, el servidor enviará en una línea el código de estado 151, seguido de la palabra buscada, el nombre corto de la base de datos, y el nombre largo de ésta, separados por espacios y rodeados con comillas dobles (decimal 34) si contienen espacios. Luego de esa línea, inicia el texto de la definición en sí (opcionalmente prefijado con encabezados y una línea en blanco según si se ha ejecutado anteriormente o no el comando OPTION MIME), el cual es una respuesta de texto y, por lo tanto, termina con la secuencia <CRLF>.<CRLF>; finalmente, después de enviar todos los bloques de definición, el servidor envía en otra línea el código de estado 250, seguido opcionalmente de texto y/o información estadística y de cronometraje.

MATCH <base de datos> <estrategia> <palabra>: Solicita al servidor buscar una palabra en una base de datos utilizando una estrategia de búsqueda específica. Se puede usar el comodín "." (decimal 46) para indicar una estrategia por defecto del servidor, que debería ser la más apropiada para revisión interactiva de ortografía. Normalmente es una derivada del algoritmo de Levenshtein. La especificación de base de datos es idéntica a la del comando DEFINE. Si no se usa el comodín ".", la estrategia especificada debe estar en la lista que muestra el comando SHOW STRATEGIES; de lo contrario, el servidor responderá con el código de estado 551, que indica que la estrategia no es válida. Si la palabra buscada no fue encontrada, el servidor responde con el código de estado 552, que indica que no se encontró ninguna coincidencia. Si la palabra buscada sí se encontró, el servidor enviará en una línea el código de estado 152, seguido del número de coincidencias encontradas y, opcionalmente, más texto (p. ej.: la línea será "152 3 coincidencias encontradas" o "150 3 entradas; sigue el texto"). Después, por cada coincidencia, el servidor enviará en una línea el nombre corto de la base de datos y la palabra que coincide, separados por un espacio y rodeados con comillas dobles (decimal 34) si contienen espacios. Las coincidencias son una respuesta de texto y, por lo tanto, ésta termina con la secuencia <CRLF>.<CRLF>; finalmente, el servidor envía en otra línea el código de estado 250, seguido opcionalmente de texto y/o información estadística y de cronometraje.

SHOW DATABASES (se puede abreviar como SHOW DB): Muestra una lista de bases de datos. No recibe parámetros. Si no hay bases de datos disponibles, el servidor responde con el código de estado 554, que indica que no hay ninguna base de datos disponible en el momento (puede que haya más bases de datos disponibles después de autenticarse con el servidor usando los comandos AUTH y SASLAUTH). Si existen bases de datos disponibles, el servidor enviará en una línea el código de estado 110, seguido del número de bases de datos disponibles y, opcionalmente, más texto (p. ej.: la línea será "110 3 bases de datos disponibles" o "110 3 diccionarios; sigue la lista"). Después, por cada base de datos, el servidor enviará en una línea el nombre corto y el nombre largo de la base de datos, separados por un espacio y rodeados con comillas dobles (decimal 34) si contienen espacios. La lista es una respuesta de texto y, por lo tanto, ésta termina con la secuencia <CRLF>.<CRLF>; finalmente, el servidor envía en otra línea el código de estado 250, seguido opcionalmente de texto y/o información estadística y de cronometraje.

SHOW STRATEGIES (se puede abreviar como SHOW STRAT): Muestra una lista de estrategias que se pueden usar con el comando MATCH. No recibe parámetros. Si no hay estrategias disponibles, el servidor responde con el código de estado 555, que indica que no hay ninguna estrategia disponible en el momento (puede que haya más estrategias disponibles después de autenticarse con el servidor usando los comandos AUTH y SASLAUTH). Si existen estrategias disponibles, el servidor enviará en una línea el código de estado 111, seguido del número de bases de datos disponibles y, opcionalmente, más texto (p. ej.: la línea será "111 3 estrategias disponibles" o "111 3 estrategias; sigue la lista"). Después, por cada estrategia, el servidor enviará en una línea el nombre corto y el nombre largo de la estrategia, separados por un espacio y rodeados con comillas dobles (decimal 34) si contienen espacios. La lista es una respuesta de texto y, por lo tanto, ésta termina con la secuencia <CRLF>.<CRLF>; finalmente, el servidor envía en otra línea el código de estado 250, seguido opcionalmente de texto y/o información estadística y de cronometraje.

SHOW INFO <base de datos>: Muestra información sobre la base de datos especificada como parámetro. Si la base de datos especificada no existe o no está disponible, el servidor responde con el código de estado 550, que indica que esa base de datos no es válida (puede que haya más bases de datos disponibles después de autenticarse con el servidor usando los comandos AUTH y SASLAUTH). Si la base de datos está disponible, el servidor enviará en una línea el código de estado 112, seguido opcionalmente de más texto (p. ej.: la línea será "112 info. de la base de datos" o "112 sigue la información de base de datos"). Después, el servidor enviará la información acerca de la base de datos. La información es una respuesta de texto y, por lo tanto, ésta termina con la secuencia <CRLF>.<CRLF>; finalmente, el servidor envía en otra línea el código de estado 250, seguido opcionalmente de texto y/o información estadística y de cronometraje.

SHOW SERVER: Muestra información acerca del servidor. No recibe parámetros. El servidor enviará en una línea el código de estado 114, seguido opcionalmente de más texto (p. ej.: la línea será "114 info. del servidor" o "114 sigue la información del servidor"). Después, el servidor enviará información acerca de sí mismo. La información es una respuesta de texto y, por lo tanto, ésta termina con la secuencia <CRLF>.<CRLF>; finalmente, el servidor envía en otra línea el código de estado 250, seguido opcionalmente de texto y/o información estadística y de cronometraje.

OPTION MIME: Habilita los encabezados de las Extensiones multipropósito para correo de Internet: es decir, indica al servidor que envíe encabezados MIME y una línea en blanco antes del texto propiamente dicho de las definiciones futuras. No recibe parámetros. El servidor responde con el código 250, seguido opcionalmente de texto.

CLIENT [texto]: Permite al cliente identificarse, con posibles propósitos de registros y estadísticas. Normalmente los clientes DICT envían este comando. El servidor responde con el código 250, seguido opcionalmente de texto y/o información estadística y de cronometraje.

STATUS: Muestra información de cronometraje o para depuración del servidor DICT. El servidor responde con el código 210, seguido opcionalmente de texto y/o información estadística y de cronometraje. Es obligatorio implementar este comando pero enviar texto en la línea de estado es opcional (es decir, la línea puede ser simplemente un "210" o ser "210 [tardó 4.52 s en procesar]").

HELP: Muestra información de ayuda, normalmente en forma de una guía de comandos que indica cuáles admite el servidor. No recibe parámetros. El servidor enviará en una línea el código de estado 113, seguido opcionalmente de más texto (p. ej.: la línea será "113 guía de comandos" o "113 sigue el texto de ayuda"). Después, el servidor enviará la información de ayuda. La información es una respuesta de texto y, por lo tanto, ésta termina con la secuencia <CRLF>.<CRLF>; finalmente, el servidor envía en otra línea el código de estado 250, seguido opcionalmente de texto y/o información estadística y de cronometraje.

QUIT: Indica al servidor DICT que cierre la conexión. Los clientes normalmente envían este comando antes de cerrar la conexión. El servidor responde con el código 221, seguido opcionalmente de texto y/o información estadística y de cronometraje. Es obligatorio implementar este comando pero enviar texto en la línea de estado es opcional (es decir, la línea puede ser simplemente un "221" o ser "221 adiós [tardó 4.52 s en procesar]").
AUTH <usuario> <cadena hexadecimal>: Autentica al cliente con el servidor. El cliente especifica un nombre de usuario como primer parámetro. Después, concatena la contraseña al final del Id. de mensaje enviado por el servidor al abrir la conexión (incluyendo los símbolos "<" y ">"), y calcula la suma de comprobación MD5 de la cadena resultante. Por ejemplo, si el Id. de mensaje es "<12345.1234.1234567890@dict.example.org>" y la contraseña es "qwerty", la cadena hexadecimal que se debe enviar es 98d556b67c89eba2efeac44ae9024364 (es decir, el resultado de aplicar el algoritmo MD5 a la cadena "<12345.1234.1234567890@dict.example.org>qwerty"). Este método de autenticación YA NO se considera seguro porque requiere que el servidor tenga acceso a la contraseña en texto plano. Por lo tanto, ahora se utilizan mecanismos SASL (véase el comando SASLAUTH) o extensiones no estandarizadas. Si la autenticación tiene éxito, el servidor responde con el código 230; si la autenticación falló, el servidor responde con el código 531. Este comando es opcional: puede que un servidor lo implemente, como puede que no.
SASLAUTH <mecanismo> [respuesta inicial]: Autentica al cliente con el servidor usando un mecanismo de la Capa simple de autenticación y seguridad (SASL). El cliente especifica un nombre de mecanismo como primer parámetro. Después, si el servidor no admite el mecanismo especificado, enviará el código de estado 532, el cual indica que el mecanismo especificado no es válido, seguido opcionalmente de texto (p.ej. "532 No se admite el mecanismo EXTERNAL"); de lo contrario, inicia el proceso de autenticación con el mecanismo SASL especificado. Opcionalmente y dependiendo del mecanismo SASL especificado, el cliente envía una respuesta inicial codificada en Base64. Si la autenticación tiene éxito inmediatamente, el servidor responde con el código 230; de lo contrario, hay varias posibilidades. Si la autenticación falló, el servidor responde con el código 531; si se requiere continuar con el intercambio (generalmente para mecanismos de desafío-respuesta), el servidor enviará el código de estado 130, seguido opcionalmente de texto (p.ej.: la primera línea puede ser "130" o "130 aquí viene un desafío"). Luego el servidor enviará en una línea una secuencia binaria codificada en Base64, terminará la respuesta de texto con la secuencia <CRLF>.<CRLF> y envía el código de estado 330, solicitando que el cliente responda al desafío utilizando el comando SASLRESP. Este comando es opcional: puede que un servidor lo implemente, como puede que no.
SASLRESP <respuesta>: Envía una respuesta al desafío SASL del servidor. Esa respuesta debe ser una cadena en Base64. El servidor responderá, dependiendo del mecanismo SASL específico, con el código 230 (la autenticación tuvo éxito), 531 (la autenticación falló), o con el código 130 seguido de un desafío y el código 330 (indicando al cliente que hay otro desafío al que debe responder).

Respuestas

Hay dos tipos de respuesta a los comandos anteriormente mencionados, a saber: respuestas de estado y respuestas de texto.

Respuestas de estado

Las respuestas de estado indica la respuesta del servidor al último comando recibido del cliente. Las líneas de respuesta de estado comienzan con un código de 3 dígitos, el cual es suficiente para distinguir todas las respuestas. El primer dígito de la respuesta indica el éxito, fracaso o proceso del anterior comando (basado generalmente en las RFC 640 y RFC 821):

      1yz - Respuesta positiva preliminar
      2yz - Respuesta positiva completa
      3yz - Respuesta positiva intermedia
      4yz - Respuesta negativa completa (transitoria)
      5yz - Respuesta negativa completa (permanente)

El siguiente dígito en el código indica la categoría de la respuesta:

      x0z - Sintaxis
      x1z - Información (p. ej., el texto de ayuda)
      x2z - Conexiones
      x3z - Autenticación
      x4z - No especificados
      x5z - Estado del sistema DICT (estas respuestas indican el estado del sistema DICT del receptor con respecto a la transferencia solicitada u otras acciones de sistema DICT).
      x8z - Extensiones privadas no estandarizadas

Las respuestas esperadas para cada comando está detallada en la propia especificación del comando. Algunas respuestas de estado pueden contener parámetros, como números o cadenas de caracteres.

Respuestas de texto

Antes del texto, se envía una línea de respuesta de estado preliminar (usando un código 1yz) para indicar que un cuerpo de texto sigue a continuación. El texto se envía como una serie de líneas sucesivas de texto, cada una terminada con una secuencia CRLF. Para indicar el final del texto, se envía una línea con el carácter "." (decimal 46). Si una línea de texto original inicia con este carácter, el servidor lo envía dos veces. Después de una respuesta de texto, se envía otra respuesta de estado de código 2yz (positiva completa) o 3yz (positiva intermedia). Las líneas todavía no deben exceder los 1024 caracteres, contando espacios, separadores, etc., como se apuntó anteriormente.