MÍMICA

La presencia de este campo de encabezado indica que el mensaje tiene formato MIME. Su valor suele ser "1.0". El campo aparece de la siguiente manera:

Versión MIME: 1.0

Según Nathaniel Borenstein , cocreador de MIME , el número de versión se introdujo para permitir cambios en el protocolo MIME en versiones posteriores. Sin embargo, Borenstein admitió deficiencias en la especificación que dificultaron la implementación de esta característica:

No especificamos adecuadamente cómo manejar una futura versión MIME. ... Entonces, si escribes algo que conoce la versión 1.0, ¿qué debes hacer si te encuentras con la 2.0 o la 1.1? Pensé que era obvio, pero resultó que cada uno lo implementó de manera diferente. Y el resultado es que sería prácticamente imposible que Internet definiera alguna vez una versión 2.0 o una 1.1. ^{[ 2 ]}

The original MIME specifications only described the structure of mail messages. They did not address the issue of presentation styles. The content-disposition header field was added in RFC 2183 to specify the presentation style. A MIME part can have:

• an inline content disposition, which means that it should be automatically displayed when the message is displayed, or
• an attachment content disposition, in which case it is not displayed automatically and requires some form of action from the user to open it.

In addition to the presentation style, the field Content-Disposition also provides parameters for specifying the name of the file, the creation date and modification date, which can be used by the reader's mail user agent to store the attachment.

The following example is taken from RFC 2183, where the header field is defined:

Content-Disposition: attachment; filename=genome.jpeg; modification-date="Wed, 12 Feb 1997 16:29:51 -0500";

The filename may be encoded as defined in RFC 2231.

As of 2010, a majority of mail user agents did not follow this prescription fully. The widely used Mozilla Thunderbird mail client ignores the content-disposition fields in the messages and uses independent algorithms for selecting the MIME parts to display automatically. Thunderbird prior to version 3 also sends out newly composed messages with inline content disposition for all MIME parts. Most users are unaware of how to set the content disposition to attachment.^[3] Many mail user agents also send messages with the file name in the name parameter of the content-type header instead of the filename parameter of the header field Content-Disposition. This practice is discouraged, as the file name should be specified either with the parameter filename, or with both the parameters filename and name.^[4]

In HTTP, the response header field Content-Disposition: attachment is usually used as a hint to the client to present the response body as a downloadable file. Typically, when receiving such a response, a Web browser prompts the user to save its content as a file, instead of displaying it as a page in a browser window, with filename suggesting the default file name.

En junio de 1992, MIME (RFC 1341, posteriormente obsoleto por RFC 2045) definió un conjunto de métodos para representar datos binarios en formatos distintos al formato de texto ASCII. El campo de encabezado MIME content-transfer-encoding: tiene un significado bidireccional:

• Indica si se ha utilizado o no un esquema de codificación de binario a texto además de la codificación original especificada en el encabezado Content-Type:

1. Si se ha utilizado algún método de codificación de binario a texto, se indica cuál.
2. En caso contrario, proporciona una etiqueta descriptiva para el formato del contenido, con respecto a la presencia de contenido binario o de 8 bits.

La RFC y la lista de codificaciones de transferencia de la IANA definen los valores que se muestran a continuación, que no distinguen entre mayúsculas y minúsculas. '7bit', '8bit' y 'binary' significan que no se utilizó ninguna codificación binaria a texto además de la codificación original. En estos casos, el campo de encabezado es redundante para que el cliente de correo electrónico decodifique el cuerpo del mensaje, pero aún puede ser útil como indicador del tipo de objeto que se está enviando. Los valores ' quoted-printable ' y ' base64 ' le indican al cliente de correo electrónico que se utilizó un esquema de codificación binaria a texto y que es necesaria una decodificación inicial adecuada antes de que el mensaje pueda leerse con su codificación original (por ejemplo, UTF-8).

• Adecuado para su uso con SMTP normal:
  • 7 bits : hasta 998 octetos por línea del rango de código 1..127, con CR y LF (códigos 13 y 10 respectivamente) permitidos únicamente como parte de un final de línea CRLF. Este es el valor predeterminado.
  • quoted-printable : se utiliza para codificar secuencias de octetos arbitrarias en un formato que cumple con las reglas de 7 bits. Está diseñado para ser eficiente y, en su mayor parte, legible para humanos cuando se utiliza para datos de texto que consisten principalmente en caracteres US-ASCII, pero que también contienen una pequeña proporción de bytes con valores fuera de ese rango.
  • Base64 : se utiliza para codificar secuencias de octetos arbitrarias en un formato que cumple con las reglas de 7 bits. Está diseñado para ser eficiente con datos binarios y de 8 bits que no son texto. A veces se utiliza para datos de texto que frecuentemente usan caracteres que no son US-ASCII.
