WWW EPI

Mayo 1996

Correo electrónico multimedia

Por Pedro Hípola y José A. Senso

Para superar la pobreza tipográfica de los primeros sistemas de correo electrónico, han surgido nuevos modelos de intercambio de mensajes entre los buzones de los usuarios. El uso de sistemas como BinHex, Mapi (Microsoft´s messaging application programming interface), Mime (Multipurpose Internet mail extensions) o X.400, permite, dentro de Internet, la "libre circulación" de documentos que contengan los más variados materiales multimedia.

Los sistemas más sencillos de correo electrónico fueron diseñados para intercambiar mensajes de texto usando el juego de caracteres ascii norteamericano.

Con 7 bits (128 posibilidades distintas) es posible representar todos los caracteres necesarios para hacerlo.

Así smtp (simple mail transfer protocol), el sistema de correo usado en Internet, regulado por los documentos RFC-821 y RFC-822 [los documentos RFC (request for comments) son los que se utilizan para reglamentar las funciones de Internet, con un proceso mucho más ágil y sencillo que el propio de los documentos ISO (International standards organization)], es un protocolo de 7 bits.

No se previó inicialmente mayor capacidad, pues para la transferencia de ficheros no textuales se contaba con el protocolo ftp (file transfer protocol).

Uuencode

Hasta hace unos años los usuarios que querían transferir por medio de correo electrónico ficheros que contuvieran algo más que caracteres ascii de 7 bits podían sólo recurrir a codificar -ellos personalmente- en 7 bits sus ficheros.

Muchas personas siguen haciendo eso hoy utilizando los programas uuencode y uudecode, presentes normalmente en los sistemas unix, pero de los que también existen versiones para ordenadores con ms-dos y otros sistemas operativos.

Con estos programas el remitente del mensaje se encarga de codificar el fichero convirtiéndolo en una cadena de caracteres de 7 bits. El fichero resultante es incluido dentro de un mensaje Smtp tradicional.

Por su parte, el usuario receptor aplica al mensaje recibido un programa decodificador, que sirve para recuperar el fichero original.

Los attachments

Frente a este sistema de codificación "no transparente", existen hoy formas más evolucionadas y cómodas para el usuario. Son, en definitiva, sistemas más "transparentes": requieren menores conocimientos y menos intervención por parte de quien usa las aplicaciones de correo electrónico.

El método más usado es el del attachment (añadido). Se trata de lo siguiente. El remitente del correo indica que quiere enviar, junto con su mensaje de texto, un fichero de cualquier tipo (un programa, un gráfico, etc.). El sistema de correo se encarga de codificarlo y transmitirlo, dividiéndolo, si es necesario, en varias partes.

Como es natural, es necesario que el programa de correo electrónico del receptor sea capaz de "entender" la codificación utilizada.

Los sistemas de codificación más extendidos son BinHex y Mime.

BinHex se utiliza principalmente entre ordenadores Macintosh, aunque también se ha generalizado su uso en otras plataformas informáticas.

La aceptación y uso de Mime ha sido mucho mayor. Por eso nos detendremos especialmente exponiendo sus características.

Nace Mime

Para facilitar, a través de correo electrónico, el intercambio de ficheros más complejos que los que sólo contenían caracteres de 7 bits, un grupo de trabajo de la Ietf (Internet engineering task force) comenzó a trabajar en Mime.

El nuevo estándar ha quedado recogido en dos documentos, aprobados por la Ietf en 1993: RFC-1521 y RFC-1522. Estos escritos, que no son más que la actualización de las RFC-1341 y RFC-1342, fueron puestos al día, a su vez, en marzo de 1994 por la RFC-1590.

Mime no establece un nuevo protocolo. Tan sólo constituye una forma normalizada de intercambio de mensajes electrónicos multimedia. Este sistema es compatible con los programas de correo electrónico que surgieron a partir de la RFC-821.

Una característica a destacar es que se trata de un sistema multiplataforma, ya que protege el formato binario del fichero, evitando así el tener que convertirlo a ascii antes de leerlo.

Con respecto a los primeros sistemas, Mime dio un paso adelante en "transparencia", ya que las aplicaciones cliente pueden saber automáticamente de qué tipo de formato de fichero se trata, y, por tanto, la codificación y decodificación se realiza de forma transparente para el usuario.

Por otra parte, con Smtp sólo se garantizaba la integridad de mensajes cuya longitud de líneas no excediera los 1000 caracteres. Mime, por contra, divide el contenido del mensaje en múltiples partes que se recomponen, también de forma transparente, cuando el mensaje llega al receptor.

