الخلاصة

  • تسمح المسودة draft-deshpande-secevent-http-multi-set-push-03 لاستجابة 202 بأن تؤكد بعض قيم jti في ack، وترفض غيرها في setErrs، وتذكر نتائج من طلبات سابقة. الرمز يخص قبول الغلاف، لا اكتمال الدُفعة.
  • الوثيقة مساهمة فردية برعاية Area Director، ومرحلة Last Call مستمرة حتى 23 سبتمبر 2026. لا توجد لها حالة فريق عمل أو تطبيقات مؤكدة أو موافقة IESG أو رقم RFC أو عملية IANA مكتملة.

يرسل النظام أربعة Security Event Tokens في طلب POST واحد. تعود الاستجابة 202، لكن متنها قد يؤكد ثلاثة معرّفات ويضع خطأ للرابع، وقد يضيف نتيجة لمعرّف أرسل في اليوم السابق. وحتى الحدث المؤكد لا يثبت أن النظام اللاحق ألغى جلسة أو غيّر حالة حساب.

هذا هو الفصل الذي تعتمد عليه المراجعة 03 من HTTP Push Delivery of Multiple Security Event Tokens. التجميع يحسن كفاءة النقل ولا ينشئ معاملة ذرية. لذلك لا يجوز تحويل نجاح الطلب إلى شهادة نجاح جماعية.

التسوية تتم بحسب jti

يحمل النوع application/secevents+json كائن sets الذي تستخدم فيه قيم jti مفاتيح. يتحقق المستقبل من كل SET على حدة. تحتوي استجابة 202 على مصفوفة ack الإلزامية، ويمكن أن تضيف setErrs المرتبط بكل معرّف. ويجمع مثال المسودة التأكيدات والخطأ في استجابة مقبولة واحدة.

ولا تنحصر النتيجة في الطلب الحالي. يستطيع المستقبل إرسال نتيجة SET سابق، كما يستطيع المرسل إرسال sets فارغاً للاستعلام عن النتائج المؤجلة. يجب تجاهل التأكيد أو الخطأ المتعلق بمعرّف مجهول. وحدة المطابقة إذن هي الحدث المسمى، لا استدعاء HTTP وحده.

يعاد إرسال SET غير المؤكد حتى يصل تأكيد أو خطأ خاص به أو يبلغ الحد الأقصى للمحاولات. وقد تؤدي سياسات الوقت أو التخزين المحلية إلى إسقاط حدث لم يصل. لا يمكن استنتاج هذه القرارات من استجابة 202 الأولى.

الاستلام ليس تطبيقاً

يشمل التأكيد الاستلام والتحليل والتحقق، ولا يضمن إجراءً لاحقاً. تفصل RFC 8935 بين التسليم والمعالجة اللاحقة، وتصف RFC 8417 الـSET بأنه بيان حقيقة من جهة المُصدر، لا أمراً واجب التنفيذ.

وتعرّف RFC 9110 الرمز 202 بأنه قبول للمعالجة لم تكتمل بعد، وربما لا تحدث. تضيف Multi-SET Push أدلة لكل عنصر داخل هذا الغلاف غير الحاسم، ولا تغير معنى HTTP.

كما أن الدُفعة لا تضمن الترتيب. كل SET مستقل، وموقعه لا ينشئ اعتماداً زمنياً، ولا تفرض المسودة متطلبات معاملة. يجب إثبات العلاقة السببية خارج مجرد التجاور في JSON.

حدود المرحلة لدى IETF

يعرض Datatracker المراجعة 03 بوصفها Internet-Draft فردية نشطة في Security Area وهدفها Proposed Standard. بدأت Last Call في 26 أغسطس وتنتهي في 23 سبتمبر. حالة Working Group هي None ولا يوجد موعد telechat.

يوضح سجل shepherd أن SECEVENT كان قد انتهى، ولم تتوافر طاقة كافية لإعادة تشكيله. لذلك تتقدم الوثيقة كمساهمة فردية برعاية Deb Cooley. لا يدل ذلك على رفض تقني، لكنه ليس إجماع فريق عمل.

صنفت مراجعة Security Directorate النص بأنه Ready مع اقتراح صياغي بسيط. لا توجد تطبيقات مؤكدة؛ وخطة دمجه في OpenID Shared Signals Framework ليست إثبات نشر. كما تتوقف إجراءات IANA على موافقة مستقبلية. Last Call ليست موافقة IESG ولا إصدار RFC.

إيصال لكل حدث

يقترح Daniel Kade حفظ الطلب الأصلي وتوقيته لكل jti، والتأكيد أو الخطأ الدقيق، والربط بطلب سابق، وعدد المحاولات، وقرار المحاولة التالية، وسبب الإسقاط النهائي. تضاف إلى ذلك نسخة إعداد المستقبل ووقت التحقق وحالة مطبق أو مرفوض أو معلق في النظام اللاحق.

هذا تصميم تحريري للحوكمة، لا مطلب من IETF. يسمح بالتجميع مع إبقاء الطريق مفتوحاً إلى الحدث الفردي. يثبت 202 قبول الغلاف فقط؛ أما ما حدث بعده فيحتاج سلسلة jti كاملة.

المصادر