الخلاصة

  • عرّف RFC 2079 السمة labeledURI الحساسة لحالة الأحرف ومتعددة القيم، والفئة المساعدة labeledURIObject التي يمكن إضافتها إلى قيد X.500 أو LDAP قائم.
  • فصلت مسافة غير مشفرة بين URI وتسمية بشرية اختيارية. وقد تعني القيم المتعددة موارد مترابطة مختلفة أو مواقع مختلفة للمورد نفسه، من دون نوع علاقة يميز الحالتين.
  • لم يكن تخزين العنوان إثباتاً لإمكانية الوصول أو الحداثة أو السلطة أو التكافؤ. ولم تكن التسمية HTML موثوقاً؛ حذر النص من إدراجها مباشرة في صفحة.

في 1997 كانت مجموعات مستقلة قد بدأت بالفعل بوضع عناوين URL في أدلة LDAP وX.500. لم يخترع RFC 2079 الرابط، بل وحّد اسم السمة وشكل القيمة لكي تتعرف التطبيقات المختلفة إلى البنية نفسها.

تبدأ القيمة بعنوان URI — وكان المطلوب آنذاك URL مطابقاً لـ RFC 1738 — ثم قد تأتي مسافات وتسمية سهلة للبشر. وبما أن URL لا يحتوي مسافة حرفية غير مشفرة، كانت أول مسافة من هذا النوع فاصلاً واضحاً. عرف التطبيق أين ينتهي العنوان من دون فهم الجملة.

التعدد أبقى سؤال العلاقة مفتوحاً

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

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

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

قابلية الإضافة لم تكن تفويضاً بالسلطة

كانت labeledURIObject فئة مساعدة مشتقة من top، لا تفرض حقلاً جديداً وتسمح بـ labeledURI. أمكن إضافتها إلى كائن قائم، كما أمكن لفئات أخرى أن تتبنى السمة مباشرة.

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

استخدم RFC 3296 الشكل نفسه لمراجع LDAP التابعة، لكنه أضاف وظيفة محددة: لم يستخدم ref التسمية، وحذفها مع الفاصل عند إنشاء الإحالة، واستخدم كل URI في القيم المتعددة، وأوصى ألا يتحقق الخادم الحافظ من سلامة المرجع. احتاج الشكل العام إلى وثيقة أخرى كي يصبح فعلاً بروتوكولياً.

عرض العبارة كان قرار تنفيذ جديداً

صممت التسمية للإنسان. لم يشجع RFC 2079 الحروف غير ASCII بسبب اختلاف تطبيقات ذلك الزمن، وفصل بين تمثيل X.500 وتهريب HTML. وكان تحذيره الأمني صريحاً: إدراج التسمية بلا معالجة في HTML قد يسمح بوسوم خبيثة تضلل قارئ الصفحة كلها.

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

لذلك يجب فصل القيد، والقيمة، وتحليل URI والتسمية، والتعدد، والعلاقة المدعاة، وصاحب الادعاء، واسترجاع الهدف، ومصدره وحداثته، والعرض الآمن، والقرار اللاحق. صحة الشكل لا تغطي سوى جزء من هذه السلسلة.

توحيد اسم السمة لم يوحد المعنى

عرّفت مسودة سابقة labeledURL. ألغى RFC 2079 التوصية بها لأن المجموعة فضلت سمة URI واحدة على سمتين، وأبقى التعريف القديم لمساعدة التطبيقات في الانتقال.

قلل القرار المفردات المشتركة، لكنه لم يمح القيم القائمة، ولم يثبت اكتمال الانتقال، ولم يضف أنواع علاقات. كما أن اتساع كلمة URI لم يجعل المخططات متبادلة.

الدرس محدود ودقيق: توحيد طريقة إلحاق مؤشر يتيح تبادله. لكنه لا يوحد سبب أهميته ولا حالته الحالية ولا مقدار الثقة في الكلمات المجاورة له.

المصادر