• Adecuado para su uso con servidores SMTP que admiten la extensión SMTP 8BITMIME (RFC 6152):
  • 8 bits : hasta 998 octetos por línea, con CR y LF (códigos 13 y 10 respectivamente) que solo pueden aparecer como parte de un final de línea CRLF.
• Adecuado para su uso con servidores SMTP que admiten la extensión SMTP BINARYMIME (RFC 3030):
  • binario – cualquier secuencia de octetos.

No existe ninguna codificación definida específicamente para enviar datos binarios arbitrarios mediante protocolos SMTP con la extensión 8BITMIME. Por lo tanto, si BINARYMIME no es compatible, base64 o quoted-printable (con su consiguiente ineficiencia) pueden resultar útiles en ocasiones. Esta restricción no se aplica a otros usos de MIME, como los servicios web con archivos adjuntos MIME o MTOM .

Los códigos ASCII para el signo de interrogación ("?") y el signo de igual ("=") no se pueden representar directamente, ya que se utilizan para delimitar la palabra codificada. El código ASCII para el espacio tampoco se puede representar directamente porque podría provocar que los analizadores sintácticos antiguos dividan la palabra codificada de forma indeseada. Para que la codificación sea más pequeña y fácil de leer, se utiliza el guion bajo para representar el código ASCII del espacio, lo que tiene como efecto secundario que el guion bajo no se pueda representar directamente. El uso de palabras codificadas en ciertas partes de los campos de encabezado impone restricciones adicionales sobre qué caracteres se pueden representar directamente.

Por ejemplo,

Subject: =?iso-8859-1?Q?=A1Hola,_se=F1or!?=

se interpreta como "Asunto: ¡Hola, señor!".

El formato de palabra codificada no se utiliza para los nombres de los campos de encabezado (por ejemplo, Asunto ). Estos nombres suelen ser términos en inglés y siempre aparecen en ASCII en el mensaje original. Al visualizar un mensaje con un cliente de correo electrónico que no esté en inglés, es posible que el cliente traduzca los nombres de los campos de encabezado.

El estándar MIME define varios subtipos de mensajes multipartes, que especifican la naturaleza de las partes del mensaje y su relación entre sí. El subtipo se especifica en el Content-Typecampo de encabezado del mensaje completo. Por ejemplo, un mensaje MIME multipartes que utilice el subtipo digest se definiría Content-Typecomo "multipart/digest".

Inicialmente, la RFC definió cuatro subtipos: mixto, resumen, alternativo y paralelo. Una aplicación que cumpla con los requisitos mínimos debe admitir los subtipos mixto y resumen; los demás subtipos son opcionales. Las aplicaciones deben tratar los subtipos no reconocidos como "multipart/mixed". Posteriormente, se han definido subtipos adicionales, como signed y form-data, en otras RFC.

• RFC 1426 , Extensión del servicio SMTP para transporte MIME de 8 bits . J. Klensin , N. Freed , M. Rose , E. Stefferud , D. Crocker. Febrero de 1993. 
• RFC 1847 , Seguridad de múltiples partes para MIME: Multipart/Signed y Multipart/Encrypted 
• RFC 3156 , Seguridad MIME con OpenPGP 
• RFC 2045 , MIME Parte Uno: Formato de los cuerpos de los mensajes de Internet 
• RFC 2046 , MIME Parte Dos: Tipos de Medios . N. Freed, Nathaniel Borenstein . Noviembre de 1996. 
• RFC 2047 , Parte tres de MIME: Extensiones de encabezado de mensaje para texto no ASCII . Keith Moore . Noviembre de 1996. 
• ( RFC 4288 , Parte cuatro de MIME: Especificaciones de tipo de medio y procedimientos de registro . Obsoleto por RFC 6838). 
• RFC 6838 , Especificaciones de tipo de medio y procedimientos de registro . J. Klensin , N. Freed , T. Hansen. Enero de 2013. (Sustituye a RFC 4288). 
• RFC 4289 , Parte cuatro de MIME: Procedimientos de registro . J. Klensin , N. Freed . Diciembre de 2005. 
• RFC 2049 , MIME Parte Cinco: Criterios de conformidad y ejemplos . N. Freed , N. Borenstein. Noviembre de 1996. 
• RFC 2183 , Comunicación de información de presentación en mensajes de Internet: El campo de encabezado Content-Disposition . Troost, R., Dorner, S. y K. Moore. Agosto de 1997. 
• RFC 2231 , Extensiones de valores de parámetros MIME y palabras codificadas: conjuntos de caracteres, idiomas y continuaciones . N. Freed , K. Moore. Noviembre de 1997. 
• RFC 2387 , El tipo de contenido MIME Multipart/Related 
• RFC 1521 , Mecanismos para especificar y describir el formato de los cuerpos de los mensajes de Internet 
• RFC 7578 , Devolución de valores desde formularios: multipart/form-data