الخلاصة

  • ميّزت RFC 1861 بين معالجة الأمر، وتوافر جهاز النداء، ووضع الرسالة في الطابور، وتسليمها إلى الجهاز، ومشاهدتها، والرد عليها، والوصول إلى حالة نهائية.
  • طلب ACKRead إشعاراً عند المشاهدة مستقلاً عن الرد، فيما أتاحت Message_Tag وPass_Code وMSTAtus ورقم تسلسلي متزايد متابعة التحول بعد انتهاء الاتصال.
  • بقيت دقة الحالات محكومة بحدود واضحة: الوثيقة Informational، ولا تناقش الأمن، وتترك بعض سياسات التشغيل والحفظ للمزود، كما تحفظ الخلاف حول بروتوكول مستقل بدلاً من استخدام بنية البريد الإلكتروني القائمة.

لحظة النظر كانت واقعة شبكية مستقلة

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

وضعت RFC 1861 أمراً مخصوصاً لهذا الحد. عند تفعيل ACKRead يُطلب من الجهاز أن يرجع إشعاراً عندما يشاهد المشترك الرسالة المستلمة فعلاً. ثم تقول المواصفة إن هذه الخاصية مستقلة عن الرد الحقيقي.

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

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

طريق العودة غيّر زمن البروتوكول

بدأ SNPP أبسط من ذلك. عرضت RFC 1568 في يناير 1994 نسخة مبكرة أحادية الاتجاه. ثم استبدلتها RFC 1645 في يوليو بالنسخة الثانية. وفي أكتوبر 1995 جعلت RFC 1861 تلك النسخة قديمة وأضافت المستوى الثالث للأجهزة ثنائية الاتجاه.

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

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

يفتح 2WAY معاملة لجهاز واحد، ويطلق SEND الرسالة وينهي مرحلة الإرسال، ثم يعود العميل لاحقاً إلى MSTAtus. لم يُطلب من الإنسان أن يعمل بسرعة السلك؛ المطلوب أن يظل ما حدث قابلاً للاستعلام.

البوابة لا تعرف كل ما في السلسلة

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

في الوضع الثنائي يضيف PAGEr تمييزاً آخر. يعني 850 أن الوحدة على الشبكة وأن المعاملة قُبلت. ويعني 950 أنها غير متصلة لكن الرسالة ستوضع في طابور للتسليم اللاحق. أما 750 فيرفض المعاملة عندما لا تكون الوحدة متاحة.

هذه النتائج ليست درجات تجميل للنجاح نفسه. مع 850 يمكن متابعة المسار الحالي. ومع 950 يقرر المرسل هل الانتظار مقبول. ومع 750 يعرف أن عليه البحث عن وسيلة أخرى. إذا اختصرتها الواجهة كلها في «قُبل الطلب» فقد احتفظت بنحو الرسائل وأضاعت معناها التشغيلي.

قوة البوابة هنا محدودة بما تراه. قبول المدخل لا يمنحها سلطة إعلان وصوله إلى الإنسان.

أربع عائلات تقيس البعد عن النهاية

رتبت المواصفة نتائج الاتجاهين بحسب نهائيتها. تشير 86x إلى أن الرسالة الأولية سُلّمت لكن فعلاً مطلوباً ما زال منتظراً. وتشير 87x إلى تقدم وسيط بانتظار الإغلاق. أما 88x فنهائية، و96x تعني أن المعاملة في الطابور.

قد يعيد SEND الرمز 860 للتسليم مع انتظار إقرار القراءة، أو 861 للتسليم مع انتظار جواب، أو 880 للتسليم حين لا يوجد رد معلق، أو 960 لوضع الرسالة في طابور التسليم.

تضيف استعلامات الحالة وقائع لاحقة. 870 يعني أن الرسالة وصلت وقُرئت لكن الرد ما زال مطلوباً. 881 يعني وصلت وقُرئت. يحمل 888 جواباً من خيارات معدة، ويحمل 889 نصاً كاملاً. ويسجل 780 انتهاء المهلة قبل التسليم.

