الخلاصة

  • بدأ RFC 1485 باسم مميّز معروف في ASN.1 وحوّله إلى نص؛ لم يبدأ باسم بشري ناقص للبحث عن قيد.
  • سمح بالفاصلة أو الفاصلة المنقوطة، وطيّ السطر، والاقتباس، وOID، والقيم الست عشرية، وRDN متعدد القيم.
  • رفضت مواصفات LDAP اللاحقة وجود سلسلة معيارية وحيدة؛ فالمساواة تتبع schema وقواعد المطابقة، أما الثقة فتحتاج أدلة أخرى.

حين خرج الاسم من البروتوكول

وصف RFC 1485 حاجة لا تتعلق بعملية بحث جديدة. كان الدليل OSI يستخدم Distinguished Name مفتاحاً لقيد ويشفّره في ASN.1، لكن المستخدمين احتاجوا إلى تبادله في رسالة أو على بطاقة عمل. تسجل صفحة RFC Editor نشره في يوليو 1993 وتصنيفه الحالي Historic.

كان DN معلوماً قبل كتابة السلسلة. أما RFC 1484 فكان يحاول حل purported name بشري داخل بيئة دليل متغيرة. لذلك لا تتكرر الأطروحتان: 1484 يملك البحث السياقي، و1485 يملك عبور البنية إلى النص.

الطريق المألوف وطريق الاستثناء

سعى التنسيق إلى الوضوح والعمومية مع سهولة القراءة. أعطى الأنواع الشائعة مفاتيح قصيرة مثل CN وO وOU وL وST وC. وإذا لم يوجد مفتاح مألوف أمكن استخدام OID منقط؛ وإذا تعذر عرض القيمة طبيعياً أمكن استخدام الترميز الست عشري. سمّى النص هذا المخرج ugly وتوقعه للحالات المرضية.

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

الورقة سطّحت نوعين من الترتيب

ظهر RDN الأكثر تخصيصاً أولاً. فصلت الفاصلة أو الفاصلة المنقوطة بين RDNs، وسمحت المسافات والأسطر بتنسيقات مختلفة، وحمت علامات الاقتباس والـescape المحارف الخاصة. جمع + عدة AVAs في RDN واحد.

لكن RFC 4512 يوضح أن DN تسلسل من RDNs، في حين أن RDN نفسه مجموعة AVAs غير مرتبة. ترتيب RDN يحمل مساراً في الشجرة؛ تبديل AVAs داخل RDN لا يصنع هوية أخرى. السلسلة الخطية تعرض النوعين معاً ولا تلغيهما.

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

تغيرت القواعد وبقيت الحاجة إلى النسخة

تظهر صفحة RFC 1779 ونصه الكامل أنه حل محل 1485، وحسّن escape وحذّر من خلط الفواصل. نقل RFC 2253 الصيغة إلى LDAPv3 وUTF-8؛ وتوثق صفحته انتقالها لاحقاً. يحدد RFC 4514 مع سجله الصيغة الحالية في LDAP.

تعني هذه السلسلة أن حفظ النص وحده غير كافٍ. يجب حفظ إصدار الصيغة، وترميز المحارف، وسجل descriptors، وschema. قد يقبل parser فاصلة منقوطة ويرفضها آخر؛ وقد يفسر اسم نوع قصير وفق سجل مختلف.

كما يتوقع RFC 4514 أن تترجم واجهة المستخدم أسماء الأنواع إلى اللغة المحلية. النص الظاهر على الشاشة ليس بالضرورة النص البروتوكولي الذي تتبادله الأنظمة.

المطابقة عملية وليست صورة

يقول RFC 4514 صراحة إنه لا يعرّف canonical string واحدة لـDN. يعطي خوارزمية موصى بها، لكنه يسمح بمخرجات مطابقة أخرى. وتنتقل المساواة إلى distinguishedNameMatch في RFC 4517.

تقارن القاعدة عدد RDNs ومواقعها، وتتجاهل ترتيب AVAs داخل RDN، ثم تستخدم قاعدة المساواة الخاصة بكل نوع attribute. يضيف RFC 4518 إعداد السلاسل الدولية: mapping وnormalization والمحارف الممنوعة ومعالجة المسافات. وقد تكون نتيجة مقارنة لازمة Undefined.

المقارنة الحرفية السريعة إذن سياسة أخرى. يمكنها تقسيم DN واحد إلى حسابين بسبب اختلاف العرض، أو دمج بنيتين متشابهتين قُرئتا تحت schema مختلف.

عرض CN=Sam لم يحفظ الأصل كله

يعرض RFC 4514 مثالاً لقيمتين تحملان Sam، إحداهما TeletexString والأخرى PrintableString. قد تصبح كلتاهما CN=Sam. لا تضمن السلسلة إعادة بناء BER أو DER نفسه. عندما يحتاج التطبيق إلى DER الدقيق، كما في استخدامات معينة لشهادة X.509، ينبغي أن يحفظ الشكل الست عشري.

هناك إذن ثلاثة مطالب: استعادة بنية DN، والحكم على مساواته، والمحافظة على octets الأصلية. لا يحقق العرض المقروء الثلاثة تلقائياً، ولا يصادق على مرسله.

القيد بقي خلف الاسم

يقرر RFC 4512 أن DN يشير بلا التباس إلى قيد في شجرة الدليل. يحتوي القيد attributes عن الشيء الذي يمثله. لكنه لا يثبت من أرسل السلسلة، ولا من يسيطر على القيد، ولا حداثة attributes، ولا صلاحية شهادة أو إذن عملية.

وقد تكشف DNs أسماء وعناوين ومواقع وانتماءات. يناقش RFC 4514 ضوابط التسمية والوصول، بينما قال RFC 1485 إن مسائل الأمن لم تناقش. المظهر المنظم ليس ضمان خصوصية.

تضع أفكار Heng Lu عن أولوية الكود العامل والحد الأدنى من المواصفة مع القرار المحلي وطبقات الواقع المسؤولية في مكانها: grammar تنقل البنية، وschema تعطي المعنى، والدليل يحفظ القيد، والتطبيق يصادق ويأذن ويسجل الأثر.

جعل RFC 1485 الاسم قابلاً للسفر. لم يجعل الورقة صاحبة السيادة على ما وراءها.

المصادر