الملخص

  • وصف RFC 5385 قالب Word يمكن أن يجعل العرض والطباعة قريبين سطراً وصفحة من نص ASCII المتوافق، لكن إنشاء النص ظل يمر عبر أنماط محددة وملف طابعة نصية وبرنامج Perl للمعالجة اللاحقة.
  • الفحص البصري يثبت تمثيلاً معيناً ولا يثبت هوية المصدر أو اكتمال المعنى أو قرار النشر. تفصل سياسة سلسلة RFC الحالية بين النسخة النهائية بصيغة RFCXML ونسخ النشر في HTML والنص وPDF.

تدقيق بدأ بالصورة وانتهى بلا أصل

وصل فريق التدقيق إلى نسخة PDF سليمة. العناوين مرتبة، والمراجع ظاهرة، وكل صفحة تحمل الشكل المتوقع. طلب الفريق الملف الذي وافق عليه أصحاب المحتوى، فقُدمت نسخة Word أحدث. طلب إصدار القالب، فلم يكن مسجلاً. طلب البرنامج الذي أنشأ PDF والسجل الذي ربط المدخل بالناتج، فقيل إن الخدمة «الرسمية» نفذت العملية.

لا يثبت هذا السيناريو فساد الوثيقة. يثبت فقط أن المؤسسة تملك ناتجاً مقنعاً ولا تملك قصة قابلة للتحقق عن نشأته.

كان RFC 5385، المنشور عام 2010 كمساهمة مستقلة معلوماتية، يحاول حل مشكلة عملية مختلفة. أراد إتاحة تأليف Internet-Drafts وRFCs في Word مع دعم أفضل لوضع المخطط وإعادة ترقيم العناوين. وكان العرض المباشر والطباعة قادرين، مع فروق طفيفة في علامات الاقتباس والشرطات، على محاكاة نص ASCII المتوافق سطراً بسطر وصفحة بصفحة.

لكن الوثيقة نفسها تشرح أن الشاشة لم تكن الناتج. كان المستخدم يطبع عبر Generic/Text Only لينشئ ملف .prn، ثم يشغّل برنامج Perl يحذف محارف CR، ويحوّل علامات ذكية إلى ASCII، وينظف الفراغ بين تذييل صفحة ورأس التالية، ويضيف form feed، ويفحص المحارف غير القانونية.

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

البنية التي لا تظهر في الخط والحجم

أعاد القالب تعريف أنماط Word المألوفة مثل Normal وHeading1 إلى Heading9 وHeader وFooter وCaption، وأضاف أنماطاً للأشكال والقوائم والمراجع والملاحق. وحذّر RFC 5385 من استخدام أنماط أخرى.

السبب ليس توحيد الذوق. النمط الداخلي يحمل سلوكاً: يمكن ترقية القسم أو تخفيضه في وضع المخطط، ثم يعاد الترقيم. أما سطر كبير وغامق صُنع يدوياً فقد يبدو عنواناً من دون أن يكون جزءاً من شجرة الوثيقة.

تتكرر المشكلة اليوم في المنصات الغنية. قد يبدو النص رابطاً لأنه أزرق، وقد يبدو ترتيب من المسافات جدولاً، وقد تكون كلمات الصورة غير قابلة للبحث أو القراءة المساعدة. البكسلات تخبر الإنسان بما رآه؛ البنية تخبر الأدوات بما يوجد.

لذلك يجب أن يفحص التدقيق مستويين منفصلين. الأول بصري: القراءة، الصفحات، الجداول، الرسوم. الثاني دلالي: مستويات العناوين، وجهات الروابط، ترتيب القراءة، أوصاف الصور، المعرّفات والمراجع. نجاح أحدهما لا يمنح الآخر شهادة مجانية.

أداة التحويل طرف في القرار

قد تبدو إحلال علامة اقتباس مستقيمة محل أخرى منحنية عملية محايدة. تصبح المسألة مختلفة عندما يكون المحرف اسماً أو رمزاً أو جزءاً من معرّف. عندئذ يقرر المحوّل ما يحفظه، وما يقربه، وما يرفضه.

نشر RFC 5385 برنامج المعالجة في ملحق، فجعل قواعده قابلة للفحص. ومع ذلك، لا يثبت النص المنشور أن نسخة بعينها من البرنامج نُفذت في واقعة بعينها. يلزم حفظ البرنامج الفعلي، وإدخاله، وبيئته، ورسائل التحذير، ورمز خروجه، والناتج.

في الأنظمة الحالية، ينبغي أن يكون هذا إيصالاً تلقائياً: بصمة المصدر المعتمد، وهوية القالب والمولّد، والإعدادات، والوقت، وبصمة كل ناتج. وإذا كانت هناك حقول متغيرة عمداً، يجب تحديدها ومقارنة البنية والمعنى بعيداً عنها.

لا تكفي عبارة «استخدمنا الأداة المعتمدة». الأداة لها إصدار وإعداد وحالة تشغيل. الثقة بالاسم لا تحل محل الدليل عن التنفيذ.

قالب متغير داخل اسم ثابت

تذكر اعتبارات الأمن في RFC 5385 أن القالب لم يحتو على وحدات macro في صورته المطورة والموزعة. كما ناقش المؤلف وضع قيم MD5 لملفي .dot و.pl. لكن القالب كان يتغير لمتابعة نصوص boilerplate المطلوبة، لذلك لم يكن ممكناً تثبيت بصمته داخل RFC؛ كانت قيمة التحقق الجارية تنشر إلى جانب الأداة الخارجية.

