الخلاصة

  • عرّف RFC 2056 مخططين، z39.50s وz39.50r، لأن الإشارة إلى جلسة بحث ليست هي الإشارة إلى استرجاع سجل بعينه، ولكل مسار شروط تشغيلية مختلفة.
  • في z39.50r لا يصبح docid هوية عالمية للسجل: إنه رمز معتم يعرّفه الخادم ويُستخدم في بحث Type-1 يجب أن تكون حصيلته سجلًا واحدًا بالضبط.
  • الحالة المسجلة اليوم لـ z39.50s وz39.50r في IANA وثائقية؛ فلا تثبت انتشارًا فعليًا أو دعمًا برمجيًا أو استمرار مورد بعينه.

عنوانان لأن المقصد يسبق الأجزاء المعتمة

صدر RFC 2056 في نوفمبر 1996 على مسار Standards Track وبحالة Proposed Standard. كان هدفه محددًا: تعريف مخططات URL لاستخدام Z39.50، وهو بروتوكول للاستعلام عن قواعد بيانات بعيدة لا تنحصر عمليته الطبيعية في طلب واحد وإجابة واحدة. فالاستعلام العام يمكن أن يجري ضمن جلسة ذات حالة محفوظة، ويمر بعدة خطوات، ويتوقف انتظارًا لمعلمات إضافية. ومقدار مشاركة المستخدم في هذه الدورة يعتمد على البرنامج العميل.

هذه الخاصية تفسر وجود مخططين. لم يجعل RFC كل شيء يبدو كعنوان وثيقة ساكنة، بل استخدم z39.50s وz39.50r كي يستطيع العميل تمييز المقصد قبل تفسير الأجزاء المعتمة من العنوان. الأول يقود إلى سياق بحث قد يستمر تفاعليًا؛ والثاني يضيق المسار نحو استرجاع سجل وفق إجراء محدد.

في z39.50s يكون المضيف إلزاميًا، والمنفذ اختياريًا وقيمته الافتراضية 210، وما عداهما اختياري. يبدأ العميل جلسة مع المضيف والمنفذ نفسيهما أو يعيد استخدام جلسة قائمة إليهما. إذا وُجد docid وجب وجود قاعدة بيانات أيضًا، ويُنفذ بحث بصيغة الاسترجاع. وإذا غاب docid فقد تُعامل المعلمات الأخرى، بحسب العميل، كمتطلبات أو تفضيلات أو تلميحات يمكن تجاهلها. وفي جميع الأحوال تُترك الجلسة مفتوحة للمستخدم، لأن المحدد قد يكون بداية تفاعل لا نهايته.

أما z39.50r فيفرض المضيف وقاعدة البيانات، مع المنفذ الافتراضي 210. ولا يحدد RFC معنى المخطط عند غياب docid. وعندما يوجد، يكون docid رمزًا معتمًا يعرّفه الخادم، لا اسمًا عالميًا يمكن تفكيكه لاستنتاج هوية الكائن. يُدرج كمصطلح وحيد في استعلام Type-1 بالصيغة العامة، مع الوسم 45، ومع Bib-1 بحيث تكون Use=docid وStructure=URx. ويجب أن يساوي عدد نتائج Search واحدًا. إذا لم يتحقق ذلك فالعملية غير ناجحة، ولا يحدد RFC سلوك التطبيق بعدها. لا توجد رخصة للاختيار التقريبي أو انتقاء سجل تعسفيًا.

قد يصل السجل الوحيد داخل Search Response نفسها؛ وإن لم يصل، يُستكمل الحصول عليه بعملية Present. وبعد الاستلام يمكن للعميل إغلاق الجلسة أو الاحتفاظ بها. وهكذا يصبح «الوصول إلى سجل» سلسلة متميزة من الوقائع: تفسير المخطط، الاتصال، اختيار قاعدة البيانات، بناء الاستعلام، اختبار التفرد، ثم التسليم.

السجل المحلي ليس الصيغة المرسلة

يفصل RFC 2056 بين سجل قاعدة البيانات المحلي، والسجل المجرد المشترك، والسجل الذي يُصدَّر فعليًا عند الاسترجاع. هذا الفصل مهم لأن اختيار محتوى السجل واختيار طريقة تغليفه ليسا قرارًا واحدًا.

