Resumo

  • A RFC 3362 registrou image/t38 como descritor de mídia em SDP, enquanto a recomendação T.38 da UIT-T permaneceu responsável pela codificação e pelos procedimentos do fax.
  • O rótulo resolvia a identificação do fluxo, mas não comprovava aceitação na oferta/resposta, transporte compatível, criptografia, conversão de gateway ou conclusão das páginas.

Uma máquina de fax produz papel. Um registro de tipos de mídia produz um identificador. Entre esses dois resultados há uma cadeia de decisões que a RFC 3362 nunca tentou esconder.

Publicada em 2002, a RFC tratou de uma junta estreita entre padrões. A recomendação T.38 da UIT-T descrevia os recursos necessários para comunicação de fax do grupo 3 em tempo real sobre redes IP. SIP e SDP ofereciam os mecanismos de sessão. image/t38 permitia que uma descrição SDP dissesse, com vocabulário comum, qual fluxo estava sendo proposto.

O documento não redefiniu T.38. Ele apontou para a recomendação da UIT-T e registrou o nome. Também observou que T.38 podia usar TCP ou UDP conforme o ambiente do serviço. Os procedimentos de Annex D escritos com as versões anteriores de SIP e SDP podiam ser aplicados à revisão de SIP publicada como RFC 3261.

Essa divisão de trabalho era útil. Nenhuma organização precisava controlar todos os níveis. A UIT-T mantinha o comportamento de fax; o IETF mantinha a descrição e a sinalização; a IANA preservava o token; fabricantes e operadores decidiam o que executar. A coordenação existia sem transformar custódia em operação.

O cadastro era mínimo. Não havia parâmetros obrigatórios nem opcionais. O conteúdo era binário e o uso pretendido, comum. O vazio nos campos de parâmetro era informativo: image/t38 não transportava um perfil completo de compatibilidade. O restante precisava vir de T.38, da negociação e da configuração real.

A RFC ainda recusou uma generalização tentadora. O tipo foi criado para indicar um fluxo T.38 em SDP, não para uso em e-mail. A seção de interoperabilidade dizia que esse uso não estava definido e, por isso, não tinha garantia de interoperar com o fluxo. O prefixo image não fazia da sessão um anexo comum.

O limite de segurança era igualmente explícito. O conteúdo designava um fluxo de bits de fax que podia ou não estar criptografado. O rótulo não afirmava confidencialidade. Ele tampouco revelava se a sinalização SIP estava protegida, se a mídia tinha proteção ou se algum gateway expunha o documento em outro segmento.

SDP descrevia, mas não transportava. A RFC 2327, depois a RFC 4566 e hoje a RFC 8866 afirmam que SDP é um formato de descrição de sessão e não incorpora um protocolo de transporte. Informar endereço, porta e formato não faz os pacotes atravessarem a rede.

Faltava ainda a resposta do outro lado. A RFC 3264 organiza a oferta sob a perspectiva de um participante e a resposta sob a perspectiva do outro. Só as duas formam a visão completa. Uma resposta pode rejeitar um fluxo colocando a porta em zero. Logo, image/t38 em uma oferta prova proposta, não aceitação.

Depois da aceitação aparecem outras fronteiras. Os terminais precisam compartilhar comportamento T.38 compatível. TCP ou UDP precisa funcionar no caminho. Perda, atraso e reordenação precisam permanecer toleráveis. Gateways precisam converter corretamente entre os tempos do fax e os tempos dos pacotes. Uma sessão aparentemente estabelecida ainda pode terminar com página truncada.

O operador precisa de recibos separados. O registro IANA prova que o tipo existe e aponta para a RFC. Um inventário de software pode provar reconhecimento. A oferta prova intenção. A resposta prova aceite ou recusa. Capturas de pacotes provam transporte observado. Logs provam tentativas de conversão. Contadores e confirmações provam páginas tecnicamente concluídas. O recebimento pela pessoa ou pelo processo de negócio vem depois.

Misturar esses recibos destrói a explicação do erro. Registro não é adoção. Reconhecimento não é negociação. Negociação não é transporte. Transporte não é documento completo.

Os procedimentos gerais também mudaram. A RFC 2048 regia o registro de tipos de mídia quando a RFC 3362 surgiu. As RFCs 4288 e 6838 atualizaram o modelo. Revisão, estabilidade e nomes não conflitantes fortalecem a referência comum. Não instalam suporte em nenhum equipamento.

As RFCs 2119 e 8174 mostram o mesmo limite em outra forma. Palavras normativas definem o que uma implementação conforme deve fazer. Não provam que uma máquina específica fez isso. A passagem do requisito ao fato exige teste e observação.

O registro atual da IANA continua valioso porque conserva image/t38 e a referência histórica. Essa continuidade é prova de custódia do nome, não de prevalência, criptografia, escolha de transporte ou sucesso de páginas.

Dois textos de Lu Heng funcionam como lentes declaradas. “Minimum Initial Specification” recomenda manter na camada comum apenas o necessário e verificável, deixando a adoção com quem executa o código. A RFC 3362 mostra como uma junta pequena pode funcionar. “On Reality Layers” impede que uma inscrição seja confundida com o sistema em execução. Registro, oferta, resposta, transporte e página pertencem a níveis distintos.

O rótulo fez seu trabalho. Deu nome ao fluxo. A interoperabilidade só começava a ser demonstrada depois dele.

Fontes