Rfc 2229 un servidor de protocolo diccionario

Red Grupo de Trabajo R. Fe
Petición de Comentarios: 2229 U. de Carolina del Norte, Chapel Hill
Categoría: Informativo B. Martin
Miranda Producciones
10 1997
Un servidor de protocolo Diccionario
Condición de este Memo
Este memorándum proporciona información para la comunidad de Internet. Lo hace
no especifica un estándar de Internet de cualquier tipo. La distribución de este
memo es ilimitada.
Aviso de copyright
Copyright (C) The Internet Society (1997). Reservados todos los derechos.
Resumen
El Protocolo de Servidor de Diccionario (DICT) es una transacción TCP basado
protocolo de consulta / respuesta que permite a un cliente diccionario acceso
definiciones de un conjunto de bases de datos de diccionario de lenguaje natural.
Tabla de contenido
1 . Introducción ......................................... 2
1.1 . Requisitos ......................................... 3
2 . Protocolo general .................................... 3
2.1 . Enlace Nivel ........................................... 3
2.2 . Fichas léxicas ....................................... 3
2.3 . Comandos ............................................. 4
2.4 . Respuestas ............................................ 5

2.4.1 . Las respuestas de estado ..................................... 5
2.4.2 . Las respuestas de estado general ............................. 6
2.4.3 . Las respuestas de texto ....................................... 6
3 . Mando y detalles Respuesta ......................... 7
3.1 . Conexión inicial ................................... 7
3.2 . El Comando DEFINE ................................... 9
3.3 . El comando Igualar .................................... 10
3.4 . Una nota sobre las bases de datos virtuales .......................... 12
3.5 . El comando show ..................................... 13
3.5.1 . SHOW PP .............................................. 13
3.5 0.2 . MOSTRAR STRAT ........................................... 13
3.5.3 . MOSTRAR INFO ............................................ 14
3.5.4 . MOSTRAR EL SERVIDOR .......................................... 14
3.6 . El Comando CLIENTE ................................... 15
Fe y Martin Informativo [Página 1]

RFC 2229 Un diccionario servidor de Protocolo de octubre 1997
3.7 . El comando de estado ................................... 15
3.8 . El comando HELP ..................................... 15
3.9 . El comando QUIT ..................................... 16
3.10 . El Comando OPCIÓN ................................... 16
3.10.1 . OPCIÓN MIME .......................................... 16
3.11 . El comando AUTH ..................................... 18
3.12 . El Comando SASLAUTH ................................. 18
4 . Comando Canalización ................................... 20
5 . URL Especificación .................................... 20
6 . Extensiones ........................................... 22
6.1 . Sintaxis de los comandos Experimental .......................... 22
6.2 . Comandos Experimental y Canalización ................. 22
7 . Resumen de los códigos de respuesta ............................ 23
8 . Conversaciones Muestra ................................. 23
8.1 . Muestra 1 - AYUDA, DEFINE, y QUIT comandos ........... 24
8.2 . Muestra 2 - VER comandos, comandos PARTIDO .............. 25
8.3 . Muestra 3 - el tiempo de inactividad del servidor ........................... 26
8.4 . Muestra 4 - Autenticación ............................ 26
9 . Consideraciones de seguridad .............................. 26
10 . Referencias ........................................... 27
11 . Agradecimientos ..................................... 29
12 . De los autores Direcciones ................................... 29
13 . Declaración de Derechos de Autor Completo ............................. 30
1 . Introducción
Durante muchos años, la comunidad de Internet se ha basado en el "Webster"
protocolo para el acceso a las definiciones de lenguaje natural. El Webster
protocolo soporta acceso a un único diccionario y (opcionalmente) a una
tesauro único. En los últimos años, el número de disposición del público
webster servidores en Internet se ha reducido drásticamente.
Afortunadamente, varios diccionarios libremente distribuibles y léxicos
se han convertido recientemente en Internet. Sin embargo, estos
bases de datos de distribución libre no son accesibles a través de un uniforme

interfaz, y no son accesibles desde un único sitio. A menudo son
pequeña e incompleta de forma individual, sino que colectivamente proporcionar una
interesante y útil base de datos de palabras en inglés. Los ejemplos incluyen
la jerga presentar [ JERGA ], la base de datos WordNet [ WordNet ], MICRA de
versión del Diccionario Unabridged revisó el 1913 de Webster
[ WEB1913 ], y el Diccionario en línea de Informática [ FOLDOC ].
La traducción y los diccionarios no ingleses también se están haciendo disponibles
(Por ejemplo, el diccionario FOLDOC está siendo traducido al
Español).

El protocolo webster no es adecuado para proporcionar acceso a una gran
número de bases de datos de diccionario separadas, y las ampliaciones de la
protocolo actual Webster no se sentía como una solución limpia para la
problema de base de datos del diccionario.
El protocolo DICT está diseñado para proporcionar acceso a múltiples
bases de datos. Definiciones de palabras se pueden solicitar, el índice palabra puede ser
buscado (usando un conjunto de algoritmos fácilmente ampliada), información
sobre el servidor se puede proporcionar (por ejemplo, que las estrategias de búsqueda de índice
son compatibles, o que las bases de datos están disponibles), y la información
sobre una base de datos se puede proporcionar (por ejemplo, derechos de autor, citación, o
información de distribución). Además, el protocolo DICT tiene ganchos que
puede ser utilizado para restringir el acceso a todos o algunos de las bases de datos.
1.1 . Requisitos
En este documento, se adopta la convención se discutió en la Sección 1.3.2
de [RFC1122] de la utilización de las palabras en mayúsculas DEBE, REQUERIDO, debería,
RECOMENDADO, MAYO, y OPCIONAL para definir el significado de cada uno
en particular el requisito especificado en este documento.
En resumen: "DEBE" (o "REQUERIDO") significa que el artículo es un absoluto
requisito de la especificación; "debería" (o "recomendados") medios
pueden existir razones válidas para no hacer caso de este tema, pero el pleno
implicaciones deben ser entendidas antes de hacerlo; y "MAYO" (o
"OPCIONAL") significa que su elemento es opcional, y puede ser omitido
sin una cuidadosa consideración.
2 . Descripción general del protocolo
2.1 . Enlace Nivel
El protocolo DICT asume un flujo de datos fiable, como previsto por
TCP. Cuando se utiliza TCP, un servidor DICT escucha en el puerto 2628.

Este servidor es sólo una interfaz entre los programas y el diccionario
bases de datos. No realiza ninguna interacción del usuario o
funciones a nivel de presentación.
2.2 . Léxicas Tokens
Los comandos y las respuestas se componen de caracteres de la UCS
conjunto de caracteres [ ISO10646 ] utilizando la codificación UTF-8 [ RFC2044 ] codificación. Más
específicamente, usando las convenciones gramaticales de [ RFC822 ]:

