Resumo

  • O RFC 3459 aplicou Handling=REQUIRED|OPTIONAL a partes MIME: se uma REQUIRED não passasse, a mensagem inteira falhava; uma OPTIONAL podia ser removida em silêncio.
  • Partes sem marca e valores desconhecidos eram REQUIRED; em assinaturas e criptografia, a posição da marca decidia se o gateway podia transformar ou precisava rejeitar.

Entrega parcial exigia um contrato de perda

O correio Internet geral esperava que um agente MIME preservasse cada parte mesmo sem o renderizador apropriado. Um sistema de voz podia armazenar áudio e fax, mas não vídeo ou documento binário. O gateway conhecia a capacidade do destino e às vezes precisava retirar o que ele não aceitava.

O RFC 3459, de janeiro de 2003, tornou essa transformação explícita. O texto, o registro RFC Editor, o Datatracker, o histórico, as referências, as citações e os errata delimitam o registro. Ele atualizou o RFC 3204, separando Handling do transporte ISUP/QSIG.

Como parâmetro de Content-Disposition, REQUIRED dizia que o remetente não considerava a mensagem entregue sem aquela parte. OPTIONAL permitia apagar silenciosamente a parte incapaz de passar e proibia falha de entrega salvo quando uma REQUIRED também falhasse. Não era escala de importância: distribuía autoridade de transformação e consequência.

Apagar, falhar e notificar eram decisões distintas

O padrão era conservador. Parte sem marca e valor futuro desconhecido eram REQUIRED. Assim, um gateway não descartava em silêncio semântica que não compreendia. O RFC 2045 dava a base MIME e o RFC 2421 o contexto de voz limitado.

Criticalidade não pedia recibo por si só. DSN seguia o RFC 3461, MDN o RFC 3798, e mídia não suportada podia usar 5.6.1 do RFC 3463. Um gateway antes da entrega podia gerar DSN; depois da entrega, como agente, MDN; SIP retornava status, incluindo 415. O papel determinava a prova.

A posição da marca governava a proteção

No RFC 1847, marcar multipart/signed REQUIRED exigia passagem intacta e verificação ponta a ponta. Marcar o controle de assinatura REQUIRED admitia verificação no gateway, mas falha obrigava rejeição. Se assinatura fosse OPTIONAL e o material REQUIRED, o gateway podia retirar a assinatura para um destino incapaz, embora verificar e avisar alteração continuasse recomendado. O RFC 2480 trazia orientação relacionada.

Controle de criptografia REQUIRED exigia criptografia ponta a ponta. OPTIONAL autorizava um gateway capaz a decifrar e encaminhar texto claro a um terminal incapaz. Esconder a marca dentro do cifrado criava um ciclo: seria preciso decifrar para descobri-la; por isso conteúdo cifrado sem marca visível continuava REQUIRED.

O RFC 3238 situava consentimento e notificação. As posteriores camadas de realidade de Heng Lu separam marca, capacidade, transformação e resultado. A primazia do código em execução exige comparar árvores MIME antes e depois. São lentes editoriais posteriores.

O RFC 3459 transformou perda parcial invisível em consequência declarada. Uma parte opcional podia sumir sem invalidar a entrega; uma pequena parte obrigatória podia invalidar tudo.

Fontes