الخلاصة

  • يقترح مشروع SCHClet وظيفة SCHC صغيرة ومستقلة تعمل ضمن Stratum واحد وInstance واحدة، ويمكنها الاستغناء عن إدارة القواعد وعن رؤوس تصبح مفهومة ضمنا.
  • لا تختفي الدلالة المحذوفة، بل تنتقل إلى SCHClet Configuration المشتركة. لذلك يجب أن يغطي إثبات التشغيل اتفاق الطرفين، ومعالجة المدخلات غير المطابقة، وإعادة بناء الحزمة، ونتيجة الطبقة الأعلى.

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

تعرض المراجعة 01 من مشروع SCHClet، المؤرخة في 29 سبتمبر 2026، تصميما يجعل هذه المسألة صريحة. الوثيقة Internet-Draft نشط ضمن مجموعة عمل SCHC ومعد لمسار المعايير. ليست RFC، ولا تقرير تنفيذ أو نشر أو قياس أداء. وهي تقترح تغليف وظيفة فرعية واحدة من SCHC، أو مجموعة محدودة منها، في مكوّن مستقل مخصص لـ Stratum واحد وSCHC Instance واحدة.

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

في المثال الأدنى، تُفترض قيم Version وTraffic Class وFlow Label في IPv6 على الترتيب 6 و0 و0. تحل هوية RuleID من ثمانية بتات محل أربعة بايتات. ويستخدم المثال 0x60 و0xFF، مع إقرار بأن هذا إنفاق متعمد للبتات مقابل بساطة الشيفرة. المقصود ليس الوصول إلى أصغر تمثيل ممكن، بل بناء وظيفة محدودة يسهل توقعها.

القيم المحذوفة ما زالت مطلوبة عند إعادة البناء؛ مكانها هو التهيئة المشتركة. تميز مسودة معمارية SCHC بين Stratum وInstance وDiscriminator. ولأن SCHClet يخدم سياقا واحدا معروفا، يمكن حذف الرأس الذي يحدد ذلك السياق بالكامل. يكمل المستقبل المعنى من معرفة سابقة. فإذا اختلفت المعرفة بين الطرفين، قد لا يبقى في الحزمة المختصرة ما يشرح سبب الاختلاف.

لهذا يلزم المشروع كل مواصفة SCHClet بأن تحدد SCHClet Configuration التي تدعمها. كما يلزم تنفيذ SCHC كاملا بالتشغيل البيني عندما يملك التهيئة المقابلة. الشرط الأخير هو حد الوعد: لا تمنح صفة «كامل» توافقا عاما مع كل إعداد. يجب أن تتطابق سعة RuleID ومجموعة القواعد والقيم المستهدفة ومعاملات المطابقة والإجراءات ونمط التجزئة والمؤقتات وسياسة المدخلات غير المعروفة.

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

أسس RFC 8724 ضغط SCHC أصلا على سياق وقواعد مشتركين. ويبين RFC 9011 كيف يثبت ملف خاص بـ LoRaWAN اختيارات محددة، بينما يوضح RFC 9441 أن الوظائف الاختيارية قد تتطور لاحقا. لا يلغي SCHClet اعتماد المعنى على السياق؛ بل يجعل الوظيفة الضيقة قابلة لإعادة الاستخدام. وكلما صغر سطح التنفيذ زادت أهمية هوية التهيئة التي تمنحه المعنى.

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

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

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

المصادر