الخلاصة

  • يطلب مشروع الوثيقة المرشح للحلول محل RFC 7451 من الخبراء المعيّنين أن يكونوا متساهلين عندما يكون امتداد EPP قد نُفذ ونُشر لدى زوج واحد على الأقل من سجل ومسجّل، أو من خادم وعميل. كما يقر بإمكان تسجيل عدة امتدادات ذات وظائف واحدة أو متشابهة، وبأن التشابه وحده لا يبرر الرفض.
  • يثبت التسجيل وجود مواصفة دائمة وهوية تقنية ومسار مراجعة يمكن نسبته إلى أصحابه. لكنه لا يختار التصميم الأفضل، ولا يمنح مرتبة Standards Track، ولا يثبت انتشاراً واسعاً أو قابلية الاستبدال داخل بيئة بعينها.
  • يعرض سجل IANA الحي التعايش فعلاً: فملاحظاته تصف امتدادات CORE للأسماء المدوّلة والخصوصية بأنها مطابقة نحوياً ووظيفياً لنظائرها لدى TANGO، مع استخدامها نطاقات أسماء XML مختلفة. والمطلوب تشغيلياً هو خريطة تحفظ التطابق والاختلاف معاً.

تبدو خانة في سجل IANA كأنها خاتمة نقاش. هناك اسم ثابت، ومرجع، وحالة Active، فتنتقل العين سريعاً من «مسجل» إلى «معتمد». وعند العثور على خانتين لوظيفة واحدة تقريباً، يصبح السؤال التلقائي: أيهما الرسمي؟

هذا السؤال يحمل السجل ما لم يُصمم للقيام به. يسمح EPP للسجلات والمسجّلين وموردي البرمجيات بإضافة قدرات تتجاوز البروتوكول الأساسي. وقد تظهر هذه القدرات في علاقات تشغيلية وأزمنة مختلفة. يجمع السجل العام معرّفاتها، يمنع التضارب، ويتيح الرجوع إلى المواصفات. لكنه لا يعيد كتابة تاريخ النشر ولا يجري منافسة تجارية بين الحلول.

تقول المراجعة العاشرة من draft-ietf-regext-ext-registry-epp، المنشورة في 17 أغسطس/آب 2026، ذلك بوضوح. يجوز تسجيل أكثر من امتداد يؤدي الوظيفة نفسها أو وظيفة شبيهة. ولا ينبغي رفض طلب صحيح لمجرد وجود شبيه له. فإذا أثبت امتداد أنه نُفذ ونُشر لدى زوج واحد على الأقل من السجل والمسجّل، أو الخادم والعميل، فعلى الخبراء اتباع نهج متساهل.

يثبت هذا الحد الأدنى أن الامتداد دخل حواراً حقيقياً. ولا يثبت أنه ربح السوق.

زوج واحد دليل وجود محدود

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

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

وحالة Active لا تزيد الدليل إلى انتشار شامل. يعرّفها المشروع بأنها «منفذة وقيد الاستخدام». أما Inactive فتشير إلى عدم التنفيذ أو الاستخدام، أو إلى تعذر الوصول إلى المواصفة. إنها إشارة إلى دورة الحياة وليست نسبة تبنٍّ. لا يقيس السجل عدد التركيبات ولا جودة الخدمة ولا التوافق المتبادل.

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

«المواصفة مطلوبة» تحمي معنى المعرّف

تقضي سياسة Specification Required في RFC 8126 بوجود مواصفة دائمة ومتاحة علناً، مع مراجعة خبراء معيّنين. يقبل المشروع الحالي وثائق RFC والمواصفات المملوكة التي تظل متاحة بسهولة، ويشترط نسخة إنجليزية. ولا يصلح Internet-Draft العادي مرجعاً دائماً للتسجيلات المقبلة، كما لا ينطبق مسار التخصيص المبكر في RFC 7120.

