Rfc 2229 un servidor de protocolo diccionario

Red Grupo de Trabajo R. FePetición de Comentarios: 2229 U. de Carolina del Norte, Chapel HillCategorí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

http://tools.ietf.org/html/rfc2229

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.


http://tools.ietf.org/html/rfc1122#section-1.3.2

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:

420 Servidor disponible temporalmente 421 Servidor de apagar a petición del operador



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

550 de base de datos no es válido, utilice "SHOW PP" para la lista de bases de datos 551 estrategia válida, utilice "mostrar STRAT" para obtener una lista de las estrategias 552 No hay resultados 152 n se han encontrado coincidencias - texto sigue 250 ok (información de temporización opcional aquí)

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.


550 de base de datos no es válido, utilice "SHOW PP" para la lista de bases de datos 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

250 ok (información de temporización opcional aquí)


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.


250 ok (información de temporización opcional aquí)

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 230 Autenticación exitosa 531 Acceso denegado, utilice "MOSTRAR INFO" para obtener información del servidor 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 230 Autenticación exitosa 250 ok (información de temporización opcional aquí) Respuesta 330 de envío 420 Servidor disponible temporalmente 421 Servidor de apagar a petición del operador 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 531 Acceso denegado, utilice "MOSTRAR INFO" para obtener información del servidor 532 Acceso denegado, mecanismo desconocido 550 de base de datos no es válido, utilice "SHOW PP" para la lista de bases de datos 551 estrategia válida, utilice "mostrar STRAT" para obtener una lista de las estrategias 552 No hay resultados 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) <[email protected]>

C: AYUDA

S: 113 Ayuda de texto sigueS: DEFINE palabra base de datos levantó la palabra en la base de datosS: PARTIDO estrategia de base de datos de palabra partido palabra en la base de datos utilizando la estrategiaS: [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 sigueS: 151 "pingüino" wn "WordNet 1.5": texto de la definición sigueS: pingüinoS: 1. n: las aves no voladoras de patas cortas de frío sur esp. AntárticoS: las regiones que tienen los pies palmeados y alas modificado como aletasS:.S: 250 Comando completa

C: DEFINIR * Shortcake

S: 150 2 definiciones encontradas: lista sigueS: 151 "Shortcake" wn "WordNet 1.5": texto sigueS: ShortcakeS: 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 sigueS: ShortcakeS: \ 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:.S: 250 Comando completa

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 sigueS: wn "WordNet 1.5"S: FOLDOC "Free On-Line Diccionario de Informática"S: la jerga "Hacker Jargon File"S:.S: 250 Comando completa

C: Mostrar STRAT

S: 111 5 estrategias presentes: lista sigueS: "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:.S: 250 Comando completa

C: PARTIDO FOLDOC regex "s.si"

S: 152 7 se han encontrado coincidencias: lista sigueS: FOLDOC Fast SCSIS: FOLDOC SCSIS: FOLDOC SCSI-1S: FOLDOC SCSI-2


S: FOLDOC SCSI-3S: FOLDOC Ultra-SCSIS: FOLDOC Wide SCSIS:.S: 250 Comando completa

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) <[email protected]>

C: SHOW PP

S: 110 1 base de datos de la actualidad: la lista sigueS: libre de "base de datos gratuito"S:.S: 250 Comando completa

C: joesmith AUTH autenticación cuerdas

S: 230 Autenticación exitosa

C: SHOW PP


S: 110 2 bases de datos actuales: lista sigueS: libre de "base de datos gratuito"S: licencia "base de datos con licencia local"S:.S: 250 Comando completa

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 <[email protected]>. 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: [email protected] (o [email protected])

Bret Martin EMail: [email protected]

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

Technology

Transcript of Rfc 2229 un servidor de protocolo diccionario