يريد IETF ترقية RFC 7405، لكن دليل النشر ما زال مجمّعاً

الخلاصة

• يطلب IESG تعليقات جوهرية حتى 28 سبتمبر على ترقية RFC 7405 وإدراجها ضمن STD 68؛ ولم يصدر قرار بعد.
• أضافت الوثيقة عام 2014 الصيغة %s للسلاسل الحساسة لحالة الأحرف والصيغة %i للتصريح بعدم الحساسية، مع إبقاء السلسلة غير المسبوقة متوافقة مع ABNF الأقدم.
• أحصى طلب الترقية 20 وثيقة RFC تحيل إليها إحالة معيارية في الربع الثاني من 2026، وأبرز HTTP/1.1 وYANG، وقال إن أدوات ABNF تدعمها على نطاق واسع.
• تطلب RFC 6410 أيضاً تطبيقين مستقلين قابلين للتشغيل البيني، وانتشاراً واسعاً، وخبرة تشغيلية ناجحة. لا يعرض الطلب مصفوفة عامة تصل تلك المطالب بأمثلة محددة.
• يمكن لوصل قصير لأدلة النضج أن يغلق الفجوة من دون إعادة تقرير الاختبار الرسمي الذي ألغته RFC 6410 عمداً.

ما الذي يتغير فعلاً؟

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

جعلت RFC 7405 ذلك أوضح. فـ%s"false" تقبل الشكل نفسه فقط، و%i"aBc" تصرح بعدم تمييز الحالة، أما غياب البادئة فيحافظ على السلوك السابق. إنها إضافة ضيقة في أربع صفحات، لا إعادة تصميم للغة.

لا تنشر العملية الجارية RFC جديدة. تسمح RFC 6410 لـIESG بإعادة تصنيف النص القائم بعد Last Call على مستوى IETF يستمر أربعة أسابيع على الأقل. ويقول إعلان 31 أغسطس إن الطلب جاء من مشارك فردي، وإن القرار متوقع في الأسابيع التالية، وإن الموعد النهائي للتعليقات هو 28 سبتمبر. بقيت صفحة Datatracker في حالة AD Review عند تجميد الأدلة.

إذن هناك ثلاثة سجلات مختلفة: الطلب، والمراجعة العامة، والقرار. مشاركة الخبرة أو الاعتراض لا تغيّر التصنيف تلقائياً، كما أن فتح Last Call ليس موافقة مسبقة.

حجة الانتشار قوية ولكنها من نوع محدد

يستند الطلب إلى 20 إحالة معيارية في وثائق RFC حتى الربع الثاني من 2026. وتعرض صفحة الإحالات الحالية أعمالاً في HTTP وYANG والبريد والوسائط وCDDL وDNS وغيرها. لكنها تنبه أيضاً إلى أن استخراج الاعتماديات يعتمد على قواعد استدلالية.

تُظهر RFC 7950 الاستخدام داخل النص نفسه. فقواعد YANG 1.1 تستعمل %s مراراً لكلمات مثل module وcontainer وleaf وrpc. ويضيف الطلب HTTP/1.1 كمثال مهم، ويقرر أن الدعم أصبح واسعاً في أدوات ABNF، من دون مشكلات تشغيل بيني معروفة أو تفسيرات متباعدة.

ويقدم مثالاً معاكساً محدوداً. استخدمت RFC 9535 في 2024 القيم السداسية عشر لكتابة true وfalse وnull بحروف صغيرة. لا يثبت ذلك عيباً أو غياب دعم، ولا يكشف سبب اختيار المؤلفين. لكنه يبين أن بعض المواصفات الحديثة ما زالت لا تتعامل مع امتداد 7405 بوصفه جزءاً بديهياً من المرجع الأساسي.

أما المعايير الأخرى فتبدو مباشرة: اقتراح تصويب باستعمال علامات اقتباس مفردة رُفض، ولا يُعرف تصويب يمنع تطبيقاً جديداً من العمل مع المنشور، والميزة واحدة ولا تزيد تعقيداً غير مستخدم، ولا تعتمد على تقنية خاضعة لترخيص معلن.

خمسة اختبارات لا يجيب عنها رقم واحد

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

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

لكن بقاء الدليل موزعاً يخلق مشكلة ذاكرة. عبارة «لا توجد مشكلة معروفة» تكون قوية حين يعرف القارئ أي تطبيقات ومدخلات وسياقات كان يمكنها كشف الاختلاف. ومن دون هذا الحد الأدنى، يبقى الاستنتاج بعد سنوات فيما تختفي طريقته.

لا حاجة إلى إعادة طقس الاختبارات القديم

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

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

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

الشفرة العاملة تحتاج إلى نسبة واضحة

مبدأ running code عند Heng Lu يضع الواقع أمام الصياغة الفنية. لكنه لا يمنح منفذي الشفرة سلطة تقريرية. وإذا لم نعرف ما الذي عمل، وبأي إصدار ومدخل ونتيجة، يمكن أن تتحول عبارة «الشفرة تعمل» نفسها إلى شعار سلطة.

التقسيم الصحيح هو أن يقدم المنفذون الأدلة، وتبين الإحالات انتشار النص، ويقدم المشاركون الخبرة والاعتراض، ويقرر IESG. ربما تستحق RFC 7405 الترقية بالفعل. وصل الأدلة لا يؤخر الاعتراف بها، بل يحفظ سبب الاعتراف.

المصادر

1. IETF — Last Call لترقية RFC 7405
2. IETF Datatracker — طلب تغيير الحالة
3. RFC 6410 — مستويان للنضج
4. RFC 7405 — سلاسل ABNF الحساسة للحالة
5. IETF Datatracker — الإحالات إلى RFC 7405
6. RFC 5234 — مواصفة ABNF
7. RFC 7950 — لغة YANG 1.1
8. RFC 9535 — تعبيرات JSONPath
9. RFC Editor — سجل errata لـRFC 7405
10. Heng Lu — أولوية الشفرة العاملة