Resumen

  • RFC 3073 registró application/font-tdpfr y publicó datos para identificarlo, pero remitió a Bitstream para consultar las características y detalles técnicos completos de PFR.
  • Compartir una etiqueta facilita el despacho de contenido; no prueba custodia pública de la especificación, código compatible ni un resultado visual correcto.

En marzo de 2001, John Collins, de Bitstream, publicó RFC 3073 para registrar un subtipo MIME de Portable Font Resource. La ficha no era vaga. Indicaba que no había parámetros obligatorios ni opcionales, exigía transferencia binaria o base64, daba el número mágico hexadecimal 50 46 52 30, asociaba la extensión PFR y declaraba uso previsto común. Emisor y receptor obtenían una palabra pública con la que nombrar el contenido anunciado.

Ese nombre no encerraba el formato entero. RFC 3073 resumía PFR como un conjunto compacto de formas de glifos vinculadas a códigos de caracteres, independiente de plataforma y resolución, escalable y capaz de incluir mapas de bits. Para las funciones y los detalles técnicos completos, enviaba al lector a la especificación PFR original. Decía que Bitstream la definía, que podía solicitarse a la empresa y que había una copia en una dirección web de Bitstream. Collins figuraba como contacto y como autor o responsable de cambios.

La frontera estaba a la vista. El registro público conservaba el identificador y una plantilla con información de intercambio; el contrato descriptivo completo estaba en otra superficie de control. El propio RFC contaba que el tipo se había registrado antes como application/vnd.truedoc y que la nueva inscripción se pidió tras su adopción por DAVIC, DVB y DTG. La mudanza del nombre ampliaba la coordinación, pero no copiaba cada regla de PFR al RFC, no entregaba el control de cambios a IANA y no instalaba un intérprete en ningún equipo.

Un tipo de medio funciona como pista de despacho. El programa lee el encabezado, busca una asociación local y entrega los bytes a algún componente. Reconocer la cadena demuestra coincidencia nominal. Encontrar un componente demuestra que existe una configuración. Que el analizador acepte el cuerpo demuestra únicamente el resultado de ese código. Que aparezca una forma en pantalla demuestra que se produjo una salida. Todavía falta saber si el programa seguía la misma revisión que el productor, si conservó códigos, métricas y contornos, y si la salida tuvo el efecto esperado.

Las consideraciones de seguridad de RFC 3073 también tenían alcance limitado. El documento describía los campos entonces definidos como informativos y no destinados a inducir una conducta particular en la aplicación receptora. Admitía que la estructura extensible podría recibir en el futuro campos capaces de ordenar acciones y crear riesgos, aunque esa capacidad no estaba presente y chocaría con los objetivos del formato. Era una afirmación sobre diseño, no una auditoría de seguridad de cada implementación, una firma del contenido ni permiso para confiar en todo lo representado.

La línea «Interoperability considerations: none» tampoco era una medición de interoperabilidad. No venía acompañada por un conjunto de pruebas, dos implementaciones independientes, comparación de métricas o capturas del mismo glifo en dispositivos distintos. El RFC mencionaba Netscape Communicator, Bitstream WebFont Maker y Hexmac Typograph como aplicaciones del tipo. Esa enumeración demostraba la declaración contenida en la ficha; no certificaba que todos los archivos válidos circularan con idéntico resultado entre todos los productos.

Las normas posteriores hicieron más explícita la gobernanza de las etiquetas. RFC 6838 organizó los árboles de registro, los requisitos de publicación, la revisión y el control de cambios. RFC 8081 creó después el tipo superior font y registró, entre otros, font/ttf, font/otf, font/sfnt, font/woff y font/woff2. El registro actual de IANA señala que application/font-sfnt y application/font-woff quedaron obsoletos en favor de nombres font/*. application/font-tdpfr sigue listado con RFC 3073 sin esa marca. Ese hecho no autoriza a inventar una migración, retirada o vigencia de uso.

La arquitectura de MIME ya suponía receptores con capacidades desiguales. RFC 2045 daba una forma común de etiquetar y transportar cuerpos, no un decodificador universal. RFC 2048 definía un procedimiento para que los nombres nuevos fueran documentados y sometidos a revisión. Registrar PFR reducía la ambigüedad del identificador. No eliminaba la dependencia de una especificación completa, un programa mantenido y pruebas sobre el resultado.

Running-Code Primacy permite ordenar después la investigación: comprobar por separado el asiento registral, la revisión de la especificación que puede obtenerse, el lector efectivamente instalado, su versión, el archivo recibido y la imagen resultante. Reality Layers ayuda a distinguir el valor simbólico de estar en una lista pública de la capacidad ejecutable del sistema concreto. Son lentes posteriores, no ideas atribuidas a Collins, Bitstream, IANA o IETF.

El argumento no exige que toda especificación deba pertenecer a IETF para recibir una etiqueta. Los registros existen precisamente para coordinar formatos procedentes de lugares distintos. Tampoco permite decir que PFR fuera secreto: RFC 3073 decía que la documentación se ofrecía previa solicitud y daba una dirección. El punto es más sobrio. Acceso al nombre, acceso a la ficha, acceso a la norma completa, presencia de código compatible y fidelidad de salida son comprobantes diferentes.

RFC 3073 convirtió el nombre de PFR en infraestructura pública y estable. Ese logro tuvo un límite. El registro podía decir qué afirmaba ser el archivo y dónde se anunciaba su documentación. Solo el documento completo, la implementación y el resultado observado podían establecer qué sabía hacer realmente un destinatario con esos bytes.

Fuentes