Network Working Group K. Moore Request for Comments: 2047 University of Tennessee Obsoletes: 1521, 1522, 1590 November 1996 Category: Standards Track Extensiones Multipropósito al Correo de Internet (MIME) Tercera Parte: Extensiones en la Cabecera de Mensajes para Texto No US-ASCII Estado de este memorándum: Este documento especifica un protocolo de seguimiento de estándar de Internet 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 estatus de este protocolo. La distribución de este memorándum es ilimitada. Resumen STD 11, RFC 822, define un protocolo de representación de mensaje especificando con considerable detalle las cabeceras de mensaje en US-ASCII, y deja el contenido del mensaje, o cuerpo del mensaje, como texto plano US-ASCII. Este conjunto de documentos, denominados en su conjunto Extensiones Multipropósito en Correo Internet, o MIME, redefine el formato de los mensajes para permitir (1) cuerpos de los mensajes de texto en otros conjuntos de caracteres diferentes al US-ASCII, (2) un conjunto ampliable de diferentes formatos para cuerpos de mensajes no de texto, (3) cuerpos de mensajes multi-parte, y (4) información de texto en la cabecera en conjuntos de caracteres diferentes al US-ASCII. Estos documentos están basados en los trabajos previos documentados en RFC 934, STD 11, y RFC 1049, pero los amplía y revisa. Dado que RFC 822 especificaba poco acerca del cuerpo de los mensajes, estos documentos son más un punto de vista distinto que una revisión de RFC 822. Este documento en concreto es el tercero de la serie. Describe K. Moore Seguimiento de Estándar [Pág. 1] RFC 2047 MIME: Tercera Parte Noviembre 1996 extensiones a RFC 822 para permitir datos de texto no ASCII en los campos de cabecera de correo Internet. Los otros documentos en esta serie incluyen: + RFC 2045, especifica las distintas cabeceras utilizadas para describir la estructura de los mensajes MIME, + RFC 2046, especifica la estructura general del sistema MIME de tipificación de contenido y define un conjunto inicial de tipos de contenido, + RFC 2048, especifica diferentes procedimientos IANA para el registro de características relacionadas con MIME, y + RFC 2049, describe los criterios de conformidad con MIME y proporciona algunos ejemplos ilustrativos de formatos de mensajes MIME, reconocimientos y la bibliografía. Estos documentos son revisiones de los RFCs 1521, 1522, y 1590, que a su vez eran revisiones de los RFCs 1341 y 1342. Un apéndice en el RFC 2049 describe las diferencias y cambios respecto a las versiones anteriores. 1. Introducción RFC 2045 describe el mecanismo para indicar partes de cuerpo de texto que están codificadas en diferentes conjuntos de caracteres, así como métodos para codificar dichas partes como secuencias de caracteres imprimibles US-ASCII. Este memorándum describe técnicas similares para permitir la codificación de texto no US-ASCII en diferentes partes de una cabecera de mensaje RFC 822 [2], de una manera que sea improbable que confunda al software existente de manejo de mensajes. Al igual que la técnicas de codificación descritas en RFC 2045, las técnicas esbozadas aquí han sido diseñadas para permitir el uso de caracteres no US-ASCII en cabeceras de mensajes de una forma que es improbable que sea alterada por las peculiaridades de programas existentes de manejo de mensajes Internet. En particular, se sabe que algunos programas de reenvío (a) borran algunos campos de cabecera mientras que conservan otros, (b) modifican el orden de las direcciones en los campos To o Cc, (c) modifican el orden (vertical) de los campos de cabecera, y/o (d) colocan las cabeceras de mensajes en sitios distintos de los del mensaje original. Además, algunos programas de lectura de correo tienen dificultades conocidas para analizar cabeceras de mensajes, que aunque legales de acuerdo a RFC 822, hacen uso del etiquetado con barra invertida (\) para "esconder" caracteres especiales como "<", ",", o ":", o que sacan provecho de K. Moore Seguimiento de Estándar [Pág. 2] RFC 2047 MIME: Tercera Parte Noviembre 1996 otras características poco utilizadas de esa especificación. Pese a lo desafortunado que es que dichos programas no interpreten correctamente la cabeceras RFC 822, el "romper" estos programas provocaría problemas de operación muy graves en el sistema de correo Internet. Por lo tanto, las extensiones descritas en este memorándum no se basan en características poco utilizadas de RFC 822. En cambio, ciertas secuencias "usuales" de caracteres imprimibles US- ASCII (conocidas como 'encoded-words', palabras codificadas) se reservan para usarlas como datos codificados. La sintaxis de las palabras codificadas es tal que es improbable que aparezcan "accidentalmente" como texto normal en las cabeceras de mensajes. Aún más, los caracteres utilizados en palabras codificadas se limitan a aquellos que no tienen un significado especial en el contexto en el que aparecen las palabras codificadas. Normalmente, una "palabra-codificada" es una secuencia de caracteres imprimibles US-ASCII que empieza con "=?", termina con "?=" y tiene dos "?" entre medias. Especifica un conjunto de caracteres y un método de codificación, y también incluye el texto original codificado como caracteres ASCII gráficos, de acuerdo a las reglas del método de codificación. Un compositor de mensajes que implemente esta especificación proporcionará la manera de introducir texto no ASCII en los campos de cabecera, pero traducirá estos campos (o la parte apropiada de estos campos) en palabras codificadas antes de insertarlos en la cabecera del mensaje. Un lector de mensajes que implemente esta especificación reconocerá palabras codificadas cuando aparezcan en determinadas partes de la cabecera del mensaje. En vez de mostrar la palabra codificada "tal cual", deshará la codificación y mostrará el texto original en el conjunto de caracteres designado. NOTAS Este memorándum se basa fundamentalmente en la notación y los términos definidos en RFC 822 y RFC 2045. En particular, la sintaxis de la ABNF utilizada en este memorándum está definida en RFC 822, así como los símbolos terminales y no terminales de RFC 822 se utilizan en la gramática para las extensiones de la cabecera definidas aquí. Entre los símbolos definidos en RFC 822 y referenciados en este memorándum están: 'addr-spec', 'atom', 'CHAR', 'comment', 'CTLs', 'ctext', 'linear-white-space', 'phrase', 'quoted-pair', 'quoted- string', 'SPACE', y 'word'. Es necesaria una cuidadosa atención a las definiciones de RFC 822 de estos términos para una implementación K. Moore Seguimiento de Estándar [Pág. 3] RFC 2047 MIME: Tercera Parte Noviembre 1996 adecuada de esta extensión de protocolo. Cuando el término "ASCII" aparece en este memorándum, se refiere al American Standard Code for Information Interchange (Código Americano Estándar para Intercambio de Información) de 7bit, ANSI X3.4-1986. El nombre MIME de conjunto de caracteres para este conjunto de caracteres es "US-ASCII". Cuando no se refiera específicamente al nombre de conjunto de caracteres de MIME, este documento utiliza el término "ASCII", tanto por brevedad como por consistencia con RFC 822. Sin embargo se advierte a los implementadores que el nombre de conjunto de caracteres se debe deletrear "US-ASCII" en cabeceras de mensaje y de partes de cuerpo MIME. Este memorándum especifica un protocolo para la representación de texto no ASCII en cabeceras de mensajes. Específicamente, NO DEFINE ninguna traducción entre "cabeceras de 8bit" y cabeceras ASCII puras, ni asume que dicha traducción sea posible. 2. Sintaxis de palabras codificadas Una "palabra codificada" se define por la siguiente gramática ABNF. Se utiliza la notación RFC 822, con la excepción de que NO DEBEN aparecer caracteres de espacio en blanco entre componentes de una "palabra codificada". encoded-word= "=?" charset "?" encoding "?" encoded-text "?=" charset = token ; Ver sección 3 encoding = token ; Ver sección 4 token = 1* especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " <"> / "/" / "[" / "]" / "?" / "." / "=" encoded-text = 1* ; (pero ver "Uso de palabras codificadas en cabeceras ; de mensaje", sección 5) Ambos nombres 'encoding' y 'charset' son insensibles a mayúsculas. Por lo tanto, el nombre de conjunto de caracteres "ISO-8859-1" es equivalente a "iso-8859-1", y el nombre codificado "Q" se puede deletrear "Q" o "q". Una palabra codificada no puede tener más de 75 caracteres de longitud, incluyendo 'charset', 'encoding', 'encoded-text' y K. Moore Seguimiento de Estándar [Pág. 4] RFC 2047 MIME: Tercera Parte Noviembre 1996 delimitadores. Si se desea codificar más texto del que cabe en una "palabra codificada" de 75 caracteres, se pueden utilizar múltiples "palabras codificadas" (separadas por CRLF SPACE). Aunque no hay límite en la longitud de un campo de cabecera multilínea, cada línea de un campo de cabecera multilínea que contenga una o más palabras codificadas está limitada a 76 caracteres. Las restricciones de longitud se incluyen tanto por facilitar la interoperabilidad entre pasarelas de correo entre redes, como por imponer un límite en la cantidad de prelectura que debe emplear un analizador de cabecera (mientras busca el delimitador final ?=) antes de decidir si un elemento es una "palabra codificada" u otra cosa. IMPORTANTE: las "palabras codificadas" están diseñadas para ser reconocidas como "átomos" por un analizador RFC 822. Por consiguiente, los caracteres de espacio sin codificar (como SPACE y HTAB) están PROHIBIDOS dentro de una "palabra codificada". Por ejemplo, la secuencia de caracteres =?iso-8859-1?q?esto es algo textual?= será analizada como cuatro "átomos", en vez de un único "átomo" (por un analizador RFC 822) o "palabra codificada" (por un analizador que entienda "'palabras codificadas"). La forma correcta de codificar la cadena "esto es algo textual" es codificar también los caracteres SPACE, p. ej. =?iso-8859-1?q?esto=20es=20algo=20textual?= Los caracteres que pueden aparecer en 'encoded-text' tienen más restricciones por las reglas de la sección 5. 3. Conjuntos de caracteres La parte 'charset' de una 'encoded-word' especifica el conjunto de caracteres asociado al texto sin codificar. Un 'charset' puede ser cualquiera de los nombres de conjuntos de caracteres permitidos en el parámetro 'charset' de MIME de una parte de cuerpo 'text/plain', o cualquier conjunto de caracteres registrado con IANA para el uso con el tipo de contenido MIME 'text-plain'. Algunos conjuntos de caracteres utilizan técnicas de cambio de código (code-switching) para alternar entre modo "ASCII" y otros modos. Si el texto no codificado de una 'encoded-word' contiene una secuencia que produce que el intérprete de caracteres salga del modo ASCII, DEBE contener códigos de control adicionales de tal forma que el modo K. Moore Seguimiento de Estándar [Pág. 5] RFC 2047 MIME: Tercera Parte Noviembre 1996 ASCII sea el seleccionado al finalizar la 'encoded-word'. (Esto regla se aplica a cada 'encoded-word' por separado, incluso a 'encoded- word's contiguas dentro de un único campo de cabecera). Cuando exista la posibilidad de usar más de un conjunto de caracteres para representar el texto de una 'encoded-word', y en ausencia de acuerdos privados entre el remitente y los receptores del mensaje, se recomienda que se utilicen preferentemente los miembros de la serie ISO-8859-* en vez de otros conjuntos de caracteres. 4. Codificaciones (encodings) Inicialmente, los valores permitidos para 'encoding' son "Q" y "B". Estas codificaciones se describen más adelante. La codificación "Q" se recomienda utilizar cuando la mayoría de los caracteres a codificar están en el conjunto de caracteres "US-ASCII"; en otro caso, se debería usar "B". No obstante, un lector de correo que presuma reconocer 'encoded-word's DEBE ser capaz de aceptar cualquiera de las dos codificaciones para cualquier conjunto de caracteres que soporte. Sólo se puede usar un subconjunto de los caracteres imprimibles US- ASCII en 'encoded-text'. Los caracteres de espacio y de tabulador no están permitidos, por lo que el inicio y el fin de una 'encoded-word' son obvios. El carácter "?" se utiliza dentro de una 'encoded-word' para separar unas de otras las distintas partes de la 'encoded-word', y por lo tanto no pueden aparecer en la parte de 'encoded-text'. Otros caracteres también son ilegales en determinados contextos. Por ejemplo, una 'encoded-word' en una 'phrase' que preceda una dirección en un campo de cabecera From no puede contener ninguno de los 'specials' definidos en RFC 822. Finalmente, otros caracteres no están permitidos en algunos contextos, para asegurar la fiabilidad en mensajes que pasen a través de pasarelas de correo entre redes. La codificación "B" automáticamente alcanza estos requerimientos. La codificación "Q" permite utilizar un amplio rango de caracteres imprimibles en partes no críticas de la cabecera del mensaje (p. ej., Subject), aunque tiene menos caracteres disponibles para otras partes. 4.1. La codificación "B" La codificación "B" es idéntica a la codificación "BASE64" definida en RFC 2045. 4.2. La codificación "Q" La codificación "Q" es similar a la codificación 'Quoted-Printable' K. Moore Seguimiento de Estándar [Pág. 6] RFC 2047 MIME: Tercera Parte Noviembre 1996 de 'Content-Transfer-Encoding' definida en RFC 2045. Está diseñada para permitir que texto que contenga en su mayor parte caracteres US- ASCII, sea descifrable en un terminal ASCII sin tener que decodificarlo. (1) Cualquier valor de 8bit se puede representar por un "=" seguido de dos dígitos hexadecimales. Por ejemplo, si el conjunto de caracteres en uso fuera ISO-8859-1, el carácter "=" se codificaría como "=3D", y el SPACE como "=20". (Se debería usar mayúsculas para los dígitos hexadecimales de "A" a "F"). (2) El valor hexadecimal de 8bit 20 (es decir, SPACE en ISO-8859-1) puede ser representado como "_" (subrayado, ASCII 95). (Este carácter puede no pasar a través de algunas pasarelas de correo entre redes, pero su uso ampliará en gran medida la legibilidad de datos "Q" codificados en lectores de correo que no soporten esta codificación). Nótese que "_" siempre representa el valor hexadecimal 20, incluso si el carácter SPACE ocupa un lugar diferente en el conjunto de caracteres utilizado. (3) Otros valores de 8bit que correspondan a caracteres imprimibles ASCII aparte de "=", "?", y "_" (subrayado), PUEDEN ser representados por sí mismos. (Pero vea las restricciones de la sección 5). En particular, SPACE y TAB NO DEBEN ser representados por ellos mismos dentro de 'encoded-word's. 5. Uso de 'encoded-words' en cabeceras de mensaje Una 'encoded-word' puede aparecer en la cabecera de mensaje o en la cabecera de una parte de cuerpo de acuerdo a las siguientes reglas: (1) Una 'encoded-word' puede sustituir a un elemento 'text' (como se define en RFC 822) en cualquier campo de cabecera Subject o Comments, cualquier campo de cabecera de extensión, o cualquier campo de parte de cuerpo MIME para el cual el contenido del campo se defina como '*text'. Una 'encoded-word' puede aparecer también en cualquier campo de cabecera de mensaje o de parte de cuerpo definidos por el usuario ("X-"). Pueden aparecer juntos texto ASCII normal y 'encoded-word's en el mismo campo de cabecera. Sin embargo, una 'encoded-word' que aparezca en un campo de cabecera definido como '*text' DEBE estar separado de cualquier 'encoded-word' o 'text' adyacentes por un "espacio en blanco" ('linear-white-space'). (2) Una 'encoded-word' puede aparecer dentro de un 'comment' delimitada por "(" y ")", es decir, donde se permita un 'ctext'. Más exactamente, la definición ABNF de RFC 822 para 'comment' se corrige K. Moore Seguimiento de Estándar [Pág. 7] RFC 2047 MIME: Tercera Parte Noviembre 1996 como sigue: comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")" Una 'encoded-word' "Q" codificada que aparezca en un 'comment' NO DEBE contener los caracteres "(", ")" o "\". Además, una 'encoded- word' que aparezca en un 'comment' DEBE estar separada de cualquier 'encoded-word' o 'ctext' adyacente por un "espacio en blanco". Es importante notar que los 'comment' sólo se reconocen dentro de campos "estructurados". En campos cuyos contenidos estén definidos como '*text', "(" y ")" se tratan como caracteres normales en vez de delimitadores de comentarios, y se aplica la regla (1) de esta sección. ( Ver RFC 822, secciones 3.1.2 y 3.1.3). (3) Sustituyendo a una entidad 'word' dentro de una 'phrase', por ejemplo, una que preceda a una dirección en una cabecera From, To o Cc. Así, la definición ABNF para 'phrase' de RFC 822 viene a ser: phrase = 1*( encoded-word / word ) En este caso el conjunto de caracteres que puede ser utilizado en una 'encoded-word' "Q" codificada se limita a: . Una 'encoded-word' que aparezca dentro de una 'phrase' DEBE estar separada de cualquier 'word', 'text' o 'special' adyacentes por 'espacio en blanco'. Estos son los UNICOS sitios donde puede aparecer una 'encoded-word'. En particular: + Una 'encoded-word' NO DEBE aparecer en ninguna parte de una 'addr- spec'. + Una 'encoded-word' NO DEBE aparecer dentro de una cadena 'quoted- string'. + Una 'encoded-word' NO DEBE ser usada en un campo de cabecera Received. + Una 'encoded-word' NO DEBE ser usada en parámetros de un campo Content-Type o Content-Disposition de MIME, o en cualquier cuerpo de campo estructurado salvo dentro de un 'comment' o 'phrase'. El 'encoded-text' de una 'encoded-word' debe ser autocontenido; el 'encoded-text' NO DEBE continuar de una 'encoded-word' a otra. Esto implica que la parte 'encoded-text' de una "B" 'encoded-word' debe tener una longitud de caracteres múltiplo de 4; para una "Q" K. Moore Seguimiento de Estándar [Pág. 8] RFC 2047 MIME: Tercera Parte Noviembre 1996 'encoded-word', cualquier carácter "=" que aparezca en la parte de 'encoded-text' aparecerá seguida de dos caracteres hexadecimales. Cada 'encoded-word' DEBE codificar un número entero de octetos. El 'encoded-text' de cada 'encoded-word' debe estar formado correctamente de acuerdo a la codificación especificada; el 'encoded- text' no debe continuar en la siguiente 'encoded-word'. (Por ejemplo, "=?charset?Q?=?= =?charset?Q?AB?=" es ilegal, porque los dos dígitos hexadecimales "AB" deben ir a continuación de "=" en la misma 'encoded-word'). Cada 'encoded-word' DEBE representar un número entero de caracteres. Un carácter multiocteto no debe estar separado en 'encoded-word's adyacentes. Sólo deberían codificarse datos imprimibles y espacios de carácter blanco utilizando este esquema. De todas formas y dado que estos esquemas de codificación permiten la codificación de valores de octeto arbitrarios, los lectores de correo que implementen esta decodificación deberían también asegurar que la presentación de los datos decodificados en el terminal del receptor no producirá efectos colaterales indeseados. No se define en este memorándum el uso de estos métodos para codificar datos no de texto (p. ej., imágenes o sonidos). El uso de 'encoded-word's para representar cadenas de caracteres ASCII puras está permitido, pero no se recomienda. En casos aislados puede ser necesario codificar texto normal que parezca una 'encoded-word'. 6. Soporte de 'encoded-words' por los lectores de correo 6.1. Reconocimiento de 'encoded-word's en cabeceras de mensaje Un lector de correo debe analizar las cabeceras de mensaje y de parte de cuerpo de acuerdo a las reglas de RFC 822 para reconocer correctamente 'encoded-word's. Las 'encoded-word's se reconocerán como sigue: (1) Cualquier campo de cabecera de mensaje o de parte de cuerpo definido como '*text', o cualquier campo de cabecera definido por el usuario, debería ser analizado como sigue: Empezando al principio del cuerpo del campo y a continuación de cada ocurrencia de un espacio en blanco ('linear-white-space'), cada secuencia de hasta 75 caracteres imprimibles (que no contengan espacios en blanco) debería ser examinada para ver si es una 'encoded-word' de acuerdo a las reglas de sintaxis de la sección 2. Cualquier otra secuencia de caracteres imprimibles deberá ser K. Moore Seguimiento de Estándar [Pág. 9] RFC 2047 MIME: Tercera Parte Noviembre 1996 tratada como texto ASCII normal. (2) Cualquier campo de cabecera no definido como '*text' debería ser analizado de acuerdo a las reglas de sintaxis de ese campo de cabecera. De todas formas, cualquier 'word' que aparezca en una 'phrase' deberá ser tratada como una 'encoded-word' si sigue las reglas de sintaxis de la sección 2. En cualquier otro caso deberá ser tratada como una 'word' normal. (3) En un 'comment', cualquier secuencia de hasta 75 caracteres imprimibles (que no contengan espacios en blanco), que sigan las reglas de sintaxis de la sección 2, deberán ser tratadas como una 'encoded-word'. En cualquier otro caso deberá ser tratada como texto de comentario normal. (4) NO es obligatorio que esté presente un campo de cabecera 'MIME- Version' para que las 'encoded-word's se interpreten de acuerdo a esta especificación. Una razón para esto es que no se espera de un lector de correo que analice la cabecera completa del mensaje antes de mostrar líneas que puedan contener 'encoded-word's. 6.2. Visualización de 'encoded-word's Cualquier 'encoded-word' así reconocida se decodifica, y si es posible, el texto decodificado resultante es mostrado en el conjunto de caracteres original. NOTA: La decodificación y la visualización de 'encoded-word's ocurre *después* de que el cuerpo de un campo estructurado haya sido analizado por elementos. Es por lo tanto posible esconder caracteres "especiales" en 'encoded-word's, los cuales serán indistinguibles de caracteres "especiales" del texto que les rodea cuando sean visualizados. Por este y otros motivos, generalmente NO es posible traducir un cabecera de mensaje que contenga 'encoded-word's a una forma decodificada que pueda ser analizada por un lector de correo RFC 822. Cuando se muestra un campo de cabecera concreto que contenga múltiples 'encoded-word's, se ignora cualquier espacio en blanco que separe dos 'encoded-word's consecutivas. (Esto es para permitir el uso de múltiples 'encoded-word's para representar cadenas largas de texto sin codificar, sin tener que separar 'encoded-word's por el lugar donde aparecen espacios en blanco en el texto sin codificar). En el caso de que se definan otras codificaciones en el futuro, y que el lector de correo no soporte la codificación utilizada, puede o bien (a) mostrar la 'encoded-word' como texto normal, o bien (b) mostrar un mensaje apropiado indicando que el texto no ha podido ser K. Moore Seguimiento de Estándar [Pág. 10] RFC 2047 MIME: Tercera Parte Noviembre 1996 decodificado. Si el lector de correo no soporta el conjunto de caracteres utilizado, puede (a) mostrar la 'encoded-word' como texto normal (es decir, como aparece en la cabecera), (b) hacer el "mejor esfuerzo" para mostrarlo utilizando los caracteres disponibles, o (c) mostrar un mensaje apropiado indicando que el texto no ha podido ser visualizado. Si el conjunto de caracteres utilizado emplea técnicas de intercambio de códigos (code-switching) la visualización del texto codificado comienza implícitamente en "modo ASCII". Además, el lector de correo debe asegurarse de que el dispositivo de salida está otra vez en "modo ASCII" después de que la 'encoded-word' haya sido visualizada. 6.3. Manejo por parte del lector de correo de 'encoded-word's mal formadas Es posible que una 'encoded-word' que sea legal de acuerdo a la sintaxis definida en la sección 2, esté incorrectamente formada con respecto a las reglas de la codificación que se esté utilizando. Por ejemplo: (1) Una 'encoded-word' que contenga caracteres que no sean legales en una codificación en concreto (por ejemplo, un "-" en la codificación "B", o un SPACE o HTAB tanto en la codificación "B" como en la "Q"), está mal formada. (2) Cualquier 'encoded-word' que codifique un número no entero de caracteres o de octetos está mal formada. No es necesario que un lector de correo intente mostrar el texto asociado con una 'encoded-word' que esté mal formada. De todas formas, un lector de correo NO DEBE evitar la visualización o el manejo de un mensaje porque tenga una 'encoded-word' mal formada. 7. Conformidad Un programa de composición de mensajes que pretenda estar en conformidad con esta especificación DEBE asegurar que cualquier cadena de caracteres US-ASCII imprimibles (salvo espacios en blanco) dentro de un '*text' o '*ctext' que empiece con "=?" y termine con "?=" sea una 'encoded-word' válida. ( "empiece" significa: al principio del cuerpo del campo, inmediatamente a continuación de un "espacio en blanco", o inmediatamente a continuación de "(" para una 'encoded-word' dentro de un '*ctext'; "termine" significa: al final del cuerpo del campo, inmediatamente precediendo un "espacio en blanco", o inmediatamente precediendo a ")" para una 'encoded-word' K. Moore Seguimiento de Estándar [Pág. 11] RFC 2047 MIME: Tercera Parte Noviembre 1996 dentro de un '*ctext'). Además, cualquier 'word' dentro de una 'phrase' que empiece con "=?" y termine con "?=" debe ser una 'encoded-word' válida. Un programa lector de mensajes que pretenda estar en conformidad con esta especificación debe poder distinguir 'encoded-word's de 'text', 'ctext' o 'word's, de acuerdo a las reglas de la sección 6, siempre que aparezcan en los lugares apropiados de las cabeceras de mensajes. Debe soportar tanto la codificación "B" como la "Q" para cualquier conjunto de caracteres que soporte. El programa debe poder mostrar el texto sin codificar si el conjunto de caracteres es "US-ASCII". Para los conjuntos de caracteres ISO-8859-*, el programa lector debe, como mínimo, poder mostrar los caracteres que también estén en el conjunto ASCII. 8. Ejemplos Lo siguiente son ejemplos de cabeceras de mensajes que contienen 'encoded-word's: From: =?US-ASCII?Q?Keith_Moore?= To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= CC: =?ISO-8859-1?Q?Andr=E9?= Pirard Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?= =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?= Nota: En la primera 'encoded-word' del campo Subject anterior, es necesario el último "=" al final del 'encoded-text' porque cada 'encoded-word' debe ser autocontenida (el carácter "=" completa un grupo de 4 caracteres base64 que representan 2 octetos). Podría haberse codificado un octeto adicional en la primera 'encoded-word' (de tal forma que la 'encoded-word' contuviera un múltiplo exacto de 3 octetos codificados), excepto si la segunda 'encoded-word' utilizase un 'charset' diferente de la primera. From: =?ISO-8859-1?Q?Olle_J=E4rnefors?= To: ietf-822@dimacs.rutgers.edu, ojarnef@admin.kth.se Subject: Time for ISO 10646? To: Dave Crocker Cc: ietf-822@dimacs.rutgers.edu, paf@comsol.se From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: RFC-HDR care and feeding From: Nathaniel Borenstein (=?iso-8859-8?b?7eXs+SDv4SDp7Oj08A==?=) To: Greg Vaudreuil , Ned Freed , Keith Moore K. Moore Seguimiento de Estándar [Pág. 12] RFC 2047 MIME: Tercera Parte Noviembre 1996 Subject: Test of new header generator MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Los siguientes ejemplos ilustran texto que contiene 'encoded-word's si aparece en el cuerpo de un campo estructurado. Las reglas son ligeramente diferentes para los campos definidos como '*text' porque "(" y ")" no son reconocidos como delimitadores de comentario ('comment'). [Sección 5, párrafo (1)]. En cada uno de los ejemplos siguientes, si la misma secuencia ocurriera en un campo '*text', la forma "se muestra como" NO será tratada como 'encoded-word's, sino idéntica a la "forma codificada". Esto es debido a que cada 'encoded-word' de los siguientes ejemplos es adyacente a un carácter "(" o ")". forma codificada se muestra como --------------------------------------------------------------------- (=?ISO-8859-1?Q?a?=) (a) (=?ISO-8859-1?Q?a?= b) (a b) Dentro de un 'comment', DEBE aparecer un espacio en blanco entre la 'encoded-word' y el texto que le rodea. [Sección 5, párrafo (2)]. De todas formas, el espacio en blanco no es necesario entre el primer "(" que empieza el 'comment' y la 'encoded-word'. (=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=) (ab) No se muestran los espacios en blanco entre 'encoded-word's adyacentes. (=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=) (ab) Se ignoran incluso múltiples SPACE entre 'encoded-word's en la visualización. (=?ISO-8859-1?Q?a?= (ab) =?ISO-8859-1?Q?b?=) Se ignora cualquier cantidad de espacios en blanco entre 'encoded-word's, incluso aunque incluyan un CRLF seguido de uno o más SPACE, en la visualización. (=?ISO-8859-1?Q?a_b?=) (a b) K. Moore Seguimiento de Estándar [Pág. 13] RFC 2047 MIME: Tercera Parte Noviembre 1996 Para hacer que se muestre un SPACE en el texto codificado, el SPACE DEBE se codificado como parte de la 'encoded-word'. (=?ISO-8859-1?Q?a?= =?ISO-8859-2?Q?_b?=) (a b) Para hacer que se muestre un SPACE entre dos cadenas de texto codificado, el SPACE PUEDE ser codificado como parte de una de las 'encoded-word's. 9. Referencias [RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982. [RFC 2049] Borenstein, N., y N. Freed, "Extensiones Multipropósito al Correo de Internet MIME) Quinta Parte: Criterios de Conformidad y Ejemplos", RFC 2049, Noviembre 1996. [RFC 2045] Borenstein, N., y N. Freed, "Extensiones Multipropósito al Correo de Internet (MIME) Primera Parte: Formato del Cuerpo de los Mensajes Internet", RFC 2045, Noviembre 1996. [RFC 2046] Borenstein N., y N. Freed, "Extensiones Multipropósito al Correo de Internet MIME) Segunda Parte: Tipos de Contenido", RFC 2046, Noviembre 1996. [RFC 2048] Freed, N., Klensin, J., y J. Postel, "Extensiones Multipropósito al Correo de Internet MIME) Cuarta Parte: Procedimientos de Registro", RFC 2048, Noviembre 1996. 10. Consideraciones de Seguridad No se discuten cuestiones de Seguridad en este memorándum. 11. Agradecimientos El autor desea agradecer a Nathaniel Borenstein, Issac Chan, Lutz Donnerhacke, Paul Eggert, Ned Freed, Andreas M. Kirchwitz, Olle Jarnefors, Mike Rosin, Yutaka Sato, Bart Schaefer, y Kazuhiko Yamamoto, sus útiles consejos, comentarios intuitivos, y preguntas esclarecedoras en respuesta a las versiones previas de esta especificación. 12. Dirección del Autor Keith Moore University of Tennessee 107 Ayres Hall K. Moore Seguimiento de Estándar [Pág. 14] RFC 2047 MIME: Tercera Parte Noviembre 1996 Knoxville TN 37996-1301 EMail: moore@cs.utk.edu Traducción: José Manuel Cainzos Sevilla - España EMail: jmcainzos@airtel.net K. Moore Seguimiento de Estándar [Pág. 15]