Resumo

  • O RFC 1865 propôs trocar os componentes de transmissão entre sistemas EDI existentes por correio da Internet. A entrega SMTP direta e assegurada chegava ao sistema do parceiro, não à aceitação comercial.
  • O RFC 1767 colocou objetos X12, EDIFACT e EDI-consent em MIME sem alterar sintaxe ou semântica e sem oferecer segurança por conta própria.
  • Os RFCs 3335 e 4130 acrescentaram Message-ID, MIC, assinatura e MDN; um recibo assinado ainda podia informar falha, enquanto a validade da transação continuava com os parceiros.

O recibo da máquina e a decisão da empresa

Uma ordem eletrônica sai do fornecedor e recebe resposta positiva do SMTP do comprador. Os bytes estão no destino. Ainda pode haver parceiro incorreto, duplicidade, assinatura inválida, erro de sintaxe, rejeição pelo tradutor ou condição comercial incompatível. A rede concluiu uma transferência; não comprou a mercadoria.

O RFC 1865, Informational de janeiro de 1996, apresentava a Internet a uma comunidade EDI. A mudança proposta mantinha programas de negócio e tradutores EDI. Os módulos de comunicação é que passavam a ser os da Internet.

O texto dizia que uma conexão SMTP dedicada levava a informação diretamente ao sistema do parceiro e assegurava a entrega. Já a integridade do armazenamento e encaminhamento dependia dos intermediários. É uma afirmação útil quando limitada à entrega no sistema. Não demonstra que o aplicativo processou o objeto nem que alguém com mandato aceitou os seus termos.

EDI continuava dentro de uma relação bilateral

RFC 1865 definiu EDI como comunicação entre aplicações de informação empresarial padronizada e o separou do comércio eletrônico mais amplo, que também podia envolver pessoas, dinheiro e recursos compartilhados. O documento eletrônico era uma entrada do negócio, não o negócio inteiro.

Os acordos de parceiros comerciais permaneceram. Endereços de Internet podiam substituir caixas postais proprietárias, mas não definiam sozinhos identidade, autoridade, prazos, duplicidades ou remédios. O RFC 1767 foi explícito: EDI-consent dependia de acordo bilateral.

Assim, abrir o meio de transporte não abriu a capacidade de obrigar a empresa. A Internet podia reduzir a centralidade de uma rede de valor agregado; o contrato continuava distribuindo responsabilidade entre as partes.

A função exata do MIME

RFC 1767 criou tipos MIME para EDI-X12, EDIFACT e EDI-consent. No emissor, o fluxo saía do programa comercial, passava pelo tradutor EDI, pelo encapsulamento MIME, pelo envio de correio e pelo SMTP. No receptor, a embalagem era removida antes da tradução e do processamento comercial.

O documento não mudou a sintaxe nem a semântica do EDI e não incluiu segurança por si só. MIME dizia como reconhecer e transportar o objeto. Não confirmava origem, integridade, validade sintática, autorização ou aceite.

Essa limitação evita transformar interoperabilidade em veredito. Uma embalagem comum resolve o encontro entre sistemas; não decide o significado dos termos que carrega.

O avanço de um recibo negativo assinado

O RFC 3335 organizou assinatura, criptografia e MDN assinado. O identificador original ligava resposta e envio; o MIC permitia comparar o conteúdo que o destinatário declarou ter recebido; a assinatura atribuía a declaração conforme chave e política. O emissor precisava verificar o recibo.

Mesmo o não repúdio de recebimento surgia como evento jurídico depois dessa verificação. Uma assinatura tecnicamente válida ainda precisa de caminho de confiança, política aplicável e autoridade do signatário.

O RFC 4130 exigia recibo assinado, quando solicitado pelo acordo, mesmo se o processamento do conteúdo falhasse. A disposition registrava a falha. Essa característica tornava o recibo mais honesto: ele provava chegada a um estado negativo, não fingia sucesso.

Se o recibo assinado obrigatório não viesse, os parceiros deveriam resolver a validade da transação, provavelmente inválida. O protocolo sustentava necessidades de evidência, mas não definia o não repúdio, pois esse era um requisito comercial ou jurídico.

Exibir não provava entendimento

O RFC 3798 lembrava que o destinatário podia ignorar o pedido de MDN e que uma disposition displayed não garantia leitura ou compreensão. A automação precisa da mesma cautela.

Aceite SMTP não é processamento EDI. MDN não é confirmação funcional do aplicativo. Assinatura não é mandato comercial. Confirmação funcional pode ainda não ser aceite contratual. Cada etapa precisa de seu ator e de sua regra.

Um registro auditável preserva o objeto exato, a recepção do correio, o MDN correlacionado e o MIC, o resultado do tradutor, a confirmação da aplicação e a decisão comercial autorizada. Os nomes variam, mas uma evidência não pode usurpar a competência da próxima.

Uma infraestrutura distribuída com regras combinadas

RFC 1865 previa diretório distribuído, roteamento e resolução cooperativos, além de provedores e servidores redundantes. A atividade EDI não exigia um coordenador central da Internet. Isso ampliava a substituição do transporte.

Os parceiros, contudo, ainda escolhiam endereços, certificados, prazo do recibo, política de repetição, retenção e disputa. A descentralização mudou a rota, não a obrigação.

As fontes não comprovam implantação em empresa específica, pedido aceito, pagamento ou decisão judicial. Comprovam uma arquitetura de limites: SMTP entregava, MIME identificava, assinaturas e MICs apoiavam evidência, e a autoridade comercial permanecia fora do servidor.

Fontes