Tipos de codificación

Mime permite que sea la aplicación del usuario la que elija el tipo de codificación que se utilizará para el contenido del mensaje. Las diferentes clases de codificación son:

• 7 bit, 8 bit y binary: la primera indica que el contenido es texto, con líneas de longitud compatible con Smtp. Cuando se indica 8 bits se advierte de la posibilidad de que en la transmisión existan caracteres no ascii (vocales acentuadas, por ejemplo). La opción binary avisa que el contenido y la longitud de línea puede ser cualquiera.
• base64: con este método se aplica una codificación de 8 a 7 bits, de tal forma que de cada tres bytes de entrada se generan cuatro de salida.
• quoted-printable: se conservan los caracteres de 7 bit. Además se forman las letras especiales de cada idioma con un código de escape y una letra del conjunto primario. Ésta es la opción elegida en idiomas que emplean el alfabeto latino (v. Carles Bellver Torlà , "ISO 8859: sopa de caracteres", en IWE-33, p. 16-18).

En la cabecera del mensaje existe un campo donde se representa el tipo de codificación elegida. Si, por ejemplo, se ha seleccionado la tercera modalidad, el campo indicaría lo siguiente:

Content-Transfer-Encoding: quoted-printable

Tipos de formato

En el mundo multimedia existe gran cantidad de formatos, tanto para imágenes como para audio. Éste fue el motivo de que Mime se decantara por agrupar estos formatos según el contenido, y, dentro de cada contenido, se escogieron dos o tres subtipos iniciales.

Con el fin de evitar conflictos, las futuras implementaciones de la norma deben registrar nuevos subtipos ante el Iana (Internet assigned numbers authority). No obstante, se pueden especificar subtipos particulares utilizando el prefijo X-, sin necesidad de que sean aprobados y registrados. Por ejemplo,

video/x-msvideo

se utiliza para especificar ficheros de Video for Windows, el estándar de Microsoft, habitualmente reconocible por la extensión .avi.

Los siete tipos de contenido definidos originariamente para la norma Mime fueron:

• Texto: dentro de esta modalidad se eligieron los subtipos plain (texto ascii sin formatear) y richtext. Se contempló, además, la posibilidad de adjuntar texto realizado mediante procesador. Se admitió la norma ISO 8859 [1-9] e ISO 2022 (para texto Kanji, el alfabeto japonés).
• Multiparte: para mensajes formados por diferentes tipos de formatos entrelazados entre sí y visualizados mezclados, de forma secuencial o en paralelo (una imagen y un sonido que haga referencia a la acción desarrollada en la imagen).
• Imagen: los dos formatos que se admitieron en un principio fueron GIF (graphics interchange format) y Jpeg (joint photographic experts group). Se eligieron estas dos extensiones gráficas por ser las más extendidas y porque para ellos existe mayor cantidad de software de dominio público utilizable en la mayoría de las plataformas informáticas.
• Audio: el subtipo definido originariamente fue Basic, sonido de calidad de telefonía básica, con un único canal de 8000 Hz.
• Vídeo: el subtipo inicial, al igual que ocurrió con el tipo imagen, correspondió a un formato en concreto, el Mpeg (v. IWE-38, José A. Senso, "Sistemas multimedia: el vídeo digital", p.15-16).
• Mensaje: este tipo se usa para encapsular un mensaje de correo. Contiene tres subtipos; RFC-822, Partial (para fragmentar un mensaje en varias partes) y External Body (textos creados por una fuente ajena al programa de correo).
• Aplicación: para cualquier otro tipo de información que no puede ser interpretada como dato binario y necesita ser procesada por una aplicación. Los subtipos originariamente definidos fueron Octet-Stream, Postscript y ODA (open document architecture) (v. Pedro Hípola, "Edición electrónica: ¿con qué formato?", en IWE-31, p.1-8).

El campo que determina el tipo de formato escogido se especifica en la cabecera del mensaje, presentando la siguiente sintaxis:

Content-Type: tipo/subtipo; parámetro

Así, Content-Type: text/plain; charset=ISO-8859-5 indicaría que el contenido del mensaje es un texto en el que se ha utilizado el conjunto de caracteres ISO 8859-5 (ISO alfabeto árabe).

La lista actualizada de los subtipos registrados puede encontrarse en:

http://www.isi.edu/in‑notes/iana/assignments/media‑types/

