الخلاصة

  • خصصت RFC 884، الصادرة في ديسمبر 1983، الرقم 24 لخيار TERMINAL-TYPE في Telnet. يفتح DO وWILL باب تبادل المعلومات؛ ويسأل SEND عن الاسم، ثم يحمله IS.
  • تستطيع الطرفية عرض اسم دقيق ثم اسم أعم عند تكرار السؤال. وتكرار الاسم الأخير ينهي القائمة. وفي 1985 اشترطت RFC 930 أن يأتي كل IS جواباً عن SEND حتى لا تختلط الرسائل المتقاطعة.

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

وضعت مواصفة Telnet الأساسية نقطة بداية مشتركة: «الطرفية الافتراضية الشبكية». يستطيع أي طرف أن يبدأ الحديث وفق صورتها المبسطة، ثم تفاوض الخيارات الإضافية عند الحاجة. وحين أراد Marvin Solomon وEdward Wimmers السماح بعرض أغنى من هذه اللغة المشتركة، كتبا RFC 884: ليطلب الحاسوب البعيد اسم الطرفية الموجودة لدى المستخدم.

أخذ الخيار الرقم 24. الوضع الأصلي هو DON'T وWON'T، فلا يتبادل الطرفان الاسم. يطلب أحدهما السماح بإرسال DO، ويعرض الآخر الاستعداد بإرسال WILL. بعد ذلك تأتي الرسالة التي تحمل السؤال نفسه: SEND، ورقم أمرها الفرعي 1. تأتي الإجابة IS، ورقمها 0، ومعها اسم مكتوب بسلسلة NVT ASCII. عرضت المواصفة المثال IBM-3278-2، وساوت بين الحروف الكبيرة والصغيرة في مقارنة الأسماء.

تسرد الوثيقة أسماء كثيرة من عالم IBM ومن بيئات TOPS20 وUnix؛ نجد فيها DEC-VT100 وTELETYPE-33 إلى جوار أجهزة أخرى. لقد وصلت الشبكة نفسها إلى مكاتب تختلف تجهيزاتها اختلافاً شديداً. يمكن للخادم أن يمرر الاسم إلى برنامج محلي يعرف كيف يخاطب الجهاز، فيستخدم التحكم بالمؤشر أو اللون عندما تكون هذه القدرات متاحة. أشارت المواصفة أيضاً إلى خيار BINARY في هذا السياق.

ثم تظهر مشكلة تعترف بها كل دفاتر الأسماء: الناس يختلفون على كتابة الاسم. ساق المؤلفان IBM3278-2 وIBM-3278/2 مثالين قد يربكان طرفي المحادثة. لا يحمل البروتوكول رداً سلبياً خاصاً يقول «لا أعرف هذه التسمية». عوضاً عن ذلك، تستطيع الطرفية التي تملك اسماً دقيقاً وآخر أعم أن تبدأ بالدقيق، ثم تقدم الأعم عند السؤال التالي. فإذا نفدت الأسماء كررت آخر اسم. وعندما يسمع الخادم الإجابة ذاتها مرتين متتاليتين، يتوقف عن السؤال. لقد اختصر البروتوكول عبارة اجتماعية مألوفة: «هل يعرفك الناس باسم آخر؟»

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

سمحت صيغة 1983 للطرفية بأن ترسل IS من تلقاء نفسها بعد اتفاق DO وWILL. تصور المؤلفان أن تقاطع الإجابة مع سؤال متزامن سيؤدي، في أسوأ الأحوال، إلى وصول المعلومة مرتين. وجدت RFC 930 عام 1985 مأزقاً أدق: قد يعبر الجواب المبادر والسؤال الطريق في وقت واحد، ثم يبدو الجواب التالي اسماً ثانياً بدلاً من كونه جواب السؤال. صار الدور واضحاً: يُرسل IS استجابةً إلى SEND فقط.

وفي RFC 1091 عام 1989، اتسع تبادل الأسماء ليشمل التنقل بين أوضاع محاكاة طرفيات متعددة. أما مشهد 1983 فبقي أبسط: حاسوب بعيد يريد أن يحسن معاملته لشاشة لا يراها. بدأ بسؤالها عن اسمها، وأعاد السؤال عندما احتاج اسماً يعرفه.