الخلاصة

  • سجلت RFC 3073 النوع application/font-tdpfr ونشرت بيانات التعريف اللازمة لتمييزه، لكنها أحالت التفاصيل الكاملة لـPortable Font Resource إلى المواصفة الأصلية التي كانت Bitstream تديرها.
  • يساعد الاسم المسجل البرنامج على اختيار معالج محتمل، لكنه لا يثبت حيازة المواصفة الصحيحة أو وجود شيفرة متوافقة أو نجاح التحليل أو أمانة العرض.

في مارس 2001، نشر John Collins من شركة Bitstream الوثيقة RFC 3073 لتسجيل نوع MIME فرعي لملفات Portable Font Resource. كانت بطاقة التسجيل محددة: الاسم application/font-tdpfr، ولا معلمات إلزامية أو اختيارية، ويتطلب النقل binary أو base64، والتوقيع السحري هو 50 46 52 30 بالنظام الست عشري، وامتداد الملف PFR، والاستخدام المقصود common. أصبح بوسع المرسل والمستقبل أن يستعملا رمزاً عاماً مشتركاً لما يزعم جسم الرسالة أنه يحتويه.

لكن الرمز لم يكن الصيغة نفسها. قدمت RFC وصفاً يكفي للتعرّف إلى PFR: مجموعة مدمجة ومستقلة عن المنصة من أشكال الحروف المرتبطة برموز المحارف، مع حدود خطية لا تعتمد على دقة الإخراج ويمكن تكبيرها إلى أي حجم، وإمكان تضمين صور نقطية للحروف. أما الخصائص والتفاصيل التقنية الكاملة فأحالتها الوثيقة إلى مواصفة PFR الأصلية. وقالت إن Bitstream عرّفت تلك المواصفة، وإنها متاحة عند الطلب من الشركة، وقدمت عنواناً على موقعها. وكان Collins، من Bitstream أيضاً، جهة الاتصال والمؤلف/المتحكم في التغيير.

لم يكن هذا الفصل ملاحظة هامشية، بل كان توزيع الأدوار الذي كشفه التسجيل. حملت طبقة التنسيق العامة الاسم والقالب والملخص اللازم للتعريف، بينما ظل العقد الوصفي الكامل في عهدة مؤسسة أخرى. وسجلت الوثيقة هوية سابقة أيضاً: كان النوع مسجلاً من قبل باسم application/vnd.truedoc. وتقول RFC إن إعادة التسجيل جاءت بعد اعتماد 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/*، لكنه ما زال يسجل application/font-tdpfr مع RFC 3073 من دون العلامة نفسها. يثبت ذلك حالة الدفتر الراهنة، لا أن PFR انتقل أو اختفى أو ما زال منتشراً أو يعمل بالتوافق بين التطبيقات.

توضح RFC 2045 المقايضة التشغيلية الأصلية. احتاج MIME إلى نحو مشترك لتسمية الأجسام ونقلها، سواء استطاع المستقبل فهمها أم لم يستطع. قلل الاسم غموض ما يعلنه المحتوى عن نفسه، لكنه لم ينشئ قدرة عالمية على فك الترميز. أما إجراءات RFC 2048 فاستهدفت جعل الأسماء الجديدة قابلة للمراجعة والتوثيق. ومن ثم كان تسجيل RFC 3073 تحسيناً حقيقياً للتنسيق، من غير أن تتحول الملكية العامة للاسم إلى حيازة عامة لسلسلة التنفيذ الكاملة.

يوفر مبدأ Running-Code Primacy اللاحق زاوية مفيدة لهذا الفصل. تبدأ السلسلة باسم مسجل، ثم مواصفة متاحة ذات إصدار معلوم، ثم مفكك مصان، وربط بالمعالج، ومدخل محدد، وتحليل ناجح، ونتيجة عرض مشهودة. ويضيف إطار Reality Layers سؤالاً موازياً: هل للهيبة الرمزية للاسم العام أساس تنفيذي في الموضع الذي يجب أن يتحقق فيه الادعاء؟ هذان إطاران تحليليان لاحقان، ولا يصح نسبتهما إلى Collins أو Bitstream أو IANA أو IETF.

لا تعني العبرة أن الصيغ التي يديرها مورد لا يمكن تنسيقها عبر سجل عام؛ كثيراً ما يكون ذلك ضرورياً. ولا يثبت السجل أن مواصفة PFR كانت سرية أو غير متاحة، فقد قالت RFC صراحة إنها متاحة عند الطلب وقدمت عنواناً لها على الويب. العبرة في الدقة: إمكان العثور على الاسم علناً، وتوفر بطاقة التسجيل، وحيازة الصيغة الكاملة، والوصول إلى شيفرة متوافقة، ورؤية خرج صحيح، شروط منفصلة. بقاء واحد منها لا يحفظ البقية تلقائياً.

منحت RFC 3073 الاسم قدراً من الثبات يكفي كي يشير المرسلون والمستقبلون إلى نوع المحتوى المزعوم نفسه، وهذه بنية تحتية حقيقية. وكان حدها حقيقياً كذلك: يستطيع السجل أن يقول ماذا تسمى الكبسولة وأين قيل إن الوثيقة توجد. أما ما يستطيع مستقبل بعينه فعله بالبايتات فلا يثبته إلا جمع المواصفة والتنفيذ والخرج المرصود.

المصادر