Resumo

  • Date registra quando o criador declarou a mensagem completa e pronta para seguir, não quando o transporte realmente começou.
  • Relays de Netnews precisam limitar o histórico de Message-ID vistos. Se a data de composição governa esse limite, um artigo recém-injetado após longa espera pode parecer recirculação antiga.
  • Injection-Date acrescentou a observação da entrada sem reescrever Date. Ela orienta decisões de antiguidade, mas não autentica autor, relógio nem chegada a todos os servidores.

Uma publicação nova com data antiga

Alguém conclui um texto longe de qualquer conexão. Na segunda-feira, o aplicativo preenche Date. Só na sexta o posting agent consegue oferecê-lo a um news server.

Para a pessoa que escreveu, segunda é a hora correta: o texto ficou pronto ali. Para um relay que mantém memória finita, o mesmo valor lembra um artigo velho que voltou depois de o registro do Message-ID ter expirado.

Trocar a data pela sexta pode melhorar a propagação, mas apaga a espera real. Preservar a segunda pode acionar um cutoff antigo. Um único campo foi obrigado a documentar criação e, ao mesmo tempo, autorizar entrada.

Injection-Date desfez o conflito sem corrigir o passado: guardou a primeira marca e acrescentou a observação do limite de rede.

Date não era horário de transporte

A RFC 1036, de 1987, chamava Date, antes Posted, de data em que a mensagem tinha sido originalmente publicada na rede. O valor deveria atravessar a propagação sem mudança, evitando que cada salto reiniciasse a cronologia.

A RFC 5322 separou com mais clareza conclusão e transporte. Origination date é quando o criador indica que a mensagem está completa e pronta para entrar no sistema de entrega. O texto usa o caso de um notebook offline: a data é a de colocar a mensagem na fila, não a da conexão posterior.

Essa definição preserva uma informação histórica. Também impede que Date seja tratada como prova suficiente de entrada. O relógio do criador pode estar errado, a afirmação pode ser falsa e a fila pode durar dias. Mesmo perfeita, a marca responde a uma pergunta diferente da feita pelo relay.

A memória de duplicatas precisava terminar

Netnews distribui artigos entre relaying agents e serving agents independentes. A RFC 5537 exige que mantenham um histórico do que já viram e rejeitem novas ofertas do mesmo artigo. Message-ID dá a chave de comparação.

Guardar todas as chaves para sempre faria a base crescer sem limite. O protocolo permite um cutoff interval: artigos com data anterior à janela podem ser recusados e seus registros antigos removidos, pois um retorno também falharia no teste temporal. A RFC descreve sete dias ou mais como convenção no Usenet e avisa que uma janela menor que o tempo de propagação pode rejeitar conteúdo nunca recebido.

A data não prova que haja duplicata. Ela limita por quanto tempo o servidor guarda a evidência capaz de reconhecê-la. Janela curta economiza mais cedo e sacrifica atrasos; janela longa protege caminhos lentos e custa armazenamento.

Quando a composição era a única hora disponível, dias passados fora da rede consumiam a janela de dentro da rede.

Uma segunda hora com poder menor

A RFC 5536 define Injection-Date como a data e hora em que o artigo foi injetado na rede. Sua finalidade é permitir que news servers verifiquem artigos stale com uma hora colocada no ingresso, em vez daquela colocada pelo user agent na composição.

O campo deve ser inserido na injeção. Por compatibilidade, agentes também devem aceitar artigos sem ele; nesse caso, RFC 5537 volta a usar Date. A transição ampliou a semântica sem romper com todos os peers antigos.

Adicionar a segunda data não autoriza alterar a primeira. RFC 5536 proíbe modificar uma Date preexistente e alerta que relógios não sincronizados podem fazer Injection-Date parecer anterior. Uma diferença negativa não comprova inversão dos acontecimentos.

O campo documentado substituiu o usado, mas não especificado, NNTP-Posting-Date, agora deprecated. O nome comum coordenou implementações, não seus relógios.

Três relógios, três pontos de observação

Na otimização comum do histórico, RFC 5537 chama de data do artigo Injection-Date quando presente, usando Date apenas como fallback. Relays e servidores verificam valores excessivamente futuros e, quando aplicam cutoff, comparam essa data à janela.

Outra estratégia remove o registro a partir da primeira vez que aquele servidor viu o artigo. No desenho descrito, a retenção deve exceder o cutoff em pelo menos 24 horas para acomodar a margem de data futura. Surge uma terceira perspectiva.

A RFC 3977 define o arrival timestamp local e exige que os números de artigo sigam sua ordem. Essa hora pertence a um servidor específico.

  • Date conserva a conclusão declarada pelo criador.
  • Injection-Date conserva a entrada no sistema Netnews.
  • arrival time conserva a recepção e a ordenação locais.

Misturar as três faz atraso de caminho parecer demora do autor, ou espera offline parecer recirculação.

Entradas redundantes não criavam novos aniversários

O mesmo artigo podia ser entregue a mais de um injecting agent para redundância ou redes separadas. A intenção continuava sendo uma única publicação. Quando caminhos convergissem, Message-ID deveria permitir uma só aceitação.

RFC 5537 exige Message-ID, Date e Injection-Date idênticos em todas as cópias do proto-artigo. Ao preparar um artigo já injetado para outra entrada, os três campos permanecem intactos. Atualizar a segunda data em cada gateway faria o mesmo artigo parecer recém-criado repetidamente.

Assim, Injection-Date não é apenas o «agora» de qualquer intermediário. Em múltipla injeção, ela integra a continuidade que permite tratar várias portas como um só ato.

Compatibilidade conservou decisões antigas

Implementações anteriores ignoram Injection-Date e continuam aplicando cutoff a Date. RFC 5537 reconhece que uma composição muito antiga ainda pode ter propagação ruim mesmo com o novo campo correto.

Se Message-ID e Date já existem, o posting agent deveria acrescentar a hora de entrada quando passou mais de um dia e deve fazê-lo ao usar vários injecting agents. O agente de injeção verifica futuro e passado excessivos e acrescenta sua hora nas condições previstas. Próximo ao poster, ainda pode explicar por que recusou.

Nada disso muda um relay legado. A compatibilidade preserva o intercâmbio, mas admite que dois peers extraiam decisões distintas da mesma publicação.

Registro não significa certificação

Injection-Date é uma afirmação temporal do agente no limite de entrada. Não é assinatura, prova de autoria ou garantia de sincronização. Não indica aprovação de moderador, leitura, chegada a cada site ou expiração local.

O atual registro de cabeçalhos de mensagem da IANA lista Injection-Date como campo padrão de Netnews e aponta para RFC 5536. O registro estabiliza o nome; não valida cada valor nem demonstra implantação universal.

O ganho histórico foi limitar cada relógio. A pessoa que escreveu conservou a data de conclusão. A rede acrescentou a hora necessária à sua admissão. Cada servidor ainda reteve sua chegada. A segunda data melhorou a verdade operacional justamente porque não recebeu poder para apagar a primeira.