Resumen

  • RFC 3059 permitió que un User Agent pidiera mediante una extensión deliberadamente vacía que cada URL de una Service Reply trajera su lista completa de atributos registrados.
  • Como 0x0002 era opcional y debía ignorarse si resultaba desconocida, su ausencia activaba Attribute Requests por URL. No constituía una lista vacía confirmada, y también podía surgir si el servidor no podía aportar el bloque exigido por un SLP SPI.

La petición parecía vacía porque aún era una pregunta

Encontrar candidatos y conocer sus propiedades son operaciones diferentes. En SLPv2, una Service Request obtenía URL de servicios; una Attribute Request posterior recuperaba atributos para una URL o un tipo de servicio. Cuantos más candidatos hubiera, más consultas podían seguir.

RFC 3059, publicado como Proposed Standard en febrero de 2001, ofreció un atajo. El User Agent insertaba una Attribute List Extension en la Service Request. En esa dirección, Service URL Length y Attribute List Length valían cero, y los campos se omitían. La estructura vacía significaba «incluya los atributos en la respuesta».

No era evidencia de que el objeto buscado estuviera vacío. El significado dependía de la dirección y de la función del mensaje. Convertir los ceros de la petición en una afirmación sobre el servicio sería responder antes que el servidor.

La URL unía cada descripción con su candidato

Un SA o DA compatible devolvía una Attribute List Extension por cada URL Entry de la Service Reply. Dentro figuraban la Service URL correspondiente y la lista completa de atributos. El orden debía ser el mismo que el de las URL Entries, pero la propia URL también viajaba en cada extensión.

Por eso la identidad residía en la URL. La posición ayudaba a comprobar coherencia; no sustituía el vínculo explícito. Un cliente que emparejara listas sólo por índice estaría descartando una prueba de identidad proporcionada por el protocolo.

La palabra «completa» tampoco prometía omnisciencia. Era la lista registrada que el SA o DA conservaba para el servicio y en el idioma de la petición. No incluía necesariamente toda capacidad real. Un registro podía seguir vivo mientras el servicio había dejado de responder. RFC 3059 transportaba mejor una descripción anunciada; no medía la ejecución.

El rango opcional protegía a los interlocutores antiguos

IANA asignó 0x0002. RFC 2608 reservaba 0x00000x3FFF para extensiones normalizadas pero opcionales, que debían ignorarse si no se reconocían. Así, un par antiguo podía enviar una Service Reply normal sin comprender el nuevo campo.

El precio de esa compatibilidad lo pagaba el cliente con trabajo adicional. Al recibir una respuesta sin Attribute List Extension, debía asumir que el SA o DA no la soportaba y enviar una Attribute Request para cada URL. La ausencia no cerraba la investigación; abría el camino de recuperación.

Otros documentos usaron reglas diferentes. Select y Sort en RFC 3421 pertenecían al rango obligatorio y podían generar OPTION_NOT_UNDERSTOOD. RFC 3224 y RFC 3082 dieron funciones distintas a extensiones de proveedor y de suscripción. Son contrastes que impiden generalizar, no actualizaciones retroactivas de 0x0002.

La autenticación añadía otra causa de ausencia

Una Service Request podía indicar un SLP Security Parameter Index. En ese caso, cada extensión de atributos devuelta tenía que incluir un bloque de autenticación para dicho SPI. Si el SA o DA no lo soportaba o no podía producir el bloque, no debía devolver la extensión.

La misma superficie —URL presentes, atributos no adjuntos— podía representar falta de implementación o imposibilidad de satisfacer el contexto de autenticación. RFC 3059 prescribía el mismo siguiente paso práctico, pero no convertía el silencio en un diagnóstico exacto.

El bloque verificaba un recibo limitado. Conforme a RFC 2608, permitía comprobar que el contenido cubierto no había cambiado y había sido enviado por un agente autorizado, usando el material y la caducidad del SPI. No probaba que el servicio siguiera alcanzable, que el usuario pudiera entrar ni que una operación terminara bien.

Se acortaba la conversación, no la cadena de autoridad

Para cuatro URL, el procedimiento básico podía requerir una petición de servicio y cuatro peticiones de atributos. Con soporte mutuo, la descripción llegaba en una sola respuesta. El número de mensajes caía; la naturaleza del dato no cambiaba.

Confundir ambos efectos produce inventarios engañosos. Una interfaz muestra «sin capacidades» cuando no recibió enriquecimiento. Un proceso guarda cero porque omitió el fallback. Un selector rechaza una URL válida porque interpreta «no transportado» como «inexistente». La disciplina de RFC 3059 era sencilla: registrar el recibo que falta y preguntar de nuevo por cada URL.

Fuentes