الخلاصة

  • تبدأ Final Review الخاصة بـRFC، وهي المرحلة التي كانت تسمى AUTH48، بعد أن يعتمد أحد مسارات النشر Internet-Draft. يراجع المؤلفون النص الكامل والترميز والصيغ، ويجيبون عن الأسئلة ويجيزون النشر؛ إنها رقابة حقيقية على السلامة، لا اقتراعاً جديداً داخل IETF.
  • يتولى RFC Production Center ضبط التغييرات على نسخة الإنتاج بعد دخولها قائمة الانتظار. يمكن أن تمر التصحيحات التحريرية ضمن هذه الحيازة، أما الإضافة والحذف والتغيير التقني أو ما يتجاوز التحرير فتحتاج إلى موافقة المسار الأصلي.
  • جعلت تجربة kramdown-rfc وGitHub في 2025–2026 الحد بين السلطتين ظاهراً. ففي 27 أغسطس 2026، كانت لـRFC-to-be 10025 صفحة Final Review ومستودع علني، بينما لم يكن عنوان معلومات RFC 10025 يعرض سجلاً منشوراً بعد.
  • ينبغي لإيصال المراجعة النهائية أن يحفظ مراجعة المسودة المعتمدة، وقرار المسار، ومجموعة تعديلات RPC، وتصنيف الأسئلة، وموافقات المؤلفين والمسار، وبصمات الملفات النهائية، وإعلان النشر. أما التنفيذ والتشغيل فطبقة إثبات مستقلة.

pull request بدا كأنه صندوق اقتراع

لم تكن لقطة الشاشة ملفقة. ظهر فرع باسم RPC-edits، ومسائل مفتوحة، وطلب مراجعة، وأسماء لم تسجل موافقتها النهائية. بدأ الخطأ حين دُمجت هذه الحالات في وصف واحد هو «غير معتمد». ثم صار الوصف «المؤلفون يعترضون»، أو «التوافق أعيد فتحه»، أو «سيحسم GitHub مصير المعيار».

تقع Final Review بين فعلين مؤسسيين مختلفين. قبلها، يعتمد أحد مسارات RFC مسودة Internet-Draft للنشر. وبعدها، ينشر RPC مجموعة محددة من الملفات ويعلن RFC. وبين الفعلين يختبر المحررون والمؤلفون وجهات الاتصال في المسار ما إذا كانت نسخة الإنتاج أمينة للمحتوى المعتمد، وما إذا كانت الصيغ صالحة لتصبح مرجعاً دائماً.

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

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

الاعتماد يسبق قائمة النشر

تبدأ الإرشادات الحالية لنشر RFC قبل وصول النص إلى التحرير. لكل من مسارات IETF وIAB وIRTF وIndependent وEditorial طريقه إلى الاعتماد. ولا تصل Internet-Draft إلى RFC Production Center إلا بعد صدور قرار النشر في المسار المناسب.

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

يوضح RFC 9920، وهو نموذج RFC Editor الحالي، تقسيم العمل. هيئات اعتماد المسارات مسؤولة عن المحتوى. ووظيفة RFC Editor مسؤولة عن الإنتاج والتوزيع. أما RPC فيحرر، ويحفظ سجلات التعديلات والحوار، ويتعرف إلى ما قد يترك أثراً تقنياً، ويطلب التوضيح، ويثبت الجاهزية، ثم ينشر الملفات.

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

لذلك يبدأ السجل المنضبط بحقلين: المصدر المعتمد، متضمناً رقم المراجعة والبصمة، والمسار الذي اعتمده. ومن دونهما لا يوجد خط أساس يمكن أن يقاس عليه أي diff لاحق.

ما الذي يوافق عليه المؤلفون فعلاً

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

تقسم تعليمات تجربة kramdown-rfc المسؤولية إلى موافقتين. يشير المؤلفون أولاً إلى استقرار markdown بما يكفي للتحويل إلى RFCXML. ثم يوافقون على المحتوى وعلى جميع الصيغ النهائية. والسبب عملي: قد يكون المصدر صحيحاً بينما يتشوه الكود أو الرسم أو المراجع أو التفاف السطور عند التحويل.

موافقة المؤلف شهادة سلامة تربط اسمه بالملفات التي ستنشر. ولا تعني أن تفضيله الفردي صار أعلى من قرار مجموعة العمل أو IESG أو أي هيئة أخرى في المسار.

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

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

الحد الذي لا يتجاوزه merge

بدأ RPC تجربة kramdown-rfc في 1 سبتمبر 2025. ومن أهدافها التحرير بصيغة اعتادها عدد متزايد من المؤلفين، والحصول على فروق أوضح تركز على المحتوى. كانت المرحلة الأولى تقبل خمس طلبات على الأقل في الشهر، مع تطوير الطريقة على ضوء الاستخدام.

بحلول 2026، صارت التعليمات العلنية تسمي AUTH48 بـFinal Review. الاسم الجديد أدق لأن الرقم 48 لم يكن ضماناً زمنياً. ويجعل GitHub الحيازة ملموسة: تحفظ تعديلات RPC في فرع، وتوثق الأسئلة في issues، وتظهر المقترحات في pull requests، ويبقى الحوار في الأرشيف.

