Resumen

  • Who-Provides? buscaba respuestas positivas en una red local, pero la falta de respuesta no demostraba que el recurso no existiera.
  • Do-You-Provide? obligaba al destinatario concreto a responder incluso con una lista vacía, y una referencia aportada por un tercero seguía siendo una pista que convenía confirmar.
  • El nombre del recurso codificaba la ruta de demultiplexación, de modo que reconocer el transporte o el puerto no implicaba reconocer todas las funciones superiores.

Un negativo explícito cuesta más que el silencio. Hay que saber a quién preguntar, lograr que la pregunta llegue y exigir que la otra parte conteste aunque no tenga nada que ofrecer. La RFC 887, publicada en diciembre de 1983, hizo de ese coste una elección del protocolo.

Su Resource Location Protocol permitía empezar sin una dirección de servidor. Pero no confundía la búsqueda abierta con la comprobación de un candidato. Cada paso producía una afirmación distinta y conservaba a su autor.

Nombrar un recurso era describir cómo alcanzarlo

El identificador empezaba por el número del protocolo Internet inferior. Después aparecían una longitud y los componentes naturales que iban seleccionando el servicio en niveles superiores. Para DNS sobre UDP, el documento usó 17 y 53. Una función especializada podía añadir más componentes.

La longitud permitía saltar una estructura desconocida y continuar con el siguiente recurso de la lista. Al evaluar un nombre, el receptor distinguía tres finales: un componente inferior no soportado, el agotamiento exacto del nombre después de comprobaciones exitosas y la presencia de componentes adicionales que ya no sabía interpretar.

Solo el segundo caso producía la afirmación completa. Una máquina podía aceptar UDP, escuchar TFTP y aun así no proporcionar una variante concreta de volcado de memoria. La arquitectura evitaba que el soporte de una capa se apropiara de la semántica de la siguiente.

La difusión pedía voluntarios positivos

Una consulta Who-Provides? se enviaba normalmente por difusión. Quien ofrecía alguno de los recursos respondía con I-Provide; quien no coincidía podía permanecer callado.

Eso reducía el número de respuestas, aunque hacía ambiguo el vacío. Podía no existir un proveedor, o haberse perdido la consulta, la respuesta, o faltar RLP en la máquina que sí tenía el servicio. La RFC 919 describió la difusión IP como no fiable, no secuenciada y posiblemente duplicada. También recordó que cada mensaje obliga a trabajar a todos los hosts que lo oyen.

La difusión resolvía el problema de no conocer direcciones a cambio de consumir atención colectiva. El protocolo no autorizaba a convertir ese intercambio imperfecto en un censo completo.

La pregunta dirigida convertía el vacío en respuesta

Do-You-Provide? se enviaba a una dirección concreta. El destinatario debía contestar tanto si reconocía el recurso como si no. Una lista vacía era entonces un no explícito para esa máquina y esa pregunta.

Difundir esta variante estaba prohibido. Si todas las máquinas tuvieran que enviar un negativo, el solicitante recibiría una avalancha. RFC 887 ajustó la obligación de hablar al tamaño del público: en el grupo, solo los positivos; ante un interlocutor, positivos y negativos.

El negativo seguía siendo local. No decía nada sobre otra dirección, otro instante o un nombre ligeramente distinto. Su fuerza provenía de no fingir más alcance.

Un tercero podía recordar mal sin mentir

Las consultas Who-Anywhere-Provides? y Does-Anyone-Provide? pedían a un host conocido información sobre terceros. Servían donde no había difusión o cuando una máquina “inteligente” había aprendido direcciones en otras redes.

La respuesta They-Provide no recibía autoridad automática. RFC 887 recomendaba tratarla como pista y preguntar directamente al host mencionado mediante Do-You-Provide?.

El ejemplo DNS muestra una corrección completa. Primero no aparece ningún candidato dentro del alcance local. Al ampliar el alcance, el intermediario propone S. S niega directamente. El cliente excluye esa dirección, vuelve a consultar y recibe T, que sí confirma el servicio UDP en el puerto 53.

La secuencia conserva dos tiempos: el del conocimiento del intermediario y el de la respuesta actual del servidor. Una discrepancia puede ser obsolescencia, no fraude. Perder la procedencia convertiría una pista envejecida en una contradicción inexplicable.

El alcance formaba parte de la consulta

La marca Local-Only limitaba las direcciones devueltas a la red IP del solicitante. Además, obligaba a un host con varias interfaces a escoger la dirección local adecuada. La misma clase de servicio podía resultar visible o invisible según el alcance pedido.

El Message-ID de 16 bits ayudaba a emparejar respuestas. No verificaba identidad ni permiso. El checksum UDP protegía contra ciertos errores accidentales, no contra una afirmación falsa. Un I-Provide directo tampoco garantizaba la siguiente operación, la conformidad completa o la autorización del cliente.

Los diseños posteriores hicieron explícitos otros controles

La comparación no implica descendencia directa. La RFC 2608 definió SLPv2 con tipos y atributos, agentes de usuario, de servicio y de directorio, y ámbitos administrativos. También añadió autenticación para URL y atributos, aunque no confidencialidad.

La RFC 6762 llevó operaciones parecidas a DNS al enlace local sin servidor unicast convencional. La RFC 6763 permitió descubrir instancias con nombre según tipo y dominio. Cambiaron las estructuras; no desapareció la necesidad de separar anuncio, alcance, identidad y efecto.

El puerto 39 es memoria administrativa

RFC 887 asignó el puerto UDP 39. El registro de nombres de servicio y puertos de IANA conserva rlp en el 39 para TCP y UDP. Esa fila prueba coordinación registral, no uso actual.

La RFC 6335 advierte que una asignación no avala una aplicación y que el tráfico de un puerto puede no corresponder al servicio registrado. Un número organiza expectativas; no responde por una máquina.

Fuentes y límites

El artículo utiliza RFC 887, RFC 919, RFC 2608, RFC 6762, RFC 6763, RFC 6335 y el registro IANA. Las fuentes no miden la difusión histórica de RLP, no demuestran una línea causal hacia protocolos posteriores y no prueban el comportamiento presente de productos o redes concretas.