الخلاصة

  • أُعلن draft-sparysh-pala-audit-00 في 3 سبتمبر 2026. يصنفه Datatracker مسودة Internet-Draft فردية نشطة بلا تأييد أو مكانة رسمية لدى IETF، وبلا مسار RFC أو Area Director مسؤول.
  • تعرض المسودة PALA-1 بوصفه wire format قائماً لسجلات التدقيق ومجمداً عند الإصدار 1.0. اتخذ مشروع Palimpsests هذا القرار محلياً في 9 أغسطس، قبل الإيداع لدى IETF.
  • تسجل المسودة خمسة تطبيقات، لكنها تفصل مرجع المؤلفين عن أربعة تطبيقات كُتبت من النص واختُبرت بمتجهات وفرها المشروع.
  • كشفت تجربة لاحقة على وسم v1.0 نقاط غموض وفجوة في مطابقة spans. تقول المسودة إن المواصفة تغيرت بعد التجميد، من دون أن تقول إن wire أو المتجهات تغيرت.
  • ينبغي لسجل موجز أن يفصل الجسم المجمد، وسلطة المشروع، وحالة IETF، والملاحظة، وفئة التغيير، وصاحب القرار، والأثر على readers وwriters الحاليين.

للمشروع ساعة ولـIETF ساعة أخرى

نشر إعلان IETF الوثيقة في 3 سبتمبر. وتضع صفحة Datatracker الحد المؤسسي بوضوح: يستطيع أي شخص تقديم I-D، وهذه المسودة لا تعني تأييد IETF ولا تملك مكانة رسمية في عملية المعايير. عند نقطة القطع لم يكن هناك RFC stream ولا Responsible AD، وكانت حالة IESG مجرد «I-D Exists».

يذكر رأس النص أن الحالة المقصودة Informational، فيما لم تسجل خانة Datatracker الملخصة intended RFC status. لا تمنح أي منهما موافقة. يوضح RFC Editor أن Internet-Draft وثيقة عمل وليست RFC، وأن النشر لا يضمن الاعتماد لاحقاً. وحتى لو تبنتها Working Group مستقبلاً، فذلك مرحلة تسبق مزيداً من النقاش والمراجعة.

أما قرار المشروع فسبق ذلك. حوّل commit 50b47edb1ed8 في 9 أغسطس حالة المواصفة من Draft إلى «Frozen — v1.0». حُصر الوعد في wire: أي تغيير فيه يستدعي format_version جديداً، بينما تستطيع profiles التوسع بإضافات ضمن مساحاتها. وتقول مسودة سبتمبر إنها تقدم صيغة موجودة كما هي ولا تعيد تصميمها.

ليس هذا الترتيب مشكلة بذاته. يستطيع مشروع تثبيت واجهة لمستخدميه قبل عرضها على مجتمع معايير. لكن التجميد المحلي لا يثبت consensus لدى IETF، وعدم التبني المؤسسي لا يمحو وعد المشروع بالتوافق. لكل واحد منهما صاحب وسجل مختلفان.

قيمة التطبيقات في مصدرها لا في عددها وحده

تذكر فقرة Implementation Status خمسة تطبيقات: reference implementation للمؤلفين؛ تطبيق co-maintainer تحت contamination boundary معلنة؛ وثلاثة تطبيقات لأشخاص كانوا خارج المشروع وقت تجاربهم، ثم أصبح أحدهم maintainer لاحقاً.

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

هنا يظهر المعنى المفيد لأولوية running code. الكود لا يصوت، لكنه يجعل الغموض قابلاً للقياس. اختلاف hash، أو تصنيف GENESIS بطريقتين، أو تعذر إعادة حساب Merkle root يحول مشكلة لغوية إلى اختبار. ويحتفظ سجل التحقق بالعيوب وطريقة إغلاقها بدلاً من عرض النجاحات فقط.

يعطي RFC 7942 Implementation Status هذه الوظيفة المحدودة. يمكن عرض النضج والتغطية وتوافق النسخ والترخيص والخبرة. وتقرر Working Group وزنها. لا يعني إدراج تطبيق تأييد IETF، كما أن المعلومات مؤقتة ولذلك تحذف عادة قبل نشر RFC.

ما كشفته التجربة التي جاءت بعد التجميد

التجربة الخامسة أهم من رقم التطبيقات. وفق المسودة، عمل منفذ كان خارج المشروع على pala1-v1.0، ونجح في الاختبارات المنشورة، وأضاف حالات adversarial، وسجل ثمانية مواضع غموض وفجوة في span pairing.

كانت المواصفة تقول إن crash يجب أن يترك span غير مغلق ظاهراً، لكنها لم تعرف فحصاً يجعل ذلك نتيجة موحدة. لم تعتبر المعالجة كل trail ناقص مزوراً، بل سجلت span غير المطابق بوصفه advisory finding. وتسمي المسودة هذه التجربة بأنها التي غيرت المواصفة بعد التجميد، وتقول إن الاكتشاف والسبب والقرار منشورة.

