الخلاصة

  • يعرّف RFC 5144 خدمة DCHK الخفيفة بوصفها مجموعة فرعية صارمة من نموذج DREG في IRIS.
  • تصف active وinactive النشر في DNS، لا حق شخص بعينه في تسجيل الاسم.
  • تعني reserved أن إجراءات التسجيل العادية لا تتيح الاسم، حتى إن لم يكن منشوراً في DNS.
  • حالات النزاع وفترات السماح تحفظ دورة حياة لا يمثلها جواب ثنائي.
  • قد تكون عمليات الإنشاء والحذف والتجديد والاستعادة والنقل والتحديث pending أو prohibited.
  • يحدد الفاعل والنطاق وسلطة الحالة الفرعية مصدر الادعاء وحدوده.
  • وقت تحديث قاعدة المصدر منفصل عن وقت الرد ووقت القرار.
  • مرجع التسجيل يدل على الجهة التالية، ولا ينقل صلاحيتها إلى الجهة السابقة.
  • تعتمد طبقة XML في IRIS على النقل للمصادقة والخصوصية.
  • بقاء معرّفات DCHK في سجلات IANA لا يثبت وجود نشر تشغيلي.
  • إحالة IDN القديمة إلى Nameprep تحتاج مراجعة منفصلة في عصر IDNA2008.
  • يجب فصل إيصال الملاحظة عن قرار السياسة وقبول الأمر والتغيير النهائي ونشر DNS.

من يملك معنى الحالة؟

يمكن لحالة DCHK أن تحمل تاريخ تطبيق، ومعرّفات تذاكر، ووصفاً طبيعياً بلغات مختلفة، وحالة فرعية. لا يعرّف RFC 5144 جميع قيم الحالة الفرعية، لكنه يفرض تحديد السلطة التي عرّفتها. ويستطيع actor التمييز بين السجل والمسجّل ومقدم خدمة التسجيل، فيما يوضح scope السياق أو الأصل.

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

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

عدم الظهور في DNS لا يعني حرية التسجيل

تعني active في RFC 5144 أن النطاق متاح عبر DNS بالتفويض أو النشر المباشر. وتعني inactive أنه غير متاح عبر DNS. المحور هنا هو النشر.

أما reserved فتعني صراحة أن الاسم غير متاح وفق إجراءات التسجيل العادية. ويمكن أيضاً أن يكون الاسم محل نزاع أو داخل فترة سماح بعد الإنشاء أو التجديد أو النقل أو الحذف. يوضح RFC 3915 أن الاسم المحذوف قد يمر بفترة استرداد ثم استعادة معلقة أو حذف معلق قبل أن يصبح متاحاً لإعادة التسجيل.

وتظهر المشكلة نفسها في أسماء العمليات. يمكن لـ DCHK وصف create أو delete أو renew أو restore أو transfer أو update، مع pending أو prohibited. ظهور كلمة transfer لا يثبت انتقال السيطرة. وفي سياق EPP، يصف RFC 5731 أمر check بأنه تلميح لاحتمال نجاح create، لأن المتطلبات النهائية تعود إلى سياسة الخادم. كما قد يبقى الأمر المعالج معلقاً قبل الاكتمال.

الحداثة خاصية للمصدر لا للشاشة

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

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

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

قناة موثقة لا تمنح تفويضاً تجارياً

ينص RFC 3981 على أن طبقة XML لا توفر بذاتها مصادقة أو خصوصية، بل تعتمد على طبقة النقل. ويلزم RFC 5144 دعم IRIS-LWZ، بينما يترك XPC وBEEP اختياريين. حتى لو تحققت المصادقة، فهي تثبت هوية طرف الجلسة وفق نموذج النقل، ولا تجعل البيانات أحدث ولا توسع نطاق الحالة ولا تمنح حق تعديل السجل.

تحتفظ IANA بمساحة وأسلوب dchk1 ووسم DCHK1 وملف BEEP. وما زال RFC 5144 Proposed Standard. ويصحح الخطأ الموثق الوحيد كتابة “Straightforward-NAPTR” فقط. هذه أدلة تخصيص ووثائق، لا إحصاءات عن التشغيل أو الدقة.

يحيل حقل IDN إلى Nameprep في RFC 3491 الذي أصبح متقادماً، بينما يعرّف RFC 5891 بروتوكول IDNA2008. لا يثبت ذلك إلغاء RFC 5144 رسمياً، لكنه يمنع افتراض توافق قواعد التطبيع القديمة مع سياسة حالية. ويقدم RFC 9083 نموذجاً أحدث لاستجابات RDAP بصيغة JSON من دون أن يكون في هذه المادة دليلاً على استبدال رسمي.

سلسلة الأدلة المطلوبة

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

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

المصادر

  1. RFC 5144 بصيغة HTML
  2. نص RFC 5144
  3. سجل RFC Editor
  4. سجل IETF Datatracker
  5. تاريخ الوثيقة
  6. بحث الأخطاء
  7. النسخة المضمنة بالتصحيح الموثق
  8. سجل XML لدى IANA
  9. معلمات S-NAPTR لدى IANA
  10. معلمات BEEP لدى IANA
  11. RFC 3981: نواة IRIS
  12. RFC 3982: سجل نطاقات IRIS
  13. RFC 3983: IRIS فوق BEEP
  14. RFC 4992: تمرير XML في IRIS
  15. RFC 4993: نقل UDP الخفيف لـ IRIS
  16. RFC 3915: فترات السماح في EPP
  17. RFC 5731: ربط نطاقات EPP
  18. RFC 3491: Nameprep
  19. RFC 5891: IDNA2008
  20. RFC 9083: استجابات RDAP بصيغة JSON
  21. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  22. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  23. Running-Code Primacy