الخلاصة

  • تنص المراجعة 07 من نقل IDMEFv2 عبر HTTPS على ألا يرسل المستقبل 2xx قبل أن يتعامل مع التنبيه بأمان، إما بحفظ دائم أو بتمريره إلى نظام آخر أكّد استلامه؛ وبذلك يصبح 204 No Content إيصال حيازة فعلياً.
  • تُرسل كل رسالة بطلب POST مستقل، لكن المشروع لا يحدد دلالات الإعادة أو مدة تذكّر التكرار أو مصير التحقيق. يحتاج التحالف إلى سجل يربط هوية المرسل بالمعرّف الإلزامي للتنبيه.

ينقطع الرد بعد أن ينجح الحفظ

يرسل Analyzer تنبيهاً، ويُتم Manager كتابة السجل في قاعدة البيانات، ثم يبدأ بإرجاع 204. إذا انقطع الاتصال قبل أن يقرأ المرسل سطر الحالة، لا يستطيع الأخير إثبات ما حدث. قد يؤدي إرسال POST مرة أخرى إلى احتساب الإشارة مرتين أو تشغيل استجابتين آليتين؛ أما الامتناع فقد يضيّع رسالة لم تصل فعلاً إلى مرحلة الحفظ.

يحمل Transport of IDMEFv2 Messages over HTTPS تاريخ 27 سبتمبر 2026، وهو Internet-Draft فردي. يذكر Datatracker أنه بلا stream وبلا مكانة رسمية في مسار معايير IETF. تستهدف المراجعة 07 Standards Track، ولا تستبدل RFC 4767 إلا إذا اعتُمدت. إنها مقترح قابل للتغيير وليست معياراً نافذاً أو إثباتاً على النشر.

يفرض النص الدقيق للمراجعة 07 طلب POST واحداً لكل رسالة IDMEFv2، مع السماح بعدة طلبات متوازية. يقابل الخطأ في الرسالة رد 4xx، ويقابل عجز المستقبل عن المعالجة رد 5xx. أما القاعدة الأهم فتجعل رمز HTTP إقراراً: لا ينبغي إرسال 2xx قبل حفظ الرسالة على قرص أو في قاعدة بيانات، أو تمريرها إلى مستقبل تالٍ أكّدها.

لذلك لا يعني مثال 204 مجرد عبور البايتات داخل TLS. تعرّف RFC 9110 الرمز 204 عموماً بأنه نجاح الفعل المطلوب من دون محتوى رد إضافي. ويضيف المشروع حدّاً تطبيقياً واضحاً لما يجب أن يكون قد نجح بأمان.

المعرّف موجود، لكن سياسة التكرار ليست مشتركة

يفرض نموذج بيانات IDMEFv2 ID من نوع UUID وCreateTime في التنبيه الأعلى. ويمكن ضم هوية شهادة المرسل إلى هذا المعرّف لتكوين مفتاح تمييز. لكن مشروع النقل لا يقول كم تدوم ذاكرة المفتاح، ولا ما إذا كان التكرار المطابق يستحق 2xx جديداً، ولا كيف يعالج UUID واحداً وصل مع محتويين مختلفين.

لا يمنح HTTP طلب POST خاصية idempotence تلقائياً. تحذر RFC 9110 من إعادة طريقة غير idempotent آلياً ما لم يعرف العميل أن دلالة التطبيق كذلك، أو يستطيع إثبات أن المحاولة الأولى لم تُطبّق. وتوضح RFC 9205 أن بناء بروتوكول فوق HTTP لا يعفيه من تحديد أثره التطبيقي.

أما المصادقة المتبادلة فترسم حدود القبول. يستند المشروع إلى RFC 5280 وRFC 6125، ويطلب شهادات X.509 للطرفين، والتحقق الكامل من المسار، وDNS-ID بلا wildcard، وقائمة صريحة بشهادات النظراء المقبولين. يثبت ذلك أي عضو مخوّل تكلم؛ لكنه لا يثبت صدق التنبيه أو فرادته أو إغلاق الحادث.

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

يضع Running-Code Primacy الدليل في سلسلة الاستلام والحفظ والقرار التي نُفذت فعلاً. ويدعم Minimum Initial Specification, Localized Future Decision إيصالاً مشتركاً صغيراً مع إبقاء قرار الاستجابة محلياً. أما On Authority, Belief, and the Internet’s Addressing System فيمنع خلط السلطات: الشهادة تعرّف النظير، و204 يقر بالحيازة، والمحلل يحكم على الحادث.