لا يثبت ذلك تغير bytes. بل يثبت أن كلمة «مجمد» تحتاج إلى جسم محدد. فالتصحيح التحريري، والتفسير، والتشخيص الإضافي، وقاعدة semantics، وتغيير profile، وتغيير offset ليست شيئاً واحداً. قد تبقى المتجهات كما هي ويصبح التفسير أدق، أو تبقى النية كما هي ويكسر تغيير field كل parser قديم.

من دون disposition علنية تظهر قراءتان خاطئتان: كل تعديل لاحق يلغي التجميد، أو ثبات المتجهات يعني ثبات كل معنى. ما يحتاجه المنفذ هو: ماذا تغير، من صنفه، وماذا يفعل كوده الحالي؟

تجميد الحد المشترك فقط

تعرف مواصفة المشروع header ثابتاً من 156 byte وTLV وأنواع records وhash chain. إذا صادف verifier نسخة أو نوعاً أو TLV مجهولاً، فعليه مواصلة فحص السلسلة والإبلاغ بأنه غير قابل للتفسير، لا رفض السلسلة كلها.

توجد parsing spine تبقى offsets فيها ثابتة: magic وversion والأطوال والنوع والتسلسل وboot ID وprevious hash وbody digest. تسمح هذه البنية لقارئ قديم بمعرفة حدود record التالي والتحقق من السلسلة. وهي لا تجمد كل semantics إلى الأبد.

أما profiles فتحدد EVENT bodies والكميات المجمعة ومصدر Merkle leaves ومفردات الأدوار. تحدد وثائق deployment أي profile تستخدمه السلسلة. هذه minimum initial specification حقيقية: يظل المشترك رقيقاً بقدر ما يحتاجه interoperability، وتبقى خيارات المجال محلية.

يفصل PALA-1 أيضاً بين الاتساق الداخلي، والاكتمال أمام anchor، والوجود أمام witness. chain متماسكة لا تثبت صدق recorder. الاعتراف بالحد ليس ضعفاً؛ إنه يمنع صيغة تقنية من ادعاء سلطة لا تستطيع آليتها إنتاجها.

إيصال تجميد وتغيير صغير

يحتفظ جانب التجميد بالـcommit والوسم وhashes المتجهات، وصاحب القرار وتاريخه وexit test والمسائل المفتوحة. ويحدد scope: wire bytes أو parsing spine أو normative semantics أو profile أو إرشاد تطبيق أو test artifact.

تحصل كل issue لاحقة على ID ثابت وrevision دقيق وقسم وفئة: editorial أو interpretation أو semantic rule أو profile أو additive extension أو vector repair أو wire incompatible. تسجل disposition دور المشروع أو IETF الذي قرر، وسببه، والنتيجة: no change أو clarification أو advisory أو profile update أو extension أو compatibility note أو new version أو deferred.

ويذكر الأثر: هل يستطيع v1 reader إيجاد الحدود والتحقق من chain؟ هل يبقى v1 writer مطابقاً؟ هل يلزم profile جديد؟ تضاف التصحيحات إلى التاريخ ولا تمحو القرار السابق.

وفي خط منفصل تبقى حالات IETF: individual I-D، ونقاش في venue مسمى، وWG adoption، وconsensus، وIESG approval، وRFC publication. يتحدث maintainer باسم release المشروع لا باسم IETF. وتراجع Working Group النص من دون امتلاك قاعدة مستخدميه. ويستطيع المشغل تبني v1 طوعاً من دون اختراع معيار مؤسسي.

يضع RFC 2026 التنفيذ والاختبار إلى جانب الجودة التقنية والوضوح والانفتاح والإنصاف والمراجعة المتكررة. الكود جزء من الانضباط، لا طريق مختصر إلى السلطة.

ويضيف إطار Heng Lu قيداً مهماً: يجب تجميد أصغر طبقة مشتركة، واختبار الكلمات بالكود، وإبقاء القرار المستقبلي محلياً حين لا يكسر interoperability، وعدم تحويل voluntary adoption إلى mandate. قد تقر المراجعة المقبلة PALA-1 كما هو، أو تطلب توضيحاً، أو تعدل profile، أو تستدعي v2. لا يمكن الجزم الآن. لكن يمكن الجزم بأن frozen لا يكفي وحده لتعريف الجسم والتوافق والمؤلف والسلطة المؤسسية.

المصادر

  1. إعلان Internet-Draft
  2. Datatracker: سجل PALA-1
  3. Datatracker: التاريخ
  4. أرشيف IETF: النسخة 00
  5. مواصفة PALA-1 في المشروع
  6. commit التجميد 50b47edb1ed8
  7. سجل independent verification
  8. متجهات الاختبار
  9. أرشيف independent runs
  10. RFC 7942: Improving Awareness of Running Code
  11. RFC 2026: The Internet Standards Process
  12. RFC Editor: How RFCs Are Created
  13. Heng Lu: Running-Code Primacy
  14. Heng Lu: Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption