الخلاصة

  • قالت RFC 3494 إن تنفيذاً مستقلاً يلتزم RFC 1777 لن يتوافق مع تطبيقات LDAPv2 القائمة، لأن الصيغ والدلالات المنتشرة كانت قد ابتعدت عن النص.
  • نقل LDAPv2 ووثائقه التابعة إلى Historic أعاد توجيه التطوير نحو LDAPv3، لكنه لم يوقف الخوادم القديمة، كما أن رقم الإصدار وحده لا يثبت المصادقة أو السلامة أو السرية.

قد تبدو الحماية سبباً بسيطاً للاستبدال: بروتوكول قديم يفتقد خصائص، وخليفة يقدمها. غير أن RFC 3494 تكشف أن الانتقال لم يكن مفتاحاً ثنائياً. LDAPv2 لم يوفر سلامة البيانات أو سريتها، ولم يدعم الآليات الحديثة التي سمتها الوثيقة، مثل DIGEST-MD5 وKerberos V ومفاتيح X.509 العامة. أما RFC 1777 فوصفت simple bind يحمل كلمة مرور واضحة وخيارات من Kerberos 4.

جمعت RFC 3377 مواصفة LDAPv3 مع وثائق المصادقة وأمن طبقة النقل لمعالجة ملاحظة IESG السابقة. ثم أعادت RFC 4510 تنظيم الحزمة، وشرحت RFC 4513 طرق المصادقة وآليات الأمان. لكن هذه الإمكانات تحتاج إلى اختيار وتشغيل: قناة محمية، آلية مناسبة، تحقق من الاعتماد، ثم سياسة تفويض. طلب الإصدار 3 في Bind لا يثبت أن أياً من ذلك حدث.

قبل الأمن كانت هناك مشكلة أعمق في معنى الامتثال نفسه. قيدت RFC 1777 أحرف LDAPString بـ IA5، وأكملت RFC 1778 تمثيلات الصيغ المرتبطة وسياق T.61. أما المنتجات العاملة فكانت، وفق RFC 3494، تستخدم ISO 8859-1 أو UCS-2 أو UTF-8 أو مجموعة المحارف المحلية.

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

أظهرت أسماء السمات الانقسام في أصغر صورة. طلبت RFC 1777 الاسم النصي في X.500؛ فالمعرف 2.5.4.10 يمثل بـ organizationName. لكن تطبيقات LDAPv2 القائمة استخدمت غالباً الاسم القصير o من مخطط LDAPv3. دخل عرف الخليفة إلى السلف قبل إعلان تقاعده.

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

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

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

انتشر التقاعد عبر التبعيات أيضاً. اعتمدت RFC 1781 على صيغ تسمية في RFC 1779 أزالتها RFC 2253. وطبقت RFC 2559 LDAPv2 على مستودعات PKIX، فاعتمدت RFC 1777 وحدّثت RFC 1778. لذلك أوصت RFC 3494 بنقل هذه المجموعة ونواة LDAPv2 والأسلاف RFC 1484 و1485 و1487 و1488 إلى Historic.

Historic حالة وثيقة، لا قراءة من جهاز. تعرف RFC 2026 المستوى للمواصفة التي استبدلت أو اعتبرت متقادمة. وتحذر RFC 2400 من أن الكلمة الواحدة مجرد مؤشر يحتاج إلى بيان التطبيق. أوصت خطوة 2003 المطورين بألا يبنوا LDAPv2 من RFC 1777، وبأن يختار الناشرون LDAPv3. لكنها لم تغلق منفذاً، ولم تحذف برنامجاً، ولم تقس ما بقي من حركة.

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

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

المصادر