El grupo de trabajo contempló la posibilidad de incluir dentro de este esquema inicial los ficheros codificados según el método uuencode. Se rechazó esta posibilidad por la carencia de una especificación única del método que fuera compatible con todos los programas que había en el mercado.

Se decidió que los ficheros uuencode podrían ser incluidos bajo la etiqueta base64.

Mime y web

La clasificación de formatos de ficheros Mime se ha utilizado como base para el funcionamiento de los browsers web. Éstos reconocen los subtipos Mime especificados (y otros identificados con prefijos x-) y analizan la codificación normalizada por Iana para "decidir" qué es lo que se debe hacer con los ficheros que se reciben a través de la Red.

Dentro de la configuración del browser, el usuario puede definir qué aplicaciones serán las encargadas de procesar los diversos ficheros. Así, un fichero de vídeo quicktime será visualizado con una aplicación específica que sea capaz de gestionar ese tipo de formato.

El universo X.400

El sistema X.400, integrado dentro del esquema OSI (open systems interconnection), se desarrolló, desde sus comienzos en 1984, pensando en el correo multimedia, al recoger la idea de "tipos de contenido" y "partes del cuerpo de un mensaje".

Los tipos de contenido que admite pueden ser voz, g3fx, mensaje encapsulado, texto encriptado, T.61 (colección de caracteres usados en el télex) e IA5 (conjunto universal de caracteres, que usa 8 bits). A pesar de permitir el uso de voz e imagen, no se especifica el método de codificación de voz, así como tampoco se decanta por ningún formato gráfico en concreto.

El hecho de tener en cuenta las partes del cuerpo de un mensaje supone que el protocolo transfiere las partes de un mensaje como unidades de datos distintas, añadiendo información de control sobre los diferentes tipos de contenido que forman el mensaje.

En contraposición con Mime, X.400 es un sistema más robusto y que cuenta con protocolos más complejos.

En el X.400 de 1988 se definen, de forma específica, varios tipos de contenido básicos, añadiendo un nuevo tipo de cuerpo denominado EBP3 (extended body part), que soporta varios juegos de caracteres (entre ellos us-ascii e ISO 8859 [1-9]) y que facilita la posibilidad de definir nuevos formatos fuera de la norma.

A pesar de que en la actualización de 1988 continúe sin estar especificado el formato de imagen y la codificación de voz, EBP3 permite integrar formatos idénticos a los definidos por Mime.

La interoperatividad entre X.400 (84) y Mime pasa siempre por X.400 (88). No obstante, en la RFC-1496 se define un nuevo estándar, llamado Harpoon, con el que se pretende conseguir la interoperatividad entre ambos sistemas.

Microsoft no se queda atrás

Ya va siendo habitual que Microsoft tenga respuesta para todo. La propuesta de la empresa americana se denomina Mapi (messaging application programming interface).

Como su propio nombre indica, se trata de una API, una "interfaz para el desarrollo de aplicaciones". Esto es, una serie de funciones ofrecidas por Microsoft que pueden ser utilizadas por las distintas empresas que desarrollan aplicaciones de correo existentes para el mercado.

Usando Mapi, los diversos sistemas de correo que funcionen bajo Windows pueden integrar "objetos" OLE (object linking and embedding) dentro del entorno de trabajo diseñado por Microsoft.

Como ya explicamos en IWE-31, p. 1-8, OLE es un sistema "orientado a objetos" en el que el "documento" es el centro, y todo gira en torno a él. Éste puede integrar en su seno una serie de elementos -textos, gráficos, tablas, imágenes, sonido...- creados por diferentes aplicaciones y que permanecen ligados a ellas.

Cada parte del documento puede más adelante ser modificada utilizando una aplicación distinta, y conservando siempre su relación con el resto de las partes.

Desde el punto de vista orgánico, la información de los documentos se almacena en diferentes ficheros, lo que permite una mayor flexibilidad al sistema: cada aplicación puede operar sobre los correspondientes ficheros.

Bibliografía adicional

Además de los documentos ya citados, puede consultarse:

Mozos, Ignacio de los. "Multimedia II: correo electrónico estructurado con gráficos, audio, datos y múltiples conjuntos de caracteres". En: Boletín de RedIris, nº 25-26, oct. 1993, p. 54-64.

Borenstein, Nathaniel S. "Mime: a portable and robust multimedia format for the Internet mail". En: Multimedia Systems, 1993, 1, p. 29-36.

Enlace del artículo:
http://www.elprofesionaldelainformacion.com/contenidos/1996/mayo/correo_electrnico_multimedia.html