الخلاصة

  • أتاح NAME/FINGER عام 1977 لمضيف بعيد طلب قائمة المستخدمين المتصلين أو معلومات عن شخص بالاسم.
  • كان الطلب قصيراً، لكن الرد قد يكشف الاسم وموقع الطرفية والخمول وآخر خروج أو رسالة تركها المستخدم.

سطر فارغ يكفي لطرح السؤال

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

وحّدت الشبكة طريقة السؤال لا طريقة عرض الشخص

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

في 1990 صار النشر قراراً تشغيلياً

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

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

وتحمل المواصفة الأولى آثار شبكة زمنها. يصف RFC 742 الاتصال بالمقبس 117 بالنظام الثماني، أي المنفذ 79 بالعشري، عبر ICP وإنشاء اتصالين من 8 بت. وفي 1984 صنف RFC 924 بروتوكول Finger اختيارياً وأشار إلى الحاجة لتعديلات كي يعمل مع TCP. وظل تعريفه المختصر يركز على نشاط المستخدم الحالي أو الأحدث.

في يونيو 1990 أبقت محاضر اجتماع IAB/IETF على RFC 742 مؤقتاً كمعيار مقترح موروث، وكلفت المجموعة بالحصول على وثيقة أفضل وإعادة النظر فيه. وصدر RFC 1194 في نوفمبر. أراد توضيح التبادل من دون كسر التطبيقات القائمة، التي استند كثير منها إلى BSD Unix في بيركلي. كما وصف معلومات المستخدم بأنها حساسة وناقش رفض الطلبات والملفات المكشوفة والبرامج القابلة للتنفيذ وسجلات التدقيق.

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

المصادر الأولية