الخلاصة

  • وضع Network Virtual Terminal تمثيلاً وسيطاً محدوداً: CR LF لسطر جديد، وCR NUL لعودة العربة بلا نزول، ومنع CR المنفرد في NVT ASCII الافتراضي.
  • حمل البايت الواقع بعد CR دليل القرار، بينما احتفظ كل طرف بسلطة تحويل الفعل المشترك إلى عاداته المحلية.
  • عالج RFC 1123 غموض مفتاح Enter، وأوقف Binary تحويل نهايات السطور، ثم أبقى Net-Unicode على CRLF وضيّق الحاجة إلى CR NUL.

حركة لا تكتمل عند CR

في طابعة NVT تعيد Carriage Return موضع الطباعة إلى الهامش الأيسر في السطر نفسه. تنقل Line Feed الموضع إلى السطر التالي مع إبقاء العمود. وعندما تأتي الحركتان معاً ينتج فعل «سطر جديد» عند الهامش الأيسر.

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

اقترح RFC 318 سنة 1972 حلاً قابلاً للتنفيذ: احتفظ بـCR واقرأ الرمز التالي. يعني LF سطراً جديداً. وإذا أراد المرسل عودة العربة وحدها أرسل CR NUL. لا يحرك NUL الطابعة، لكنه يغلق الفرع ويثبت غياب LF.

هكذا صار «لا فعل» معلومة إيجابية في موضع محدد. لم يكن الصفر حشواً عاماً، بل نهاية لعبارة ثنائية البنية.

طرفية مشتركة نحيفة

جعل RFC 854 Network Virtual Terminal حالة البدء في اتصال Telnet. يحول كل host خصائص جهازه أو process المحلي إلى هذا النموذج المشترك، ثم يحول ما يستقبله إلى بيئته. لا يحتاج إلى قائمة بكل الطرفيات الممكنة عند الطرف الآخر.

حددت الطبقة المشتركة أقل قدر ضروري: NUL بلا فعل، وLF حركة عمودية، وCR عودة إلى اليسار. بقي عرض الشاشة وطول الصفحة والتحويل الحرفي والـbuffering في الأطراف.

أما موضع الغموض فحصل على قاعدة صارمة. يجب التعامل مع CR LF كرمز new line واحد عند قصد الفعل المركب، ويجب استخدام CR NUL عند قصد عودة العربة وحدها، وتجنب CR في غير ذلك داخل NVT ASCII الافتراضي. وتسري القاعدة في الاتجاهين.

عند استقبال CR NUL تُحذف NUL قبل تحويل فعل NVT إلى الترميز المحلي. فهي جزء من التمثيل الشبكي في هذه الطبقة، وليست بالضرورة byte يجب أن يصل إلى التطبيق. لكن هذا لا يسمح بحذفها في mode آخر.

مفتاح Enter لم يكن اسماً بروتوكولياً

بقي سؤال الإدخال البشري: ماذا يرسل User Telnet عندما يضغط المستخدم Return أو Enter؟ هل يريد فعل نهاية السطر أم يريد CR حرفياً لتطبيق يعمل character by character؟

وثّق RFC 1123 أن بعض clients أرسل CR LF وبعضها أرسل CR NUL، وأن الاختلاف تحول إلى مشكلة توافق طويلة. على ASCII server صحيح يجب أن ينتج الشكلان، بوصفهما terminal input، أثر مفتاح نهاية السطر المحلي نفسه. أما host غير ASCII فقد يضطر إلى الاختيار بين حفظ CR منفرد وبين قبول clients قائمة.

فصل التوضيح بين الأدوار. يجب أن يستطيع User Telnet إرسال CR LF وCR NUL وLF. ويستحسن على ASCII client أن يتيح اختياراً للمستخدم وأن يجعل CR LF الوضع الأولي لمفتاح نهاية السطر. أما server output أو نص protocol آخر محمول داخل Telnet فيستخدم CR LF لنهاية السطر.