; (Octal, decimal.)
CHAR = <cualquier carácter UTF-8 (de 1 a 6 octetos)>
CTL = <ningún control ASCII; (0- 37, 0.- 31.)
carácter y DEL>; (177, 127.)
CR = <ASCII CR, retorno de carro>; (15, 13)
LF = <ASCII LF, salto de línea>; (12, 10)
ESPACIO = <ASCII SP, espacio>; (40, 32)
HTAB = <ASCII HT, horizontal-tab>; (11, 9.)
<"> = <ASCII comillas>, (42, 34)
<'> = <ASCII comilla simple>; (47, 39)
CRLF LF = CR
WS = 1 * (ESPACIO / HTAB)
dqstring = <"> * (dqtext / de par citado) <">
dqtext = <cualquier CHAR excepto <">" ", y CTL>
sqstring = <'> * (dqtext / de par citado) <'>
sqtext = <cualquier CHAR excepto <'> ", ", y CTL>
de par citado = "" CHAR
átomo = 1 * <cualquier CHAR excepto ESPACIO, CTL, <>, <">, y" ">
cadena = * <dqstring / sqstring / de par citado>
palabra = * <átomo / string>
Descripción * = <palabra / WS>
text = * <palabra / WS>
2.3 . Comandos
Comandos consisten en una palabra de comando seguido de cero o más
parámetros. Comandos con parámetros deben separar los parámetros
unos de otros y del comando por uno o más espacio o pestaña
personajes. Las líneas de comando deben estar completos con todos los necesarios
parámetros, y no pueden contener más de un comando.
Cada línea de comandos debe terminarse con un CRLF.

La gramática de los comandos es:
= comando cmd-palabra * <WS cmd-param>
cmd-palabra = átomo
cmd-param = base de datos / estrategia / palabra
base de datos = átomo
estrategia = átomo
Los comandos no distinguen entre mayúsculas y minúsculas.

Las líneas de comandos no debe superar los 1024 caracteres de longitud, contando todos
caracteres incluyendo espacios, separadores, puntuacion, y la
arrastrando CRLF. No existe ninguna disposición para la continuación del comando
líneas. Desde UTF-8 puede codificar un carácter con un máximo de 6 octetos, el
buffer de línea de comando debe ser capaz de aceptar hasta 6144 octetos.
2.4 . Respuestas
Las respuestas son de dos clases, el estado y textual.
2.4.1 . Las respuestas de estado
Las respuestas de estado indican la respuesta del servidor para el último comando
recibida del cliente.
Líneas de respuesta de estado comienzan con un código numérico de 3 dígitos que es
suficiente para distinguir todas las respuestas. Algunos de estos pueden anunciar
la posterior transmisión de texto.
El primer dígito de la respuesta en términos generales indica el éxito,
fracaso, o el progreso de la orden anterior (basado generalmente en
[RFC640, RFC821 ]):
1yz - Positiva respuesta preliminar
2yz - Finalización positiva respuesta
3yz - Intermedio respuesta positiva
4yz - Transitoria respuesta negativa de Terminación
5yz - respuesta negativa de Terminación Permanente
El siguiente dígito en el código indica la categoría de respuesta:
x0z - Sintaxis
x1z - Información (por ejemplo, ayuda)
x2z - Conexiones
x3z - Autenticación

x4z - Sin especificar aún
x5z - Sistema DICT (Estas respuestas indican el estado de la
receptor del sistema de DICT vis-a-vis la transferencia solicitada
u otra acción DICT sistema.)
x8z - (aplicación privada) extensiones no estándar
Los códigos de respuesta exactos que se deben esperar de cada comando
se detallan en la descripción de ese comando.
Ciertas respuestas de estado contienen parámetros tales como números y
cuerdas. El número y tipo de tales parámetros se fijan para cada
código de respuesta para simplificar la interpretación de la respuesta. Otro
respuestas de estado no requieren identificadores de texto específicos. Parámetro

requisitos se detallan en la descripción de los comandos pertinentes.
Excepto para los parámetros detallados específicamente, el texto siguiente
códigos de respuesta depende del servidor.
Los parámetros se separan del código de respuesta numérico y de cada
otra por un solo espacio. Todos los parámetros numéricos son decimal, y puede
tener ceros a la izquierda. Todos los parámetros de cadena debe ajustarse al "átomo"
o "dqstring" producciones gramaticales.
Si no hay parámetros están presentes, y la implementación del servidor ofrece
ningún texto específico de la implementación, entonces no puede o no puede ser un espacio
después de que el código de respuesta.
Los códigos de respuesta no especificados en la presente norma se pueden usar para cualquier
comandos adicionales específicos de la instalación también no especificados.
Estos deben ser elegidos para encajar el patrón de x8z especificado anteriormente.
El uso de códigos de respuesta no especificados para los comandos estándar es
prohibida.
2.4.2 . Las respuestas de estado generales
En respuesta a cada comando, las siguientes respuestas de estado generales
son posibles:
500 Error de sintaxis, no mandaré reconocido
501 Error de sintaxis, parámetros ilegales
502 Comando no implementado
503 parámetro Comando no implementado
420 Servidor disponible temporalmente
421 Servidor de apagar a petición del operador
2.4.3 . Las respuestas de texto
Antes de texto se envía una línea de respuesta de estado numérico, utilizando un código 1yz,

será enviado indicando texto seguirá. El texto se envía como una serie de
líneas sucesivas de la materia textual, cada terminan con un CRLF. La
se envía una sola línea que contiene sólo un punto (código decimal 46, ".")
para indicar el final del texto (es decir, el servidor enviará un CRLF en
el final de la última línea de texto, un período, y otro CRLF).
Si una línea de texto original contenía un período como el primer carácter
de la línea, que el primer período se duplica por el servidor DICT.
Por lo tanto, el cliente debe examinar el primer carácter de cada línea
recibida. Los que comienzan con dos períodos debe tener los dos
períodos derrumbó en un período. Aquellos que contienen sólo un único
seguido de un período CRLF indicar el final de la respuesta de texto.

Si no se ha dado la orden OPCIÓN MIME, todas las respuestas textuales voluntad
ser precedida por una cabecera MIME [ RFC2045 ] seguido de un único espacio en blanco
línea (CRLF). Ver sección 3.10.1 para más detalles sobre OPCIÓN MIME.
A raíz de una respuesta de texto, se enviará un código de respuesta 2yz.
Las líneas de texto no debe superar los 1024 caracteres de longitud, contando todos
caracteres, incluyendo espacios, separadores, puntuacion, el extra
período inicial (si es necesario), y el CRLF al final. Desde UTF-8 de mayo
codificar un carácter con un máximo de 6 octetos, el buffer de entrada de línea de texto
DEBE ser capaz de aceptar hasta 6144 octetos.
De forma predeterminada, el texto de las definiciones debe estar compuesto por
personajes de carácter UCS establecen [ISO10644] utilizando la codificación UTF-8
[ RFC2044 codificación]. La codificación UTF-8 tiene la ventaja de
la preservación de la gama completa de 7 bits ASCII de EE.UU. [USASCII] valores.
Los clientes y servidores DEBE apoyo UTF-8, aunque sólo sea en algunos mínimos
la moda.
3 . Comando y Respuesta detalles
A continuación, cada comando DICT y respuestas apropiadas se detallan.
Cada comando se muestra en mayúsculas para mayor claridad, pero el servidor DICT
entre mayúsculas y minúsculas.
A excepción de los comandos AUTH y SASLAUTH, cada comando se describe en
Esta sección debe ser implementado por todos los servidores DICT.
3.1 . Conexión inicial
Cuando un cliente se conecta inicialmente a un servidor DICT, se envía un código 220
si se permite que IP del cliente para conectar:
220 capacidades de texto msg-id

