الخلاصة

  • لا تعني كلمة «اعتيادي» في RFC 6709 أن التعديل صغير أو أن أسطر الشيفرة قليلة. لا يصح هذا التصنيف إلا إذا أمكن للبروتوكول الأساسي والتنفيذات المنشورة تجاهل الامتداد من دون ضرر؛ وإذا احتاج البرنامج القائم إلى تغيير، فقد يكون التعديل جوهرياً حتى لو لم تتبدل صيغة الإرسال إلا قليلاً.
  • لا يلغي التصنيف مراجعة الخبراء. توصي RFC 6709 بتقييد الإجراءات التي لا تتطلب مراجعة أو تكتفي بالقليل منها، وتقول إن الامتدادات الاعتيادية قد تستفيد من الخبراء. كما تشرح RFC 4775 لماذا ينبغي مناقشة سمات RADIUS الجديدة مع من يعرفون البنية واستخداماتها القائمة.

لا تدع كلمة واحدة تحسم قرارين

في تقييم البروتوكول، يسهل الخلط بين سؤالين: ما أثر الامتداد في البروتوكول والأنظمة التي تستخدمه بالفعل؟ وما مقدار المراجعة التي يحتاجها المقترح قبل أن يعتمد عليه الآخرون؟ تبدو كلمة «اعتيادي» كأنها تجيب عن الاثنين. وتوضح RFC 6709 لماذا لا تفعل ذلك.

نشر مجلس هندسة الإنترنت (IAB) الوثيقة RFC 6709 في سبتمبر 2012 ضمن فئة Informational. وهي موجهة إلى مصممي البروتوكولات الأساسية والامتدادات معاً. يقر النص بأن قابلية التوسع تسهّل التطور التدريجي، لكنه يحذر أيضاً من مشكلات التشغيل البيني والتشغيل والأمن. ويربط التمييز بين الامتداد الاعتيادي والجوهري بالأثر المتوقع وبمستوى التدقيق الذي قد يلزم. هذه إرشادات معمارية، وليست معياراً للإنترنت ولا قاعدة موافقة عامة.

وتضع RFC 6709 نفسها ضمن نقاش أقدم. فهي تذكر RFC 1263، مذكرة «TCP Extensions Considered Harmful» الصادرة سنة 1991، بوصفها تحذيراً سابقاً من كلفة الامتدادات. لتلك المذكرة حجتها التاريخية الخاصة؛ أما RFC 6709 فلا تعيد فتح خلاف حدود إصدارات TCP. بل تقول إن الاعتبارات العامة لتصميم الامتدادات لم تكن قد جُمعت في مرجع واحد. وكانت RFC 4775، المنشورة سنة 2006 بوصفها BCP 125، قد تناولت إجراءات توسيع بروتوكولات IETF. وجاءت RFC 6709 لتوضح اختباراً معمارياً يسترشد به ذلك العمل.

«جوهري» يتعلق بالعواقب، لا بحجم الحزمة

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

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

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

للاعتيادي حد صارم

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

تذكر RFC 6709 خيارات DHCP الخاصة بالمورد، وسمات RADIUS الخاصة بالمورد، ومعرّفات الكائنات المؤسسية المستخدمة لوحدات MIB، وأنواع MIME الخاصة بالمورد. ليست العبرة بصغر الإضافات، بل بقدرتها على شغل مساحة الامتداد التي أتاحها البروتوكول من دون فرض سلوك جديد على الأنظمة غير المشاركة.

ويمنع المقطع نفسه قراءة متساهلة أكثر مما ينبغي. توصي RFC 6709 باستخدام محدود لآليات الامتداد الاعتيادي التي تتطلب مراجعة ضئيلة أو لا تتطلبها، مثل التخصيص بالأسبقية في الطلب، وقصرها على الحالات الأقل عرضة لمخاطر التشغيل البيني والأمن والتشغيل. كما تقول إن الامتداد الاعتيادي قد يستفيد من الخبراء: فخيار DHCP الذي يُعامل كبيانات معتمة لكنه يفتقر كلياً إلى البنية قد يصعب على العملاء والخوادم معالجته بلا داعٍ.

RADIUS يوضح أن السؤالين منفصلان

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

ومع ذلك، تذكر RFC 6709 سمات RADIUS الخاصة بالمورد مثالاً على الامتداد الاعتيادي. لا يوجد تناقض؛ فالوثيقتان تجيبان عن سؤالين مختلفين. تسأل «اعتيادي» هل ينسجم الامتداد مع البنية وهل تستطيع الأنظمة التي لا تستخدمه تجاهله بأمان. وتسأل RFC 4775 ما الإجراء والخبرة اللازمان لمرافقة المقترح. وتترك RFC 6709 صراحة مجالاً لمراجعة الخبراء حتى بعد اجتياز الامتداد اختبار الاعتيادية.

وهذا فارق مهم: لا يثبت نشر الوثيقة أو تخصيص القيمة وحده أن الامتداد آمن، أو أنه نُفذ، أو أن المشغلين اعتمدوه. قد تكشف المراجعة عن مشكلة قبل تقدم المقترح، لكنها لا تحل محل اختبار التنفيذ الفعلي ولا تثبت حصول النشر.

ثلاث قرائن بدلاً من ملصق واحد

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

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

وتحذر RFC 6709 أيضاً من تصميم قابلية توسع أكبر مما يلزم عند إنشاء البروتوكول. وقد تكون الاستخدامات اللاحقة مجهولة، لكن هذا لا يوجب على التصميم الأولي توقع كل طلب ممكن. القاعدة المتزنة هي إبقاء موضع آمن للتغيير من دون الادعاء بأن كل استخدام مستقبلي سيناسبه.

ما تثبته السجلات وما لا تثبته

توثق RFC 6709 إرشاد IAB للتصميم، ولا تقدم إحصاءً تجريبياً للتنفيذات. وتسجل RFC 4775 إجراءات، ولا تثبت أن كل مقترح اتبعها. تثبت المصادر المعايير والتنبيهات الواردة في الوثائق، لكنها لا تبين عدد الامتدادات المنشورة، أو ما إذا كانت شبكة بعينها قد تبنت أحدها، أو ما إذا كان امتداد محدد سبب حادثاً.

تقدم Note 64 لهينغ لو منظوراً تحريرياً آخر: وضع القواعد المشتركة الضرورية للتشغيل البيني فقط، وترك القرارات اللاحقة للمشاركين ما أمكن، واعتبار التغيير واقعاً تشغيلياً عبر التنفيذ والتبني. هذا تفسير تحليلي لاحق من BTW، وليس بياناً عن قصد IAB. ومن هذا المنظور، تصف «اعتيادي» حدود التوافق؛ ولا يثبت النشر أو التسجيل أو نتيجة المراجعة حصول التبني.

تكمن القيمة التاريخية لـ RFC 6709 في السؤال الذي يصعب بعده التهرب: هل تستطيع الأنظمة الأقدم تجاهل الامتداد بلا ضرر، أم يُطلب منها التغيير؟ بعد اتضاح الإجابة، يمكن اختيار مستوى المراجعة عمداً. «اعتيادي» لا يعني آمناً تلقائياً، و«جوهري» لا يعد أسطر الشيفرة.

المصادر