يظل server مسؤولاً عن التحويل إلى terminal driver المحلي. في raw mode قد يمرر CR إلى التطبيق؛ وفي formatted mode يطبق اتفاق السطر المحلي. المطلوب تكافؤ الفعل عند الحد، لا تطابق كل buffer داخلي.

Binary ينقل حق التفسير

تُتفاوض Binary option في RFC 856 لكل اتجاه على حدة. لا يبدأ الوضع إلا بطلب من طرف وموافقة الآخر. تصبح الـoctets العادية بيانات ذات ثمانية bits، لكن IAC يظل بداية command ويجب مضاعفته إذا كان قيمة 255 داخل البيانات.

يحسم RFC 1123 الأثر: لا توجد معالجة لنهاية السطر في Binary. لا يجوز استبدال CR بـCR NUL أو CR LF. فالخيار لا يضيف bit إلى NVT فحسب؛ بل يغيّر parser صاحب السلطة.

في NVT ASCII يبدأ CR قراراً ينتظر byte آخر. في Binary تبقى CR وLF وNUL بيانات للتطبيق. حذف NUL لأنه جاء بعد CR يفسد stream، وإضافته بدافع «التصحيح» يفسده أيضاً.

لهذا يجب أن تحتفظ المراقبة بالـoctets والاتجاه وحالة التفاوض معاً. النص المرئي بعد التحويل لا يكفي لإثبات أن المكوّن الصحيح هو الذي اتخذ القرار.

Linemode نقل التحرير ولم يستول على الإخراج

أعطى RFC 1184 client قدرة تحرير السطر محلياً لتقليل الرحلات على الروابط البطيئة. عند تشغيل EDIT يرسل line terminator المحلي المعتاد على هيئة CR LF.

عند إيقاف EDIT تُرسل carriage return كـCR NUL، وline feed كـLF، والمفتاح الخاص الذي يعني اكتمال السطر كـCR LF. ويظل server مسؤولاً عن إخراجه: CR LF للسطر الجديد، وCR NUL للعودة وحدها، وLF للنزول وحده.

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

ورث Unicode السطر وتراجع عن حركة الطابعة

راجع RFC 5198 تاريخ NVT ASCII عند تعريف Net-Unicode. اختار UTF-8 وأبقى CRLF تمثيلاً لنهاية السطر، كما أبقى القيد البنيوي بأن يلي CR إما LF أو NUL.

لكنه أوصى بتجنب CR NUL. وفرت Unicode والـmarkup بدائل عن overstriking وتنسيق الطابعة القديم، وصار NUL خطراً في برامج تعدّه نهاية string. تراجعت فائدة عودة العربة المنفردة، بينما بقي CRLF عميقاً في التوافق المركب.

لا يجعل ذلك الاختيار الأول خطأ. لقد حل CR NUL غموضاً حقيقياً في نموذج كان يتعامل مع الحركة. وحين تغير نموذج النص، أمكن تضييق الاستثناء مع حفظ الحد المشترك.

يسجل IANA Telnet Options registry Binary وLinemode وخيارات carriage-return. التسجيل دليل على الأرقام والمراجع، لا على الانتشار الحالي أو مطابقة المنتجات.

التطبيع المبكر يمحو صاحب القرار

وزع Telnet السلطة بوضوح: يختار المرسل فعل NVT، ويتحقق المستقبل من البايت المجاور، ويحول كل endpoint محلياً، ولا يتغير المفسر إلا بالتفاوض.

تبدأ الأعطال حين تقفز طبقة على هذا الترتيب. يوحّد gateway كل السطور قبل قراءة mode، أو تنهي مكتبة string عند NUL، أو يخزن السجل النص المعروض فقط. بعد إسقاط البايت لا تعيد النية البشرية بناء الدليل.

المصادر وحدود الإثبات

تثبت الوثائق النموذج والتصحيحات والحدود المتفاوض عليها والمفردات المسجلة. لا تقيس الاستخدام المعاصر، ولا تصادق على منتج، ولا تثبت اتفاق جميع التطبيقات التاريخية. يبقى معنى CR NUL محصوراً في mode واتجاه ووظيفة معلومة.