تقول AFRINIC إنها أضافت JSContact، لكن دليل RDAP لا يبيّن أيّ صيغة منه

الخلاصة

• يسرد سجل WHOIS 2.10.7 الحالي لدى AFRINIC، المؤرخ في 29 نوفمبر 2022، JSContact بوصفه ميزة RDAP جديدة.
• يشرح دليل RDAP الحالي الاستعلامات والعميل وإعادة التوجيه خارج المنطقة، لكنه لا يحدد إصدار JSContact أو تمثيل الاستجابة أو إشارة المطابقة أو طريقة طلب العميل.
• هذه ملاحظة عن الوثائق المنشورة، وليست دليلاً على ما يعيده الطرف النهائي أو على عدم امتثال أو ضرر تشغيلي.

ما الذي يقوله السجل، وما الذي لا يقوله

تسجل صفحة التغييرات لدى AFRINIC أن WHOIS 2.10.7 هو الإصدار الحالي، وتؤرخ مدخلَه في 29 نوفمبر 2022. وتذكر الصفحة معالجة تحسينات تتصل بمطابقة ملف NRO RDAP، ثم إضافة ميزة RDAP جديدة اسمها JSContact. هذا يكفي لإثبات أن المؤسسة أعلنت تغييراً على مستوى الميزة في خدمة السجل.

أما دليل RDAP فيؤدي وظيفة مختلفة. فهو يحدد عنوان الخدمة، ومسارات البحث عن عناوين IP وautnum وDNS العكسي والكيانات. ويشير إلى عميل NicInfo في سطر الأوامر، ويشرح أن طلب مورد خارج منطقة AFRINIC يتلقى HTTP 301 مع رأس Location يدل على مورد RDAP الصحيح. هذه خريطة نافعة للقارئ الذي يريد إجراء استعلام مألوف.

لكن الخريطتين لا تضعان الاسم نفسه في موضع قابل للاختبار من جانب العميل. فالنص الحالي لإرشاد RDAP لا يحتوي على JSContact أو jCard أو rdapConformance أو version. لا يستطيع القارئ أن يعرف من هاتين الصفحتين وحدهما أي تمثيل لبيانات الاتصال يقصده اسم JSContact، أو إن كان الإصدار مهماً، أو هل توجد طريقة منشورة لطلب تمثيل معين، أو ما العلامة التي ستظهر في الاستجابة لتدل عليه.

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

لا يجوز إسقاط لغة 2026 على إعلان 2022

للتاريخ أهمية هنا. كان هناك في أبريل 2022 مسودة IETF عن استخدام JSContact في استجابات RDAP، قبل سجل AFRINIC في نوفمبر. كانت المسودة عملاً جارياً، تصف امتداداً لمعلومات اتصال الكيانات، وتستعمل مصطلحات مثل jscard. وجودها الزمني لا يثبت أن AFRINIC طبقتها، ولا يحوّلها إلى التزام على AFRINIC.

المسودة الحالية في أغسطس 2026 تستعمل لغة لاحقة: jscontact_card، واختيار التمثيل بناءً على طلب العميل، وإشارات rdapConformance، ومراحل انتقال بين jCard وJSContact. هي مقارنة تقنية مفيدة لأنها تبين أن الاسم وحده لا يجيب عن أسئلة مستقلة: ماذا يعاد افتراضياً؟ كيف يطلب بديل؟ كيف تبيّن الاستجابة ما وقع؟ وكيف توصف مرحلة التوافق؟ لكنها ليست معياراً بأثر رجعي لسجل AFRINIC لعام 2022.

كما أن سجل IANA الحالي لـJSContact يفصل بين الإصدارين الرئيسيين 1.0 و2.0. هذا لا يعرّف إصداراً منشوراً لدى AFRINIC. إنه يوضح فقط أن الاسم الواسع يحتاج أحياناً إلى سياق إضافي قبل أن يصبح وصفاً تشغيلياً للعميل.

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

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

سجل يحفظ السلطة ويضبط الاستنتاج

هذا الاقتراح لا يفرض على AFRINIC اختيار JSContact أو jCard ولا يفرض جدول انتقال. تبقى سلطة اختيار التمثيل وتشغيل الخدمة لدى السجل. الغرض هو منع القارئ من تحويل عبارة «أضيفت ميزة» إلى وعد غير منشور بإصدار أو افتراض أو توافق.

للكاتب العميل حد عام يمكن التحقق منه، وللمؤسسة موضع عام يمكن تصحيحه. لا يتغير قرار تقني ولا تتسع دائرة الإفصاح الحساس. إنما يعود الاسم العام إلى سجل يحدد ما يقوله حقاً.

المصادر

1. AFRINIC Online Services Changelog
2. دليل خدمة RDAP لدى AFRINIC
3. IETF draft-ietf-regext-rdap-jscontact-11
4. IETF draft-ietf-regext-rdap-jscontact
5. سجل IANA لـJSContact