Resumen

  • El cambio de control señalado por el propio registro de revisiones de MOQT es concreto: en el parámetro 0x21, el campo Length del borrador 21 pasa a ser Location Filter Type en el 22. Los valores 0x00 a 0x05 determinan qué datos siguen y qué filtro se pide; cualquier otro valor es PROTOCOL_VIOLATION.
  • Esta es una propuesta de protocolo del grupo de trabajo MOQ, actualizada el 1 de octubre, que aún consta como Internet-Draft. No hay en las fuentes una avería medida, un despliegue obligatorio ni una RFC terminada.

Quien opera un servicio en tiempo real suele vigilar si el suscriptor se conecta y si el relevo responde. Esas dos señales son insuficientes cuando la orden relevante es «empieza aquí» o «dame este intervalo». La conexión puede estar sana mientras una aplicación y un relevo esperan codificaciones distintas de la posición solicitada. La revisión hace visible la pregunta de compatibilidad antes de que el equipo declare aceptada una actualización.

En el texto anterior, LOCATION_FILTER llevaba primero su identificador 0x21 y después una longitud codificada como entero variable. Según el número de bytes anunciado se entendía que venían cero, uno, dos, tres o cuatro campos variables. Longitud cero significaba ausencia de filtro. Dos campos con valor cero expresaban «siguiente objeto». El receptor tenía que reconstruir la forma a partir del tamaño y, en ciertos casos, de los valores. No se trataba de una medición de calidad de vídeo, sino de una regla de lectura de mensajes.

El borrador 22 conserva el identificador externo y sustituye el segundo entero por un tipo. 0x00 no impone filtro; 0x01 establece un comienzo relativo; 0x02, uno absoluto; 0x03, un final de grupo; 0x04, un intervalo absoluto; y 0x05, el siguiente objeto. El tipo decide cuáles de los campos opcionales aparecen. Un tipo no reconocido causa una infracción del protocolo. El caso «siguiente objeto» ya no se representa mediante la pareja especial de ceros. La diferencia es verificable comparando las secciones 9.20.10 y 9.20.9 de los dos borradores.

No hay que confundir cambio de bytes con cambio de autoridad sobre el contenido. Los filtros se envían en solicitudes FETCH y SUBSCRIBE, en PUBLISH y en mensajes que actualizan o notifican el estado. Si el relevo intermedia entre dos participantes, debe preservar la intención de selección dentro de la versión que realmente negoció en cada tramo. Esa obligación de prueba es una inferencia operativa; el borrador no informa de un relevo concreto que haya decodificado mal el campo.

La versión de MOQT no es una etiqueta informal añadida después. El documento describe negociación mediante ALPN sobre QUIC y el mecanismo de WebTransport, con identificadores provisionales para los números de borrador. Por ello tampoco sería correcto insinuar que dos implementaciones conformes de versiones diferentes se enviarán automáticamente formatos incompatibles: primero hay que comprobar qué versión acordaron. Lo que sí cambia es el contenido que debe superar la prueba de aceptación cuando un producto afirma hablar la versión 22.

El anexo de cambios ayuda a no exagerar. Coloca la nueva discriminación de LOCATION_FILTER bajo el plano de sesión y control. La explicación de suscripciones pausadas y la reorganización del tratamiento de FETCH figuran entre las aclaraciones editoriales. Convertir esas mejoras de redacción en supuestas funciones inventadas en octubre diluiría la noticia. La novedad verificable es que la forma del filtro ahora viaja declarada en el mensaje.

Fuentes