Resumen

  • RFC 3080 permitía varios intercambios independientes dentro de una sesión BEEP. El canal cero administraba la sesión, pero el perfil aceptado definía la sintaxis y el significado de cada canal de aplicación.
  • Una conexión activa podía no tener ningún perfil útil seleccionado. Incluso un canal abierto y una respuesta válida podían no producir el efecto esperado fuera del protocolo.

La sesión empezaba antes que la conversación

Dos equipos pueden abrir una conexión, entender sus saludos y rechazar todas las propuestas de perfil. El transporte está sano. El canal cero funciona. La aplicación todavía no existe entre ellos.

Ésa fue la frontera que RFC 3080 volvió explícita en marzo de 2001. BEEP era un núcleo genérico para interacciones asíncronas orientadas a conexión. Permitía intercambios simultáneos e independientes bajo una identidad de usuario común, pero no imponía a la conexión un solo lenguaje de aplicación.

El soporte físico quedaba en otro documento. RFC 3081 describió cómo una sesión BEEP ocupaba una conexión TCP. Por tanto, completar TCP no elegía un perfil ni autorizaba trabajo. Era una condición necesaria situada dos capas antes.

El canal cero abría puertas, no realizaba operaciones

Al comenzar sólo existía el canal cero. Por él viajaban el saludo, la lista de perfiles ofrecidos, las peticiones de apertura y cierre y la liberación de la sesión.

El saludo era un anuncio. No convertía cada URI enumerado en un canal disponible. Para eso hacía falta start: un número propuesto y una o más alternativas de perfil. El receptor podía escoger una y responder positivamente, o negarlas todas. La selección estaba en la respuesta; la publicidad anterior no era consentimiento.

La asignación de números evitaba un árbitro. El iniciador elegía impares y el oyente pares. Cada extremo conservaba espacio propio para abrir canales sin carrera con el otro. Era una regla pequeña, determinista y suficiente para la colisión que debía resolver.

Un número de canal no describía la aplicación

El perfil elegido daba sintaxis y semántica al canal. El núcleo aportaba patrones: MSG iniciaba; RPY o ERR resolvían uno a uno; ANS producía respuestas múltiples y NUL cerraba la serie. Los números de mensaje identificaban intercambios; las secuencias contaban octetos de carga dentro de cada canal.

Las tramas de canales distintos podían alternarse. Un mensaje fragmentado conservaba su orden local, mientras varias respuestas ANS podían intercalarse con un número propio. Eso permitía concurrencia, no demostraba prioridad justa ni terminación.

Los usos posteriores conservaron esa división. RFC 3195 puso entrega fiable de syslog en perfiles BEEP. RFC 4227 añadió a SOAP un estado de arranque y preparación. RFC 4744 hizo de NETCONF otro perfil y separó manager/agente de iniciador/oyente. El marco sabía transportar conversaciones; cada aplicación seguía teniendo que explicar cuándo estaba lista y qué producía.

Proteger la sesión obligaba a olvidar el pasado

RFC 3080 distinguía canales de ajuste inicial y canales continuos. TLS y SASL podían transformar la seguridad y la identidad de la sesión, pero sólo un ajuste debía estar activo a la vez.

Tras negociar TLS, la información almacenada antes de la protección debía desecharse. Un atacante podía haberla modificado. La nueva confidencialidad no certificaba el estado viejo.

La autenticación tampoco concedía autoridad automática. Cada canal debía aplicar control de acceso según la identidad y el nivel de privacidad. Saber quién estaba al otro lado no significaba aceptar cualquier perfil o ejecutar cualquier mensaje.

La independencia necesitaba presupuesto propio

RFC 3081 mostró por qué multiplexar no consistía sólo en etiquetar tramas. TCP controlaba el flujo de toda la conexión. BEEP añadió ventanas por canal para impedir hambre y bloqueo mutuo. Un canal nacía con 4096 octetos y SEQ anunciaba la siguiente secuencia esperada y el espacio disponible.

TCP ya resolvía la entrega fiable. La nueva ventana repartía capacidad entre conversaciones. Una aplicación lenta debía consumir menos del recurso común para que las demás avanzaran.

Los puertos también tuvieron historia

BEEP recibió perfiles para syslog, SOAP y NETCONF. Años después, RFC 9900 liberó el puerto de NETCONF sobre BEEP y los de NETCONF sobre SOAP, pero conservó los nombres de servicio.

La secuencia evita dos exageraciones. Publicar un RFC no demostraba adopción. Liberar un puerto no convertía en absurda la separación original. Especificación, registro, implementación y uso tenían estados propios.

El legado útil de RFC 3080 es una disciplina de evidencia. Un saludo no era selección. start aceptado no era autorización empresarial. RPY no era persistencia. El cierre limpio del canal no era prueba de que el mundo exterior había cambiado.

Fuentes

  1. https://www.rfc-editor.org/info/rfc3080
  2. https://www.rfc-editor.org/rfc/rfc3080.html
  3. https://datatracker.ietf.org/doc/rfc3080/
  4. https://www.rfc-editor.org/rfc/rfc3081.html
  5. https://www.rfc-editor.org/rfc/rfc3117.html
  6. https://www.rfc-editor.org/rfc/rfc3195.html
  7. https://www.rfc-editor.org/rfc/rfc4227.html
  8. https://www.rfc-editor.org/rfc/rfc4744.html
  9. https://www.rfc-editor.org/rfc/rfc9900.html
  10. https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
  11. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  12. https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/