Resumo

  • O RFC 1681 sugeriu codificar no endereço de destino a classe de quem paga ou um índice para uma tabela de algoritmos de cobrança, de modo que clientes e roteadores de borda pudessem decidir antes do contato.
  • O texto considerou inaceitável descobrir o custo depois e explicou por que um aviso na conexão falharia em interações sem intervenção humana ou diante de um redirecionamento Gopher silencioso.
  • O sinal podia selecionar uma política, mas não provar sozinho a pessoa responsável, os termos vigentes, a aprovação informada, o serviço útil, a medição correta, a validade da fatura ou a liquidação.

O software podia chegar ao destino antes da decisão humana

O cenário mais incisivo do RFC 1681 é um redirecionamento. Um servidor Gopher poderia encaminhar o chamador para um endereço “pay-to-play” sem mostrar o aviso exigido. O documento não relata uma fraude real na Gopher. Ele usa uma hipótese para expor a ordem errada: o programa escolhe e contata o destino antes que a pessoa tenha oportunidade de compreender e recusar o custo.

Por isso, exibir uma mensagem no momento da conexão não bastaria. Muitas interações de rede não ofereciam um gancho para diálogo com o usuário. Quando o alerta aparecesse, o evento cobrável talvez já tivesse começado.

A proposta adiantava uma parte da informação comercial. Alguns bits do endereço indicariam quem pagava. Um campo maior poderia funcionar como índice de uma tabela de algoritmos de cobrança. Roteadores na fronteira de uma organização reconheceriam a classe de serviço pago e aplicariam regras locais antes de encaminhar o tráfego.

O endereço não seria uma fatura compacta. Seria um seletor legível por máquinas, posicionado cedo o suficiente para permitir uma negativa antes do contato.

Contar computadores deixou de bastar

O argumento sobre cobrança fazia parte de uma questão maior. A maioria dos hosts finais da época tinha um endereço, e projeções de capacidade frequentemente contavam máquinas. O RFC 1681 advertiu que a conta poderia ficar seriamente errada quando um único host precisasse de endereços para serviços, visões de acesso, usuários ou mobilidade limitada.

Um endereço secundário poderia representar um serviço, e não a máquina física que o executava naquele momento. O serviço seria transferido para outro equipamento mantendo sua identidade externa. Endereços diferentes no mesmo host também poderiam oferecer arquivos ou políticas de acesso distintos sem exigir um protocolo novo ou uma porta especial. Um firewall poderia liberar apenas o endereço do serviço, desde que cada processo estivesse vinculado ao endereço correto. Os riscos da autenticação baseada em endereço não desapareceriam.

O memo cogitou estender o DNS para devolver a porta junto com o endereço. Seu problema era a transição: cada cliente relevante teria de mudar. Acrescentar significado ao endereço explorava o que os aplicativos existentes já sabiam usar.

Esse atalho juntava funções com ciclos de vida diferentes. O endereço podia ser localizador de host, identidade de serviço, classe de acesso, identificador de sessão, âncora de mobilidade e categoria de cobrança. Um serviço sobreviveria à troca de servidor; o endereço do usuário terminaria no logout; a tabela de preço mudaria sem alterar o destino. A persistência dos bits não preservaria a história de todas essas interpretações.

Quatro arranjos de pagamento, muitos campos ausentes

O RFC 1681 descreveu quatro esquemas de cobrança por uso. No modelo tradicional, cada host pagaria pelos próprios pacotes, fazendo ambos os lados arcarem com parte da conversa. Em “caller pays”, pagaria quem iniciou. Uma chamada a cobrar transferiria a despesa ao destinatário. Um serviço equivalente a um número norte-americano “900” cobraria um prêmio do chamador.

Com essa variedade, chamador e receptor precisavam saber com antecedência quem pagaria. Descobrir somente depois que um custo já havia sido incorrido era inaceitável.

Mas o pagador é apenas uma coordenada. O RFC 1125 havia separado unidade contábil, base da cobrança, valor real, quem paga ou recebe, qual contador de pacotes prevalece e quais limites se aplicam. Reconhecer corretamente a classe “chamador paga” não diz se a tarifa é por byte, pacote, minuto ou sessão, qual versão está em vigor, de quem é a medição válida ou qual teto foi autorizado.

