Resumen

  • RFC 3458 creó el campo opcional Message-Context para describir la interacción prevista con el mensaje completo, no para afirmar qué partes MIME debían existir.
  • Una clasificación equivocada, desconocida o antigua podía orientar funciones locales, pero nunca debía impedir la transferencia ni degradar la presentación respecto de un mensaje sin esa cabecera.

La intención no cabía en el tipo de medio

En 2003, una sola bandeja podía reunir correo convencional, avisos de buscapersonas, fax, grabaciones de voz y documentos multimedia. Dos mensajes de texto podían pedir interacciones distintas: uno se leía como correspondencia; otro podía ser un SMS o la transcripción de una llamada. Inspeccionar un objeto grande solo para elegir icono o visor tampoco era una solución eficiente.

RFC 3458 introdujo una cabecera superior que podía aparecer una vez. Registró inicialmente voice-message, fax-message, pager-message, multimedia-message, text-message y none, sin distinguir mayúsculas; la ausencia equivalía a none. El texto, la ficha del RFC Editor, el expediente, el historial, las referencias, las citas posteriores y los errata definen el registro verificable.

El receptor podía escoger un visor, agrupar o ordenar entradas, reducir lo mostrado por una conexión limitada o sugerir una respuesta. Pero la comodidad no demostraba que hubiese audio, imagen de fax o código ejecutable dentro del cuerpo.

Una pasarela podía cambiar el cuerpo sin borrar su historia

El ejemplo decisivo era un mensaje de voz cuya grabación desaparecía al cruzar una pasarela, mientras sobrevivía la transcripción. Seguía teniendo un origen de mensajería vocal, pero el cliente ya no disponía de sonido. También podía llegar una etiqueta de voz junto a contenido de fax. En ambos casos debía presentar las partes reales.

RFC 2822 regulaba la sintaxis del mensaje; RFC 2183, la disposición de una parte. RFC 2387 y RFC 2557 trataban estructuras compuestas, y RFC 2423 aportaba el contexto VPIM. Message-Context no anulaba ninguna de esas capas.

Por eso, un valor incorrecto no justificaba rechazar el transporte ni dejar una pantalla vacía. El contenido debía mostrarse con, al menos, el mismo sentido que tendría sin la cabecera. El estándar no resolvía cómo reinterpretar un contexto al reenviar; una señal preservada podía quedar obsoleta y debía tratarse como observación, no como verdad.

Ninguna etiqueta autorizaba una acción peligrosa

La advertencia de seguridad prohibía ejecutar un programa solo porque el contexto pareciera pedirlo. Un emisor malicioso podía provocar gasto de recursos, rutas erróneas o atención inmerecida. La cabecera no autenticaba origen ni cuerpo, no otorgaba permisos, no acreditaba entrega y no medía urgencia ni lectura humana.

RFC 3459 definía aparte los parámetros de contenido crítico para partes MIME. RFC 3938 actualizó después la política de registro; RFC 3864 estableció un marco general. El registro de IANA prueba que el campo fue asignado, no que un programa determinado lo aplicara correctamente.

La posterior idea de Heng Lu sobre capas de realidad permite separar declaración y cuerpo recibido. La primacía del código que funciona obliga a observar árbol MIME, transformación y salida de reserva. La especificación inicial mínima explica el valor de un campo pequeño que no absorbe la seguridad ni MIME. Son lentes editoriales posteriores, no pruebas sobre la intención privada de los autores.

RFC 3458 protegió así una diferencia fundamental: el contexto podía preparar la interacción; el cuerpo disponible seguía mandando sobre la lectura.

Fuentes