الخلاصة

  • خصص RFC 1408 في خيار Telnet رقم 36 القيمتين VAR=0 وVALUE=1، ثم وثّق RFC 1571 أن تنفيذ BSD المرجعي كان يفسر العلامتين بالترتيب المعاكس.
  • حاول RFC 1571 تمييز قاموس الطرف الآخر من علامات غير جائزة وترتيبها وفراغها وعددها والأسماء المعروفة، لكنه أبقى حالات لا تكفي فيها الأدلة.
  • أبقى RFC 1572 تعيين المواصفة المكتوب ونقله إلى الخيار الجديد 39، NEW-ENVIRON. وحتى بعد زوال غموض القراءة، ظل للخادم أن يهمل المدخل أو يستبدله أو يطبقه.

البايت لا يحمل معه قاموس منشئه

نشر RFC 1408 في يناير 1993 ليتيح نقل معلومات البيئة عند إنشاء اتصال Telnet. حمل ENVIRON رقم الخيار 36. داخل التفاوض الفرعي كانت IS=0 وSEND=1 وINFO=2، ثم قسمت العلامات VAR=0 وVALUE=1 وESC=2 وUSERVAR=3 الأسماء والقيم والمحارف المحجوزة.

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

لذلك يغير عكس الصفر والواحد حدود التركيب كله: ما يراه محلل بداية اسم يراه آخر بداية قيمة.

بعد عام شرح RFC 1571 أصل المشكلة. قال إن تعريفَي VAR وVALUE في RFC 1408 معكوسان قياساً إلى تنفيذ BSD. ووصف BSD بأنه التنفيذ المرجعي الذي كان ينبغي للـRFC أن يوثقه، وبأنه أساس لكثير من التنفيذات القائمة.

لا تقدم هذه العبارة إحصاء انتشار أو أسماء أجهزة. حدودها أوضح من ذلك: صار للخيار 36 تاريخان تشغيليان، ولم يعد الرقم وحده يحدد كيف سيقرأ النظير الصفر.

حاوية عامة لمعلومات لا يحتاج Telnet إلى فهمها

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

حدد RFC 1408 المتغيرات المعروفة USER وJOB وACCT وPRINTER وSYSTEMTYPE وDISPLAY. أما USERVAR فحمل الأزواج التي يقترحها المستخدم. كانت العلامة توثق فئة المصدر، لا صدقه. أشار النص إلى أن التنفيذ الحذر قد يعامل الفئتين بالقدر نفسه من الشك، وترك تصادم الاسم المعروف واسم المستخدم لقرار التنفيذ.

الوضع الافتراضي هو عدم التبادل: WONT ENVIRON وDONT ENVIRON. يعلن طرف بـWILL استعداده للإرسال، ويعلن الآخر بـDO استعداده للاستقبال. لا يبدأ SEND إلا طرف DO، ولا يرسل IS أو INFO إلا طرف WILL.

بهذا فصل التصميم بين الاستعداد والطلب والواقعة. لا يثبت WILL أن متغيراً أرسل. ولا يثبت SEND أن متغيراً موجود. كان IS جواب البداية، أما INFO فيستطيع الإعلان تلقائياً عن تغير لاحق. ولا يثبت أي منهما أن الخادم أدخل القيمة في حالته.

الوصول قبل تسجيل الدخول لا يمنح ثقة

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

نص RFC 1408 على أن المضيف المستقبل غير ملزم بوضع كل المتغيرات المستلمة في البيئة. يستطيع إهمال اسم مجهول، أو استخدام USER وACCT في اختيار حساب من دون نسخهما إلى العملية، أو تفضيل معلومة حصل عليها من مصدر أدق.

إذا كان خيار Terminal-Type قد حدد نوع الطرفية، أمكن للخادم تجاهل USERVAR TERM=xterm. وإذا تعارض DISPLAY مع خيار X-Display-Location، اقترح النص استعمال المعلومة الأحدث. تختلف سياسة الحسم، لكن موضعها واحد: عند المستقبل.

إذن كان USER اسم الحساب الذي يرغب فيه العميل، لا هوية مصادقاً عليها. ولم يكن لـPRINTER آنذاك تنسيق شبكي موحد للاسم، فلا يثبت وجود طابعة أو إذن وصول أو طباعة. ولا يثبت فك DISPLAY اتصال X أو ظهور نافذة.

حذّر قسم الأمن من المتغيرات التي تضبط قبل الدخول. قد يتيح متغير يؤثر في برنامج تسجيل الدخول أو المصادقة نفسه تجاوز البرنامج أو اختراقه. لم يوثق RFC حادثة بعينها؛ عيّن الحد بين مدخل بعيد والسلطة المحلية التي تمنحه أثراً.

حوّل RFC 1571 المخالفة النحوية إلى قرينة

لم يتضمن الخيار القديم حقلاً يعلن نسخة القاموس. لذلك استعمل RFC 1571 شكل الرسالة.

في SEND لا يجوز إلا VAR وUSERVAR. فإذا صادف العميل علامة يسميها قاموسه VALUE، رجح أن الخادم يعكس الصفر والواحد. ومن تلك النقطة يعكس تفسير بقية الطلب وصياغة جوابه IS أو INFO. أما إن لم يظهر الصفر أو الواحد، فلا توجد قرينة، فيفترض التعريف المنشور.

كان عمل الخادم أصعب لأن IS وINFO يحتويان قيماً مشروعة. ظهور VAR أولاً يرجح ترتيب RFC، وظهور VALUE يرجح الترتيب المعكوس. وإذا بدأت الرسالة بـUSERVAR أمكن للعلامتين أن تأتي كل منهما في تركيب جائز. عندئذ يبحث المحلل عن علامتين متتاليتين أو علامة فارغة، ويقارن الأعداد، ثم يفحص إن كانت السلاسل تشبه أسماء معروفة.

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

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

منح الرقم 39 المعنى الجديد مساحة نظيفة

في يناير 1994 أبقى RFC 1572 VAR=0 وVALUE=1، لكنه وضع القواعد تحت رقم جديد هو 39 باسم NEW-ENVIRON. أوضح أن الرقم الجديد يسمح للتنفيذات بالتشغيل البيني من دون غموض.

لو أعيد نشر جدول الخيار 36 لما عرف النظير أي ثنائي قديم يعمل بعيداً عنه. أما التفاوض على 39 فيختار رقماً جديداً وقاموساً واحداً في الوقت نفسه. لم تزعم المعالجة أن السجل يملك البرامج السابقة؛ أنشأت طبقة مشتركة حتمية للمتبنين لاحقاً.

يحفظ سجل IANA لخيارات Telnet الإدخالين منفصلين: 36 لـEnvironment Option المرتبط بـRFC 1408، و39 لـNew Environment Option المرتبط بـRFC 1572. يثبت السجل التخصيص، لا تنفيذ مضيف أو نجاح تفاوض أو وصول متغير إلى عملية.

وبقي NEW-ENVIRON معطلاً افتراضياً ومشروطاً باتفاق الاتجاهين. كما بقي للمستقبل أن يختار مصدراً أدق أو يهمل المدخل. صار معنى السلك مشتركاً، ولم تصبح نتيجة التشغيل مركزية.

فك الرسالة يقع في منتصف سلم الدليل

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

لم تعدّل المواصفة BSD. ولم يثبت التفاوض الإرسال. ولم يصادق USER على شخص. ولم يثبت قبول المدخل أن العملية ورثته. ولم تثبت البيئة تنفيذ أمر أو نتيجة. لكل انتقال سجل مستقل.

المصادر

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