تحدد elementset العناصر المنطقية المراد تضمينها. إذا لم تُعطَ esn يختار العميل؛ وإذا أُعطيت فتُستخدم في small/medium-set-element-set-names ضمن Search أو لاحقًا في Present بحسب مسار الاسترجاع. أما recordsyntax فتحدد الصيغة التي تُعبَّأ بها العناصر. إذا غابت rs يختار العميل، وإذا حضرت قائمة من الصيغ فمن المفضل استخدام أول صيغة يدعمها بوصفها PreferredRecordSyntax.

ولذلك تمثيل نحوي دقيق. تسمح قواعد BNF بقواعد بيانات مفصولة بعلامة +، ثم ?docid اختياري، ثم ;esn=، ثم معلمة واحدة ;rs= يمكن أن تضم عدة قيم لصيغ السجل مفصولة بعلامة +. ليست البنية تكرارًا لمعلمة ;rs=. ويستند النحو العام للـURL إلى RFC 1738.

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

قابلية التمثيل وحدود الاستدلال

يوثق RFC 1729 مشكلة أوسع من تلك الحقبة: مخاطر التشغيل البيني في تمثيل المعلومات. نقل البيانات لا يضمن وحده أن الأنظمة تتشارك المعنى أو تستطيع تمثيل البنية نفسها بلا خسارة. وفي سياق RFC 2056 يوضح ذلك لماذا يستحق elementset وrecordsyntax أن يُعاملا كقرارين منفصلين: ما يختاره النظام من عناصر، وكيف يرمزها للتسليم، يؤثران في الصورة التي يتلقاها الطرف الآخر.

ولا ينبغي خلط هذا التصميم بسياق WAIS في RFC 1625. هناك استُخدم استعلام نصي Type-3، وكانت النتائج تُحذف لتحقيق معالجة بلا حالة محفوظة، ولم تُستخدم Present. التشابه التاريخي في تقنيات البحث لا يجعل آلية WAIS هي آلية z39.50r؛ فاختلاف نوع الاستعلام والاحتفاظ بالنتائج ومسار التسليم اختلاف تشغيلي جوهري.

حين لا يعني «الاسترجاع» عملية آمنة

يتضمن RFC 2056 تحذيرًا أمنيًا لافتًا. فقد لا يعود محدد المورد يشير إلى العنصر الذي كان مقصودًا أصلًا، كما أن عملية تبدو كاسترجاع غير مؤذٍ وقابل للتكرار قد تؤدي لدى نظام بعيد إلى عملية ضارة. أي أن مظهر الطلب لا يثبت أن أثره البعيد قراءة فقط.

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

ماذا تقول السجلات العامة اليوم؟

في البيانات الوصفية العامة المتاحة حاليًا يظهر RFC 2056 بوصفه وثيقة Standards Track من نوفمبر 1996، بحالة Proposed Standard، وضمن مسار Legacy. ولا يظهر ارتباط صريح بوثيقة تحدّثه أو تجعله متقادمًا. هذه أوصاف وثائقية وليست قياسًا للاستخدام الحالي.

وبالمثل يسجل IANA كلاً من z39.50s وz39.50r بحالة Permanent، بينما يسجل z39.50 بحالة Historical. استمرار التسجيل لا يعني حركة مرور قابلة للقياس، ولا دعمًا في العملاء الحاليين، ولا توصية تشغيلية، ولا إقرارًا بأن خادمًا أو قاعدة بيانات محددين ما زالا متاحين.

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

من العنوان إلى النتيجة: سلسلة لا تختصر إلى هوية

يمكن قراءة RFC 2056 كسلسلة من الملاحظات المنفصلة: المخطط يعلن المقصد؛ المضيف والمنفذ يحددان جهة الاتصال؛ قاعدة البيانات تضيق مجال البحث؛ docid يدخل كرمز محلي معتم في استعلام مضبوط؛ عدد النتائج يختبر شرط التفرد؛ elementset يختار العناصر؛ recordsyntax يحدد تغليفها؛ وSearch Response أو Present يسلّمان النتيجة.

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

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

المصادر