كانت الرسالة واحدة، لكن صاحب الصلاحية تغيّر

الخلاصة

• في RFC 3632 كان الراعي الحالي يستخدم -Approve:No لرفض نقل معلّق، بينما يستخدمه المسجّل الطالب لإلغاء طلبه هو. وقد حدّدت الجلسة الموثقة والدور والحالة السابقة معنى الأمر.
• تثبت استجابة 200 نجاح معالجة أمر RRP، لكنها لا تثبت إرادة صاحب النطاق أو موافقة بشرية أو نشر DNS أو النتيجة التي رآها المستخدم.
• يتطلب الدليل القابل للمساءلة ربط الفاعل والدور والكائن والحالة السابقة والقاعدة والمهلة والاستجابة والحالة اللاحقة والإشعار خارج القناة. حفظ النص وحده قد ينسب القرار إلى الجهة الخطأ.

لم تكن الكلمة هي التي تملك السلطة

نُشر RFC 3632 في ديسمبر/كانون الأول 2003 بوصفه وثيقة معلوماتية تصف RRP 2.0.0. وهو ليس Internet Standard ولا دليلاً لتشغيل RRP اليوم. لكن تفصيلاً صغيراً فيه يصلح لاختبار أي نظام تدقيق حديث: هل يحفظ النظام الرسالة فقط، أم يحفظ أيضاً من كان مخولاً بإعطائها معناها؟

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

تثبت صفحة RFC Editor وسجل IETF Datatracker وتاريخ الوثيقة وبحث الأخطاء حالة النص ونشره. ولا يثبت أي منها أن مشغّلاً بعينه طبقه أو أن نقلاً محدداً انتهى بنتيجة ما.

هوية المتكلم جاءت من الجلسة

يوضح RFC 2832 أن هوية المسجّل الطالب كانت تُستمد من الجلسة النشطة الموثقة، وأن السجل كان يعرف المسجّل الراعي للنطاق. ومن ثم كانت الصلاحية نتيجة وصل ثلاثة أشياء: هوية الجلسة، وعلاقة الفاعل بالكائن، وحالة النقل.

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

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

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

كان حق الإلغاء ينتهي عند حافة زمنية

قسّم RFC 3375 الأدوار بوضوح: يبدأ الطالب النقل ويستطيع إلغاءه قبل القرار؛ ويستطيع الراعي الحالي الموافقة أو الرفض؛ ويجب رفض محاولات غير المخولين؛ ويحتاج الطرفان إلى متابعة الحالات المعلّقة والمنتهية.

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

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

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

للاستجابة 200 موضوع محدود

تنتهي عينة الإلغاء بعبارة 200 Command completed successfully. وهي دليل مفيد على أن خادم RRP أكمل الأمر. لا ينبغي التقليل من قيمتها، ولا ينبغي أيضاً توسيعها خارج موضوعها.

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

يقدم Lu Heng في On Authority and Belief السؤال الحاسم: من أصدر العبارة، وعن أي كائن، وإلى أين تمتد ولايته؟ يستطيع السجل أن يتحدث بسلطة عن الكائنات التي يديرها. ولا يستطيع كود الاستجابة أن ينوب عن نية العميل أو واقع الشبكة.

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

جعل EPP الفعل أكثر وضوحاً

يفصل RFC 5731 عمليات النقل إلى request وcancel وapprove وreject وquery. ويمكن أن تتضمن حالة النقل المعلّق هوية العميل الطالب وتاريخ الطلب وهوية العميل المنفذ وتاريخ الفعل. ويوفر RFC 5730 معرّفات معاملات لدى العميل والخادم.

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

يساعد RFC 3730 في وضع جيل أقدم من EPP في سياقه. ولا تثبت هذه الوثائق انتقال جهة مسماة أو التزامها. الواجهة الرسمية احتمال؛ أما ما نفذه النظام واحتفظ به فدليل مستقل.

حكم 510 على الترميز لا على الهوية

أضاف RFC 3632 الكود 510 لترميز غير صالح في عمليتي ADD أو MOD. وقدم RFC 5890 لاحقاً مصطلحات أدق لأسماء النطاقات المدوّلة.

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

ينبغي ألا تُستخدم كلمة «صالح» بلا مضاف إليه: صالح لأي صياغة، وبأي نسخة، وتحت أي سياسة؟ حذف هذا القيد يجعل المحلل اللغوي يتولى سلطة مؤسسية لم تُمنح له.

قبول IPv6 لا يثبت الوصول

سمح RFC 3632 بعناوين IPv6 الكاملة أو المختصرة في كائنات خوادم الأسماء. يصف RFC 4291 بنية العنونة، ويقترح RFC 5952 لاحقاً تمثيلاً نصياً معيارياً.

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

ينبغي حفظ كائن المضيف ومجموعة التفويض ونشر المنطقة ورؤية التوجيه ومجسات DNS الموزعة. عندما تتفق، تزداد الثقة؛ وعندما تختلف، تكشف طبقة الانفصال بين الشكل والتشغيل.

رسم 557 حدود سطح تحكم آخر

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

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

لا تشرح هذه المواد المعاصرة معاملة RRP تاريخية. لكنها تظهر أن كائن السجل، وطلب الجذر المصرح، ونشر الجذر، والخدمة العاملة ليست حالة واحدة.

الإيصال الأدنى علاقة قابلة للوصل

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

يقدم Minimum Initial Specification لدى Heng المقياس المناسب: واجهة أدنى مشتركة من دون مركزة كل سلطة لاحقة. يجعل السجل قراره قابلاً للربط، ولا يتحول إلى حكم على موافقة العميل أو التوافر.

تفصل Reality Layers بين الرمز والقرار المؤسسي وسجل البيانات ونشر DNS وتجربة المستخدم. ويطلب Running Code Primary التحقق من الانتقال الذي نُفذ فعلاً.

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

المصادر

1. RFC 3632 — VeriSign Registry Registrar Protocol 2.0.0
2. النص الكامل لـ RFC 3632
3. معلومات RFC Editor عن RFC 3632
4. سجل RFC 3632 في IETF Datatracker
5. تاريخ RFC 3632
6. بحث أخطاء RFC 3632
7. RFC 2832 — Registry Registrar Protocol 1.1
8. RFC 3375 — متطلبات بروتوكول السجل والمسجّل
9. RFC 3730 — Extensible Provisioning Protocol
10. RFC 5730 — Extensible Provisioning Protocol
11. RFC 5731 — ربط نطاقات EPP
12. RFC 5732 — ربط مضيفي EPP
13. RFC 4291 — بنية عنونة IPv6
14. RFC 5952 — التمثيل النصي لعناوين IPv6
15. RFC 5890 — تعريفات IDNA
16. IANA — إدارة منطقة الجذر
17. IANA — إدارة نطاق مستوى أعلى
18. IANA — الموافقة على تغيير منطقة الجذر
19. IANA — المتطلبات التقنية لخوادم الأسماء
20. IANA — واجهة نظام إدارة منطقة الجذر
21. Lu Heng — On Authority and Belief
22. Lu Heng — On Reality Layers
23. Lu Heng — Running Code Primary
24. Lu Heng — Minimum Initial Specification