الخلاصة

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

صدر RFC 2000 في فبراير 1997 بوصفه STD 1، وحل محل RFC 1920 وقوائم أقدم. قال إن الإصدار متوقع كل ثلاثة أشهر تقريباً، ثم وضع حداً صريحاً: لا تستخدم هذه الطبعة بعد 16 يونيو. وفي يونيو حل RFC 2200 محله وحدد موعداً تالياً. كانت السلطة مرتبطة بالنسخة الجارية.

لهذا تجيب كل خانة عن سؤال مؤرخ: كيف صنفت المؤسسة المواصفة آنذاك؟ لم تكن الوثيقة تعد البرامج أو الموجهات. بل أقرت بأن بعض بروتوكولات الشركات حققت تنفيذاً واسعاً من دون موافقة IESG. كان من الممكن أن يختلف الانتشار التشغيلي عن الوضع الرسمي.

جاء التصنيف على محورين مستقلين. محور STATE للنضج يضم Standard وDraft Standard وProposed Standard وExperimental وInformational وHistoric. ومحور STATUS لمستوى المتطلب يضم Required وRecommended وElective وLimited Use وNot Recommended. أما المصفوفة المطبوعة فكانت تصور تركيبات شائعة، لا أحجام السوق أو عدد المضيفين أو الحركة.

يحمل محور النضج أدلة متفاوتة. Standard يعني أن IESG قرر أن المواصفة معيار إنترنت رسمي ومنحها رقم STD. وبموجب RFC 2026، تطلب Draft Standard تنفيذين مستقلين ومتوافقين تشغيلياً من قاعدتي شيفرة مختلفتين، وخبرة تشغيل ناجحة كافية. وحتى عندها قد يكشف الإنتاج واسع النطاق سلوكاً غير متوقع. أما Proposed Standard فلم يكن يتطلب عادة تنفيذاً أو خبرة تشغيلية؛ كان مرشحاً مستقراً نسبياً، لا شهادة انتشار.

التسميات الخارجة عن المسار لا تقيس الواقع مباشرة. نشر Experimental أعمال البحث والتطوير للمنفعة العامة، ونص RFC 2000 على أن وجودها ليس دليلاً على التقييس. وقد يحمل Informational أعمال جهات أخرى أو شركات. ووصف Historic مواصفة تجاوزتها مواصفة أحدث أو عُدت بالية. لم يكن أي منها جرداً للأصول، ولم يوقف البرامج القديمة.

المحور الآخر لا يصف النضج، بل التوقع داخل نطاق التطبيق. Required لازم لتحقيق الحد الأدنى من المطابقة كما تحدده Applicability Statement، وليس أمراً عالمياً لكل مشترٍ. Recommended مرغوب من دون أن يكون شرطاً للحد الأدنى. Elective لا يفرض التنفيذ، لكنه يفرض اتباع المواصفة عند اختيار الوظيفة. ويقيد Limited Use وNot Recommended الاستخدام العام لأسباب متعددة، من غير أن يحددا ما بقي في الخدمة.

حتى آلية التغيير مختلفة. يقرر RFC 2000 أن تغيير STATE هو الذي يحرك البروتوكول على مسار المعايير، بينما يمكن إعادة النظر في STATUS في أي وقت. قد تنضج مواصفة ولا تصبح مطلوبة لكل نظام، وقد تكون وظيفة ضيقة ضرورية في مجالها من دون أن تتحول إلى أمر عام.

وتكشف الوثيقة اختلافاً بين ساعات تحديث أجزائها. ففي البداية ما زالت تسمي RFC 1602 الوصف الحاسم للعملية، بينما تسجل في قسم RFCs الجديدة وثيقة RFC 2026 التي كانت قد ألغت RFC 1602 في أكتوبر 1996. لا يثبت ذلك سبب بقاء العبارة، لكنه يثبت أن تاريخ الغلاف لا يجعل كل جزء من القائمة متزامناً.

تغيرت البنية لاحقاً. اختصر RFC 6410 في 2011 درجات المسار إلى Proposed Standard وInternet Standard، مع إبقاء أدلة التنفيذ المستقل والتشغيل البيني والانتشار الواسع والخبرة الناجحة للمستوى الأعلى. ثم أنهى RFC 7100 في 2013 ملخص STD 1 الدوري لأنه لم يعد محدثاً وانتقل الاستخدام إلى قائمة RFC Editor على الإنترنت.

تبقى قيمة RFC 2000 في حدوده الدقيقة: فهو يثبت التصنيف الرسمي في نافذة من عام 1997. أما الادعاء بالتنفيذ أو المطابقة أو التشغيل البيني أو الاستمرار فيحتاج إلى قوائم أصول واختبارات ورصد وقرارات شراء ومصدر حالة حديث.

المصادر: RFC 2000، سجل RFC Editor، RFC 1920، RFC 2026، RFC 2200، RFC 6410، RFC 7100.