MD5 هنا حقيقة تاريخية وليس توصية معاصرة. أما الدرس فباقٍ: الوثيقة التفسيرية ثابتة، والأصل التشغيلي متحرك. عبارة «قالب RFC 5385» لا تعيّن وحدها بايتات محددة.

تعيش المؤسسات هذا الخطر في «النموذج القياسي» و«العقد الموحد» و«التقرير الرسمي». يبقى الاسم بينما تتغير الحقول أو الشروط. بعد أشهر لا يمكن تفسير اختلاف وثيقتين تدعيان المصدر نفسه.

يحتاج كل قالب متغير إلى رقم إصدار وبصمة وتاريخ نفاذ ومسؤول وسجل تغيير. ويجب أن يحتفظ الناتج بهذه الهوية. وإذا أدخل القالب نصاً قانونياً أو تنظيمياً، تراجع القيمة الموسعة نفسها؛ اسم القالب لا يفوض كل ما يخرجه.

المراجع كشفت الفرق عند أول تعديل

في الآلية الأقدم، كانت المراجع تعتمد على endnotes. يوضح RFC 5385 أن حذف أول استشهاد قد يحذف المرجع ذاته، رغم بقاء إحالات لاحقة. نقل الإصدار الجديد المراجع الرقمية إلى فقرات في المتن، وأتاح bookmarks لتسميات المؤلف والسنة.

قبل الحذف، قد تبدو الصفحتان متماثلتين. بعد تعديل عادي، تختلفان. هذه هي حدود لقطة الشاشة: لا تختبر سلوك الوثيقة عندما تتحرك.

ينبغي لاختبار القبول أن ينقل عنواناً، ويحذف أول استشهاد، ويضيف ملحقاً، ويبدل شرح شكل، ويعيد إنشاء الفهرس، ويصدر كل الصيغ. موثوقية القالب هي بقاء خصائصه المهمة تحت التغيير، لا جمال عينة ساكنة.

من مظهر واحد إلى مصدر دلالي محدد

تطورت سلسلة RFC بعد ذلك. سجل RFC 6949 الحاجة إلى وصول أفضل وبيانات وصفية ورسوم ومحارف دولية وأجهزة متنوعة. وضع RFC 7990 إطاراً جديداً، ثم استبدله RFC 9720 عام 2025 بمصطلحات أكثر دقة.

RFCXML هو definitive format، والـRFC المنشور به هو definitive version. أما HTML والنص العادي وPDF فهي publication formats، والملفات الناتجة publication versions. تحتفظ النسخة النهائية بكل المعلومات المقصودة، ومنها تُحسم أسئلة النية المنشورة.

لا يصح إسقاط سياسة 2025 على ملف Word من 2010 وكأنه كان يحمل الصفة نفسها. المقارنة في الفصل بين الطبقات. أظهر RFC 5385 عملياً أن شاشة التأليف والتحويل والناتج أشياء مختلفة؛ أما RFC 9720 فحدد لاحقاً أين تستقر السلطة الدلالية وكيف تخدم النسخ المنشورة قراء مختلفين.

كل مؤسسة تحتاج إلى جواب مماثل. هل السجل المعتمد في قاعدة البيانات، أم الملف المنظم، أم PDF الموقّع، أم صفحة الموقع؟ يمكن أن تكون عدة نسخ رسمية، لكن يجب أن توجد قاعدة واحدة لحسم التعارض.

إعادة الإصدار لا تعني محو النسخة السابقة

يسمح RFC 9720 بإعادة إصدار محدودة عند تصحيح XML أو تغير أدوات التوليد، مع حفظ المعنى قدر الإمكان، وتسجيل السبب، وإتاحة النسخ السابقة. كما يعترف بأن إعادة التوليد قد تدخل تغيراً غير مقصود في معيار أو معلومة بروتوكولية مهمة.

الحفظ طويل الأجل لا ينجح بالجمود المطلق ولا بالاستبدال الصامت. قد تصبح الصيغة القديمة صعبة القراءة، وقد يحسن العارض الجديد الوصول. لكن كل تغيير يحتاج إلى نسخ قبل وبعد، وبصمات، وأداة، ومقارنة دلالية، ومراجع، وتاريخ.

ويفصل RFC 9920 الحالي بين صنع السياسة والموافقة عليها وتنفيذها بواسطة RFC Production Center، ويجعل مسؤولية أدوات النشر صريحة. تشغيل الأداة واجب إنتاجي، لا تفويض لتحرير المعنى.

اختبار يعيد بناء الحقيقة لا الصورة فقط

يبدأ الاختبار بمصدر يحتوي أسماء غير ASCII، وعناوين متدرجة، وروابط، ومراجع، وجدولاً، وكوداً، وصورة ذات وصف، وضغطاً على حدود الصفحات. تثبت نسخة المصدر والقالب. ثم تنشأ كل الصيغ في بيئة نظيفة وتحفظ السجلات والبصمات.

تقارن الصفحات بصرياً، ثم تستخرج العناوين والروابط وترتيب القراءة والأوصاف والكلمات المعيارية. يعاد البناء في بيئة ثانية، وتفسر الفروق. يُغير عنصر دلالي واحد ليثبت انتقاله، ثم تتغير قاعدة عرض واحدة للتأكد من ثبات المعنى.

أخيراً تُحاكى إعادة إصدار مع حفظ القديم. يجب أن يستطيع شخص لم يشغّل الأداة تحديد السجل المعتمد وإعادة كل نسخة عامة إلى مدخلاتها. إذا كان الجواب الوحيد «كلها تبدو متشابهة»، فقد نجح العرض وفشل الأرشيف.

المصادر