Resumo

  • O RFC 3391 cortava mensagens MIME em blocos numerados e delimitados por comprimento, permitindo intercalá-los para que uma imagem chegasse logo antes ou depois de sua referência no documento raiz.
  • A proximidade era uma escolha antecipada do produtor, não uma resposta do consumidor; blocos válidos não comprovavam memória suficiente, apresentação correta nem o encerramento futuro de todas as mensagens.

Uma página digital raramente nasce inteira. Um scanner descobre a próxima imagem enquanto trabalha; um gerador de documentos encontra uma referência quando chega àquele parágrafo. Do outro lado, uma impressora quer começar sem guardar o trabalho completo. A ordem convencional das partes cria um impasse: anexos antes do texto ocupam memória cedo demais; anexos depois dele chegam tarde demais.

No multipart/related, componentes relacionados aparecem como partes sucessivas separadas por marcadores. A relação está descrita, mas a referência em uma parte longa e o objeto referido podem ficar distantes por muitos octetos. Para processamento progressivo, essa distância tem consequências.

Publicado em dezembro de 2002 como RFC Informational, o RFC 3391 introduziu application/vnd.pwg-multiplexed. A entidade passou a ser uma sequência de blocos, cada qual contendo uma mensagem MIME inteira ou um trecho. Blocos de mensagens diferentes podiam alternar. Assim, o produtor interrompia a raiz, inseria a imagem necessária e retomava a raiz.

A especificação não confundia essa representação com o objeto. O documento composto e seus componentes eram abstrações; a entidade e as mensagens eram os octetos usados para transportá-los ou armazená-los. Uma mensagem reconstituída deveria ser idêntica, octeto a octeto, à parte de multipart/related que representasse o mesmo componente. O significado continuava onde estava; mudava o cronograma de chegada.

Cada bloco tinha uma cabeçalho conciso: CHK, número da mensagem, comprimento da carga e MORE ou LAST. O comprimento eliminava a procura por uma cadeia delimitadora. MORE mantinha a mensagem aberta e LAST concluía sua última parte. Fragmentos de outras mensagens podiam entrar no meio, mas as partes de uma mesma mensagem preservavam a ordem.

O primeiro bloco trazia a mensagem raiz inteira ou parcial. A carga podia ter zero octetos, de modo que os primeiros bytes reais da raiz surgissem mais adiante. O fim da entidade era separado: CHK 0 0 LAST. O número zero ficava reservado para esse sentinela.

O sentinela não certificava o passado. Se ele aparecesse antes do último bloco de cada mensagem, o comportamento do consumidor seria indefinido. Os números normalmente distinguiam mensagens, embora a reutilização fosse permitida e desaconselhada. Nesse caso, a primeira mensagem tinha de alcançar LAST antes de a seguinte com o mesmo número começar.

O parâmetro obrigatório type declarava o tipo de mídia da raiz. Ele antecipava a classe do objeto composto sem exigir que o consumidor abrisse a mensagem interna. Uma divergência entre a declaração e o Content-Type efetivo levava novamente a comportamento indefinido. Content-ID e Content-Location podiam seguir padrões de MHTML; o RFC 3391 não pretendia definir a linguagem dos vínculos.

No exemplo de impressão, um produtor cria uma longa sequência de descrições de página e só descobre as imagens à medida que avança. Ele pode colocar cada imagem pouco antes de sua primeira referência. A impressora encontra o vínculo com os bytes já disponíveis, sem esperar pelo final da raiz nem armazenar todas as imagens futuras.

No exemplo de digitalização, a imagem também pode vir logo depois da referência. Primeiro o consumidor conhece o lugar; em seguida recebe o material. O ganho consiste em aproximar eventos no fluxo, permitindo que produção e consumo avancem sem um lote completo.

Mas o terceiro exemplo entrega a diagramação ao consumidor. Duas imagens podem ficar lado a lado; o texto pode contornar uma figura. O produtor conhece a posição da referência no documento, não a largura da página, as métricas tipográficas nem o limite de armazenamento no aparelho remoto.

Intercalar faixas de imagens lado a lado parece aproveitar bem o fluxo. Se faltar memória, porém, o consumidor fica com pedaços alternados de várias imagens e não consegue concluir nenhuma de modo limpo. O RFC recomenda não intercalar imagens nesse cenário. A existência de uma operação não a torna uma boa política.

Com texto contornando imagem, cortar cedo demais pode obrigar o consumidor a guardar a imagem inteira ou encerrar prematuramente o contorno. Cortar tarde demais pode acumular texto e empurrar a imagem. O documento sugere preferir um pouco mais de texto, porque texto costuma ocupar menos espaço. Trata-se de uma aposta informada, ainda incapaz de enxergar o receptor.

Por isso a nota do IESG é central. O uso do tipo seria apropriado apenas quando o produtor conhecesse plenamente as capacidades e limitações do consumidor. Consumidores diferentes precisariam de coisas diferentes em instantes diferentes, e o mecanismo não continha uma forma de descobrir isso. Diante de um consumidor desconhecido, deveria ser considerada uma alternativa bidirecional, como BEEP.

A comparação separa previsão e demanda. Na entidade multiplexada, o produtor empurra o componente no momento que julga correto. Em um protocolo bidirecional, o consumidor pode pedir a imagem ao chegar à referência ou solicitar faixas adequadas à sua diagramação. A solicitação pode impor espera; o envio antecipado pode errar o alvo. Cada mecanismo controla um risco diferente.

Nem a apresentação final pertencia ao cabeçalho do bloco. Se o consumidor reconhecesse o contêiner e a raiz, mostraria os componentes no contexto do objeto composto. Nesse caso, Content-Disposition poderia ser redundante ou enganoso e deveria ser ignorado para exibição. Se reconhecesse o contêiner, mas não a raiz, poderia suprimir tudo ou tratar as mensagens como anexos mistos. Sem reconhecer o contêiner, veria apenas algo opaco.

Os riscos de segurança nasciam da mesma liberdade de cronograma. Um produtor defeituoso ou malicioso podia separar os fragmentos de uma mensagem por uma enorme quantidade de dados ou nunca enviar o fechamento. Podia iniciar muitas mensagens, referenciar componentes ausentes ou entregar tantos componentes antes da hora que o consumidor não soubesse quais já poderia descartar.

Cada bloco isolado ainda podia estar correto. Número, comprimento e estado podiam passar pela validação, enquanto as promessas incompletas acumulavam uma obrigação de armazenamento sem limite prático. Correção local de enquadramento não equivalia a segurança global de recursos.

O princípio de Especificação Inicial Mínima de Lu Heng ajuda a entender o desenho. A camada comum fixou apenas o necessário para reconstruir mensagens: identidade, comprimento, continuidade, raiz e término. Diagramação e gestão de memória continuaram locais, capazes de evoluir sem autorização central.

A Primazia do Código em Execução estabelece o teste seguinte. Registrar o tipo não comprova que uma impressora real manteve velocidade. Receber LAST não comprova que a imagem foi exibida. Fluxo original, grafo de referências, telemetria de memória e resultado renderizado são recibos distintos.

O RFC 3391 tornou a distância programável, não o consumidor transparente. A imagem podia chegar ao lado da referência, mas o produtor permanecia do lado de fora. Ordenar bytes era uma capacidade; conhecer a necessidade continuava exigindo comunicação.

Fontes