تحمي هذه الشروط قابلية تفسير نطاق الأسماء. فعندما يعثر مطور بعد سنوات على نطاق XML في سجل معاملة، يجب أن يستطيع معرفة المعنى المقصود. ولهذا يحتفظ الجدول بالاسم، وحالة الوثيقة، والمرجع، والمسجِّل، ونطاقات TLD، ومعلومات الملكية الفكرية، وحالة النشاط، والملاحظات.

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

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

وحتى القواعد الجديدة لم تصبح RFC بعد. المراجعة العاشرة Internet-Draft نشط، حالته المقصودة Best Current Practice، وقد أُرسل إلى IESG وهو في قائمة RFC Editor بانتظار تعيين محرر. إذا أُقر ونُشر فسيجعل RFC 7451 متقادماً. تجاهل هذه المرحلة ينسب إلى المشروع سلطة لم يكتمل مسارها بعد.

CORE وTANGO يثبتان أن التشابه لا يمحو الهوية

يجمع سجل IANA لامتدادات EPP، المحدث في 4 سبتمبر/أيلول 2026، وثائق Standards Track وأخرى مصنفة Other، ومدخلات Active وInactive. وتعرض ملاحظاته مثالاً مباشراً على الوظائف المتداخلة.

في امتدادات الأسماء المدوّلة، يوصف امتداد CORE بأنه مطابق نحوياً ووظيفياً لامتداد TANGO المقابل، لكنه يستعمل نطاق أسماء XML مختلفاً. وتتكرر الملاحظة نفسها لامتدادات الخصوصية لدى الجهتين.

الاختلاف في نطاق الأسماء ليس تجميلياً. فهو جزء من هوية الرسالة على السلك. عميل يرسل عناصر TANGO لا يضمن أن خادماً يدعم CORE سيفهمها تلقائياً. قد يدعم الخادم واحداً أو كليهما أو لا يدعم أياً منهما. وقد تختلف اختبارات المطابقة ودورات الإصدارات وجهة التحكم في التغيير ونطاق النشر.

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

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

خريطة تعايش تفصل أربع دعاوى

يبقى سجل IANA المصدر المرجعي لحقيقة التسجيل. أما قرار الدعم أو الانتقال فيحتاج طبقة تحليل إضافية أسميها «خريطة التعايش». إنها أداة يقترحها هذا المقال، وليست حقلاً رسمياً لدى IANA أو التزاماً في مشروع IETF.

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

يُسجل النشر بصورة محددة: أي خادم وعميل، وأي برنامج وإصدار وTLD وتاريخ. إذا كان الدليل زوجاً واحداً، يبقى الوصف «زوجاً واحداً». ولكل ادعاء تشابه مصدر واضح: ملاحظة IANA، أو قول المسجل، أو مقارنة مخططات، أو اختبار توافق، أو رصد إنتاجي. ويجب تحديد ما إذا كان التطابق يشمل الحقول الاختيارية والأخطاء أيضاً.

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

بهذا تبقى أربع جمل مستقلة: الامتداد مسجل؛ نُشر في مكان ما؛ تدعمه بيئتنا؛ يمكن أن يحل محل امتداد آخر في هذه الحالة. السجل يثبت الأولى مباشرة، ولا يحق له أن يتحدث باسم الثلاث الأخرى.

الحذف قد يمحو الدليل لا الاعتماد

يميّز المشروع بين الإدراج والتعديل والتعطيل والإزالة، ويطلب مبرراً لتغيير الحالة. إزالة مدخل نتج عن توافق IETF تتطلب موافقة IESG. ويمكن إزالة أو تعطيل مدخل غير تابع لـIETF من جانب IESG أو صاحب التسجيل الأصلي بالتعاون مع الخبراء.

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

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

ينسق السجل الحاضر، وتحفظ اللقطات المؤرخة القدرة على تفسير الماضي. من دون الاثنين تصبح البساطة الحالية ديناً على التحقيقات المقبلة.

المصادر