A extensão por índice do RFC 1681 torna a dependência explícita. Se o endereço aponta para uma linha, o significado está na tabela mantida por alguém, em uma versão e intervalo determinados. Guardar o endereço e perder a tabela preserva a chave, não a regra.

O roteador tinha poder de recusa, não de consentimento

Um roteador de borda oferecia uma superfície local de execução. O RFC 1681 imaginou que estações anônimas de um laboratório em dormitório não pudessem fazer chamadas a cobrar. A organização controlaria quais classes atravessariam sua fronteira sem esperar uma atualização de todos os aplicativos.

Essa decisão não representava automaticamente a pessoa. A máquina poderia ser compartilhada; o pedido, automático; o dono da conta, diferente do usuário presente; a autorização, limitada a determinado valor. A tabela do serviço remoto também poderia divergir da versão consultada na origem. O roteador poderia cumprir sua política e ainda deixar a cobrança contestável.

O documento também sugeriu atribuir um endereço IP separado a cada usuário durante a sessão. O roteador continuaria medindo por endereço; o host registraria a associação; a cobrança ocorreria depois, fora de linha. Classes distintas de usuários poderiam receber formatos de endereço que permitissem ou negassem serviços caros.

O ganho era juntar evidências com granularidade melhor. Não era autenticação humana embutida no IP. Seriam necessários a medição do roteador, o registro temporal do host, as credenciais, o mandato de gasto, a tabela aplicável e os registros do serviço. Um endereço por usuário reduz candidatos, mas não prova quem operou a sessão nem quem aprovou aquele custo.

O futuro não converteu a proposta em implantação

O registro do RFC Editor classifica o RFC 1681 como Informational. Ele respondeu à solicitação de textos sobre IPng do RFC 1550 e declarou que a publicação não significava aceitação das ideias pela área IPng. O RFC 1550 tratou esses documentos como material de trabalho e parte do registro histórico do processo.

É verdade que múltiplos endereços se tornaram comuns na arquitetura IPv6. O RFC 4291 atribui endereços a interfaces e permite que uma interface tenha vários tipos e escopos. Isso não demonstra que o IPv6 adotou bits de cobrança, nem que essa arquitetura derivou causalmente do RFC 1681.

Também surgiu um registro explícito para localização de serviços. O RFC 2782 define no DNS SRV serviço, protocolo, prioridade, peso, porta e alvo, com regras de uso estabelecidas pelo protocolo cliente. Ele localiza um serviço; não padroniza preço, pagador, consentimento, medidor ou fatura.

A recomendação de reservar 2^6 e talvez 2^8 endereços adicionais por host era folga de planejamento para usos possíveis, especialmente o dispendioso endereço por usuário e a alocação esparsa. Não era média observada ou direito de alocação.

Cada etapa entre o sinal e o pagamento precisa sobreviver

Uma trilha auditável teria de preservar separadamente o destino escolhido; a classe ou índice; a tabela vigente, seu operador e intervalo; a decisão da borda; a conta e o principal autenticados; os termos apresentados antes do compromisso e a resposta do usuário; a admissão e entrega útil do serviço; unidade, contador e período medidos; cálculo, pagador e limites da fatura; e a liquidação, reversão ou disputa.

Nenhuma etapa prova a seguinte. A classe reconhecida não prova que a tabela estava atualizada. A passagem pelo roteador não prova concordância. A conexão não prova utilidade. O contador não define a tarifa. A fatura não prova quitação.

A Primazia do Código em Execução de Heng Lu impede promover uma proposta, publicação ou etiqueta a realidade adotada e observada. A Especificação Inicial Mínima separa a semântica comum indispensável de arranjos comerciais que podem permanecer locais. Realidade, não promoção mantém a conclusão dentro das fontes: não é preciso reviver nem ridicularizar o mecanismo.

O RFC 1681 queria que a rede enxergasse uma regra antes de gastar o dinheiro de alguém. O princípio de ordem permanece mais sólido que a codificação proposta: informação antecipada reduz surpresa somente quando identidade, autoridade, prestação, medição e pagamento continuam verificáveis por evidências próprias.

Fontes