Resumo
- Em 3 de setembro de 2026, o IESG concluiu que a submissão independente Safe-IOC não conflitava com trabalhos do IETF. O ato não avaliou mérito técnico, não formou consenso do IETF e não publicou um RFC.
- A versão 13 define transformação ordenada e reversível. Mesmo assim, cada consumidor decide se o valor fica em texto inerte ou atravessa para prévia, resolução, acesso e política. Essa passagem precisa de custódia própria.
O anúncio do IETF registra a conclusão da conflict review. Pela RFC 5742, o IESG procura conflito entre uma submissão independente e o trabalho do IETF; sem conflito, a avaliação técnica e a decisão de publicação permanecem no processo independente. A página do documento o identifica como Internet-Draft individual, de Independent Submission e pretendido como Informational. A versão 13 data de 4 de setembro e ainda não tinha número RFC.
A explicação do RFC Editor impede ampliar esse recibo: RFCs independentes não exigem nem carregam consenso comunitário e não são padrões ou melhores práticas. “Sem conflito” não quer dizer “segurança certificada”.
O texto da versão 13 substitui variantes improvisadas por uma sequência canônica. Ele envolve o scheme, altera delimitadores estruturais de userinfo e host e trata tokens já neutralizados como opacos. Repetir a operação mantém o mesmo resultado, em vez de acumular colchetes.
A operação inversa recoloca o poder. Ela recupera o valor acionável e, por isso, só pode escrever em buffer não executável. Não deve operar em prévia de navegador, documento vivo, editor rico ou outro destino que possa resolver, executar ou criar link. O pipeline precisa provar a natureza do destino; não basta apontar para o formato de entrada.
A RFC 3986 mostra por que a ordem e o contexto importam. Um ponto percentualmente codificado no host é não reservado e pode ser normalizado; delimitadores reservados codificados precisam ser preservados. A volta pode manter a semântica sem restaurar os mesmos bytes. Perder o original enfraquece investigação e auditoria.
No redirecionamento aninhado, path, query e fragment não podem sofrer substituição global. O rascunho manda reconhecer spans que sejam URI, email ou literal de endereço e só então aplicar recursão. Pontuação fora dessas estruturas permanece intacta. Assim, gramática, versão e configuração do parser formam uma superfície de controle.
Saída parcial também não é aceitável. Neutralizar só os pontos e deixar o scheme ativo pode preservar linkificação. hxxp e hxxps ocupam a posição de scheme; suas entradas provisórias no registro da IANA, lidas com a RFC 7595, não autorizam resolução. O documento orienta tratar toda forma ofuscada como não resolvível.
Nem a forma canônica prova que o indicador merece ação. A RFC 9424 inclui descoberta, avaliação, compartilhamento, implantação, detecção, reação e fim de vida. Um endereço pode estar velho, ter uso duplo ou mudar de titular. A RFC 7970, STIX 2.1 e TAXII 2.1 carregam contexto e recibos próprios. Transporte concluído não prova instalação, observação ou efeito.
Casos de teste devem usar nomes reservados pela RFC 2606. Running-Code Primacy exige testar o parser e o previewer em execução. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption permite uma forma mínima comum com decisões locais sobre ativação. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile separa o rótulo visual do pedido de rede realmente emitido.
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance

