الخلاصة

  • تقترح النسخة 15 من RDAP Extensions حقل تاريخ لإلغاء استخدام الامتداد في سجل IANA. يطلب جهة الاتصال المسجلة ذلك لامتدادها، ويستطيع IESG طلبه لأي قيد. هذا يغيّر صفة القيد ولا يحذف البرمجيات الموزعة.
  • تعرض مسودة الإصدارات في /help البداية والنهاية والنسخة الافتراضية والسلف والخلف، وتحدد النسخة المستخدمة في الرد، وتسمح للعميل بطلب نسخة. وهي تنسّق الانتقال من دون أن تحصي كل العملاء.
  • يلزم إيصال تقاعد يفصل سلطة السجل وحالة كل خادم والطلب المقاس وما بقي مجهولاً. هذا اقتراح حوكمة من Daniel Kade، وليس شرطاً من IETF.

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

تصف draft-ietf-regext-rdap-extensions-15، المنشورة في 13 أغسطس 2026، RDAP بوصفه منظومة سلطات منفصلة. ينتقل العميل عبر خدمة إقلاع وتحويلات وإحالات إلى خوادم نطاقات أو مسجلين أو سجلات أرقام. لهذا لا يجوز افتراض أن طرفاً واحداً يرى دورة الاستخدام كلها.

الوثيقة مسودة عمل نشطة لمجموعة REGEXT، ومسارها المقصود Standards Track. يسجل Datatracker أن المجموعة طلبت نسخة منقحة بسبب مسألة مرفوعة، ولا يذكر مدير منطقة مسؤولاً. والنسخة 07 من مسودة الإصدارات، المنشورة في 31 يوليو، ما زالت مسودة أيضاً. ليست أي منهما RFC أو تفويض نشر.

السجل يملك صفة الاسم

تظهر معرّفات الامتدادات في rdapConformance وتمنع تضارب أسماء عناصر البروتوكول. وهي معرّفات مبهمة؛ فلا يثبت الرقم في آخر الاسم أن قيداً خلف لقيد سابق. يجب أن توثق المواصفة هذه العلاقة.

تقترح النسخة 15 إضافة Deprecation Date. تستطيع جهة الاتصال المذكورة طلب تقادم امتدادها، ويستطيع IESG طلب ذلك لأي امتداد، ثم تسجل IANA التاريخ بصيغة اليوم الكامل في RFC 3339. السلسلة واضحة في حدودها: طلب مختص، وحافظ للسجل، وتاريخ عام.

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

تطلب المسودة إسناد 21 أغسطس 2025 إلى icann_rdap_response_profile_0 وicann_rdap_technical_implementation_guide_0، وهما معروضان بالفعل بوصفهما OBSOLETED. وكان سجل IANA الحالي، المحدث في 1 سبتمبر 2026، يعرض الخلفين ذوي النسخة 1، من دون عمود مستقل للتاريخ. لا يثبت ذلك تقصيراً من IANA، لأن الحقل الجديد لم يتجاوز بعد مسودة العمل.

وتحمي سياسة Specification Required مع Expert Review باب الدخول إلى السجل. ينبغي أن تكون المرجعية ثابتة ومتاحة ومفصلة بما يكفي لتشغيل تطبيقات مستقلة معاً. تقترح النسخة 15 ثلاثة خبراء على الأقل ومراجعة ثانية لكل طلب. إنها مراجعة لمفردة مشتركة، لا إحصاء للأجهزة التي تستخدمها.

الخادم يعلن ساعته فقط

تفصل مسودة الإصدارات بين ثلاثة آثار. يعرض versioning_help في /help النسخ المدعومة والافتراضية والوثائق وعلاقات السلف والخلف وstart وend. ويحدد versioning_data النسخة التي شكّلت رداً بعينه. وينقل versioning_list تفضيل العميل.

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

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

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

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

القياس من دون سجل مراقبة

يمكن عد طلبات النسخة القديمة، ومقارنة ما قبل تغيير الافتراضي بما بعده، واختبار مسارات الإحالة، والاتصال بالعملاء المدارين. لكنها عينة. قد تغيب المهام الموسمية أو المكتبات التي تقبل الافتراضي بصمت.

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

إيصال التقاعد

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

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

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

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

المصادر