الخلاصة

  • عرّفت RFC 1096 ‏X-DISPLAY-LOCATION بوصفه خيار Telnet رقم 35. لم يفعل WILL وDO سوى السماح بنقاش لاحق، ثم نُقلت القيمة في إجابة IS على طلب SEND مضبوط الاتجاه.
  • اتبع محدد الموقع صيغة Unix DISPLAY ‏<host>:<dispnum>[.<screennum>]. كان على عميل Telnet تعديل صيغة محلية مثل :0 قبل إرسالها، لكن التعديل لا يصادق على المضيف ولا يثبت ملكية الشاشة أو إمكان الوصول إليها.
  • ظل على التطبيق البعيد إنشاء اتصال X مستقل واجتياز قائمة الوصول وآلية التفويض لدى خادم X. استلام العنوان، وقبول setup، وظهور نافذة للمستخدم ثلاثة أحكام مختلفة.

كان ينقص العملية البعيدة إحداثي محلي

يعمل عميل Telnet داخل بيئة X على محطة المستخدم. يدخل المستخدم إلى مضيف آخر ويشغّل هناك تطبيقاً رسومياً. صارت العملية في الجهاز البعيد، لكن الشاشة المقصودة ما زالت أمام المستخدم. ولا يلزم أن تعرف shell البعيدة قيمة DISPLAY التي تمنحها البيئة المحلية عادةً لبرامجها.

سدّت RFC 1096 هذه الفجوة في مارس 1989 بوصفها Proposed Standard. خصصت الرقم 35 لخيار X Display Location، بحيث يستطيع خادم Telnet أن يطلب من العميل موقع شاشة X التي يعمل تحتها. وما زال سجل خيارات Telnet لدى IANA يحتفظ بالرقم والمرجع.

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

منح WILL وDO إذناً للكلام فقط

الحالة الافتراضية هي WON’T/DON’T؛ لا يعلن تسجيل الدخول موقع الشاشة تلقائياً. وفق مفردات RFC 854، يعبّر WILL عن الاستعداد لتنفيذ خيار، ويطلب DO أو يؤكد أن ينفذه الطرف الآخر. في الخيار 35 يعني الأول استعداداً لإرسال الموقع لاحقاً، والثاني استعداداً لاستقباله.

تحد RFC 1096 معنى هذا الاتفاق بعبارة واضحة: الغرض منه تحصيل ومنح الإذن بنقاش مستقبلي. تقسم RFC 855 تفاوض الخيارات إلى مرحلتين؛ يتفق الطرفان أولاً على مناقشة المعلمة، ثم تمر القيمة نفسها بين SB وSE. ويمكن إنهاء التفاوض اللاحق بـWON’T أو DON’T.

إذن يثبت النجاح حالةً بين نظيرين في Telnet. لا يثبت صحة الاسم الذي سيأتي، ولا هوية المستخدم، ولا سياسة خادم X. السماح بالسؤال عن عنوان ليس إذناً باستعمال المورد الذي يشير إليه.

حدّد SEND وIS من يبدأ ومن يجيب

لا يحق إلا لمن أرسل DO أن يرسل SEND، ولا يحق إلا لمن أرسل WILL أن يرد بـIS. ولا يجوز للمورّد أن يدفع الموقع بلا طلب. هكذا تبقى الرغبة العامة في توفير القيمة منفصلة عن الكشف الفعلي عنها.

أخذت RFC 1096 هذا النسق من RFC 1079، خيار سرعة طرفية Telnet. أعادت استعمال حوار SEND/IS المطلوب بدلاً من اختراع آلة حالات جديدة. لكن تشابه الغلاف لا يوحد دلالة المحتوى؛ سرعة الطرفية خاصية، أما موقع X فيشير إلى خدمة أخرى ذات طريق وسياسة مستقلين.

في المثال تحمل IS السلسلة SRI-NIC.ARPA:0.0 بترميز NVT ASCII، ويبلغ طول أمر التفاوض الفرعي 22 ثُمانية. يثبت وصوله أن نظير Telnet صرّح بهذه السلسلة المنسقة. ولم يقع بعد أي اتصال X يمكن ملاحظته.

كان تعديل :0 ترجمةً لنطاق المعنى

صيغة Unix DISPLAY هي <host>:<dispnum>[.<screennum>] بلا مسافات أو محارف زائدة. تكفي محلياً صيغة :0 أو unix:0.0 لأن المضيف مفهوم من السياق. ولو قرأها المضيف البعيد كما هي، لصار معنى «محلي» هو الجهاز الخطأ.

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

قد تكون السلسلة صحيحة البنية وقديمة. وقد تكون دقيقة لكن يتعذر بلوغها. وقد يصل الاتصال إلى خدمة ترفضه. الصياغة والشبكة والسلطة طبقات أدلة منفصلة.

بدأ X باتصال ثانٍ

تصف RFC 1013 عميل X وهو ينشئ اتصال IPC مستقلاً بخادم X. عند استخدام TCP تقابل الشاشة ذات الرقم N المنفذ 6000+N. يساعد المضيف ورقم الشاشة الواردان من Telnet على اختيار هذه الوجهة.

لا يتحول تدفق Telnet إلى تدفق X. الخيار 35 ليس نفقاً ولا وكيلاً ولا آلية تحويل، ولا يحمل طلبات الرسم. يبدأ التطبيق البعيد، بصفته عميل X، مساراً جديداً يخضع لحل الأسماء والتوجيه والمرشحات وحالة الاستماع.

لهذا الفصل قيمة تشخيصية. وصول IS يثبت تسليم محدد الموقع. فشل TCP يقع في مرحلة الشبكة اللاحقة. رفض setup يأتي من طبقة X. أما اختزال الجميع في عبارة «تعطل Telnet» فيمحو المكان الذي نشأ فيه العطل.

بقي باب القبول لدى خادم X

يتضمن setup لاتصال X اسم بروتوكول تفويض وبيانات التفويض، إلى جانب معلومات الإصدار وترتيب البايتات. يستطيع الخادم الرفض مع سبب، أو القبول وإرجاع معلومات عن الشاشات والصيغ والموارد. وتترك RFC 1013 اختيار آلية التفويض الصالحة خارج قلب البروتوكول.

كما تصف الوثيقة قائمة تحكم بالوصول حسب المضيف. يستطيع خادم X رفض العميل وفق قواعده الخاصة. لا يحل اتفاق WILL/DO محل هذا القرار.

يفصل سجل IANA الحالي بين X Display Location بوصفه الخيار 35 وTelnet Authentication بوصفه الخيار 37. يساعد هذا التصنيف المعاصر على منع وصف الخيار 35 بأنه مصادقة، لكنه لا يثبت أن الخيار اللاحق استُخدم معه في منظومة سنة 1989.

سلم الأدلة متدرج. يسمح WILL/DO بالتفاوض الفرعي. يثبت SEND/IS تسليم السلسلة. يثبت نجاح TCP مساراً إلى endpoint. يثبت قبول setup أن X أجاز الاتصال وفق ما طبقه من ضوابط. ولا تثبت هذه المراحل أن التطبيق أنشأ النافذة المطلوبة.

بقيت نتيجة الإنسان بعد قبول الاتصال

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

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

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

عبر العنوان Telnet. أما حق الدخول إلى الشاشة فظل قراراً يخص X.

المصادر