El código 220 es una bandera, por lo general contiene el nombre de host y DICT
información de la versión del servidor.
El segundo a última secuencia de caracteres en el banner es el
opcional cadena de capacidades, lo que permitirá a los servidores declaran
soporte para extensiones al protocolo DICT. La cadena de capacidades
se define a continuación:
capacidades = ["<" msg-átomo * ("." msg-átomo) ">"]
msg-átomo = 1 * <cualquier CHAR excepto ESPACIO, CTL,
"<", ">", ".", Y "">

Capacidades individuales son descritos por una única msg-átomo. Para
ejemplo, la cadena <html.gzip> podría ser usado para describir un servidor
que soporte las extensiones que permiten HTML o salida comprimida.
Capacidad nombres que comienzan con "x" o "X" están reservados para
extensiones experimentales, y no debe ser definido en cualquier DICT futuro
especificación del protocolo. Algunas de estas capacidades podrán informar a la
cliente que cierta funcionalidad está disponible o se puede solicitar.
Las siguientes capacidades están actualmente definidas:
Mime El comando OPCIÓN MIME es compatible
auth El comando AUTH es apoyado
kerberos_v4y El SASL Kerberos versión 4 mecanismo es apoyado
gssapi El SASL GSSAPI [ RFC2078 es apoyada] mecanismo
La tecla s SASL S / Key [ RFC1760 es apoyada] mecanismo
mecanismo externo externo El SASL es apoyado
La última secuencia de caracteres en el banner es un msg-id, similar a
el formato especificado en [ RFC822 ]. La descripción simplificada es
se indica a continuación:
msg-id = "<" especificaciones ">"; Identificación del mensaje único
spec = local-parte "@" dominio
parte-local = msg-átomo * ("." msg-átomo)
domain = msg-átomo * ("." msg-átomo)
Tenga en cuenta que, en contraste con [ RFC822 ], espacios y pares no son citadas
permitido en el msg-id. Esta restricción hace que el msg-id mucho más fácil
para el cliente para localizar y analizar, pero no lo hace de forma significativa
disminuir las prestaciones de la seguridad, ya que el msg-id puede ser arbitrariamente
de largo (como limitada por los límites de longitud de respuesta establecidos en otra parte
este documento).
Tenga en cuenta también que los paréntesis de apertura y cierre son parte de msg-id y
deben ser incluidos en la cadena que se utiliza para calcular la MD5
suma de comprobación.

Este id mensaje será utilizada por el cliente en la formulación de la
cadena de autenticación utilizado en el comando AUTH.
Si no se permite IP del cliente para conectar, a continuación, se envía un código 530
en su lugar:
530 Acceso denegado
Respuestas error transitorio también son posibles:

Por ejemplo, el código de respuesta 420 debe utilizarse si el servidor no puede
Actualmente bifurcar un proceso de servidor (o no se puede obtener en la actualidad otra
los recursos necesarios para proceder con una conexión utilizable), pero espera
para poder desembolsar u obtener estos recursos en el futuro cercano.
Código de respuesta 421 debe ser utilizado cuando el servidor se ha cerrado
a petición del operador, o cuando las condiciones indican que la capacidad de
servicio más solicitudes en el futuro cercano será imposible. Este
puede ser utilizado para permitir un cierre temporal agraciado operador mediada
de un servidor, o para indicar que un servidor conocido ha sido
retirado permanentemente de servicio (en cuyo caso, el mensaje de texto
podría proporcionar más información).
3.2 . El comando DEFINE
DEFINE palabra base de datos
3.2.1 . Descripción
Este comando buscará la palabra especificada en el especificado
base de datos. Todos los servidores DICT DEBE aplicar este comando.
Si se especifica el nombre de la base de datos con un signo de exclamación (decimal
código 33, "!"), a continuación, todas las bases de datos se buscará hasta un
partido se encuentra, y se mostrará todos los partidos en esa base de datos.
Si se especifica el nombre de la base de datos con una estrella (código decimal 42 "*",),
entonces todos los partidos en todas las bases de datos disponibles se mostrarán.
En ambos de estos casos especiales, las bases de datos se buscaron en el
mismo orden que el impreso por el comando "SHOW PP".
Si no se ha encontrado la palabra, a continuación, se envía el código de estado 552.
Si se encontró la palabra, luego se envía el código de estado de 150, lo que indica que
una o más definiciones siguen.

Para cada definición, se envía el código de estado 151, seguido por el textual
cuerpo de la definición. Los tres primeros parámetros delimitados por espacios
siguiente código de estado 151 dan la palabra recuperada, el nombre de la
base de datos (que es la misma que la primera columna de la serie DB
comando), y una breve descripción de la base de datos (que es el mismo
como la segunda columna de DB el comando SHOW). El nombre corto es
conveniente para la impresión como:
De nombre:
antes de que se imprima la definición. Esto proporciona información de la fuente
para el usuario.

El cuerpo textual de cada definición se termina con un período CRLF
Secuencia CRLF.
Después de todo de las definiciones han sido enviados, se envía el código de estado 250.
Este comando puede proporcionar información de temporización opcional (que es el servidor
dependiente y no se pretende que sea apta para su procesamiento por el cliente). Este
información adicional es útil para depurar y afinar el
servidor.
3.2.2 . Respuestas
550 de base de datos no es válido, utilice "SHOW PP" para la lista de bases de datos
552 No hay resultados
150 n definiciones recuperados - definiciones siguen
151 palabra nombre de base de datos - texto sigue
250 ok (información de temporización opcional aquí)
Los códigos de respuesta 150 y 151 requieren parámetros especiales como parte de
su texto. El cliente puede utilizar estos parámetros para mostrar
información sobre el terminal del usuario.
Para el código 150, los parámetros 1 indica el número de definiciones
recuperado.
Para el código de 151, parámetro 1 es la palabra recuperada, parámetro 2 es el
Nombre de base de datos (el primer nombre que se muestra por "SHOW PP") a partir del cual la
definición se ha recuperado, y el parámetro 3 es el corto
Descripción base de datos (la segunda columna del comando "SHOW PP").
3.3 . El comando Igualar
PARTIDO estrategia de base de datos de la palabra

Este comando busca en un índice para el diccionario, e informa de palabras
que fueron encontrados usando una estrategia en particular. No todas las estrategias son
útil para todos los diccionarios, y algunos diccionarios pueden apoyar
estrategias de búsqueda adicionales (por ejemplo, de búsqueda inversa). Todo DICT
servidores debe implementar el comando Igualar, y deben apoyar el
"exactas" y estrategias "prefijo". Estos son fáciles de implementar y son
generalmente los más útiles. Otras estrategias dependen del servidor.
La estrategia de "exacta" coincide con una palabra exactamente, aunque diferente
servidores pueden tratar los datos que no sean alfanuméricos diferente. Hemos encontrado
que una comparación entre mayúsculas y minúsculas que ignora no alfanumérico

