Resumo

  • A RFC 7865 identifica o documento XML de metadados SIPREC como application/rs-metadata+xml; a RFC 7866 usa application/rs-metadata nos procedimentos e exemplos.
  • A Errata 7987 registrou a contradição em junho de 2024 e continua marcada Held for Document Update. A RFC 9806, publicada em junho de 2025, atualiza a RFC 7866 e substitui cada ocorrência antiga.
  • A RFC 9806 também fez o registro IANA que os documentos de 2016 omitiram. A linha atual usa application/rs-metadata+xml e referencia as RFCs 7865 e 9806.
  • A documentação define a regra vigente. Ela não comprova o valor emitido por um SRC, aceito por um SRS, processado em uma parte multipart ou preservado em um arquivo.

O texto foi corrigido; a frota ainda precisa ser medida

A RFC 7865 descreve as informações de participantes e outros metadados de uma sessão gravada em um documento XML específico de SIPREC. O tipo declarado é application/rs-metadata+xml. A RFC 7866, publicada no mesmo mês de 2016, define o protocolo, mas usa application/rs-metadata na seção 9 e em seus exemplos.

Não são dois formatos XML concorrentes. A própria RFC 7866 aponta para a RFC 7865 como definição do conteúdo. A divergência está no identificador MIME que aciona o analisador. Um receptor pode entender aqueles bytes XML e ainda rejeitá-los porque o Content-Type não está em sua tabela. Um emissor pode produzir SIP e XML válidos, porém anunciar o nome incorreto.

A Errata 7987, relatada em 12 de junho de 2024, preserva o texto antigo, a correção e a observação de que nenhuma das RFCs originais registrou o tipo. Seu estado exibido hoje é Held for Document Update. Não é Verified, e uma cadeia de custódia deve manter essa distinção.

A RFC 9806 fornece a decisão posterior. Publicada como Standards Track em junho de 2025, ela declara Updates: 7866, afirma resolver a errata e manda trocar todas as instâncias de application/rs-metadata por application/rs-metadata+xml. A norma corrente está resolvida; o software instalado pode continuar heterogêneo.

Atualizar não significa reescrever o passado

O arquivo original da RFC 7866 ainda mostra o rótulo curto. A RFC 9806 não altera silenciosamente o texto histórico: acrescenta uma atualização rastreável. Isso permite que um auditor veja a alegação original, o problema comunicado e a resolução.

Também significa que uma leitura parcial produz conclusões parciais. Quem consulta apenas a RFC 7866 pode copiar a cadeia antiga. Um inventário que registra apenas “suporta RFC 7866” não identifica a variante implementada. Um coletor de erratas pode guardar o estado Held e não associar a RFC posterior. Uma verificação exclusiva do registro encontra o nome certo, mas não mostra se qualquer versão de produto o consumiu.

Cada registro responde a uma pergunta. A RFC 7865 mostra a intenção do tipo; a RFC 7866 localiza a inconsistência no procedimento; a Errata 7987 guarda o relato e seu tratamento editorial; a RFC 9806 estabelece a atualização formal. Nenhum deles lista processos ativos ou configurações implantadas.

A IANA fecha a lacuna do nome

A RFC 9806 reconhece a falta do registro e entrega seu modelo. O tipo é application, o subtipo rs-metadata+xml, sem parâmetros obrigatórios ou opcionais, com codificação alinhada a application/xml segundo a RFC 7303. Os usos são o Session Recording Client e o Session Recording Server, a finalidade é COMMON e o controle de mudança fica com o IETF.

No instantâneo de 20 de setembro de 2026, o registro IANA contém application/rs-metadata+xml e cita as RFCs 7865 e 9806. Isso prova a coordenação do namespace. Não informa se uma release incluiu o token, se uma configuração o ativou, se um intermediário o reescreveu ou se um repositório guardou o valor recebido.

O sufixo +xml também tem alcance limitado. Ele permite ao software genérico reconhecer a família XML. Não garante aderência ao esquema SIPREC, associação à Recording Session correta ou coerência entre uma fotografia completa e atualizações parciais.

