Network Working Group N. Freed Request for Comments: 2046 Innosoft Obsoletes: 1521, 1522, 1590 N.Borenstein Category: Standards Track First Virtual November 1996 Extensiones Multipropósito al Correo de Internet (MIME) Segunda Parte: Tipos de Contenido Estatus 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. El documento inicial de este conjunto, RFC 2045, especifica las N.Freed Seguimiento de Estándar [Pág. 1] RFC 2046 MIME: Segunda Parte Noviembre 1996 distintas cabeceras utilizadas para describir la estructura de los mensajes MIME. Este segundo documento 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. Definición de Tipo de Contenido de Nivel Máximo ...... 4 3. Introducción a los Tipos de Contenido iniciales de Nivel Máximo ......................................... 4 4. Tipos de Contenido Simples ........................... 6 4.1 Tipo de Contenido "Text" (texto) .................... 6 4.1.1 Representación de saltos de línea ................. 7 4.1.2 Parámetro "charset" (conjunto de caracteres) ...... 8 4.1.3 Subtipo "plain" (tal-cual) ........................ 11 4.1.4 Subtipos no reconocidos ........................... 12 4.2 Tipo de Contenido "image" (imagen) .................. 12 4.3 Tipo de Contenido "audio" (audio) ................... 12 4.4 Tipo de Contenido "video" (video) ................... 13 4.5 Tipo de Contenido "application" (aplicación) ........ 13 4.5.1 Subtipo "octet-stream" (flujo de octetos) ......... 14 4.5.2 Subtipo "PostScript" .............................. 15 4.5.3 Otros subtipos "application" ...................... 18 5. Tipos de Contenido Compuestos ........................ 18 5.1 Tipo de Contenido "multipart" (multiparte: múltiples partes) ....................... 18 5.1.1 Sintaxis común .................................... 20 5.1.2 Manejo de Mensajes y Multipartes anidados ......... 25 5.1.3 Subtipo "mixed" (mezclado) ........................ 26 5.1.4 Subtipo "alternative" (alternativo) ............... 26 5.1.5 Subtipo "digest" (compendio) ...................... 28 5.1.6 Subtipo "parallel" (paralelo) ..................... 29 5.1.7 Otros subtipos "multipart" ........................ 29 N.Freed Seguimiento de Estándar [Pág. 2] RFC 2046 MIME: Segunda Parte Noviembre 1996 5.2 Tipo de Contenido "message" (mensaje) ............... 30 5.2.1 Subtipo RFC822 .................................... 30 5.2.2 Subtipo "partial" (parcial) ....................... 31 5.2.2.1 Fragmentación de mensajes y reensamblado ........ 32 5.2.2.2 Ejemplo de fragmentación y reensamblado ......... 33 5.2.3 Subtipo "external-body" (cuerpo externo) .......... 34 5.2.4 Otros subtipos "message" .......................... 42 6. Valores de Tipo de Contenido Experimentales .......... 42 7. Sumario .............................................. 43 8. Consideraciones de Seguridad ......................... 43 9. Direcciones de los autores ........................... 43 A. Compendio de Gramática ............................... 44 1. Introducción El primer documento de este conjunto, RFC 2045, define varios campos de cabecera, incluyendo el Content-Type. El campo Content-Type se usa para especificar la naturaleza de la información en el cuerpo de una entidad MIME, por medio de los identificadores de tipo y subtipo de contenido, y dando información complementaria que pueda ser necesaria para determinados tipos de contenido. Después de los nombres de tipo y subtipo, el resto del campo de cabecera es simplemente un conjunto de parámetros, especificados con notación atributo/valor. El orden de los parámetros no es significativo. En general, el tipo de contenido de nivel máximo se utiliza para declarar el tipo general de los datos, mientras que el subtipo especifica un formato para ese tipo de datos. Así, un tipo de contenido "image/xyz" es suficiente para indicar al agente de usuario que los datos son una imagen, incluso si el agente de usuario no conoce el formato de imagen específico "xyz". Dicha información puede utilizarse, por ejemplo, para decidir si mostrar o no al usuario los datos en bruto de un subtipo no reconocido -- dicha acción podría ser razonable para subtipos no reconocidos de "text", pero no para subtipos no reconocidos de "image" o "audio". Por esta razón, los subtipos registrados de "text", "image", "audio" y "video" no deben contener información incrustada que sea de otro tipo diferente. Esos formatos combinados serán representados utilizando los tipos "multipart" o "application". Los parámetros son modificadores del subtipo de contenido, y como tales no afectan fundamentalmente a la naturaleza del contenido. El conjunto de parámetros significativos depende del tipo y subtipo de contenido. La mayoría de los parámetros se asocian con un único subtipo específico. De todas formas, un contenido de nivel máximo puede definir parámetros aplicables a cualquier subtipo de él. Los parámetros pueden ser obligatorios para el tipo o subtipo que los N.Freed Seguimiento de Estándar [Pág. 3] RFC 2046 MIME: Segunda Parte Noviembre 1996 define o pueden ser opcionales. Las implementaciones de MIME deben ignorar cualquier parámetro cuyo nombre no reconozcan. El mecanismo MIME de campo de cabecera Content-Type y tipo de contenido ha sido cuidadosamente diseñado para ser ampliable, y se espera que el conjunto de pares tipo/subtipo y sus parámetros asociados crezca significativamente con el tiempo. Otras características de MIME, como las codificaciones para transferencia del contenido y tipos de acceso "message/external-body", es probable que con el tiempo tengan nuevos valores definidos. Para asegurar que el conjunto de estos valores se desarrolla de una forma ordenada, bien especificada y pública, MIME establece un proceso de registro que utiliza IANA (Internet Assigned Numbers Authority: Autoridad de Números Asignados de Internet) como central de registro para las diversas áreas de ampliación de MIME. El proceso de registro para estas áreas se describe en un documento de acompañamiento, RFC 2048. Los siete tipos de contenido estándar de nivel máximo iniciales se definen y describen en el resto de este documento. 2. Definición de Tipo de Contenido de Nivel Máximo La definición de un tipo de contenido de nivel máximo consiste en: (1) un nombre y una descripción del tipo, incluyendo los criterios por los cuales un tipo concreto se clasificaría bajo ese tipo, (2) los nombres y definiciones de los parámetros, si existen, definidos para todos los subtipos de ese tipo (incluyendo si dichos parámetros son obligatorios u opcionales), (3) cómo un agente de usuario y/o una pasarela deben tratar subtipos desconocidos de ese tipo, (4) consideraciones generales en el transporte de entidades de este tipo de nivel máximo, si las hay, y (5) cualquier restricción en content-transfer-encodings para entidades de este tipo de nivel máximo. 3. Introducción a los Tipos de Contenido iniciales de Nivel Máximo Los cinco tipos de contenido simples de nivel máximo son: (1) text -- información de texto. En particular, el subtipo N.Freed Seguimiento de Estándar [Pág. 4] RFC 2046 MIME: Segunda Parte Noviembre 1996 "plain" indica texto plano que no contiene comandos de formateado o directivas de ninguna clase. El texto plano está pensado para ser mostrado "tal-cual". No se requiere ningún software especial para obtener el significado completo del texto, aparte del soporte para el conjunto de caracteres indicado. Otros subtipos son para utilizarlos con texto enriquecido en formularios en los que el software de aplicación puede realzar la apariencia del texto, pero dicho software no debe ser necesario para obtener la idea general del contenido. Subtipos posibles de "text" por tanto incluyen cualquier formato de procesador de textos que pueda ser leído sin recurrir a software que entienda el formato. En particular, formatos que empleen información binaria de formateado incrustada no son considerados directamente legibles. Un subtipo muy simple y portable, "richtext", se definió en RFC 1341, con una revisión posterior en RFC 1896 bajo el nombre "enriched". (2) image -- datos de imagen. "Image" precisa un dispositivo de visualización (tal como un monitor gráfico, una impresora gráfica, o una máquina de FAX) para ver la información. Se define un subtipo inicial para el ampliamente utilizado formato de imagen JPEG. Se definen subtipos para dos formatos de imagen ampliamente usados, jpeg y gif. (3) audio -- datos de audio. "Audio" precisa un dispositivo de salida de audio (tal como un altavoz o un teléfono) para "mostrar" los contenidos. Un subtipo inicial "basic" se define en este documento. (4) video -- datos de video. "Video" necesita la capacidad de mostrar imágenes en movimiento, lo que incluye normalmente hardware y software especializado. Un subtipo inicial "mpeg" se define en este documento. (5) application -- algún otro tipo de datos, normalmente o datos binarios sin interpretar o información para ser procesada por una aplicación. El subtipo "octet-stream" es para ser usado en el caso de datos binarios sin interpretar, en cuyo caso la acción recomendada más sencilla es ofrecer al usuario el escribir la información en un fichero. También se define el subtipo "PostScript" para el transporte de material PostScript. Otros usos previsibles para "application" incluyen hojas de cálculo, datos para sistemas de planificación basados en correo, y lenguajes para mensajería "activa" (computacional), y formatos de procesamiento de textos que no sean legibles directamente. Téngase en cuenta que pueden existir consideraciones de seguridad para algunos N.Freed Seguimiento de Estándar [Pág. 5] RFC 2046 MIME: Segunda Parte Noviembre 1996 tipos de datos "application", principalmente "application/PostScript" y cualquier tipo de mensajería activa. Los dos tipos de contenido compuestos de nivel máximo son: (1) multipart -- datos consistentes en multiples entidades de tipos de datos independientes. Inicialmente se definen cuatro subtipos, que incluyen el subtipo básico "mixed" para el conjunto general de partes mezcladas, "alternative" para representar los mismos datos en múltiples formatos, "parallel" para partes que se pretenda que se vean simultáneamente, y "digest" para entidades multiparte en las que cada parte tiene un tipo por defecto de "message/rfc822". (2) message -- un mensaje encapsulado. El cuerpo de un tipo de contenido "message" es él mismo todo o parte de algún tipo de objeto mensaje. Dichos objetos pueden o no contener otras entidades. El subtipo "rfc822" se utiliza cuando el contenido encapsulado es un mensaje RFC 822. El subtipo "partial" se define para mensajes RFC 822 parciales, para permitir la transmisión fragmentada de cuerpos que se crea que son demasiado grandes para pasar a través de elementos de transporte en una pieza. Otro subtipo, "external-body", se define para especificar cuerpos grandes por referencia a una fuente de datos externa. Deberá tenerse en cuenta que la lista de valores de tipo de contenido dada aquí puede aumentar con el tiempo, a través de los mecanismos descritos más arriba, y que el conjunto de subtipos se espera que crezca sustancialmente. 4. Tipos de Contenido Simples Cinco de los siete tipos de contenido iniciales se refieren a cuerpos simples. El contenido de estos tipos debe ser manejado por mecanismos no-MIME; son opacos a procesadores MIME. 4.1 Tipo de Contenido "Text" (texto) El tipo de contenido "text" está pensado para enviar material formado como texto principalmente. Un parámetro "charset" se puede usar para indicar el conjunto de caracteres del cuerpo de texto para subtipos de "text", principalmente para el subtipo "text/plain", el cual es un subtipo genérico para texto plano. El texto plano no proporciona ni permite comandos de formateo, especificaciones de atributos de fuentes, instrucciones de procesado, directivas de interpretación, o N.Freed Seguimiento de Estándar [Pág. 6] RFC 2046 MIME: Segunda Parte Noviembre 1996 marcado del contenido. El texto plano se interpreta simplemente como una secuencia lineal de caracteres, posiblemente interrumpidas por saltos de línea o saltos de página. El texto plano puede permitir el apilamiento de varios caracteres en la misma posición en el texto. El texto plano en escrituras como el Arabe y Hebreo puede también incluir añadidos que permitan el mezclado arbitrario de segmentos de texto con direcciones opuestas de escritura. Aparte del texto plano, hay muchos formatos para representar lo que podría conocerse como "texto rico". Una característica de muchas de esas representaciones es que son hasta cierto punto legibles incluso sin el software que las interpreta. Es útil, entonces, distinguirlas, en el nivel máximo, de datos ilegibles como imágenes, sonido, o texto representado de forma ilegible. En ausencia del software apropiado de interpretación, es razonable mostrar los subtipos "text" al usuario, mientras que no es razonable hacer eso con la mayoría de datos no de texto. Estos datos de texto formateado se representarán utilizando subtipos de "text". 4.1.1 Representación de saltos de línea La forma canónica de cualquier subtipo "text" de MIME DEBE siempre representar un salto de línea como una secuencia CRLF. De igual forma, cualquier ocurrencia de CRLF en "text" de MIME DEBE representar un salto de línea. El uso de CR y LF fuera de secuencias de salto de línea está también prohibido. Esta regla se aplica independientemente del formato o conjunto de caracteres (uno o varios) involucrados. NOTA: La adecuada interpretación de saltos de línea cuando se muestra el cuerpo depende del tipo de contenido. En particular, mientras que es apropiado tratar un salto de línea como una transición a una nueva línea cuando se muestra un cuerpo "text/plain", este tratamiento es en realidad incorrecto con otros subtipos de "text" como "text/enriched" [RFC-1896]. De igual forma, el que los saltos de línea deban ser añadidos o no mientras se muestran los datos está también en función del tipo de contenido. No sería necesario añadir ningún salto de línea para mostrar correctamente "text/plain", mientras que para mostrar "text/enriched" de forma adecuada se requiere la adición de saltos de línea apropiados. NOTA: Algunos protocolos definen una longitud máxima de línea. P.ej. SMTP [RFC-821] permite un máximo de 998 octetos antes de la siguiente ocurrencia de la secuencia CRLF. Para ser transportado por tales protocolos, los datos que incluyan segmentos demasiado largos sin secuencias CRLF deben ser codificados con el content-transfer- encoding apropiado. N.Freed Seguimiento de Estándar [Pág. 7] RFC 2046 MIME: Segunda Parte Noviembre 1996 4.1.2 Parámetro "charset" (conjunto de caracteres) Un parámetro crítico que se puede especificar en el campo Content- Type para datos "text/plain" es el conjunto de caracteres. Esto se especifica con un parámetro "charset", como en: Content-type: text/plain; charset=iso-8859-1 Al contrario que otros valores de parámetros, los valores del parámetro charset NO son sensibles a mayúsculas. El conjunto de caracteres por defecto, el cual se debe asumir en ausencia del parámetro charset, es US-ASCII. La especificación de cualquier futuro subtipo de "text" debe especificar si también utilizará un parámetro "charset" o no, y también puede posiblemente restringir sus valores. Para otros subtipos de "text" aparte de "text/plain", la semántica del parámetro "charset" debería ser definida de idéntica forma a la especificada aquí para "text/plain", es decir, el cuerpo consiste enteramente en caracteres del conjunto de caracteres dado. En concreto, los definidores de futuros subtipos "text" deberán poner especial atención en las implicaciones de los conjuntos de caracteres multioctetos con respecto a sus definiciones de subtipos. El parámetro charset para subtipos de "text" da un nombre de un conjunto de caracteres, tal y como se define "conjunto de caracteres" en RFC 2045. Las reglas en lo que se refiere a saltos de línea detalladas en la sección anterior deben también ser respetadas -- un conjunto de caracteres cuya definición no sea acorde con estas reglas no puede ser usado en un subtipo "text" de MIME. Se puede encontrar una lista inicial de nombres de conjuntos de caracteres predefinidos al final de esta sección. Conjuntos adicionales de caracteres pueden ser registrados con IANA. Otros tipos de contenido aparte de los subtipos de "text" podrían elegir emplear el parámetro charset como aquí se define, pero sin la restricción de CRLF/salto de línea. Por tanto, todos los conjuntos de caracteres conformes con la definición general de "conjunto de caracteres" de RFC 2045 se pueden registrar para utilizar con MIME. Nótese que si el conjunto de caracteres especificado incluye caracteres de 8-bit y dichos caracteres se usan en el cuerpo, es necesario un campo de cabecera Content-Transfer-Encoding y la correspondiente codificación de los datos para transmitir el cuerpo mediante algunos protocolos de transporte, como el SMTP [RFC-821]. El conjunto de caracteres por defecto, US-ASCII, ha sido objeto de N.Freed Seguimiento de Estándar [Pág. 8] RFC 2046 MIME: Segunda Parte Noviembre 1996 confusión y ambigüedad en el pasado. No sólo había algunas ambigüedades en la definición, sino que ha habido amplias variaciones en la práctica. Con objeto de eliminar dichas ambigüedades y variaciones en el futuro, se recomienda encarecidamente que los nuevos agentes de usuario especifiquen explícitamente un conjunto de caracteres como parámetro de tipo de contenido en el campo de cabecera Content-Type. "US-ASCII" no indica un conjunto de caracteres arbitrario de 7-bit, sino que especifica que todos los octetos del cuerpo deben ser interpretados como caracteres de acuerdo al conjunto de caracteres US-ASCII. Las versiones nacionales y específicas de aplicaciones de ISO 646 [ISO-646] normalmente NO son idénticas a US- ASCII, y en ese caso su uso en correo Internet está explícitamente desaconsejado. La omisión del conjunto de caracteres ISO 646 en este documento es deliberada en lo que a esto respecta. El nombre de conjunto de caracteres "US-ASCII" explícitamente se refiere al conjunto de caracteres definido en ANSI X3.4-1986 [US-ASCII]. La nueva versión internacional de referencia (IRV: International Reference Version) de la edición de 1991 de ISO 646 es idéntica a US- ASCII. El nombre de conjunto de caracteres "ASCII" está reservado y no debe ser utilizado con ningún propósito. NOTA: RFC 821 especifica explícitamente "ASCII", y remite a una versión temprana del American Standard. En tanto que uno de los propósitos de especificar un tipo de contenido y un conjunto de caracteres es para permitir al receptor determinar sin ambigüedades cómo el remitente pretendía que fuese interpretado el mensaje, asumir otra cosa que no sea "ASCII estricto" por defecto sería arriesgarse a cambios inintencionados e incompatibles con la semántica de los mensajes que se transmiten. Esto también implica que los mensajes que contengan caracteres codificados de acuerdo a otras versiones de ISO 646, que no sean US-ASCII ni 1991 IRV, o que utilicen procesos de intercambio de códigos (code-switching, p.ej. los de ISO 2022), así como codificaciones de caracteres de 8bit o de múltiples octetos DEBEN usar una especificación de conjunto de caracteres apropiada coherente con MIME. El conjunto de caracteres completo US-ASCII está listado en ANSI X3.4-1986. Nótese que los caracteres de control incluyendo DEL (0-31, 127) no tienen significado definido con la excepción de la combinación CRLF (los valores US-ASCII 13 y 10), indicadores de nueva línea. Dos de los caracteres tienen un significado "de facto" ampliamente utilizado: FF (12) a menudo significa "empieza el texto siguiente en el principio de una nueva página"; y TAB o HT (9) con frecuencia (aunque no siempre) significa "mueve el cursor a la siguiente columna disponible después de la posición actual donde el número de columna sea un múltiplo de 8 (contando la primera columna como 0)". Al margen de estas convenciones, cualquier uso de caracteres de control o DEL en el cuerpo debe ocurrir en cualquiera de los dos N.Freed Seguimiento de Estándar [Pág. 9] RFC 2046 MIME: Segunda Parte Noviembre 1996 supuestos siguientes: (1) porque un subtipo de "text" distinto a "plain" específicamente asigne algún significado adicional, o (2) dentro del contexto de un acuerdo privado entre el remitente y el destinatario. Estos acuerdos privados se desaconsejan y deberían ser reemplazados por las otras capacidades de este documento. NOTA: Existe una proliferación enorme de conjuntos de caracteres aparte del US-ASCII. Un gran número de conjuntos de caracteres parcial o totalmente solapados NO es buena cosa. Un UNICO conjunto de caracteres que pudiera ser usado universalmente para representar todos los lenguajes del mundo en el correo Internet sería preferible. Desafortunadamente, la práctica existente en diversas comunidades parece apuntar al uso continuado de múltiples conjuntos de caracteres en un futuro cercano. Un pequeño número de conjunto de caracteres estándar son, por lo tanto, definidos para el uso en Internet en este documento. Los valores definidos de "charset" son: (1) US-ASCII -- como se define en ANSI X3.4-1986 [US-ASCII] (2) ISO-8859-X -- donde "X" se sustituirá, según sea necesario, por las partes de ISO-8859 [ISO-8859]. Nótese que los conjuntos de caracteres ISO 646 han sido omitidos deliberadamente en favor de sus sustitutos 8859, los cuales son los conjuntos de caracteres designados para correo Internet. A la publicación de este documento, los valores legítimos de "X" son los dígitos del 1 al 10. Los caracteres en el rango 128-159 no tienen significado asignado en ISO-8859-X. Los caracteres con valores por debajo de 128 en ISO-8859-X tienen el mismo significado asignado que en US-ASCII. La parte 6 de ISO 8859 (alfabeto Latino/Arabe) y la parte 8 (alfabeto Latino/Hebreo) incluyen ambas caracteres para los cuales la dirección normal de escritura es de derecha a izquierda y caracteres para los cuales es de izquierda a derecha, pero no definen un método de ordenación canónico para representar texto bidireccional. Los valores de charset "ISO-8859-6" y "ISO-8859-8", así y todo, especifican que se utiliza el método visual [RFC-1556]. Todos estos conjuntos de caracteres se usan como conjuntos puros de 7bit u 8bit sin ninguna función de cambio o escape. El significado de las secuencias de cambio y de escape en estos conjuntos de caracteres N.Freed Seguimiento de Estándar [Pág. 10] RFC 2046 MIME: Segunda Parte Noviembre 1996 no están definidas. Los conjuntos de caracteres especificados arriba son los únicos relativamente no controvertidos durante la redacción de MIME. Este documento no respalda el uso de ningún conjunto de caracteres en particular aparte del US-ASCII, y reconoce que la evolución futura del mundo de los conjuntos de caracteres continúa poco clara. Nótese que el conjunto de caracteres utilizado, si es distinto del US-ASCII, debe siempre ser explícitamente especificado en el campo Content-Type. Ningún nombre de conjunto de caracteres diferente a los definidos arriba puede ser utilizado en correo Internet sin la publicación de una especificación formal y su registro con IANA, o sin acuerdo privado, en cuyo caso el nombre del conjunto de caracteres debe comenzar con "X-". Se desaconseja a los implementadores el definir nuevos conjuntos de caracteres a no ser que sea absolutamente necesario. El parámetro "charset" ha sido definido en primer lugar con el propósito de datos de texto, y se describe en esta sección por esa razón. De todas formas, es concebible que datos no de texto pudieran también desear especificar un valor de "charset" con algún propósito, en cuyo caso deberán ser utilizados la misma sintaxis y los mismos valores. En general, el software de composición debería usar siempre el "mínimo denominador común" del conjunto de caracteres posible. Por ejemplo, si un cuerpo contiene sólo caracteres US-ASCII, DEBERIA ser marcado que está en el conjunto de caracteres US-ASCII, no en ISO-8859-1, el cual, como el resto de la familia ISO-8859 de conjuntos de caracteres, es un superconjunto de US-ASCII. Más en general, si un conjunto de caracteres ampliamente utilizado es un subconjunto de otro conjunto de caracteres, y el cuerpo contiene sólo caracteres del subconjunto ampliamente utilizado, debería ser marcado como que está en ese subconjunto. Esto incrementará las posibilidades de que el receptor pueda ver correctamente la entidad resultante. 4.1.3 Subtipo "plain" (tal-cual) El subtipo más simple y más importante de "text" es "plain". Este indica texto plano que no contiene ningún comando de formateado o directivas. El texto plano está pensado para ser mostrado "tal cual", es decir, no será necesario interpretar comandos incrustados de formateado, especificaciones de atributos de fuentes, instrucciones N.Freed Seguimiento de Estándar [Pág. 11] RFC 2046 MIME: Segunda Parte Noviembre 1996 de proceso, directivas de interpretación, o marcado de contenido, para mostrarlo de forma adecuada. El tipo de contenido por defecto para correo Internet "text/plain" describe la práctica actual en Internet. Es decir, es el tipo de cuerpo definido por RFC 822. Ningún otro subtipo de "text" se define en este documento. 4.1.4 Subtipos no reconocidos Subtipos no reconocidos de "text" deberán ser tratados como el subtipo "plain" siempre y cuando la implementación de MIME sepa cómo manejar el conjunto de caracteres. Subtipos no reconocidos que además especifiquen un conjunto de caracteres no reconocido deberán ser tratados como "application/octet-stream". 4.2 Tipo de Contenido "image" (imagen) Un tipo de contenido "image" indica que el cuerpo contiene una imagen. Los nombres de subtipo especifican el formato de la imagen. Estos nombres no son sensibles a mayúsculas. Un subtipo inicial es "jpeg" para el formato JPEG con la codificación JFIF [JPEG]. La lista de subtipos "image" dada aquí no es ni exclusiva ni exhaustiva, y se espera que crezca al registrar nuevos tipos con IANA, como se describe en RFC 2048. Subtipos no reconocidos de "image" deberán, como mínimo, ser tratados como "application/octet-stream". La implementaciones pueden opcionalmente optar por pasar subtipos de "image" que no reconozcan específicamente a una aplicación de visualización de imágenes de propósito general segura y robusta, si dicha aplicación está disponible. NOTA: El uso de esta manera de una aplicación de visualización de imágenes de propósito general hereda los problemas de seguridad del tipo más peligroso soportado por la aplicación. 4.3 Tipo de Contenido "audio" (audio) Un tipo de contenido "audio" indica que el cuerpo contiene datos de audio. Aunque no hay todavía un consenso en cuanto al formato de audio "ideal" para utilizar con ordenadores, existe una necesidad perentoria de un formato capaz de ofrecer un funcionamiento interoperable. El subtipo inicial "basic" se especifica para alcanzar este requerimiento mediante un absolutamente mínimo común denominador formato de audio. Se espera que formatos más ricos para más alta N.Freed Seguimiento de Estándar [Pág. 12] RFC 2046 MIME: Segunda Parte Noviembre 1996 calidad y/o menor ancho de banda de audio se definan en un documento posterior. El contenido del subtipo "audio/basic" es un único canal de audio codificado utilizando ISDN mu-law [PCM] de 8bit a una frecuencia de muestreo de 8000 Hz. Subtipos no reconocidos de "audio" deberán como mínimo ser tratados como "application/octet-stream". Las implementaciones pueden optar opcionalmente por pasar subtipos de "audio" que no reconozcan a una aplicación de reproducción de sonido robusta, si dicha aplicación está disponible. 4.4 Tipo de Contenido "video" (video) Un tipo de contenido "video" indica que el cuerpo contiene una imagen de cuadros variables con el tiempo, posiblemente en color y con sonido coordinado. El término 'video' se utiliza en su más amplio sentido, en vez de asociarlo con un formato o tecnología en particular, y no pretende excluir subtipos como ilustraciones animadas codificadas de forma compacta. El subtipo "mpeg" se refiere al video codificado de acuerdo al estándar MPEG [MPEG]. Nótese que aunque en general este documento desaconseja encarecidamente la mezcla de múltiples datos en un cuerpo simple, se reconoce que muchos, así llamados, formatos de video incluyen una representación de sonido sincronizado, y esto está específicamente permitido para subtipos de "video". Subtipos no reconocidos de "video" deberán como mínimo ser tratados como "application/octet-stream". Las implementaciones pueden optar opcionalmente por pasar subtipos de "video" que no reconozcan a una aplicación de reproducción de video robusta, si dicha aplicación está disponible. 4.5 Tipo de Contenido "application" (aplicación) El tipo de contenido "application" es para utilizarlo con datos que no casen en ninguna de las otras categorías, y particularmente con datos para ser procesados por algún tipo de programa de aplicación. Esta es información que debe ser procesada por una aplicación antes de ser visualizada o utilizada por el usuario. Los usos esperados del tipo de contenido "application" incluyen transferencia de ficheros, hojas de cálculo, datos para sistemas de planificación basados en correo, y lenguajes para material "activo" (computacional). (Esto último, en particular, puede plantear problemas de seguridad que deben ser comprendidos por los implementadores, y que se exponen con N.Freed Seguimiento de Estándar [Pág. 13] RFC 2046 MIME: Segunda Parte Noviembre 1996 detalle en la discusión del tipo de contenido "application/PostScript"). Por ejemplo, un planificador de citas podría definir una representación estándar para información relativa a fechas de citas propuestas. Un agente de usuario inteligente usaría esta información para dirigir un diálogo con el usuario, y podría entonces enviar material adicional basado en ese diálogo. Más en general, ha habido varios lenguajes para mensajería "activa" desarrollados en los cuales programas en un lenguaje convenientemente especializado son transportados a destinos remotos y ejecutados automáticamente en el entorno del receptor. Dichas aplicaciones pueden ser definidas como subtipos del tipo de contenido "application". Este documento define dos subtipos: octet-stream, y PostScript. El subtipo de "application" será a menudo o bien el nombre o bien incluirá parte del nombre de la aplicación para la cual están proyectados los datos. Esto no significa, de todas formas, que cualquier nombre de programa de aplicación pueda ser libremente usado como subtipo de "application". 4.5.1 Subtipo "octet-stream" (flujo de octetos) El subtipo "octet-stream" se usa para indicar que el cuerpo contiene datos binarios arbitrarios. El conjunto de parámetros actualmente definidos es: (1) TYPE (tipo) -- el tipo general o categoría de los datos binarios. Está enfocado como información para el receptor humano en vez de para ningún proceso automático. (2) PADDING (relleno) -- el número de bits de relleno que hayan sido añadidos al flujo de bits que forman los contenidos para producir los datos de bytes completos de 8bit. Esto es útil para encerrar un flujo de datos en un cuerpo cuando el número total de bits no es un múltiplo de 8. Ambos parámetros son opcionales. Un parámetro adicional, "CONVERSIONS" (conversiones), fue definido en RFC 1341 pero ha sido eliminado desde entonces. RFC 1341 también definía el uso de un parámetro "NAME" que tenía el nombre de fichero sugerido para usarlo si los datos iban a ser escritos a un fichero. Esto ha sido desaprobado anticipando un campo de cabecera separado N.Freed Seguimiento de Estándar [Pág. 14] RFC 2046 MIME: Segunda Parte Noviembre 1996 Content-Disposition, a definir en una RFC posterior. La acción recomendada para una aplicación que reciba una entidad "application/octet-stream" es simplemente ofrecer el poner los datos en un fichero, sin deshacer ningún Content-Transfer-Encoding, o quizás usarlo como entrada a un proceso definido por el usuario. Para reducir el peligro de trasmitir programas con mala intención, se recomienda encarecidamente que las implementaciones NO implementen una búsqueda de directorio mediante la cual un programa arbitrario indicado en el parámetro Content-Type (p.ej., un parámetro "interpreter=") se encuentre y se ejecute con el cuerpo del mensaje como entrada. 4.5.2 Subtipo "PostScript" Un tipo de contenido "application/PostScript" indica un programa PostScript. Actualmente se permiten dos variantes del lenguaje PostScript; la variante original Nivel 1 se describe en [POSTSCRIPT] y la variante más reciente Nivel 2 se describe en [POSTSCRIPT2]. PostScript es una marca registrada de Adobe Systems, Inc. El uso del tipo de contenido MIME "application/PostScript" implica el reconocimiento de la marca y de todos los derechos que conlleva. La definición del lenguaje PostScript proporciona capacidades para el etiquetado interno de las características específicas del lenguaje que utilice un programa dado. Este etiquetado, denominado convenciones de estructuración de documento PostScript, o DSC (document structuring conventions), es muy general y ofrece sustancialmente más información que sólo el nivel del lenguaje. El uso de convenciones de estructuración de documentos, aunque no obligatorio, se recomienda encarecidamente en aras de la interoperabilidad. Los documentos que carezcan de las convenciones de estructuración adecuadas no pueden ser probados para ver si funcionan o no en un entorno determinado. De esa forma, algunos sistemas pueden asumir lo peor y rechazar el procesar un documento no estructurado. La ejecución de intérpretes PostScript de propósito general conlleva serios riesgos de seguridad, y no se recomienda a los implementadores que simplemente envíen cuerpos PostScript a intérpretes externos. Aunque es habitualmente seguro enviar PostScript a una impresora, donde el daño potencial se ciñe a los entornos típicos de impresora, los implementadores deberían considerar todo lo siguiente antes de añadir visualización interactiva de cuerpos PostScript a sus lectores MIME. El resto de esta sección reseña algunos, aunque probablemente no N.Freed Seguimiento de Estándar [Pág. 15] RFC 2046 MIME: Segunda Parte Noviembre 1996 todos, de los problemas posibles con el transporte de entidades PostScript. (1) Las operaciones peligrosas en el lenguaje PostScript incluyen, pero pueden no estar limitadas a, los operadores PostScript "deletefile", "renamefile", "filenameforall", y "file". "File" sólo es peligroso cuando se aplica a algo distinto de la entrada o salida estándar. Las implementaciones pueden también definir operadores de fichero no estándar; esto puede suponer una amenaza a la seguridad. "Filenameforall", el operador comodín de búsqueda de ficheros, puede parecer a primera vista que no puede causar daño. Nótese, sin embargo, que este operador potencialmente puede revelar información acerca de a qué ficheros el receptor tiene acceso, y esta información en sí puede ser delicada. Los remitentes de mensajes deberían evitar el uso de operadores de fichero potencialmente peligrosos, dado que estos operadores muy probablemente no estarán disponibles en implementaciones PostScript seguras. El software de recepción y visualizado de mensajes debería o desactivar completamente todos los operadores de fichero potencialmente peligrosos o poner especial cuidado en no delegar ninguna autoridad especial a su operación. Estos operadores deberían ser vistos al interpretar documentos PostScript como si estuvieran hechos por un agente externo. El desactivado y/o comprobación debería ser hecho fuera del alcance del lenguaje PostScript en sí mismo; debería ponerse cuidado en asegurar que no exista un método para la reactivación de versiones completamente funcionales de estos operadores. (2) El lenguaje PostScript proporciona capacidades para salir del bucle del intérprete normal o del servidor. Los cambios hechos en este entorno "exterior" normalmente se conservan a través de los documentos, y en muchos casos pueden ser conservados semipermanentemente en memoria no volátil. Los operadores asociados con la salida del bucle de intérprete pueden potencialmente interferir en el procesado de documentos posteriores. Por tanto, su uso indiscriminado constituye una amenaza de negación de servicio. Los operadores PostScript que salen del bucle del intérprete incluyen, pero pueden no estar limitados a, los operadores "exitserver" y "startjob". El software de envío de mensajes no debería generar PostScript que dependa de la salida del bucle del intérprete para funcionar, dado que la capacidad de salir probablemente no esté disponible en implementaciones PostScript seguras. El software de recepción y visualizado de mensajes debería desactivar completamente la capacidad de retener cambios en el entorno PostScript eliminando o N.Freed Seguimiento de Estándar [Pág. 16] RFC 2046 MIME: Segunda Parte Noviembre 1996 desactivando las operaciones "startjob" y "exitserver". Si estas operaciones no pudieran se eliminadas o completamente desactivadas, la contraseña asociada a ellas debería ser como mínimo un valor difícil de adivinar. (3) PostScript proporciona operadores para establecer parámetros de sistema y específicos de dispositivo. Estos valores de parámetros pueden ser conservados a través de trabajos y pueden potencialmente suponer una amenaza al correcto funcionamiento del intérprete. Los operadores PostScript que establecen parámetros de sistema y de dispositivo incluyen, pero pueden no estar limitados a, los operadores "setsystemparams" y "setdevparams". El software de envío de mensajes no debería generar PostScript que dependiese de los valores de parámetros de sistema o de dispositivo para funcionar correctamente. La capacidad de establecer estos parámetros probablemente no estará disponible en implementaciones PostScript seguras. El software de recepción y visualizado de mensajes debería desactivar la capacidad de cambiar los parámetros de sistema y de dispositivos. Si estos operadores no pudieran ser completamente desactivados la contraseña asociada a ellos debería ser como mínimo un valor difícil de adivinar. (4) Algunas implementaciones PostScript proporcionan capacidades no estándar para la carga directa y ejecución de código máquina. Dichas capacidades están claramente abiertas a un abuso considerable. El software de envío de mensajes no debería hacer uso de esas características. Al margen de ser totalmente específicas del hardware, también es muy probable que no estén disponibles en implementaciones PostScript seguras . El software de recepción y visualizado de mensajes no debería permitir el uso de dichos operadores si existen. (5) PostScript es un lenguaje extensible, y muchas, si no la mayoría, de sus implementaciones proporcionan numerosas extensiones propias. Este documento no trata estas extensiones dado que constituyen un factor desconocido. El software de envío de mensajes no debería hacer uso de extensiones no estándar; probablemente no existirán en algunas implementaciones. El software de recepción y visualizado de mensajes debería comprobar que cualquier operador PostScript no estándar es seguro y que no supone ningún tipo de amenaza. (6) Es posible escribir PostScript que consuma enormes cantidades de recursos del sistema. También es posible escribir programas PostScript que se queden en un bucle indefinido. N.Freed Seguimiento de Estándar [Pág. 17] RFC 2046 MIME: Segunda Parte Noviembre 1996 Ambos tipos de programas tienen el potencial de causar daños a receptores confiados. El software de envío de mensajes debería evitar la construcción y difusión de dichos programas, que son antisociales. El software de recepción y visualizado de mensajes debería proporcionar mecanismos apropiados para abortar el procesado después de que haya pasado un lapso de tiempo razonable. Además, los intérpretes PostScript deberían estar limitados al consumo de una cantidad razonable de cualquier recurso de sistema dado. (7) Es posible incluir información binaria en bruto dentro de PostScript de diversas formas. No está recomendado usarlo en correo Internet, tanto porque no está soportado por todos los intérpretes PostScript, como porque complica de forma significativa el uso de Content-Transfer-Encoding de MIME. (Sin esos datos binarios, PostScript puede ser visto normalmente como datos basados en líneas. El tratamiento de secuencias CRLF se torna extremadamente problemático si se mezclan datos binarios y basados en líneas en un mismo flujo de datos PostScript). (8) Finalmente, pueden existir errores en algunos intérpretes PostScript que podrían posiblemente ser aprovechados para conseguir acceso no autorizado al sistema del receptor. Aparte de hacer constar esta posibilidad, no hay acción específica que se pueda tomar para prevenirlo, excepto la corrección periódica de dichos errores si se encuentra alguno. 4.5.3 Otros subtipos "application" Se espera que sean definidos en el futuro muchos otros subtipos de "application". Las implementaciones MIME deben como mínimo tratar cualquier subtipo no reconocido como equivalente a "application/octet-stream". 5. Tipos de Contenido Compuestos Los dos restantes de los siete valores iniciales de Content-Type se refieren a entidades compuestas. Las entidades compuestas se manejan utilizando mecanismos MIME -- un procesador MIME normalmente maneja el cuerpo directamente. 5.1 Tipo de Contenido "multipart" (multiparte: múltiples partes) En el caso de entidades multiparte, en las cuales uno o más conjuntos diferentes de datos están combinados en un cuerpo único, debe aparecer en la cabecera de la entidad un campo de tipo de contenido N.Freed Seguimiento de Estándar [Pág. 18] RFC 2046 MIME: Segunda Parte Noviembre 1996 "multipart". El cuerpo debe contener pues una o más partes de cuerpo, cada una precedida por una línea con el delimitador, y la última seguida por una línea de cierre de delimitador. Después de su línea de delimitador, cada cuerpo consiste en un área de cabecera, una línea en blanco, y un área de cuerpo. Por tanto una parte de cuerpo es similar a un mensaje RFC 822 en su sintaxis, pero diferente en su significado. Una parte de cuerpo es una entidad y por lo tanto NO tiene que ser interpretada como si fuera un mensaje RFC 822. Para empezar, NO son necesarios campos de cabecera en partes de cuerpo. Una parte de cuerpo que empiece con una línea en blanco, por tanto, está permitida y es una parte de cuerpo para la cual se asumen todo los valores por defecto. En ese caso, la ausencia de una cabecera Content-Type normalmente indica que el cuerpo correspondiente tiene un content- type:"text/plain; charset=US-ASCII". Los únicos campos de cabecera que tienen significado definido para partes de cuerpo son aquellos cuyos nombres empiezan con "Content-". Todos los demás campos de cabecera pueden ser ignorados en partes de cuerpo. Aunque deberían ser generalmente conservados si es posible, pueden ser descartados por pasarelas si fuera necesario. Estos otros campos está permitido que aparezcan en partes de cuerpo pero no deben depender de ellos. Pueden ser creados campos "X-" con fines experimentales o privados, con el reconocimiento de que la información que contengan puede perderse en algunas pasarelas. NOTA: La distinción entre un mensaje RFC 822 y una parte de cuerpo es sutil, pero importante. Una pasarela entre Internet y correo X.400, por ejemplo, debe ser capaz de ver la diferencia entre una parte de cuerpo que contiene una imagen y una parte de cuerpo que contiene un mensaje encapsulado, el cuerpo del cual es una imagen JPEG. Para representar esto último, la parte de cuerpo debe tener "Content-Type: message/rfc822", y su cuerpo (después de la línea en blanco) debe ser la imagen encapsulada con su propio campo de cabecera "Content-Type: image/jpeg". El uso de una sintaxis similar facilita la conversión de mensajes a partes de cuerpo, y viceversa, pero la distinción entre ambos debe ser comprendida por los implementadores. (Para el caso especial en el cual las partes del cuerpo son realmente mensajes, se define también un subtipo "digest"). Como se ha hecho constar antes, cada parte de cuerpo está precedida por una línea delimitadora que contiene el delimitador. El delimitador NO DEBE aparecer dentro de una parte encapsulada, en una línea por sí mismo o como prefijo de ninguna línea. Esto implica que es crucial que el agente de composición sea capaz de elegir y especificar un valor de parámetro delimitador único que no contenga el valor del parámetro delimitador de una multiparte que la englobe N.Freed Seguimiento de Estándar [Pág. 19] RFC 2046 MIME: Segunda Parte Noviembre 1996 como prefijo. Todos los presentes y futuros subtipos de "multipart" deben usar una sintaxis idéntica. Los subtipos pueden diferir en su semántica, y pueden imponer restricciones adicionales de sintaxis, pero deben ser conformes con la sintaxis obligatoria del tipo "multipart". Este requerimiento asegura que todos los agentes que sean conformes podrán como mínimo reconocer y separar las partes de una entidad multiparte, incluso aquellas de un subtipo no reconocido. Como se establece en la definición del campo Content-Transfer- Encoding [RFC 2045], no se permite otra codificación que no sea "7bit", "8bit" o "binary" para entidades de tipo "multipart". Los delimitadores de "multipart" y los campos de cabecera se representan siempre como 7bit US-ASCII en cualquier caso (aunque los campos de cabecera pueden codificar texto de cabecera no US-ASCII mediante RFC 2047) y los datos dentro de las partes de cuerpo pueden ser codificadas parte a parte, con campos Content-Transfer-Encoding para cada parte de cuerpo. 5.1.1 Sintaxis común Esta sección define una sintaxis común para subtipos de "multipart". Todos los subtipos de "multipart" deben usar la misma sintaxis. Un ejemplo sencillo de un mensaje multiparte aparece al final de esta sección. Un ejemplo de un mensaje multiparte más complejo se da en RFC 2049. El campo Content-Type para entidades multiparte requiere un parámetro, "boundary". La línea del delimitador se define entonces como una línea que consiste únicamente en dos caracteres guión ("-", valor decimal 45) seguidos del valor del parámetro "boundary" (delimitador) del campo de cabecera Content-Type, espacios en blanco opcionales, y un CRLF al final. NOTA: Los guiones son para la compatibilidad basta con el anterior método de encapsulación de mensajes de RFC 934, y para facilitar la búsqueda de límites en alguna implementaciones. De toda formas, deberá tener en cuenta que los mensajes multiparte NO son totalmente compatibles con las encapsulaciones RFC 934; en particular, no obedecen las convenciones de RFC 934 de entrecomillado de líneas incrustadas que empiecen con guiones. Este mecanismo se ha elegido en vez del mecanismo de RFC 934 porque este último produce que las líneas se alarguen con cada nivel de entrecomillado. La combinación del efecto de estiramiento de líneas con el hecho de que las implementaciones de SMTP algunas veces parten las líneas largas hicieron que el mecanismo RFC 934 fuera inadecuado para el caso de que se deseara una estructuración multiparte con muchos niveles de N.Freed Seguimiento de Estándar [Pág. 20] RFC 2046 MIME: Segunda Parte Noviembre 1996 anidamiento. ADVERTENCIA A LOS IMPLEMENTADORES: La gramática de los parámetros del campo Content-Type es tal que a menudo es necesario encerrar el valor del parámetro "boundary" entre comillas en la línea Content-Type. No siempre es necesario, pero nunca está de más. Los implementadores deberían asegurarse de estudiar la gramática cuidadosamente para evitar producir campos Content-Type no válidos. Por tanto, un campo de cabecera Content-Type "multipart" típico podría ser como este: Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08j34c0p Pero el siguiente no es válido: Content-Type: multipart/mixed; boundary=gc0pJq0M:08jU534c0p (por los dos puntos) y debe en cambio representarse como Content-Type: multipart/mixed; boundary="gc0pJq0M:08jU534c0p" Este valor de Content-Type indica que el contenido consiste en una o más partes, cada una con una estructura que es sintácticamente idéntica a un mensaje RFC 822, excepto que el área de cabecera se permite que esté completamente vacía, y que cada parte está precedida por la línea --gc0pJq0M:08jU534c0p El delimitador DEBE aparecer al principio de la línea, es decir, a continuación de un CRLF, y este CRLF se considera que está unido a la línea del delimitador en vez de formar parte de la parte anterior. El delimitador puede estar seguido por cero o más caracteres de espacio en blanco. Se termina o bien con otro CRLF y los campos de cabecera de la siguiente parte o bien con dos CRLF, en cuyo caso no hay campos de cabecera para la siguiente parte. Si no existe campo Content-Type se asume que es un "message/rfc822" en un "multipart/digest"; en caso contrario, "text/plain". NOTA: El CRLF que precede a la línea del delimitador conceptualmente se añade al delimitador, por lo que es posible que exista una parte que no termine con un CRLF (salto de línea). Por tanto, las partes de cuerpo que se deban considerar que terminan con saltos de línea deben tener dos CRLF antes de la línea del delimitador, el primero de los cuales forma parte de la anterior parte de cuerpo, y el segundo forma parte del delimitador de encapsulamiento. Los delimitadores no deben aparecer en el material encapsulado, y no deben tener una longitud mayor de 70 caracteres, sin contar los dos N.Freed Seguimiento de Estándar [Pág. 21] RFC 2046 MIME: Segunda Parte Noviembre 1996 guiones del principio. La línea del delimitador que sigue a la última parte de cuerpo es un delimitador diferenciado que indica que no hay más partes de cuerpo a continuación. Dicha línea del delimitador es idéntica a las anteriores, con el añadido de dos guiones más después de valor del parámetro "boundary". --gc0pJq0M:08jU534c0p-- NOTA A LOS IMPLEMENTADORES: Las comparaciones de cadenas delimitadoras deben comparar el valor de delimitador con el principio de cada línea candidata. No se requiere una coincidencia exacta con la línea candidata completa; es suficiente con que el delimitador aparezca completo a continuación del CRLF. Parece haber sitio para información adicional antes de la primera línea de delimitador y a continuación de la última línea de delimitador. Generalmente, estas áreas deberían dejarse en blanco, y las implementaciones deben ignorar cualquier cosa que aparezca antes de la primera línea de delimitador o después de la última. NOTA: Estas áreas de "preámbulo" y de "epílogo" generalmente no se usan por la falta de una tipificación correcta de estas partes y la falta de una semántica clara para el manejo de estas áreas en las pasarelas, especialmente en pasarelas X.400. De todas formas, en vez de dejar las áreas de preámbulo y epílogo en blanco, muchas implementaciones MIME han encontrado que es un lugar muy conveniente para colocar notas explicativas para el receptor que lea el mensaje con software pre-MIME, dado que dichas notas son ignoradas por el software conforme a MIME. NOTA: Debido a que los delimitadores no deben aparecer en las partes de cuerpo encapsuladas, el agente de usuario debe actuar con cuidado para elegir un valor de parámetro "boundary" único. El valor de parámetro "boundary" en el ejemplo anterior podría haber sido el resultado de un algoritmo diseñado para generar delimitadores con una muy baja probabilidad de existir en los datos a encapsular sin tener que realizar una lectura previa de los datos. Otros algoritmos alternativos podrían ofrecer delimitadores más "legibles" para receptores con agentes de usuario antiguos, pero necesitarían prestar mayor atención a la posibilidad de que el delimitador pudiera aparecer al principio de alguna línea de los datos encapsulados. La línea de delimitador más sencilla posible es algo como "---", con una línea de cierre de delimitador de "-----". Como ejemplo muy sencillo, el siguiente mensaje multiparte tiene dos partes, ambas texto plano, una explícitamente tipificada y la otra N.Freed Seguimiento de Estándar [Pág. 22] RFC 2046 MIME: Segunda Parte Noviembre 1996 implícitamente tipificada: From: Nathaniel Borenstein To: Ned Freed Date: Sun, 21 Mar 1993 23:56:48 -0800 (PST) Subject: Mensaje de ejemplo MIME-Version: 1.0 Content-type: multipart/mixed; boundary="delimitador sencillo" Este es el preámbulo. Se ignorara, aunque es un sitio apropiado para que los agentes de composición incluyan una nota aclarativa para lectores no conformes a MIME. --delimitador sencillo Esto esta tipificado implícitamente como texto plano US-ASCII. NO termina con un salto de linea. --delimitador sencillo Content-type: text/plain; charset=us-ascii Esto esta tipificado explícitamente como texto plano US-ASCII. SI termina con un salto de linea. --delimitador sencillo Esto es el epilogo. Se ignorara. El uso de un tipo de contenido "multipart" en una parte de cuerpo dentro de otra entidad "multipart" se permite explícitamente. En dichos casos, por razones obvias, se debe tener cuidado para asegurarse de que cada entidad "multipart" anidada utiliza un delimitador distinto. Ver RFC 2949 para un ejemplo de entidades "multipart" anidadas. El uso del tipo de contenido "multipart" con solamente una parte de cuerpo puede ser útil en determinadas ocasiones, y se permite explícitamente. NOTA: La experiencia ha mostrado que un tipo de contenido "multipart" con una única parte de cuerpo es útil para enviar tipos de contenido no de texto. Tiene la ventaja de ofrecer el preámbulo como sitio donde incluir instrucciones de decodificación. Además, numerosas pasarelas SMTP mueven o quitan las cabeceras MIME, y un decodificador MIME inteligente podría utilizar los delimitadores multiparte incluso en ausencia de la cabecera Content-Type y por lo tanto decodificar satisfactoriamente el mensaje. El único parámetro global obligatorio para el tipo de contenido N.Freed Seguimiento de Estándar [Pág. 23] RFC 2046 MIME: Segunda Parte Noviembre 1996 "multipart" es el parámetro "boundary", consistente en de 1 a 70 caracteres de un conjunto de caracteres tenido por robusto a través de pasarelas de correo, y que NO termine en espacios en blanco. (Si una línea de delimitador termina con espacio en blanco, el espacio en blanco se debe suponer que ha sido añadido por una pasarela, y debe ser borrado). Se especifica formalmente con la siguiente BNF: boundary := 0*69 bchars := bcharsnospace / " " bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" / "_" / "," / "-" / "." / "/" / ":" / "=" / "?" En conjunto, el cuerpo de una entidad "multipart" puede ser especificado como sigue: dash-boundary := "--" boundary ; "boundary" tomado del valor ; del parámetro "boundary" del ; campo Content-Type. multipart-body := [preamble CRLF] dash-boundary transport-padding CRLF body-part *encapsulation close-delimiter transport-padding [CRLF epilogue] transport-padding := *LWSP-char ; Los compositores NO DEBEN generar ; rellenos de transporte, pero ; los receptores DEBEN poder manejar ; relleno añadido por el transporte ; del mensaje. encapsulation := delimiter transport-padding CRLF body-part delimiter := CRLF dash-boundary close-delimiter := delimiter "--" preamble := discard-text epilogue := discard-text discard-text := *(*text CRLF) *text N.Freed Seguimiento de Estándar [Pág. 24] RFC 2046 MIME: Segunda Parte Noviembre 1996 ; Puede ser ignorado o descartado body-part := MIME-part-headers [CRLF *OCTET] ; Las líneas en una parte de cuerpo no deben empezar ; con el dash-boundary especificado y el delimitador ; no debe aparecer en ningún lugar de la parte del ; cuerpo. Nótese que la semántica de una parte de ; cuerpo difiere de la semántica de un mensaje, como ; se describe en el texto. OCTET := IMPORTANTE: La libre inserción de espacios en blanco (LWSP: linear- white-spaces) y comentarios RFC 822 entre los elementos mostrados en esta gramática BNF NO está permitida dado que esta BNF no especifica un campo de cabecera estructurado. NOTA: En ciertos enclaves de transporte, las restricciones RFC 822 como la que limita el cuerpo a caracteres imprimibles US-ASCII pueden no estar en uso. (Es decir, pueden existir dominios de transporte que parezcan transportes de correo Internet estándar tal y como se especifica en RFC 821 y que asume RFC 822, pero sin ciertas restricciones). La relajación de estas restricciones podría ser interpretada como una extensión regional de la definición de cuerpos, por ejemplo para incluir octetos que no estén en el rango US-ASCII, siempre y cuando estas extensiones estén soportadas por el transporte y documentadas adecuadamente en el campo de cabecera Content- Transfer-Encoding. De todas formas, no están permitidas cabeceras (bien cabeceras mensaje, bien cabeceras de parte de cuerpo) que contengan otra cosa que caracteres US-ASCII en ninguna circunstancia. NOTA: Visiblemente omitido en el tipo "multipart" está el concepto de partes de cuerpo estructuradas o relacionadas. Se recomienda que aquellos que deseen proveer capacidades de mensajería multiparte más estructuradas o integradas definan subtipos de multiparte que sean sintácticamente idénticos pero que definan las relaciones entre las distintas partes. Por ejemplo, podrían definirse subtipos de multiparte que incluyeran una parte diferenciada en la cual especificar las relaciones entre las otras partes, probablemente refiriéndose a ellas mediante el campo Content-ID. Las implementaciones antiguas no reconocerán el nuevo subtipo si se utiliza este esquema, pero lo tratarán como si fuera "multipart/mixed" y por tanto podrán mostrar al usuario las partes que sean reconocidas. 5.1.2 Manejo de Mensajes y Multipartes anidados El subtipo "message/rfc822" definido en una sección posterior de este N.Freed Seguimiento de Estándar [Pág. 25] RFC 2046 MIME: Segunda Parte Noviembre 1996 documento no tiene otra condición de terminación que la finalización de los datos. De forma análoga, una entidad "multipart" inapropiadamente truncada puede no tener ningún delimitador de terminación, y volverse operativa debido al mal funcionamiento del sistema de correo. Es esencial que dichas entidades sean tratadas correctamente cuando ellas mismas estén incrustadas en otra estructura "multipart". Se requiere a las implementaciones MIME que reconozcan el nivel más externo de los marcadores de límite en CUALQUIER nivel de anidamiento interno. No es suficiente con comprobar simplemente la siguiente marca que se espera u otra condición de terminación. 5.1.3 Subtipo "mixed" (mezclado) La intención del subtipo "mixed" de "multipart" es usarlo cuando las partes del cuerpo son independientes y necesitan ser agrupadas en un orden determinado. Cualquier subtipo "multipart" que una implementación no reconozca debe ser tratado como si fuera del subtipo "mixed". 5.1.4 Subtipo "alternative" (alternativo) El tipo "multipart/alternative" es sintácticamente idéntico al "multipart/mixed", pero la semántica es diferente. En concreto, cada una de las partes de cuerpo es una versión "alternativa" de la misma información. Los sistemas deberán reconocer que el contenido de las distintas partes son intercambiables. Los sistemas deberán elegir el "mejor" tipo basándose en el entorno local y en referencias, en algunos casos a través de interacción con el usuario. Al igual que con "multipart/mixed", el orden de las partes de cuerpo es significativo. En este caso, las alternativas aparecen en orden creciente de fidelidad al contenido original. En general, la mejor elección es la ULTIMA parte que sea de un tipo soportado por el entorno local del receptor. Se puede utilizar "multipart/alternative", por ejemplo, para enviar un mensaje en un formato vistoso de texto de tal forma que pueda ser fácilmente visualizado en cualquier parte: From: Nathaniel Borenstein To: Ned Freed Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST) Subject: Correo de texto formateado MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=delimitador42 N.Freed Seguimiento de Estándar [Pág. 26] RFC 2046 MIME: Segunda Parte Noviembre 1996 --delimitador42 Content-Type: text/plain; charset=us-ascii ... la version de texto plano del mensaje va aqui ... --delimitador42 Content-Type: text/enriched ... la version RFC 1896 text/enriched del mismo mensaje va aqui ... --delimitador42 Content-Type: application/x-laquesea ... la version mas vistosa del mismo mensaje va aqui ... --delimitador42-- En este ejemplo, los usuarios cuyos sistemas de correo entiendan el formato "application/x-laquesea" verán sólo la versión vistosa, mientras que otros usuarios verán sólo la versión de texto enriquecido o la de texto plano, dependiendo de las capacidades de sus sistemas. En general, los agentes de usuario que compongan entidades "multipart/alternative" deben colocar las partes de cuerpo en orden creciente de preferencia, es decir, el formato preferido el último. Para texto vistoso, el agente del usuario que envía deberá poner el formato más plano primero y el más rico el último. Los agentes de los usuarios receptores deberán coger y visualizar el último formato que sean capaces de visualizar. En el caso en el que una de las alternativas sea por sí misma de tipo "multipart" y contenga sub- partes no reconocidas, el agente de usuario puede elegir entre mostrar esa alternativa, una alternativa anterior, o ambas. NOTA: Desde el punto de vista del implementador, podría parecer mejor invertir esta ordenación, y tener la alternativa más plana la última. De todas formas, poner la alternativa más plana primero es la opción posible más amigable cuando se visualizan entidades "multipart/alternative" utilizando un visualizador no conforme a MIME. Mientras que este enfoque impone alguna carga adicional a visualizadores conformes a MIME, la interoperabilidad con lectores de correo más antiguos fue considerada más importante en este caso. Puede ser el caso de que algún agente de usuario, si pueden reconocer más de uno de los formatos, prefiera ofrecer al usuario la opción de elegir el formato a ver. Esto tiene sentido, por ejemplo, si un mensaje incluye una imagen formateada y una versión texto. Lo que es más importante, de todas formas, es que al usuario no se le muestren automáticamente múltiples versiones de los mismos datos. O bien al N.Freed Seguimiento de Estándar [Pág. 27] RFC 2046 MIME: Segunda Parte Noviembre 1996 usuario se le mostrará la última versión reconocida o bien se le dará a elegir la opción. EL SIGNIFICADO DE CONTENT-ID EN MULTIPART/ALTERNATIVE: Cada parte de una entidad "multipart/alternative" representa la misma información, pero la correspondencia entre las dos no es necesariamente sin pérdida de información. Por ejemplo, se pierde información cuando se traduce de ODA a PostScript o texto plano. Se recomienda que cada parte tenga un valor de Content-ID diferente en el caso en el que la información de las dos partes no sea idéntica. Y cuando la información sea idéntica -- por ejemplo, cuando varias partes del tipo "message/external-body" especifican caminos alternativos para acceder a datos idénticos -- debería usarse el mismo valor del campo Content-ID, para optimizar cualquier mecanismo de almacenamiento intermedio (cache) que pudiera existir en el extremo del receptor. De todas formas, los valores de Content-ID usados en las partes NO deberán ser el mismo que describe el "multipart/alternative" como un todo, si existe dicho campo Content-ID. Es decir, un valor de Content-ID se referirá a la entidad "multipart/alternative", mientras que uno o más valores de Content-ID se referirán a las partes dentro de ella. 5.1.5 Subtipo "digest" (compendio) Este documento define un subtipo "digest" del Content-Type "multipart". Este tipo es sintácticamente idéntico al "multipart/mixed", pero la semántica es diferente. En particular, en un "digest", el valor por defecto de Content-Type para una parte de cuerpo se cambia de "text/plain" a "message/rfc822". Esto se hace para permitir un formato de compendio más legible que sea altamente compatible con RFC 934 (excepto en cuanto a la convenciones de entrecomillado). NOTA: Aunque es posible especificar un valor de Content-Type para una parte de cuerpo en un compendio que no sea "message/rfc822", como una parte "text/plain" que contenga una descripción del material que hay en el compendio, hacer eso es indeseable. El Content-Type "multipart/digest" está pensado para usarlo en el envío de colecciones de mensajes. Si se necesita una parte "text/plain", deberá ser incluida como una parte separada de un mensaje "multipart/mixed". Un compendio en este formato podría, por tanto, asemejarse a esto: From: Direccion-Moderador To: Recipient-List Date: Mon, 22 Mar 1994 13:34:51 +0000 Subject: Compendio de Internet, volumen 42 N.Freed Seguimiento de Estándar [Pág. 28] RFC 2046 MIME: Segunda Parte Noviembre 1996 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- delimitador principal ----" ------ delimitador principal ---- ...Texto introductorio o tabla de contenidos... ------ delimitador principal ---- Content-Type: multipart/digest; boundary="---- siguiente mensaje ----" ------ siguiente mensaje ---- From: Alguien Date: Fri, 26 Mar 1993 11:13:32 +0200 Subject: mi opinion ...el cuerpo va aqui ... ------ siguiente mensaje ---- From: Alguien-otra-vez Date: Fri, 26 Mar 1993 10:07:13 -0500 Subject: mi otra opinion ... otro cuerpo va aqui ... ------ siguiente mensaje ------ ------ delimitador principal ------ 5.1.6 Subtipo "parallel" (paralelo) Este documento define un subtipo "parallel" del Content-Type "multipart". Este tipo es sintácticamente idéntico al "multipart/mixed", pero la semántica es diferente. En particular, en una entidad paralela, el orden de las partes de cuerpo no es significativo. Una presentación corriente de este tipo es mostrar todas las partes simultáneamente sobre hardware y software que sea capaz de hacerlo. De todas formas, los agentes de composición deberían tener en cuenta que muchos lectores de correo carecerán de esta capacidad y que mostrarán las partes secuencialmente. 5.1.7 Otros subtipos "multipart" N.Freed Seguimiento de Estándar [Pág. 29] RFC 2046 MIME: Segunda Parte Noviembre 1996 Se esperan otros subtipos "multipart" en el futuro. Las implementaciones MIME deben, en general, tratar subtipos no reconocidos de "multipart" como equivalentes a "multipart/mixed". 5.2 Tipo de Contenido "message" (mensaje) A menudo es deseable, al enviar correo, encapsular otro mensaje de correo. Se define un tipo especial de contenido, "message", para facilitarlo. En particular, el subtipo "rfc822" de "message" se utiliza para encapsular mensajes RFC 822. NOTA: Se ha sugerido que se podrían definir subtipos de "message" para mensajes reenviados o rechazados. Con todo, los mensajes reenviados y los rechazados se pueden manejar como mensajes multiparte en los que la primera parte contiene cualquier información de control o descriptiva, y en la que la segunda parte, de tipo "message/RFC822", es el mensaje reenviado o rechazado. La composición de mensajes rechazados o reenviados de esta forma preservará la información de tipo en el mensaje original y permitirá que sea correctamente presentada al receptor, y por tanto se recomienda encarecidamente. Los subtipos de "message" a menudo imponen restricciones en cuanto a qué codificaciones se permiten. Estas restricciones se describen en conjunción con cada subtipo específico. Pasarelas de correo, reenviadores, y otros agentes de manejo de correo se sabe que frecuentemente alteran la cabecera de nivel máximo de los mensajes RFC 822. En concreto, añaden, quitan o reordenan campos de cabecera. Estas operaciones están explícitamente prohibidas en las cabeceras encapsuladas en los cuerpos de mensajes de tipo "message". 5.2.1 Subtipo RFC822 Un tipo de contenido "message/rfc822" indica que el cuerpo contiene un mensaje encapsulado, con la sintaxis de un mensaje RFC 822. Sin embargo, al contrario que en mensajes de nivel máximo RFC 822, la restricción de que cada cuerpo "message/rfc822" debe incluir un "From", un "Date", y como mínimo un destino en la cabecera, se elimina y sustituye por el requerimiento de que como mínimo debe aparecer un "From", un "Subject" o un "Date". Debe hacerse notar que, a pesar del uso de los números "822", una entidad "message/rfc822" no está limitada a material en conformidad estricta con RFC822, ni la semántica de objetos "message/rfc822" está limitada a la semántica definida en RFC822. Más específicamente, un mensaje "message/rfc822" podría ser perfectamente un artículo de News N.Freed Seguimiento de Estándar [Pág. 30] RFC 2046 MIME: Segunda Parte Noviembre 1996 o un mensaje MIME. No se permiten otras codificaciones que "7bit", "8bit" y "binary" para el cuerpo de una entidad "message/rfc822". Los campos de cabecera de mensaje son siempre US-ASCII en cualquier caso, y los datos dentro del cuerpo pueden ser codificados, en cuyo caso el campo de cabecera Content-Transfer-Encoding del mensaje encapsulado reflejará esto. Se puede especificar texto no US-ASCII en las cabeceras de un mensaje encapsulado utilizando el mecanismo descrito en RFC 2047. 5.2.2 Subtipo "partial" (parcial) El subtipo "partial" se define para permitir que entidades grandes puedan ser enviadas como piezas separadas de correo y automáticamente reensambladas por el agente de usuario receptor. (El concepto es similar al fragmentado y reensamblado IP de los protocolos de Internet básicos). Este mecanismo puede ser utilizado cuando los agentes intermedios de transporte limiten el tamaño de los mensajes individuales que se pueden enviar. El tipo de contenido "message/partial" por tanto indica que el cuerpo contiene un fragmento de una entidad más grande. Debido a que datos de tipo "message" nunca pueden estar codificados en base64 o en quoted-printable, puede surgir un problema si se construyen entidades "message/partial" en un entorno que soporte transporte "binary" o de "8bit". El problema es que si los datos binarios fueran divididos en múltiples mensajes "message/partial", cada uno de ellos requeriría transporte binario. Si esos mensajes se encontraran en una pasarela de un entorno de transporte de 7bit, no habría manera de codificarlos adecuadamente para 7bit, al margen de esperar todos los fragmentos, reensamblar el mensaje interior, y entonces codificar los datos reensamblados en base64 o quoted- printable. Dado que es posible que fragmentos distintos puedan ir a través de pasarelas distintas, incluso esta no es una solución aceptable. Por esta razón, se especifica que las entidades de tipo "message/partial" deben tener siempre un content-transfer-encoding de 7bit (el valor por defecto). En particular, incluso en entornos que soporten transporte "binary" o de "8bit", el uso de content-transfer- encoding de "8bit" o "binary" está explícitamente prohibido para entidades MIME del tipo "message/partial". Por otro lado esto implica que el mensaje interno no debe usar codificación "8bit" o "binary". Debido a que algunos agentes de transferencia de mensajes pueden elegir fragmentar mensajes grandes automáticamente, y a que esos agentes pueden elegir diferentes umbrales de fragmentación, es posible que piezas de mensajes parciales, al reensamblarlas, resulten contener un mensaje parcial. Esto está explícitamente permitido. N.Freed Seguimiento de Estándar [Pág. 31] RFC 2046 MIME: Segunda Parte Noviembre 1996 Deben estar especificados tres parámetros en el campo Content-Type de tipo "message/partial": El primero, "id", es un identificador único, tan cercano a ser universalmente único como sea posible, para usarlo para agrupar los fragmentos. (En general, el identificador es en esencia un message-id; si se coloca entre dobles comillas, puede ser CUALQUIER message-id, de acuerdo con la notación BNF para "parameter" dada en RFC 2045). El segundo, "number", un entero, es el número de fragmento, que indica dónde casa este fragmento en la secuencia de fragmentos. El tercero, "total", otro entero, es el número total de fragmentos. Este tercer subcampo es obligatorio en el último fragmento, y es opcional (aunque recomendado) en los fragmentos precedentes. Nótese que estos parámetros pueden estar en cualquier orden. Por tanto, la segunda pieza de un mensaje de tres piezas puede tener cualquiera de los siguientes campos de cabecera: Content-Type: Message/Partial; number=2; total=3; id="oc=jpbe0M2Yt4s@thumper.bellcore.com" Content-Type: Message/Partial; id="oc=jpbe0M2Yt4s@thumper.bellcore.com"; number=2 Pero la tercera pieza DEBE especificar el número total de fragmentos: Content-Type: Message/Partial; number=3; total=3; id="oc=jpbe0M2Yt4s@thumper.bellcore.com" Nótese que la numeración de fragmentos empieza en 1, no en 0. Cuando los fragmentos de una entidad troceada de esta forma se ponen juntos, el resultado es siempre una entidad MIME completa, que puede tener su propio campo de cabecera Content-Type, y por tanto puede contener cualquier otro tipo de datos. 5.2.2.1 Fragmentación de mensajes y reensamblado La semántica de un mensaje parcial reensamblado debe ser la del mensaje "interno", en vez de ser un mensaje conteniendo al mensaje interno. Esto hace posible, por ejemplo, enviar un mensaje de audio grande como varios mensajes parciales, y aún así parecer al receptor como un mensaje simple de audio en vez de un mensaje encapsulado conteniendo un mensaje de audio. Es decir, la encapsulación del mensaje se considera que es "transparente". Cuando se genera y se reensamblan las piezas de un mensaje "message/partial", las cabeceras del mensaje encapsulado deben N.Freed Seguimiento de Estándar [Pág. 32] RFC 2046 MIME: Segunda Parte Noviembre 1996 combinarse con las cabeceras de las entidades que las contienen. En este proceso se deben observar las siguientes reglas: (1) Los agentes de fragmentación deben dividir los mensajes sólo en límites de líneas. Esta restricción se impone porque dividir en puntos distintos a los finales de línea depende de que los transportes de mensajes sean capaces de preservar la semántica de mensajes que no terminen con la secuencia CRLF. Muchos transportes son incapaces de preservar dichas semánticas. (2) Todos los campos de cabecera del mensaje contenedor inicial, excepto aquellos que empiecen con "Content-" y los específicos "Subject", "Message-ID", "Encrypted", y "MIME- Version", deben copiarse, en orden, al nuevo mensaje. (3) Los campos de cabecera del mensaje contenido que empiecen con "Content-", más los campos "Subject", "Message-ID", "Encrypted", y "MIME-Version", deben ser añadidos, en orden, a los campos de cabecera del nuevo mensaje. Cualquier campo del mensaje contenido que no empiece con "Content-" (excepto los campos "Subject", "Message-ID", "Encrypted", y "MIME- Version") serán ignorados y descartados. (4) Todos los campos de cabecera del segundo y siguientes mensajes contenedores se descartan en el proceso de reensamblado. 5.2.2.2 Ejemplo de fragmentación y reensamblado Si un mensaje de audio se divide en dos piezas, la primera pieza debe parecer algo como esto: X-Cabecera-Rara-1: Cualquier From: Bill@host.com To: joe@otherhost.com Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST) Subject: Correo de Audio (parte 1 de 2) Message-ID: MIME-Version: 1.0 Content-type: message/partial; id="ABC@host.com"; number=1; total=2 X-Cabecera-Rara-1: Cosa X-Cabecera-Rara-2: Hola Message-ID: Subject: Audio mail MIME-Version: 1.0 Content-type: audio/basic N.Freed Seguimiento de Estándar [Pág. 33] RFC 2046 MIME: Segunda Parte Noviembre 1996 Content-transfer-encoding: base64 ... la primera mitad de audio codificado va aqui ... y la segunda parte podría ser algo como esto: From: Bill@host.com To: joe@otherhost.com Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST) Subject: Correo de Audio (parte 2 de 2) MIME-Version: 1.0 Message-ID: Content-type: message/partial; id="ABC@host.com"; number=2; total=2 ... la segunda mitad de audio codificado va aqui ... Entonces, cuando el mensaje fragmentado es reensamblado, el mensaje resultante a mostrar al usuario sería algo como esto: X-Cabecera-Rara-1: Cualquier From: Bill@host.com To: joe@otherhost.com Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST) Subject: Correo de Audio Message-ID: MIME-Version: 1.0 Content-type: audio/basic Content-transfer-encoding: base64 ... la primera mitad de audio codificado va aqui ... ... la segunda mitad de audio codificado va aqui ... La inclusión de un campo "References" en las cabeceras de la segunda y siguientes piezas de un mensaje fragmentado que referencie al Message-Id de la pieza anterior puede ser beneficioso para lectores de correo que entiendan y rastreen referencias. De todas formas, la generación de dichos campos "References" es completamente opcional. Finalmente, debe tenerse en cuenta que el campo de cabecera "Encrypted" ha sido hecho obsoleto por Privacy Enhanced Messaging (PEM: Envío de Mensajes con Privacidad Ampliada) [RFC-1421, RFC-1422, RFC-1423, RFC-1424], pero las reglas anteriores a pesar de todo se considera que describen la forma correcta de tratarlo si se encuentra en el contexto de una conversión de y hacia fragmentos "message/partial". 5.2.3 Subtipo "external-body" (cuerpo externo) N.Freed Seguimiento de Estándar [Pág. 34] RFC 2046 MIME: Segunda Parte Noviembre 1996 El subtipo "external-body" indica que los datos del cuerpo no están incluidos, sino meramente referenciados. En este caso, los parámetros describen un mecanismo para acceder a los datos externos. Cuando una entidad MIME es del tipo "message/external-body", consiste en una cabecera, dos CRLF consecutivos, y la cabecera de mensaje para el mensaje encapsulado. Si aparece otro par de CRLF consecutivos, esto por supuesto finaliza la cabecera de mensaje para el mensaje encapsulado. De todas formas, dado que el cuerpo del mensaje es externo, NO aparece en el área siguiente. Por ejemplo, considere el siguiente mensaje: Content-type: message/external-body; access-type=local-file; name="/u/nsb/Me.jpeg" Content-type: image/jpeg Content-ID: Content-Transfer-Encoding: binary ESTO NO ES REALMENTE EL CUERPO! El área al final, que podría llamarse "cuerpo fantasma", se ignora en la mayoría de mensajes "external-body". Aún así, se puede utilizar para contener información auxiliar para algunos mensajes, como de hecho es cuando el "access-type" (tipo de acceso) es "mail-server". El único "access-type" definido en este documento que utiliza el cuerpo fantasma es "mail-server", pero puede haber otros tipos que se definan en un futuro en otras especificaciones que utilicen este área. Las cabeceras encapsuladas en TODAS las entidades "message/external- body" DEBEN incluir el campo de cabecera Content-ID para ofrecer un identificador único con el que referenciar los datos. Este identificador se puede usar para mecanismos de almacenamiento intermedio (caching), y para reconocer al receptor de los datos cuando el tipo de acceso es "mail-server". Nótese que, como se especifica aquí, los valores individuales que describen los datos "external-body", como nombres de fichero y comandos de servidor de correo, es obligatorio que estén en el conjunto de caracteres US-ASCII. Si esto resulta problemático en la práctica, puede que sea necesario definir un nuevo mecanismo como futura extensión a MIME, bien como una nueva definición de tipo de acceso para "message/external-body" o bien por algún otro mecanismo. N.Freed Seguimiento de Estándar [Pág. 35] RFC 2046 MIME: Segunda Parte Noviembre 1996 Al igual que con "message/partial", las entidades MIME del tipo "message/external-body" DEBEN tener un content-transfer-encoding de 7bit (el valor por defecto). En particular, incluso en entornos que soporten transporte binario o de 8bit, el uso de un content-transfer- encoding de "8bit" o "binary" se prohibe explícitamente para entidades del tipo "message/external-body". 5.2.3.1. Parámetros Generales de External-Body Los parámetros que se pueden usar con cualquier "message/external- body" son: (1) ACCESS TYPE (tipo de acceso) -- Una palabra indicando el mecanismo soportado de acceso por el cual se puede obtener el fichero o los datos. Esta palabra no es sensible a mayúsculas. Los valores incluyen, pero no están limitados a, "FTP", "ANON-FTP", "TFTP", "LOCAL-FILE", y "MAIL-SERVER". Valores futuros, excepto para valores experimentales que empiecen por "X-", se deben registrar con IANA, como se describe en RFC 2048. Este parámetro es obligatorio incondicionalmente y DEBE estar presente en TODOS los "message/external-body". (2) EXPIRATION (caducidad) -- La fecha (en la sintaxis de "date- time" de RFC 822, ampliada por RFC 1123 para permitir cuatro dígitos en el campo de año) después de la cual la existencia de los datos no se garantiza. Este parámetro se puede utilizar con CUALQUIER tipo de acceso y es SIEMPRE opcional. (3) SIZE (tamaño) -- El tamaño (en octetos) de los datos. El objetivo de este parámetro es ayudar al receptor a decidir si gastar o no los recursos necesarios para recuperar los datos externos. Téngase en cuenta que describe el tamaño de los datos en su forma canónica, es decir, antes de que se haya aplicado el Content-Transfer-Encoding o después de que los datos hayan sido decodificados. Este parámetro se puede utilizar con CUALQUIER tipo de acceso y es SIEMPRE opcional. (4) PERMISSION (permiso) -- Un campo no sensible a mayúsculas que indica si se espera o no que los clientes también puedan intentar sobreescribir los datos. Por defecto, o si el permiso es "read" (lectura), se asume que no, y que si los datos son recuperados una vez entonces no son necesarios nunca más. Si PERMISSION es "read-write" (lectura-escritura) esta asunción no es correcta, y cualquier copia local no debe ser considerada más que un almacenamiento temporal. Los únicos valores definidos de permiso son "Read" y "Read- write". Este parámetro se puede utilizar con CUALQUIER tipo N.Freed Seguimiento de Estándar [Pág. 36] RFC 2046 MIME: Segunda Parte Noviembre 1996 de acceso y es SIEMPRE opcional. El significado exacto de los tipos de acceso aquí definidos se describen en las secciones a continuación. 5.2.3.2. Los tipos de acceso 'ftp' y 'tftp' Un tipo de acceso FTP o TFTP indica que el cuerpo del mensaje es accesible como un fichero utilizando el protocolo FTP [RFC-959] o el TFTP [RFC-783], respectivamente. Para estos tipos de acceso, los siguientes parámetros adicionales son obligatorios: (1) NAME (nombre) -- El nombre del fichero que contiene realmente los datos del cuerpo. (2) SITE (sitio) -- Una máquina de la que pueda ser obtenido el fichero, utilizando el protocolo dado. Debe ser un nombre de dominio completamente cualificado, no un apodo. (3) Antes de que se recupere cualquier dato, utilizando FTP, generalmente se necesita pedir al usuario un identificador de acceso y una contraseña para la máquina nombrada en el parámetro "site". Por razones de seguridad, dichos identificador y contraseña no se especifican como parámetros de content-type sino que deben ser obtenidos del usuario. Además, los siguientes parámetros son opcionales: (1) DIRECTORY (directorio) -- Un directorio del cual podrán ser recuperados los datos mencionados en NAME. (2) MODE (modo) -- Una cadena no sensible a mayúsculas indicando el modo a usar cuando se recupere la información. Los valores válidos para el tipo de acceso TFTP son "NETASCII", "OCTET", y "MAIL", como se especifica en el protocolo TFTP [RFC-783]. Los valores válidos para el tipo de acceso "FTP" son "ASCII", "EBCDIC", "IMAGE", y "LOCALn" donde "n" es un entero decimal, normalmente 8. Estos corresponden con los tipos de representación "A" "E" "I" y "L n" como especifica el protocolo FTP [RFC-959]. Nótese que "BINARY" y "TENEX" no son valores válidos para MODE y que "OCTET" o "IMAGE" o "LOCAL8" deberán ser usados a cambio. Si MODE no está especificado, el valor por defecto es "NETASCII" para TFTP y "ASCII" en caso contrario. 5.2.3.3. El tipo de acceso 'anon-ftp' El tipo de acceso "anon-ftp" es idéntico al tipo de acceso "ftp", N.Freed Seguimiento de Estándar [Pág. 37] RFC 2046 MIME: Segunda Parte Noviembre 1996 excepto que no es necesario preguntar al usuario para que proporcione un nombre y una contraseña para el sitio especificado. En vez de ello, se usará el protocolo ftp con identificador de acceso "anonymous" y como contraseña la dirección de correo del usuario. 5.2.3.4. El tipo de acceso 'local-file' El tipo de acceso "local-file" indica que el cuerpo real es accesible como fichero en la máquina local. Se definen dos parámetros adicionales para este tipo de acceso: (1) NAME (nombre) -- El nombre del fichero que contiene los datos del cuerpo. Este parámetro es obligatorio para el tipo de acceso "local-file". (2) SITE (sitio) -- Un especificador de dominio para una máquina o conjunto de máquinas que se sabe que tienen acceso al fichero de datos. Este parámetro opcional se usa para describir la localización de referencia para los datos, es decir, el sitio o sitios en los que se espera que el fichero esté visible. Se pueden usar asteriscos como patrón de coincidencia de una parte del nombre de dominio, como "*.bellcore.com", para indicar el conjunto de máquinas en las que los datos serán directamente visibles, mientras que un único asterisco se puede usar para indicar un fichero que se espera que esté universalmente disponible, p.ej., mediante un sistema de ficheros global. 5.2.3.5. El tipo de acceso 'mail-server' El tipo de acceso "mail-server" indica que el cuerpo está disponible en un servidor de correo. Se definen dos parámetros adicionales para este tipo de acceso: (1) SERVER (servidor) -- La dirección específica del servidor de correo del cual se pueden obtener los datos. Este parámetro es obligatorio para el tipo de acceso "mail-server". (2) SUBJECT (asunto) -- El asunto es para usarlo en el mensaje que se envía para obtener los datos. NO se recomienda dialogar con los servidores de correo mediante las líneas de Subject, aunque se conocen servidores de correo que lo aceptan. Este es un parámetro opcional. Debido a que los servidores de correo aceptan gran variedad de sintaxis, algunas de las cuales son multilínea, el comando completo a enviar al servidor de correo no se incluye como parámetro en el campo de cabecera Content-Type. En vez de ello, se indica en el "cuerpo N.Freed Seguimiento de Estándar [Pág. 38] RFC 2046 MIME: Segunda Parte Noviembre 1996 fantasma" cuando el tipo de contenido es "message/external-body" y el tipo de acceso es "mail-server". Nótese que MIME no define una sintaxis de servidor de correo. Por el contrario, permite la inclusión de comandos de servidor de correo arbitrarios en el cuerpo fantasma. Las implementaciones deben incluir el cuerpo fantasma en el cuerpo de mensaje que envíen al servidor de correo para obtener los datos relevantes. Al contrario que otros tipos de acceso, el acceso "mail-server" es asíncrono y ocurre en un momento futuro impredecible. Por esta razón, es importante que haya un mecanismo por el cual los datos obtenidos puedan ser comparados con la entidad "message/external-body" original. Los servidores de correo MIME deben usar en el mensaje devuelto el mismo campo Content-ID que fue usado en las entidades "message/external-body" originales, para facilitar dicha comparación. 5.2.3.6. Cuestiones de seguridad en External-Body La entidades "message/external-body" hacen aflorar dos importantes cuestiones de seguridad: (1) El acceso a los datos mediante una referencia "message/external-body" resulta en realidad en la realización en el receptor del mensaje de una operación especificada por el originador del mensaje. Es por tanto posible para el originador engañar al receptor para hacer algo que no hubiera hecho de otra forma. Por ejemplo, un originador podría especificar una acción que intente la recuperación de material que el receptor no esté autorizado a obtener, provocando que el receptor involuntariamente viole alguna medida de seguridad. Por esta razón, los agentes de usuario capaces de resolver referencias externas deben siempre tomar medidas para describir al receptor las acciones que van a tomar y pedir el permiso explícito antes de realizarlas. El tipo de acceso "mail-server" es particularmente vulnerable, ya que provoca que el receptor envíe un nuevo mensaje cuyos contenidos los especifica el originador del mensaje original. Dado este abuso potencial, estos mensajes de petición que se construyan deberían contener una indicación clara de que han sido generados automáticamente (p.ej., en un campo de cabecera Comments:) en un intento de resolver una referencia MIME "message/external-body". (2) Algunas veces MIME se utilizará en entornos que proporcionen alguna garantía de integridad y autenticidad de mensajes. Si dichas garantías existen, puede que se apliquen sólo al N.Freed Seguimiento de Estándar [Pág. 39] RFC 2046 MIME: Segunda Parte Noviembre 1996 contenido directo actual de los mensajes -- pueden aplicarse o no a los datos accedidos mediante el mecanismo MIME "message/external-body". En particular, puede ser posible saltarse determinados mecanismos de acceso incluso aunque el sistema de mensajes sea seguro. Debe hacerse notar que este problema existe con o sin la disponibilidad de mecanismos MIME. Una referencia casual en un texto seguro a un sitio FTP que contenga un documento trae a colación consideraciones similares -- la única diferencia es que MIME proporciona la recuperación automática de dicho material, y los usuarios pueden poner una confianza injustificada en dichos mecanismos automáticos de recuperación. 5.2.3.7. Ejemplos y Explicaciones Adicionales Cuando el mecanismo de cuerpo externo se utiliza junto con el tipo de contenido "multipart/alternative", extiende la funcionalidad de "multipart/alternative" al incluir los casos en los que se facilita la misma entidad en el mismo formato pero mediante diferentes mecanismos de acceso. Cuando sea este el caso, el originador del mensaje debe ordenar las partes, primero en términos de preferencias de formatos y después por mecanismos de acceso preferidos. El visualizador del receptor evaluará la lista tanto en términos de formato como de mecanismos de acceso. Con la emergente posibilidad de sistemas de ficheros de área muy amplia, se torna muy difícil conocer por anticipado el conjunto de máquinas donde será o no accesible un fichero directamente desde el sistema de ficheros. Por tanto toma sentido el proporcionar tanto un nombre de fichero, que se intentará directamente, como el nombre de uno o más sitios donde se sabe que el fichero está accesible. Una implementación puede intentar recuperar ficheros remotos usando FTP o cualquier otro protocolo, utilizando recuperación de ficheros anónima o preguntando al usuario el nombre y la contraseña necesarios. Si un cuerpo externo es accesible mediante múltiples mecanismos, el remitente puede incluir varias entidades del tipo "message/external- body" en las partes del cuerpo de una entidad contenedora "multipart/alternative". No obstante, el mecanismo "external-body" no está pensado exclusivamente para recuperación de ficheros, como demuestra el tipo de acceso "mail-server". Aparte de esto, uno podría imaginar, por ejemplo, el utilizar un servidor de video para referencias externas de 'video clips'. Los campos de cabecera de mensaje incrustados que aparecen en el N.Freed Seguimiento de Estándar [Pág. 40] RFC 2046 MIME: Segunda Parte Noviembre 1996 cuerpo de los datos "message/external-body" se deben usar para declarar el tipo de contenido del cuerpo externo si es otra cosa que texto plano US-ASCII, ya que los cuerpos externos no tienen una sección de cabecera para declarar su tipo. De igual forma, cualquier Content-Transfer-Encoding distinto a "7bit" se debe declarar también aquí. Por tanto, un mensaje completo "message/external-body", que se refiera a un objeto en formato PostScript, podría se como esto: From: Dequiensea To: Aquiensea Date: Cuandosea Subject: Loquesea MIME-Version: 1.0 Message-ID: Content-Type: multipart/alternative; boundary=42 Content-ID: --42 Content-Type: message/external-body; name="BodyFormats.ps"; site="thumper.bellcore.com"; mode="image"; access-type=ANON-FTP; directory="pub"; expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" Content-type: application/postscript Content-ID: --42 Content-Type: message/external-body; access-type=local-file; name="/u/nsb/writing/rfcs/RFC-MIME.ps"; site="thumper.bellcore.com"; expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" Content-type: application/postscript Content-ID: --42 Content-Type: message/external-body; access-type=mail-server server="listserv@bogus.bitnet"; expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" Content-type: application/postscript Content-ID: get RFC-MIME.DOC --42-- N.Freed Seguimiento de Estándar [Pág. 41] RFC 2046 MIME: Segunda Parte Noviembre 1996 Nótese que en el ejemplo anterior, se asume el Content-Transfer- Encoding por defecto de "7bit" para los datos PostScript externos. Como el tipo "message/partial", el tipo de contenido "message/external-body" pretende ser transparente, es decir, transportar el tipo de datos en el cuerpo externo en vez de transportar un mensaje con un cuerpo de ese tipo. De esa forma las cabeceras de las partes internas y externas se pueden combinar utilizando las mismas reglas que para "message/partial". En concreto, esto significa que los campos Content-Type y Subject se pasan por alto, pero el campo From: se mantiene. Nótese que debido a que los cuerpos externos no se transportan junto con la referencia del cuerpo externo, no necesitan estar sometidos a las limitaciones de transporte que afectan a las referencias mismas. En particular, los transportes de Internet pueden imponer limites de longitud de línea y 7bit, pero esto no se aplica automáticamente a referencias a cuerpos externos binarios. Por tanto, no es necesario Content-Transfer-Encoding generalmente, aunque está permitido. Nótese que el cuerpo de un mensaje del tipo "message/external-body" está gobernado por la sintaxis básica de un mensaje RFC 822. En particular, cualquier cosa antes del primer par de CRLF consecutivos es información de cabecera, mientras que cualquier cosa después de él es información del cuerpo, el cual se ignora en la mayoría de tipos de acceso. 5.2.4 Otros subtipos "message" Las implementaciones de MIME deben, en general, tratar subtipos de "message" no reconocidos como equivalentes a "application/octet- stream". Futuros subtipos de "message" pensados para usar con correo electrónico deberían estar restringidos a codificación de "7bit". Se debería usar un tipo distinto de "message" si la restricción a "7bit" no es posible. 6. Valores de Tipo de Contenido Experimentales Un valor tipo de contenido que empiece con los caracteres "X-" es un valor privado, para ser utilizado por sistemas que lo consientan de mutuo acuerdo. Cualquier formato sin una definición rigurosa y pública debe ser nombrado con un prefijo "X-", y los valores especificados públicamente nunca empezarán con "X-". (Versiones antiguas del ampliamente utilizado sistema Andrew utilizan el nombre "X-BE2", por lo que los sistemas nuevos probablemente elegirían un nombre diferente). N.Freed Seguimiento de Estándar [Pág. 42] RFC 2046 MIME: Segunda Parte Noviembre 1996 En general, el uso de tipos de nivel máximo "X-" está encarecidamente desaconsejado. Los implementadores deberían inventar subtipos de los tipos existentes siempre que sea posible. En muchos casos, un subtipo de "application" será más apropiado que un nuevo tipo de nivel máximo. 7. Sumario Los cinco tipos de contenido simple proporcionan un mecanismo estándar para el marcado de entidades como "audio", "image", o varios otros tipos de datos. Los tipos de contenido compuestos "multipart" y "message" permiten el mezclado y la estructuración jerárquica de entidades de tipos diferentes en un único mensaje. Una sintaxis de parámetro diferenciada permite la especificación adicional de detalles de los formatos de datos, particularmente la especificación de conjuntos de caracteres alternativos. Campos de cabecera opcionales proporcionan mecanismos para determinadas extensiones consideradas deseables por muchos implementadores. Finalmente, se define cierto número de tipos de contenido para uso general por agentes de usuario, donde destacan "message/partial" y "message/external-body". 8. Consideraciones de Seguridad Las cuestiones de seguridad se abordan en el contexto del tipo "application/Postscript, del tipo "message/external-body", y en RFC 2048. Los implementadores prestarán especial atención a las implicaciones de seguridad de cualquier tipo de contenido que pueda provocar la ejecución remota de acciones en el entorno del receptor. En dichos casos, la discusión del tipo "application/postscript" podría servir como modelo para considerar otros tipos de contenido con capacidades de ejecución remota. 9. 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 N.Freed Seguimiento de Estándar [Pág. 43] RFC 2046 MIME: Segunda Parte Noviembre 1996 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 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. boundary := 0*69 bchars := bcharsnospace / " " bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / N.Freed Seguimiento de Estándar [Pág. 44] RFC 2046 MIME: Segunda Parte Noviembre 1996 "+" / "_" / "," / "-" / "." / "/" / ":" / "=" / "?" body-part := <"message" como se define en RFC 822, con todos los campos de cabecera opcionales, sin empezar con el dash-boundary especificado y sin que el delimitador aparezca en ningún lugar de la parte del cuerpo. Nótese que la semántica de una parte de cuerpo difiere de la semántica de un mensaje, como se describe en el texto.> close-delimiter := delimiter "--" dash-boundary := "--" boundary ; "boundary" tomado del valor ; del parámetro "boundary" del ; campo Content-Type. delimiter := CRLF dash-boundary discard-text := *(*text CRLF) ; Puede ser ignorado o descartado encapsulation := delimiter transport-padding CRLF body-part epilogue := discard-text multipart-body := [preamble CRLF] dash-boundary transport-padding CRLF body-part *encapsulation close-delimiter transport-padding [CRLF epilogue] preamble := discard-text transport-padding := *LWSP-char ; Los compositores NO DEBEN generar ; rellenos de transporte, pero ; los receptores DEBEN poder manejar ; relleno añadido por el transporte ; del mensaje. N.Freed Seguimiento de Estándar [Pág. 45]