Network Working Group J. Postel Request For Comments: 2223 J. Reynolds Obsoletos: 1543, 1111, 825 ISI Categoría: Informativo Octubre 1997 Instrucciones para Autores de Petición de Comentarios (RFC) (Request For Comments) Status de este memorándum Este memorándum proporciona información para la comunidad Internet. No especifica ningún estándar de Internet de tipo alguno. Su distribución es ilimitada. Nota de Copyright Copyright (C) The Internet Society (1997). Todos los derechos reservados. Indice 1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Principios Editoriales . . . . . . . . . . . . . . . . . . . 3 3. Normas de Formato. . . . . . . . . . . . . . . . . . . . . . 4 3a. Normas de Formato ASCII. . . . . . . . . . . . . . . . . . . 5 3b. Normas de Formato PostScript . . . . . . . . . . . . . . . . 6 4. Cabecera . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4a. Cabecera de primera página . . . . . . . . . . . . . . . . . 7 4b. Cabecera normal. . . . . . . . . . . . . . . . . . . . . . . 8 4c. Pie de página normal . . . . . . . . . . . . . . . . . . . . 8 5. Sección de Status. . . . . . . . . . . . . . . . . . . . . . 8 6. Nota de Copyright. . . . . . . . . . . . . . . . . . . . . . 9 7. Sección de Introducción. . . . . . . . . . . . . . . . . . . 9 8. Sección de Referencias . . . . . . . . . . . . . . . . . . 10 9. Sección de Consideraciones de Seguridad. . . . . . . . . . 11 10. Sección de Dirección del Autor . . . . . . . . . . . . . . 11 11. Sección de Copyright. . . . . . . . . . . . . . . . . . . 11 12. Relación con otros RFCs. . . . . . . . . . . . . . . . . . 12 13. Proceso para Estándares de Protocolo . . . . . . . . . . . 13 14. Contacto . . . . . . . . . . . . . . . . . . . . . . . . . 13 15. Listas de Distribución . . . . . . . . . . . . . . . . . . 13 16. Indice RFC . . . . . . . . . . . . . . . . . . . . . . . . 14 17. Consideraciones de Seguridad . . . . . . . . . . . . . . . 14 18. Referencias. . . . . . . . . . . . . . . . . . . . . . . . 14 19. Dirección del Autor. . . . . . . . . . . . . . . . . . . . 15 20. Apéndice - "macros nroff" para RFC's . . . . . . . . . . . 16 21. Declaración Completa de Copyright. . . . . . . . . . . . . 21 Postel & Reynolds Informativo [Pág. 1] RFC 2223 Instrucciones para Autores de RFC Octubre 1997 1. Introducción Este documento de 'Petición de Comentarios' (RFC) (Request For Comments) proporciona información acerca de la preparación de RFCs, y ciertos principios relacionados con la publicación de RFCs. La serie de notas RFC cubre un amplio rango de intereses. Los temas fundamentales son Internet y el grupo de protocolos TCP/IP. Sin embargo, cualquier tema relacionado con la comunicación entre ordenadores es aceptable, sujeto a la discreción del Editor RFC. Cualquier persona puede enviar memorandums propuestos para ser RFCs. Una gran fuente de memorandums que se convierten en RFCs es la 'Internet Engineering Task Force' (IETF). Los grupos de trabajo (Work Groups - WGs) de la IETF desarrollan sus memorandums de trabajo (conocidos como Borradores Internet (Internet Drafts - I-Ds) hasta que piensan que están listos para su publicación, momento en el cual son revisados por el 'Internet Engineering Steering Group' (IESG), y si son aprobados son enviados por el IESG al Editor RFC. La mayoría de los memorandum enviados al Editor RFC desde fuentes independientes serán revisados por el IESG por su posible relación con trabajos en curso en los Grupos de Trabajo de la IETF. Los RFCs son distribuídos en la red siendo almacenados como ficheros de acceso público y enviando un mensaje a la lista de distribución indicando la disponibilidad del memorandum. Los ficheros en la red son copiados por gente interesada e impresos o visualizados en su máquina y en su lugar de trabajo. Esto significa que el formato de éstos debe cumplir las restricciones de una amplia variedad de equipo de impresión y visualización. (Los RFCs pueden ser también enviados via correo electrónico en repuesta a una consulta por correo electrónico, o pueden ser accedidos a través de herramientas de búsqueda de información y bases de datos tales como Gopher, Wais o la 'World Wide Web' (WWW). Los RFCs se han publicado tradicionalmente, y así se seguirán publicando, en texto ASCII. Mientras que los RFCs primarios son siempre ficheros de texto ASCII, se pueden suministrar versiones alternativas o secundarias en PostScript. Esta decidsión viene motivada por el deseo de incluir diagramas, dibujos, y cosas por el estilo en los RFCs. Los documentos PostScript (sólo en papel, por el momento) son más llamativos visualmente y tienen una mejor legibilidad. Se eligió PostScript como la forma de publicación vistosa de RFC Postel & Reynolds Informativo [Pág. 2] RFC 2223 Instrucciones para Autores de RFC Octubre 1997 entre otros sistemas (p. ej., impress, interpress, oda) por la perceptiblemente amplia disponibilidad de impresoras PostScript. Sin embargo, muchos usuarios de RFC leen los documentos electrónicamente y usan diversas herramientas orientadas a texto (p. ej., emacs, grep) para buscar en ellos. A menudo, se incluyen breves extractos de RFCs en mensajes de correo electrónico. Esto no es todavía práctico con ficheros PostScript. Los sistemas de producción PostScript son menos estándar de lo deseable y varios de los sistemas de producción de documentos que dicen producir PostScript producen resultados no estándar. En el futuro, puede ser necesario identificar un conjunto de sistemas de producción autorizados para su uso en la producción de RFCs PostScript, basándose en cuán razonables son los ficheros de salida que produzcan. 2. Principios Editoriales Los documentos propuestos para ser RFCs son revisados por el Editor RFC y posiblemente por otros revisores por él seleccionados. El resultado de la revisión puede ser el sugerir al autor ciertas mejoras del documento previas a su publicación. Ocasionalmente, puede hacerse patente que el tema de un RFC propuesto sea también el asunto de un Grupo de Trabajo de la IETF, y que el autor podría coordinarse con el grupo de trabajo para provecho de ambos. El resultado usual de esto es la producción de un memorandum revisado como Borrador Internet del grupo de trabajo, que emerge eventualmente del proceso de la IETF como una recomendación del IESG al Editor RFC. En algunos casos podría determinarse que el documento enviado no es material apropiado para ser publicado como RFC. En algunos casos puede ser necesario incluir en el documento una declaración basada en los análisis acerca de las ideas contenidas en el documento. Esto podría hacerse en el caso de que el documento sugiriera ideas relevantes pero inapropiadas o inseguras, además de otras situaciones. El Editor RFC puede hacer pequeños cambios en el documento, especialmente en el área de estilo y formato, pero en algunos casos también en el propio texto. Algunas veces el Editor RFC acometerá cambios más significativos, especialmente cuando no se siguen las normas de formato (ver más abajo). Sin embargo, la mayor parte de las Postel & Reynolds Informativo [Pág. 3] RFC 2223 Instrucciones para Autores de RFC Octubre 1997 veces el documento será devuelto al autor para que éste haga el trabajo adicional. Los documentos destinados a convertirse en RFCs que especifiquen seguimiento de estándares de protocolo deben ser aprobados por el IESG antes de ser enviados al Editor RFC. El procedimiento establecido es que cuando el IESG completa el trabajo sobre un documento destinado a convertirse en un RFC de seguimiento de estándar, la comunicación tendrá lugar entre el Secretario del IESG y el Editor RFC. Generalmente, los documentos en cuestión son Borradores Internet. La comunicación normalmente cita el Borrador Internet exacto en cuestión (por su nombre de fichero). El Editor RFC debe asumir que sólo ese fichero será procesado para convertirse en RFC. Si el autor tiene pequeñas correciones que hacer al texto, deberán ser enviadas al Editor RFC separadamente (o como un "diff"); los autores no tendrán que enviar una nueva versión del documento. En algunos casos, los autores preparan versiones secundarias alternativas a los RFCs en formato vistoso usando PostScript. Dado que la versión en texto ASCII es la versión primaria, la versión PostScript debe concordar con la versión texto. El Editor RFC debe decidir si la versión PostScript es "la misma que" la versión ASCII antes de que la versión PostScript pueda ser publicada. El efecto de lo anterior es que el Editor RFC primero procesa la versión ASCII del memorandum para su publicación como RFC. Si el autor desea en ese momento enviar una versión PostScript que concuerde con la versión ASCII (y el Editor RFC está de acuerdo), entonces la versión PostScript será instalada en los repositorios RFC y anunciada a la comunidad. Debido a diversas presiones de tiempo del personal de la Editorial RFC, el tiempo transcurrido entre la entrega y la publicación puede variar mucho. Se considera aceptable consultar (ping) al Editor RFC acerca del estado de un RFC durante este periodo (pero no más de una vez por semana). Las dos semanas que preceden a un encuentro de la IETF son generalmente muy ajetreadas, de forma que los RFCs enviados poco antes de un encuentro IETF serán publicados casi con toda seguridad después del encuentro. 3. Normas de Formato Para cumplir con las restricciones de distribución, se establecen las siguientes normas para los dos formatos permitidos para RFCs: ASCII y PostScript. Postel & Reynolds Informativo [Pág. 4] RFC 2223 Instrucciones para Autores de RFC Octubre 1997 El Editor RFC intenta asegurar un estilo RFC consistente. Para conseguir esto el Editor puede decidir reformatear el RFC entregado. Esto es mucho más sencillo de hacer si la entrega se adapta al estilo de los RFCs más recientes. Por favor, eche un vistazo a los RFCs más recientes y prepare el suyo en el mismo estilo. Debe enviar un documento editable electrónicamente al Editor RFC. El Editor RFC puede efectuar cambios menores de formato o estilo o requerir que los haga usted e insertará el número de RFC actual. La mayoría de los RFCs son procesados por el Editor RFC con el programa unix "nroff", usando un conjunto simple de órdenes de formato del paquete de macros "ms" (ver el Apéndice). Si un memorandum enviado para ser un RFC ha sido preparado por el autor usando nroff, será de gran ayuda hacérselo saber al Editor RFC en el momento de enviarlo. 3a. Normas de Formato ASCII Los códigos de caracteres son ASCII. Cada página debe estar limitada a 58 líneas seguidas de un salto de página en una línea aparte. Cada línea está limitada a 72 caracteres seguidos de un retorno de carro y un salto de línea. No se permiten caracteres en negrita o subrayados. Estas restricciones en "altura" y "anchura" incluyen cabeceras, pies de página, números de página o sangría de izquierda. No rellenar el texto con espacios extra para proporcionar un margen derecho uniforme. No cortar palabras en el margen derecho. No se usarán pies de página. Si tales anotaciones son necesarias, pónganse al final de la sección, o al final del documento. Usar espaciado simple en el texto de un párrafo y una línea en blanco entre párrafos. Nótese que el número de páginas de un documento y los números de página que abarca una sección cambiarán seguramente con el reformateo. Por ello las referencias cruzadas por número de sección en el texto son normalmente más fáciles de mantener consistentes que las referencias cruzadas por número de página. Postel & Reynolds Informativo [Pág. 5] RFC 2223 Instrucciones para Autores de RFC Octubre 1997 Los RFCs en formato ASCII pueden ser enviados al Editor RFC por correo electrónico (o como ficheros), tanto en el formato de publicación definitivo como en nroff. Si planea entregar un documento en nroff, por favor consulte primero al Editor RFC. 3b. normas de Formato PostScript El tamaño de página estándar es 8 1/2 por 11 pulgadas. Márgenes de 1 pulgada por todos los lados (arriba, abajo, izquierda y derecha). El texto principal deberá tener un tamaño de punto no menor de 10 puntos con un interlineado de 12 puntos. Las notas a pie de página y las notaciones gráficas no serán menores de 8 puntos con un interlineado de 9.6 puntos. Hay tres fuentes aceptables: Helvetica, Times Roman y Courier. Más sus versiones negrita y cursiva (bastardilla). Estas son las tres fuentes estándar en la mayoría de impresoras PostScript. Prepárense los diagramas e imágenes basados en el menor denominador común PostScript. Considérese la funcionalidad de las impresoras PostScript comunes y sus requerimientos de memoria. No deben usarse las siguientes órdenes PostScript: initgraphics, erasepage, copypage, grestoreall, initmatrix, initclip, banddevice, framedevice, nulldevice y renderbands. Nótese que el número de páginas de un documento y los números de páginas que abarquen las diferentes secciones probablemente diferirán entre la versión ASCII y la PostScript. Por ello las referencias cruzadas por número de sección en el texto son normalmente más fáciles de mantener consistentes que las referencias cruzadas por número de página. Estas normas PostScript son susceptibles de cambio y expansión conforme se acumule experiencia. Los RFCs en formato PostScript pueden ser enviados al Editor RFC por correo electrónico (o como ficheros), tanto en el formato de publicación definitivo como en nroff. Si planea entregar un documento en PostScript, por favor consulte primero al Editor RFC. Nótese que como la versión entexto ASCII del RFC es la versión primaria, la versión PostScript debe ajustarse a la versión texto. El Editor RFC debe decidir si la versión PostScript es "la misma Postel & Reynolds Informativo [Pág. 6] RFC 2223 Instrucciones para Autores de RFC Octubre 1997 que" la versión ASCII antes de que la versión PostScript pueda ser publicada. 4. Cabeceras y pies de página Tenemos la cabecera de la primera página, las cabeceras normales y los pies de página. 4a. Primera página Por favor, vea la primera página de este memorandum para ver un ejemplo de cabecera de primera página. En la primera página no haz cebcera normal. El principio de la primera página tiene los siguientes elementos: Network Working Group La cabecera tradicional para el grupo que fundó las series RFC. Aparece en la primera línea, en la parte izquierda de la cabecera. Request for Comments: nnnn Identifica el documento como un 'Petición de Comentarios' (RFC) y especifica el número. Indicado en la segunda línea en la parte izquierda. El número real es completado en el último momento antes de la publicación por el Editor RFC. Autor El nombre del autor (Primera inicial y primer apellido sólo) indicado en la primera línea, en la parte izquierda de la cabecera. Organización La organización del autor, indicada en la parte derecha de la segunda línea. Fecha Esto es el Mes y Año de la Publicación RFC. Indicado en la parte derecha de la tercera línea. Actualizados u Obsoletos Si este RFC actualiza o deja obsoleto otro RFC, se indica Postel & Reynolds Informativo [Pág. 7] RFC 2223 Instrucciones para Autores de RFC Octubre 1997 mediante una tercera línea en la parte izquierda de la cabecera. Categoría La categoría de este RFC, una entre: Seguimiento de Estándares, Mejores Prácticas Actuales, Informativo, o Experimental. Esto se indica en la tercera (si no hay indicación Actualizados u Obsoletos) o cuarta línea, parte izquierda. Otros Números Otros números en las series de notas RFC incluye la subserie 'Para Su Información (FYI) (For Your Information) [4], 'Mejores Prácticas Actuales' (BCP) (Best Current Practice) [5], y STD (Estándar) [6]. Se colocan en la parte izquierda. Título El título aparece, centrado, bajo el resto de la cabecera. No se admiten puntos en el título. Si hay múltiples autores y éstos provienen de múltiples organizaciones la parte derecha de la cabecera puede contener líneas adicionales para acomodarlos y asociar correctamente los autores a sus organizaciones. 4b. Cabeceras normales La cabecera normal en una sóla línea (en la segunda página y todas las siguentes) contiene el número RFC en la parte izquierda (RFC NNNN), el título (posiblemente acortado) centrado, y la fecha (Mes Año) en la parte derecha. 4c. Pies de página El pie de página en una sóla línea (en todas las páginas) contiene el apellido del autor a la izquierda, la categoría centrada y el número de página en la parte derecha ([Pág. N]). 5. Sección Status Cada RFC debe incluir en su primera página la sección "Status de este memorandum", la cual contendrá dos elementos: (1) un párrafo describiendo el tipo del RFC y (2) las condiciones de distribución. El contenido de esta sección será una de las cuatro declaraciones Postel & Reynolds Informativo [Pág. 8] RFC 2223 Instrucciones para Autores de RFC Octubre 1997 siguientes: Seguimiento de Estándares "Este documento especifica un Internet standards track protocol para la comunidad Internet, y solicita su discusión y sugerencias para posibles mejoras. Por favor, remítase a la edición actual del "Estándares de Protocolo Oficiales de Internet" (STD 1) para las condiciones de estandarización y status de este protocolo. La distribución de este memorandum es ilimitada." Mejores Prácticas Actuales "Este documento especifica un 'Mejores Practicas Actuales' de Internet para la Comunidad Internet, y solicita su discusión y sugerencias para posibles mejoras. La distribución de este memorandum es ilimitada." Experimental "Este memorándum define un Protocolo Experimental para la comunidad Internet. Este memorándum no especifica ningún Estándar de Internet. Se solicita su discusión y sugerencias. La distribución de este memorandum es ilimitada." Informativo "Este memorándum proporciona información para la comunidad Internet. Este memorándum no especifica ningún Estándar de Internet. La distribución de este memorándum es ilimitada." 6. Nota de los derechos de autor Inmediatamente a continuación de la sección Status, figura la frase "Copyright (C) The Internet Society (fecha). Todos los derechos reservados.".Vea también la Sección 11 para la declaración completa que debe aparecer al final del documento. 7. Sección Introducción Cada RFC debe tener una sección Introducción que explique (entre otras cosas) la motivación del RFC y describa (si es apropiado) la aplicabilidad del protocolo descrito. Normalmente, ésta será la sección "abstract" del Borrador Internet. Si el RFC no se basa en un Borrador Internet, otras posibilidades son: Postel & Reynolds Informativo [Pág. 9] RFC 2223 Instrucciones para Autores de RFC Octubre 1997 Protocolo Este protocolo está pensado para proporcionar el servicio tal-y-tal, y para ser usado en ordenadores entre clientes y servidores. Típicamente, los clientes están en estaciones de trabajo y los servidores en ordenadores centrales. o Este protocolo está pensado para proporcionar el servicio tal-y-tal, y para ser usado entre unidades de propósito especial como servidores de terminales o enrutadores y equipos de monitorización. Discusión El propósito de este RFC es centrar la discusión sobre problemas particulares de Internet y posibles métodos de solución. Las soluciones propuestas en este documento no se consideran como estándares de Internet. Se espera más bien que el consenso general emergerá como la solución apropiada a tales problemas, llevando eventualmente a la adopción de estándares. Interés Este RFC se está distribuyendo a los miembros de la comunidad Internet con el propósito de solicitar sus reacciones a las propuestas contenidas en él. Aunque los temas discutidos pueden no ser directamente relevantes a los problemas de investigación de Internet, pueden resultar interesantes para un cierto número de investigadores e implementadores. Informe de Status En respuesta a la necesidad de mantenimiento de la información actual acerca del estado y progreso de diversos proyectos en la comunidad Internet, se publica este RFC para provecho de los miembros de la comunidad. La información contenida en este documento es correcta a fecha de publicación, pero susceptible de cambio. Subsiguientes RFCs reflejarán tales cambios. Estos párrafos no necesitan ser seguidos al pie de la letra, pero la intención general del RFC debe ser puesta en claro. 8. Sección Referencias Postel & Reynolds Informativo [Pág. 10] RFC 2223 Instrucciones para Autores de RFC Octubre 1997 Prácticamente todos los RFCs contienen menciones de otros documentos, y estas son listadas en una sección Referencias hacia el final del RFC. Hay muchos estilos para las referencias, y los RFCs tienen una propia. Por favor, siga el estilo de referencia usado en RFCs recientes. Véase la sección referencias de este RFC como ejemplo. Nótese por favor que para los protocolos a los que se ha asignado números STD, el número STD debe ser incluído en la referencia. En muchos documentos de seguimiento de estándares se utilizan varias palabras para significar los requerimientos de la especificación. A menudo estas palabras están en mayúsculas. BCP 14 y RFC 2119 [3] definen estas palabras tal y como deben ser interpretadas en los documentos IETF. 9. Sección Consideraciones de Seguridad Todos los RFCs deben contener usección hacia el final del documento que trate de las consideraciones de seguridad del protocolo o procedimientos que conforman el tema principal del RFC. 10. Sección Dirección del Autor Cada RFC debe tener al final del todo una sección que dé la dirección del autor, incluyendo el nombre y dirección postal, número de teléfono (opcional: número de FAX) y la dirección de correo electrónico de Internet. 11. Sección Copyright Por BCP 9, RFC 2026 [2], "La siguiente nota y renuncia de copyright debe ser incluída en toda la documentación relacionada con estándares de ISOC." La siguiente declaración debe ser colocada en la última página del RFC, como la "Declaración Completa de Copyright". "Copyright (C) The Internet Society (fecha). Todos los derechos reservados. Este documento y sus traducciones pueden ser copiados y facilitados a otros, y los trabajos derivados que lo comenten o expliquen o ayuden a su implementación pueden ser preparados, copiados, publicados y distribuídos, enteros o en parte, sin restricción de ningún tipo, siempre que se incluyan, en todas esas copias y trabajos derivados, este párrafo y la nota de copyright expuesta arriba . Sin embargo, este documento en sí no debe ser modificado de ninguna forma, como por ejemplo eliminando la nota de copyright o referencias a la 'Internet Society' u otras organizaciones de Internet, excepto cuando sea necesario en el desarrollo de estándares Internet, en cuyo caso se seguirán los Postel & Reynolds Informativo [Pág. 11] RFC 2223 Instrucciones para Autores de RFC Octubre 1997 procedimientos para copyrights definidos en el proceso de Estándares Internet, o con motivo de su traducción a otras lenguas aparte del Inglés. Los permisos limitados concedidos más arriba son perpétuos y no serán revocados por la 'Internet Society' o sus sucesores o cesionarios. Este documento y la información contenida en él se proporcionan en su forma "TAL CUAL" y LA INTERNET SOCIETY Y LA INTERNET ENGINEERING TASK FORCE RECHAZAN CUALESQUIERA GARANTIAS, EXPRESAS O IMPLICITAS, INCLUYENDO, PERO NO LIMITADAS A, CUALQUIER GARANTIA DE QUE EL USO DE LA INFORMACION AQUI EXPUESTA NO INFRINGIRA NINGUN DERECHO O GARANTIAS IMPLICITAS DE COMERCIALIZACION O IDONEIDAD PARA UN PROPOSITO ESPECIFICO. 12. Relación con otros RFCs A veces un RFC añade información a un tema tratado en un RFC previo o reemplaza completamente a un RFC anterios. Existen dos términos usados en estos casos respectivamente, Actualizados y Obsoletos. Un documento que deja obsoleto un documento anterior puede servir por sí sólo. Un documento que simplemente actualiza un documento anterior no sirve por sí mismo; es algo que debe añadirse o insertarse en el documento preexistente, y tiene una utilidad limitada independientemente. Los términos Supercedes y Replaces ya no se utilizan. Actualizados Se usa como referencia en un nuevo elemento que no puede utilizarse por sí sólo (es decir, uno que complementa a un documento previo), para refereirse al documento previo. La nueva publicación es una parte que complementará o será añadida al documento existente; p. ej., un suplemento, o información aparte o extra que debe añadirse al documento original. Obsoletos Se usa como referencia a un documento anterior que es reemplazado por este documento. Este documento contiene o bien información revisada, o bien toda la información anterior más información nueva, sea cual sea la extensión de la nueva información, es decir, este documento puede ser usado por sí solo, sin referencias al documento antiguo. Por ejemplo: Postel & Reynolds Informativo [Pág. 12] RFC 2223 Instrucciones para Autores de RFC Octubre 1997 En los RFCs de Números Asignados debe usarse el término Obsoletos ya que el nuevo documento incorpora nueva información (no importa lo breve que sea) dentro del texto de información existente y está más actualizado que el documento anterior y, por tanto, lo reemplaza y lo deja obsoleto. En las listas de RFCs o el Indice-RFC (pero no en los RFCs mismos) se puede usar lo siguiente con los primeros documentos para apuntar a documentos posteriores. Obsoleto por Se usa para citar los nuevos documentos que reemplazan a un documento anterior. Actualizado por Utilizado para citar secciones más nuevas las cuales deben añadirse al documento existente aún en uso. 13. Proceso para Estándares de Protocolo Véase el memorándum "Protocolos Estándares Oficiales de Internet" (STD 1) para la declaración definitiva sobre estándares de protocolo y su publicación [1]. El procedimiento establecido es que cuando el IESG completa el trabajo de un documento destinado a convertirse en un estándar se establecerá la comunicación del Secretario del IESG al Editor RFC. Generalmente, los documentos en cuestión son Borradores Internet. Normalmente la comunicación cita el Borrador Internet exacto (por nombre de fichero) en cuestión. El Editor RFC debe asumir que sólo este fichero está destinado a ser procesado para convertirse en RFC. Si el autor tiene pequeñas correciones que hacer al texto, deben ser enviadas al Editor RFC separadamente (o como un "diff"), no enviar una nueva versión del documento. 14. Contacto Para contactar con el Editor RFC envíe un mensaje de correo electrónico a: "rfc-editor@isi.edu". 15. Listas de Distribución Los anuncios de RFC son distribuídos a través de dos listas de correo: la lista "IETF-Announce", y la lista "RFC-DIST". No necesita Postel & Reynolds Informativo [Pág. 13] RFC 2223 Instrucciones para Autores de RFC Octubre 1997 estar en ambas listas. Para apuntarse a (o borrarse de) la lista IETF-Announce envíe un mensaje a ietf-request@ietf.org. Para apuntarse a (o borrarse de) la lista RFC-DIST envíe un mensaje a rfc-dist-request@isi.edu. 16. Indice RFC Diversas organizaciones mantienen archivos índice de RFC, normalmente usando el nombre de fichero "rfc-index.txt". El contenido de tal fichero compiado de un sitio puede no ser idéntico a aquél copiado de otro sitio. 17. Consideraciones de Seguridad Este RFC no plantea cuestiones de seguridad (no obstante, vea la Sección 9). 18. Referencias [1] Postel, J., Editor, "Protocolos Estándar Oficiales de Internet", STD 1, RFC 2200, Junio 1997. [2] Bradner, S., "El proceso de Estándares de Internet -- Revision 3", BCP 9, RFC 2026, Octubre 1996. [3] Bradner, S., "Palabras clave para su uso en RFCs para indicar Niveles de Requerimientos", BCP 14, RFC 2119, Marzo 1997. [4] Malkin, G., and J. Reynolds, "'F.Y.I. on F.Y.I' Introdución a las Notas F.Y.I.", FYI 1, RFC 1150, Marzo 1990. [5] Postel, J., Li, T., and Y. Rekhter, "Las Mejores Practicas Actuales", BCP 1, RFC 1818, Agosto 1995. [6] Postel, J., Editor, "Introducción a las Notas STD", RFC 1311, Marzo 1992. Postel & Reynolds Informativo [Pág. 14] RFC 2223 Instrucciones para Autores de RFC Octubre 1997 19. Direcciones de los Autores Jon Postel USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 Teléfono: +1 310-822-1511 Fax: +1 310-823-6714 EMail: Postel@ISI.EDU Joyce K. Reynolds USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 Teléfono: +1 310-822-1511 Fax: +1 310-823-6714 EMail: jkrey@isi.edu Traducción al castellano: Pedro J. Ponce de León C/ Montengón 8 03002 Alicante - Spain EMail: pjleon@arrakis.es Postel & Reynolds Informativo [Pág. 15] RFC 2223 Instrucciones para Autores de RFC Octubre 1997 20. Apéndice - RFC "macros nroff" Normalmente, usamos las características más simples de nroff. Usamos las macros "ms". Por tanto, "nroff -ms fichero-entrada > fichero- salida". Sin embargo, no podemos hacer que nroff haga lo correcto poniendo un salto de página después de la última línea visible de cada página y sin añadir saltos de línea extra antes de la primera línea visible de la página siguiente. Queremos lo siguiente: última línea visible en la página i ^L primera línea visible en la página i+1 Así que nos hemos inventado un truco para solucionarlo. Usamos un guión perl llamado "fix.pl". La orden para procesar el fichero se transforma en: nroff -ms fichero_entrada | fix.pl > fichero-salida El guión perl es el siguiente: #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #! /local/bin/perl # fix.pl 17-Nov-93 Craig Milo Rogers at USC/ISI # # La guía de estilo de los RFCs especifica que las páginas deben estar # delimitadas por la secuencia <última-linea-no-en-blanco> # . # Desafortunadamente, NROFF es reluctante a la hora de producir una salida # conforme a este convenio. Este guión soluciona el problema en los documentos # estilo RFC buscando el símbolo "FORMFEED[Page", sustituyendo "FORMFEED" por # espacios, añadiendo una línea de salto de página y borrando los espacios en # blanco hasta el siguiente carácter que no sea un espacio en blanco. # # Hay una diferencia entre este guión y el de "fix.sh" y el programa pg, a los # cuales sustituye: este guión incluye un salto de línea después del salto de # página al final de la última página de un fichero, donde los programas # anteriores dejaban sólo un salto de página como último carácter del fichero. # Para obtener sólo un salto de página, quite el comentario a la segunda orden # de sustitución más abajo. Para quitar el último salto de página, quite el # comentario de la tercera orden de sustitución. # # Este guión está pensado para actuar como filtro, como en: # # nroff -ms input-file | fix.pl > output-file # # Cuando exporte este guión, por favor observe los siguientes puntos: # Postel & Reynolds Informativo [Pág. 16] RFC 2223 Instrucciones para Autores de RFC Octubre 1997 # 1) ISI mantiene perl en "/local/bin/perl"; su sistema puede tenerlo en # cualquier otra parte. # 2) En sistemas con convenio CRLF como fin-de-línea, los "\n"s presentes # abajo deben ser sustituídos por "\r\n"s. # # N.T.: Para RFCs en castellano, sustitúyase la cadena de caracteres '[Page' # por '[Pág.'. # $* = 1; # Activa patrones multilínea. undef $/; # Lee ficheros completos de un solo # trago. while (<>) { # Lee el fichero de entrada entero. s/FORMFEED(\[Page\s+\d+\])\s+/ \1\n\f\n/g; # Reescribe los finales-de-página. # s/\f\n$/\f/; # ¿Salto-de-página aislado al final? # s/\f\n$//; # ¿Sin salto de página al final? print; # Imprime el fichero resultante. } #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Este guión tambien puede obtenerse de ftp://ftp.isi.edu/in-notes/rfc- editor/fix.pl Ahora, acerca de las características nroff que actualmente usamos, sigue un memorándum de ejemplo, preparado en el estilo RFC. Postel & Reynolds Informativo [Pág. 17] RFC 2223 Instrucciones para Autores de RFC Octubre 1997 .pl 10.0i .po 0 .ll 7.2i .lt 7.2i .nr LL 7.2i .nr LT 7.2i .ds LF Waitzman .ds RF FORMFEED[Pág. %] .ds CF .ds LH RFC 1149 .ds RH 1 Abril 1990 .ds CH Datagramas IP mediante Palomas Mensajeras .hy 0 .ad l .in 0 Network Working Group D. Waitzman Request for Comments: 1149 BBN STC 1 Abril 1990 .ce Un Estándar para la Transmisión de Datagramas IP mediante Palomas Mensajeras .ti 0 Status de este Memorándum .fi .in 3 Este memorándum describe un método experimental para la encapsulación de datagramas IP en palomas mensajeras. Esta especificación es útil principalmente en Redes de Area Metropolitana. Este es un estándar experimental, no recomendado. La distribución de este memorándum es ilimitada. .ti 0 Panorama general y Razonamiento Las palomas mensajeras pueden proporcionar un servicio de alto retardo, bajo rendimiento y baja altitud. La topología de conexión está limitada a rutas únicas punto-a-punto para cada mensajera, usando palomas estándar, pero se pueden utilizar muchas palomas sin que haya interferencia significativa entre ellas, excepto al principio de la primavera. Esto se debe al espacio éter 3D del que disponen las palomas, en contraste con el éter 1D usado por el IEEE802.3. Las palomas tienen un sistema intrínseco para evitar colisiones, el cual aumenta la disponibilidad. Al contrario que algunas tecnologías de red, Postel & Reynolds Informativo [Pág. 18] RFC 2223 Instrucciones para Autores de RFC Octubre 1997 como los radio-paquetes, la comunicación no está limitada a la distancia visible. En algunas ciudades hay disponible un servicio orientado a la conexión, normalmente basado en una topología de distribuidor central. .ti 0 Formato de Trama El datagrama IP es impreso, en un pequeño rollo de papel, en hexadecimal, cada octeto separado por un espacio en blanco. El rollo de papel es enrollado alrededor de una de las patas de la paloma mensajera. Para asegurar los extremos del datagrama se utiliza una cinta elástica. El ancho de banda está limitado a la longitud de la pata. El MTU es variable y, paradójicamente, aumenta generalmente con la edad de la paloma. Un MTU típico son 256 miligramos. Puede ser necesario algo de relleno del datagrama. En la recepción, se quita la cinta elástica y la copia en papel del datagrama es examinada ópticamente de forma electrónicamente transmitible. .ti 0 Discusión Se pueden proporcionar múltiples tipos de servicio con un orden de picoteo con prioridad. Una propiedad adicional incorporada es la detección y erradicación de gusanos. Dado que IP sólo garantiza la entrega mediante el mayor esfuerzo posible, la pérdida de una paloma es tolerable. Con el tiempo, las palomas se auto-regeneran. Como no se especifica la multi-difusión, las tormentas pueden causar pérdida de datos. Existe el reintento de entrega persistente, hasta que la paloma cae. Se generan automáticamente rastros para auditoría, y estos pueden encontrarse a menudo en troncos y postes de cables. .ti 0 Consideraciones de Seguridad .in 3 La seguridad no es un problema en el modo de operación normal, pero se deben tomar medidas especiales (tales como cifrado de datos) cuando las palomas mensajeras sean usadas en un entorno táctico. .ti 0 Dirección del Autor .nf David Waitzman BBN Systems and Technologies Corporation Postel & Reynolds Informativo [Pág. 19] RFC 2223 Instrucciones para Autores de RFC Octubre 1997 BBN Labs Division 10 Moulton Street Cambridge, MA 02238 Teléfono: (617) 873-4323 EMail: dwaitzman@BBN.COM Postel & Reynolds Informativo [Pág. 20] RFC 2223 Instrucciones para Autores de RFC Octubre 1997 21. Declaración Completa de Copyright Copyright (C) The Internet Society (1997). Todos los derechos reservados. Este documento y sus traducciones puede ser copiado y facilitado a otros, y los trabajos derivados que lo comentan o lo explican o ayudan a su implementación pueden ser preparados, copiados, publicados y distribuídos, enteros o en parte, sin restricción de ningún tipo, siempre que se incluyan este párrafo y la nota de copyright expuesta arriba en todas esas copias y trabajos derivados. Sin embargo, este documento en sí no debe ser modificado de ninguna forma, tal como eliminando la nota de copyright o referencias a la 'Internet Society' u otras organizaciones de Internet, excepto cuando sea necesario en el desarrollo de estándares Internet, en cuyo caso se seguirán los procedimientos para copyrights definidos en el proceso de Estándares Internet, o con motivo de su traducción a otras lenguas aparte del Inglés. Los permisos limitados concedidos más arriba son perpétuos y no serán revocados por la 'Internet Society' o sus sucesores o cesionarios. Este documento y la información contenida en él se proporcionan en su forma "TAL CUAL" y LA INTERNET SOCIETY Y LA INTERNET ENGINEERING TASK FORCE RECHAZAN CUALESQUIERA GARANTIAS, EXPRESAS O IMPLICITAS, INCLUYENDO, PERO NO LIMITADAS A, CUALQUIER GARANTIA DE QUE EL USO DE LA INFORMACION AQUI EXPUESTA NO INFRINGIRA NINGUN DERECHO O GARANTIAS IMPLICITAS DE COMERCIALIZACION O IDONEIDAD PARA UN PROPOSITO ESPECIFICO. Postel & Reynolds Informativo [Pág. 21]