요약

  • RFC 3073은application/font-tdpfr를 등록하고 식별 메타데이터를 공개했지만, 완전한 Portable Font Resource 사양에 대해서는 구현자에게 Bitstream을 안내했습니다.
  • 레지스트리 이름은 핸들러로의 디스패치를 조정할 수 있습니다. 그러나 사양의 보유권, 호환 코드, 성공적인 파싱, 충실한 렌더링, 권한 부여나 다운스트림 효과를 증명할 수는 없습니다.

2001년 3월, Bitstream의 John Collins는 Portable Font Resource 파일을 위한 MIME 서브타입을 등록하는 RFC 3073을 발표했습니다. 이 기록은 구체적이었습니다.application/font-tdpfr는 매개변수를 요구하지 않았고 선택적으로 허용하지도 않았으며, binary 또는 base64 전송을 요구했고, 매직 바이트를 16진수50 46 52 30으로 식별했으며, 파일 확장자를 PFR로 명시하고 의도된 사용을 common으로 표시했습니다. 이제 발신자와 수신자는 본문이 담고 있다고 주장하는 내용에 대한 공개 토큰을 공유할 수 있게 되었습니다.

그러나 그 토큰에는 포맷 자체가 담겨 있지 않았습니다. RFC 3073은 PFR을 쓸 만한 거리에서 묘사했습니다. 문자 코드와 연관된 글리프 모양의 컴팩트하고 플랫폼 독립적인 집합, 출력 해상도와 무관한 아웃라인, 임의 크기로의 스케일링, 선택적 비트맵 글리프가 그 내용이었습니다. 그러나 완전한 기능과 기술적 세부 사항에 대해서는 이 문서는 독자를 원본 PFR 사양으로 안내했습니다. 이 문서는 그 사양을 Bitstream이 정의했으며 요청 시 제공 가능하고 Bitstream 주소에 사본이 호스팅되어 있다고 명시했습니다. 역시 Bitstream에 소속된 Collins는 연락처와 저자·변경 관리자 역할을 모두 맡았습니다.

이러한 분할은 숨겨지지 않았습니다. 그것이 바로 등록의 구조였습니다. 이 RFC는 이름과 템플릿을 공개 조정 계층에 두면서 완전한 기술 계약은 다른 기관의 보유권 아래 남겨두었습니다. 심지어 이전 정체성도 기록했습니다. 이 미디어 타입은 이전에application/vnd.truedoc으로 등록된 바 있었습니다. 새 이름은 DAVIC, DVB, DTG의 채택이 보도된 뒤에 나왔고, 이 타입을 당시 광범위한 인터넷 사용과 연관되어 있던 비계층 트리로 옮겼습니다. 그러나 공개 레이블을 바꾸는 것이 포맷의 모든 규칙을 RFC로 복사하거나 수신 기기에 렌더러를 설치하는 것은 아니었습니다.

이 구분이 중요한 이유는 미디어 타입이 디스패치 단서이기 때문입니다. 애플리케이션은Content-Type필드를 검사하고 후보 핸들러를 선택하고 바이트를 넘겨줄 수 있습니다. 각 동작은 서로 다른 증거를 만들어냅니다. 문자열 인식은 토큰이 일치했음을 증명합니다. 핸들러 선택은 구성이 토큰을 코드에 매핑했음을 증명합니다. 바이트 수용은 그 코드의 파서가 반환한 것만 증명합니다. 렌더링은 어떤 출력이 만들어졌음을 증명합니다. 그 어느 단계 하나만으로도 핸들러가 생산자가 의도한 동일한 PFR 리비전을 구현했는지, 모든 글리프 매핑을 보존했는지, 올바른 메트릭을 사용했는지, 수신자에게 저자가 기대한 대로 보여주었는지 증명되지 않습니다.

RFC 3073의 보안 문단 역시 명시된 범위 안에서 읽어야 합니다. 이 문서는 당시 정의된 필드들이 기술적 성격을 띠며 특정 수신자 행동을 유도하는 데 사용되지 않는다고 말했습니다. 확장 가능한 구조가 나중에 행동을 유도하는 필드를 갖게 되면 새로운 위험이 생길 수 있음을 인정하면서도, 그런 지시는 지원되지 않으며 참조된 포맷의 목표에 반한다고 밝혔습니다. 이는 포맷의 설계 경계에 대한 진술이었습니다. 이는 모든 파서에 대한 메모리 안전성 감사도, 모든 파일에 대한 진위 확인 메커니즘도, 디코딩된 모양이 신뢰할 수 있다는 약속도, 애플리케이션이 표시한 내용에 따라 행동하도록 하는 권한 부여도 아니었습니다.