يوفر مستودع RFC-to-be 10025، وهي مراجعة لمواصفة HTTP Cookie، مثالاً حياً. يذكر README أن ملف markdown الأول نسخة من Internet-Draft كما اعتمدت للنشر. وتوضع تعديلات RPC في فرع منفصل. يجيز المؤلفون المحتوى والصيغ، ويجيز Area Directors ما يتجاوز التحرير، ويدعى رؤساء مجموعة العمل وdocument shepherd إلى السطح نفسه. ويمكن الرجوع إلى البريد الإلكتروني عند الحاجة.

في 27 أغسطس 2026، كانت صفحة حالة Final Review والمستودع متاحين، بينما كان عنوان معلومات RFC 10025 يعيد 404. وكانت الواجهة تعرض خمس عشرة issue وpull request واحداً. لا تثبت تلك الأعداد وجود خمسة عشر عيباً تقنياً أو اعتراضاً أو قراراً معطلاً؛ إنها تثبت فقط أن بنود عمل مسماة ظهرت على سطح علني.

قد تتغير الحالة بعد هذه اللقطة، ولذلك يحتاج السجل إلى وقت رصد وروابط مرجعية. قيد Final Review حالة آنية. أما نُشرت RFC 10025 فحدث آخر لا يثبته إلا السجل النهائي والإعلان.

RFC 9991 والكلمة التي احتاجت Area Director

يظهر الاختصاص بوضوح عندما يعبر تغيير حقيقي الحد. أثناء Final Review للوثيقة التي أصبحت RFC 9991، اقترح المؤلفون إضافة كلمة مفتاحية من BCP 14. قد تغير كلمات الإلزام المكتوبة بأحرف كبيرة المعنى التقني، ولذلك ليست تعديلاً عادياً في علامات الترقيم.

في المراسلة العلنية المحفوظة، طلب RPC من Area Director المسؤول مراجعة الإضافة والموافقة عليها. وسجل AD موافقته. ثم نشر RPC الوثيقة لاحقاً.

قيمة السجل في أفعاله المنفصلة: المؤلفون اقترحوا، وRPC تعرف إلى تجاوز محتمل وطلب المراجعة، وAD وافق، وRPC نشر. لم يحل merge محل الإذن، ولم تتحول موافقة AD وحدها إلى ادعاء بأن RFC صدرت.

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

لماذا لم يكن 48 موعداً نهائياً

أوحى اسم AUTH48 بوعد مدته 48 ساعة. لكن RFC 8963 فصل، في عينة من RFCs أُنتجت سنة 2018، بين زمن التحرير وزمن AUTH48 والفترة من الاتفاق النهائي إلى النشر. وتجاوز متوسط AUTH48 شهراً في تلك العينة مع تفاوت واسع.

يحفظ RFC 8700 المزحة القديمة بأن 48 قد تعني يوماً أو أسبوعاً. والأهم أنه يحفظ الحد المؤسسي: التغييرات التقنية في هذه المرحلة تحتاج إلى موافقة Area Director المعني أو مدير المسار.

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

أزال اسم Final Review ساعة مضللة. ولا ينبغي أن يحل محلها صندوق اقتراع مضلل بدوره. المرحلة عملية إنهاء مقيدة بالصلاحيات.

إيصال المراجعة النهائية

الحقل الدليل الواجب حفظه سبب أهميته
المصدر المعتمد اسم Internet-Draft ومراجعته وبايتاته وبصمته يثبت خط الأساس الذي قبله المسار
قرار المسار المسار والهيئة والتاريخ والرابط يحدد صاحب سلطة النشر
التسليم إلى RPC وقت دخول القائمة والحالة يفصل القرار عن حيازة الإنتاج
مجموعة التعديلات الفرع أو diff أو البصمة يظهر ما تغير بعد الاعتماد
بنود المراجعة السؤال والفاعل والجواب والرابط ينسب الغموض والحل
تصنيف التغيير تحريري أو صيغي أو تقني أو خارج التحرير يحدد الموافقة اللازمة
موافقة المؤلف الهوية والنطاق والوقت تربط الشخص بالملفات النهائية
موافقة المسار إيصال AD أو مدير المسار يمنع حيازة الإنتاج من أن تصبح سلطة محتوى
حالات التعليق الخارجية IANA أو المراجع أو المسار أو الأدوات تكشف المالك الحقيقي للتوقف
الملفات النهائية بصمات HTML وPDF وTXT وXML تربط الموافقة بما سيصل إلى القارئ
النشر الإعلان والرابط والوقت يثبت الانتقال من RFC-to-be إلى RFC
التبني التنفيذ والاختبار والنشر التشغيلي يفصل سلطة الوثيقة عن الواقع العامل

لا يحول الإيصال الحكم التحريري إلى آلة. إنه يمنع الحكم من فقدان صاحبه. وعندها يمكن القول بدقة: ينتظر الملف موافقة مؤلف؛ أو تحتاج إضافة تقنية إلى AD؛ أو لم يكتمل إجراء IANA؛ أو لم يظهر سجل النشر بعد. هذه الأوصاف أقل إثارة من «فيتو» أو «تصويت ثان»، لكنها أصلح لاتخاذ قرار شراء أو تنفيذ.

المصادر

تثبت ملاحظات RFC-to-be 10025 حالة 27 أغسطس 2026. ولا تعامل أعداد issues بوصفها أعداد عيوب، ولا تتنبأ بتاريخ النشر أو نتيجته.