personajes y que se pliega el espacio en blanco es útil para Inglés-idioma
diccionarios. Otras comparaciones pueden ser más apropiadas para otro
idiomas o cuando se utilizan conjuntos de caracteres extendidos.
La estrategia de "prefijo" es similar a "exacta", excepto que sólo
compara la primera parte de la palabra.
Diferentes servidores pueden aplicar estos algoritmos diferente. El
requisito es que las estrategias con los nombres de "exactas" y "prefijo"
existir para que un cliente simple puede utilizarlos.
Otras estrategias que podrían ser considerados por un implementador del servidor son
partidos sobre la base de subcadena, sufijo, expresiones regulares, soundex
[ KNUTH73 ], y Levenshtein [ PZ85 ] algoritmos. Estos dos últimos son
especialmente útil para corregir los errores de ortografía. Otros útiles
estrategias realizan algún tipo de búsqueda "inverso" (es decir, mediante la búsqueda
definiciones para encontrar la palabra que sugiere la consulta).
Si se especifica el nombre de la base de datos con un signo de exclamación (decimal
código 33, "!"), a continuación, todas las bases de datos se buscará hasta un
partido se encuentra, y se mostrará todos los partidos en esa base de datos.
Si se especifica el nombre de la base de datos con una estrella (código decimal 42 "*",),
entonces todos los partidos en todas las bases de datos disponibles se mostrarán.
En ambos de estos casos especiales, las bases de datos se buscaron en el
mismo orden que el impreso por el comando "SHOW PP".
Si se especifica la estrategia de usar un punto (código decimal 46, "."),
entonces la palabra se comparará el uso de un valor predeterminado depende del servidor
estrategia, que debe ser la mejor estrategia disponible para interactivo
corrección ortográfica. Esto es generalmente un derivado de la Levenshtein
algoritmo [ PZ85 ].
Si no se encuentran coincidencias en cualquiera de las bases de datos consultadas, a continuación, el estado
se devolverá el código 552.

De lo contrario, el código de estado 152 se le entregará seguido por una lista de
palabras coincidentes, uno por línea, en la forma:
palabra de base de datos
Esto hace que las respuestas directamente útil en un comando DEFINE.
El cuerpo textual de la lista de coincidencias se termina con un período CRLF
Secuencia CRLF.
Después de la lista, se envía el código de estado 250, que puede incluir
sincronización específica del servidor y la información estadística, como se discute en
la sección sobre el comando DEFINE.

3.3.2 . Respuestas
551 estrategia válida, utilice "mostrar STRAT" para obtener una lista de las estrategias
152 n se han encontrado coincidencias - texto sigue
Código de respuesta 152 requiere un parámetro especial como parte de su texto.
Parámetro 1 debe ser el número de coincidencias recuperados.
3.4 . Una nota sobre las bases de datos virtuales
La capacidad de buscar todas las bases de datos proporcionadas utilizando un único
comando se da mediante el especial "*" y "!" bases de datos.
Sin embargo, a veces, un cliente lo desea, puede buscar en algunos, pero no todos
de las bases de datos que un servidor en particular ofrece. Una alternativa
es para que el cliente utilice el comando SHOW PP para obtener una lista de
bases de datos y las descripciones y, a continuación (tal vez con la ayuda de una
humano), seleccionar un subconjunto de estas bases de datos para una búsqueda interactiva.
Una vez que esta selección se ha hecho una vez, los resultados se pueden guardar, para
ejemplo, en un archivo de configuración de cliente.
Otra alternativa es que el servidor de bases de datos para proporcionar "virtuales"
que se unen varias de las bases de datos regulares en uno. Por ejemplo,
una base de datos virtual puede ser proporcionado que incluye la totalidad de la
la traducción de los diccionarios, pero que no incluye regular de
diccionarios o tesauros. El especial "*" y "!" bases de datos pueden ser
considerado como nombres de bases de datos virtuales que proporcionan acceso a todos
de las bases de datos. Si un servidor de bases de datos virtuales implementa, entonces la
especial "*" y "!" bases de datos probablemente deberían excluir otros virtuales
bases de datos (ya que se limitan a proporcionar información duplican en otro
bases de datos). Si se admiten las bases de datos virtuales, deben ser
aparece como una base de datos normal con el comando SHOW PP (aunque,

ya que "*" y "!" se requiere, que sea necesaria su enumeración).
Bases de datos virtuales son un detalle específico de la implementación que tiene
absolutamente ningún impacto en el protocolo DICT. Los puntos de vista del protocolo DICT
bases de datos virtuales y no virtuales de la misma manera.
Mencionamos aquí las bases de datos virtuales, sin embargo, porque resuelven un
problema de la selección de base de datos que podría también haber sido resuelto por
cambios en el protocolo. Por ejemplo, podría ser cada diccionario
atributos asignados, y el protocolo se podría extender para especificar
Búsquedas más bases de datos con ciertos atributos. Sin embargo, este
innecesariamente complica el análisis sintáctico y el análisis que debe estar
realizado por la aplicación. Además, a menos que la clasificación

sistema es extremadamente general, existe un riesgo de que se restringiría
los tipos de bases de datos que pueden utilizarse con el protocolo DICT
(Aunque el protocolo ha sido diseñado con el lenguaje humano-bases
de datos en mente, es aplicable a cualquier base de datos de sólo lectura
aplicación, especialmente aquellos con una sola semi-alfanumérico único
clave y datos textuales).
3.5 . El comando show
3.5.1 . SHOW PP
SHOW PP
VER LAS BASES DE DATOS
3.5.1.1 . Descripción
Muestra la lista de bases de datos accesibles en la actualidad, uno por línea, en
la forma:
Descripción de bases de datos
El cuerpo textual de la lista de la base de datos termina con un CRLF
secuencia CRLF período. Todos los servidores DICT DEBE aplicar este comando.
Tenga en cuenta que algunas bases de datos pueden ser restringidos debido al dominio del cliente o
la falta de autenticación de usuario (ver el AUTH y comandos en SASLAUTH
secciones 3.11 y 3.12 ). Información sobre estas bases de datos no es
disponible hasta que la autenticación se realiza. Hasta ese momento, la
cliente interactuar con el servidor como si las bases de datos adicionales
no existía.
3.5.1.2 . Respuestas
110 n bases de datos presentan - texto sigue
554 No hay bases de datos de la actualidad

Código de respuesta 110 requiere un parámetro especial. Parámetro 1
debe ser el número de bases de datos disponibles para el usuario.
3.5.2 . MOSTRAR STRAT
MOSTRAR STRAT
VER LAS ESTRATEGIAS

Muestra la lista de estrategias de búsqueda soportados actualmente, uno por
línea, en la forma:
descripción de la estrategia
El cuerpo textual de la lista de estrategia se termina con un CRLF
secuencia CRLF período. Todos los servidores DICT DEBE aplicar este comando.
111 n estrategias disponibles - texto sigue
555 No hay estrategias disponibles
Código de respuesta 111 requiere un parámetro especial. Parámetro 1 debe ser
el número de estrategias disponibles.
3.5.3 . MOSTRAR INFO
MOSTRAR INFO base de datos
Muestra la fuente, el derecho de autor, y la información sobre la concesión de licencias
especifica la base de datos. La información es el texto de forma libre y es
adecuada para su visualización al usuario de la misma manera como una definición.
El cuerpo textual de la información se termina con un período CRLF
Secuencia CRLF. Todos los servidores DICT DEBE aplicar este comando.
112 información de la base de datos sigue

