الخلاصة

  • حذرت نسخة RFC 1410 الرسمية الصادرة في مارس 1993 من استخدامها بعد 31 يوليو من العام نفسه. كان سجل الحالة الرسمية وثيقة مؤرخة ذات أجل محدد.
  • احتاج الانتقال بين درجات النضج إلى توصية IESG وتصديق IAB. وإذا امتنع المجلس عن التصديق، عاد الاقتراح إلى IETF؛ وساعدت فترات الانتظار والتطبيقات المستقلة على اختبار ادعاء النضج.

قد تبدو عبارة «لا تستخدم هذه النسخة بعد 31 يوليو» غريبة في قائمة معايير رسمية. لكنها كانت في صلب وظيفة RFC 1410 الصادر في مارس 1993. حالة البروتوكول تتغير، والنسخة المطبوعة من القائمة لا تتغير معها. لذلك طلبت الوثيقة التحقق من أن النسخة هي الأحدث، ثم وضعت حدًا واضحًا لعمرها.

وراء كل خانة في القائمة سلسلة قرارات. كانت مجموعات عمل IETF تنجز معظم التطوير. يبدأ المسار بدرجة Proposed Standard، ثم Draft Standard، ثم Standard. في كل ترقية، يوصي Internet Engineering Steering Group، ويصدق Internet Architecture Board. إذا رفض IAB التصديق، يعاد الاقتراح إلى IETF لمزيد من العمل. التوصية والتصديق قراران مختلفان، ومن حق الثاني أن يعيد الملف إلى الأول.

حدد IAB مهلة دنيا ملزمة لكل انتقال: ستة أشهر على الأقل من Proposed إلى Draft، ثم أربعة أشهر على الأقل من Draft إلى Standard. وفي وصف منفصل، اعتبر دخول مرحلة Draft إنذارًا بترقية محتملة إلى Standard خلال ستة أشهر ما لم تظهر اعتراضات أو عيوب كبرى. الستة أشهر الأولى حد أدنى للانتقال الأول؛ والستة أشهر الثانية توقع للانتقال الثاني؛ والأربعة أشهر حد أدنى له. بلوغ أي موعد لا يصدر قرار الترقية وحده.

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

عند الشك، استطاع IAB تشكيل لجنة خاصة من خبراء IETF وIRTF وIAB لتوصي بخطوة محددة. وبقي القرار في سلسلة التصديق المعلنة. حتى الجدول نفسه سجل الحركة: حملت السطور المعدلة علامة نجمة، واحتفظت القائمة ببروتوكولات Historic التي استبدلت أو خرجت من الاستعمال. في قسم التغييرات، ارتفع Network Time Protocol الإصدار الثالث (RFC 1305) إلى Draft Standard، وانتقل IEEE 802.4 Token Bus MIB (RFC 1230) إلى Historic. تسجل القائمة القرارين، لكنها لا تقدم ملف اختبارات التطبيق لكل منهما.

يضع سجل RFC Editor اليوم RFC 1410 في حالة Historic، ويذكر أن RFC 1500 حل محله. لدينا قصة أخرى عن RFC 1311 تفصل بين رقم RFC ورقم STD. أما سؤال هذه النسخة فمختلف: من استطاع نقل البروتوكول بين الدرجات، ومن استطاع إعادته، وما الذي كان يجب أن يثبت قبل الانتقال؟

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