Resumen

  • MIME dio a cada entidad una etiqueta Content-ID con sintaxis de Message-ID para que otra parte pudiera citarla sin depender de su posición.
  • multipart/related convirtió la etiqueta en una forma de escoger la raíz; cid: y la variante larga de mid: permitieron resolver enlaces dentro del mensaje o del almacén.
  • La unicidad mundial era una regla de generación, no una huella, autenticación ni garantía de recuperación global. El contenedor y el receptor seguían eligiendo la representación y su tratamiento.

La URL que apuntaba al paquete que ya había llegado

El enlace habitual separa un documento del recurso al que llama. En el correo compuesto, ambos podían cruzar la red juntos. Una referencia cid: dentro del HTML buscaba una cabecera de otra parte MIME; no describía necesariamente una conexión futura.

Ese diseño necesitaba algo más duradero que «la segunda pieza». Los sistemas reordenaban, almacenaban o extraían partes, y un mensaje podía contener árboles multipart anidados. El nombre debía sobrevivir a esos movimientos sin convertirse en una dirección de transporte.

RFC 1341 introdujo Content-ID en 1992 entre las cabeceras MIME opcionales. La especificación es conocida por los tipos de medios y la estructura multipart, pero el identificador ocupó una capa distinta. Content-Type decía cómo interpretar los octetos; Content-Transfer-Encoding, cómo habían sido representados; el boundary, dónde terminaba una parte; Content-ID, qué entidad pretendía nombrar una referencia.

En 1996, RFC 2045 reutilizó la sintaxis de Message-ID y exigió valores generados para ser únicos en el mundo. Reutilizar la gramática no igualaba los objetos. Message-ID se refiere al mensaje; Content-ID puede marcar una entidad interna. Los corchetes angulares y la forma de addr-spec aportaban una convención de baja colisión, no una identidad de correo completa.

El RFC señaló la caché como uso central. Una entidad message/external-body puede describir datos disponibles mediante un acceso exterior, y quien la genere debe incluir Content-ID. La caché reconoce así el objeto entre varios accesos. Pero el valor no es un resumen de los octetos. Una coincidencia es una afirmación del compositor; no demuestra integridad ni igualdad criptográfica.

Tampoco existe un directorio universal de Content-ID. «Único en el mundo» limita la creación de colisiones, pero no obliga a un servicio a devolver la parte. El destinatario puede carecer del mensaje, del índice, del permiso o del lector necesario aunque la etiqueta sea válida.

Dos partes podían compartir el nombre con una condición

RFC 2046 impide tratar Content-ID como una clave única sin contexto. multipart/alternative agrupa representaciones de la misma información y deja al receptor escoger la última que sabe mostrar.

Si una conversión pierde información, las partes deberían tener identificadores distintos. Si varias entidades message/external-body son caminos alternativos a datos idénticos, pueden compartir Content-ID para aprovechar la misma caché. Las reglas del padre deciden cuál se usa.

La excepción es pequeña pero decisiva. Rechazar todos los duplicados rompería un mensaje conforme. Aceptarlos fuera de un contenedor con regla de selección dejaría una referencia ambigua. La etiqueta solo produce sentido junto con el árbol MIME y la semántica de su padre.

El objeto compuesto no era una lista de adjuntos

RFC 2110 llevó en 1997 esta idea a documentos HTML empaquetados con sus recursos. Content-ID, URL CID y Content-Location permitían que una página encontrara imágenes incluidas en el mismo correo.

RFC 2387 definió después multipart/related. El contenedor representa partes interdependientes. type anuncia el tipo de la raíz; start puede señalarla mediante Content-ID. Si falta start, la primera parte se convierte en raíz.

Así, el orden ofrece una decisión por defecto y el identificador puede sustituirla. Un intermediario que mueva la raíz debe preservar también la relación. El parámetro type tampoco certifica el contenido: si contradice el Content-Type real de la parte raíz, el comportamiento queda indefinido.

La aplicación compuesta manda sobre sugerencias ordinarias de presentación. Una imagen con nombre de archivo puede ser un componente interno, no un adjunto independiente. Aplanar el mensaje conserva bytes, pero pierde el grafo que decía cómo usarlos.

El prefijo definía una comparación, no un protocolo de descarga

RFC 2392 normalizó cid: y mid:. Para convertir una URL CID en cabecera, el receptor quita cid:, decodifica %hh y encierra el addr-spec entre < y >. La sintaxis hace posible escribir una referencia dentro de HTML u otro cuerpo.

Muchos almacenes indexan mensajes y no cada subparte. Por eso existe la forma larga mid:message-id/content-id: primero establece el mensaje y después la entidad. La implementación debe soportarla. Usar la unicidad para buscar un cid: corto en todo el almacén es opcional.

El esquema no promete una solicitud de red. Describe la resolución contra una estructura MIME. Si no aparece la parte, saltar automáticamente a una URL externa cambia tanto la privacidad como la procedencia. El fallo local no equivale a una caída de Internet.

El RFC conserva los Content-ID repetidos en circunstancias limitadas, como alternativas. La regla del contenedor selecciona. Por eso ni siquiera la intención de unicidad elimina la autoridad del contexto local.

Ubicación e identidad podían etiquetar la misma parte

RFC 2557 sustituyó a RFC 2110 en 1999. Content-Location podía ser una URI absoluta o relativa, interna o no recuperable por el destinatario. Junto con Content-ID, ofrecía otra etiqueta válida, pero no un comprobante de disponibilidad.

Además, la URI del agregado MHTML no era la URI de la raíz. Recuperar el paquete devuelve una instantánea compuesta; pedir la raíz y sus recursos por separado puede obtener versiones distintas. La procedencia del paquete y el resultado de una descarga posterior son evidencias diferentes.

Content-ID funcionó porque no intentó resolverlo todo. Mantuvo una referencia a través de cambios de orden y ubicación. El cliente aún debía encontrar el contexto, elegir una alternativa, decodificar, verificar y decidir si mostrar.