Estos códigos de respuesta no requieren parámetros especiales.
3.5.4 . MOSTRAR EL SERVIDOR
MOSTRAR EL SERVIDOR
Muestra información del servidor local, escrito por el administrador local.
Esto podría incluir información acerca de las bases de datos o estrategias locales,
o información administrativa, como a quién contactar para el acceso a
las bases de datos que requieren autenticación. Todos los servidores DICT DEBE aplicar
este comando.

114 información del servidor sigue
Este código de respuesta no requiere parámetros especiales.
3.6 . El Comando CLIENTE
Texto CLIENTE
Este comando permite al cliente para proporcionar información sobre sí mismo
con fines estadísticos posible tala y. Todos los clientes deben
enviar este comando después de conectar con el servidor. Todos los servidores DICT
DEBE aplicar este comando (tenga en cuenta, sin embargo, que el servidor no
tienen que ver nada con la información proporcionada por el cliente).
3.6.2 . Respuestas
3.7 . El comando de estado
ESTADO
Mostrar un poco de tiempo o la depuración de información específica del servidor. Este
información puede ser útil en la depuración o sintonizar un servidor DICT. Todo
Servidores DICT DEBE aplicar este comando (tenga en cuenta, sin embargo, que el texto
parte de la respuesta no se especifica y puede ser omitido).

3.7.2 . Respuestas
210 (tiempo opcional y la información estadística aquí)
3.8 . El Comando AYUDA
AYUDA

Proporciona un breve resumen de los comandos que se entiende por este
implementación del servidor DICT. El texto de ayuda se presentará
como una respuesta textual, terminada por un solo período en una línea
sí mismo. Todos los servidores DICT DEBE aplicar este comando.
3.8.2 . Respuestas
113 texto de ayuda sigue
3.9 . El comando QUIT
QUIT
Este comando es utilizado por el cliente para salir limpiamente el servidor. Todo
Servidores DICT DEBE aplicar este comando.
3.9.2 . Respuestas
Conexión 221 Clausura
3.10 . El Comando OPCIÓN
3.10.1 . OPCIÓN MIME
OPCIÓN MIME

Pide que todas las respuestas de texto serán precedidos por una cabecera MIME
[ RFC2045 ], seguido de una línea en blanco (CRLF).
Si un cliente solicita esta opción, el cliente debe ser capaz de
analizar las cabeceras Content-Type y Content-Transfer-Encoding, y debe ser
capaz de ignorar respuestas textuales que tienen un contenido no soportado o
codificación. Un cliente debe soportar la codificación UTF-8 [ RFC2044 ], que
mínimamente significa que el cliente debe reconocer UTF-8 multi-octeto
codificaciones y convertir estos en algún símbolo que se puede imprimir por
el cliente.

Si un cliente solicita esta opción, el servidor proporcionará un MIME
encabezado. Si la cabecera está vacía, la respuesta de texto se iniciará con una
sola línea en blanco (CRLF), en cuyo caso el cliente debe interpretar esto
como un encabezado predeterminado. El encabezado predeterminado para la autenticación SASL es:
Content-type: application / octet-stream
Content-Transfer-Encoding: base64
El encabezado predeterminado para todas las otras respuestas textuales es:
Content-type: text / plain; charset = UTF-8
Content-Transfer-Encoding: 8bit
Si OPCIÓN MIME no está especificado por el cliente, el servidor puede
restringir el contenido de la información proporcionada al cliente. Para
ejemplo, una definición puede ir acompañada de una imagen y un archivo de audio
clip, pero el servidor no puede transmitir esta información a menos que el
cliente es capaz de analizar los encabezados de formato MIME.
Tenga en cuenta que, debido a las restricciones de longitud de línea y fin-de-semántica
de respuesta, el "binario" Content-Transfer-encoding NO DEBE
ser utilizado. En el futuro, se pueden proporcionar extensiones al protocolo
que permiten a un cliente a solicitar codificaciones binarias, pero el defecto
Siempre debe ser que el cliente puede buscar un "CRLF. CRLF"
secuencia para localizar el final de la respuesta de texto actual. Esto permite
clientes para saltar fácilmente sobre las respuestas de texto que tienen no admitido
tipos o codificaciones.
En el futuro, después de una importante experiencia con grandes bases de datos en
varios idiomas se ha ganado, y después de evaluar la necesidad de
especificando los juegos de caracteres y otras codificaciones (por ejemplo, comprimido o
Codificación base64), extensiones estándar a este protocolo debe ser
propuso que permiten al cliente para solicitar ciertos tipos de contenido o
codificaciones. Se debe tener cuidado de que estas extensiones no requieren
un apretón de manos que derrota a la canalización. Por el momento, privado

extensiones deben ser utilizados para explorar el espacio de parámetros para determinar
mejor manera de aplicar estas extensiones.
OPCIÓN MIME es una capacidad servidor requerido, todos los servidores DICT DEBE
aplicar este comando.
Tenga en cuenta que algunas implementaciones de servidores de mayor edad, completaron antes de esta
documento fue finalizado, devolverá un código de estado 500 si este comando
no se implementa. Los clientes deben ser capaces de aceptar este comportamiento,

hacer suposiciones por defecto. Los clientes también podrán examinar el
capacidades de cadena en el encabezado de estado del código 220 para determinar si un
servidor soporta esta capacidad.
3.11 . El comando AUTH
AUTH nombre de usuario de autenticación de cuerdas
El cliente puede autenticarse en el servidor mediante un nombre de usuario y
contraseña. La cadena de autenticación se calcula como en el APOP
protocolo discutido en [ RFC1939 ]. Brevemente, la cadena de autenticación
es la suma de control MD5 de la concatenación de msg-id (obtenido de
la bandera inicial) y el "secreto compartido" que se almacena en el
los archivos del servidor y configuración del cliente. Puesto que el usuario no tiene
para escribir este secreto compartido al acceder al servidor, el compartido
secreto puede ser una frase de contraseña arbitrariamente larga. Debido a la
computacional facilidad de cálculo de la suma de control MD5, el secreto compartido
debe ser significativamente más largo que una contraseña habitual.
La autenticación puede hacer que las bases de datos más Diccionario disponible para la
sesión actual. Por ejemplo, puede haber algo de públicamente
bases de datos distribuibles disponibles para todos los usuarios, y otros privados
bases de datos disponibles sólo para los usuarios autenticados. O bien, un servidor puede
requerir la autenticación de todos los usuarios para minimizar los recursos
la utilización de la máquina servidor.
La autenticación es una capacidad de servidor opcional. El comando AUTH
Puede ser implementado por un servidor DICT.
3.11.2 . Respuestas
230 Autenticación exitosa
531 Acceso denegado, utilice "MOSTRAR INFO" para obtener información del servidor

