وافق المستلِم على خدمة واحدة بالنيابة عن جهة واحدة، لا على كل طلب مستقبلي

الخلاصة

• تتيح RFC 5363 إرسال قائمة URI أو الإشارة إليها في معاملة SIP واحدة، ثم ينشئ خادم القائمة طلبات متشابهة إلى وجهات متعددة. سهولة الإدخال لا توحّد السلطات: هوية المستدعي، حقه في استخدام الخدمة، وموافقة كل مستلِم ادعاءات منفصلة.
• حتى المستدعي الموثّق والمخوّل يستطيع إساءة الاستخدام. لذلك يشترط الإطار إذناً مناسباً من كل هدف، وإذا افتقدت URI واحدة ذلك الإذن فلا يجوز إرسال أي طلب إلى أي عضو في القائمة. ويجب أن يطابق الإذن الخدمة والمستدعي والعمل الفعلي.
• تحتاج القيادة إلى سجل يربط النسخة الدقيقة من القائمة، والتطبيع، ونطاق كل موافقة، وحاجز الكل أو لا شيء، وميزانية التضخيم، وكل عملية صادرة ونتيجتها. لا يجوز لمؤشر إجمالي أن يحوّل إذناً ضيقاً إلى سلطة واسعة.

كلمة «موافق» كانت ناقصة من دون مفعولها

يعتمد كثير من الأنظمة على حقل بسيط: وافق أو لم يوافق. هذا التمثيل مناسب للواجهة، لكنه خطير إذا انفصل عن السؤال الذي أُجيب عنه. وافق على ماذا؟ من أي جهة؟ عبر أي خدمة؟ لأي مدة؟ وبأي نوع من الأثر؟

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

يجب أن يصادق الخادم المستدعي ويخوّله قبل الإرسال. هذه بداية سلسلة السلطة وليست نهايتها. المصادقة تثبت هوية ضمن نموذج ثقة. التخويل يثبت أن تلك الهوية تستطيع استعمال وظيفة محددة. أما المستلِم فيملك قراراً منفصلاً بشأن ما يجوز أن يصل إليه وبالنيابة عن مَن.

عندما يُختزل كل ذلك إلى حقل واحد، تُعاد كتابة موافقة ضيقة باعتبارها قبولاً دائماً لكل استعمال. لا يحدث التوسع في التشفير، بل في تفسير السياسة.

هوية المستدعي لم تكن هوية صاحب الحق في كل وجهة

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

ينبغي أن يحمل إيصال الإذن عدة أبعاد: URI القياسية للمستلِم، هوية المستدعي أو الفئة المسموح لها، اسم الخدمة، طريقة SIP أو نوع العملية، مدة الصلاحية، إصدار السياسة، وأي قيود على التكرار أو المحتوى.

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

لهذا لا يصح نقل الإذن بين خدمات متجاورة لمجرد أنها تستخدم القائمة ذاتها. القائمة تعرّف مجموعة مراجع؛ الخدمة هي التي تمنح كل مرجع معنى عملياً.

الإذن كان علاقة لا خاصية ثابتة للمستلِم

تصميم قاعدة البيانات حول recipient_allowed=true يوحي بأن الموافقة صفة دائمة للشخص. الأدق أنها علاقة بين أطراف وسياق وزمن. المستلِم لا يصبح «مسموحاً» في المطلق؛ بل توجد سلطة محددة لاستدعاء فعل محدد نحوه.

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

تقدم RFC 5360 إطاراً مرتبطاً بالموافقة، مع الانتباه إلى ألا يصبح طلب الموافقة نفسه وسيلة تضخيم. لكن موضوع RFC 5363 هنا مستقل: عند لحظة التنفيذ، هل يستطيع خادم القائمة إثبات أن كل وجهة وافقت على هذا الاستعمال وبهذه النيابة؟

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

هدف واحد بلا إذن أوقف المجموعة كلها

تنص RFC 5363 على قاعدة قوية: إذا لم يمنح أي هدف الإذن المطلوب، فلا يرسل الخادم طلبات إلى أي URI في القائمة. هذه ليست معالجة «أفضل جهد» تحذف العضو الرافض وتتابع.

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

إذن يجب أولاً تحديد المجموعة القياسية كاملة، ثم تقييم كل علاقة إذن، ثم إغلاق حاجز واحد قبل إنشاء أول عملية صادرة. يسجل النظام وقت آخر قرار ووقت أول إرسال. إذا سبق الإرسال اكتمال القرارات، فالحاجز لم يكن وقائياً.

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

لا توجد موافقة كاملة قبل وجود مجموعة كاملة

يمكن أن تأتي القائمة في جزء يحمل recipient-list، ويمكن دمج أجزاء متعددة. كما يمكن أن تكون مرجعاً إلى مستند خارجي، مثلاً ضمن آليات XCAP التي تصفها RFC 4825 وRFC 4826.

يجب تطبيق قواعد مقارنة مخطط URI، لا مقارنة النصوص وحدها. تطلب RFC 5363 من العميل تجنب التكرار ومن المستقبِل اعتبار URI المكررة واحدة. وقد تضيف RFC 5364 خصائص تحكم في النسخ تجعل تعارض المعنى منفصلاً عن تطابق الهوية.

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

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

