Resumo

  • O RFC 3059 permitiu que um User Agent pedisse, por uma extensão propositalmente vazia, que cada URL da Service Reply viesse acompanhada da lista completa de atributos registrados.
  • Como 0x0002 era opcional e ignorável quando desconhecida, a falta da extensão iniciava Attribute Requests por URL. Não comprovava uma lista vazia e também podia ocorrer quando o respondente não conseguia fornecer o bloco exigido por um SLP SPI.

O vazio era uma ação

Descobrir candidatos e conhecer suas propriedades são etapas distintas. No SLPv2 básico, a Service Request devolvia URLs. Para obter os atributos, o User Agent enviava depois uma Attribute Request para uma URL ou um tipo de serviço.

Publicado como Proposed Standard em fevereiro de 2001, o RFC 3059 encurtou esse caminho. O cliente incluía uma Attribute List Extension na Service Request. Nessa direção, Service URL Length e Attribute List Length eram zero, e os campos não apareciam. A cápsula vazia queria dizer: inclua os atributos na resposta.

Zero, ali, não descrevia o serviço. Era gramática de solicitação. Interpretá-lo como ausência de atributos transformaria uma pergunta em resposta antes que o SA ou DA tivesse falado.

Cada URL carregava sua própria junção

Um SA ou DA compatível devolvia uma extensão para cada URL Entry da Service Reply. A extensão trazia a Service URL correspondente e a lista inteira de atributos. A ordem deveria acompanhar as URL Entries, mas a URL também estava gravada dentro de cada extensão.

Logo, o vínculo autoritativo era a URL. A ordem servia de conferência, não de substituto para identidade. Associar duas listas apenas pela posição desperdiçaria o identificador explícito do protocolo.

“Lista inteira” continuava limitada ao anúncio registrado, no idioma da Service Request. Não era uma inspeção de todas as propriedades do processo vivo. O registro podia permanecer válido enquanto a conexão falhava; uma capacidade não registrada ficava fora da lista. O RFC acelerava uma descrição anunciada, não produzia prova de execução.

O número opcional preservava compatibilidade

IANA registrou 0x0002. O RFC 2608 colocou 0x0000 a 0x3FFF na faixa padronizada, opcional de implementar e ignorada quando desconhecida. Um par antigo podia, portanto, devolver uma Service Reply normal.

O User Agent assumia o custo dessa compatibilidade. Sem a extensão na resposta, ele deveria concluir apenas que o SA ou DA não a suportava e enviar uma Attribute Request para cada URL obtida. Ausência era estado incompleto e gatilho de fallback, não valor zero.

Extensões posteriores não compartilhavam necessariamente essa semântica. Select e Sort, no RFC 3421, usaram a faixa obrigatória e OPTION_NOT_UNDERSTOOD. O RFC 3224 tratou dados opacos de fornecedor; o RFC 3082, assinaturas de notificação. A forma “extensão” não autorizava importar uma reação de erro para outra.

O SPI podia retirar o enriquecimento

A Service Request podia carregar um SLP Security Parameter Index. Nesse caso, toda Attribute List Extension retornada precisava conter um bloco de autenticação daquele SPI. Se o SA ou DA não o suportasse ou não conseguisse produzi-lo, a extensão não deveria ser enviada.

Assim, a mesma ausência visível podia vir de código não implementado ou de um contexto de autenticação impossível de satisfazer. O cliente tinha uma ação segura — recorrer às consultas individuais — mas não uma justificativa para inventar qual causa ocorrera.

O bloco autenticado também não era uma garantia total. Pelo RFC 2608, verificava integridade do conteúdo coberto e autoria por agente autorizado, segundo material de chave e expiração do SPI. Não demonstrava alcance atual, permissão do usuário ou êxito da operação de negócio.

Menos pacotes não significavam mais verdade

Quatro resultados podiam exigir uma descoberta e quatro consultas de atributos. Com apoio mútuo, a descrição vinha em uma única resposta. A latência diminuía, mas a autoridade dos dados permanecia a do anúncio.

Quando sistemas perdem essa separação, uma tela mostra “sem capacidade” porque faltou enriquecimento; um inventário grava zero porque não executou fallback; um seletor elimina um serviço porque confundiu “não veio aqui” com “não existe”. O RFC 3059 determinava o contrário: observe o recibo ausente e faça a segunda pergunta.

Fontes