الخلاصة

  • لم يضع RFC 3383 امتدادات LDAP كلها خلف بوابة واحدة؛ بل وزّع Standards Action ومراجعة الخبراء وSpecification Required وأسبقية الوصول والتجربة والاستخدام الخاص بحسب أثر التصادم.
  • أثبت التسجيل حدوث تنسيق، لا وجود تنفيذ أو ضمان أمان. جاءت قيمته من ربط المعرّف بمواصفة عامة ومسؤول ومسار للمراجعة والتغيير.

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

نُشر RFC 3383 في سبتمبر 2002 بوصفه BCP 64، وتعامل مع قابلية LDAP للتوسعة كمسؤولية حوكمة ذات أثر تقني. كان البروتوكول يسمح بعمليات جديدة، وامتدادات للعمليات القائمة، وschema قابلة للزيادة. بقي أن تُنظم أسماء هذه الإضافات حتى لا يشغل اختراعان الموضع العام نفسه.

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

كان في وسع مواصفة تطورها IETF أن تحصل على فرع OID واحد تحت Internet Directory Numbers بعد Expert Review مع Specification Required. وبعد منح الفرع، استطاعت المواصفة توزيع أرقام فرعية داخله من دون الرجوع إلى IANA لكل ورقة. نسّق السجل الفروع، بينما أدارت الوثيقة شجرتها المحلية.

استطاع المطورون الآخرون استعمال أي OID مفوض بصورة صحيحة، بما في ذلك Private Enterprise Numbers. وشُجعت الأعمال المبكرة على استعمال الفرع التجريبي حتى لا تتشبث النماذج الأولية بمعرّف النشر النهائي. لم يكن ينبغي إبقاء OID تجريبي في مواصفة منشورة.

اتخذت الآليات المعلنة في Root DSE مساراً أخف. أمكن تسجيل controls وextensions القابلة للاكتشاف وفق First Come First Served مع Specification Required. أما آلية Standards Track فكان تسجيلها يتطلب Standards Action. أتاح المسار الأول العثور على وصف تقني عام من دون الادعاء أنه معيار.

لا تمثل هذه السياسات درجات جودة. لا تفحص أسبقية الوصول الأمان. ولا تجعل Specification Required النص معيار IETF. ولا تثبت Standards Action أن برمجية ما نشرت الآلية. تحدد كل سياسة فقط مقدار الدليل والمراجعة اللازمين لاحتلال مساحة معينة.

كانت OID descriptors أسماء قصيرة غير حساسة لحالة الأحرف، وكان يمكن ربط أكثر من اسم بـ OID واحد. حجز الاسم المنتهي بشرطة عائلة كاملة. خُصص x- للاستخدام الخاص غير القابل للتسجيل، وe- للتجارب وفق أسبقية الوصول، واحتاجت الأسماء الأخرى إلى Expert Review.

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

كشفت نطاقات resultCode تدرج الحوكمة بالأرقام. احتاجت القيم 0–1023 إلى Standards Action، و1024–4095 إلى Expert Review مع Specification Required، و4096–16383 إلى First Come First Served مع كلمات e-. أما 16384 فما فوق وكلمات x- فكانت Private Use غير قابلة للتسجيل.

استخدمت أساليب الاستيثاق النطاقات نفسها، وأضافت تصنيف COMMON أو LIMITED USE أو OBSOLETE. لم يكن ممكناً تصنيف أسلوب بلا مواصفة عامة بأنه COMMON، ولم تُقبل إضافة جديدة تبدأ بوصف OBSOLETE. سجّل التصنيف الاستخدام المقصود ولم يكن إحصاءً لمدى الانتشار.

احتاج نوع رسالة LDAP جديد إلى Standards Action. قللت الرسائل القابلة للتوسعة الحاجة إلى تغيير الاختيار الأعلى في غلاف البروتوكول، لكنها لم تلغها. استحق تغيير البنية الأساسية احتكاكاً أكبر من تجربة محلية.

وأغلق RFC 3383 سجلاً قديماً من دون محوه. توقفت Directory Systems Names، المرتبطة بتمثيل distinguished names في LDAPv2، عن استقبال إضافات جديدة لأن LDAPv3 استخدم OID descriptors بصيغة مختلفة. كان على القائمة القديمة أن تبقى متاحة للتاريخ. إيقاف التخصيص لا يعني حذف الذاكرة.

جعلت الإجراءات السياسات قابلة للتطبيق. كان طلب Expert Review ينشر نموذجاً مكتملاً لأسبوعين من المراجعة العامة. وإذا عُدّل النموذج بدأ الأجل من جديد. أمكن للمشاركين الاعتراض؛ وكان الخبير يوافق ويرسل الطلب أو يرفضه، مع إمكان الاستئناف. أما طلبات First Come First Served فذهبت مباشرة إلى IANA.

تبعت الملكية مسار التسجيل. عُدّت IESG مالكة لقيم Standards Action، وعُدّ مقدم الطلب مالكاً عادة لقيم مراجعة الخبراء وأسبقية الوصول. خضعت التحديثات لقيود تماثل التسجيل الجديد. وإذا عجز المالك عن إصلاح ضروري أو رفضه، أمكن لـ IESG تولي السيطرة.

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

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

قدّم RFC 2434 مفردات سياسات التسجيل في ذلك الوقت، ثم حدّثها RFC 8126. وتُظهر صفحات IANA الحالية لمعاملات LDAP استمرار السجل العام، لكنها لا تثبت أن كل حقل بقي كما كان سنة 2002 أو أن كل قيمة نُفذت في منتج.

وضع RFC 3377 العمل في سياق LDAPv3 آنذاك. وقدمت RFC 2251 وRFC 2252 وRFC 2255 خلفية البروتوكول وschema وURL، ثم وصف RFC 4510 المجموعة المنقحة لاحقاً. يثبت هذا النسب الوثائقي التسلسل، لا التبني.

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

تكشف عدسة Lu Heng حول الحد الأدنى للمواصفة الأولية اقتصاد القرار: تحديد الأقسام والسياسات والنماذج والمالكين ومسارات الإصلاح، مع إبقاء كل امتداد مستقبلي في وثيقته المحلية. وتفصل طبقات الواقع بين التخصيص والتسجيل والمواصفة والتنفيذ والنشر والنتيجة. لا يثبت سطر في IANA إلا طبقة التنسيق.

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

المصادر