Resumo

  • O MIME atribuiu a uma entidade de corpo um Content-ID com a sintaxe de Message-ID, permitindo que outra parte a citasse sem depender da ordem ou de um endereço externo.
  • multipart/related usou o identificador para escolher a raiz de um objeto composto, enquanto cid: e o formato longo de mid: levaram o mesmo valor para links.
  • A exigência de geração mundialmente única não produziu um hash, uma prova de autoria nem disponibilidade global. O contêiner e o aplicativo receptor continuaram decidindo o resultado.

Um endereço podia apontar para dentro

No modelo habitual da Web, um endereço leva o cliente para fora do documento. No correio MIME surgiu uma direção diferente: o HTML e a imagem viajavam no mesmo pacote, e o link servia para reencontrar um componente na árvore recebida. Nenhum servidor precisava responder para que o documento fosse montado.

A necessidade não se resolvia com nomes de arquivo ou números de posição. Gateways podiam reorganizar as partes, arquivos de correio podiam extrair anexos e uma estrutura recursiva podia conter vários conjuntos compostos. “Terceira parte” deixava de significar a mesma coisa depois de uma transformação perfeitamente legítima.

Em 1992, a RFC 1341 ampliou o corpo simples do correio da Internet para entidades tipadas e multipartes. Entre os campos opcionais, introduziu Content-ID e Content-Description. O primeiro criava uma referência técnica; o segundo podia descrever a entidade em linguagem humana. Content-Type dizia como interpretar os bytes decodificados, Content-Transfer-Encoding dizia como eles atravessavam o transporte, e a fronteira multipart delimitava blocos. Content-ID respondia a outra pergunta: qual entidade um vínculo pretendia indicar.

A RFC 2045, publicada em 1996, deu precisão ao contrato. O valor segue a sintaxe de Message-ID e deve ser gerado para ser único no mundo. A forma compartilhada não funde os papéis. Message-ID identifica a mensagem inteira; Content-ID rotula uma entidade MIME, que pode estar profundamente aninhada.

O documento mencionou o uso em cache. Uma entidade message/external-body descreve dados obtidos por um mecanismo externo e, quando esse tipo é gerado, Content-ID é obrigatório. Um cache pode reconhecer o mesmo conteúdo por trás de instruções de acesso alternativas. Mas o valor não é calculado a partir dos octetos. É uma afirmação de identidade feita pelo compositor, não uma prova criptográfica. A unicidade de geração também não cria um catálogo público, um registro DNS ou um origin HTTP capaz de entregar o objeto.

A exceção aos duplicados explicava o nível do rótulo

Seria conveniente tratar Content-ID como uma chave primária de cada nó serializado. A RFC 2046 mostrou por que isso seria incorreto ao definir multipart/alternative. As partes ali apresentam a mesma informação em formatos diferentes, e o destinatário normalmente escolhe a última que consegue processar.

Se uma conversão perde informação, as representações devem receber identificadores diferentes. Por outro lado, várias partes message/external-body que oferecem caminhos distintos para dados idênticos podem compartilhar o Content-ID. O cache reconhece uma identidade, e a regra do multipart escolhe uma representação.

O identificador, portanto, expressa a identidade de conteúdo pretendida dentro de uma estrutura; ele não garante que cada bloco delimitado por boundary tenha uma chave exclusiva. Rejeitar toda repetição destrói alternativas válidas. Aceitá-la em qualquer contêiner permite ambiguidades e desvios. O pai da entidade faz parte da evidência necessária para interpretar o valor.

Um conjunto relacionado precisava declarar sua raiz

Uma página HTML com imagens não é apenas uma lista de anexos. Um componente organiza os demais, e exibi-los de forma independente perde a relação. A RFC 2110 padronizou em 1997 uma primeira encapsulação MHTML para documentos agregados, conectando Content-ID, URLs CID e Content-Location.

Em 1998, a RFC 2387 definiu o contêiner geral multipart/related. Seu parâmetro type anuncia o tipo de mídia da raiz. O parâmetro opcional start aponta, por Content-ID, para a parte que deve ser processada primeiro. Na ausência de start, a primeira parte do corpo é a raiz.

A ordem fornecia uma escolha padrão; o identificador podia substituí-la. Se um gateway movesse a raiz sem preservar ou reescrever start, mudaria o sentido do pacote apesar de manter todos os bytes. Ao mesmo tempo, start só pode ser resolvido no objeto relacionado correto. Quando type diverge do Content-Type real da raiz, a RFC deixa indefinido o comportamento do agente de usuário.

As regras do objeto composto também podiam prevalecer sobre a apresentação normal de um anexo. Um nome de arquivo ajuda a salvar uma imagem, mas não determina se ela é uma peça independente ou uma dependência indispensável do documento. Extrair conteúdo e abandonar os vínculos é preservar os materiais sem preservar a obra montada.

cid: transformava um cabeçalho em sintaxe de link

A RFC 2392 definiu as formas de URL para Message-ID e Content-ID. Um CID URL é composto por cid: e um addr-spec codificado para URL. Para compará-lo ao cabeçalho, a implementação remove o prefixo, decodifica os caracteres percentuais e restaura os sinais de menor e maior. O valor recuperado pode então ser confrontado diretamente com os campos Content-ID da árvore MIME.

O formato de URL não impõe um protocolo de transporte. Ele descreve um procedimento de resolução dentro da estrutura MIME. Muitos armazenamentos indexam mensagens, mas não todas as partes internas. Por isso a RFC definiu o formato longo mid:message-id/content-id e exigiu que implementações conformes o suportassem: a primeira parcela encontra a mensagem; a segunda, a entidade dentro dela.

O cid: curto costuma ficar restrito a outras partes da mesma mensagem. Um armazenamento pode aproveitar a convenção de unicidade para procurar mais longe, mas essa extensão não é um serviço universal. A RFC 2392 ainda reconhece casos limitados em que uma mensagem contém partes com o mesmo Content-ID; as regras da entidade contenedora determinam qual candidato o URL representa.

Localização era uma alegação distinta

A RFC 2557 substituiu a RFC 2110 em 1999 e separou Content-ID, Content-Location e Message-ID como rótulos diferentes. Content-Location pode carregar um URI absoluto ou relativo sem prometer que o destinatário conseguirá recuperá-lo. O endereço pode funcionar apenas em um domínio fechado ou até ser fictício, servindo somente para relacionar referências do documento a componentes do pacote.

Isso não torna o campo inútil. Ele registra a localização conceitual de uma representação e ajuda a resolver links quando o conteúdo já está anexado. O que não faz é provar disponibilidade externa.

O documento também distingue o URI de um agregado MHTML do URI de sua raiz. Buscar o agregado retorna um pacote. Buscar a raiz pode retornar apenas a página e obrigar o cliente a obter dependências separadamente. Como as duas operações podem ocorrer em momentos diferentes, elas também podem produzir estados diferentes.

Content-ID ocupou o centro dessa arquitetura justamente por alegar menos. Ele manteve uma relação interna enquanto ordem, localização e momento de recuperação mudavam ao redor. Depois da identificação, ainda cabia ao receptor estabelecer o contexto, analisar o contêiner, escolher a alternativa permitida, decodificar, aplicar sua política de segurança e decidir o que renderizar.