أعاد الخادم علامة زائد، لكن الرسالة لم تُرَ بعد: RFC 1312

الخلاصة

• عرّف RFC 1312 في عام 1992 خدمة تجريبية للرسائل القصيرة فوق TCP وUDP؛ وحقول المستخدم والطرفية فيه ترشد محاولة التسليم ولا تثبت حضور إنسان محدد.
• في خدمة TCP تعني + نجاح التسليم إلى مستخدم أو طرفية ما، لكن RFC يقيد ذلك صراحة: قد يكون الأمر مجرد استدعاء ناجح لخدمة محلية لتسليم الرسائل.
• لا يحدد النص هل يرتبط الإقرار بالتسليم المحلي أو بعرض نافذة أو بتأكيد المستخدم بعد قراءة الرسالة. ولذلك فالحالة الإيجابية ليست دليلا على القراءة.

التحليل

عنوان الطرفية لم يكن رصدا لشخص

صدر RFC 1312 في أبريل 1992 بوصفه بروتوكولا تجريبيا لإرسال رسالة قصيرة إلى مستخدم عند طرفية على مضيف. يبدأ شكل الرسالة بثمانية بتات للمراجعة، ثم حقول منتهية بصفر للمستلم وطرفية المستلم والنص والمرسل وطرفية المرسل وملف تعريف الارتباط والتوقيع. وحده الكلي لا يتجاوز 512 ثمانية بتات. إلا أن اختصار الشكل لم يحسم موضع وصول الرسالة في العالم البشري.

إذا كان حقل المستلم فارغا، جاز أن تُسلَّم الرسالة إلى أي مستخدم في النظام المقصود. وإذا كانت الطرفية فارغة، اختار النظام الطرفية «الصحيحة»، وهو اختيار يصفه RFC بأنه معتمد على ذلك النظام. وتدل النجمة في حقل الطرفية على جميع الطرفيات. وإذا كان الحقلان فارغين، فينبغي كتابة الرسالة على console، أي موضع يرجح أن يراه مشغّل أو مدير. هذه تعليمات مفيدة لخدمة تستقبل الطلب. لكنها ليست ملاحظة تقول من كان أمام جهاز، وأي شاشة اختيرت، وهل وصل النص إلى انتباه أحد.

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

لعلامة الزائد نطاق محدد

في الخدمة المعتمدة على TCP ينشئ العميل الاتصال ويرسل الرسالة، ثم يعيد الخادم حرفا واحدا: + أو ، مع تفسير اختياري. تعني الزائد أن الرسالة سُلّمت بنجاح إلى مستخدم أو طرفية ما، وتعني الناقص أنها لم تُسلَّم إلى أي طرفية. ذلك فرق عملي حقيقي لحالة المكوّن الذي يولده.

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

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

صمت UDP وملف تعريف الارتباط يجيبان عن أسئلة أخرى

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

لذلك لا يحمل الصمت معنى فشلا واحدا. قد يكون ناتجا عن سياسة متعمدة لكبح الردود، لا عن عدم نجاح التسليم وحده. وجعل كل غياب لجواب UDP في عداد «غير المسلَّم» يضيف إلى البروتوكول يقينا لا يمنحه.

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

خانة التوقيع لم تحسم الهوية

إذا كانت SIGNATURE فارغة فلا يمكن، حسب RFC، التحقق من هوية المرسل. وإذا لم تكن فارغة فهي ترميز نصي غير حساس لحالة الحروف لرمز أمني، من دون أن تعرّف المواصفة ترميزه أو تفسيره. إن وجود الخانة يترك مكانا لرمز محتمل، ولا يؤسس وحده دعوى مكتملة للتحقق من الشخصية.

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

القيمة التاريخية في اسم النجاح باسمه الضيق

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

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

المصادر

• RFC 1312 — Message Send Protocol 2

RFC 1312 مواصفة تجريبية من عام 1992؛ ولا يثبت مستلما حقيقيا أو عرضا أو قراءة أو موافقة أو هوية أو نشرًا أو نتيجة.