Resumo

  • Um registro no Resource Directory contém nome, URI base, links e vida útil; não é um recibo de disponibilidade atual do endpoint.
  • Registro, descoberta, alcance de rede, autenticação, resposta de recurso e efeito operacional exigem evidências separadas e datadas.

O problema que um Resource Directory resolve é descoberta em redes restritas, não observação contínua da operação. Um nó pode dormir e o multicast pode ser caro ou inadequado. Por isso, o RFC 9176 permite que endpoints e ferramentas de comissionamento registrem, atualizem e removam descrições de recursos em um RD; clientes então pesquisam os links registrados. A utilidade é ter uma superfície comum para localizar descrições, e não transformar uma descrição em batimento cardíaco do equipamento.

O formato da entrada delimita o que foi afirmado. Ela associa um endpoint a nome, URI base, tempo de vida, localização do recurso de registro no RD, conjunto de links e, quando aplicável, sector e atributos. Ao aceitar a criação, o RD devolve uma localização que o registrante usa para atualizar a vida útil, manter links ou remover a entrada. Essa resposta demonstra que o próprio RD aceitou um recurso de registro. Não demonstra que o dispositivo terá energia, permanecerá conectado ou executará o mesmo serviço quando outra pessoa fizer uma consulta.

A vida útil é a parte que impede uma leitura descuidada. O registro é estado suave e deve ser renovado periodicamente. Depois de expirar, o RD não deve oferecer resultados de descoberta para aquele endpoint; ainda assim, pode conservar o recurso de registro para que um endpoint tardio o renove e pode coletá-lo mais tarde. Assim, um objeto administrativo que permaneça depois do vencimento não é prova de retorno do endpoint, restauração do serviço ou sucesso de uma tarefa. É um elemento da máquina de estados do diretório.

O resultado de uma busca também é limitado. O RD devolve links submetidos no registro e resolve referências relativas contra o URI base. Isso mostra como o registrante descreveu recursos em determinado momento. Não é uma tentativa, a partir da posição do consultante, de abrir caminho até o URI. Não verifica rota atual, transporte, credenciais, autorização daquele cliente, processamento da requisição nem efeito físico. Um URI pode continuar bem formado quando o endpoint está desligado; uma resposta de recurso pode parecer válida sem que a ação prometida pela aplicação tenha ocorrido.

Identidade e permissão não podem ser inferidas de campos do diretório. O RFC 9176 observa que protocolo, porta e endereço IP não bastam para identificar um endpoint, pois podem mudar ao longo de sua vida. Quem pode usar um nome de endpoint ou sector depende da política de segurança; controles de acesso para registro e para busca também devem ser distintos. Poder ler um link não concede direito de operar o recurso, e poder escrever um registro não torna sua descrição uma verdade persistente.

Uma prática verificável separa o pedido de registro e a resposta do RD, a localização devolvida, autorização de nome e sector, URI base, links, vida útil e histórico de renovação. A busca precisa trazer hora e posição de observação. Para afirmar disponibilidade de serviço, acrescentam-se testes diretos de alcance, resultados de transporte e autenticação, requisição e resposta do recurso e evidência do efeito na aplicação. A distinção corresponde à disciplina de Lu Heng: uma interface compartilhada reduz custo de coordenação, mas não toma decisões do operador nem substitui a observação do que está rodando.

Fontes