Resumo

  • A RFC 3073 registrou application/font-tdpfr e publicou metadados de identificação, mas encaminhou os detalhes completos do Portable Font Resource à especificação original mantida pela Bitstream.
  • Um nome no registro ajuda o software a escolher um tratador. Não comprova custódia da especificação, código compatível, análise bem-sucedida ou renderização fiel.

Em março de 2001, John Collins, da Bitstream, publicou a RFC 3073 para registrar um subtipo MIME dos arquivos Portable Font Resource. A ficha era precisa. application/font-tdpfr não tinha parâmetros obrigatórios nem opcionais; exigia transferência binary ou base64; identificava a assinatura hexadecimal 50 46 52 30; indicava a extensão PFR e classificava o uso pretendido como comum. Emissor e receptor passavam a compartilhar um símbolo público para aquilo que o corpo dizia conter.

O símbolo não continha o formato inteiro. A RFC descrevia PFR como uma coleção compacta e independente de plataforma de formas de glifos associadas a códigos de caracteres. Os contornos não dependiam da resolução da saída, podiam ser ampliados para tamanhos arbitrários e o recurso ainda admitia glifos em bitmap. Quando chegava às funções e aos detalhes técnicos completos, entretanto, o documento remetia à especificação PFR original. Dizia que a Bitstream a definira, que ela podia ser solicitada à empresa e que havia uma cópia em um endereço da Bitstream. Collins, também da empresa, aparecia como contato e como autor/controlador de mudanças.

Essa separação não estava escondida. Era a arquitetura institucional da inscrição. O nível público de coordenação guardava o nome, o modelo de registro e uma descrição suficiente para identificação; o contrato descritivo completo continuava sob custódia de outra organização. A RFC preservou inclusive a identidade anterior: o tipo havia sido registrado como application/vnd.truedoc. Segundo o texto, a adoção por DAVIC, DVB e DTG motivou um novo registro no ramo então usado para aplicações amplas da Internet. Trocar o rótulo público não copiava todas as regras para a RFC e não instalava um renderizador nas máquinas destinatárias.

Um tipo de mídia é, antes de tudo, uma pista de despacho. A aplicação pode ler Content-Type, procurar um mapeamento, selecionar um tratador candidato e entregar a ele os bytes. Cada verbo produz um recibo diferente. Reconhecer a cadeia prova a correspondência do nome. Selecionar o tratador prova a existência de uma configuração. Aceitar o arquivo prova apenas o resultado daquele analisador. Mostrar uma página prova que alguma saída foi gerada. Nenhuma dessas etapas, isoladamente, demonstra que o receptor implementava a mesma revisão de PFR pressuposta pelo produtor, preservava cada associação de caracteres e métricas ou exibia a forma esperada pelo autor.

O trecho de segurança da RFC 3073 também deve permanecer dentro do próprio escopo. Ele dizia que os campos então definidos eram descritivos e não serviam para induzir uma ação específica do destinatário. Reconhecia, ao mesmo tempo, que uma estrutura extensível poderia receber no futuro campos capazes de provocar ações e, assim, criar novos riscos; tais instruções não eram apoiadas pela especificação citada e contrariariam seus objetivos. Isso delimitava o desenho do formato.

Não era uma auditoria de segurança de memória de todos os analisadores, um mecanismo de autenticidade dos arquivos, uma garantia de que os desenhos fossem confiáveis ou uma autorização para agir sobre a saída.

Também seria excessivo transformar “Interoperability considerations: none” em certificado de interoperabilidade. A RFC não trazia conjunto de conformidade, relatório de implementações independentes, corpus de teste ou comparação mensurada de renderizações. Netscape Communicator, Bitstream WebFont Maker e Hexmac Typograph eram citados como aplicativos que usavam o tipo, mas uma lista de produtos não prova que qualquer par deles trocava todo arquivo válido com fidelidade. A afirmação histórica segura é mais estreita: havia um nome compartilhado e metadados públicos quando se relatava o uso por alguns programas e organismos de padronização.

As regras institucionais posteriores não eliminaram essa fronteira. A RFC 6838 sistematizou o registro de tipos de mídia como um regime público de nomes, com ramos, requisitos de publicação, revisão e responsabilidades de controle de mudanças. A RFC 8081 criou depois o tipo de nível superior font e registrou font/ttf, font/otf, font/sfnt, font/woff e font/woff2. No registro atual da IANA, os nomes antigos application/font-sfnt e application/font-woff aparecem como obsoletos em favor de variantes font/*; application/font-tdpfr continua associado à RFC 3073 sem a mesma anotação. A linha prova o estado do registro, não uma migração, retirada, presença atual em navegadores ou compatibilidade real.

A RFC 2045 ajuda a recuperar o acordo operacional original. MIME precisava de uma gramática comum para nomear e transportar corpos que o receptor poderia ou não entender. O rótulo reduzia a ambiguidade da apresentação, mas não criava capacidade universal de decodificação. Já a RFC 2048 procurava tornar novos nomes documentados e examináveis. Sob essa perspectiva, a RFC 3073 foi uma melhoria concreta de coordenação, sem que a inscrição pública passasse a possuir toda a cadeia de implementação subjacente.

O princípio posterior de Running-Code Primacy oferece uma lente útil para a diferença. A cadeia que importa começa pelo nome registrado e segue pela revisão disponível da especificação, pelo decodificador mantido, pelo mapeamento do tratador, pelo objeto concreto, pela análise bem-sucedida e pelo resultado renderizado. Reality Layers acrescenta a pergunta: a autoridade simbólica de um nome público encontra suporte executável no ponto em que a afirmação precisa produzir efeito? Essas lentes não pertencem ao argumento de Collins e não devem ser atribuídas à Bitstream, à IANA ou à IETF.

A lição não é proibir formatos mantidos por fornecedores de usar registros públicos; muitas vezes essa coordenação é necessária. Tampouco o registro permite dizer que a especificação PFR era secreta ou indisponível: a RFC afirmava que ela podia ser solicitada e informava um endereço na Web. A precisão está em separar a descoberta pública do nome, a disponibilidade da ficha, a custódia do formato completo, o acesso ao código compatível e a observação de uma saída correta. A sobrevivência de uma condição não conserva automaticamente as demais.

A RFC 3073 tornou o nome durável o suficiente para que emissores e receptores apontassem ao mesmo tipo de conteúdo alegado. Isso era infraestrutura real. Seu limite era igualmente real: o registro podia dizer como a cápsula se chamava e onde a documentação supostamente residia. Somente a especificação, a implementação e a saída observada podiam revelar o que um destinatário específico conseguia fazer com aqueles bytes.

Fontes