A implantação é observável dentro do multipart

A RFC 7866 permite que o SRC envie uma fotografia completa ou uma atualização parcial em INVITE ou UPDATE. Quando o mesmo SIP contém uma oferta SDP e os metadados, o corpo externo deve ser multipart/mixed, com uma parte SDP e outra para os metadados. Esta última usa Content-Disposition: recording-session.

Uma evidência útil precisa unir o método SIP e identificadores limitados, o Content-Type externo e o boundary, o Content-Type e o Content-Disposition da parte, um hash do XML, o namespace, o estado completo ou parcial e o resultado do par. Uma caixa marcada “RFC 9806” não substitui esses dados.

O SRS mantém estado. Ele acompanha a sequência de atualizações e, se perder o estado interno, pode pedir uma nova fotografia completa. Diante de erro sintático ou semântico nos metadados, pode encerrar a Recording Session. Uma resposta 2xx em outro ponto do diálogo não prova a aceitação dessa cadeia.

Um arquivo de áudio tampouco fecha a questão. Armazenamento e reprodução estão fora do escopo da RFC 7866. O áudio pode existir enquanto os metadados foram recusados, atrasados, normalizados ou indexados com o nome legado. É necessário seguir o valor armazenado, a regra de índice e o resultado de reprodução ou exportação.

Compatibilidade sem origem cria um ponto cego

Aceitar temporariamente os dois nomes pode proteger pares antigos durante a migração. É uma política operacional possível, não uma exigência da RFC 9806. E faz com que um sucesso seja menos informativo.

Se todos os SRS aceitarem ambos para sempre, um SRC desatualizado desaparece nas métricas. Se um gateway converter o nome antigo, a telemetria posterior atribui a correção à origem errada. Se os logs normalizarem antes de registrar, ninguém conseguirá contar o tráfego legado restante.

Uma transição verificável define direção e saída. Novos geradores emitem apenas a forma corrigida; analisadores preservam aceitação dupla somente para coortes nomeadas; reescritas registram separadamente recebido e encaminhado; cada exceção possui responsável e critério baseado no tráfego observado.

O recibo de custódia da correção

O recibo proposto é um controle editorial de Daniel Kade, não um campo da RFC 9806 nem uma exigência do IETF, RFC Editor ou IANA.

Primeiro, ele fixa a sequência documental: trechos exatos das RFCs originais; ID, data, estado e alteração da errata; categoria, relação de atualização e regra de substituição da RFC 9806; e uma captura datada com hash do modelo IANA.

Depois, liga a implementação: produto, versão e build de SRC e SRS; módulos de análise e geração; geração de configuração; valores aceitos e emitidos por direção. Para o alias legado, registra rejeição, aceitação, normalização ou reescrita e a regra que torna o comportamento visível.

Na transação, conserva método, identificadores limitados, Accept, Content-Type, boundary, Content-Disposition, hash e namespace, estado da fotografia, vínculo SDP e veredito do par. Rejeição, solicitação de nova fotografia e encerramento são resultados distintos.

Por fim, une o arquivo: rótulo armazenado, chave de índice, normalização, representação exportada e teste de reprodução. Acrescenta coorte, contagem de novo/antigo/desconhecido, canário, janela compatível, testes negativos, gatilho de rollback, responsável, decisão de retirar o alias e exceções remanescentes.

A publicação prova que a regra existe. O recibo mostra onde ela foi executada.

Limite da evidência

As fontes estabelecem a contradição, a errata, a atualização e o registro. Não apresentam censo de produtos ou instalações SIPREC, matriz de suporte de fornecedores, participação de cada rótulo nem incidentes atribuídos à diferença. Este artigo não acusa qualquer implementação identificada.

Os caminhos de risco são cenários testáveis, não falhas observadas. Eles decorrem das superfícies explícitas do protocolo: token exato, estrutura multipart, análise XML, sequência de atualizações e arquivo. Cada ambiente deve testá-los localmente em vez de tratar a existência da RFC 9806 como evidência de execução.

Fontes