الخلاصة

  • ينقل ملف RAW في RFC 3195 رسائل syslog المعروفة عبر BEEP، الذي يضمن تسليماً موثوقاً ومرتباً ضمن كل قناة؛ أما COOKED فيضيف مُدخلات مهيكلة ورداً إيجابياً أو سلبياً لكل مُدخل.
  • يثبت كل إيصال نطاقاً مختلفاً. فوصول إطار أو ظهور <ok/> لا يثبت وحده مصدر الحدث أو حفظه الدائم أو فهرسته أو استجابة تشغيلية.

قد تبدو كلمة «موثوق» أوسع من الضمان الذي يحدده البروتوكول. نُشرت RFC 3195 في نوفمبر 2001 ضمن مسار Standards Track، وربطت syslog بإطار BEEP الموجّه للاتصال. ويكشف الملفان عن مفاضلة تصميمية. يركز RAW على قلة التعقيد والتوافق مع الإصدارات السابقة: يحتفظ بتمثيل رسائل syslog المألوف، بينما يوفر BEEP تسليماً موثوقاً ومرتباً داخل القناة الواحدة. ويستخدم COOKED عمليات مهيكلة تسمح بالرد ok أو error على كل entry. يتعلق الرد بالتبادل البروتوكولي، لا بكل مرحلة تالية في نظام التسجيل. (RFC 3195 §§1, 3.1, 4.4.2)

ينبغي فصل إيصالات سلسلة الأدلة. يرسل المصدر حدثاً؛ ويستلم نظير BEEP الرسالة كاملة؛ ويمكن لمستقبِل COOKED قبول المُدخل أو رفضه؛ ثم قد يحلله الجامع أو يكتبه أو يفهرسه أو ينسخه، وقد ينشئ تنبيهاً. هذه تحولات حالة مختلفة. تحدد RFC 3195 النقل وتبادلات الملفات، لكنها لا تنشئ معاملة تخزين عامة. وحتى <ok/> لا يحدد إن كان الجامع قد ثبّت البيانات على وسيط دائم أو إن كانت الأنظمة اللاحقة قد استهلكت السجل. قد يعني error رفضاً إدارياً: فهو دليل على قرار سياسة، لا على أن الحدث لم يوجد.

يوضح RAW الحد الفاصل عملياً. تحدد علامة النهاية في BEEP نهاية الرسالة، ويضمن النقل الموثوق والترتيب داخل القناة الفردية. لكن أول رسالة من مستمع RAW لا تحمل معنى مُدخل syslog؛ أما ردود البادئ فتحمل المُدخلات. كما يفرض الملف حداً قدره 1,024 بايت لجسم كل حدث RAW، من دون احتساب حمل تأطير BEEP. هذا حد للحمولة، لا وعد بالحفظ الدائم. وهو مختلف عن حد الحزمة كاملة واحتمال اقتطاعها عند المُرحِّل في RFC 3164؛ فهما آليتان منفصلتان. (RFC 3195 §3.3؛ RFC 3164)

وتفصل RFC 3195 بين حماية الاتصال وسلامة كائن الرسالة. يحذر قسم الأمن من أن الجهاز المخترق قد ينشئ رسائل غير صحيحة، وأن المُرحِّلات أو جامعات السجلات قد تعدّل الرسائل أو تدرجها أو تحذفها دون كشف، ما لم تُستخدم تقنيات إضافية. وتُعامل المصادقة والحماية من الإعادة والسلامة والسرية بوصفها خدمات تُهيّأ كل على حدة. قد تصادق قناة محمية على نظير في إحدى القفزات، لكن هويته لا تطابق بالضرورة اسم المضيف المكتوب في الحدث، ولا تشكل توقيعاً من المصدر إلى المستهلك على محتوى الحدث. (RFC 3195 §§5, 10؛ RFC 5425 §4)

توضح أعمال syslog اللاحقة هذا الفارق أكثر. تعرّف RFC 5848 كتل توقيع يمكن أن تدعم توثيق المصدر والسلامة ومقاومة الإعادة والتسلسل واكتشاف الرسائل المفقودة. لكنها تشير أيضاً إلى أن النقل الموثوق لا يمنع الفقد على مستوى التطبيق، كأن يغلق المستقبِل جلسة TCP أو TLS. لا يثبت ذلك أن RFC 3195 انتشرت على نطاق واسع أو أن التوقيعات تحل جميع مسائل الاحتفاظ؛ بل يوضح أن التسليم والأصالة والاكتمال تحتاج إلى أدلة مختلفة. (RFC 5848 §§1, 8.3–8.7)

تكمن القيمة المستمرة لـ RFC 3195 في رسم حدود الضمان بدقة. يستطيع RAW الإجابة عن سؤال: «هل سلّمت قناة BEEP هذه الرسالة بالترتيب؟» ويضيف COOKED سؤالاً آخر: «هل رد المستقبِل إيجاباً أم سلباً على هذا المُدخل؟» لكنهما لا يثبتان، من دون ضوابط إضافية، أصالة الحدث أو بقاءه بعد عطل التخزين أو صدور إجراء من المشغّل. ينبغي أن تحفظ مراجعة الحوادث حالة الجلسة وردود المُدخلات والتحقق من التوقيعات واستدامة الكتابة لدى الجامع والمعالجة اللاحقة كلّاً على حدة. تحدد RFC سلوك البروتوكول؛ ولا تثبت المصادر المتاحة مدى انتشاره حالياً أو أداءه التشغيلي.

المصادر: RFC 3195؛ السجل الحالي لـ RFC 3195 لدى RFC Editor؛ نص RFC 3195 في IETF Datatracker؛ RFC 3080، نواة BEEP؛ RFC 3081، BEEP فوق TCP؛ RFC 3164، بروتوكول BSD Syslog؛ RFC 5424، بروتوكول Syslog؛ RFC 5425، نقل Syslog عبر TLS؛ RFC 5426، نقل Syslog عبر UDP؛ RFC 5848، رسائل Syslog الموقعة؛ RFC 6587، نقل Syslog عبر TCP؛ RFC 2782، DNS SRV؛ RFC 2119، مستويات متطلبات الكلمات المعيارية.