Resumo

  • Who-Provides? convidava respostas positivas em broadcast; o silêncio não tinha força de negativa explícita.
  • Do-You-Provide? exigia resposta do host endereçado, inclusive uma lista vazia, enquanto They-Provide permanecia uma indicação de terceiro a ser confirmada.
  • O nome do recurso seguia os pontos de demultiplexação e mantinha separadas a oferta do transporte, da porta e de uma especialização de aplicação.

A situação inicial da RFC 887 é prática: um host recém-iniciado precisa de um gateway, mas ainda não sabe o endereço de nenhum. Em vez de depender apenas de uma lista fixa, ele pode perguntar à rede local.

O Resource Location Protocol, publicado em dezembro de 1983, não encerra o problema com a primeira resposta. Ele cria uma escada de evidência na qual procurar, receber uma indicação e confirmar o provedor são ações diferentes.

O recurso era nomeado de baixo para cima

O primeiro octeto do nome identificava o protocolo Internet de nível mais baixo usado para acessar o recurso. Vinham depois o comprimento e os valores naturais que faziam a demultiplexação nos níveis superiores. Para DNS sobre UDP, o exemplo era protocolo 17 e porta 53.

O comprimento explícito permitia ignorar um identificador desconhecido e encontrar corretamente o item seguinte. Na análise do nome, três resultados importavam: uma camada inferior não suportada; o término exato do nome depois de verificações bem-sucedidas; ou componentes extras que o host já não entendia.

Só o término exato autorizava a afirmação completa. Oferecer TFTP não implicava oferecer uma função especializada de crash dump sobre TFTP. A RFC 887 evitava que uma capacidade ampla anexasse, sem prova, todas as capacidades mais estreitas.

O broadcast fazia uma pergunta assimétrica

Who-Provides? era enviado normalmente por broadcast. O host que oferecesse algum item respondia com I-Provide; quem não oferecesse podia permanecer em silêncio.

Isso poupava respostas, mas o silêncio podia ser ausência real, perda do pedido, perda da resposta ou falta de RLP em um equipamento que ainda possuía o serviço. A RFC 919 caracterizou o broadcast IP como não confiável, sem sequência e sujeito a duplicação. Cada mensagem ainda consome trabalho de todos os hosts que a recebem.

Perguntar à coletividade reduzia configuração estática, ao preço de atenção compartilhada e de um negativo inconclusivo.

A resposta vazia ganhava sentido numa pergunta direta

Do-You-Provide? tinha um destinatário conhecido. Esse host precisava responder mesmo quando nenhum recurso da lista era oferecido. Um I-Provide vazio registrava uma negativa explícita daquela máquina para aquela consulta.

Era proibido transmitir essa variante por broadcast. Se toda máquina tivesse de negar, uma pergunta produziria uma tempestade. Assim, o protocolo reservou respostas apenas positivas para o grupo e respostas positivas ou negativas para o destinatário individual.

A negativa direta continuava limitada. Não falava por outros servidores, outro horário ou outra especialização do nome.

Um host “inteligente” podia indicar, não confirmar

Who-Anywhere-Provides? e Does-Anyone-Provide? consultavam uma máquina conhecida sobre serviços que ela acreditava existir em outros hosts. Essa função ajudava redes sem broadcast e permitia aproveitar conhecimento obtido em redes vizinhas.

A resposta They-Provide era deliberadamente mais fraca. A RFC dizia que o cliente não precisava confiar nela sem exame e que, em geral, deveria enviar Do-You-Provide? diretamente ao endereço indicado.

No exemplo de DNS, a busca local produz uma resposta vazia. Com o escopo ampliado, o intermediário aponta S. S nega diretamente. O cliente exclui S, pergunta novamente, recebe T e só então obtém de T a confirmação para UDP 53.

O intermediário podia estar desatualizado sem ser malicioso. Preservar a origem de cada afirmação separava erro de memória, mudança operacional e falsidade.

O flag Local-Only controlava quais endereços podiam aparecer e qual endereço local um host multihomed usaria. Escopo fazia parte da pergunta e podia mudar o conjunto visível de provedores.

Correlacionar não era autenticar

O Message-ID de 16 bits ajudava a associar respostas ao pedido. Não provava identidade, autorização nem frescor criptográfico. O checksum UDP também não era assinatura.

Mesmo uma confirmação direta dizia somente que o host afirmava oferecer o recurso nomeado. Não provava que a próxima operação terminaria, que toda a especificação era suportada, que o cliente tinha permissão ou que o serviço permaneceria saudável.

Protocolos posteriores escolheram outras estruturas

A comparação não estabelece descendência. A RFC 2608 organizou o SLPv2 em tipos e atributos de serviço, User Agents, Service Agents, Directory Agents e escopos administrativos. Também definiu autenticação de URLs e atributos, sem oferecer confidencialidade.

A RFC 6762 levou operações semelhantes às do DNS para o link local sem exigir um servidor unicast convencional. A RFC 6763 estruturou a descoberta de instâncias nomeadas por tipo e domínio. Mudaram nomes e mecanismos; anúncio, confirmação, confiança e efeito continuaram distintos.

A porta registrada não mantinha o serviço vivo

A RFC 887 atribuiu a porta UDP 39. O registro de nomes de serviço e portas da IANA ainda mostra rlp na porta 39 para TCP e UDP. A linha demonstra continuidade administrativa, não prevalência operacional.

A RFC 6335 esclarece que uma atribuição não endossa uma aplicação e que o tráfego na porta pode nem pertencer ao serviço registrado. Registro coordena o espaço de nomes; não observa execução.

Fontes e limites

O texto usa as RFCs 887, 919, 2608, 6762, 6763 e 6335 e o registro IANA. Elas não medem a adoção histórica de RLP, não provam relação causal com os protocolos posteriores e não estabelecem o comportamento atual de nenhum produto ou operador.