الخلاصة

  • تسمح RFC 9083 بأن يحمل كائن RDAP سلسلة port43 تتضمن اسم مضيف خادم WHOIS أو عنوان IP قد يوجد عليه ذلك الكائن.
  • يسجل الحقل عنوان خدمة؛ ولا يثبت أن الخدمة متاحة، أو أن السجلات متكافئة، أو أن العميل سينتقل تلقائياً إلى WHOIS.

بدأ WHOIS كطريقة قصيرة للسؤال عن الأشخاص والمنظمات على الشبكة. شرحت RFC 812 خدمة NICNAME عام 1982، ثم سجلت RFC 954 عام 1985 تشغيلها لدى SRI-NIC. يرسل العميل سطر استعلام واحداً، ويرد الخادم بنص مقروء ثم يغلق الاتصال. كان من الممكن توسيع قواعد البحث بمرور الوقت؛ بل إن النجمة قد تطلب قائمة مستخدمي منظمة أو مضيف. أفادت هذه الطريقة القارئ البشري، لكنها لم تُصمم كواجهة مستقرة للمعالجة الآلية.RFC 812؛ RFC 954

وصفت RFC 3912 لاحقاً WHOIS بأنه بروتوكول بسيط للطلب والرد عبر TCP على المنفذ 43. يتكون الطلب من سطر، وينهي الخادم الرد بإغلاق الاتصال. ولا يحدد البروتوكول نفسه ترميزاً للأحرف أو تدويلًا أو وسائل مصادقة قوية.RFC 3912 كانت خفته وانتشاره مفيدين، لكن العملاء احتاجوا غالباً إلى فهم قواعد البحث ومخرجات النص الخاصة بكل خدمة.

أما RDAP فيستخدم نموذجاً آخر: خدمات HTTP ومسارات استعلام متوقعة وردود JSON. تحدد RFC 7480 النقل وسلوك HTTP، بما يشمل إعادة التوجيه والتوطين. وتتناول RFC 7481 خدمات الأمان مثل التحكم في الوصول والمصادقة والسلامة. وتحدّث RFC 9082 أنماط الاستعلام، بينما تحدد RFC 9083 بنية رد JSON.RFC 7480؛ RFC 7481؛ RFC 9082

في القسم 4.7 من RFC 9083، port43 سلسلة JSON تمثل خدمة WHOIS. وقيمتها اسم مضيف أو عنوان IP وتشير إلى أن الكائن قد يوجد أيضاً على ذلك الخادم. وتوضح الوثيقة أن القيمة ليست URI، إذ لا يوجد مخطط URI لـWHOIS.RFC 9083 ليس هذا تغليفاً لـWHOIS داخل RDAP ولا دليلاً على اكتمال الانتقال. إنه يحتفظ داخل كائن منظم بإشارة إلى واجهة الاستعلام الأقدم.

لذلك ينبغي حصر الاستنتاج في وجود موقع خادم قد يصلح للاستعلام. لا يخبرنا الحقل إن كانت نقطة النهاية تعمل الآن، أو إن كانت بيانات WHOIS وRDAP متكافئة أو متزامنة، أو إن كان على العميل اتباع الإشارة. تحدد RFC 9083 صيغة البيانات ولا تقيس نشرها أو استخدامها لدى سجل بعينه. وجود الحقل في المعيار يثبت أن التوافق أُخذ في الحسبان كخيار؛ أما واقع التشغيل فيحتاج إلى تحقق منفصل.