الخلاصة

  • صدرت المراجعة 03 في 13 سبتمبر 2026، وما زالت مسودة Internet-Draft فردية، لا وثيقة تبنّتها REGEXT ولا RFC منشورا.
  • بات طلب التسجيل يحيل إلى مواصفة مستقلة مجمّدة؛ وتؤكد المسودة بقاء نموذج البيانات والمعرّف وصيغة النقل دون تغيير.
  • لا يظهر reliabilityAssessment في قائمة IANA التي فُحصت. عرض طلب داخل وثيقة لا يثبت استلامه أو مراجعته أو الموافقة عليه.
  • تحديد معنى الاسم لا يمنح إجماع التقييس، ولا يحل محل قرار نشر البرمجيات أو تفويض الإجراءات التشغيلية.

أي نص يقف وراء الاسم؟

يحتاج منفّذ الامتداد إلى مرجع واضح يحدد معنى اسمه. أما تأييد مجتمع التقييس للتصميم فمسألة أخرى. وتحوّل المراجعة 03 من RDAP Extension for Structured Reliability Assessment Metadata هذا الفرق إلى ترتيب ملموس لنشر الوثائق.

يحمل المقترح تقييمات لمسجّلي أسماء النطاقات وللنطاقات ضمن استجابات RDAP. ولم تغيّر مراجعة 13 سبتمبر نموذج البيانات أو معرّف الامتداد أو اسم عضو JSON أو صيغة النقل. التغيير في القسم 13، حيث يُحدَّد النص الذي يستند إليه تسجيل reliabilityAssessment المطلوب.

كانت المراجعة 02 تتوقع الانتظار حتى نشر RFC. ويوضح المؤلفون الآن أن النقص كان في وجود مرجع مستقر، لا في شرط مطلق يمنع التسجيل خارج مسار RFC. وقد نشروا bcsec-RDAP-RA Version 1 بصورة مستقلة واستندوا إليه في الطلب. لم يُلغَ شرط الاستقرار؛ بل يقول النص إن المرجع الناقص صار متاحا.

ذلك لا يعني اكتمال التسجيل. فلا تتضمن لقطة سجل RDAP Extensions لدى IANA التي اعتمدها هذا التقرير الاسم المطلوب. ويسجل Datatracker العمل بوصفه مسودة فردية نشطة، بحالة I-D Exists. وليس لدينا دليل على استلام طلب رسمي لمجرد تضمينه في المواصفة.

النشر المستقل لا يعفي من مراجعة الخبراء

سياسة السجل الحالية هي Specification Required. ويشترط RFC 8126 موافقة خبير معيّن، مع مواصفة دائمة ومتاحة للجمهور، واضحة وسليمة تقنيا بما يكفي لتنفيذ مستقل قابل للتشغيل البيني. ويعد RFC وسيلة نشر مثالية، لكنه يسمح صراحة بمواصفات منشورة خارج هذا المسار.

أنشأ RFC 7480 سجل امتدادات RDAP ونموذج التسجيل. وتقترح مسودة مجموعة العمل RDAP Extensions إرشادات أكثر تحديدا للمرجع الثابت والمراجعة. تظل تلك إرشادات مقترحة؛ ولا يجعل استشهاد المسودة الفردية بها قاعدة نهائية بديلة.

مراجعة الخبير ليست حجزا إداريا للاسم فقط. وبالمقابل، استيفاء شروط التسجيل لا يحوّل العمل الفردي إلى إجماع IETF. وتحفظ المواصفة المستقلة صراحة حرية REGEXT في عدم تبنّي الامتداد. وتنشرها Bertoldi Cybersecurity وحدها، مع الإقرار بالتصميم التقني المشترك مع Simon Pietro Romano عبر المسودة الفردية.

تثبيت النص يفصل التصحيح عن إعادة الكتابة

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

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

ويقول الملحق C إن نموذج البيانات مطابق للمسودة، ثم يوضح فروقا في الوثيقة: تصبح بعض إحالات العمل غير المكتمل معلومات إرشادية، أو تُعاد كتابة قواعد التشغيل البيني اللازمة. وتُحذف دعوات المراجعة وصياغات المسائل المفتوحة أو تُعاد صياغتها. ولا تطلب المواصفة المستقلة تسجيلا منفصلا في RDAP JSON Values؛ تتابع المسودة الفردية هذا الجانب على نحو منفصل. إذن لا تعني المطابقة التقنية أن الوثيقتين متبادلتان لكل غرض إجرائي.

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

المصادر