Resumo

  • IHAVE oferecia um Message-ID antes do corpo. O receptor podia dizer que já conhecia o artigo, pedir nova tentativa ou solicitar o envio completo.
  • Solicitar o corpo não encerrava a decisão. Depois da inspeção, o servidor ainda podia confirmar, adiar ou rejeitar a transferência; a confirmação tampouco assegurava retenção permanente.
  • CHECK e TAKETHIS permitiram manter várias negociações em andamento. A fila ficou mais eficiente, mas a política de armazenamento continuou pertencendo ao receptor.

Três fichas no balcão

As três fichas produzem três economias diferentes. A primeira evita um duplicado: o receptor consulta seu histórico e dispensa o corpo. A segunda evita uma tentativa em momento ruim: há um impedimento temporário, portanto o remetente guarda a possibilidade de voltar. A terceira autoriza o gasto de transmitir o artigo.

Só depois desse gasto o receptor conhece o objeto inteiro. Grupos, distribuição, cabeçalhos, tamanho e outras propriedades podem tornar o artigo inadequado. A ficha abriu a conversa; não decidiu o destino do corpo.

O mérito do protocolo está em não esconder essa mudança de informação. Antes do corpo, o receptor sabe o nome e sua própria história. Depois do corpo, sabe o que realmente recebeu. Cada conjunto de evidências recebe seu próprio veredito.

A origem em lotes de nomes

RFC 1036 descreveu os controles anteriores ihave e sendme. Um sistema anunciava Message-IDs disponíveis; outro solicitava aqueles que ainda não possuía. Era possível reunir vários nomes numa mensagem, pois a oferta isolada podia custar quase tanto quanto um artigo curto.

A lógica respondia às condições do armazenamento e encaminhamento. Enlaces intermitentes ou caros não deveriam transportar um texto inteiro para descobrir no fim que o vizinho já o tinha. O histórico local do receptor funcionava como filtro de duplicidade sem depender de um catálogo central compartilhado.

Essa solução também deixava um limite. O Message-ID identificava o artigo para a negociação, mas não provava que seus bytes, grupos ou distribuição seriam aceitáveis. A ficha dizia qual objeto estava em jogo; não substituía o objeto.

O primeiro balcão de IHAVE

RFC 977 transformou a ideia no comando IHAVE. O cliente apresenta o Message-ID. O servidor responde 335 quando quer que o artigo seja enviado, 435 quando não o quer e 436 quando uma tentativa posterior ainda faz sentido.

Após 335, chega o corpo completo e aparece o segundo balcão. 235 confirma a transferência, 436 registra falha temporária e 437 recusa sem pedir repetição. A especificação permite rejeitar depois da inspeção por grupos ou distribuição indesejados, falta de espaço, comprimento excessivo ou cabeçalhos corrompidos.

Por isso, 335 não quer dizer “aceitei o artigo”. Quer dizer “envie o necessário para que eu termine de decidir”. A diferença parece pequena numa leitura rápida, mas determina se um relatório consegue explicar onde a operação parou.

Uma falha sem resposta continuava sendo falha

RFC 3977 reafirmou a sequência. IHAVE não pode ser colocado em pipeline: o cliente espera a resposta inicial, envia o corpo quando solicitado e espera o resultado final. Se uma resposta esperada não aparece, o caso é tratado como falha temporária, nunca como sucesso presumido.

Essa regra protege as reconexões. O remetente pode repetir uma oferta cujo resultado ficou desconhecido. O receptor deve reconhecer a repetição para não armazenar ou transportar o mesmo artigo desnecessariamente. A incerteza não desaparece, mas ganha uma recuperação definida.

O documento também separa trânsito e postagem. IHAVE move entre pares um artigo já formado; POST introduz novo material. O receptor de trânsito decide dentro do acordo de alimentação local, não em nome de toda a rede.

A confirmação não congelava o futuro

RFC 977 observa que um servidor pode responder 235 e, em processamento posterior, descobrir que o artigo é inaceitável e descartá-lo silenciosamente. O código continua sendo prova de uma transação bem-sucedida, mas não é recibo de arquivo perpétuo.

RFC 4644 repete a fronteira no modo contínuo. Mesmo depois do 239 de TAKETHIS, o artigo pode desaparecer durante etapas posteriores. Para afirmar custódia durável, é preciso verificar o spool, a oferta aos leitores ou o encaminhamento a outro par.

Uma evidência de bytes enviados vale menos que uma confirmação de transferência; esta, por sua vez, vale menos que a prova de retenção. Juntar essas camadas numa única palavra produz certezas que o protocolo nunca ofereceu.

De uma fila parada a várias faixas

Em trajetos de alta latência, as duas esperas de IHAVE deixavam capacidade ociosa. RFC 4644 introduziu CHECK, uma consulta sobre o interesse por um Message-ID, e TAKETHIS, a entrega do corpo com resposta final. Muitas consultas e artigos podiam avançar simultaneamente.

Ainda assim, a resposta de CHECK era uma orientação. O receptor não devia supor obediência absoluta do cliente. Uma política entre sites ou uma estratégia adaptativa podia enviar TAKETHIS sem CHECK anterior, e o servidor continuava livre para rejeitar o corpo.

A inovação mudou a geometria da espera. Não transformou a ficha de identidade numa ordem de armazenamento, nem a resposta positiva numa cessão do disco.

O acordo que não estava na ficha

RFC 5537 situa o mecanismo na arquitetura de Netnews. Os antigos controles ihave e sendme já eram amplamente obsoletos na Internet, embora ainda aparecessem em alguns ambientes UUCP. Pares modernos combinavam o que trocar e qual transporte empregar.

Esse acordo definia hierarquias, distribuições e práticas aceitas. Não cabia no Message-ID nem era criado por 335. Os códigos permitiam executar e observar uma negociação específica dentro de uma relação operacional estabelecida pelos dois sites.

Assim, a história de IHAVE não termina quando o receptor diz “mande”. Ela termina apenas para aquela etapa. A arquitetura conservou espaço para a inspeção, para a política local e para o tempo posterior ao recibo. É justamente essa modéstia que tornou o mecanismo útil.

Fontes