Resumo

  • O RFC 3940 deu a cada NormObject em trânsito um número no escopo do remetente para coordenar dados e reparos, sem lhe dar uma identidade global de conteúdo.
  • Como o campo tinha 16 bits e podia se repetir, qualquer nome destinado a durar precisava ser definido pela aplicação em NORM_INFO ou no próprio conteúdo.

Pouco retorno exigia uma referência precisa

Na distribuição multicast, confirmar cada pacote em milhares de receptores poderia transformar a confiabilidade em congestionamento. O NORM preferiu o silêncio quando tudo funcionava. Um receptor avisava sobre o que faltava, e símbolos de correção de erros podiam recompor perdas diferentes sem repetir individualmente cada fragmento original.

Ainda era necessário indicar a qual objeto pertenciam um segmento, um pedido e uma resposta de reparo. Publicado como Experimental em novembro de 2004, o RFC 3940 usou object_transport_id. O remetente atribuía valores crescentes e mantinha o mesmo número para a transmissão e os reparos de um objeto. Com o identificador de remetente levado pelo protocolo, o número distinguia o NormObject durante seu percurso na sessão.

Era uma referência para o trabalho em andamento, não um registro civil para os bytes.

DATA e FILE diziam onde guardar, não o que guardar

O protocolo tratava três formas: dados estáticos em memória, arquivos e fluxos sem fim definido. A diferença entre NORM_OBJECT_DATA e NORM_OBJECT_FILE era sobretudo uma sugestão de armazenamento ao receptor. Memória para um, armazenamento não volátil para o outro. Fora disso, ambos eram unidades finitas entregues da mesma maneira. Até um fluxo podia carregar material estático por decisão da aplicação.

FILE, portanto, não trazia nome, caminho, versão ou proveniência. O receptor podia reconstruir integralmente uma tabela e continuar sem saber se era a edição vigente, uma cópia revogada ou outro conjunto com o mesmo formato. Reparar a transmissão não atribuía automaticamente significado, autorização nem destino documental.

A contagem acabava encontrando o próprio início

O identificador tinha 16 bits e cada remetente mantinha sua sequência de forma independente. Um valor solto não identificava nada de modo duradouro. Era preciso conhecer remetente, instância, sessão e estado atual. Para sessões muito longas ou indefinidas, o RFC 3940 admitia a repetição e orientava o receptor a se sincronizar de novo diante de números incompatíveis com o estado mantido.

A fronteira apareceu sem ambiguidade: os cabeçalhos NORM não forneciam identificação global ou no nível da aplicação. Os identificadores de transporte valiam apenas enquanto o objeto era transmitido ou reparado. Uma sequência crescente oferecia ordem local; um espaço finito não oferecia unicidade permanente.

O RFC 5740 substituiu o experimento em novembro de 2009 e levou o NORM à trilha de padrões. A separação permaneceu. O sucessor afirmou que o campo dará a volta e será repetido em uma sessão longa. Padronizar o transporte não converteu a etiqueta provisória em chave de arquivo.

Um cartão de contexto podia acompanhar o pacote

NORM_INFO oferecia contexto opcional e definido pela aplicação para cada objeto. Um tipo MIME era um uso possível. O receptor podia examinar essa pequena informação antes de participar da recepção confiável e pedir sua recuperação caso não a tivesse recebido.

Mas INFO não era autoridade de nomes. Seu uso era opcional, seu significado não era universal e todo o conteúdo precisava caber em um único segmento do remetente. A atomicidade acelerava o reparo, ao preço de limitar o espaço. Não havia obrigação de incluir ID persistente, resumo criptográfico, versão, assinatura ou nome de arquivo.

Compartilhar o número com o objeto ligava o contexto à transmissão correta naquele momento. Depois do encerramento da janela, guardar apenas esse número e descartar a geração, a instância e o ID da aplicação equivalia a guardar uma senha de atendimento sem guardar a loja nem a data. Quando o número reaparecesse, a falha não seria uma duplicidade criada pelo protocolo, mas a perda do escopo pela aplicação.

Entrega perfeita não impedia arquivamento errado

Considere um cache que persiste somente o identificador de remetente do protocolo e o número de 16 bits. Ele perde o estado, retorna depois da volta do contador e recebe um objeto novo sob uma chave conhecida. Todos os segmentos atuais chegam e os ausentes são reparados corretamente. Mesmo assim, o cache pode anexar aos novos bytes o título, a validade ou a permissão do objeto anterior.

Esse é um cenário deduzido da fronteira, não o relato de um incidente. Ele separa os tipos de prova. O estado de transporte mostra qual objeto ativo recebeu um segmento. Um resumo fornecido pela aplicação pode comparar os bytes. Um ID persistente relaciona a entrega a uma versão. Autorização e publicação exigem evidência própria. O sucesso de uma camada não concede a ela o poder das seguintes.

O valor histórico do RFC 3940 está nessa disciplina. Ele definiu a identidade mínima necessária à reparação distribuída e parou. O protocolo cuidava do movimento; a aplicação, da memória. Aquilo que precisa viver mais do que o transporte precisa de um nome próprio.