الخلاصة

  • نصّت RFC 742 على أن إرسال CRLF وحده يطلب من مضيف بعينه قائمة بمن يستخدمون ذلك النظام في تلك اللحظة.
  • انتقل الطلب عبر الشبكة، لكن المضيف هو الذي أنشأ الرد؛ ثم أوضحت RFC 1288 حق الموقع في رفض القائمة العامة واختيار الحقول الإضافية محلياً.

السؤال الفارغ كان موجهاً إلى مضيف واحد

لفهم Name/Finger، ابدأ بأقصر طلب ممكن. يتصل العميل بجهاز محدد، ويرسل محرفي العودة إلى السطر والسطر الجديد، ثم ينتظر. في مواصفة ديسمبر 1977، كان هذا السطر الفارغ يعني: اعرض الأشخاص الذين يستخدمون هذا النظام الآن. لم يكن الطلب يجوب شبكة ARPANET كلها، ولم يكن يستشير دليلاً مركزياً يقرر من يُعد حاضراً.

قدمت RFC 742، التي كتبها كين هارِنشتاين، واجهة شبكية لبرنامجي NAME وFINGER اللذين كانا يعملان بالفعل في SAIL وSRI وعدد من أنظمة ITS في MIT. وشبّهت الطلب الفارغ بأمر محلي لعرض حالة النظام، مثل systat في TOPS-10 أو TENEX. كان يمكن للقائمة أن تعرض الأسماء الكاملة ومواقع الطرفيات؛ كما عُدّ اسم المهمة ومدة الخمول إضافتين مفيدتين. أما السؤال عن مستخدم محدد فكان عملية أخرى: يمكنه عرض جلسته الحالية، أو، بعد تسجيل خروجه، وقت آخر مغادرة وخطة نصية كتبها المستخدم.

هنا يتغير حجم السؤال. يبدأ طلب الاسم بحساب يعرفه السائل مسبقاً، بينما يطلب السطر الفارغ من المضيف أن يكشف مجموعة من المستخدمين. سهّل البروتوكول نقل هذا السؤال، لكنه لم يجعل الإجابة سجلاً موحداً. تقول RFC 742 إن الرد يختلف باختلاف النظام، ولا تفرض تنسيقاً واحداً. وتعرض أمثلتها طرفيات وغرفاً ومهاماً ومدداً من عدم النشاط؛ وهي توضح ما ورد في الأمثلة، لا ما كانت جميع الخوادم تعرضه.

تقرير قابل للقراءة لا يثبت الهوية

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

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

جاء التوضيح بعد انتشار البرامج القائمة

لم تبدأ المرحلة التالية بإعادة تصميم كاملة. سعت RFC 1194، المنشورة في نوفمبر 1990، إلى توضيح الاتصال من دون إبطال التطبيقات الكثيرة القائمة أو إضافة قيود غير ضرورية. وقالت إن أكثر التطبيقات انتشاراً آنذاك بدت مستمدة أساساً من عمل BSD UNIX في بيركلي. هذا تقدير مؤرخ، لا إحصاء لعدد عمليات النشر. وأدخلت RFC 1196، المنشورة في ديسمبر من العام نفسه، تصحيحات وتوضيحات طفيفة. ثم حلّت RFC 1288، في ديسمبر 1991، محل الوثائق الثلاث السابقة.

أصبح الطلب الفارغ أكثر تحديداً بوصفه طلب {C} لقائمة جميع المستخدمين المتصلين. كان على البرنامج البعيد أن يجيب أو يرفض بوضوح. وإذا أجاب، وجب أن يورد الاسم الكامل على الأقل؛ وينبغي أن يستطيع المسؤول اختيار الحقول الأخرى. كما أتاحت فقرة الأمن رفض القائمة العامة، ونبّهت إلى أن معلومات المستخدمين قد تكون حساسة. وذكرت RFC 1288 مثالاً لتطبيق يعرض أوقات الدخول وقراءة البريد وحالة الرسائل غير المقروءة واسم آخر مرسل. يبيّن هذا المثال مساراً محتملاً للإفصاح، ولا يصف كل المضيفين.

كان تحكم المسؤول حقيقياً، لكنه لم يلغ المخاطر. يستطيع المضيف المستهدف تشغيل الخدمة أو رفض طلب القائمة العامة أو تقليل الحقول. وناقشت RFC 1288 أيضاً الهجمات على التنفيذ، ومنها دودة موريس؛ وهذا مسار مختلف. فالخلل الذي يتيح تنفيذ التعليمات أو اختراق الخادم ليس هو الخدمة السليمة التي تعيد معلومات اختار مشغلوها نشرها.

السؤال أصبح مشتركاً والرد بقي محلياً

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

لا تخبرنا هذه الوثائق بعدد المواقع التي شغلت Finger، ولا بتواتر الطلبات الفارغة، ولا باستخدام المسؤولين لخيارات الرفض، ولا بمدى حداثة كل رد. إنها توثق خدمة وتطور مواصفاتها، لا انتشارها الكلي. والاستنتاج التاريخي الأكثر أماناً محدد: منذ 1977 أمكن لطلب شبكي بسيط أن يجعل تقرير مستخدمي مضيف واحد متاحاً عن بعد؛ وبحلول 1991 وصفت المواصفة رفض القائمة واختيار الحقول محلياً بوصفهما جزءاً من التحكم بالخدمة.

المصادر