الخلاصة

  • تبقى الملفات القديمة المطابقة ضمن القواعد الجديدة، لكن المعالجات الأقدم لا تقبل بالضرورة الصيغة \u{hex}؛ فالتوافق الخلفي ليس وعدًا في الاتجاه المعاكس. RFC 9682.
  • ينبغي أن يقتصر كل اعتماد على ما تثبته أدلته: قبول النموذج، وتجميع المخطط، وتوليد برنامج التحقق، ونشره، وقبول رسالة، قرارات مترابطة لا شهادات متبادلة.

المرجع يحدّد اللغة، ولا يختار البرنامج

تتيح CDDL وصف بنى البيانات المستخدمة مع CBOR وJSON، وتعرض RFC 8610 استعمالها في الوصف والفحص الآلي. أما ABNF فهي وسيلة لصياغة القواعد النحوية؛ بل تفصل RFC 5234، القسم 2.4 بين النحو والترميز الخارجي. لذلك لا ينبغي اختزال وصف اللغة في برنامج بعينه، أو اعتبار اعتماد الوصف دليلًا على سلوك كل برنامج يزعم دعمه.

يستبدل الملحق A المعياري من RFC 9682 صيغة ABNF المجمعة في الملحق B من RFC 8610، لا المواصفة الأصلية كاملة. وتشمل المعالجة Errata 6278 لاتساق السلاسل، و6526 للشرطات المائلة العكسية المفقودة أثناء النشر، و6527 لهروب السلاسل النصية، و6543 لسلاسل البايتات المؤهلة، و6575 لتفسير الرقم بعد النقطة في تمثيل الوسوم والقيم البسيطة. ولا تُنسخ المقترحات جميعها حرفيًا: تبقى معالجة محتوى سلاسل البايتات خطوة دلالية تلي تحليل صيغتها. وتعبّر الإضافة \u{hex} مباشرة عن قيمة Unicode قياسية (Unicode scalar value) ضمن U+0000–U+10FFFF، باستثناء نقاط البدائل U+D800–U+DFFF. تفاصيل التصحيحات والإضافة.

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

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

الاعتماد يبدأ بما قُرئ، لا بما سُمّي

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

وهنا يلزم الاحتراس من عبارة «لم نغيّر المعنى». تنص RFC 8610، القسم 3.1 على استخدام UTF-8، وعلى أن معالجة CDDL لا تتضمن تطبيع Unicode. وعليه، فالتوصية ليست السماح بأي إعادة كتابة تبدو مريحة بصريًا، بل مراجعة التحويل المقصود وحدوده. تساوي القيمة المستهدفة، إن ثبت، لا يجعل نسختين مختلفتين من المصدر وثيقة واحدة للاعتماد.

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

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

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

كل نتيجة تحمل حدود شهادتها

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

لذلك، لا تكفي نتيجة parsing للموافقة على التجميع. السؤال التالي هو: هل فُهمت القيود والقيم كما قُصدت، وهل اكتملت المعالجة الدلالية المطلوبة؟ كما لا تكفي عبارة «اكتمل التجميع» لإجازة برنامج تحقق مولّد، أو validator، ولا لإثبات تكافؤ برنامجَي تحقق أنتجهما إصداران مختلفان. يلزم عند هذا الانتقال تحديد ما وُلّد، ومن أي مخطط، وبأي نسخة من أداة التوليد، وما حدود الفحص التي يُنتظر أن ينفذها.

وهذه الحدود ليست تفصيلًا إداريًا. تترك RFC 8610، القسم 4.2 مدى إنفاذ وصف البيانات لمصممي التطبيق ومنفذيه، مع مراعاة الأمن. ومن ثم لا أوصي بمعاملة اسم CDDL ضمانًا بأن كل تطبيق يفحص القيود نفسها. المطلوب بيان الفحوص المقصودة، ثم دليل مستقل على أن البرنامج الناتج ينفذها؛ لا مجرد إثبات أن أداة التوليد انتهت دون خطأ.

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

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

رسالة وقت التشغيل لا تشهد على تاريخ بنائها

يقدّم RFC 8949، القسم 1.2 تمييزًا ضروريًا: البيانات السليمة البنية تتبع تركيب CBOR، والبيانات الصالحة تستوفي كذلك قيوده الدلالية، أما البيانات المتوقعة فتستوفي متطلبات التطبيق الإضافية. ليست هذه أسماء مختلفة لنجاح واحد. ولذلك لا يثبت فك ترميز رسالة وحده أنها توافق مخطط التطبيق، ولا أن التطبيق نفّذ جميع الفحوص المقصودة قبل قبولها.

ويفصل القسم 3.1 من RFC 8949 بين سلاسل البايتات وسلاسل النص، ويجعل النص مشفّرًا بـUTF-8 من دون هروب المحارف بالطريقة النصية. وعليه، ينبغي ألا يتحول البحث عن الصيغة ذات الأقواس في ملف CDDL إلى اشتراط ظهورها في رسالة CBOR. ما يُكتب لتمثيل القيمة في المصدر ليس ما يلزم أن يُرسل حرفيًا، وتطابق المحتوى لا يمحو اختلاف نوع البيانات.

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

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

الأمن يبدأ عند منع انتقال الثقة بلا دليل

يحذّر RFC 9682، القسم 4 من اختلاف تفسير النماذج عند مزج أدوات محدثة وأخرى غير محدثة، ومن احتمال استغلاله، ويدعو إلى العناية بأصل النماذج وسلامتها وملاءمتها كالشيفرة المصدرية. هذا تحذير من إمكانية، لا توثيق لحادثة أو ثغرة مسماة. وتؤكد RFC 8610، القسم 5 ضرورة ألا يعتمد أمن النظام على صحة وصف CDDL أو تنفيذه من دون دفاعات إضافية.

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