3.12 . El Comando SASLAUTH
Mecanismo SASLAUTH inicial-respuesta
Respuesta SASLRESP
La Capa de autenticación y seguridad (SASL) es actualmente
se están desarrollando [ RFC2222 ]. El protocolo DICT se reserva el SASLAUTH
y los comandos SASLRESP para este método de autenticación. Los resultados

de la autenticación exitosa con SALSAUTH será la misma que la
resultados de la autenticación AUTH éxito: más bases de datos de diccionario
pueda estar disponible para la sesión actual.
La respuesta inicial es un parámetro opcional para el SASLAUTH
comando, codificada utilizando codificación base64 [ RFC2045 ]. Algunos SASL
mecanismos pueden permitir el uso de este parámetro. Si SASL
la autenticación se apoya en un servidor DICT, entonces este parámetro
También debe ser apoyada.
Un típico autenticación SASL será iniciado por el cliente utilizando
el comando SASLAUTH. El servidor responderá con código de estado 130,
seguido de un desafío. El reto será seguido por el estado
código 330, que indica que el cliente ahora debe enviar una respuesta a la
servidor.
Dependiendo de los detalles del mecanismo SASL actualmente en uso, el
servidor o bien continuar el intercambio utilizando código de estado 130, una
desafío, y el estado de código 330; o el servidor utilizará el código de estado
230 o 531 para indicar la autenticación ha tenido éxito o ha fracasado.
Los retos enviados por el servidor se definen por los mecanismos como
fichas binarios de longitud arbitraria, y se deben enviar mediante un
respuesta textual DICT estándar, tal como se describe en la sección 2.4.3 . Si
OPCIÓN MIME no está establecido, entonces la codificación Base64 DEBE utilizarse. Si
OPCIÓN MIME se establece, entonces BASE64 es la codificación por defecto, como se especifica
en la sección 3.10.1 .
El cliente enviará todas las respuestas utilizando el comando SASLRESP y un
Codificado en base 64 de parámetros. Las respuestas enviadas por el cliente son
definido por los mecanismos como tokens binarias de longitud arbitraria.
Recuerde que las líneas de comando DICT sólo pueden ser de 1024 caracteres en
longitud, por lo que la respuesta proporcionada por un cliente DICT es limitado.

Si el mecanismo especificado en el comando SASLAUTH no es compatible,
a continuación, se le devolverá el código de estado 532.
La autenticación es una capacidad de servidor opcional. El SASLAUTH
comando puede ser ejecutado por un servidor DICT.
3.12.2 . Respuestas
130 reto sigue
Respuesta 330 de envío
532 Acceso denegado, mecanismo desconocido

4 . Comando Canalización
Todos los servidores DICT DEBE ser capaz de aceptar varios comandos en una sola
TCP envía operación. El uso de una sola operación de TCP enviar múltiples
comandos pueden mejorar el rendimiento DICT significativamente, sobre todo en
la cara de los enlaces de red de alta latencia.
Los posibles problemas de aplicación para un servidor que haría DICT
prevenir comando pipelining son similares a los problemas que impiden
la canalización en un servidor SMTP. Estos problemas se discuten en detalle
en [ RFC1854 ], que debe ser consultada por todos los servidores DICT
ejecutores.
La implicación principal es que una implementación del servidor DICT NO DEBE
enjuagar o de lo contrario perderá el contenido de la memoria intermedia de entrada TCP bajo
ninguna circunstancia.
Un cliente tubería puede DICT varios comandos y debe comprobar el
respuestas a cada comando individualmente. Si el servidor se ha apagado,
es posible que todos los comandos no serán procesados. Para
ejemplo, un simple cliente DICT puede gasoducto un cliente, DEFINE, y QUIT
secuencia de comandos, ya que se está conectando con el servidor. Si el servidor es
cerrar, el código de respuesta inicial enviado por el servidor puede ser 420
(Temporalmente no disponible) en lugar de 220 (banner). En este caso, el
definición no puede ser recuperada, y el cliente debe informar y
error o volver a intentar el comando. Si el servidor está funcionando, puede ser capaz de
para devolver la bandera, definición, y el mensaje de terminación en un
la sola operación de envío TCP.
5 . URL Especificación
El esquema de URL DICT se utiliza para referirse a las definiciones o listas de palabras
disponibles mediante el protocolo DICT:

dict: // <usuario>, <auth> @ <host>: <puerto> / d: <palabra>: <base de datos>: <n>
dict: // <usuario>, <auth> @ <host>: <puerto> / m: <palabra>: <base de datos>: <Strat>: <n>
La sintaxis "/ d" especifica el comando DEFINE ( sección 3.2 ), mientras que
el "/ m" especifica el comando MATCH ( sección 3.3 ).

Algunos o todos los "<usuario>, <auth> @", ": <puerto>", "<base de datos>", "<Strat>",
y "<n>" puede omitirse.
"<N>" por lo general se omite, pero cuando se incluye, especifica el
definición enésimo partido o de una palabra. Un método para extraer exactamente
esta información desde el servidor no está disponible utilizando el DICT
protocolo. Sin embargo, un cliente mediante la especificación URL podría obtener
todas las definiciones o partidos, y luego seleccionar el que es
especificado.
Si "<usuario>, <auth> @" se omite, no se realiza la autenticación. Si
": <Puerto>" se omite, se utilizará el puerto predeterminado (2628). Si
"<Base de datos>" se omite, "!" DEBE ser utilizado (ver sección 3.2 ). Si
"<Strat>" se omite "." DEBE ser utilizado (ver sección 3.3 ).
"<Usuario>, <auth> @" especifica el nombre de usuario y el tipo de
realiza la autenticación. Para "<auth>", la cadena "AUTH" indica
que se llevará a cabo la autenticación APOP utilizando el comando AUTH,
mientras que la cadena "SASLAUTH = <AUTH_TYPE>" indica que el SASLAUTH
y se utilizarán los comandos SASLRESP, con "<AUTH_TYPE>" indicando el
tipo de autenticación SASL que se utilizará. Si "<AUTH_TYPE>" es
una estrella (código decimal 42, "*"), a continuación, el cliente seleccionará algún tipo
de autenticación.
Cada vez que se requiere la autenticación, el cliente debe solicitar
información adicional (por ejemplo, una frase de contraseña) del usuario. En
contraste con [ RFC1738 ], las contraseñas de texto no cifrado no están permitidos en el
URL.
Dos puntos de arrastre pueden omitirse. Por ejemplo, el siguiente URL
podría especificar definiciones o partidos:
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: sol
dict: //dict.org/d: sol :: 1
dict: //dict.org/m: sol
dict: //dict.org/m: sol :: soundex
dict: //dict.org/m: sol: wordnet :: 1
dict: //dict.org/m: sol :: soundex: 1
dict: //dict.org/m: sol :::

