Resumen

  • RFC 3485 hizo posible referenciar material SIP/SDP desde el primer mensaje al exigir que toda implementación tuviera el mismo estado estático, exacto e inmutable.
  • Las listas legibles de los apéndices explicaban el origen del contenido, pero el contrato real era la representación binaria normativa con identidad, longitud y cortes precisos.

Un compresor aprende de lo que ya vio. En el primer mensaje todavía no hay cabeceras anteriores, cuerpo de sesión previo ni estado dinámico compartido. RFC 3485 evitó esperar: colocó antes del diálogo un diccionario común que el emisor podía referenciar de inmediato.

Para que esa referencia funcionara sin negociación, el diccionario tenía que ser único y obligatorio en SigComp para SIP/SDP. No se actualizaría al ritmo de SIP o SDP. Quedaba definido una vez y para siempre. Así desaparecía la pregunta que, de otro modo, bloquearía el arranque: ¿qué versión conserva el receptor?

El acuerdo no era una lista aproximada de palabras. La sección 3 fijaba un estado SigComp concreto: identificador completo, longitud 0x12E4, acceso mínimo de seis octetos y valor binario. El ejemplo de STATE-ACCESS usaba los primeros seis octetos del identificador bajo las reglas de búsqueda de estado, pero ese prefijo seguía apuntando al mismo objeto completo.

Los apéndices A y B eran explicativos. Enumeraban cadenas de SIP y SDP, prioridades, offsets, longitudes y documentos de origen. La sección binaria era normativa. Si dos programas reunían las mismas palabras pero alteraban un byte, un orden o un desplazamiento, ya no compartían el estado que la referencia prometía.

El valor unía dos regiones. El subconjunto de cadenas contenía todo el material como subcadenas, con solapamientos para ahorrar espacio. El subconjunto de tabla guardaba pares de longitud y offset; la longitud ocupaba un byte y el offset dos, con 1024 sumado para referenciar directamente un diccionario cargado en la dirección UDVM 1024.

La reutilización era deliberada. Un prefijo común podía servir a varias cabeceras, mientras distintas entradas de tabla completaban cada forma. Los códigos de respuesta aparecían solos y también con la frase sugerida, porque el código era normativo y la frase no. El significado editorial de una entrada se convertía en direcciones sobre regiones binarias compartidas.

También importaba la forma exacta del mensaje. Las coincidencias distinguían mayúsculas de minúsculas. Muchas cabeceras incluían CRLF anterior, dos puntos y espacio. Un mensaje SIP podía ser válido con otro espaciado y obtener menos compresión. Compartir el concepto no equivale a compartir los bytes.

Las prioridades de uno a cinco eran estimaciones de frecuencia, no telemetría. Los valores bajos representaban material considerado más común y se colocaban donde ciertos algoritmos podían referenciarlo con eficiencia. No describían la distribución de mensajes de una red posterior.

El orden permitía recortar por memoria. La RFC publicaba offsets y longitudes para cargar prioridad uno, uno a dos, uno a tres o uno a cuatro, además del estado completo. Elegir un corte no creaba una nueva versión del diccionario. Seguía siendo un acceso a una región exacta del mismo estado inmutable.

Por eso un registro que diga sólo «diccionario usado» es insuficiente. Debe conservar prefijo de identidad, offset, longitud, zona de cadenas o tabla y corte de prioridad. Aun así, demuestra acceso, no descompresión correcta. Y una salida descomprimida todavía debe superar el análisis y las decisiones de la aplicación.

Las RFC vecinas conservan esos límites. RFC 3320 posee la ejecución UDVM y la autorización de estado persistente. RFC 3321 trata reconocimiento y retención de estado dinámico. RFC 3322 separa modelos de rendimiento de mediciones. RFC 3485 se limita a la memoria estática previa al primer intercambio.

RFC 3486 añadió la señalización SIP de SigComp. RFC 4464 explicó el uso; RFC 4465 probó el acceso; RFC 4896 aclaró el diseño; RFC 5049 exigió soporte para SIP; RFC 5112 creó otro diccionario para presencia. Esa última decisión confirma la regla: un nuevo vocabulario necesitaba otro estado, no una revisión silenciosa del original.

La sección de seguridad remitía a RFC 3320 y no afirmaba riesgo adicional conocido. No convertía la coincidencia del identificador en autenticación. El diccionario no prueba identidad, integridad, autorización, entrega ni sesión lograda.

Tampoco prueba una ganancia cuantitativa. La motivación era mejorar la compresión inicial en enlaces estrechos, pero no se documentó un despliegue concreto. Algoritmo, contenido, formato, corte y enlace determinan el resultado observado.

Con las capas de realidad de Heng Lu, la auditoría empieza por hash, identidad y longitud del estado. Después conserva cada operando STATE-ACCESS y resuelve el intervalo binario. Luego compara la traza de descompresión. Sólo al final agrega validez SIP/SDP, autenticación, transporte y efecto de sesión.

La solución histórica consistió en regalar pasado al primer mensaje. Ese pasado común sólo podía ser fiable si nadie lo editaba. RFC 3485 no publicó un glosario vivo: selló una matriz de bytes para que ambos extremos pudieran recordar exactamente lo mismo antes de hablar.

Fuentes