Resumo

  • A RFC 2158 identificava JPEG e GIF por nomes de partes de corpo, OIDs, Content-Types MIME e octetos copiados sem conversão; esses sinais se relacionavam, mas não eram intercambiáveis.
  • A subseção FTAM EMA GIF imprime image/jpeg, embora o título, o nome da parte e o OID gif-image(4) apontem para GIF.
  • O contexto torna provável um erro de cópia, mas o RFC Editor não registra hoje errata para a RFC 2158; nem a intenção provável nem o rótulo publicado provam o que qualquer gateway implantado emitiu.

Uma entrada rompeu a própria cadeia de identidade

A RFC 2158, publicada em janeiro de 1998, descreveu dois caminhos curtos para imagens entre MIME e X.400. As Extended Body Parts eram mime-jpeg-body, sob { mixer-bp-data 3 }, e mime-gif-body, sob { mixer-bp-data 4 }, ambas sem parâmetros. O texto também registrou dois identificadores FTAM da Electronic Messaging Association.

Três dos quatro casos seguem uma sequência regular. A parte estendida JPEG corresponde a image/jpeg; FTAM EMA JPEG também corresponde a image/jpeg e usa um OID terminado em jpeg-image(6); a parte estendida GIF corresponde a image/gif. A quarta subseção tem o título “image/gif - FTAM EMA GIF”, nomeia FTAM EMA GIF e traz um caminho OID terminado em gif-image(4). No meio, porém, aparece MIME Content-Type: image/jpeg, seguido de uma frase que chama o OID de identificador atribuído a JPEG.

A contradição está inteira numa única entrada. Três identificadores dizem GIF; um campo e um substantivo aparentemente copiado dizem JPEG. Eles não podem descrever simultaneamente o mesmo formato.

“Sem conversão” aumentava o custo do rótulo errado

Todas as correspondências declaram Conversion: None. O gateway não deveria decodificar um raster e recodificá-lo em outro formato. Ele associava uma representação X.400 a um tipo MIME e transportava os octetos sem alteração. Assim, um cabeçalho JPEG não transforma bytes GIF em JPEG, e um ramo OID chamado GIF não transforma bytes JPEG em GIF.

A RFC 2046 define a fronteira: dentro do tipo principal image, o subtipo identifica o formato específico. O registro de tipos de mídia da IANA mantém image/gif e image/jpeg como registros separados. O receptor pode usar o rótulo para escolher um decodificador, mas o rótulo continua sendo uma afirmação sobre os octetos. Seleção da regra, continuidade de hash e êxito de decodificação são observações diferentes.

A norma companheira, RFC 2157, confirma o padrão ao associar mime-jpeg-body a image/jpeg e mime-gif-body a image/gif. Isso não edita silenciosamente a RFC 2158, mas explica por que uma implementação tinha vários campos a reconciliar.

A correção óbvia ainda é uma inferência

A leitura textual mais forte é que a subseção FTAM EMA GIF deveria dizer image/gif e descrever um OID atribuído a GIF. Título, nome da parte, folha do OID e entradas vizinhas sustentam essa conclusão. O rascunho MIXER anterior também associa a parte estendida GIF a image/gif, mas antecede as subseções FTAM e não oferece uma versão corrigida da linha contestada.

A investigação precisa parar nesse limite. A busca de errata do RFC Editor não retorna correspondências para a RFC 2158. “Provável erro editorial” é análise respaldada; “corrigido oficialmente” não é.

O documento também não testemunha o que foi implantado. Um fornecedor pode ter seguido literalmente o campo MIME, preferido título e OID, aplicado uma correção privada, inspecionado a assinatura dos bytes ou nunca implementado esse mapeamento FTAM.

Uma linha da especificação não fala pelo gateway

Para demonstrar o comportamento real são necessários a versão da tabela, a parte X.400 selecionada, o OID completo, o campo MIME e os bytes de entrada, os campos e bytes de saída, o manipulador escolhido e o resultado da decodificação. Um hash inalterado prova continuidade binária naquela etapa, não a correção do rótulo. Uma imagem aberta prova que um manipulador aceitou o objeto, não que todos os destinatários fariam a mesma escolha.

Documento, implementação e resultado observado são camadas distintas. Podem coincidir, mas nenhuma toma emprestada a comprovação das outras. A lição da RFC 2158 não é abandonar rótulos: é tratar a identidade de formato como uma afirmação composta. Havendo conflito, o rótulo não deve falar pelos bytes nem pelo código até que os identificadores sejam reconciliados.

Fontes