الخلاصة

  • قبل Commit-Final يستطيع المصدر فك القفل ويستطيع المقصد عكس السك المؤقت؛ أما بعد إحراق الأصل فتقول المراجعة 17 إن أمر الإنهاء غير فعّال.
  • لا يدعم Core الحالي استعادة الجلسة أو استئنافها. تطلب وثيقة المعمارية سجلات ونقاط تحقق، لكنها تترك دلالاتها المشتركة ونقطة البدء لعمل لاحق وقرار محلي.
  • يلزم دفتر لنقطة اللاعودة يفصل النية المحلية والإرسال والاستلام وادعاء البوابة عن الحالة المرصودة في كل شبكة مغلقة.

قد تكون الرسالة سليمة تماماً وتصل متأخرة تماماً. ترسل بوابة المصدر Commit-Final وتعلن أنها أطفأت الأصل في شبكتها. ينقطع الاتصال قبل وصول الإقرار النهائي. يضغط المشغّل زر الإنهاء، لكن الحالة السابقة لم تعد موجودة كي يستعيدها الأمر.

تنص الفقرة 11.5 من SATP Core المراجعة 17 على أن الإنهاء بعد Commit-Final غير فعّال. فقد أحرق G1 الأصل في NW1، وسك G2 المقابل في NW2 والتزم بإسناده إلى المستفيد. الاسم البروتوكولي لا يغيّر الواقع الذي وصل إليه التنفيذ.

دخلت الوثيقة Last Call لدى IETF في 25 سبتمبر 2026 حتى 9 أكتوبر. ويثبت سجل Datatracker أنها Internet-Draft قيد النظر كـ Proposed Standard، لا RFC ولا دليلاً على تطبيق أو تحويل فعلي.

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

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

تقترب المرحلة 3 من الحد. يعلن Commit-Ready أن المقصد سك أصلاً مقابلاً وأسنده مؤقتاً إلى نفسه وأصبح مستعداً. قبل ذلك يمكن فك القفل أو عكس السك المؤقت. ثم يعلن Commit-Final الإحراق، ويعلن ACK-Final إسناد الأصل إلى المستفيد، وتغلق Transfer-Complete الجلسة. جمع هذه الوقائع في حالة واحدة باسم «ملتزم» يمحو موضع العطل.

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

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

يحمي TLS 1.3 القناة، ويربط JWS الادعاء بالمفتاح، وينظم RFC 9457 الأخطاء. لا يراقب أي منها تلقائياً القفل والإحراق والسك والإسناد داخل الشبكتين. وتقدم حالات استخدام SAT سندات الشحن وخطابات الاعتماد كأمثلة تصميم، لا كدليل تبنٍّ.

يجب أن يربط دفتر نقطة اللاعودة sessionId وtransferContextId بكل رسالة موقعة وتجزئة سابقة، ثم يضيف أدلة القفل والإحراق والسك والإسناد، انتهاء القفل، أوقات الإرسال والاستلام، هوية البوابات، نهائية كل شبكة، جيل إعادة التشغيل، وأحدث مرحلة أثبتها الطرفان معاً.

تضع أولوية الشيفرة العاملة لدى Lu Heng الحالة المنفذة قبل اسم الرسالة. وتحافظ المواصفة الأولية الدنيا على عقد مشترك ضيق، بينما تمنع طبقات الواقع الرمز الموقّع من انتحال أثر لم يرصده.

المصادر