Resumo

  • O NNTP separou o Message-ID globalmente único da chave local composta pelo grupo e pelo número do artigo. Um único crosspost podia ter vários números sem virar vários artigos.
  • O Xref reunia as posições atribuídas pelo último servidor para que o leitor não processasse repetidamente o mesmo artigo publicado em mais de um grupo.
  • Um servidor de leitura normalmente removia o Xref recebido e gravava o próprio. Mudava o comprovante de arquivamento local, não o corpo nem a identidade global do artigo.

A segunda aparição

Uma leitora termina um artigo em um grupo de notícias. Ao abrir outro grupo assinado, encontra o mesmo título e o mesmo corpo, mas com outro número. Se o aplicativo guardou apenas o primeiro número, a segunda coordenada parece ser um segundo artigo.

O Netnews oferecia uma explicação mais precisa. O autor podia ter publicado um único artigo em vários grupos ao mesmo tempo. O servidor em geral armazenava uma só cópia e criava uma entrada de índice em cada grupo, cada qual com sua posição.

Xref era o comprovante compacto dessa organização. O campo informava o servidor que o produziu e listava os grupos e localizadores em que aquele servidor arquivou o artigo. Não criava outra identidade; conectava diversos pontos locais ao mesmo artigo.

A fronteira importa: identidade responde qual é o artigo; localização responde onde este servidor o oferece. Trocar uma pela outra cria duplicatas ou inventa uma localização universal que o protocolo nunca prometeu.

Três chaves, três alcances

O RFC 3977 descreve três tipos de chave usados pelo NNTP. O Message-ID identifica o artigo globalmente. Outra chave combina o nome de um grupo com um número de artigo dentro dele. A terceira registra o instante de chegada ao servidor.

A combinação grupo-número é inequívoca no seu domínio: em um grupo de um servidor, um número só pode apontar para um artigo, e o mesmo artigo não pode ter dois números naquele grupo. Um crosspost, porém, pertence a vários grupos e pode receber um número diferente em cada um.

Essa combinação não é única fora do servidor. O mesmo grupo e número podem apontar para artigos diferentes em servidores diferentes. Os números seguem a ordem local de chegada. Mudar de servidor é mudar de sistema de coordenadas, ainda que o Message-ID continue igual.

O comando GROUP devolve marcas d’água inferior e superior e uma estimativa de quantidade. Não assegura que todos os números intermediários existam. Artigos podem ser removidos, e um artigo antigo pode ser restabelecido com o número anterior dentro das condições do protocolo. Uma lacuna não comprova exclusão mundial, e um número alto não define cronologia global.

Um artigo em várias prateleiras

O RFC 5536 distingue um artigo publicado em vários grupos de várias publicações separadas com o mesmo texto. No crosspost, há um único artigo e um único Message-ID, cercado por diversos índices de grupo.

Xref expressa essa abertura. Primeiro vem a identidade do servidor gerador; depois, uma ou mais localizações. Cada localização associa o nome de um grupo a um localizador. O formato tradicional no NNTP é um número decimal, embora a especificação permita formas próprias da implementação.

O nome do servidor delimita o espaço dos localizadores. Sem ele, a mesma posição aparente pode levar a outro artigo em outro serviço. Com ele, o cliente entende que várias entradas daquele mapa local convergem para um artigo.

O RFC 5536 afirma que agentes de usuário costumam usar o campo para evitar múltiplo processamento de artigos publicados em vários grupos. Depois de apresentar o artigo uma vez, o leitor pode alinhar o estado das outras posições conectadas. Assim, uma intervenção destinada a mais de um público continua sendo uma só intervenção.

Grupos declarados e grupos arquivados

Newsgroups declara os grupos aos quais o artigo foi publicado. Xref relata onde o último servidor de fato o arquivou. O RFC 5536 permite que os dois conjuntos sejam diferentes.

Isso torna visível a autoridade local. Um servidor pode não transportar todos os grupos, pode recusar um destino por política ou alterar a disponibilidade com retenção e moderação. Copiar a declaração do autor para o comprovante ocultaria essas decisões.

Um campo preserva a distribuição declarada; o outro materializa a visão de armazenamento. A posição local não reescreve a intenção do autor, e a intenção não prova que um servidor aceitou todos os destinos.

Um comprovante feito para ser substituído

O RFC 1036, de 1987, descrevia Xref como o nome do host seguido por pares grupo-número retirados do diretório local. O documento dizia que a informação só tinha valor para o sistema local e não deveria ser transmitida. Seu exemplo mostrava uma mensagem com números diferentes em dois grupos.

A arquitetura posterior organizou a reescrita sem transformar o campo em identidade. O RFC 5537 permite ao agente de retransmissão apagar um Xref existente e adicionar outro para uso próprio. O servidor de leitura normalmente deve remover o campo recebido — exceto numa configuração especial que conserva os localizadores do remetente — e pode, como geralmente faz, adicionar o seu antes do armazenamento.

A troca não altera o artigo. O mesmo RFC proíbe retransmissores e servidores de modificar suas partes, salvo as exceções estreitas de Path e Xref, e proíbe tocar o corpo. O mapa local muda enquanto o artigo permanece.

Essa permissão mostra quem controla o dado: o comprovante descreve uma decisão de arquivamento do servidor, não uma afirmação permanente do autor.

Escopo não é autenticação

O servidor nomeado em Xref não é selo de origem. Ele informa em qual espaço os localizadores devem ser interpretados. Não é assinatura criptográfica, não verifica o autor e não prova qual servidor recebeu o artigo primeiro.

A possibilidade de remover e regenerar o campo impede tratá-lo como proveniência imutável. A conclusão de que ele não autentica é uma inferência cuidadosa das regras de reescrita e da ausência de um contrato de autenticação. O campo serve como evidência da visão local apenas dentro do contexto de confiança daquele serviço.

O atual Registro de Cabeçalhos de Mensagem da IANA mantém Xref como campo padrão de Netnews e aponta para o RFC 5536. Message-ID e Newsgroups aparecem separadamente. O registro oferece vocabulário comum; não concentra identidade, distribuição declarada e localização em uma única autoridade.

O número significava “aqui”

O feito do Xref não foi criar um identificador mais forte. Foi permitir que um sistema distribuído reconhecesse várias coordenadas para um único artigo e aceitasse que outro servidor as trocasse sem trocar o artigo.

Tratar localização como identidade fabrica duplicatas em cada crosspost ou migração. Tratar identidade como localização supõe que um nome global dá acesso a um endereço universal. O NNTP manteve as duas camadas e limitou o poder de cada uma.

As fontes oficiais não demonstram a adoção atual do campo nem a prática de um provedor específico. Também não explicam sozinhas por que um número local desapareceu. Elas fixam a fronteira: Message-ID diz qual é o artigo; Xref diz onde este servidor o arquivou. A precisão nasce dessa contenção.