الخلاصة

  • جمع RFC 1959 موقع خادم LDAP والاسم المميز والسمات المطلوبة ونطاق البحث والمرشح في عنوان محمول، وكانت الحقول المحذوفة تستدعي قيمًا افتراضية.
  • أمكن حذف اسم المضيف، ولم يوجد حقل لبيانات الاعتماد. لذلك أمكن تنفيذ السلسلة نفسها عبر خوادم وجلسات وسياسات وصول مختلفة.
  • وصف العنوان نية البحث، لكنه لم يثبت التنفيذ المختار أو اكتمال النتيجة أو صلاحية أي إجراء لاحق.

حصل السؤال على غلاف قابل للنقل

قُدِّم LDAP بوصفه وصولًا أخف إلى دليل X.500. أراد RFC 1959 أن يمنح عملاء الإنترنت وصولًا مباشرًا إلى البروتوكول، وأوضح أن الصيغة تصلح أيضًا لخوادم LDAP المستقلة. لم تكن الإضافة حكمًا جديدًا من الدليل، بل غلافًا صغيرًا لعملية قائمة.

كان ترتيب المكونات ثابتًا: ldap://، ثم مضيف ومنفذ اختياريان، ثم شرطة مائلة واسم مميز، وبعده السمات والنطاق والمرشح مفصولة بعلامات استفهام. حدد المضيف خادمًا، والاسم قاعدة البحث، والسمات الحقول المطلوبة، والنطاق الكائن الأساسي أو مستوى واحدًا أو شجرة فرعية، والمرشح السجلات المطابقة.

للمرشح تاريخ مستقل؛ فقد وصف RFC 1558 تمثيلًا نصيًا لمحمول LDAP تنفذه الآلة. أما RFC 1959 فتناول الغلاف الذي نقل ذلك المحمول مع بقية المعلمات. لم يختر المرشح الخادم ولم يمنح الوصول، ولم يلغ عنوان URL قواعد المرشح الداخلية.

أدت المواضع الفارغة عملًا حقيقيًا

عند غياب المنفذ استُخدم TCP 389. وعند غياب قائمة السمات طُلبت جميع السمات. وكان النطاق الافتراضي base والمرشح الافتراضي (objectClass=*). أكملت هذه القواعد سؤال العميل؛ ولم تصف حالة الدليل.

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

في مثال University of Michigan للبحث في شجرة فرعية ظهرت علامتا استفهام متتاليتان. أبقى حقل السمات الفارغ sub والمرشح في موضعيهما. لذلك يجب أن يسجل التدقيق المكتوب وما فعّلته المواضع المحذوفة معًا.

احتفظ الاسم المميز والمرشح بقواعدهما، ورُمزت المحارف غير الملائمة للعناوين وفق RFC 1738. تصحح errata 528 الموثقة مرجع صيغة الاسم من RFC 1485 إلى RFC 1779. أتاح الترميز النقلي الحركة؛ ولم يجعل الاسم قانونيًا نهائيًا أو المرشح آمنًا أو الادعاء صحيحًا.

أبقى غياب المضيف الاختيار خارج السلسلة

لم تسمِّ الصيغة ldap:/// خادمًا. إذا كان السجل ضمن فضاء X.500، سمح RFC 1959 للعميل بالاتصال بأي خادم LDAP يملك وصولًا خلفيًا إلى X.500. حرر ذلك المرجع من آلة واحدة، لكنه لم يوثق خوارزمية الاختيار أو النسخة أو مشهد البيانات أو زمن الإجابة. لا تعني «أي» «جميع»، ولا تمنح ختم سلطة عالمية.

جعل RFC 2255 الفصل أوضح لاحقًا. عند غياب المضيف احتاج العميل معرفة سابقة بخادم مناسب. واستطاع فتح اتصال أو إعادة استخدامه، واختيار الأمن والمصادقة، وملء معلمات SearchRequest التي لا يحملها العنوان، مثل حدود الحجم والوقت وسياسة الأسماء البديلة.

لا ينبغي إسقاط هذه الإيضاحات اللاحقة على نص 1996. لم يحمل RFC 1959 خوارزمية اختيار خادم أو تاريخ اتصال أو حدود تنفيذ أو قرارًا بشأن الأسماء البديلة.

لم يحمل العنوان هوية

لم يوفر RFC 1959 طريقة لإدراج بيانات اعتماد، ولذلك توقع حل العنوان من دون مصادقة. قد يكون البحث المجهول خيارًا مقصودًا للبيانات العامة، لكنه لا ينشئ حقًا في كل معلومة طُلبت.

وصف اختيار السمات رغبة العميل. ظل الخادم يطبق ضوابط الوصول والقيود الإدارية. أوضح RFC 4511 لاحقًا أن السجل المعاد قد يضم بعض السمات المطلوبة فقط، أو لا يضم أي قيم.

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

بدأت النتيجة بعد السؤال

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

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

يشير RFC 4516، وهو معيار عناوين LDAPv3 الحالي، إلى أن الصيغة لا تستطيع التعبير عن كل معلمات SearchRequest. يبقى العنوان أصغر من العملية، وتبقى العملية أصغر من قرار النظام المستهلك.

من زاوية Minimum Initial Specification لدى Heng Lu، هذا الحد ميزة: واجهة مشتركة صغيرة تيسر التنسيق من دون أن تدعي سلطة دائمة. وتطلب Running-Code Primacy دليلًا منفصلًا للسلسلة والتفسير والاتصال والرسائل والفعل. جعل RFC 1959 السؤال يسافر، ولم يجعله صاحب سيادة.

المصادر والحدود

تظهر هوية الوثيقة في IETF Datatracker وصفحة RFC Editor. يتوفر النص في HTML ونص عادي، وتصحح errata 528 مرجع الاسم. يقدم السياق RFC 1777 وRFC 1558 وRFC 1738، وتشرح الحدود اللاحقة RFC 2255 وRFC 4511 وRFC 4516.

تعتمد القراءة التحريرية على Running-Code Primacy وMinimum Initial Specification وReality Layers لـ Heng Lu. ليست هذه المقالات دليلًا على تطبيق LDAP. تثبت المصادر المواصفات وحدودها المعلنة، ولا تثبت الانتشار الحالي أو توافق المنتجات أو محتوى دليل بعينه أو حادثة أو سياسة وصول أو قرار تطبيق.