Resumo

  • RFC 3023 criou a convenção +xml para que tipos de mídia específicos revelassem uma base XML comum e pudessem usar ferramentas genéricas.
  • O sufixo não carregava o significado do vocabulário nem uma permissão operacional; tipo completo, bytes, parsing, validação, confiança, autorização e efeito continuavam distintos.

No início de 2001, XML já funcionava como matéria-prima para muitos formatos. Uma mensagem comercial, um desenho vetorial e um documento de configuração podiam obedecer à mesma gramática de marcação sem aceitar as mesmas operações. Chamá-los todos de application/xml manteria a sintaxe e perderia o contrato. Dar a cada um um nome opaco manteria o contrato e esconderia a estrutura comum de editores, indexadores e parsers.

RFC 3023 acrescentou uma junção pequena ao nome. O subtipo específico permanecia e terminava em +xml. A parte anterior identificava o formato; as quatro letras finais anunciavam a representação subjacente.

Reuso de infraestrutura sem reuso automático de significado

Uma aplicação que conhecia application/foo+xml podia aplicar regras próprias de foo. Uma ferramenta que não conhecia foo, mas conhecia XML, podia examinar o final do subtipo e decidir se um tratamento genérico — parsing, busca, formatação ou transformação — era adequado.

Isso evitava uma lista crescente de vocabulários em cada ferramenta. O RFC também explicou por que um parâmetro seria frágil: parâmetros modificavam subtipos, e os despachantes MIME existentes raramente escolhiam aplicações por eles. Criar um novo tipo superior mudaria arquitetura demais. O sufixo carregava somente o fato compartilhado.

O nome completo, contudo, não perdia autoridade. Para um processador alheio a XML, o sufixo era opaco. O apêndice de RFC 3023 dizia que sua presença não podia receber semântica adicional. application/foo e application/foo+xml eram tipos independentes; a variante XML poderia trazer nova sintaxe e novo significado. Suportar um não comprovava suporte ao outro.

A árvore analisada ainda não era uma ordem válida

O header recebido é uma declaração. O parser testa se os bytes realmente formam XML e, em caso positivo, produz uma estrutura. Ainda falta saber se o namespace é aceito, se o documento segue o profile, se a assinatura é confiável e se o signatário pode pedir a operação.

Um elemento chamado transfer não movimenta nada por ser bem formado. A aplicação atribui significado, a política confere autoridade, o executor tenta a ação e a observação posterior comprova o resultado. Tampouco o sufixo autoriza entidades externas, recursos de rede, stylesheets ou consumo ilimitado. São escolhas de segurança locais.

O valor de +xml estava em permitir o processamento comum sem obrigar o receptor a aceitar o conteúdo específico.

A convenção virou infraestrutura registrada

RFC 6838 incorporou sufixos de sintaxe estruturada ao registro de tipos de mídia: a parte depois do último sinal de mais identifica uma sintaxe registrada. RFC 6839 formalizou +xml e separou dois níveis. O tipo exato fornece a semântica específica; o sufixo permite processamento genérico quando essa semântica não é necessária e o parser não precisa de conhecimento extra.

RFC 7303 substituiu RFC 3023 e preservou o desenho. Novos formatos XML deveriam usar +xml, salvo quando o processamento genérico fosse impróprio. O receptor podia reconhecer o sufixo, chamar um parser para verificar a suposição e então decidir. Exibição, edição, segurança, runtime e fragmentos continuavam sob o tipo específico.

Os registros atuais da IANA mostram o resultado: uma entrada para o sufixo +xml e muitos tipos completos diferentes que o usam. O final comum demonstra uma família sintática, não equivalência de formato ou de suporte.

Fontes

Lu Heng não escreveu nem endossou RFC 3023. Seus ensaios são usados aqui como lentes analíticas declaradas.