6 . Extensiones
Este protocolo fue diseñado para que las bases de datos de texto plano pueden ser utilizados
con un servidor después de un mínimo de análisis y formateo. Nuestro
experiencia es que simplemente la construcción de un índice para una base de datos puede ser
suficiente para que sea útil con un servidor DICT. La capacidad de
servir de texto con formato previo es especialmente importante, ya que freely-bases
de datos disponibles se distribuyen a menudo como archivos de texto plano sin
cualquier información de marcado semántico (y, a menudo contienen "ASCII art", que
se opone a la automatización de formato sencillo, incluso).
Sin embargo, dada una base de datos con información suficiente margen de ganancia, puede
ser posible para generar la salida en una variedad de diferentes formatos
(Por ejemplo, HTML simple o más sofisticado SGML). La especificación de
formateo está más allá del alcance de este documento. Los requisitos
para la negociación de formato (incluyendo el conjunto de caracteres y otro
codificaciones) es complejo y debe ser examinados con el tiempo a medida que más
se adquiere experiencia. Sugerimos que el uso de diferentes formatos,
así como otras características del servidor, se explorarán como extensiones a la
protocolo.
6.1 . Sintaxis de los comandos Experimental
Comandos de una sola letra se reservan para la depuración y pruebas, DEBEN
NO se definirán en una futura especificación de protocolo DICT, y debe
NO ser utilizado por cualquier software de cliente.
Los comandos que comienzan con la letra "X" están reservadas para experimentación
extensiones, y no debe ser definido en cualquier protocolo DICT futuro
especificación. Los autores de software de cliente deben entender que
estos comandos no son parte del protocolo DICT y pueden no estar
disponible en todos los servidores DICT.
6.2 . Comandos Experimental y Canalización

Comandos experimentales deben ser diseñados de manera que un cliente pueda
tubería los comandos experimentales sin saber si un servidor
apoya los comandos (por ejemplo, en lugar de utilizar la negociación característica).
Si el servidor no admite los comandos, a continuación, un código de respuesta en
Se dará la serie 5yz (generalmente 500), notificando al cliente que
la extensión no es compatible. Por supuesto, dependiendo de la
complejidad de las extensiones añadido, la negociación puede ser característica
necesario. Para ayudar a minimizar el tiempo de negociación, apoyada servidor-características
pueden ser anunciados en el banner (código 220) con el programa opcional
parámetro de capacidades.

7 . Resumen de los códigos de respuesta
A continuación se muestra un resumen de los códigos de respuesta. Una estrella (*) en la primera columna
indica la respuesta ha definido argumentos que deben ser proporcionados.
* 110 n bases de datos de la actualidad - texto sigue
* 111 n estrategias disponibles - texto sigue
112 información de la base de datos sigue
113 texto de ayuda sigue
114 información del servidor sigue
130 reto sigue
* 150 n definiciones recuperados - definiciones siguen
* 151 palabra nombre de base de datos - texto sigue
* 152 n se han encontrado coincidencias - texto sigue
210 (tiempo opcional y la información estadística aquí)
* 220 texto msg-id
Conexión 221 Clausura
Respuesta 330 de envío
500 Error de sintaxis, no mandaré reconocido
501 Error de sintaxis, parámetros ilegales
502 Comando no implementado
503 parámetro Comando no implementado
530 Acceso denegado
532 Acceso denegado, mecanismo desconocido
551 estrategia válida, utilice "mostrar STRAT" para obtener una lista de las estrategias
554 No hay bases de datos de la actualidad
555 No hay estrategias disponibles

8 . Las conversaciones de ejemplo
Las tesis son muestras de las conversaciones que se podría esperar con
un servidor DICT típico. La notación "C:" indica mandatos establecidos por
el cliente, y "S:" indica las respuestas enviadas por el servidor. En blanco
líneas se incluyen para mayor claridad y no indican los saltos de línea reales
en la transacción.

8.1 . Muestra 1 - AYUDA, DEFINE, y QUIT comandos
C: [cliente inicia la conexión]
S: 220 dict.org dictd (versión 0.9) <27831.860032493@dict.org>
C: AYUDA
S: 113 Ayuda de texto sigue
S: DEFINE palabra base de datos levantó la palabra en la base de datos
S: PARTIDO estrategia de base de datos de palabra partido palabra en la base de datos utilizando la estrategia
S: [más dependiente de la ayuda del servidor de texto]
S:.
S: 250 Comando completa
C: DEFINE! pingüino
S: 150 1 definiciones encontradas: lista sigue
S: 151 "pingüino" wn "WordNet 1.5": texto de la definición sigue
S: pingüino
S: 1. n: las aves no voladoras de patas cortas de frío sur esp. Antártico
S: las regiones que tienen los pies palmeados y alas modificado como aletas
S:.
C: DEFINIR * Shortcake
S: 150 2 definiciones encontradas: lista sigue
S: 151 "Shortcake" wn "WordNet 1.5": texto sigue
S: Shortcake
S: 1. n: propagación de galletas muy corto con fruta endulzada y usu.
S: crema batida

S:.
S: 151 "El Diccionario Webster (1913)" "Shortcake" web1913: texto sigue
S: Shortcake
S: Corto "cake` , n.
S: Un pastel de desayuno sin azúcar acortado con mantequilla o manteca de cerdo,
S: laminado fino, y al horno.
S:.
C: DEFINE abcdefgh
S: 552 No hay resultados

C: dejar de fumar
S: conexión 221 Clausura
8.2 . Muestra 2 - VER comandos, comandos PARTIDO
C: SHOW PP
S: 110 3 bases de datos actuales: lista sigue
S: wn "WordNet 1.5"
S: FOLDOC "Free On-Line Diccionario de Informática"
S: la jerga "Hacker Jargon File"
S:.
C: Mostrar STRAT
S: 111 5 estrategias presentes: lista sigue
S: "palabras exactas coincidir exactamente"
S: el prefijo "prefijos de palabras Match"
S: subcadena "subseries de partido en cualquier lugar de la palabra"
S: regex "Partido el uso de expresiones regulares"
S: revertir "las palabras partido determinado palabras clave Definición"
S:.
C: PARTIDO FOLDOC regex "s.si"
S: 152 7 se han encontrado coincidencias: lista sigue
S: FOLDOC Fast SCSI
S: FOLDOC SCSI
S: FOLDOC SCSI-1
S: FOLDOC SCSI-2

S: FOLDOC SCSI-3
S: FOLDOC Ultra-SCSI
S: FOLDOC Wide SCSI
S:.
C: PARTIDO wn subcadena "ABCDEFGH"
S: 552 No hay resultados

8.3 . Muestra 3 - el tiempo de inactividad del servidor
S: 420 Servidor disponible temporalmente
S: 421 Servidor cerrando a petición del operador
8.4 . Muestra 4 - Autenticación
S: 220 dict.org dictd (versión 0.9) <27831.860032493@dict.org>
C: SHOW PP
S: 110 1 base de datos de la actualidad: la lista sigue
S: libre de "base de datos gratuito"
S:.
C: joesmith AUTH autenticación cuerdas
S: 230 Autenticación exitosa
C: SHOW PP

S: 110 2 bases de datos actuales: lista sigue
S: libre de "base de datos gratuito"
S: licencia "base de datos con licencia local"
S:.
9 . Consideraciones de Seguridad
Este RFC no plantea problemas de seguridad.

