Resumo

  • O issue 563 do W3C Strategy iniciou em 21 de julho de 2026 a renovação da carta do Web Real-Time Communications Working Group; ele continua aberto e em refinamento depois da meta de 25 de agosto.
  • O projeto diz não alterar substancialmente o escopo, mas lista seis trabalhos a descontinuar e ainda descreve SFrame como substituto de WebRTC Identity.
  • A revisão de segurança pediu um sucessor para identidade, par destinatário e isolamento de mídia, ou uma redução explícita desses objetivos.
  • Um copresidente do WebRTC concordou que as tecnologias não são substitutas, atribuiu a retirada à falta de interesse de implementadores e confirmou não haver produto sucessor no grupo.
  • A pull request 869 continua aberta e não incorporada; ela limita SFrame a um conjunto de casos de uso. Uma matriz de disposição deve registrar o que ficou descoberto.

O fim de um documento não transfere suas propriedades

O issue 563 começou como uma renovação discreta. Aberto em 21 de julho, ele afirma que a carta proposta não traz mudança substantiva de escopo e que alguns rascunhos serão retirados enquanto conteúdo maduro passa a especificações mais adiantadas na trilha de Recomendação. O registro, porém, permanece aberto, com os rótulos de refinamento de carta e revisão de segurança concluída, mesmo após a data esperada de 25 de agosto.

Isso delimita a notícia. Nem a carta nem a correção são finais. O valor da troca pública está em detectar uma equivalência errada quando ainda é possível corrigi-la: parar um documento, substituir um mecanismo e dar destino às suas propriedades são atos diferentes.

A seção Discontinued Work reúne seis itens. Quatro rascunhos normativos recebem planos de migração ou substituição; dois documentos não normativos de casos de uso são considerados sem manutenção. Para os normativos, a tabela conserva datas de Exclusion Draft e cartas de origem. A retirada, portanto, integra o estado público e a história de patentes, não é apenas arrumação de repositório.

Identity e SFrame colocam a confiança em camadas diferentes

O texto público atual diz que SFrame, incluído em extensões WebRTC, deve substituir WebRTC Identity e abranger dados, áudio e vídeo. A frase vai além de registrar baixa adoção: ela afirma equivalência funcional.

A Candidate Recommendation de 2018 tratava de identidade validada do par e isolamento de mídia imposto pelo navegador. O conteúdo podia ser restrito ao destinatário identificado e retido quando condições de identidade ou isolamento não fossem atendidas. As fontes não comprovam implementação ampla desse modelo, mas alcance de adoção e definição de propriedade são perguntas distintas.

SFrame protege quadros de mídia codificados em conferências multiparticipantes. A RFC 9605 deixa a gestão de chaves para os aplicativos e declara que o mecanismo não fornece por si só autenticação da mídia por remetente. Isso não torna SFrame inadequado ao seu objetivo. Mostra que proteção de quadros, identidade do par e aplicação de isolamento pelo navegador pertencem a superfícies de controle diferentes.

Por isso, a revisão de 24 de agosto pediu que a carta identificasse um sucessor para identidade, garantia de destino e isolamento de mídia. Se não houvesse sucessor, seria necessário dizer que os objetivos foram reduzidos em vez de atribuí-los implicitamente a SFrame.

O copresidente respondeu sem rodeios: SFrame e WebRTC Identity são tecnologias não relacionadas como substitutas; Identity será descontinuado por falta de interesse de implementadores; e não existe no Working Group um produto sucessor para as propriedades apontadas.

A correção é real, mas ainda não é o texto vigente

A pull request 869, aberta em 25 de agosto, propõe que WebRTC Identity seja descontinuado por falta de interesse e que SFrame em WebRTC Encoded Transform cubra apenas um conjunto limitado de seus casos de uso. A mudança responde diretamente à objeção e separa o motivo da retirada do grau de sobreposição.

No corte da apuração, o patch seguia aberto e não fundido. A carta pública ainda continha a alegação ampla. O estado correto é, portanto, “correção proposta”, não “carta corrigida”, “decisão revertida” ou “SFrame rejeitado”.

Mesmo incorporada, a expressão “conjunto limitado” ainda não diria quais propriedades foram abandonadas, adiadas, transferidas ou deixadas sem responsável. Ela resolve a equivalência mais evidente, mas não conclui a disposição.

Discontinued é estado documental, não prova de equivalência

O Processo do W3C prevê que um trabalho inacabado na trilha de Recomendação, quando não houver intenção de avançá-lo, seja publicado como Discontinued Draft sem alteração substantiva e com uma explicação. Dentro do escopo de uma carta futura, o grupo pode retomá-lo por meio de um novo Working Draft.

Esse estado comunica a interrupção e preserva seu motivo. Não comprova que todas as propriedades migraram. Da mesma forma, chamar algo de substituto não prova implementação, interoperabilidade ou adoção voluntária.

A disciplina de especificação inicial mínima de Heng Lu oferece uma regra útil: o registro comum carrega somente o estado necessário à coordenação; implementação e adoção fornecem a prova posterior. A carta não precisa manter cada propriedade sem usuários, mas não deve criar por rótulo uma equivalência que sistemas em funcionamento ainda não demonstraram.

Uma matriz de disposição por propriedade

Cada trabalho encerrado deveria ter um registro curto com:

  • documento de origem e estado exato de publicação;
  • propriedade de segurança ou interoperabilidade;
  • evidência atual de implementação;
  • destino: migração, substituição, abandono, adiamento ou ausência de responsável;
  • produto de destino e grupo proprietário, quando existentes;
  • avaliação de equivalência e resíduo não coberto;
  • linhagem de exclusões e revisão de patentes;
  • objeções e sua resolução; e
  • gatilho de reavaliação ou retomada.

Para WebRTC Identity, a matriz pode reconhecer a sobreposição limitada de SFrame com usos de mídia protegida e registrar separadamente que identidade, vínculo ao par pretendido e isolamento imposto pelo navegador não têm sucessor nomeado no Working Group. Outra coluna explicaria que a retirada decorre da falta de interesse.

Esse desenho preserva escolhas futuras sem falsear o presente. Se aplicativos demonstrarem nova demanda por identidade ligada ao destino, a comunidade poderá localizar a propriedade residual sem reativar toda a Candidate Recommendation. Se a demanda não surgir, o encerramento continuará legítimo e legível.

O que as fontes não provam

Os documentos públicos não demonstram adoção ampla de WebRTC Identity, remoção de uma função implantada em navegadores, defeito de SFrame ou violação da política de patentes. Não mostram aprovação da carta nem incorporação da pull request. Também não decidem se as propriedades restantes devem ficar nesse grupo, migrar ou ser abandonadas.

Eles comprovam algo mais estreito: uma revisão pública identificou incompatibilidade entre a alegação de substituição e as propriedades das tecnologias; um copresidente concordou; e uma correção textual está aberta. Falta atribuir às propriedades não cobertas um destino que possa ser lido sem depender do rótulo de retirada.

Fontes

  1. W3C Strategy — issue 563 de renovação do WebRTC
  2. W3C — projeto da carta 2026 do WebRTC Working Group
  3. W3C charter-drafts — pull request 869
  4. W3C charter-drafts — commit de correção proposto
  5. W3C — carta vigente do WebRTC Working Group
  6. W3C — WebRTC Identity Candidate Recommendation
  7. RFC 9605 — considerações de segurança do SFrame
  8. Processo do W3C — abandono de trabalho inacabado
  9. Política de Patentes do W3C
  10. Heng Lu — especificação inicial mínima, decisão futura localizada e adoção voluntária