الخلاصة

  • أزالت المراجعة 05 من RDAP DELEG الحقلين priority وtarget، وسمّت البنية DelegInfos، وأعادت بناء الأمثلة على DELEG-11.
  • ما زالت مراجعة EPP DELEG-02، التي يستشهد بها النص مرجعًا معياريًا، تعرّف الحقلين داخل مخطط XML تصفه بأنه كامل وقابل للتحقق الآلي.
  • تطلب مسودة RDAP الإعلان عن dnsDeleg، لكنها تترك المواصفة الكاملة لأزواج المفاتيح والقيم في JSON بعلامة TBD.
  • لا تعرض المصادر تنفيذًا عاملًا أو فقدًا فعليًا للبيانات. وما تثبته هو غياب رحلة ذهاب وإياب قابلة للتكرار من EPP إلى DNS ثم RDAP.

تغيّر مخرج القراءة أولًا

يسجل إعلان مسودة الإنترنت نشر draft-albanna-regext-rdap-deleg-05 في 4 سبتمبر 2026. وتتمثل مهمتها في إتاحة قيم DELEG وDELEGPARAM ضمن استجابات RDAP الخاصة بكائنات النطاق. فهي تصف نافذة عامة على حالة التفويض، لا آلية التفويض في DNS نفسها.

يوضح سجل التغييرات ما وقع منذ المراجعة 04: حُذفت الإشارتان إلى priority وtarget، وتحوّل الاسم من delegInfo إلى DelegInfos، وصارت الأمثلة مبنية على DELEG-11. وتذكر مسودة DELEG-11 صراحة أن تنسيقها، رغم استفادته من SVCB، لا يحتوي SvcPriority ولا TargetName. أما الحمولة فهي قائمة من أزواج مفتاح وقيمة باسم DelegInfo.

تتضمن المجموعة الأولية server-ipv4 وserver-ipv6 وserver-name وinclude-delegparam، إضافة إلى مفتاح mandatory. وتقترح المسودة سجلًا مستقلًا لدى IANA يمنح كل مفتاح لاحق رقمًا واسمًا ومعنى ومرجعًا ثابتًا وجهة مسؤولة عن التغيير. هكذا يبقى الامتداد ممكنًا من دون أن تصبح الحقول لهجات خاصة بالمشغّلين.

إذًا اتبع طرف RDAP المقروء قرار DELEG-11. لكن طرف الإدخال لم يتحرك في الوقت نفسه.

مخطط EPP ما زال يحمل الشكل السابق

لا تعتمد مسودة RDAP على DELEG وحده؛ فهي تستشهد أيضًا، على نحو معياري، بخريطة EPP لسجلات DELEG. ويستخدم العميل الراعي EPP لإنشاء كائن نطاق في السجل وتعديله والاستعلام عنه. وتضيف المسودة المقترحة عناصر DELEG فوق خريطة النطاق المعيارية في RFC 5731.

تصف المراجعة 02 من EPP DELEG قسم الصياغة الرسمية بأنه مخطط كامل يصلح للتحقق الآلي من XML. ومع ذلك، ما زال النوع delegType يتضمن السمة priority بعدد صحيح قصير غير موقّع والسمة target. ويسمح نوع المعاملات كذلك بسمات عشوائية عبر processContents="skip".

قد يفسر التسلسل الزمني الفرق: نُشرت EPP-02 في 21 يوليو، وDELEG-11 في 23 يوليو، ثم RDAP-05 في سبتمبر. لكن التأخر التحريري ليس قاعدة تحويل. فقد يقبل المخطط المنشور رسالة EPP تحتوي حقلين تقول قاعدة DELEG الحالية إنهما غير موجودين، بينما أزالتهما صيغة RDAP الحالية.

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

اسم dnsDeleg لا يسجل أصل القيمة

تلزم RDAP-05 الاستجابة التي تحتوي البنية الجديدة بإضافة dnsDeleg إلى rdapConformance. يشرح RFC 9083 أن هذه المعرّفات تشير إلى المواصفات المستخدمة في بناء الاستجابة. وهي تساعد العميل على فهم JSON الممتد، لكنها لا تثبت مصدر كل قيمة ولا التحويلات التي سبقتها.

وتزداد أهمية ذلك لأن قسم الاستجابة نفسه يضع TBD مكان المواصفة الكاملة للمفاتيح والقيم التي يجوز ظهورها في DelegInfos. وينتظر تطور DELEG وEPP قبل اختيار المرجع. ترسم الأمثلة شكل المخرج، لكنها لا تقدم جدولًا معياريًا يصل XML في EPP بالعرض والأسلاك في DNS ثم JSON في RDAP.

عند تجميد البحث، لم يكن dnsDeleg موجودًا في سجل امتدادات RDAP لدى IANA. وتطلب المسودة تسجيله لمشغّل من نوع “Any”. الغياب ليس رفضًا من IANA، بل حالة زمنية لمعرّف ما زال مقترحًا.

هناك عمل منفصل في REGEXT بشأن إصدار امتدادات RDAP، يقترح إصدارات قابلة للقراءة الآلية، وروابط بين السابق واللاحق، وبيانات الإهمال وسياسة الانتقال. لا تستخدم RDAP DELEG-05 هذه الآلية حاليًا لتسمية إصدار الحمولة الذي أنتج الاستجابة.

لا تنتقل المكانة الإجرائية عبر المرجع

يصنف Datatracker لمسودة RDAP DELEG النص مسودة فردية بلا مسار RFC ولا مدير منطقة مسؤول. كما أن خريطة EPP مسودة فردية. يستطيع أي شخص تقديم Internet-Draft، ولا يعني النشر مصادقة IETF.

أما DELEG-11 فهي وثيقة لمجموعة عمل DELEG وفي مرحلة Working Group Last Call. لكنها لم تصبح RFC، وما زالت أرقام أنواع DNS والسجل الجديد ضمن الطلبات أو القيم المؤقتة. تقدم الوثيقة الأساسية لا يمنح الوثيقتين المرافقتين المكانة نفسها.

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

المطلوب سجل لحراسة المعنى

يجب أن يحدد العقد الكامل الإصدار الذي يحكم كل حقل، وكيف يصبح إدخال EPP حالة DNS ذات سلطة، وكيف تتحول تلك الحالة إلى RDAP، وما الذي يجوز إسقاطه عمدًا. ويجب أن يفرّق بين نية السجل، وملاحظة DNS السلطوية، وإسقاط محلي آخر معلن.

بدون ذلك قد يعلن خادمان dnsDeleg وهما يطبقان سياستين مختلفتين للتحويل. من يتحكم في الجسر يتحكم في النسخة التي تصبح مرئية من نية صاحب النطاق. عند هذه النقطة يتحول اختلاف المخطط إلى مسألة حوكمة.