تغيّر القائمة غيّر نطاق الموافقة

القائمة المخزنة مفيدة لأنها تُحدّث مركزياً. لكنها تضيف الزمن إلى قرار السلطة. قد يراجع المستدعي نسخة فيها سبعة أعضاء، ثم يضاف ثامن قبل أن يجلبها الخادم.

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

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

مغادرة شخص للقائمة بعد الإرسال لا تلغي ما تلقاه. ودخول شخص قبل إعادة المحاولة لا يمنحه تلقائياً مكاناً في نية سابقة. الفهرس الزمني ليس تفصيلاً؛ إنه جزء من الإذن.

TLS لم يوسّع معنى الموافقة

تناقش RFC 5363 حماية S/MIME من طرف إلى طرف وTLS بين القفزات. يحمي TLS اتصالاً معيناً ويصادق طرفيه بحسب الإعداد. ويمكن لـS/MIME ربط موقّع بالمحتوى المغطى.

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

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

وصف العملية كلها بأنها «آمنة» يمحو تلك الحدود. الأفضل أن يقول كل إيصال بدقة ما شاهده وما لم يشاهده.

ميزانية التضخيم كانت سلطة أخرى

قد يحول طلب واحد إلى عدد كبير من الطلبات نحو أنظمة SIP وغير SIP ووسطاء الشبكة. تعترف RFC 5363 بخطر التضخيم وحجب الخدمة، وتتيح وضع حد لعدد URI.

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

الموافقة لا تعوّض الميزانية، والميزانية لا تعوّض الموافقة. يمكن أن تكون عملية رخيصة غير مأذونة، أو عملية مأذونة لكنها خطرة على السعة. ينبغي إغلاق القرارين قبل الإرسال.

يحمل إيصال الميزانية هوية المستدعي لأنه يوضح من استهلك القدرة، لكنه لا يُشتق من الهوية وحدها. إنه قرار مستقل بشأن مقدار العمل الذي تسمح المنصة بتوليده.

معنى الفعل حدده نوع الخدمة

تترك RFC 5363 معنى القائمة للتطبيق والخدمة. قد ينفذ الخادم توزيعاً بسيطاً، أو يعمل كخادم تطبيق مثل مكوّن مؤتمر. وتعرض RFCs 5364 إلى 5368 استخدامات خاصة، بينما تقدم RFC 4575 وRFC 4662 نماذج مختلفة للحالة والتجميع.

لذلك يجب أن يرتبط الإذن بالفعل. إرسال MESSAGE ليس دعوة، والدعوة ليست انضماماً، والاشتراك ليس مجرد رسالة. كما تختلف النتيجة النهائية: قبول بروتوكولي، أو تسليم، أو مشاركة، أو حالة اشتراك.

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

هذا هو سبب بقاء آلية النتائج خارج تعريف عام واحد. الاختلاف ليس فراغاً ينبغي ملؤه بخانة غامضة، بل سلطة محلية يجب تعريفها بوضوح.

لكل مستلِم موضع مستقل في سجل النتيجة

تشترط RFC 5363 أن يستطيع المستدعي معرفة النتائج. فإذا كانت المجموعة القياسية تضم عشرة، يحتاج التقرير إلى عشرة مواضع حتى لو تشابهت حالاتها.

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

يربط كل موضع هوية العضو بالعملية الصادرة، والتوقيت، والمحاولات، والنتيجة أو حالة مجهولة محدودة. ويُحسب الملخص من هذه السجلات؛ لا يحل محلها.

إذا كان رد SIP يثبت القبول فقط، فقد تحتاج النتيجة المقصودة إلى ملاحظة مستقلة. لا ينبغي للمنصة أن تتحدث باسم تجربة المستلِم من دون قياسها.

اثنا عشر إيصالاً تحفظ حدود التفويض

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

لا يغني إيصال عن التالي. هوية صحيحة لا تمنح موافقة. موافقة صحيحة لا تثبت إرسالاً. الإرسال لا يثبت تسليماً. والملخص لا يثبت عناصره ما لم يحتفظ بها.

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

سجل IANA وحّد الاسم ولم يمنح السلطة

يسجل IANA قيمة recipient-list ضمن معلمات SIP. هذا يجعل الرمز قابلاً للفهم بين التطبيقات. لا يثبت نشر خدمة معينة أو موافقة مستلِم أو نجاح أثر.

صدرت RFC 5363 في أكتوبر 2008 ضمن Standards Track. هذه الصفة لا تكشف الانتشار الحالي. يلزم دليل من التنفيذ الفعلي.

تقدم ملاحظة Lu Heng عن الحد الأدنى للمواصفات الأولية عدسة تحليلية لاحقة: ينبغي أن يظل المشترك صغيراً وأن تبقى القرارات المستقبلية لدى من يملك السياق المحلي. يمكن مشاركة صيغة القائمة ومتطلبات أساسية، أما معنى الإذن والنتيجة فيبقى محلياً.

وتساعد ملاحظته عن طبقات الواقع في فصل سجل الموافقة الرمزي عن الفعل الذي غادر الخدمة والأثر الذي اختبره المستلِم. تحمل RFCs وIANA الحقائق التقنية؛ أما الملاحظتان فإطاران تحليليان معلنان.