الخلاصة

  • اقترحت RFC 933 خيار Telnet رقم 27، OUTMRK، كي يرسل الخادم شريطاً أمنياً مرة واحدة ويحافظ عليه User-Telnet خارج مساحة التطبيق.
  • يثبت WILL وDO قبول استعمال الخيار؛ أما الشريط المحدد فيظل بحاجة إلى ACK أو NAK، ويتولى الطرف المستقبل ترتيب الشاشة.
  • لا يثبت ACK صحة المستوى أو تصريح المستخدم أو السماح بفعل أو سلامة تشفيرية أو استمرار ظهور الشريط على الشاشة الحقيقية.

نشرت S. Silverman في يناير 1985 وثيقة RFC 933، وكان موضوعها حافة الشاشة. ربطت بعض البنى العسكرية مستوى أمنياً بكل وصلة Telnet واحتاجت إلى إظهار شريط مناسب. وكانت الطريقة الجارية تضع التنبيه ضمن بيانات كل شاشة من التطبيق.

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

ما زال سجل IANA لخيارات Telnet يربط الرقم 27 باسم Output Marking. يثبت السجل تخصيص الرقم فقط، ولا يثبت التنفيذ أو الانتشار أو صدق المستوى المكتوب.

قبول الآلية لا يعني قبول أي نص

وفق RFC 854، يعرض WILL OUTMRK إرسال معلومات العلامة ويقبل DO OUTMRK استقبالها. ويرفض WON'T وDON'T، ويظل عدم التبادل هو الوضع الافتراضي.

بعد الاتفاق يرسل الخادم IAC SB OUTMRK CNTL data IAC SE. يحدد CNTL الموضع وتحمل data نص ASCII. ثم يرسل العميل ACK، وقيمته ASCII 6، إن كان النص مرضياً، أو NAK، وقيمته 21، إن اعترض.

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

تفصل RFC 855 بين الاتفاق على مناقشة المعلمات وبين تبادلها داخل SB/SE. لذلك فـ DO وACK الخاص بالشريط والسماح بأمر داخل التطبيق ثلاثة أحداث لا حدث واحد.

صار العميل حارساً لحد متحرك

بعد ACK كان على User-Telnet ترجمة أوامر المؤشر كي يبقى خرج التطبيق في المساحة المتبقية. ترك D الموضع للعميل، وحدد T الأعلى وB الأسفل. وسمّى L وR اليسار واليمين، لكن الوثيقة تركت معناهما الدقيق بلا تعريف.

فصل CRLF أسطر الشريط، وأتاح ASCII Group Separator جمع علامات متعددة. بقي التموضع مسؤولية المستقبل. وقد يغطي تغيير حجم النافذة أو أمر المسح أو خلل المحاكي الشريط بعد ACK صحيح؛ لذا لا تثبت الحزمة حالة الشاشة.

ينهي الخادم العلامة بـ WON'T. ويمكن للعميل طلبها بـ DO ثم الخروج بـ DON'T إن لم يتبع الاتفاق وصول البيانات. كان الرفض والإنهاء طريقين عاديين في البروتوكول.

وصف النص السياسة ولم ينفذها

استند دافع RFC 933 إلى معايير الأنظمة الموثوقة الأمريكية. تحتفظ NIST بنسخة رسمية من DoD 5200.28-STD صدرت في ديسمبر 1985 وحلت محل نسخة 1983 التي أشارت إليها RFC. هي سياق محدود وليست دليلاً على أن الخيار نفذ المعيار كله.

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

لم تعرف OUTMRK توقيعاً أو MAC أو حداثة أو ربطاً موثقاً بالقناة أو قاموساً لمستويات الأمن. يثبت التركيب الصحيح أن طرفاً اقترح نصاً كعلامة. ويحتاج صدقها إلى سلطة تعيّن السياق وربط صحيح بالجلسة ومسار عرض موثوق.

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

وفر الخادم التكرار ونقل الحيازة

توقف الخادم عن إعادة الرسم وتخمين ارتفاع الطرف البعيد. ورث العميل حفظ الشريط وحماية المساحة وترجمة المؤشر وتعدد العلامات وتغير الحجم. لم يختف العمل بل تغير صاحبه.

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

المصادر والحدود

تعتمد المقالة على RFC 933 وRFC 854 وRFC 855 وسجل IANA ونسخة NIST من DoD 5200.28-STD. لا تثبت المصادر انتشاراً أو دعماً حالياً أو مطابقة منتج أو جلسة سرية حقيقية أو عرضاً صحيحاً أو فهم المستخدم أو نتيجة تشغيلية.