الخلاصة

  • تنتهي صلاحية Internet-Draft في التشغيل الحالي لمستودع IETF عادة بعد 185 يوماً من إيداعها، ما لم تمنع حالة معالجة رسمية ذلك. تصف العلامة دورة حياة النسخة النشطة، ولا تسمّي جهة رفضت المقترح.
  • Repository النشط وArchive التاريخي سجلان مختلفان. تخرج النسخة من السطح النشط عند تحديثها أو استبدالها أو نشرها RFC أو انتهاء صلاحيتها، بينما تبقى النسخ محفوظة في Archive إلا في حالات إزالة استثنائية.
  • تفصل التواريخ الرسمية بين الساعة والقرار. انتهت النسخة draft-iab-protocol-maintenance-05 ثم عادت في مراجعات لاحقة وأصبحت RFC 9413. وانتهت draft-ietf-netvc-testing مرات عدة، لكن الإغلاق المؤثر كان حدثاً مستقلاً: حالة IESG باسم Dead مع سبب معلن.
  • يحتاج التدقيق إلى إيصال لحالة المسودة: الاسم والمراجعة بدقة، التواريخ، سلسلة الأرشفة والاستبدال، حالة مجموعة العمل ومسار النشر، أدلة التبنّي وLast Call، القرار الصريح، اعتماد التطبيقات، والمسؤول عن الاستنتاج.

السجل الذي حوّل الساعة إلى حكم

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

الوقائع المرصودة صحيحة: حدث انتهاء ثم ظهرت مراجعة. أما القراران المنسوبان إلى IETF فغير مثبتين. حوّل الإدخال الأول تاريخاً آلياً إلى رفض، وحوّل الثاني ملفاً جديداً إلى موافقة.

للرفض فاعل واختصاص ومحل. هل امتنعت مجموعة العمل عن تبنّي النص؟ هل قرر الرئيس غياب rough consensus؟ هل رفض Area Director رعاية العمل؟ هل أغلق IESG طلب نشر؟ هل توقف المؤلفون عن إرسال نسخ جديدة فحسب؟ هل حلت مسودة أخرى محل الاسم القديم؟ أم استمر النقاش بينما عبرت النسخة موعدها الآلي؟

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

Repository وArchive وحدث الأيام الـ185

تميز صفحة IETF Author Resources الحالية بين Repository الخاص بـInternet-Drafts وبين Archive. يحتوي Repository النسخ النشطة. وتتوقف نسخة عن كونها نشطة إذا حدّثتها مراجعة أحدث، أو استبدلتها مسودة أخرى، أو نُشرت RFC، أو انتهت صلاحيتها. أما Archive فيحفظ المراجعات وصيغ عرضها، باستثناء حالات الإزالة النادرة.

تحدد القاعدة التشغيلية الانتهاء عادة بعد 185 يوماً من الإيداع. غير أن بعض الحالات الرسمية تمنع الساعة من إنتاج علامة الانتهاء، مثل معالجة IESG للنشر في مسار IETF، أو مراجعة Independent Series Editor لمسار Independent Submission. حتى الحدث الآلي إذن مرتبط بسجل الإجراء، وليس مقصلة واحدة تعمل بالطريقة نفسها على كل ملف.

ولا يجعل الحفظ في Archive المسودة منشوراً أرشيفياً. تؤكد الصفحة نفسها أن Internet-Drafts أعمال قيد التطوير، وينبغي ألا تُقتبس بصفة أخرى. يجيب الحفظ عن سؤال «ما النص الذي كان موجوداً؟»، لا عن سؤال «ما الذي وافقت عليه IETF؟».

تكشف الفقرة 2.2 من RFC 2026 تطور البنية. ففي 1996 وصفت BCP 9 الدليل بأنه وسيلة لعرض نص متغير للمراجعة غير الرسمية. كانت المسودة تزال إذا بقيت أكثر من ستة أشهر بلا تغيير ومن دون توصية IESG بالنشر، وتبدأ المدة من جديد مع نسخة أحدث. كما قررت الوثيقة أن Internet-Drafts لا تتمتع بمكانة رسمية وقابلة للتغيير أو الإزالة.

