| Control de autoridades |
|
|---|
Datos: Q192902
Multipurpose Internet Mail Extensions o MIME (en español "extensiones multipropósito de correo de internet") son una serie de convenciones o especificaciones dirigidas al intercambio a través de Internet de todo tipo de archivos (texto, audio, vídeo, etc.) de forma transparente para el usuario. Una parte importante del MIME está dedicada a mejorar las posibilidades de transferencia de texto en distintos idiomas y alfabetos. En sentido general las extensiones de MIME van encaminadas a admitir:
Prácticamente todos los mensajes de correo electrónico escritos por personas en Internet y una proporción considerable de estos mensajes generados automáticamente son transmitidos en formato MIME a través de SMTP. Los mensajes de correo electrónico en Internet están tan cercanamente asociados con el SMTP y MIME que usualmente se les llama mensaje SMTP/MIME.[1]
En 1991 la IETF comenzó a desarrollar esta norma y desde 1994 todas las extensiones MIME están especificadas de forma detallada en diversos documentos oficiales disponibles en Internet.
MIME está especificado en seis solicitudes de comentarios (RFC): RFC 2045, RFC 2046, RFC 2047, RFC 2077, RFC 4288 y RFC 4289.
Los tipos de contenido definidos por el estándar MIME tienen gran importancia también fuera del contexto de los mensajes electrónicos. Ejemplo de esto son algunos protocolos de red tales como HTTP de la Web. HTTP requiere que los datos sean transmitidos en un contexto de mensajes tipo correo electrónico aunque los datos pueden no ser un mensaje de correo electrónico propiamente dicho.
En la actualidad ningún programa de correo electrónico o navegador de Internet puede considerarse completo si no acepta MIME en sus diferentes facetas (texto y formatos de archivo).
El protocolo básico de transmisión de mensajes electrónicos de Internet soporta solo caracteres ASCII de 7 bit (véase también 8BITMIME). Esto limita los mensajes de correo electrónico, ya que incluyen solo caracteres suficientes para escribir en un número reducido de lenguajes, principalmente Inglés. Otros lenguajes basados en el Alfabeto latino es adicionalmente un componente fundamental en protocolos de comunicación como HTTP, el que requiere que los datos sean transmitidos como un mensaje de correo electrónico aunque los datos pueden no ser un mensaje de correo electrónico propiamente dicho. Los clientes de correo y los servidores de correo convierten automáticamente desde y a formato MIME cuando envían o reciben (SMTP/MIME) correos electrónicos.
MIME asigna un nombre a cada tipo de datos. Los nombres siguen el siguiente formato:
tipo/subtipo (tipo como subtipo son cadenas de caracteres)
El tipo define la categoría general de los datos y el subtipo define un tipo más específico de esos datos. El tipo puede contener los siguientes valores:
La presencia de este encabezado indica que el mensaje utiliza el formato MIME. Su valor es típicamente igual a "1.0" por lo que este encabezado aparece como:
MIME-Versión: 1.0
Debe señalarse que los implementadores han intentado cambiar el número de versión en el pasado y el cambio ha tenido resultados imprevistos. En una reunión de IETF realizada en julio de 2007 se decidió mantener el número de versión en "1.0" aunque se han realizado muchas actualizaciones a la versión de MIME.
Este encabezado indica el tipo de medio que representa el contenido del mensaje, consiste en un tipo: type y un subtipo: subtype, por ejemplo:
Content-Type: text/plain
A través del uso del tipo multiparte (multipart), MIME da la posibilidad de crear mensajes que tengan partes y subpartes organizadas en una estructura arbórea en la que los nodos hoja pueden ser cualquier tipo de contenido no multiparte y los nodos que no son hojas pueden ser de cualquiera de las variedades de tipos multiparte. Este mecanismo soporta:
Content-Type: application/vnd.oasis.opendocument.text;
name="Carta.odt"
Content-Disposition: inline;
filename="Carta.odt"
En junio de 1992, MIME (RFC 1341 queda obsoleta por la nueva RFC 2045) define un conjunto de métodos para representar datos binarios usando texto ASCII. El encabezado MIME content-transfer-encoding: indica el método que ha sido usado. La RFC y la lista de IANA definen los siguientes valores, que no son sensibles a mayúsculas ni minúsculas:
No existe una codificación definida explícitamente para enviar datos binarios arbitrarios a través de un transporte SMTP con las extensiones 8BITMIME. Por tanto base64 o quoted-printable (con sus ineficiencias asociadas) tienen que ser usadas aún. Estas restricciones no se aplican a otros usos de MIME como son Servicios Web con adjuntos MIME o MTOM
Desde la RFC 2822, los nombres y valores de los encabezados MIME de mensajes son siempre caracteres ASCII; los valores que contengan otro tipo de caracteres tienen que usar la sintaxis de palabra codificada o encoded-word (RFC 2047) en lugar del texto literal. Esta sintaxis utiliza una cadena de caracteres ASCII que indica el conjunto de caracteres original (el "charset") y el content-transfer-encoding usado para mapear los bytes del conjunto original a caracteres ASCII.
Su forma general es:
=?charset?codificación?texto codificado?=
Q" que denota Q-encoding que es similar a la codificación quoted-printable, o "B" que denota la codificación base64.Los códigos ASCII del signo de pregunta (?) y el signo de igualdad (=) no pueden ser representados directamente dado que ellos son usados como delimitadores del encoded-word. El código ASCII reservado para el espacio no puede ser representado directamente porque puede ocasionar que intérpretes antiguos dividan, de forma no deseada, el encoded-word. Para hacer la codificación más pequeña y fácil de leer, el símbolo subrayado (_) se utiliza en lugar del espacio, creando el efecto colateral que este símbolo no se pueda representar directamente. El uso de encoded-word en ciertas partes de los encabezados impone otras restricciones sobre cuáles caracteres pueden o no ser representados directamente.
Por ejemplo:
Subject: =?utf-8?Q?=C2=A1Hola,_se=C3=B1or!?=
es interpretado como:
Subject: ¡Hola, señor!
El formato encoded-word no se utiliza para los nombres de los encabezados (por ejemplo Subject). Estos nombres de encabezados son siempre en inglés. Cuando se lee el mensaje con un cliente de correo en otro idioma que no sea Inglés, los nombres de los encabezados son traducidos por el cliente.
Un mensaje MIME multiparte contiene una frontera en el encabezado "Content-type:"; esta frontera, que no puede aparecer en ninguna de las partes, es ubicada entre cada una de ellas, y al inicio y al final del cuerpo del mensaje, como se muestra a continuación:
MIME-Versión: 1.0 Content-type: multipart/mixed; boundary="frontera" This is a multi-part message in MIME format. --frontera Content-type: text/plain Este es el cuerpo del mensaje --frontera Content-type: application/octet-stream Content-transfer-encoding: base64 PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+RXN0ZSBlcyBlbCBjdWVy cG8gZGVsIG1lbnNhamU8L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cic=\ --frontera--
Cada parte consiste de su propio encabezado de contenido (cero o más campos de encabezados Content-) y un cuerpo. El contenido multiparte puede estar anidado. El encabezado content-transfer-encoding de un tipo multiparte tiene siempre que ser "7bit", "8bit" o "binary" para evitar las complicaciones impuestas con la presencia de múltiples niveles de decodificación. El bloque multiparte, como un todo, no tiene especificación acerca del conjunto de caracteres (charset); los caracteres no ASCII en los encabezados de la parte son manejados a través de Encoded-Word, y los cuerpos de las partes pueden tener conjuntos de caracteres especificados si aplicase para su tipo de contenido.
Notas:
El estándar MIME define varios subtipos para mensajes multiparte, estos especifican la naturaleza de la parte del mensaje y su relación con otras partes. El subtipo es especificado en el encabezado "Content-type" para todo el mensaje. Por ejemplo, un mensaje MIME multiparte que usa el subtipo digest tendrá un "Content-Type": "multipart/digest".
La RFC inicialmente define 4 subtipos: mixed, digest, alternate y parallel. Una aplicación que cumpla mínimamente el estándar debe soportar al menos mixed y digest; el resto de los subtipos son opcionales. Otras RFCs definen subtipos adicionales como: signed y form-data.
Lo que sigue es una lista de los subtipos más comúnmente usados:
Multipart/mixed es usado para enviar mensajes o archivos con diferentes encabezados "Content-Type" ya sea en línea o como adjuntos. Si se envían imágenes u otros archivos fácilmente legibles, la mayoría de los clientes de correo electrónico las mostrarán como parte del mensaje (a menos que se especifique de manera diferente el encabezado "Content-disposition"). De otra manera serán ofrecidos como adjuntos. El content-type implícito para cada parte es "text/plain".
Definido en RFC 2046, Sección 5.1.3
Una parte message/rfc822 contiene un mensaje de correo electrónico, incluyendo cualquier encabezado. Rfc822 es un nombre erróneo, dado que el mensaje puede ser un mensaje MIME completo. Es usado también para resúmenes el reenviar mensajes.
Definido en la RFC 2046.
Multipart/digest es una forma simple de enviar múltiples mensajes de texto. El content-type implícito para cada parte es "message/rfc822".
Definido en RFC 2046, Sección 5.1.5.
El subtipo multipart/alternative indica que cada parte es una versión "alternativa" del mismo contenido (o similar), cada una en formatos diferentes denotados por su encabezado "Content-Type". Los formatos son ordenados atendiendo a cuan fieles son al original, con el menos fiel al inicio. Los sistemas pueden escoger la "mejor" representación que ellos son capaces de procesar; en general esta será la última parte que el sistema entiende, a menos que otros factores puedan afectar este comportamiento.
Dado que es poco probable que un cliente quiera enviar una versión que es poco fiel a la versión en texto plano, esta estructura ubica la versión en texto plano (si existe) primero. Esto facilita la tarea de leer los mensajes para los usuarios de clientes que no entienden mensajes multipartes.
Lo que ocurre más comúnmente es usar multipart/alternative para mensajes con dos partes, una como texto plano (text/plain) y una HTML (text/html). La parte en texto plano provee compatibilidad con clientes viejos que no son capaces de entender otros formatos, mientras que la parte HTML permite usar formato de texto y enlaces. Muchos clientes de correo ofrecen al usuario la posibilidad de preferir texto plano sobre HTML; esto es un ejemplo de como factores locales pueden afectar cómo una aplicación selecciona cuál es la "mejor" parte del mensaje para mostrar.
Aunque se pretende que cada parte represente el mismo contenido, esto no es requerido. Algunos filtros antispam examinan únicamente la parte text/plain de un mensaje porque es más fácil de analizar que las partes text/html. Pero los spammers al notar esto, comenzaron a crear mensajes con una parte text/plain que aparenta ser inocua e incluyen la propaganda en la parte text/html. Los mantenedores de programas antispam han modificado sus filtros, penalizando a los mensajes con textos muy diferentes en un mensaje multipart/alternative.
Definido en RFC 2046, Sección 5.1.4
El subtipo multipart/related es usado para indicar que las partes del mensaje no deben ser consideradas individualmente sino como agregados de un todo. El mensaje consiste de una parte raíz (implícitamente la primera) que hace referencia a otras partes, las que a su vez pueden hacer referencia a otras partes. Las partes son comúnmente referenciadas por el encabezado: "Content-ID". La sintaxis de la referencia no está especificada sino que está dictada por la codificación o el protocolo usado en la parte que contiene la referencia.
Un uso común de este subtipo es para enviar páginas web completas con imágenes en un único mensaje. La parte raíz contendría el documento HTML, que usaría etiquetas HTML para imágenes, para referirse a las imágenes almacenadas en partes subsiguientes.
Definido en RFC 2387
Multipart/report es un tipo de mensaje que contiene datos formateados para que un servidor de correo lo interprete. Está entre un text/plain (o algún otro tipo de contenido fácilmente legible) y un message/delivery-status.
Definido en RFC 3462
El subtipo multipart/signed es usado para adjuntar una firma digital al mensaje. Esta tiene dos partes, una parte cuerpo y una parte firma. La parte del cuerpo completa, incluyendo los encabezados MIME, es usada para crear la parte de la firma. Existen muchos tipos de firmas, como application/pgp-signature y application/x-pkcs7-signature.
Definido en RFC 1847, Sección 2.1
Un mensaje multipart/encrypted tiene dos partes. La primera contiene información de control que es necesaria para descifrar la segunda parte, de tipo: application/octet-stream.
Definido en RFC 1847, Sección 2.2
Como su nombre lo indica, multipart/form-data es usada para expresar valores enviados a través de un formulario. Originalmente definido como parte de HTML 4.0, es mayormente utilizado para enviar archivos vía HTTP.
Definido en RFC 2388
El tipo de contenido multipart/x-mixed-replace fue desarrollado como parte de una tecnología para emular server push y streaming sobre HTTP.
Todas las partes de un mensaje mixed-replace poseen el mismo significado semántico. Sin embargo, cada parte invalida - "reemplaza" - a la parte previa tan pronto como es recibida completamente. Los clientes deben procesar la parte individual al momento de su llegada y no deben esperar a que termine el mensaje completo.
Desarrollado originalmente por Netscape, aún es soportado por Mozilla, Firefox, Safari (pero no en Safari para iPhone) y Opera, pero tradicionalmente ignorada por Microsoft.