Resumen

  • RFC 3529 ordenó devolver tanto el resultado normal como el fallo XML-RPC dentro de RPY; ERR quedaba para problemas de la capa BEEP.
  • Resolver el nombre, proteger la sesión y completar el patrón solicitud-respuesta no demostraba autorización, éxito de negocio ni persistencia del efecto.

La operación más peligrosa para un sistema de métricas no siempre es la que desaparece. A veces llega completa, correlacionada y con una envoltura positiva, pero contiene un rechazo perfectamente válido. RFC 3529 diseñó exactamente ese caso al transportar XML-RPC sobre BEEP.

Primero se creaba un canal para un perfil identificado. Su estado inicial era boot. El iniciador enviaba bootmsg y nombraba un recurso. Si el servidor lo reconocía, respondía bootrpy; solo entonces el perfil quedaba ready. Si el mensaje era defectuoso o el recurso no existía, la respuesta era error o una trama ERR, y no había transición.

Después empezaba otro espacio semántico. El cliente enviaba methodCall en una trama BEEP MSG. El servidor devolvía methodResponse en RPY. RFC 3529 aclaró que un fallo XML-RPC no debía cambiar esa trama exterior a ERR: cualquier respuesta generada por el servidor viajaba en RPY.

La consecuencia era precisa. RPY significaba que BEEP había completado la mitad de respuesta del intercambio uno-a-uno. No significaba que la aplicación hubiese aceptado parámetros, autorizado al actor, encontrado el objeto o aplicado el cambio. El lector tenía que abrir el cuerpo XML y distinguir una respuesta normal de una estructura de fallo.

Mantener separados esos dos veredictos evitaba perder causalidad. Un ERR podía señalar que ni siquiera había un intercambio XML-RPC utilizable. Un fallo dentro de RPY demostraba algo diferente: la solicitud alcanzó una lógica capaz de producir un rechazo aplicativo. Para diagnóstico, recuperación y responsabilidad, ambas situaciones no eran intercambiables.

La URL tampoco era un comprobante de servicio. xmlrpc.beep vinculaba la autoridad con serverName y el camino con el recurso de arranque. Cuando faltaba un puerto explícito, el cliente podía consultar el registro SRV _xmlrpc-beep._tcp; si no encontraba uno adecuado, resolvía la dirección y usaba el puerto asignado. El resultado de DNS elegía un destino. No certificaba un proceso en escucha, un perfil compatible ni una llamada exitosa.

xmlrpc.beeps añadía una obligación antes del perfil: ajustar la sesión BEEP para privacidad. TLS o un perfil de autenticación con seguridad de transporte podía cumplirla. Con TLS, la autoridad de la URL se comparaba con la identidad presentada por el certificado. Esto daba evidencia sobre confidencialidad y sobre el par alcanzado, pero no convertía la identidad de transporte en autorización de método.

La tecnología de seguridad exigida conserva una fecha. DIGEST-MD5 y una suite RSA/3DES eran requisitos mínimos en 2003. RFC posteriores sustituyeron el marco SASL anterior y retiraron versiones y prácticas TLS antiguas. El valor histórico de RFC 3529 no es aconsejar esas opciones hoy, sino mostrar dónde terminaba cada garantía.

El registro coordinó un perfil, los esquemas xmlrpc.beep y xmlrpc.beeps, y el servicio xmlrpc-beep en TCP 602. Una entrada IANA puede demostrar que un nombre fue reservado y descrito. No puede demostrar que siga desplegado, que un producto lo implemente, que una conexión lleve tráfico real ni que una transacción de negocio haya terminado.

La comparación con SOAP sobre BEEP revela el momento de diseño. BEEP ofrecía sesiones y canales reutilizables; XML proporcionaba envolturas de aplicación; SRV permitía localizar servicios. La combinación reducía la necesidad de inventar un transporte para cada protocolo. A cambio, cada recibo debía conservar su dueño: DNS elegía, TCP conectaba, BEEP encuadraba, TLS protegía y XML-RPC decidía el significado del resultado.

Un registro operativo fiel debía guardar la autoridad original, el destino elegido, la identidad del par, el canal, el recurso, el número de mensaje, la clase de trama y la forma del cuerpo. Si la llamada cambiaba datos, todavía faltaba la evidencia de la aplicación: una versión posterior, un identificador durable o una lectura que confirmara el estado.

Los reintentos hacían material esta distinción. Una desconexión sin respuesta dejaba ambiguo si hubo ejecución. Un RPY con fallo daba una negativa explícita, pero no prometía por sí mismo ausencia de efectos parciales. Repetir una llamada no idempotente porque el monitor solo vio “falló la solicitud” podía duplicar la consecuencia que se intentaba recuperar.

RFC 3529 fue Experimental, y eso limita cualquier relato de adopción. No limita su lección documental: una respuesta puede ser positiva respecto de su transporte y negativa respecto de su contenido. La observabilidad madura guarda las dos cosas sin permitir que una borre a la otra.

Sources