تغيرت الأداة: أصبح الوصف 185 يوماً، وصار Archive يحفظ التاريخ. لكن الحد المؤسسي لم ينقلب. المسودة ليست RFC، وبلوغ موعد المستودع لا يقوم مقام قرار صادر عن صاحب صلاحية.

أربع طبقات لا تتسع لها شارة واحدة

الطبقة الأولى هي هوية الوثيقة. ليست draft-example-foo-04 فكرة عائمة اسمها Foo؛ بل مراجعة محددة بتاريخ وبايتات ومراجع. قد تصلح النسخة 05 شرطاً أمنياً أو تغير الآلية أو تضيق النطاق. من يحذف رقم المراجعة لا يستطيع إثبات النص الذي فحصه.

الثانية هي دورة حياة المستودع. تشرح حالات active وupdated وreplaced وpublished وexpired سبب بقاء مراجعة نسخة نشطة أو خروجها من العرض الحالي. تساعد في العثور على العمل الجاري، لكنها لا تقيس الجودة التقنية أو التوافق.

الثالثة هي حالة الإجراء. يختلف الإيداع الفردي عن المرشح لتبنّي مجموعة عمل، وعن وثيقة تبنتها المجموعة، وعن نص في Working Group Last Call، وعن طلب نشر يراجعه IESG. تصف الفقرة 7.2 من RFC 2418 المسودات بوصفها وثائق عمل؛ وتعامل الفقرة 7.4 Last Call كفعل مستقل؛ ثم تفصل الفقرة 7.5 بين rough consensus اللازم للتقدم وبين الإحالة إلى IESG.

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

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

المسودة التي انتهت ثم أصبحت RFC 9413

يقدم تاريخ Maintaining Robust Protocols الرسمي مثالاً مباشراً يمنع مساواة الانتهاء بالرفض. نُشرت المراجعة 05 في 12 يوليو/تموز 2021، وسجل النظام انتهاءها في 13 يناير/كانون الثاني 2022. ظهرت المراجعة 06 في 10 مايو/أيار، ثم تلتها المراجعات 07 إلى 12. نقل IAB الوثيقة عبر Community Review ثم IAB Review، وسجل التوافق والموافقة، وأرسل النص إلى RFC Editor في فبراير/شباط 2023.

نُشرت النتيجة في يونيو/حزيران 2023 بصفتها RFC 9413. انتهاء النسخة 05 واقعة تاريخية ينبغي حفظها، لكن وصفها بأنها رفض من IAB أو IETF يظل خاطئاً. لم تمنع الساعة المراجعات اللاحقة ولم تحسم مصيرها.

لا يثبت المثال أن كل مسودة منتهية ستعود. يثبت فقط القضية الأضيق والضرورية: الانتهاء لا يساوي الرفض منطقياً. إذا كان النموذج لا يستطيع إلا كتابة «مرفوض» ثم استبدالها لاحقاً بـ«مقبول»، فهو يمحو سلسلة الحوكمة التي يفترض أن يوثقها.

السجل السليم يحتفظ بكل حدث: خروج 05 آلياً، وصول 06، خطوات المراجعة بفاعليها، ثم نتيجة النشر RFC 9413. لكل حقيقة وقتها وفاعلها ومعناها.

الإغلاق الحقيقي كانت له جهة وسبب

يبين تاريخ Video Codec Testing and Quality Measurement الجهة المقابلة. انتهت المراجعة 05 في سبتمبر/أيلول 2017، وجاءت 06 في الشهر التالي. انتهت 06 في مايو/أيار 2018؛ وظهرت 07 في يوليو/تموز ودخلت Last Call في المجموعة. وفي يناير/كانون الثاني 2019 انتهت 07 بينما كانت حالة المجموعة تسجل وجود توافق وانتظار write-up. ثم دخلت 08 مسار النشر وIETF Last Call.