10 . Referencias
[ ASCII ] US-ASCII. Coded Character Set - 7-Bit de las Américas
Código para el Intercambio de Información. Estándar ANSI X3.4-1986,
ANSI, 1986.
[ FOLDOC ] Howe, Denis, ed. The Free On-Line Diccionario de
Informática, <URL: http: //wombat.doc.ic.ac.uk/>
[ ISO10646 ] ISO / IEC 10646-1: 1993. Norma Internacional -
Tecnología de la información - universal múltiple-Octeto Coded
Conjunto de caracteres (UCS) - Parte 1: Arquitectura y Básico
Plano multilingüe. UTF-8 se describe en el anexo I, adoptó
pero aún no publicada. UTF-16 se describe en el anexo Q,
aprobada pero aún no publicada.
[ JERGA ] El online de hackers Jerga Archivo, versión 4.0.0, 25 de julio
1.996, <URL: http: //www.ccil.org/jargon/>
[ KNUTH73 ] Knuth, Donald E. "The Art of Computer Programming",
Volumen 3: Clasificación y búsqueda (Addison-Wesley Publishing
Co., 1973, páginas 391 y 392). Knuth señala que el soundex
método fue descrito originalmente por Margaret K. Odell y
Robert C. Russell [Patentes de Estados Unidos (1918) 1261167 y 1435663
(1922)].
[ PZ85 ] Pollock, Joseph J. y Zamora, Antonio, "ortografía automático
la corrección en el texto científico y académico ", MCCA, 27 (4):
04 1985, 358-368.
[ RFC640 ] "Códigos de FTP Responder revisadas" Postel, J.,, RFC 640 , junio,
1975.
[ RFC821 ] Postel, J., "Simple Mail Transfer Protocol", STD 10,
RFC 821 , agosto 1982.

[ RFC822 ] Crocker, D., "Norma para el Formato de ARPA Internet
Los mensajes de texto ", STD 11, RFC 822 , agosto 1982.
[ RFC977 ] Kantor, B. y P. Lapsley, "Noticias de la Red de Transferencia
Protocolo: Un Proyecto de Norma para la Corriente-Based
Transmisión de Noticias ", RFC 977 , Febrero de 1986.
[ RFC2045 ] Freed, N., y N. Borenstein, "Internet Multipropósito
Mail Extensions (MIME) Primera Parte: Formato de los mensajes de Internet
Órganos ", RFC 2045 , noviembre de 1996.

[ RFC1738 ] Berners-Lee, T., Masinter, L. y M. McCahill, "Uniforme
Localizadores de recursos (URL) ", RFC 1738 , diciembre de 1994.
[ RFC1760 ] Haller, N., "El S / KEY contraseña del sistema de una sola vez",
RFC 1760 , febrero de 1995.
[ RFC1985 ] Freed, N. y A. Cargille, "SMTP Servicio de Extensión
Comando Canalización ", RFC 1854 , octubre de 1995.
[ RFC1939 ] Myers, J. y M. Rose, "Post Office Protocol - Versión 3",
STD 53, RFC 1939 , mayo de 1996.
[ RFC2044 ] Yergeau, F., ", un formato de transformación UTF-8 de Unicode
y la norma ISO 10646 ", RFC 2044 , octubre de 1996.
[ RFC2068 ] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
y T. Berners-Lee, "Protocolo de Transferencia de Hipertexto - HTTP / 1.1",
RFC 2068 , enero de 1997.
[ RFC2078 ] Linn, J., "Programa de Aplicación de servicio de seguridad genérico
Interfaz, Versión 2 ", RFC 2078 , enero de 1997.
[ RFC2222 ] Myers, J., "SASL
(SASL) ", RFC 2222 , octubre de 1997.
[ WEB1913 ] Revisado Unabridged Dictionary de Webster (G & C. Merriam
Co., 1913, editado por Noah Porter). Versión en línea preparado por
MICRA, Inc., de Plainfield, Nueva Jersey y editado por Patrick Cassidy
<Cassidy@micra.com>. Para más información, consulte
<URL: ftp: //uiarchive.cso.uiuc.edu/pub/etext/gutenberg/etext96/pgw*>,
y
<URL: http: //humanities.uchicago.edu/forms_unrest/webster.form.html>
[ WordNet ] Miller, GA (1990), ed. WordNet: Un léxico On-Line
Base de datos. Revista Internacional de Lexicografía. Volumen 3,

Número 4. <URL: http: //www.cogsci.princeton.edu/~wn/>

11 . Agradecimientos
Gracias a Arnt Gulbrandsen y Nicolai Langfeldt para muchos útiles
discusiones. Gracias a Bennet Yee, Doug Hoffman, Kevin Martin, y
Jay Kominek de extensas pruebas y retroalimentación sobre la inicial
implementaciones del servidor DICT. Gracias a Zhong Shao consejos
y apoyo.
Gracias a Brian Kanto, Phil Lapsley, y Jon Postel para la escritura
RFC ejemplares que fueron consultados durante la preparación de este
documento.
Gracias a Harald Alvestrand T., cuyos comentarios ayudaron mejorar esta
documento.
12 . De los autores Direcciones
Rickard E. Fe
EMail: faith@cs.unc.edu (o faith@acm.org)
Bret Martin
EMail: bamartin@miranda.org
La mayor parte de este trabajo se completó mientras Bret Martin era un
estudiante de la Universidad de Yale.

13 . Declaración de Derechos de Autor Completo
Copyright (C) The Internet Society (1997). Reservados todos los derechos.
Este documento y sus traducciones puede ser copiado y facilitado a
otros, y las obras derivadas que comentar o de otra manera explicarlo
o ayudar a su implmentation podrán ser preparados, copiados, publicados
andand distribuido, en su totalidad o en parte, sin restricción de ningún
clase, siempre que el aviso de copyright anterior y este párrafo son
Incluido en todas esas copias y trabajos derivados. Sin embargo, este
Documento en sí no puede ser modificado de ninguna manera, como mediante la eliminación
la nota de copyright o referencias a la Sociedad Internet o de otro tipo
Organizaciones de Internet, excepto cuando sea necesario con el fin de
el desarrollo de estándares de Internet, en cuyo caso los procedimientos para
copyrights definidos en el proceso de normalización de Internet debe ser
seguido, o según sea necesario traducirla a otros idiomas distintos
Inglés.
Los limitados permisos concedidos anteriormente son perpetuos y no serán
revocados por la Internet Society ni sus sucesores o cesionarios.
Este documento y la información contenida en este documento se proporciona en un
"TAL CUAL" y LA INTERNET SOCIETY Y LA INTERNET ENGINEERING
EQUIPO DE TRABAJO DE RENUNCIA A TODA GARANTÍA, EXPRESA O IMPLICADA, INCLUYENDO
PERO NO LIMITADO A CUALQUIER GARANTÍA DE QUE EL USO DE LA INFORMACIÓN
En este documento no vulnere cualquier derecho o cualquier garantía implícita de
COMERCIALIZACIÓN O IDONEIDAD PARA UN PROPÓSITO PARTICULAR.

Rfc 2229 un servidor de protocolo diccionario

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (18)

Andere mochten auch

Andere mochten auch (7)

Ähnlich wie Rfc 2229 un servidor de protocolo diccionario

Ähnlich wie Rfc 2229 un servidor de protocolo diccionario (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Rfc 2229 un servidor de protocolo diccionario