Network Working Group N. Freed Request for Comments: 2045 Innosoft Obsoletes: 1521, 1522, 1590 N.Borenstein Category: Standards Track First Virtual November 1996 Extensiones Multipropósito al Correo de Internet (MIME) Primera Parte: Formato del Cuerpo de los Mensajes Internet Estado de este memorándum: 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 estado 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 inicial especifica las distintas cabeceras utilizadas N.Freed Seguimiento de Estándar [Pág. 1] RFC 2045 MIME: Primera Parte Noviembre 1996 para describir la estructura de los mensajes MIME. El segundo documento, RFC 2046, define la estructura general del sistema de identificación de contenido MIME y define un conjunto inicial de tipos de contenido. El tercer documento, RFC 2047, describe extensiones a RFC 822 para permitir información de texto en los campos de la cabecera de correo Internet en otro conjunto de caracteres distinto al US-ASCII. El cuarto documento, RFC 2048, especifica varios procedimientos para registrar en IANA programas o módulos para MIME. El quinto y último documento, RFC 2049, describe los criterios de evaluación de cumplimiento de MIME así como provee de ejemplos ilustrativos de formatos de mensaje MIME, agradecimientos, 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. Indice de contenidos 1. Introducción ............................................... 3 2. Definiciones, Convenciones y Gramática Genérica BNF ........ 5 2.1 CRLF ...................................................... 6 2.2 Conjunto de caracteres .................................... 6 2.3 Mensaje ................................................... 7 2.4 Entidad ................................................... 7 2.5 Parte del cuerpo .......................................... 7 2.6 Cuerpo .................................................... 7 2.7 Datos de 7 bits ........................................... 7 2.8 Datos de 8 bits ........................................... 8 2.9 Datos binarios ............................................ 8 2.10 Líneas ................................................... 8 3. Campos de cabecera MIME .................................... 8 4. Campo de cabecera MIME-version (Versión MIME) .............. 9 5. Campo de cabecera Content-Type (Tipo de Contenido) ......... 11 5.1 Sintaxis del campo Content-Type ........................... 12 5.2 Valores por defecto del campo Content-Type ................ 14 6. Campo Content-Transfer-Encoding (Codificación para la Transferencia de Contenido) ............. 15 6.1 Sintaxis del campo Content-Transfer-Encoding .............. 15 6.2 Semántica ................................................. 16 6.3 Nuevos Content-Transfer-Encoding .......................... 16 6.4 Interpretación y uso ...................................... 17 6.5 Traduciendo codificaciones ................................ 19 6.6 Modelo canónico de codificación ........................... 19 6.7 Content-Transfer-Encoding "Quoted-Printable" .............. 20 6.8 Content-Transfer-Encoding "Base64" ........................ 24 N.Freed Seguimiento de Estándar [Pág. 2] RFC 2045 MIME: Primera Parte Noviembre 1996 7. Campo de cabecera Content-ID (Identificador de Contenido) .. 27 8. Campo de cabecera Content-Description (Descripción de Contenido) 28 9. Campos adicionales de la cabecera MIME ..................... 28 10. Sumario ................................................... 28 11. Consideraciones de seguridad .............................. 28 12. Direcciones de los autores ................................ 29 A. Compendio de Gramática ..................................... 30 1. Introducción Desde su publicación en 1982, RFC 822 ha definido el formato estándar de los mensajes de correo de texto en Internet. Su éxito ha sido tal que el formato RFC 822 ha sido adoptado, completamente o en parte, más allá de los límites de Internet y del transporte SMTP en Internet definido por RFC 821. Al verse tan ampliado su uso, el formato se ha ido tornando cada vez más restrictivo para la comunidad de usuarios. RFC 822 pretendía especificar un formato para mensajes de texto. Como tal, mensajes no de texto, como los mensajes multimedia que pueden incluir sonido o imágenes, simplemente no se mencionan. De todas formas, incluso en el caso de sólo texto, RFC 822 es inadecuado para las necesidades de usuarios de correo cuyos lenguajes requieren el uso de conjuntos de caracteres más amplios que el US-ASCII. Dado que RFC 822 no especifica mecanismos para incluir en el correo sonido, vídeo, texto en lenguajes asiáticos, o incluso de la mayoría de lenguajes europeos, se requieren especificaciones adicionales. Una de las limitaciones más notables de los sistemas de correo basados en RFC 821/822 es el hecho de que se restringe el contenido de los mensajes de correo electrónicos a líneas relativamente cortas (unos 1000 caracteres o menos [RFC 821]) en el conjunto de 7 bits US-ASCII. Esto obliga a los usuarios a convertir cualquier contenido que quieran enviar, que no sea texto, en bytes de 7 bits representados como caracteres imprimibles US-ASCII, antes de poder invocar su Agente de Usuario (User Agent, un programa mediante el cual los usuarios humanos pueden enviar y recibir correo). Ejemplos de esas codificaciones utilizadas habitualmente en Internet son la representación hexadecimal, el uuencode, el esquema de 3-en-4 base 64 especificado en RFC 1421, la representación del Andrew Toolkit [ATK], y muchos otros. Las limitaciones del correo según RFC 822 son más evidentes al considerar pasarelas de correo diseñadas para permitir intercambiar mensajes de correo entre nodos según la RFC 822 y nodos X.400. X.400 [X400] especifica mecanismos para la inclusión de contenido no de texto en los mensajes de correo electrónico. Los estándares actuales para la correspondencia entre mensajes X.400 y RFC 822 especifican N.Freed Seguimiento de Estándar [Pág. 3] RFC 2045 MIME: Primera Parte Noviembre 1996 que, o bien que el contenido no de texto de X.400 debe ser convertido (no codificado) a formato IA5Text, o bien que debe ser descartado, notificando al usuario RFC 822 que se ha descartado información. Esto es claramente indeseable, ya que la información que un usuario espera recibir se pierde. Incluso aunque un UA no pueda manejar el contenido no de texto, puede que el usuario tenga otros mecanismos externos al UA para extraer información útil del contenido. Aún más, no permite el hecho de que el mensaje sea reenviado de vuelta a un nodo de correo X.400 (p.ej., el mensaje X.400 es "tunelado" a través de correo Internet), donde la información no de texto tendría sentido otra vez. Este documento describe varios mecanismos que juntos solucionan la mayoría de estos problemas sin introducir ninguna incompatibilidad seria con el mundo existente de correo RFC 822. En particular, se describe: (1) Un campo de cabecera Versión de MIME (MIME-Version), en el que se utiliza un número de versión para indicar que el mensaje es conforme a la especificación MIME y permite a los sistemas procesadores de correo distinguir entre esos mensajes y aquellos generados por programas anteriores o no conformes con MIME, que se supone carecen de dicho campo. (2) Un campo de cabecera Tipo de Contenido (Content-Type), generalización desde RFC 1049, que puede ser usado para especificar el tipo y subtipo de los datos contenidos en el cuerpo del mensaje y para especificar completamente la representación nativa (forma canónica) de esos datos. (3) Un campo de cabecera de Codificación para la Transferencia del Contenido (Content-Transfer-Encoding), que puede ser usado para especificar tanto la transformación de codificación que ha sido aplicada al cuerpo del mensaje, como el dominio del resultado. Transformaciones de codificación distintas a la transformación identidad se aplican normalmente a los datos para permitirles pasar por mecanismos de transporte de correo que puedan tener limitaciones en cuanto a contenido de los mensajes o juegos de caracteres. (4) Dos campos de cabecera adicionales que se pueden usar para ampliar la descripción de la información contenida en el cuerpo del mensaje, el campo Identificador de Contenido (Content-ID) y el campo Descripción de Contenido (Content- Description). Todos los campos de cabecera definidos en este documento están sujetos a las reglas sintácticas generales para campos de cabecera N.Freed Seguimiento de Estándar [Pág. 4] RFC 2045 MIME: Primera Parte Noviembre 1996 especificados en la RFC 822. En particular, todos los campos de cabecera excepto el Content-Disposition pueden incluir comentarios tipo RFC 822, los cuales no tienen contenido semántico y serán ignorados durante un procesado MIME. Finalmente, para especificar y promover la interoperabilidad, RFC 2049 proporciona una declaración de aplicabilidad básica para un subconjunto de los mecanismos anteriormente descritos que definen un nivel mínimo de conformidad con este documento. NOTA HISTORICA: Varios de los mecanismos descritos en esta serie de documentos pueden parecer extraños o incluso barrocos en una lectura previa. Es importante hacer resaltar que la compatibilidad con los estándares existentes y la robustez en el uso a través de sistemas operando con los métodos actuales son dos de las máximas prioridades del grupo que ha desarrollado esta serie de documentos. En particular, la compatibilidad se ha antepuesto siempre a la elegancia. Por favor, refiérase a la edición actualizada de "Internet Official Protocol Standards" para el estado de estandarización y estado de este protocolo. RFC 822 y STD 3, RFC 1123 también recogen información para MIME ya que ninguna implementación conforme a MIME puede infringirlas. Adicionalmente, otros documentos RFC de carácter informativo serán de interés para el implementador de MIME, en particular RFC 1344, RFC 1345 y RFC 1524. 2. Definiciones, Convenciones y Gramática Genérica BNF Aunque todos los mecanismos especificados en este conjunto de documentos están descritos en prosa, la mayoría están también descritos formalmente en la notación BNF aumentada de RFC 822. Los implementadores necesitarán estar familiarizados con dicha notación para entender este conjunto de documentos, y se les remite a RFC 822 para una completa explicación de la notación BNF aumentada. Algunas de las BNF aumentadas en este conjunto de documentos menciona referencias a las reglas sintácticas definidas en RFC 822. Una gramática formal completa se obtendrá combinando los apéndices de gramática de cada documento de este conjunto con el BNF de RFC 822 más las modificaciones a RFC 822 definidas en RFC 1123 (que en concreto cambia la sintaxis de 'return', 'date' y 'mailbox'). Todos los valores numéricos y octales están en notación decimal en este conjunto de documentos. Todos los tipos de contenido, subtipos y nombres de parámetros se definen como no sensibles a la diferencia entre mayúsculas y minúsculas. Por otro lado, los valores de los N.Freed Seguimiento de Estándar [Pág. 5] RFC 2045 MIME: Primera Parte Noviembre 1996 parámetros son sensibles a mayúsculas-minúsculas a no ser que se especifique lo contrario para un determinado parámetro. NOTA SOBRE EL FORMATO: Las notas, como esta misma, ofrecen información adicional no esencial que puede ser pasada por alto por el lector sin perder nada esencial. El principal propósito de estas notas accesorias es ofrecer información acerca del fundamento de este conjunto de documentos, o para ubicar estos documentos en su contexto histórico o evolutivo. Esta información la pueden pasar por alto particularmente aquellos cuyo objetivo es construir una implementación válida, pero puede ser de utilidad para aquellos que quieran entender por qué se han hecho determinadas elecciones de diseño. 2.1 CRLF El término CRLF, en este conjunto de documentos, se refiere a la secuencia de octetos correspondientes a los dos caracteres US-ASCII CR (valor decimal 13) y LF (valor decimal 10), que tomados juntos y este orden indican un salto de linea en el correo tipo RFC 822. 2.2 Conjunto de caracteres El término "conjunto de caracteres" se usa en MIME para indicar el método para convertir una secuencia de octetos en una secuencia de caracteres. Téngase en cuenta que: no se requiere una conversión incondicional y sin ambigüedades en sentido inverso, que no todos los caracteres pueden ser representables en un determinado conjunto de caracteres y que un conjunto de caracteres puede tener más de una secuencia de octetos para representar una determinada secuencia de caracteres. Esta definición tiene como fin el permitir varias clases de codificación de caracteres, desde la simple correspondencia de tabla única como el US-ASCII hasta los métodos complejos de intercambio de tablas como los que se usan en las técnicas de ISO 2022, para usarlos como conjuntos de caracteres. De todas formas, la definición asociada con el nombre de un conjunto de caracteres MIME debe especificar completamente la correspondencia a utilizar. En particular, el uso de perfiles de información externos para determinar la correspondencia exacta no están permitidos. NOTA: el término "conjunto de caracteres" se acuñó originalmente para describir los esquemas directos como el US-ASCII y el ISO-8859-1, los cuales tienen una correspondencia simple uno-a-uno de un octeto a un carácter. Los conjuntos de caracteres que codifican multi-octetos y las técnicas de intercambio hacen la situación más compleja. Por ejemplo, algunas comunidades usan el término "codificación de N.Freed Seguimiento de Estándar [Pág. 6] RFC 2045 MIME: Primera Parte Noviembre 1996 caracteres" para lo que en MIME se denota por "conjunto de caracteres", mientras utilizan la frase "conjunto de caracteres codificado" para indicar una correspondencia abstracta de enteros (no octetos) a caracteres. 2.3 Mensaje El término "mensaje", cuando no esté adjetivado, significa o bien un (completo o "top-level") mensaje según RFC 822 siendo trasferido en una red, o bien un mensaje encapsulado en un cuerpo de tipo "message/rfc822" o "message/partial". 2.4 Entidad El término "entidad" se refiere específicamente a los campos de cabecera definidos en MIME y al contenido de un mensaje o de una de las partes en el cuerpo de una entidad multi-parte. La especificación de estas entidades es la esencia de MIME. Dado que los contenidos de una entidad son a menudo denominados "cuerpo", toma sentido el hablar del cuerpo de una entidad. Cualquier tipo de campo puede estar en la cabecera de una entidad, pero actualmente sólo aquellos campos cuyos nombres empiezan por "content-" tienen algún significado relacionado con MIME. Nótese que esto NO implica que no tengan ningún significado -- una entidad que es también un mensaje tiene campos de cabecera no definidos en MIME cuyo significado está definido en RFC 822. 2.5 Parte de cuerpo El término "parte de cuerpo" se refiere a una entidad dentro de una entidad multiparte. 2.6 Cuerpo El término "cuerpo", cuando no esté adjetivado, significa el cuerpo de una entidad, esto es, el cuerpo bien de un mensaje, bien de una parte de cuerpo. NOTA: Las cuatro anteriores definiciones son claramente circulares. Esto es inevitable, dado que la estructura completa de un mensaje MIME es en sí recursiva. 2.7 Datos de 7 bits "Datos de 7 bits" alude a información que está toda representada como líneas relativamente cortas, de 998 octetos o menos, entre secuencias de separación de línea CRLF [RFC-821]. Ningún octeto con valor decimal mayor de 127 está permitido; tampoco los NUL (octetos con valor decimal 0). Los octetos CR (valor decimal 13) y LF (valor N.Freed Seguimiento de Estándar [Pág. 7] RFC 2045 MIME: Primera Parte Noviembre 1996 decimal 10) sólo aparecen formando parte de la secuencia CRLF de salto de líneas. 2.8 Datos de 8 bits "Datos de 8 bits" se refiere a información que está toda representada como líneas relativamente cortas, de 998 octetos o menos, entre secuencias de separación de línea CFLF [RFC-821], pero se pueden utilizar octetos con valor decimal mayor que 127. Igual que con "datos de 7 bits", CR y LF sólo aparecen como parte de la secuencia CRLF de salto de línea y no se permiten NULs. 2.9 Datos binarios "Datos binarios" se refiere a datos en los que está permitida cualquier secuencia de cualesquiera octetos. 2.10 Líneas "Líneas" se define como secuencias de octetos separadas por una secuencia CRLF. Esto es consistente tanto con RFC 821 como con RFC 822. "líneas" sólo se refiere a una unidad de información en un mensaje, que puede o no corresponder con algo que sea mostrado por un Agente de Usuario. 3. Campos de cabecera MIME MIME define varios campos de cabecera nuevos de tipo RFC 822 que se usan para describir el contenido de una entidad MIME. Estos campos de cabecera aparecen en, al menos, dos contextos: (1) Como parte de una cabecera de mensaje RFC 822 normal. (2) En la cabecera de una parte del cuerpo MIME en una construcción multiparte. La definición formal de estos campos de cabecera es como sigue: entity-headers := [ content CRLF ] [ encoding CRLF ] [ id CRLF ] [ description CRLF ] *( MIME-extension-field CRLF ) IME-message-headers := entity-headers fields version CRLF ; El orden de los campos de cabecera N.Freed Seguimiento de Estándar [Pág. 8] RFC 2045 MIME: Primera Parte Noviembre 1996 ; de esta definición BNF ; es indiferente. MIME-part-headers := entity-headers [ fields ] ; Cualquier campo que no empiece con ; "content-" puede no tener significado ; definido y ser ignorado. ; El orden de los campos de cabecera ; de esta definición BNF ; es indiferente. La sintaxis de los diferentes campos de cabecera específicos de MIME se describen en las secciones siguientes. 4. Campo de cabecera MIME-version (Versión MIME) Desde que RFC 822 fue publicada en 1982, ha habido realmente un sólo formato estándar para los mensajes de Internet, y ha habido poca necesidad de indicar el formato estándar utilizado. Este documento es una especificación independiente que complementa a RFC 822. Aunque las ampliaciones en este documento han sido definidas de forma que sean compatibles con RFC 822, hay todavía circunstancias en las que sería deseable, para un programa de usuario, saber si el mensaje fue compuesto teniendo en cuenta el nuevo estándar. Por tanto, este documento define un nuevo campo de cabecera, "MIME- Version", para ser usado para indicar la version estándar del formato de cuerpo de mensaje Internet utilizado. Los mensajes compuestos de acuerdo con este documento DEBEN incluir dicho campo de cabecera, con el siguiente texto literal: MIME-Version: 1.0 La presencia de este campo de cabecera es una afirmación de que el mensaje ha sido compuesto en conformidad con este documento. Dado que es posible que un futuro documento pueda ampliar el formato de mensaje estándar otra vez, se da a continuación una descripción BNF formal para el contenido del campo MIME-Version: version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT Por lo tanto, futuros especificadores de formato que puedan reemplazar o ampliar "1.0", están limitados a dos campos de un entero, separados por un punto. Si un mensaje se recibe con un valor N.Freed Seguimiento de Estándar [Pág. 9] RFC 2045 MIME: Primera Parte Noviembre 1996 de MIME-Version distinto de "1.0", no se puede dar por supuesto que se amolda a este documento. Tenga en cuenta que el campo de cabecera MIME-Version es obligatorio en el primer nivel del mensaje. No es obligatorio para cada parte del cuerpo de una entidad multiparte. Es obligatorio para las cabeceras incrustadas de un cuerpo de tipo "message/rfc822" o "message/partial" si y sólo si el mensaje incrustado pretende ser asimismo conforme con MIME. No es posible especificar completamente cómo un lector de correo que sea conforme a MIME como se define en este documento, tratará un mensaje que pueda llegar en el futuro con algún valor de MIME-Version distinto a "1.0". Es digno de mención también resaltar que el control de versión de tipos de contenidos específicos no se realiza a través del uso de MIME-Version. En particular, algunos formatos (como application/postscript) tienen convenciones de numeración de versiones internos al formato. Donde tales convenciones existan, MIME no los reemplaza. Donde no haya tales convenciones, un tipo de contenido MIME puede utilizar un parámetro "version" en el campo "content-type" si es necesario. NOTA A LOS IMPLEMENTADORES: Cuando se comprueben los valores de MIME- Version, cualquier cadena de comentario RFC 822 que aparezca debe ignorarse. En particular, los siguientes cuatro campos MIME-Version son equivalentes: MIME-Version: 1.0 MIME-Version: 1.0 (produced by MetaSend Vx.x) MIME-Version: (produced by MetaSend Vx.x) 1.0 MIME-Version: 1.(produced by MetaSend Vx.x)0 En ausencia de un campo MIME-Version, el agente de usuario receptor de correo (conforme a los requerimientos MIME o no) puede opcionalmente elegir interpretar el cuerpo del mensaje de acuerdo a convenciones locales. Muchas de tales convenciones se utilizan actualmente y es preciso hacer notar que, en la práctica, los mensajes no-MIME pueden contener cualquier cosa. Es imposible estar seguro de que un mensaje no-MIME es texto plano en el conjunto de caracteres US-ASCII ya que puede ser un mensaje que, utilizando algún conjunto no estándar de convenciones locales anteriores a MIME, incluya texto en otro conjunto de caracteres o N.Freed Seguimiento de Estándar [Pág. 10] RFC 2045 MIME: Primera Parte Noviembre 1996 datos no de texto presentados de una manera que no pueda ser automáticamente reconocida (p.ej., un fichero uuencodeado comprimido tar de UNIX). 5. Campo de cabecera Content-Type (Tipo de Contenido) El propósito del campo Content-Type es describir la información contenida en el cuerpo lo suficiente para que el agente de usuario receptor pueda utilizar el agente o mecanismo apropiado para presentar al usuario la información, o de lo contrario hacerse cargo de la información de la manera más adecuada. Al valor de este campo se le denomina tipo de contenido. NOTA HISTORICA: El campo de cabecera Content-Type se definió primero en RFC 1049. RFC 1049 utilizaba una sintaxis más simple y menos potente, pero que tiene un alta compatibilidad con el mecanismo que se ofrece aquí. El campo de cabecera Content-Type especifica la naturaleza de la información en el cuerpo de una entidad mediante los identificadores del tipo de contenido y el subtipo, y ofreciendo información complementaria que pueda necesitarse en determinados tipos de contenidos. Después de los nombres de tipo de contenido y de subtipo, el resto del campo de cabecera es simplemente un conjunto de parámetros, especificados con la notación atributo=valor. El orden de los parámetros no es significativo. En general, el tipo de contenido de primer nivel se utiliza para indicar el tipo general de información, mientras que el subtipo especifica un formato específico para ese tipo de información. Por tanto, el tipo "image/xyz" es suficiente para decir al agente de usuario que la información es una imagen, incluso si el agente de usuario no tiene conocimiento del formato de imagen específico "xyz". Dicha información se puede usar, por ejemplo, para decidir si mostrar o no al usuario la información tal cual de un subtipo no reconocido -- dicha acción puede parecer razonable para subtipos no reconocidos de texto, pero no de imagen o de audio. Por esta razón, los subtipos registrados de texto, imagen, audio y vídeo no deben contener información que sea de un tipo distinto. Estos formatos compuestos deben ser representados utilizando los tipos "multipart" o "application". Los parámetros son modificadores del subtipo de contenido, y como tales, no afectan la naturaleza fundamental del contenido. El conjunto de parámetros significativos depende del tipo y subtipo de contenido. Muchos parámetros se asocian con un único subtipo específico. De todas formas, un tipo de contenido de primer nivel N.Freed Seguimiento de Estándar [Pág. 11] RFC 2045 MIME: Primera Parte Noviembre 1996 puede definir parámetros que sean aplicables a cualquier subtipo de ese tipo. Los parámetros puede que sean requeridos por los tipos y subtipos que definen o pueden ser opcionales. Las implementaciones de MIME deben ignorar cualquier parámetro cuyo nombre no reconozcan. Por ejemplo, el parámetro "charset" es aplicable a cualquier subtipo de "text", mientras que el parámetro "boundary" es obligatorio para cada subtipo del tipo de contenido "multipart". NO hay parámetros con significado global que se apliquen a todos los tipos de contenidos. Los mecanismos globales se consiguen mejor, en el modelo MIME, con la definición de campos de cabecera Content-* adicionales. En RFC 2046 se define un conjunto inicial de siete tipos de contenido de primer nivel. Cinco de ellos son tipos diferenciados cuyo contenido es opaco en lo que concierne al procesado MIME. Los dos restantes son tipos compuestos cuyos contenidos requieren procesado adicional por parte de los procesadores MIME. Este conjunto de tipos de contenido de primer nivel pretende ser completo. Se supone que las adiciones al gran conjunto de tipos soportados se pueden generalmente acometer mediante la creación de nuevos subtipos de estos tipos iniciales. En el futuro, sólo se podrán definir mediante ampliaciones de seguimiento de estándar a este estándar. Si, por cualquier motivo, se tiene que utilizar otro tipo de primer nivel, debe asignársele un nombre que empiece por "X-" para indicar su estado de no-estándar y evitar cualquier conflicto potencial con un futuro nombre oficial. 5.1 Sintaxis del campo Content-Type En la notación BNF aumentada de RFC 822 el valor del campo de cabecera Content-Type se define como sigue: content := "Content-Type" ":" type "/" subtype *(";" parameter) ; La concordancia de tipo y subtipo de contenido ; es SIEMPRE insensible a mayúsculas. type := discrete-type / composite-type discrete-type := "text" / "image" / "audio" / "video" / "application" / extension-token composite-type := "message" / "multipart" / extension-token N.Freed Seguimiento de Estándar [Pág. 12] RFC 2045 MIME: Primera Parte Noviembre 1996 extension-token := ietf-token / x-token ietf-token := x-token := subtype := extension-token / iana-token iana-token := parameter := attribute "=" value attribute := token ; La concordancia de atributos ; es SIEMPRE insensible a mayúsculas. value := token / quoted-string token := 1*< cualquier CHAR (US-ASCII) excepto SPACE, CTLs, o tspecials> tspecials := "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " "/" / "[" / "]" / "?" / "=" ; Deben aparecer entre comillas ; en los valores de parámetros Nótese que la definición de "tspecials" es la misma que la definición en RFC 822 de "specials" con la adición de los tres caracteres "/", "?" y "=", y quitando el ".". Nótese también que es OBLIGATORIO la especificación de un subtipo -- no puede ser omitido en el campo de cabecera Content-Type. Por lo tanto, no hay subtipos por defecto. El tipo, subtipo y nombres de parámetros no son sensibles a mayúsculas. Por ejemplo, TEXT, Text y TeXt son todos tipos de contenido de primer nivel equivalentes. Los valores de los parámetros son normalmente sensibles a mayúsculas, pero algunas veces son interpretados de forma insensible a mayúsculas, dependiendo de la utilización pretendida. (Por ejemplo, límites de multiparte son sensibles a mayúsculas, pero el parámetro "access-type" de "message/External-body" no es sensible a mayúsculas). N.Freed Seguimiento de Estándar [Pág. 13] RFC 2045 MIME: Primera Parte Noviembre 1996 Note que el valor de un parámetro de cadena entrecomillado no incluye las comillas. Esto es, las comillas de una cadena entrecomillada no forman parte del valor del parámetro, sino que simplemente se utilizan para delimitar el valor del parámetro. Además, los comentarios se permiten de acuerdo con las reglas de RFC 822 para campos de cabecera estructurados. Por tanto, las siguiente dos formas Content-type: text/plain; charset=us-ascii (Plain text) Content-type: text/plain; charset="us-ascii" son completamente equivalentes. Además de esta sintaxis, la única limitación sintáctica en la definición de nombres de subtipos es el deseo de que sus usos no deben entrar en conflicto. Esto es, sería indeseable tener a dos comunidades diferentes utilizando "Content-Type: application/foobar" para significar dos cosas distintas. El proceso de definición de nuevos subtipos de contenidos, por tanto, no pretende ser un mecanismo para imponer restricciones, sino simplemente un mecanismo para la publicación de su definición y utilización. Hay, por tanto, dos mecanismos aceptables para definir nuevos tipos de contenidos: (1) Valores privados (empezando con "X-") que pueden ser definidos bilateralmente entre dos agentes cooperantes sin registro o autorización externa. Dichos valores no pueden ser registrados o estandarizados. (2) Nuevos valores estándar que deberán ser registrados con IANA como se describe en RFC 2048. El segundo documento de este conjunto, RFC 2046, define el conjunto inicial de tipos de contenido para MIME. 5.2 Valores por defecto del campo Content-Type Los mensajes por defecto de tipo RFC 822 sin una cabecera Content- Type de MIME son considerados por este protocolo que son texto plano en el conjunto de caracteres US-ASCII, lo cual puede ser explícitamente definido como: Content-type: text/plain; charset=us-ascii Este valor por defecto se toma si no se especifica el campo de cabecera Content-Type. También se recomienda que este valor por defecto se asuma cuando se encuentre un contenido sintácticamente incorrecto del campo de cabecera Content-Type. En presencia de un N.Freed Seguimiento de Estándar [Pág. 14] RFC 2045 MIME: Primera Parte Noviembre 1996 campo de cabecera MIME-Version y en ausencia del campo de cabecera Content-type, el Agente de Usuario receptor puede también asumir que era texto plano US-ASCII lo que se pretendía enviar. Texto plano US- ASCII también puede darse por sentado incluso en ausencia de MIME- Version o la presencia de un campo de cabecera Content-type sintácticamente inválido, pero la intención del remitente podría haber sido otra cualquiera. 6. Campo Content-Transfer-Encoding (Codificación para la Transferencia de Contenido) Muchos tipos de contenidos que podría ser útil transportar vía correo electrónico están representados, en su formato "natural", como caracteres de 8 bits o como datos binarios. Estos datos no se pueden transmitir sobre algunos protocolos de transferencia. Por ejemplo, RFC 821 (SMTP) restringe los mensaje de correo a datos de 7 bits US- ASCII con lineas no más largas de 1000 caracteres incluyendo los separadores de lineas CRLF al final. Es necesario, por lo tanto, definir un mecanismo estándar para codificar esos datos en el formato de líneas cortas de 7 bits. También es deseable el etiquetado adecuado de material codificado en formatos menos restrictivos para el uso directo sobre transportes menos restrictivos. Este documento especifica que dichas codificaciones se indicarán en un nuevo campo de cabecera "Content- Transfer-Encoding". Este campo no ha sido definido por ningún estándar previo. 6.1 Sintaxis del campo Content-Transfer-Encoding El contenido del campo Content-Transfer-Encoding es una única etiqueta especificando el tipo de codificación, como se enumera más adelante. Formalmente: encoding := "Content-Transfer-Encoding" ":" mechanism mechanism := "7bit" / "8bit" / "binary" / "quoted-printable" / "base64" / ietf-token / x-token Estos valores no son sensibles a mayúsculas -- Base64 y BASE64 y bAsE64 son todos equivalentes. Un tipo de codificación de 7BIT requiere que el cuerpo esté en una representación de 7bit. Este es el valor por defecto -- esto es, se asume "Content-Transfer-Encoding: 7BIT" si no está presente el campo Content-Transfer-Encoding. N.Freed Seguimiento de Estándar [Pág. 15] RFC 2045 MIME: Primera Parte Noviembre 1996 6.2 Semántica Esta única etiqueta Content-Transfer-Encoding proporciona dos informaciones. Especifica qué clase de transformación de codificación ha sufrido el cuerpo y por tanto qué operación de decodificación debe usarse para restaurarla a su forma original, y especifica a qué dominio pertenece el resultado. La parte de transformación de Content-Transfer-Encoding especifica, explícita o implícitamente, un único y bien definido algoritmo de decodificación, el cual para cada secuencia de octetos codificados o bien la transforma en la secuencia original de octetos que fue codificada, o bien indica que es ilegal como secuencia codificada. Las transformaciones Content-Transfer-Encoding nunca dependen de perfiles externos adicionales para un correcto funcionamiento. Nótese que mientras los decodificadores deben producir una única y bien definida salida, para una codificación válida no existen esas restricciones en los codificadores: La codificación de una secuencia de octetos dada en distintas y equivalentes secuencias codificadas es perfectamente legal. Actualmente hay tres transformaciones definidas: identidad, la codificación "quoted-printable" y la codificación "base64". Los dominios son "binary", "8bit" y "7bit". Los valores de Content-Transfer-Encoding "7bit", "8bit" y "binary" significan que se ha realizado la transformación de codificación identidad (esto es, NO se ha realizada ninguna transformación de codificación). Por tanto, sirven simplemente como indicadores del dominio al que pertenecen los datos del cuerpo, y proporcionan información útil acerca de la clase de codificación que pudiera ser necesaria para la transmisión en un sistema de transporte dado. Los términos "7bit data", "8bit data" y "binary data" se definen en la Sección 2. Las codificaciones quoted-printable y base64 transforman la entrada de un dominio arbitrario en salida en el ámbito de "7bit", haciéndola por tanto segura para llevarla sobre transportes restringidos. La definición específica de las transformaciones se da más abajo. Se debe utilizar siempre la etiqueta de Content-Transfer-Encoding apropiada. No está permitido etiquetar datos no codificados que contengan caracteres de 8bit como "7bit" 6.3 Nuevos Content-Transfer-Encoding Los implementadores podrán, si es necesario, definir valores propios N.Freed Seguimiento de Estándar [Pág. 16] RFC 2045 MIME: Primera Parte Noviembre 1996 de Content-Transfer-Encoding, pero deberán usar una marca x-token, el cual es un nombre con prefijo "X-", para indicar su carácter no- estándar, p.e., "Content-Transfer-Encoding: x-mi-nuevo-codigo". Los valores adicionales estándar deberán ser especificados a través de una RFC de seguimiento de estándar. Los requerimientos que dichas especificaciones deben cumplir se recogen en RFC 2048. Por tanto, el conjunto de nombres de content-transfer-encoding salvo los que empiecen por "X-" están explícitamente reservados a la IETF para usos futuros. Al contrario que con los tipos y subtipos de contenido, la creación de nuevos valores de Content-Transfer-Encoding está fuertemente desaconsejada, ya que parece probable que impidiera la interoperabilidad a cambio de un pequeño beneficio potencial. 6.4 Interpretación y uso Si un campo de cabecera Content-Transfer-Encoding aparece como parte de una cabecera de mensaje, se aplica al cuerpo entero de ese mensaje. Si un campo de cabecera Content-Transfer-Encoding aparece formando parte de la cabecera de una entidad, se aplica sólo al cuerpo de esa entidad. Si una entidad es del tipo "multipart" el Content-Transfer-Encoding no está permitido que tenga otro valor que no sea "7bit", "8bit" o "binary". Se aplican restricciones incluso más severas a algunos subtipos del tipo "message". Debe hacerse notar que la mayoría de los tipos de contenido se definen en términos de octetos en vez de bits, por lo que los mecanismos descritos aquí son mecanismos para la codificación de flujos arbitrarios de octetos, no flujos de bits. Si un flujo de bits va a ser codificado mediante uno de estos mecanismos, primero debe ser convertido a un flujo de bytes de 8 bits usando el orden de bits estándar en la red ("big-endian"), en el cual los primeros bits de un flujo son los bits de orden alto de un byte de 8 bits. Un flujo de bits que no termine con 8 bits debe ser completado con ceros. RFC 2046 provee un mecanismo para anotar la adición de dicho relleno en el caso del tipo de contenido application/octet-stream, el cual tiene un parámetro "padding" (relleno). Los mecanismos de codificación definidos aquí, explícitamente codifican todos los datos en US-ASCII. De ese modo, por ejemplo, supongamos que una entidad tiene unos campos de cabecera como sigue: Content-Type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: base64 Esto debe interpretarse que significa que el cuerpo es una N.Freed Seguimiento de Estándar [Pág. 17] RFC 2045 MIME: Primera Parte Noviembre 1996 codificación base64 US-ASCII de datos originalmente en ISO-8859-1, y que estarán en ese conjunto de caracteres otra vez después de la decodificación. Determinados valores de Content-Transfer-Encoding pueden ser solamente usados sobre determinados tipos de contenido. En particular, está EXPRESAMENTE PROHIBIDO usar cualquier otro aparte de "7bit", "8bit" o "binary" con un tipo de contenido compuesto, p.ej. uno que incluya recursivamente otros campos Content-Type. Actualmente los únicos tipos de contenido compuestos son "multipart" y "message". Todas las codificaciones deseadas para cuerpos de tipo multipart o message deben hacerse al nivel más interno, codificando el cuerpo que necesite ser codificado. Debe hacerse notar que, por definición, si una entidad compuesta tiene un valor de transfer-encoding tal como "7bit", pero una de las entidades contenidas tiene un valor menos restrictivo tal como "8bit", entonces o bien el etiquetado externo de "7bit" es un error, porque se incluyen datos en 8bit, o el etiquetado interno de 8bit establece una demanda innecesaria de recursos del sistema de transporte ya que los datos incluidos son ya 7bit-seguros. NOTA SOBRE RESTRICCIONES DE CODIFICACION: Aunque la prohibición en contra de la utilización de codificaciones-para-transferencia-de- contenidos en datos de cuerpos compuestos pueda parecer demasiado restrictiva, es necesario prevenir codificaciones anidadas, en las cuales los datos pasan múltiples veces por un algoritmo de codificación, y deben ser decodificados múltiples veces para ser correctamente visualizados. Las codificaciones anidadas añaden mucha complejidad a los agentes de usuario: aparte de los problemas obvios de eficiencia con tales codificaciones múltiples, pueden oscurecer la estructura básica de un mensaje. En particular, pueden implicar que sean necesarias varias operaciones de decodificación simplemente para saber cuántos tipos de cuerpo contiene el mensaje. La prohibición de codificaciones anidadas puede complicar el trabajo de determinadas pasarelas de correo, pero esto parece menos problemático que el efecto de codificaciones anidadas en los agentes de usuario. Una entidad con un valor desconocido de Content-Transfer-Encoding debe ser tratada como si el valor de Content-Type fuera de "application/octet-stream", sin importar el valor que tenga el campo de cabecera Content-Type. NOTA SOBRE LA RELACION ENTRE CONTENT-TYPE Y CONTENT-TRANSFER- ENCODING: Puede parecer que Content-Transfer-Encoding podría inferirse de las características del contenido que se va a codificar, o, como mínimo, que determinados Content-Transfer-Encoding podrían ser obligatorios para un tipo de contenido concreto. Existen varias N.Freed Seguimiento de Estándar [Pág. 18] RFC 2045 MIME: Primera Parte Noviembre 1996 razones por las que no ocurre esto. Primero, dado la variación de tipos de transporte utilizado con el correo, algunas codificaciones pueden ser apropiadas para una combinación de tipo de contenido y transporte, pero no para otras combinaciones. (Por ejemplo, en un transporte de 8bit, no se requeriría ninguna codificación para texto en determinados conjuntos de caracteres, mientras que dichas codificaciones son claramente necesarias sobre SMTP de 7bit.) Segundo, determinados tipos de contenido pueden necesitar diferentes tipos de codificación para transmisión bajo diferentes circunstancias. Por ejemplo, muchos cuerpos PostScript pueden consistir en su totalidad en lineas cortas de datos de 7bit y por tanto no precisar ninguna codificación. Otros cuerpos PostScript (especialmente aquellos que utilizan el mecanismo de codificación binario del PostScript Nivel 2) pueden ser solamente representados razonablemente utilizando una codificación binary. Finalmente, dado que el campo Content-Type se pretende que sea un mecanismo de especificación abierto, la especificación estricta de una asociación entre tipos de contenido y codificaciones emparejaría la especificación de un protocolo de aplicación con un transporte determinado de más bajo nivel. Esto no es una situación deseable ya que los desarrolladores de un tipo de contenido tendrían que estar al tanto de todos los transporte en uso y de cuales son sus limitaciones. 6.5 Traduciendo codificaciones Las codificaciones quoted-printable y base64 están diseñadas de forma que la conversión entre ellas sea posible. La única cuestión que surge en dicha conversión es el tratamiento de los saltos de línea duros en la salida codificada quoted-printable. Cuando se convierte desde quoted-printable a base64, un salto de línea duro quoted- printable representa una secuencia CRLF en la forma canónica de los datos. Por lo tanto debe convertirse al CRLF codificado que le corresponde en la forma base64 de los datos. De igual forma, una secuencia CRLF en la forma canónica obtenida después de la decodificación base64 debe ser convertida a un salto de línea duro quoted-printable, pero SOLAMENTE cuando se conviertan datos de texto. 6.6 Modelo canónico de codificación Había alguna confusión, en las versiones previas de esta RFC, respecto al modelo a seguir para decidir cuándo los datos de mensajes iban a ser convertidos a una forma canónica y codificados, y en particular cómo este proceso habría de afectar al tratamiento de los CRLF, ya que la representación del salto de línea varía enormemente N.Freed Seguimiento de Estándar [Pág. 19] RFC 2045 MIME: Primera Parte Noviembre 1996 de un sistema a otro, y la relación entre content-transfer-encoding y los conjuntos de caracteres. Por esta razón en RFC 2049 se presenta un modelo canónico de codificación. 6.7 Content-Transfer-Encoding "Quoted-Printable" La pretensión de la codificación Quoted-Printable es representar datos que en gran parte consisten en octetos que se corresponden con caracteres imprimibles en el conjunto de caracteres US-ASCII. Codifica los datos de tal forma que los octetos resultantes sea improbable que los modifique el transporte de correo. Si los datos codificados son principalmente texto en US-ASCII, la forma codificada de los datos continúa siendo en gran medida reconocible por humanos. Un cuerpo que sea completamente US-ASCII puede ser también codificado en Quoted-Printable para asegurar la integridad de los datos por si el mensaje pasara a través de una pasarela con traducción de caracteres y/o tratamiento de líneas. En esta codificación, los octetos se representarán de la forma determinada por las siguientes reglas: (1) (Representación general de 8bit) Cualquier octeto, excepto CR o LF que sea parte de un salto de línea CRLF en la forma canónica (estándar) de los datos que están siendo codificados, deben ser representados por un "=" seguido por la representación hexadecimal de dos dígitos del valor del octeto. Los dígitos del alfabeto hexadecimal, para este propósito, son "0123456789ABCEDF". Se deben usar letras mayúsculas; las minúsculas no están permitidas. Así, por ejemplo, el valor decimal 12 (expulsión de página US-ASCII) puede ser representado por "=0C", y el valor decimal 61 (signo igual US-ASCII) se puede representar con "=3D". Esta regla se debe seguir excepto cuando las reglas siguientes permitan una codificación alternativa. (2) (Representación literal) Los octetos con valor decimal del 33 al 60, ambos inclusive, y del 62 al 126, ambos inclusive, DEBEN ser representados con los caracteres US-ASCIII que correspondan a esos octetos.( EXCLAMACION hasta MENOR QUE, y MAYOR QUE hasta TILDE, respectivamente). (3) (Espacio en blanco) Los octetos con valor de 9 y 32 DEBEN ser representados como el carácter TAB de US-ASCII y el carácter SPACE, respectivamente, pero NO DEBEN ser representados así al final de una línea codificada. Cualquier carácter TAB (HT) o SPACE en una línea codificada DEBE, por tanto, ir seguido en esa línea de por un carácter imprimible. En particular, un N.Freed Seguimiento de Estándar [Pág. 20] RFC 2045 MIME: Primera Parte Noviembre 1996 "=" al final de una línea codificada, indicando un salto de línea suave (ver Regla #5) debe seguir a uno o más caracteres TAB (HT) o SPACE. De lo que resulta que un octeto con valor decimal de 9 o 32 apareciendo al final de una línea codificada debe ser representado de acuerdo con la Regla #1. Esta regla es necesaria porque algunos MTAs (Message Transport Agents, Agentes de Transporte de Mensajes, programas que transportan los mensajes de un usuario a otro, o realizan parte de esa transferencia) es sabido que completan las líneas de texto con SPACEs (espacios), y otros es sabido que quitan carácteres de "espacio en blanco" del final de las líneas. Por tanto, cuando se decodifique un cuerpo Quoted-Printable, cualquier espacio en blanco del final de una línea debe ser borrado, porque habrá sido necesariamente añadido por agentes de transporte intermedios. (4) (Saltos de línea) Un salto de línea en un cuerpo de texto, representado por la secuencia CRLF en la forma canónica de texto, debe ser representado por un salto de línea (RFC 822), el cual es también una secuencia CRLF en la codificación Quoted-Printable. Dado que la representación canónica de tipos de contenido distintos de texto no incluyen generalmente la representación de saltos de línea como secuencias CRLF, no pueden aparecer saltos de línea duros (esto es, saltos de línea que tienen significado y que se pretende que se visualicen al usuario) en la codificación Quoted-Printable de esos tipos. Secuencias como "=0D", "=0A", "=0A=0D" y "=0D=0A" aparecerán normalmente en datos no de texto representados en quoted-printable, por supuesto. Nótese que muchas implementaciones pueden elegir codificar la representación local de diferentes tipos de contenido directamente en vez de convertirlo primero a la forma canónica, codificarlo y luego reconvertirlo a la representación local. En particular, esto es aplicable a material de texto plano en sistemas que utilizan convenciones de salto de línea diferentes a la secuencia CRLF. Dicha optimización de la implementación es permisible, pero sólo cuando el paso combinado de canonización-codificación sea equivalente a aplicar los tres pasos por separado. (5) (Saltos de línea suaves) La codificación Quoted-Printable REQUIERE que las líneas codificadas no sean de más de 76 caracteres de longitud. Si se van a codificar líneas más largas con la codificación Quoted-Printable, se deben utilizar saltos de línea "suaves". Un signo igual como último carácter en una línea codificada indica la existencia de ese salto de línea no significativo ("suave") en el texto N.Freed Seguimiento de Estándar [Pág. 21] RFC 2045 MIME: Primera Parte Noviembre 1996 codificado. De este modo si la forma "natural" de la línea es una única línea no codificada que dice: Ahora es el momento para todas las personas de ayudar a su país. Esto se puede representar, en la codificación Quoted-Printable, como: Ahora es el momento = para todas las personas de= ayudar a su país. Esto proporciona un mecanismo con el cual las líneas largas se codifican de una forma que pueda ser restaurada por el agente de usuario. El límite de 76 caracteres no tiene en cuenta el CRLF del final, pero cuenta todos los demás caracteres, incluyendo cualquier signo igual. Dado que el carácter guión ("-") se puede representar con él mismo en la codificación Quoted-Printable, se debe tener cuidado cuando se encapsule un cuerpo codificado quoted-printable dentro de una o más entidades multiparte, para asegurar que el indicador de límite no aparezca en algún lugar del cuerpo codificado. (Una buena estrategia es elegir un límite que incluya una secuencia de caracteres como "=_", la cual no puede aparecer nunca en un cuerpo quoted-printable. Véase la definición de mensajes multiparte en RFC 2046). NOTA: La codificación Quoted-Printable representa el compromiso entre legibilidad y fiabilidad en el transporte. Los cuerpos codificados con la codificación quoted-printable funcionarán fiablemente sobre la mayoría de las pasarelas de correo, pero pueden no funcionar perfectamente sobre unas pocas pasarelas, especialmente aquellas con traducción a EBCDIC. Un mayor nivel de confianza lo ofrece el Content-Transfer-Encoding base64. Una manera de conseguir un transporte razonablemente fiable a través de pasarelas EBCDIC es representar también los caracteres US-ASCII !"#$@[\]^`{|}~ de acuerdo con la Regla #1. Debido a que los datos en quoted-printable se asume generalmente que están basados en líneas, se debe esperar que la representación de los saltos entre las líneas de datos en quoted-printable puedan ser alterados durante el transporte, de la misma forma que el correo de texto plano siempre ha sido alterado en el correo Internet en el paso entre sistemas con distintas convenciones de salto de línea. Si N.Freed Seguimiento de Estándar [Pág. 22] RFC 2045 MIME: Primera Parte Noviembre 1996 dichas alteraciones es probable que produzcan corrupción en los datos, probablemente sea más acertado utilizar la codificación base64 en lugar de la codificación quoted-printable. NOTA: Varios clases de subcadenas no pueden ser generadas de acuerdo a las reglas de codificación content-transfer-encoding del tipo quoted-printable, y por lo tanto son formalmente ilegales si aparecen en la salida de un codificador quoted-printable. Esta nota enumera estos casos y sugiere maneras de manejar esas subcadenas ilegales si son encontradas en los datos quoted-printable que se van a decodificar. (1) Un "=" seguido de dos dígitos hexadecimales, uno o dos de los cuales son letras minúsculas en "abcdef", es formalmente ilegal. Una implementación robusta podría elegir el tratarlas como las correspondientes letras mayúsculas. (2) Un "=" seguido por un carácter que no es ni un dígito hexadecimal (incluyendo "abcdef") ni el carácter CR de un par CRLF es ilegal. Este caso puede ser el resultado de haber sido incluido texto US-ASCII en la parte quoted-printable de un mensaje que no haya sido por sí mismo codificado como quoted-printable. Una aproximación razonable de una implementación robusta podría ser incluir el carácter "=" y el siguiente carácter en los datos decodificados sin ninguna transformación y, si es posible, indicar al usuario que la decodificación correcta no ha sido posible en ese punto de los datos. (3) Un carácter "=" no puede ser ni el último ni el penúltimo carácter de un objeto codificado. Esto podría tratarse como en el caso (2) anterior. (4) Caracteres de control distintos del TAB, o CR y LF como partes de pares CRLF, no deben aparecer. Lo mismo es válido para octetos con valor decimal mayor que 126. Si un decodificar los encuentra en datos quoted-printable entrantes, una implementación robusta debe excluirlos de los datos decodificados y advertir al usuario que han sido descubiertos caracteres ilegales. (5) Las líneas codificadas no deben ser más largas de 76 caracteres, sin contar el CRLF del final. Si se encuentran líneas más largas en datos codificados entrantes, una implementación robusta debería, a pesar de todo, decodificar las líneas, y debería informar al usuario de la codificación errónea. N.Freed Seguimiento de Estándar [Pág. 23] RFC 2045 MIME: Primera Parte Noviembre 1996 ADVERTENCIA A LOS IMPLEMENTADORES: Si se codifican datos binarios en quoted-printable, debe tomarse cuidado en codificar los caracteres CR y LF como "=0D" y "=0A" respectivamente. En particular, una secuencia CRLF en datos binarios se codificará "=0D=0A". En caso contrario, si CRLF fuese representado como un salto de línea duro, podría ser incorrectamente decodificada en plataformas con diferente convención de saltos de línea. Para los formalistas, la sintaxis de datos quoted-printable se describe con la siguiente gramática: quoted-printable := qp-line *(CRLF qp-line) qp-line := *(qp-segment transport-padding CRLF) qp-part transport-padding qp-part := qp-section ; Longitud máxima de 76 caracteres qp-segment := qp-section *(SPACE / TAB) "=" ; Longitud máxima de 76 caracteres qp-section := [*(ptext / SPACE / TAB) ptext] ptext := hex-octet / safe-char safe-char := ; Los caracteres no listados como "mail-safe" en ; RFC 2049 tampoco se recomiendan. hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") ; Octet debe usarse para caracteres > 127, =, ; SPACEs o TABs al final de línea, y se ; recomienda para cualquier carácter no listado ; en RFC 2049 como "mail-safe". transport-padding := *LWSP-char ; Los compositores NO DEBEN generar ; "transport padding", ; pero los receptores DEBEN ; poder manejar rellenos ; añadidos en el transporte del mensaje. IMPORTANTE: NO está permitida la adición de LWSP entre los elementos mostrados en esta BNF ya que esta BNF no especifica un campo de cabecera estructurado. N.Freed Seguimiento de Estándar [Pág. 24] RFC 2045 MIME: Primera Parte Noviembre 1996 6.8 Content-Transfer-Encoding "Base64" El Content-Transfer-Encoding Base64 está diseñado para representar secuencias arbitrarias de octetos en una forma no necesariamente legible por humanos. Los algoritmos de codificación y de decodificación son simples, pero los datos codificados son por lo regular sólo un 33 por ciento más grandes que los datos sin codificar. Esta codificación es virtualmente idéntica a la usada en aplicaciones de Correo Electrónico Privado (PEM: privacy Enhanced Mail), como se define en RFC 1421. Se utiliza un subconjunto de 65 caracteres de US-ASCII, permitiendo representar 6 bits por cada carácter imprimible. (El carácter extra 65, "=", se utiliza para indicar una función especial de proceso). NOTA: Este subconjunto tiene la importante propiedad de que se representa de idéntica forma en todas las versiones de ISO 646, incluyendo US-ASCII, y todos los caracteres del subconjunto se representan igual en todas las versiones de EBCDIC. Otras codificaciones populares, como la codificación utilizada por la utilidad "uuencode", el binhex 4.0 [RFC 1741] de Macintosh, y la codificación base85 especificada como parte del PostScript Nivel 2, no comparten estas propiedades, y por tanto no satisfacen los requerimientos de portabilidad que una codificación binaria para el transporte de correo debe tener. El proceso de codificación representa grupos de 24 bits de la entrada como cadenas de salida de 4 caracteres codificados. Procediendo de izquierda a derecha, se forma un grupo de 24 bits de entrada concatenando 3 grupos de 8 bits de entrada. Estos 24 bits se tratan como 4 grupos concatenados de 6 bits, cada uno de los cuales se traduce en un sólo dígito del alfabeto base64. Cuando se codifica un flujo de bits mediante la codificación base64, el flujo de bits se debe considerar ordenado con el bit más significativo primero. Esto es, el primer bit del flujo será el bit de orden más alto en el primer byte de 8 bits, y el octavo bit será el de orden más bajo en el primer byte de 8 bits, y así sucesivamente. Cada grupo de 6 bits se usa como índice en un array de 64 caracteres imprimibles. El carácter referenciado por el índice se coloca en la cadena de salida. Estos caracteres, identificados en la Tabla 1, abajo, se han escogido por ser universalmente representables, y el conjunto excluye caracteres con significado particular en SMTP (p.ej. ".", CR, LF) y los identificadores de límites multiparte definidos en RFC 2046 ("-"). N.Freed Seguimiento de Estándar [Pág. 25] RFC 2045 MIME: Primera Parte Noviembre 1996 Tabla 1: El Alfabeto Base64 Valor Codificación Valor Cod. Valor Cod. Valor Cod. 0 A 17 R 34 i 51 z 1 B 18 S 35 j 52 0 2 C 19 T 36 k 53 1 3 D 20 U 37 l 54 2 4 E 21 V 38 m 55 3 5 F 22 W 39 n 56 4 6 G 23 X 40 o 57 5 7 H 24 Y 41 p 58 6 8 I 25 Z 42 q 59 7 9 J 26 a 43 r 60 8 10 K 27 b 44 s 61 9 11 L 28 c 45 t 62 + 12 M 29 d 46 u 63 / 13 N 30 e 47 v 14 O 31 f 48 w (relleno) = 15 P 32 g 49 x 16 Q 33 h 50 y El flujo de salida codificado debe ser representado en lineas de no más de 76 caracteres cada una. Todos los saltos de línea u otros caracteres no presentes en la Tabla 1 deben ser ignorados por el software de decodificación. En datos base64, los caracteres no representados en la Tabla 1, saltos de línea y otros espacios en blanco probablemente indican un error en la transmisión, respecto al cual un mensaje de aviso o incluso un rechazo del mensaje podrían ser apropiados bajo algunas circunstancias. Se realiza un proceso especial si quedan disponibles menos de 24 bits al final de los datos que se están codificando. Al final del cuerpo siempre se completa un quanto entero de codificación. Cuando están disponibles menos de 24 bits en un grupo de entrada, se añaden bits cero (a la derecha) para formar un número entero de grupos de 6 bits. El relleno al final de los datos se realiza utilizando el carácter "=". Dado que la entrada de base64 es un número entero de octetos, sólo pueden ocurrir los siguientes casos: (1) el quanto final de la entrada a codificar es un múltiplo entero de 24 bits; aquí, la unidad final de la salida codificada será un 'múltiplo entero de 4' caracteres sin relleno con "=", (2) el quanto final de la entrada a codificar es exactamente de 8 bits; aquí, la unidad final de salida codificada será de dos caracteres seguidos de dos caracteres "=" de relleno, o (3) el quanto final de la entrada a codificar es exactamente 16 bits; aquí, la unidad final de la salida codificada serán tres caracteres seguidos de un carácter "=" de relleno. Ya que se usa sólo para rellenar al final de los datos, la existencia N.Freed Seguimiento de Estándar [Pág. 26] RFC 2045 MIME: Primera Parte Noviembre 1996 de cualquier carácter "=" se puede tomar como evidencia de que se ha alcanzado el final de los datos (sin truncamiento en el tránsito). Sin embargo, dicha seguridad no es posible cuando el número de octetos transmitidos sea un múltiplo de tres y no haya ningún carácter "=". Cualquier carácter fuera del alfabeto base64 será ignorado en los datos codificados base64. Se debe tener cuidado en utilizar los octetos apropiados para saltos de línea si la codificación base64 se aplica directamente a material de texto que no haya sido convertido a la forma canónica. En particular, saltos de línea de texto deben ser convertidos en secuencias CRLF antes de la codificación en base64. Lo importante a tener en cuenta es que esto puede ser realizado por el codificador en vez de en un paso previo de canonización en algunas implementaciones. NOTA: No existe la necesidad de preocuparse por los posibles indicadores de límites en cuerpos codificados base64 dentro de entidades multiparte porque en la codificación base64 no se utiliza ningún carácter de guión. 7. Campo de cabecera Content-ID ( Identificador de Contenido) Cuando se construye un agente de usuario de alto nivel, puede ser deseable permitir que un cuerpo haga referencia a otro. En consecuencia, los cuerpos pueden ser etiquetados utilizando el campo de cabecera "Content-ID", el cual es sintácticamente idéntico al campo de cabecera "Message-ID": id := "Content-ID" ":" msg-id Al igual que los valores de Message-ID, los valores de Content-ID deben ser generados para ser globalmente únicos. El valor Content-ID puede utilizarse para identificar entidades MIME en varios contextos, en particular para almacenamiento provisional de datos referenciados mediante el mecanismo message/external-body. Aunque el campo de cabecera Content-ID es generalmente opcional, su uso es OBLIGATORIO en implementaciones que generen datos del tipo de contenido MIME opcional "message/external-body". Esto es, cada entidad message/external-body debe tener un campo Content-ID para permitir el almacenamiento provisional de esos datos. También merece la pena mencionar que el valor Content-ID tiene un significado especial en el caso de tipo de contenido multipart/alternative. Esto se explica en la sección de RFC 2046 N.Freed Seguimiento de Estándar [Pág. 27] RFC 2045 MIME: Primera Parte Noviembre 1996 referente a multipart/alternative. 8. Campo de cabecera Content-Description (Descripción de Contenido ) Es a menudo deseable la capacidad de asociar alguna información descriptiva con un cuerpo dado. Pro ejemplo, puede ser útil marcar un cuerpo "image" como "una foto de la Lanzadera Espacial Endeavor". Dicho texto puede ser colocado en el campo de cabecera Content- Description. Este campo de cabecera es siempre opcional. description := "Content-Description" ":" *text La descripción se asume que está en el conjunto de caracteres US- ASCII, aunque el mecanismo especificado en RFC 2047 se puede utilizar para valores de Content-Description no US-ASCII. 9. Campos adicionales de la cabecera MIME Futuros documentos pueden elegir el definir campos de cabecera MIME adicionales con varios propósitos. Cualquier nuevo campo de cabecera que amplíe la descripción del contenido de un mensaje debería empezar con la cadena "Content-" para permitir que dichos campos que aparecieran en la cabecera pudieran ser diferenciados de los campos de cabecera RFC 822 usuales. MIME-extension-field := 10. Sumario Utilizando los campos de cabecera MIME-Version, Content-Type y Content-Transfer-Encoding es posible incluir, de un forma estandarizada, cualquier tipo de datos arbitrario en mensajes conformes a RFC 822. No se infringe ninguna restricción impuesta por RFC 821 ni RFC 822, y se ha puesto cuidado para evitar problemas producidos por las restricciones adicionales impuestas por las características de algunos mecanismos de transporte de correo Internet (ver RFC 2049). El siguiente documento de este conjunto, RFC 2046, especifica el conjunto inicial de tipos de contenido que pueden ser indicados y transportados utilizando estas cabeceras. 11. Consideraciones de seguridad Las cuestiones de seguridad se abordan en el segundo documento de N.Freed Seguimiento de Estándar [Pág. 28] RFC 2045 MIME: Primera Parte Noviembre 1996 este conjunto, RFC 2046. 12. Direcciones de los autores Para más información, es mejor contactar con los autores de este documento a través de correo Internet: Ned Freed Innosoft International, Inc. 1050 East Garvey Avenue South West Covina, CA 91790 USA Phone: +1 818 919 3600 Fax: +1 818 919 3614 EMail: ned@innosoft.com Nathaniel S. Borenstein First Virtual Holdings 25 Washington Avenue Morristown, NJ 07960 USA Phone: +1 201 540 8967 Fax: +1 201 993 3032 EMail: nsb@nsb.fv.com MIME es el resultado del Grupo de Trabajo en Ampliaciones de RFC 822 de la Internet Engineering Task Force. Con el presidente de dicho grupo, Greg Vaudreuil, se puede contactar en: Gregory M. Vaudreuil Octel Network Services 17080 Dallas Parkway Dallas, TX 75248-1905 USA EMail: Greg.Vaudreuil@Octel.Com Traducción al castellano: José M. Caínzos -------------- SEVILLA EMail: jmcainzos@airtel.net N.Freed Seguimiento de Estándar [Pág. 29] RFC 2045 MIME: Primera Parte Noviembre 1996 A. Compendio de Gramática Este apéndice contiene la gramática BNF completa para toda la sintaxis especificada por este documento. Por si misma, de todas formas, esta gramática es incompleta. Hace referencia a varias reglas sintácticas que están definidas por RFC 822. En vez de reproducir esas definiciones aquí, y por el riesgo de diferencias inintencionadas entre las dos, este documento simplemente remite al lector a RFC 822 para las definiciones restantes. Cuando un término esté indefinido, se remite a la definición de RFC 822. attribute := token ; La concordancia de atributos ; es SIEMPRE insensible a mayúsculas. composite-type := "message" / "multipart" / extension-token content := "Content-Type" ":" type "/" subtype *(";" parameter) ; La concordancia de tipo y subtipo de medio ; es SIEMPRE insensible a mayúsculas. description := "Content-Description" ":" *text discrete-type := "text" / "image" / "audio" / "video" / "application" / extension-token encoding := "Content-Transfer-Encoding" ":" mechanism entity-headers := [ content CRLF ] [ encoding CRLF ] [ id CRLF ] [ description CRLF ] *( MIME-extension-field CRLF ) extension-token := ietf-token / x-token hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") ; Octet debe ser usado para caracteres > 127, =, ; SPACEs o TABs al final de línea, y se ; recomienda para cualquier carácter no listado en ; RFC 2049 como "mail-safe". iana-token := N.Freed Seguimiento de Estándar [Pág. 30] RFC 2045 MIME: Primera Parte Noviembre 1996 ietf-token := id := "Content-ID" ":" msg-id mechanism := "7bit" / "8bit" / "binary" / "quoted-printable" / "base64" / ietf-token / x-token MIME-extension-field := MIME-message-headers := entity-headers fields version CRLF ; El orden de los campos de cabecera ; implícitos por esta definición BNF ; deben ser ignorados. MIME-part-headers := entity-headers [fields] ; Cualquier campo que no empiece con ; "content-" puede tener un significado no ; definido y puede ser ignorado. ; El orden de los campos de cabecera ; implícitos por esta definición BNF ; deben ser ignorados. parameter := attribute "=" value ptext := hex-octet / safe-char qp-line := *(qp-segment transport-padding CRLF) qp-part transport-padding qp-part := qp-section ; Longitud máxima de 76 caracteres qp-section := [*(ptext / SPACE / TAB) ptext] qp-segment := qp-section *(SPACE / TAB) "=" ; Longitud máxima de 76 caracteres quoted-printable := qp-line *(CRLF qp-line) safe-char := ; Los caracteres no listados como "mail-safe" en N.Freed Seguimiento de Estándar [Pág. 31] RFC 2045 MIME: Primera Parte Noviembre 1996 ; RFC 2049 tampoco se recomiendan. subtype := extension-token / iana-token token := 1* transport-padding := *LWSP-char ; Los compositores NO DEBEN generar ; "transport padding", ; pero los receptores DEBEN ; poder manejar rellenos ; añadidos en el transporte del mensaje. tspecials := "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " "/" / "[" / "]" / "?" / "=" ; Deben aparecer entre comillas ; en los valores de parámetros type := discrete-type / composite-type value := token / quoted-string version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT x-token := N.Freed Seguimiento de Estándar [Pág. 32]