Network Working Group J. Postel Request for Comments: 805 ISI 8 de Febrero de 1982 Apuntes del Congreso de Correo por Ordenador Introducción Se mantuvo un congreso el 11 de Enero de 1982 en el Instituto de Ciencias de la Información de USC para plantear cuestiones de direccionamiento en el correo por ordenador. Los asistentes están listados al final de este memorándum. La conclusión principal alcanzada en el congreso es extender el formato de buzón "usuario@máquina" a "usuario@máquina.dominio", donde el dominio puede además ser estructurado. Panorama General El congreso se abrió con una breve discusión de sus objetivos y una revisión de la agenda. El congreso estaba llamado a discutir unas pocas cuestiones específicas en los sistemas de correo de texto para la Internet ARPA. En particular, las de mayor incumbencia son las cuestiones de direccionamiento debido a que desarrollamos una Internet en la cual la retransmisión del correo es una situación habitual. Necesitamos plantear alternativas en el diseño del sistema de correo para facilitar una alta utilidad a un coste razonable. Un esquema sugerido es crear "dominios de correo" que son otro nivel de direccionamiento. El esquema provisional de encaminamiento fuente, a pesar de ser efectivo para algunos casos, conduce a algunos problemas. Un test clave de esquemas de direccionamiento es el procedimiento para enviar copias de una respuesta a un mensaje a la gente que recibió copias del mensaje original. Los documentos clave para el congreso fueron los RFCs 788, 799 y 801. Jon Postel proporcionó una breve revisión del plan de transición de NCP a TCP (RFC 801). El énfasis estuvo en el correo, la tabla de máquinas de Internet y el rol de un Servidor de Nombres de Máquinas (Host Name Server). La mayor parte de la reunión se dedicó a una discusión de amplio Postel [Pág. 1] RFC 805 Apuntes del Congreso de Correo por Ordenador Febrero 1982 espectro acerca del problema genérico de identificación de buzones. En particular se planteó la noción de una estructura jerárquica de nombres de dominio, y se abordaron los temas relacionados con servidores de nombres incluyendo los tipos de información que deberían facilitar los servidores de nombres. Nombres de Dominio Una de las ideas interesantes que emergieron de este debate fue que el modelo de identificación de buzón "usuario@máquina" debería, en principio, ser reemplazado por un modelo "id-único@id-ubicación" (id -> identificador), donde el id-único debería ser un identificador único en el mundo para este buzón (independiente de la ubicación) y se debería informar al id-ubicación de dónde encontrar el buzón. Sin embargo, se admitió que el modelo "usuario@máquina" estaba bien establecido y que había tantas elaboraciones diferentes del campo "usuario" ya en uso que no tenía sentido perseguir esta idea de "identificador único" ahora. Se discutieron diversas alternativas para estructurar y ordenar las extensiones al campo "máquina" para convertirlo en un "identificador de ubicación" general. Estas básicamente implicaban añadir mas información jerárquica al nombre, bien a la derecha o a la izquierda de la @, con las porciones de "orden superior" más a la derecha o más a la izquierda. Estaba claro que el contenido de información de todas estas alternativas sintácticas era el mismo, de manera que se debería elegir la que causase menor dificultad para los sistemas existentes. Por lo tanto se decidió añadir toda la información nueva a la derecha del signo @, dejando el campo "usuario" de la izquierda determinado completamente por cada sistema (en particular para prevenir el problema de que algunos sistemas ya usan el punto (.) internamente como parte de nombres de usuario). La conclusión en este área fue que el actual identificador de buzón "usuario@máquina" se debería extender a "usuario@máquina.dominio" donde "dominio" podría ser una jerarquía de dominios. En particular, el campo "máquina" se convertiría en un campo Postel [Pág. 2] RFC 805 Apuntes del Congreso de Correo por Ordenador Febrero 1982 "ubicación" y la estructura se leería (de izquierda a derecha) desde el más específico al más general. Por ejemplo: "Postel@F.ISI.IN" podría ser el buzón de Jon Postel en la máquina F en el complejo ISI del dominio INTERNET. Formalmente, en el RFC733, la regla de definición de indicador de máquina sería: indicador de máquina = ( "at" / "@" ) dominios dominios = nodo / nodo "." dominios Nótese que solo se permite un "at" o "@" y los dominios forman una jerarquía con el ámbito más general al final. Y nótese que la elección de los nombres de dominio se debe controlar administrativamente y los nombres de dominio de más alto nivel deben ser únicos a nivel mundial. El tipo de nombrado de dominios jerárquico difiere del encaminamiento fuente en que el primero da direccionamiento absoluto mientras que el último da direccionamiento relativo. Servidores de Nombres La discusión de servidores de nombres identificó tres funciones de estos: "paginas blancas", "id-único a id-ubicación", e "id-ubicación a dirección". El servicio de "páginas blancas" es una forma de buscar un usuario Postel [Pág. 3] RFC 805 Apuntes del Congreso de Correo por Ordenador Febrero 1982 por su nombre y otras propiedades utilizando un patrón de búsqueda y puede devolver varios "aciertos" de la base de datos. Cada acierto debe tener un identificador único asociado. El servicio de "id-único a id-ubicación" devuelve la cadena de caracteres id-ubicación donde actualmente se encuentra el id-único. El servicio "id-ubicación a dirección" devuelve una dirección de red (numérica) correspondiente al identificador de ubicación. Si el identificador de ubicación es el nombre de una máquina en el dominio actual, está claro que la dirección devuelta será la dirección a la que enviar el correo, pero si el identificador de ubicación es de algún otro dominio, entonces la dirección devuelta puede ser bien la dirección a la que enviar el correo o la dirección de un servidor de nombres para ese dominio, y estos dos casos deben distinguirse. La conclusión de esta discusión fue que se debe definir pronto un servicio de nombres identificador de ubicación a dirección. Los otros tipos de servidores de nombres no fueron discutidos más, y no se requieren en la implementación. Otro aspecto del servidor de nombres es devolver información adicional además de la dirección. En particular para el correo es importante saber qué procedimientos de correo implementa el destino (NCP/FTP, TCP/SMTP, etc.). Se discutieron dos aproximaciones: una es codificar la información como nombres de servicio (p. ej. NCP/SMTP), y la otra es por referencia al protocolo y números de puerto (p. ej. PROTOCOLO=6, PUERTO=25). Otra sugerencia fue que la petición debe ser "id-ubicación, servicio" (p. ej. "ISIF.IN,CORREO") y la respuesta debería ser el identificador de ubicación, dirección, protocolo y puerto. Se sugirió que otra forma de obtener esta información sería que en vez de (o en adición a) tener esta información en el servidor de nombres, uno debería obtener estos datos del propio máquina a través de alguna clase de petición o protocolo "quien eres". También se discutió la dotación inicial para el servicio de nombres. Parece útil comenzar con un fichero de texto que pueda ser accedido Postel [Pág. 4] RFC 805 Apuntes del Congreso de Correo por Ordenador Febrero 1982 vía FTP, y tener ambas formas "Tipo Telnet" (p. ej. basado en TCP) y "Datagrama" (p. ej. basado en UDP) de acceso a un servidor de peticiones. Esto podría ser posible como una extensión del servidor de nombres IEN-116. Otra cuestión fue la implementación distribuida vs. centralizada del servicio de búsqueda de nombres. Se reconoció que servidores separados para cada dominio tiene ventajas administrativas y de mantenimiento, pero un servidor central puede ser un primer paso útil. También se admitió que cada base de datos distinta debería ser replicada varias veces y debería estar disponible desde distintos servidores para un servicio robusto y fiable. Un Ejemplo: Supongamos que la nueva especificación de buzón es de la forma USUARIO@HOST.ORG.DOMINIO. p. ej. Postel@F.ISI.IN Una máquina fuente que envía correo a esta dirección primero solicita un servidor de nombres para el dominio IN (dando la ubicación completa "F.ISI.IN"). El resultado de la petición es bien (1) la dirección final de la máquina destino (F.ISI), o (2) la dirección de un servidor de nombres para ISI, o (3) la dirección de un agente de reenvío para ISI. En los casos 1 y 3, la máquina fuente envía el correo a la dirección devuelta. En el caso 2, la máquina fuente solicita el servidor de nombres de ISI y... (llamada recursiva a este párrafo). Elementos de Acción: Revisión del RFC 733 Para incluir el procedimiento de nombrado jerárquico de máquina y dominio, y para eliminar las características en las que hay que dar marcha atrás en el congreso de Correo por Ordenador el 10 de Enero del 1979. Postel [Pág. 5] RFC 805 Apuntes del Congreso de Correo por Ordenador Febrero 1982 Por: Dave Crocker Vencimiento 15 de Febrero del 1982 Descripción del Servidor de Nombres de Host Para especificar un modo de obtener las conversiones de nombre a dirección y para descubrir servicios ofrecidos. También cómo obtener información sobre nombres de dominio. Por: Jon Postel Vencimiento 15 de Febrero de 1982 Revisión del Plan de Transición Para incluir nuevos nombres de máquina y dominio. Por: Jon Postel Vencimiento 15 de Febrero de 1982 Revisión del SMTP Para incluir nuevos nombres de máquina y dominio. Vencimiento Sin especificar Revisión de la Descripción del Sistema de Correo Cómo crear sistemas de correo, incluyendo el uso de SMTP y Servidores de Nombres de Host. Por: Jon Postel Vencimiento: Sin especificar Conversión de Programas de Usuario y Programas de Correo Los Programas tienen que manejar los puntos en el campo "máquina". Postel [Pág. 6] RFC 805 Apuntes del Congreso de Correo por Ordenador Febrero 1982 Muchos programas de muchas máquinas tendrán que ser modificados en mayor o menor medida. En muchos casos las modificaciones deberían ser bastante simples. Por: un reparto de miles Vencimiento: Sin especificar (Ver el siguiente elemento) Fijar una fecha para que funcione enviar mensajes con puntos en el campo "máquina". Debe haber una fecha después de la cual esté bien enviar campos de máquina con puntos a través de la ARPANET y el mundo Internet sin que se quejen los receptores. Por: DARPA (Duane Adams) Vencimiento: 1 de Marzo de 1982 Asistentes: Duane A. Adams DARPA/IPTO Adams@ISI (202) 694-8096 Vint Cerf DARPA/IPTO Cerf@ISI (202) 694-3049 Harry Forsdick BBN Forsdick@BBN (617) 497-3638 Eric Schienbrood BBN shienbrood@bbn-unix (617) 497-3756 Bob Thomas BBN BThomas@BBND (617) 497-3483 Bob Fabry Berkeley Fabry@Berkeley (415) 642-2714 Bill Joy Berkeley unj@berkeley (415) 642-7780 Gene Ball CMU Ball@CMUA (412) 578-2569 Anil Agarwal COMSAT Agarwal@ISID (301) 863-6103 David L. Mills COMSAT Mills@ISID (202) 863-6092 Dave Crocker Univ. Del DCrocker@Udel (302) 738-8913 Ray McFarland DoD McFarland@ISIA (301) 796-6290 Dave Lebling MIT PDL@MIT-XX (617) 253-1440 Paul Mockapetris ISI Mockapetris@ISIF (213) 822-1511 Jon Postel ISI Postel@ISIF (213) 822-1511 Carl Sunshine ISI Sunshine@ISIF (213) 822-1511 Mark Crispin Stanford U. Admin.MRC@SCORE (415) 497-1407 Bob Braden UCL[A] braden@ISIA (uk) (01)387-7050 Steve Kille UCL UCL-Netwiz@ISIE (uk) (01)387-7050 Postel [Pág. 7] RFC 805 Apuntes del Congreso de Correo por Ordenador Febrero 1982 Bill Tuck UCL UKSAT@ISIE (uk) (01)387-7050 Marv Solomon Univ. Wisc Solomon@UWisc Ed Taft Xerox Parc Taft@Parc-Maxc (415) 494-4419 Traducción al Castellano: Carlos Varela Cuadrado (Septiembre 2001) Postel [Pág. 8]