등록의 "Interoperability considerations: none" 필드도 마찬가지로 과도하게 읽기 쉽습니다. 이 필드는 테스트 코퍼스, 독립 구현 보고서, 적합성 스위트 또는 측정된 렌더링 비교를 수반하지 않았습니다. 같은 RFC가 Netscape Communicator, Bitstream WebFont Maker, Hexmac Typograph를 이 타입을 사용하는 애플리케이션으로 언급했지만, 제품 목록은 모든 쌍이 모든 유효한 파일을 충실하게 주고받았다는 증거가 아닙니다. 신중한 역사적 주장은 더 좁습니다. 이 등록은 여러 애플리케이션과 표준화 기구가 이 포맷을 사용한다고 알려진 시점에 공유 이름과 공개 메타데이터를 제공했다는 것입니다.

제도적 맥락은 나중에 바뀌었지만 그 경계를 지우지는 않았습니다. RFC 6838은 미디어 타입 등록을 서로 다른 트리, 공개 규칙, 검토 경로, 변경 관리 기대를 갖춘 공개 명명 체계로 형식화했습니다. RFC 8081은 나중에font최상위 타입을 만들고font/ttf,font/otf,font/sfnt,font/woff,font/woff2를 등록했습니다. 현재 IANA 레지스트리는 더 오래된application/font-sfnt와application/font-woff이름을font/*형식 대비 폐기(deprecated)로 표시하고 있습니다. 그러나 여전히application/font-tdpfr을 RFC 3073과 함께 그러한 주석 없이 나열하고 있습니다. 이 대장 상태는 현재 레지스트리 항목을 확립할 뿐입니다. 이는 마이그레이션, 철회, 현재 배포 상황 또는 상호운용성을 확립하지 않습니다.

RFC 2045는 원래의 운영적 거래를 이해하는 데 도움을 줍니다. MIME은 수신자가 이해할 수도 있고 이해하지 못할 수도 있는 본문에 레이블을 달고 전송하기 위한 공통 문법이 필요했습니다. 레이블은 콘텐츠가 스스로를 어떻게 광고하는지에 대한 모호성을 줄였지만, 보편적인 디코딩 능력을 만들어내지는 못했습니다. RFC 2048의 등록 절차는 새 레이블을 검토 가능하고 문서화된 것으로 만들려고 노력했습니다. 따라서 RFC 3073의 기록은 조정 개선으로 이해할 수 있으며, 등록을 기반 구현 체계의 소유권으로 바꾸지 않습니다.

바로 여기서 Running-Code Primacy가 유용한 후기 렌즈를 제공합니다. 관련 체계는 등록된 이름으로 시작해, 입수 가능하고 버전이 관리되는 사양, 유지되는 디코더, 핸들러 매핑, 특정 입력, 성공적인 파싱, 렌더링된 결과로 이어집니다. Reality Layers는 병렬적인 질문을 던집니다. 공개 이름의 상징적 권위가 그 주장이 실질적으로 중요한 지점에서 실행 가능한 기반을 갖고 있는가? 이 렌즈들은 Collins의 논증이 아니며, Bitstream, IANA 또는 IETF에 귀속되어서는 안 됩니다. 이 렌즈들은 하나의 영수증을 다른 영수증으로 대체하려는 시도를 걷어내는 데 도움을 줍니다.

교훈은 외부에서 유지되는 포맷이 공개 레지스트리를 통해 조정될 수 없다는 것이 아닙니다. 조정되어야 하는 경우가 많습니다. 이 기록이 PFR 사양이 비밀이었다고 보여주는 것도 아닙니다. RFC 3073은 사양이 요청 시 제공 가능하며 웹 주소를 제공한다고 명시적으로 밝혔습니다. 교훈은 정확성에 관한 것입니다. 이름의 공개 탐색 가능성, 등록의 공개 가용성, 완전한 포맷의 보유권, 호환 코드 접근, 성공적인 렌더링은 서로 다른 조건입니다. 하나가 살아남는다고 해서 나머지가 자동으로 보존되는 것은 아닙니다.

RFC 3073은 발신자와 수신자가 동일한 주장된 콘텐츠 타입을 지칭할 수 있을 만큼 이름을 내구성 있게 만들었습니다. 그것은 실제 인프라였습니다. 그 한계 역시 똑같이 실재했습니다. 레지스트리는 캡슐이 스스로를 뭐라고 부르는지, 문서가 어디에 있다고 말해지는지 말할 수 있었습니다. 특정 수신자가 실제로 바이트로 무엇을 할 수 있었는지는 오직 사양, 구현, 관찰된 출력만이 보여줄 수 있습니다.

출처