الخلاصة
- عرّفت RFC 779 خياراً يسمح لبرنامج Telnet لدى المستخدم بتقديم وصف نصي لمكانه إلى الخادم البعيد، فوق اسم الموقع الذي جاء منه الاتصال.
- يبدأ الخيار معطلاً، ثم يأتي العرض والموافقة وإرسال النص وقرار الخادم بشأن عرضه؛ كل خطوة لها صاحب قرار مختلف.
كان البحث عن زميل عام 1981 عملاً يجمع بين الحاسوب والممرات. تسأل النظام عن المتصلين، فتحصل أحياناً على اسم الشخص ومكان الطرفية التي يجلس أمامها، وربما هاتف قريب. لكن إذا دخل زميلك من مؤسسة أخرى، فقد يعرف الخادم البعيد اسم تلك المؤسسة وحده. «إنه في المختبر الآخر» تذكرة سفر أكثر منه عنوان مكتب. لهذا اقترح Earl Killian في RFC 779 أن يرسل برنامج Telnet على جانب المستخدم وصف المكان الذي يعرفه إلى المضيف الذي يستضيف الجلسة.
كانت قوائم المستخدمين جزءاً من الحياة اليومية للحواسيب المشتركة. وصفت RFC 742 الخاصة بـ NAME/FINGER استعلاماً يُظهر المتصلين، مع أسمائهم الكاملة والموقع الفعلي لطرفياتهم حين يمكن تحديده. وقد تظهر معه المهمة الجارية أو مدة الخمول. هذه معلومات عملية لمن يريد أن يمر على مكتب زميل أو يتصل به هاتفياً. أما الدخول عبر الشبكة فكان يُبقي لدى النظام المستضيف معلومة واسعة: موقع المؤسسة التي نشأ منها الاتصال. بين المؤسسة والمكتب مسافة طويلة حتى لو وصلتها حزمة بيانات في لحظة.
سمّى Killian الإضافة SEND-LOCATION ومنحها رقم الخيار 23 في Telnet. تبدأ المفاوضة على حالتي WON'T وDON'T، أي إن إرسال المكان ليس هو الوضع الابتدائي. إذا عرف العميل وصف المكان، يستطيع أن يعرض WILL SEND-LOCATION. يرد الخادم الراغب في تلقيه بـ DO SEND-LOCATION، ويمكنه أيضاً طلبه بـ DO. بعد الاتفاق، يرسل العميل سلسلة من أحرف ASCII القابلة للطباعة داخل تفاوض فرعي يبدأ بـ IAC SB وينتهي بـ IAC SE. ما ينتقل هنا وصف يقدمه جانب المستخدم؛ الغاية أن يعرف الخادم ما يستطيع الشخص أو آلته قوله عن مكان الجلوس.
لأفعال Telnet القصيرة أثر حقيقي. يستطيع جانب الإرسال أن يقول WON'T، ويستطيع الطرف الآخر أن يقول DON'T. ويمكن للخادم أن يطلب النص ويرفض العميل الطلب. وبعد الاتفاق، قد تصل العبارة في وقت لاحق من الجلسة. لذلك لا يكفي النظر إلى اتصال المستخدم للحكم بأن الموقع أصبح لدى الخادم. عليه أن يُعرض أولاً، وأن يلقى قبولاً، وأن يصل النص بالفعل. ثم تأتي مهمة برنامج الخادم: هل يُدرج العبارة في قائمة المتصلين، وكيف؟
عرفت الشبكة فكرة شبيهة قبل هذا الاقتراح. في RFC 734 عن بروتوكول SUPDUP، يوجد أمر يرسل نصاً يحدد مكان وحدة التحكم إلى النظام البعيد. كان ذلك النظام يحفظه عادة ليستعمله في قائمة who. حملت RFC 779 الحاجة نفسها إلى نظام خيارات Telnet. الجهاز القريب من المستخدم يعرف العبارة، والجهاز البعيد يدير سجل من يستخدمه. وكانت المفاوضة جسر التسليم بينهما.
ثمة فرق بين وصف القائمة ووصف الطريق الذي يغذيها. NAME/FINGER تحدثت عن معلومات يمكن أن تعرضها قائمة الأشخاص؛ SEND-LOCATION قدمت وسيلة لإيصال إحدى تلك المعلومات أثناء جلسة Telnet. ذكرت RFC 779 نظام ITS مثالاً لنظام يمكنه الاستفادة منها. يبقى شكل العرض من شأن الخادم المحلي. قد يستلم النظام عبارة ثم يقرر أين يضعها في واجهته. الكود، مثل موظف الاستقبال، يحتفظ بدفتره الخاص.
في النهاية، أعطى الخيار معنى بشرياً لبيان تقني صغير. اسم المؤسسة يصلح لتوجيه الاتصال إليها. اسم الغرفة أو الهاتف القريب يصلح لتوجيه شخص إليها. بين المهمتين وضع RFC 779 عرضاً وموافقة ونصاً قصيراً. صار بإمكان المضيف أن يعرف عن زائره أكثر من اسم المبنى، إذا اختار الزائر أن يعطيه العنوان وإذا اختار المضيف أن يستخدمه. شبكة طرفيات تحولت، لوهلة، إلى دليل يساعد على طرق الباب الصحيح.
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات





