Resumo

  • O RFC 1874 escolhia text/sgml quando o conteúdo era compreensível sem um sistema SGML e application/sgml quando o processamento especializado era indispensável.
  • charset, SGML-bctf e SGML-boot tratavam, respectivamente, da leitura textual, da transformação entre combinações de bits e octetos, e de uma referência para outra parte MIME com dados de inicialização.
  • O próprio RFC advertia que sistemas SGML poderiam permitir comandos de sistema. A legibilidade do fallback não autorizava o processamento ativo, e a separação posterior de XML confirmou os limites da herança sintática.

A ausência de software também fazia parte do protocolo

O destinatário ideal de um documento estruturado não era o único destinatário previsto. O RFC 1874 perguntou o que aconteceria numa estação que conhecia MIME, mas não SGML. Se uma pessoa ainda pudesse discernir o conteúdo, o tipo apropriado seria text/sgml.

Cada registro SGML da forma textual precisava corresponder a uma linha do corpo MIME. Assim, um visualizador comum preservaria alguma utilidade. Ele não reconstruiria necessariamente a hierarquia, não resolveria entidades nem obedeceria instruções de apresentação. A promessa era obter a ideia geral, não reproduzir o documento completo.

Quando essa perda fosse excessiva, o remetente usaria application/sgml. O contraste não separava material importante de material trivial; separava entidades segundo o comportamento aceitável quando o intérprete faltava.

O RFC 2046 depois descreveu esse papel dos tipos de nível superior. Mesmo ignorando o subtipo, um agente pode decidir que dados textuais desconhecidos são exibíveis, ao passo que áudio ou imagem desconhecidos não devem virar caracteres brutos. A classificação administra o desconhecido.

Ela não declara o que um processador conhecido está autorizado a fazer.

A mesma entidade atravessava três traduções

O charset ajudava a apresentação simples de text/sgml. Para um sistema SGML, SGML-bctf respondia a uma pergunta diferente: como as combinações de bits de largura constante do modelo SGML tinham sido transformadas no fluxo de octetos transportado.

O RFC listava identity, formatos fixos e transformações variáveis. Conhecer o nome do subtipo não significava implementar cada valor. Ver caracteres plausíveis tampouco provava que a declaração SGML recebera os números corretos.

SGML-boot acrescentava uma peça externa. Seu valor era o Content-ID de outra parte MIME application/octet-stream, que continha triplas numéricas para construir o mapeamento de caracteres necessário à declaração. A opção valia apenas para entidades de documento.

Esse desenho separava referência e disponibilidade. A mensagem podia citar um identificador e não conter a parte. Um intermediário podia perder a estrutura multipart. Dois corpos podiam disputar o mesmo ID. Depois da resolução, o destinatário ainda precisava interpretar as triplas e analisar a declaração.

O RFC 1590 tornou públicos os procedimentos de registro de tipos. O registro fixava o vocabulário e apontava para uma especificação. Não inspecionava o pacote recebido nem comprovava a capacidade do software instalado.

O caminho rico aumentava a superfície de autoridade

Na seção de segurança, RFC 1874 lembrou que entidades SGML eram analisadas e processadas. Alguns sistemas poderiam permitir comandos explícitos de nível de sistema. Instruções de processamento para apresentação ou composição também criavam riscos semelhantes aos de PostScript.

Logo, text não equivalia a inerte. A rota de fallback podia apenas mostrar linhas. A rota SGML podia interpretar a mesma entrada com acesso a funções mais poderosas. A primeira era evidência de leitura; a segunda exigia uma decisão de segurança nova.

Um parser podia produzir uma árvore correta e ter cada comando bloqueado. Outro podia falhar na transformação antes da sintaxe. Um visualizador comum podia mostrar informação suficiente sem entender nada da estrutura. Chamar todos os três casos de “documento aberto” eliminaria a causa e o responsável.

MIME mandava ignorar parâmetros desconhecidos para sustentar a extensibilidade. Isso podia manter a entrega viva, mas ignorar SGML-boot talvez impedisse a interpretação correta. Compatibilidade do envelope e fidelidade do documento eram recibos diferentes.

XML recusou um atalho baseado apenas em parentesco

Embora XML fosse subconjunto de SGML, o RFC 2376 criou text/xml e application/xml. Muitos aplicativos XML não processavam todo o conjunto de recursos de SGML. Sistemas SGML não necessariamente reconheciam correções usadas por XML. E os parâmetros de transformação e inicialização de SGML não pertenciam a XML.

A relação entre linguagens não descrevia o inventário real de executáveis. Herança formal não era teste de interoperabilidade.

O RFC 3023 ampliou o modelo com o sufixo +xml: a mídia completa mantinha o significado da aplicação, enquanto o final do nome revelava uma sintaxe comum a ferramentas genéricas.

O RFC 6838 estabeleceu o registro de sufixos de sintaxe estruturada e pediu documentação sobre codificação, interoperabilidade, fragmentos e segurança. A aprovação tornava a alegação revisável; não instalava suporte nos receptores.

O RFC 7303 manteve a decisão local. Um programa poderia detectar +xml, verificar a hipótese por meio de um processador XML e só então continuar segundo o tipo específico. Quando o processamento genérico fosse inadequado, omitir o sufixo era legítimo.

O RFC também separou documentos, subconjuntos DTD externos, entidades analisadas externas e entidades de parâmetro. Compartilhar XML não tornava seus papéis intercambiáveis.

O que o rótulo realmente provava

Um tipo registrado provava que existia uma definição pública. Um cabeçalho recebido provava que o remetente declarou aquele tipo. Uma tela provava que um caminho mostrou algo. Um log do parser provava uma transformação local. Nenhum, isoladamente, provava pacote completo, política correta, ausência de efeito ativo ou resultado útil.

Não é necessário inventar um incidente para extrair a lição histórica. RFC 1874 já documentou o ponto de controle: conteúdo legível pode ser entrada de um intérprete poderoso. Preservar um fallback não reduz o dever de observar e autorizar a etapa seguinte.

Fontes e limites

Os RFCs 1590, 1874 e 2046 definem registro, parâmetros SGML e comportamento MIME. Os RFCs 2376, 3023, 6838 e 7303 mostram a separação XML e os sufixos estruturados. As fontes não provam adoção, conformidade de produto, processamento real, exploração, dano ou resultado comercial.