Resumen

  • La RFC 2361 permitió citar valores de los registros WAVE y AVI mediante audio/vnd.wave;codec=... y video/vnd.avi;codec=...; la IANA republicaba identificadores cuya asignación procedía de un registro externo.
  • Encontrar el valor demostraba que existía un nombre, no que el cuerpo coincidiera, el equipo tuviera el decodificador, el contacto siguiera vigente o la ejecución fuera segura.

Un archivo llega con la etiqueta audio/vnd.wave;codec=55. El catálogo devuelve “MPEG Layer 3”. El sistema muestra un icono familiar y habilita el botón de reproducción. Parece que ya se conoce todo lo necesario. Pero el 55 no es una orden para ejecutar, ni un inventario del equipo, ni una inspección del archivo. Es el resultado de una regla de traducción entre dos registros.

Ese era precisamente el problema de 1998. Gran parte del audio y el vídeo existente se había creado para entornos que no nacieron como protocolos de Internet. WAVE y AVI ya acumulaban identificadores, empresas, descripciones y variantes. Las aplicaciones conectadas querían localizar, anunciar o transmitir ese material, pero necesitaban una forma estable de expresar el códec declarado.

La RFC 2361 no reescribió los formatos. Publicada en junio como documento informativo, creó una referencia desde el árbol de proveedores de MIME. audio/vnd.wave nombraba el registro de audio y un parámetro obligatorio codec elegía un número WAVE. video/vnd.avi hacía lo mismo con un identificador AVI. El subtipo señalaba el espacio ajeno; el parámetro seleccionaba una entrada.

La división de autoridad era parte del diseño. Microsoft había mantenido los registros para evitar colisiones y publicar las asignaciones. MIME aportaba el sobre que podía viajar por protocolos de Internet. La RFC documentaba la correspondencia. La página actual de la IANA no lo oculta: “IANA does not assign. Republication of values.” Una superficie administrada por la IANA no transforma automáticamente cada valor en una asignación, recomendación o auditoría de la IANA.

En WAVE, el detalle peligroso estaba en la base numérica. Los números de registro eran hexadecimales y se escribían en el parámetro sin 0x. Por eso 0x0055 aparecía como codec=55. No se había convertido en cincuenta y cinco decimal. Un programa que interpretara la cadena como decimal y volviera a formatearla podía resolver otra entrada mientras conservaba la apariencia de una operación matemática limpia.

AVI preservaba otro tipo de literalidad. Un FourCC era una secuencia de cuatro caracteres ASCII, 32 bits y distinción entre mayúsculas y minúsculas. Corregir la capitalización, aplicar una normalización Unicode o recortar caracteres no era embellecer texto: era alterar la identidad. Un registro puede contener dos grafías parecidas porque los octetos, no la intención visual, fijan la clave.

El documento añadió un mapeo hacia GUID para software que trabajaba con ese modelo. Un número WAVE ocupaba el primer campo de una plantilla fija. Un FourCC ocupaba los mismos 32 bits. En el ejemplo de la RFC, H260 se veía como 30363248 en hexadecimal debido al orden de bytes del DWORD. Con la misma regla, dos programas podían comprobar que el FourCC y el GUID representaban la misma entrada.

La equivalencia era sintáctica. El GUID no incorporaba una especificación del flujo ni una declaración del proveedor. Tampoco demostraba que una biblioteca instalada aceptara el perfil, la profundidad de bits o el encapsulado recibido. La RFC 4122 dio después un marco normalizado a los UUID, pero un identificador mejor formateado no hereda pruebas que su valor de origen nunca tuvo.

Las fichas históricas imponían otra cautela. La RFC decía que los contactos, domicilios y teléfonos no solían actualizarse salvo que el registrante comunicara un cambio. Sus anexos eran la lista autorizada de valores registrados hasta enero de 1998. Esa fecha no certificaba que las empresas siguieran existiendo, que los derechos fueran fáciles de obtener o que hubiera una implementación mantenida.

La persistencia del nombre era útil precisamente porque podía sobrevivir a todo eso. Un archivo archivado seguía teniendo una clave interpretable después de una adquisición o la retirada de un producto. Sin embargo, la misma persistencia hacía peligrosa una inferencia habitual: una fila viva no implicaba un proveedor vivo. Identidad, custodia, soporte, licencia y respuesta de seguridad requerían comprobaciones distintas.

También faltaba la prueba del cuerpo. El parámetro MIME venía del remitente. Antes de seleccionar código nativo, el receptor todavía debía analizar el contenedor y descubrir qué identificadores aparecían en las pistas reales. Una cabecera podía ser equivocada, incompleta o maliciosa; el archivo, truncado o construido para explotar el analizador. El resultado positivo del catálogo solo decía que la cadena tenía un referente.

Años más tarde, la RFC 6381 definió codecs para otros tipos contenedores y expresó una regla que ilumina esta frontera: si el parámetro contradice los elementos multimedia, el cuerpo es definitivo. Además, algunas pistas declaradas pueden ser opcionales para un resultado parcial. No es la sintaxis de la RFC 2361 ni una actualización de ella. Es una confirmación posterior de que la etiqueta ayuda a decidir, pero no sustituye el examen.

El equipo receptor seguía teniendo que demostrar capacidad. Debía identificar la biblioteca concreta, versión, procedencia, perfiles admitidos, arquitectura, límites de memoria y aislamiento. Tener un paquete instalado no probaba que fuera el seleccionado. Seleccionarlo no probaba que inicializara. Decodificar muestras no probaba que se presentaran con tiempo correcto ni que llegaran al usuario previsto.

Los protocolos de transporte tampoco cerraban esos huecos. RTSP podía controlar una sesión y HTTP entregar el objeto. La referencia WAVE o AVI permitía hablar del material. No era un formato de carga RTP, una confirmación de sesión, una prueba de transferencia completa o un recibo de reproducción.

La sección de seguridad de la RFC fue breve porque su límite era tajante. Registrar formatos no trataba los riesgos de esos formatos; cada uno debía investigarse. Una coincidencia en el registro no podía justificar descarga automática de complementos, ejecución privilegiada ni ausencia de límites de recursos.

Una cadena de evidencias responsable conserva la cabecera exacta, la versión del catálogo, la regla numérica o FourCC, la inspección interna, el conflicto si lo hay, el decodificador real, su procedencia, la política de aislamiento, el intento, las salidas y el resultado observado. Solo entonces un identificador se convierte en parte de una historia operativa, sin ser nunca la historia completa.

La aportación de la RFC 2361 fue permitir que Internet se extendiera mediante referencias, no mediante apropiación. Un protocolo podía nombrar un formato gobernado fuera de él. Ese nombre no absorbía la autoridad del registro, el código del proveedor ni el resultado del usuario.