وصل السجل السلبي المهم في 25 مارس/آذار 2020. تغيرت حالة IESG إلى Dead. وشرح Area Director أنه بعد محاولات متكررة للحصول على ردود على ملاحظات التقييم، لم يعد لدى مجموعة NETVC الزخم الكافي لإكمال الوثيقة. لم يحدث انتهاء آلي آخر إلا في أغسطس/آب.

هنا يوجد إغلاق صالح للاستشهاد: تاريخ، وسطح قرار، وسبب. يتناول السبب ضعف الزخم وبقاء ملاحظات بلا حل؛ ولا يحكم بأن طرق الاختبار عديمة القيمة. بل ذكر shepherd write-up أنها كانت مستخدمة لدى مطوري AV1. كان اعتماد التطبيق، والتصرف في النشر، وانتهاء المستودع ثلاث وقائع منفصلة.

لو سمي الانتهاء الأخير وحده رفضاً، لاختفت أفضل بينة: تغيير IESG وتفسيره. ولو سميت الانتهاءات السابقة رفضاً، لتعارض الوصف مع استمرار العمل الموثق.

المراجعة الجديدة ليست موافقة

الحد متناظر. إذا لم يثبت الانتهاء الرفض، فلا تثبت المراجعة القبول. يستطيع من يستوفي الشروط تقديم Internet-Draft. وقد تستجيب النسخة الجديدة للتعليقات، أو تستعيد الظهور، أو تعيد النقاش، أو تحفظ خيار الاستمرار فحسب.

ولا يكفي الاسم. يعكس draft-ietf-... عادة تبنّي مجموعة، لكن التاريخ الدقيق يبقى الدليل. لا يثبت الاسم rough consensus حالياً على كل جملة ولا موافقة IESG. يفتح Last Call مراجعة محددة؛ ولا يشكل نشرًا نهائياً.

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

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

اقتراح إلغاء الانتهاء يبقى اقتراحاً

تجادل المسودة الفردية Removing Expiration Notices from Internet-Drafts بأن الانتهاء الآلي فقد فائدته بعدما صارت النسخ محفوظة. وتشير إلى استمرار الاستشهاد بمسودات منتهية وإلى أن بعض الأنظمة تغير العرض فقط. هذه بينة على وجود نقاش، لا على توافق.

انتهت المراجعة الأخيرة من الاقتراح نفسه. لا تجعل المفارقة الحجة موضع سخرية أو مصدر إلزام. لم يعتمد النص قاعدة حالية، ولا يعني وجوده أن IETF قررت إلغاء الانتهاء.

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

إيصال حالة المسودة

الحقل ما يثبته
الاسم والمراجعة النص المحدد الذي جرى فحصه
بصمة المحتوى تطابق البايتات المقروءة والمحفوظة
تاريخا الإيداع والانتهاء حدث الساعة والقاعدة المطبقة
حالة Repository هل النسخة نشطة ولماذا خرجت
موضع Archive مكان حفظ النص والصيغ
سلسلة المراجعات السابق واللاحق من دون خلط
علاقات الاستبدال استمرار العمل باسم آخر
المسار والراعي والمجموعة الجهة المسؤولة عن الخطوة التالية
التبنّي قبول المجموعة للعمل ودليله
التوافق وLast Call النسخة التي روجعت والاعتراضات المفتوحة
قرار IESG أو المسار الفاعل والتاريخ والحالة والأسباب
نتيجة النشر رقم RFC والمسار والفئة
اعتماد التطبيق الكود والاختبارات والنشر العملي
أداة التبنّي الخارجي العقد أو السياسة والمراجعة المختارة
المسؤول والمراجعة التالية من يصحح السجل عند التغير

يمنع الإيصال خطأين متعاكسين. تحويل Active أو adopted أو Last Call إلى «وافقت IETF» يضخم السلطة. وتحويل Expired إلى «رفضت IETF» يخترع سلطة سلبية. يحتاج الأول فعلاً إيجابياً، والثاني قراراً سلبياً. لا توفر الساعة أياً منهما.

المصادر

النتيجة

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

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