تقول الوثيقة إن حالة 88x تغلق المعاملة ولا يتغير السجل بعدها. لذلك لا يجوز لعميل أن يعرض 860 كأنه نهاية، لأن القراءة المطلوبة لم تحدث. ولا يجوز أن يعرض 960 كتسليم، لأن الطابور مجرد وعد بالمحاولة.

لم تصنع الأرقام الحقيقة. لقد منعت كل مرحلة، إذا احترمتها البرمجيات، من استعارة اسم المرحلة التالية.

الرد ليس تفويضاً

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

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

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

رفض الانتظار قد يكون النتيجة الأصدق

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

يُرسل NOQUEUE قبل PAGEr ليمنع التخزين في هذه المعاملة. إذا كانت الوحدة غير متصلة، يعيد الخادم رفضاً من فئة 750. بذلك يظل قرار قيمة الوقت عند الجهة التي تعرف سياق الرسالة. لا يحتاج الخادم إلى تخمين الأهمية؛ عليه فقط احترام عدم الإذن بالانتظار.

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

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

وسم ورقم سري، لا منظومة أمن كاملة

يعيد SEND الناجح في الاتجاهين Message_Tag وPass_Code. وصفت الوثيقة الأول بأنه محدد موقع للسجل، والثاني بأنه رقم PIN عشوائي يجيز فحصه. تستخدمهما MSTAtus لجلب الحالة.

يحمل السجل أيضاً Sequence يرتفع عندما تتغير الحالة، مع التاريخ والوقت. يستطيع العميل بذلك التمييز بين قراءة جديدة وتكرار حالة قديمة. الرقم دليل على تغير معلن، وليس وعداً بسجل غير قابل للتعديل أو بساعات متطابقة في كل المكونات.

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

كلما احتوى السجل على قراءة ورد ومكان صار أكثر حساسية. الدقة تزيد واجب الحماية؛ لا تقوم مقامه.

يمكن إثبات الوجود من دون كشف الموقع

يستطيع PING معرفة موقع الوحدة أو حالتها. واعترفت الوثيقة بحساسية المكان، فأتاحت للمشترك اختيار جواب عام: الوحدة موجودة على النظام، ولا تتوافر معلومات موقع. سُمي هذا ACLU mode وأُعطي الرمز 821.

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

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

النشر حفظ الخلاف ولم يحسمه

سجل المؤلف أن أعضاء في IESG ومجموعة «822 Extensions» فضلوا استخدام بنية البريد الإلكتروني الموجودة. كان نشر بروتوكول جديد مكلفاً، بينما كان البريد واسع الانتشار. رأى بعض المراجعين أن إعداد العملاء والخوادم بعناية يمكن أن يحقق شرط «سلّم فوراً أو افشل». وقبل آخرون وظائف خاصة بالنداء لكنهم فضلوها امتدادات لـSMTP.

دافع المؤلف عن بروتوكول منفصل يعزل تفاصيل TAP/IXO وخلفائه عن المستخدمين وطرائق البريد. ويمكن أن تصل بوابات البريد إلى SNPP. كان النزاع حول موقع التعقيد وتكلفة النشر، لا حول حقيقة واحدة ألغت كل البدائل.

تحفظ صفحة RFC Editor الوثيقة بوصفها Informational. جعلها النشر ثابتة وقابلة للتنفيذ والنقد، ولم يثبت انتشارها الشامل أو يمنح IETF سلطة فرضها على المشغلين.

السجل الموثوق أصغر من الواقع

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

جعل RFC 1861 هذا النقص صريحاً ومفيداً. يمكن أن تكون الرسالة «وصلت إلى الجهاز» و«لم يقرأها الشخص» في آن واحد. ويمكن أن تكون مقروءة والرد ما زال مفتوحاً. ويمكن أن تنتهي قبل التسليم من دون تحويل الفشل إلى نجاح متأخر.

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

المصادر