الخلاصة
- عرّفت RFC 3367 نواة مشتركة للاستعلام عن خدمات الأسماء الشائعة، واكتشاف قدراتها، واستقبال النتائج والإحالات، وحفظ مصدر الخدمة ومجموعة البيانات.
- بقي اكتشاف المزود واختياره وتسجيل الاسم وملكيته وتفرّده خارج النطاق عمداً. اتفقت صيغة السؤال من دون أن يقرر البروتوكول المؤسسة المخولة بالإجابة.
في أواخر التسعينيات لم يعد شريط عنوان المتصفح مخصصاً لعناوين URL وحدها. كتب المستخدمون أسماء شركات وأشخاص وكتب وأماكن، وحولتها المتصفحات والبوابات إلى تنقل أو بحث. لكن ربط الأدلة المتخصصة كان يحتاج واجهات مختلفة.
اقترح Common Name Resolution Protocol واجهة موحدة. نشرت RFC 3367 سنة 2002 بوصفها Proposed Standard، وعرّفت رسائل XML للاستعلام عن روابط منشأة مسبقاً بين عبارات بشرية وموارد إنترنت. لم تنشئ DNS آخر ولا دليلاً عالمياً واحداً.
لم يفرض الاسم الشائع بنية نحوية. فهو لا يحمل بنية تعريف مثل URI، ولا يشترط أن يكون الربط فريداً أو دائماً مثل URN. وكان متوقعاً أن تستخدم خدمات متعددة العبارة نفسها لبيانات مختلفة.
يبدأ CNRP بعد اختيار الخدمة. يطلب العميل وصفها، ويتعلم الخصائص ومجموعات البيانات التي تدعمها، ثم يرسل الاستعلام. قد تحتوي الإجابة واصفات موارد ورسائل حالة وإحالات. ويستطيع وسيط تجميعي سؤال مزودين عدة مع إبقاء مصدر كل نتيجة.
كانت النواة الإلزامية صغيرة: الاسم، ومعرف محلي للخدمة، وURI للمورد، ووصف. أما اللغة والجغرافيا والفئة فكانت تلميحات بأفضل جهد. مقدار استجابة المزود لها فرق بين الخدمات، لا ضماناً لترتيب موحد.
لم يكن الاستعلام شرط SQL. يمكن للخدمة إعادة ما تراه الأقرب، والإفصاح عن تجاهل خصائص أو تعذر إحالة بحالة نجاح جزئي. وحّد المعيار الغلاف وبعض الدلالات، ولم يوحد التغطية أو التصنيف كله.
رسمت RFC 2972 الحد المؤسسي بوضوح. خرج اكتشاف المزود واختياره والإدارة والتسجيل والملكية وضمان الأسماء الفريدة من التصميم الأولي. يستطيع العميل الحديث مع وجهة اختيرت سلفاً؛ ولا يختارها البروتوكول.
هنا تدخل السلطة. قد يسأل متصفح دليلاً تجارياً ويسأل آخر خدمة إقليمية، ويرسلان العبارة نفسها ويستقبلان رابطين صحيحين مختلفين. يحفظ CNRP المصدر ولا يعلن جواباً عالمياً وحيداً.
في فضاءات الأسماء العامة، مثل أسماء الناس والأماكن والأعمال، لا توجد جهة تخصيص واحدة. ويمكن للخدمات تنظيم الموارد في تصنيفات مختلفة. وأقرت RFC 2972 بأن الكلمات الحرة للفئات لم تثبت قدرتها على تحقيق توافق كامل بين تلك التصنيفات.
جعلت RFC 3368 الحد ظاهراً في مخطط go:. صورة تحدد خادماً، وأخرى تحمل الاستعلام فقط إلى الخدمات المضبوطة في العميل. قد تعطي السلسلة نفسها على جهازين نتيجتين مختلفتين لأن اختيار المؤسسة لا يسافر دائماً معها.
كان بدء النقل أكثر تحديداً. على العملاء والخوادم العامة دعم HTTP على المنفذ 1096 للاتصال الأول، ثم تستطيع الخدمة إعلان وسائل أخرى. تحدد القاعدة كيفية الوصول إلى وجهة معروفة، لا كيفية اكتشافها أو سبب الثقة بها.
تضيف الإحالات اعتماداً جديداً. يمكن للخدمة تقديم بعض النتائج والإشارة إلى مزود آخر. وعلى العميل تذكر أزواج الخدمة ومجموعة البيانات لكشف الحلقات. وإذا غابت وجهة إحالة فقد تكون النتيجة نجاحاً جزئياً لا إجابة كاملة.
عاد الأمن إلى الحد نفسه. حذرت RFC 3367 من الوسيط وانتحال كائن Service وحجب الخدمة الناتج عن طبقة غير مباشرة جديدة. يمكن توقيع الكائن، لكن التحقق يحتاج مفتاحاً عاماً موثوقاً. بقي الحصول عليه خارج النطاق لأنه يعتمد على اكتشاف الخدمة.
تحمي التوقيعات القول بعد اختيار أصل الثقة، ولا تختار ذلك الأصل. الصلاحية التشفيرية والسلطة المؤسسية دليلان مختلفان.
يسجل سجل IANA الحالي go كمخطط Permanent ويحيل إلى RFC 3368، وتبقى RFC 3367 Proposed Standard. هذه حقائق حفظ معياري وليست تعداداً للمتصفحات أو الخوادم أو الحركة أو المستخدمين. كما أن توقعات RFC 2972 للسوق ليست قياس اعتماد.
تضع RFC 2396 وRFC 3986 إطار URI العام، وتبحث RFC 2276 وRFC 2483 في الحل حول URN، وتعرض RFC 3401 عائلة أخرى للاكتشاف بالتفويض. تحدد هذه النصوص سياق التجربة ولا تثبت أن آلية أزاحت غيرها في التشغيل.
يوفر مقالان لـ Lu Heng العدسة المعلنة. يشرح “Minimum Initial Specification” النواة المشتركة الصغيرة والقرارات المحلية اللاحقة؛ فقد وحّد CNRP التبادل لا السلطة. ويفصل “On Reality Layers” بين توافق البروتوكول وهوية الخدمة ومصدر البيانات والربط والوصول وقصد المستخدم.
اعترف التصميم بتعدد الأجوبة وحفظ المصدر والنجاح الجزئي وكشف الحلقات. لكن الشفافية لم تلغ قوة من يضبط قائمة الخدمات الأولى، إذ يحدد مجموعات البيانات القادرة على الإجابة قبل بدء التبادل الموحد.
هذه هي حدود RFC 3367 التاريخية: أمكن الاتفاق على طريقة السؤال. أما الاتفاق على صاحب الحق في الإجابة فاحتاج قرار حوكمة آخر لم يتخذه البروتوكول.
المصادر
- RFC 3367
- سجل RFC 3367 لدى RFC Editor
- سجل RFC 3367 لدى IETF Datatracker
- تاريخ RFC 3367 لدى IETF Datatracker
- RFC 3368
- سجل RFC 3368 لدى RFC Editor
- سجل RFC 3368 لدى IETF Datatracker
- RFC 2972
- سجل RFC 2972 لدى RFC Editor
- RFC 2396
- RFC 2483
- RFC 2276
- RFC 3401
- RFC 3986
- سجل مخططات URI لدى IANA
- Lu Heng: Minimum Initial Specification
- Lu Heng: On Reality Layers
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات
