Resumen

  • RFC 7865 llama application/rs-metadata+xml al documento XML de metadatos SIPREC; RFC 7866 usa application/rs-metadata en el procedimiento y los ejemplos.
  • El erratum 7987 notificó la contradicción el 12 de junio de 2024 y todavía aparece como Held for Document Update. RFC 9806, publicada en junio de 2025, actualiza RFC 7866 y ordena sustituir todas las apariciones antiguas.
  • RFC 9806 también aporta el registro que faltaba. La tabla vigente de IANA muestra application/rs-metadata+xml y cita RFC 7865 y RFC 9806.
  • La cadena resuelve qué nombre debe usarse. No acredita qué emitió un SRC desplegado, qué aceptó un SRS, cómo se procesó una parte multipart ni qué etiqueta conservó un archivo.

El estándar ya no duda; la red todavía puede hacerlo

La RFC 7865 define el documento XML que transporta información sobre participantes y otros elementos de una sesión grabada. Allí el tipo es application/rs-metadata+xml. La RFC 7866, publicada en el mismo mes de 2016, describe el protocolo de grabación, pero en la sección 9 y en sus ejemplos recorta la cadena a application/rs-metadata.

No se trata de dos formatos rivales. RFC 7866 remite a RFC 7865 para la estructura de los datos. La discrepancia está en el identificador de contenido. Un analizador puede ser capaz de leer el XML y aun así no invocarse porque la tabla de despacho no reconoce el Content-Type recibido. Del mismo modo, un generador puede construir SIP y XML válidos mientras anuncia una etiqueta no registrada.

El erratum 7987 registró el problema en junio de 2024. La ficha conserva el texto original, el corregido y la observación de que ninguno de los RFC de 2016 había registrado el tipo. Su estado actual es Held for Document Update. Esa denominación importa: no es un erratum Verified y no debe describirse como tal.

La RFC 9806 es la decisión posterior. Como documento Standards Track de junio de 2025, lleva la relación Updates: 7866, dice que resuelve el erratum y reemplaza cada application/rs-metadata por application/rs-metadata+xml. La lectura normativa actual queda cerrada. La adopción en producción sigue siendo una pregunta aparte.

La actualización no borra lo que leyó una implementación antigua

El texto archivado de RFC 7866 sigue mostrando la cadena corta. RFC 9806 no reescribe en silencio el documento anterior; añade una actualización visible. El modelo permite reconstruir la historia, pero obliga a unir varias piezas.

Un desarrollador que consulte únicamente RFC 7866 todavía puede copiar la etiqueta antigua. Un inventario que diga «soporta RFC 7866» no revela qué variante usa el producto. Un sistema que ingiera errata puede conservar el estado Held sin relacionarlo con el RFC que declara resuelto el asunto. Y consultar IANA prueba el nombre coordinado, no que una versión determinada lo haya incorporado.

Por eso conviene separar capas. RFC 7865 explica la intención del tipo. RFC 7866 muestra dónde se introdujo la incoherencia en el protocolo. El erratum conserva el informe y su tratamiento editorial. RFC 9806 fija la actualización y la inscripción. Ninguno enumera procesos en ejecución ni configuraciones habilitadas.

IANA cierra el nombre, no la migración

RFC 9806 afirma que los documentos originales no registraron el tipo y proporciona la plantilla. Define el tipo application, el subtipo rs-metadata+xml, ningún parámetro obligatorio u opcional y consideraciones de codificación vinculadas a application/xml conforme a la RFC 7303. Las aplicaciones son SRC y SRS; el uso previsto es COMMON y el control de cambios queda en el IETF.

La captura del registro de IANA del 20 de septiembre de 2026 incluye la fila application/rs-metadata+xml con referencias a RFC 7865 y RFC 9806. Es la evidencia adecuada para el espacio de nombres. No indica si un binario contiene la nueva cadena, si la configuración la habilita, si un proxy modifica el encabezado o si una base de grabaciones guarda el valor original.

El sufijo +xml tiene un alcance igualmente preciso. Permite que software genérico reconozca una entidad de la familia XML. No certifica que el documento cumpla el esquema SIPREC, que pertenezca a la Recording Session correcta ni que una secuencia de instantáneas y actualizaciones parciales sea coherente.

La prueba aparece dentro del multipart

