Resumo

  • A revisão 10 de draft-ietf-mediaman-6838bis ficou disponível em 9 de setembro de 2026 UTC. É uma draft ativa do grupo Media Type Maintenance, ainda sem força de RFC.
  • A versão anterior decidia a precedência pelo sucesso de uma resolução em execução. A nova formulação exige compatibilidade com regras realmente definidas pelo sufixo e, na ausência delas, entrega a decisão ao tipo de mídia.
  • O texto manda retirar uma regra de três casos de treze registros da IANA. As próprias fichas afirmam que não há sintaxe de fragmento definida para os respectivos sufixos, tornando os casos inalcançáveis.
  • Sugiro um manifesto de correção em leque, com a autoridade final e os treze pares antes/depois. A proposta é de Daniel Kade e não faz parte das obrigações atuais da draft.

A precedência dependia do resultado que pretendia governar

Na versão 09, o sufixo prevalecia quando definia o tratamento e conseguia resolver o fragmento. Caso contrário, valia a regra do tipo específico. A issue 93 observou que o processador só descobriria o sucesso depois de escolher e executar uma regra. O resultado era parte do critério para selecionar o próprio procedimento.

A revisão 10 estabelece outra relação. Se o registro do sufixo definir sintaxe e semântica de fragmentos, o tipo que usa esse sufixo precisa ser compatível e não pode proibir a sintaxe exigida. Se não houver definição, o tipo de mídia decide. O diff 09–10 confirma a troca de uma tentativa sequencial por uma obrigação estática.

A seção nova para a IANA transforma o ponto lógico em uma lista de trabalho. Ela cita +json, +ber, +cbor, +der, +fastinfoset, +wbxml, +zip, +tlv, +json-seq, +sqlite3, +jwt, +gzip e +cbor-seq. O modelo de três casos circula desde o RFC 6839. Só que cada uma dessas fichas informa também que o sufixo não tem sintaxe de fragmento definida. A draft diz que os casos não podem ocorrer e pede a remoção apenas desse texto, com preservação do restante.

Publicar a regra e aplicar a regra são dois marcos

O registro de sufixos estruturados da IANA marcava 25 de junho de 2026 como última atualização quando foi consultado. Havia 24 registros, política de Expert Review e dois especialistas designados. A verificação dos treze alvos encontrou as três cláusulas e a declaração de sintaxe inexistente em todos eles. Esse é o estado anterior à mudança, não prova de inação: a revisão 10 continua provisória.

O grupo Media Type Maintenance prepara um possível substituto para o RFC 6838. A IANA mantém as fichas. Os especialistas atuam de acordo com a política e o marco do RFC 8126. A IESG administra especialistas de registros criados pela IETF e entra quando cabível. A junção da pull request 108 documenta a edição da draft, não treze operações no registro.

O estado processual também permanece aberto. O cabeçalho da draft indica Best Current Practice, mas a página do Datatracker mostra atualmente nenhum status RFC pretendido. In WG Last Call é um estado registrado desde a revisão 06, em outubro de 2025. Não há base para anunciar aprovação da IESG, publicação de RFC ou execução pela IANA.

O sinal no nome não uniformiza o conteúdo

Um structured suffix ajuda um processador genérico a reconhecer um formato de base. Não torna equivalentes todos os tipos terminados em +json, +zip ou +jwt. A revisão 10 ressalta que o nome, sozinho, não revela a relação entre um tipo com sufixo e aquele obtido ao remover a terminação. Fragmentos e propriedades de segurança podem continuar específicos.

Retirar as cláusulas impossíveis melhora a orientação comum. Não cria sintaxe para os treze sufixos, não atualiza software, não demonstra interoperabilidade e não comprova um incidente. O RFC 3986 define o papel geral do fragmento na URI, sem atribuir semântica a todo tipo de mídia.

A draft ainda incorporaria o RFC 9694 e substituiria os RFCs 6838 e 9694 se fosse aprovada. A consolidação não muda a necessidade de evidência separada para as futuras edições do registro.

Uma lista fechada transforma intenção em encerramento verificável

O manifesto mínimo teria a identidade, seção e hash da autoridade publicada; os treze alvos; a identidade estável e o hash anterior de cada registro; a classe exata de texto autorizada para remoção; e o hash do conteúdo que deve permanecer. Após o trabalho, receberia ação e horário da IANA, manifestação do especialista ou da IESG apenas quando usada, hashes posteriores e um vínculo de correção ou reversão.

Não é uma nova instância decisória. Não expõe deliberação protegida e não interfere na semântica local dos tipos. Apenas prova que uma ordem comum chegou a todos os destinos sem apagar campos laterais.

É uma aplicação da disciplina proposta por Heng Lu: definir o menor registro comum necessário à coordenação e deixar o comportamento específico sob a autoridade adequada.

Limites

O registro atual no Datatracker e o histórico fixam data e estado. O commit de merge fixa uma transição editorial. Nenhum deles prova o resultado futuro da padronização ou da manutenção do registro.

Fontes