Summary

  • ترسم مسودة RPP الأساسية، المراجعة 01، بتاريخ 2 نوفمبر 2026، مقابلة بين إدارة عناصر قاعدة مشتركة مثل النطاقات وواجهات HTTP؛ وتضع مسودة عناصر البيانات نموذج العناصر منفصلاً. ما زالت المسودة قيد العمل في IETF.
  • نقل النطاق يغيّر العميل الراعي، لكن RPP يصوغ النقل كعنصر عملية له دورة حياة. يرسل المسجّل المبادر POST /domainNames/{name}/processes/transferProcesses؛ ويعرض المثال رد 201 Created مع رابط للعملية في Location.
  • يستطيع المبادر إلغاء الطلب المعلّق، ويستطيع الراعي الحالي رفضه أو الموافقة عليه. قد تحمل قائمة رسائل دائمة خبر اكتمال العملية لاحقاً؛ قراءة الرسالة غير تأكيد استلامها.

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

صُمّم RPP بروتوكولاً مستقلاً. يمكن تشغيله أمام نظام EPP، لكن الجسر بينهما موضوع آخر. تحدد المسودة الأساسية المسارات وطرق HTTP والترويسات والرموز، فيما تحدد وثيقة أخرى عناصر البيانات، وتتولى مواصفات منفصلة شكل الرسائل. لذلك ينبغي لقارئ سجل العمليات أن يسأل: أي عنصر أنجزت هذه الاستجابة خطوة فيه، النطاق أم عملية نقل النطاق؟

الرابط يشير إلى ملف عمل مفتوح

تعرّف الفقرة 16.9.5 النقل بأنه تغيير العميل الراعي، وتعطيه مورداً إجرائياً بدورة حياة مستقلة. يرسل المسجّل الراغب في الدخول POST إلى مجموعة transferProcesses التابعة للنطاق. مثال الرد يحمل 201 Created ورمز نتيجة RPP وLocation ينتهي بـ/transferProcesses/latest. ذلك العنوان يتيح متابعة أحدث عملية نقل. ليس قراءة نهائية لراعي النطاق.

يمكن للعميل الاستعلام عن حالة العملية بـGET. إن ظل الطلب معلقاً، يلغيه المبادر بـDELETE. وللمسجّل الراعي حالياً عمليتا transferReject وtransferApprove. توزيع الأفعال هنا توزيع سلطة. من يطلب الدخول لا يمنح نفسه موافقة الطرف الذي لا يزال يرعى الاسم. السجل التشغيلي السليم يصل بين الطلب وحالة العملية والقرار والقراءة اللاحقة لبيانات النطاق.

وحتى بقاء رابط العملية له شروط. إذا كشف الخادم عن نسخ العمليات، يجب أن يتيح الوصول إلى أحدثها عبر latest، ويمكنه إعطاء معرف دائم. إذا اختار ألّا يكشف عن مورد عملية دائم، تلزمه المسودة برد 200 OK بدلاً من 201 Created. لا يصح افتراض رابط طويل العمر عند كل مشغّل. يمكن مع ذلك حفظ معرفات المعاملة وحالات العملية المتاحة ثم قراءة الراعي النهائي.

الرسالة المقروءة تبقى حتى تُؤكَّد

تضع المسودة قائمة دائمة لإشعارات غير متزامنة تخص العميل، وتذكر اكتمال نقل يحتاج موافقة جهة أخرى مثالاً. يحصل العميل على الرسائل بواسطة GET، ويؤكد رسالة بعينها بواسطة DELETE عليها. الرسالة التي استُرجعت ولم تُؤكَّد يجب أن تبقى في القائمة. بذلك لا تتحول عبارة «رأينا الخبر» تلقائياً إلى «عالجنا الخبر». ويصير الرد الأول على طلب النقل والإخطار اللاحق حدثين منفصلين في سلسلة الأدلة.

عندما تُنشئ عملية عادية مورداً إجرائياً كأثر جانبي، تشير الفقرة 15 إليه بترويسة Link وعلاقة rel="rpp-process". تحدد process النوع، وتظهر processId إن عيّن الخادم معرفاً دائماً، وتشير latest إلى أحدث عملية من النوع نفسه. تساعد هذه العلامات العميل في العثور على العمل المعلّق، ولا تصدر حكمه الأخير.

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

RPP الأساسي، المراجعة 01 · سجل Datatracker · عناصر بيانات RPP · RFC 5730