RFC 7866 permite que el SRC envíe una instantánea completa o una actualización parcial en INVITE o UPDATE. Cuando el mensaje contiene a la vez una oferta SDP y metadatos, el cuerpo exterior debe ser multipart/mixed. Una parte lleva SDP; la de metadatos declara Content-Disposition: recording-session.

Una recepción 2xx no basta para demostrar que toda esa ruta funcionó. El recibo de interoperabilidad debería capturar el método y unos identificadores acotados, Content-Type exterior y límite multipart, Content-Type y Content-Disposition de la parte, un hash del cuerpo XML, el espacio de nombres, la condición de instantánea o actualización y el resultado del par.

El SRS mantiene estado. Debe aplicar las actualizaciones parciales en secuencia; si pierde su estado interno puede solicitar otra instantánea completa. Si detecta un error sintáctico o semántico puede terminar la Recording Session. Por eso «la llamada funcionó» y «los metadatos corregidos fueron aceptados» son afirmaciones distintas.

Tampoco una grabación almacenada prueba la segunda. RFC 7866 deja almacenamiento y reproducción fuera de alcance. El audio puede existir aunque los metadatos fueran rechazados, llegaran tarde, se normalizaran a otro nombre o se indexaran con una etiqueta heredada. El control debe seguir la cadena hasta la representación guardada y su posterior exportación o reproducción.

Una capa compatible también puede ocultar deuda

Durante una transición puede ser prudente aceptar tanto application/rs-metadata como application/rs-metadata+xml. Así se evita cortar pares antiguos mientras los emisores nuevos adoptan el nombre correcto. Es una decisión operativa, no un mandato de RFC 9806.

La compatibilidad reduce la fuerza de un resultado positivo. Si un SRS acepta siempre las dos formas, el SRC desactualizado nunca se hace visible. Si una pasarela transforma la antigua en la nueva, los contadores posteriores adjudican la corrección al origen equivocado. Si el sistema normaliza antes de registrar, desaparece la señal necesaria para retirar el alias.

Una migración comprobable tiene dirección, límites y salida. Los generadores nuevos emiten solo el nombre corregido. Los analizadores mantienen temporalmente la doble aceptación para cohortes identificadas. Las reescrituras conservan por separado el valor recibido y el enviado. Cada excepción tiene dueño, observación y criterio de cierre basado en tráfico real.

Un recibo de custodia de la corrección

El recibo propuesto es un control editorial de Daniel Kade. No forma parte de RFC 9806 ni es un requisito del IETF, RFC Editor o IANA.

Primero fija la cadena documental: secciones concretas de los RFC originales; ID, fecha, estado y sustitución del erratum; categoría, relación de actualización y regla de RFC 9806; captura fechada y hash de la entrada de IANA.

Después fija la implementación: producto y versión de SRC y SRS, build, módulos de análisis y generación, versión de configuración, etiquetas admitidas y emitidas en cada dirección. Para el alias antiguo conserva si fue rechazado, aceptado, normalizado o reescrito, junto con la regla que hace observable el comportamiento.

En la transacción registra método, identificadores acotados, Accept y Content-Type, límite multipart, Content-Disposition, hash y espacio de nombres del documento, estado completo o parcial, enlace con SDP y veredicto del par. Un rechazo, una petición de instantánea y una terminación son resultados diferenciados.

El tramo final une el archivo: etiqueta guardada, clave de índice, normalización, representación exportada y resultado de reproducción. Añade cohorte, recuentos nuevo/antiguo/desconocido, canario, ventana compatible, pruebas negativas, disparador de reversión, responsable, decisión de retirar el alias y excepciones residuales.

Publicar la norma acredita la regla. Conservar el recibo acredita dónde llegó.

Límite de la evidencia

Los documentos prueban la contradicción, el informe, la actualización y el estado del registro. No contienen un censo de productos o despliegues SIPREC, una matriz de soporte por proveedor, mediciones del uso de cada etiqueta ni incidentes atribuidos a la diferencia. Este artículo no afirma que un producto concreto esté atrasado.

Los fallos descritos son escenarios que se pueden ensayar, no hechos observados. Se derivan de superficies explícitas: token exacto, envoltura multipart, análisis XML, orden de actualizaciones y tratamiento de archivo. La comprobación debe realizarse en cada entorno; la existencia de RFC 9806 no sustituye la evidencia local.

Fuentes