الخلاصة

  • تعرّف RFC 5365 خدمة SIP لرسائل pager-mode: يرسل العميل MESSAGE يضم قائمة URI مسطحة وحمولة رسالة، ثم تعمل الخدمة بوصفها B2BUA متخصصاً وتنشئ MESSAGE جديدة لكل مستلِم.
  • لا ينبغي نسخ Authorization أو Proxy-Authorization إذا كان الـ realm يخص خدمة القائمة نفسها؛ أما القيمة المرتبطة بنطاق آخر فتخضع لقاعدة مختلفة. الاعتماد يجيب جهة محددة، ولا يصبح صالحاً في كل اتجاه لأن النص يُنسخ.
  • تحتاج القيادة إلى إيصالات مستقلة لقبول الإدخال، وتصنيف realm، وقرار الهوية والخصوصية، والجمهور المشفّر، والأجسام المحذوفة أو المنشأة، وهوية المعاملة الجديدة، والاستجابة اللاحقة والتسليم. لا يثبت أي إيصال مبكر ما بعده.

كلمة المرور أجابت سؤال جهة واحدة

المصادقة ليست مادة لاصقة تُوضع على الطلب ثم تظل صالحة أينما تحرك. إنها جواب عن تحدٍّ أصدرته سلطة في نطاق محدد. يتغير معنى الاعتماد عندما يتغير من يسأل.

في RFC 5365 يرسل UAC طلباً متعدد الأجزاء يحتوي قائمة مسطحة وفق استخدام RFC 4826 وحمولة الرسالة، ويطلب دعم recipient-list-message. تستقبل خدمة القائمة العملية ثم تنشئ طلباً جديداً لكل URI قانونية.

إذا كانت ترويسة Authorization أو Proxy-Authorization تخص realm خدمة MESSAGE، فلا ينبغي نقلها إلى الطلب الصادر. لقد سمحت لـ Alice باستعمال الوسيط؛ لم تسمح بعرض السر على Bob أو على أول hop في طريقه.

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

السجل المطلوب قرار لا سر جديد

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

يكفي تسجيل نوع الاعتماد، واسم realm، ومرجع غير قابل للعكس، وقاعدة المطابقة، وقرار النسخ أو الحجب، وسياق الثقة في الوجهة. ويمكن الاحتفاظ بنتيجة التحقق وتوقيته من دون الاحتفاظ بما يستطيع مهاجم إعادة استعماله.

هذا الفصل يجعل الخطأ قابلاً للتشخيص. إن ظهرت بيانات تخص Realm الخدمة في downstream نعرف أن الحد انكسر. وإن حُذف اعتماد يخص نطاقاً آخر نعرف أن قاعدة تنظيف عامة عطلت سلوكاً مشروعاً.

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

الخدمة أنشأت معاملة لا نسخة طريق

تصف RFC 5365 الخدمة بأنها B2BUA متخصص. هي خادم في جهة الإدخال وعميل في جهة الإخراج. لا تمد معاملة Alice الشفافة إلى عدة نهايات، بل تبدأ معاملات مستقلة.

لكل مستلِم ينبغي إنشاء To جديد وCall-ID جديد وعدّاد CSeq منفصل، وتهيئة Max-Forwards وإضافة Via الخاصة بالخدمة. تتحول Request-URI من عنوان خدمة القائمة إلى عنوان الهدف.

هذه الحقول تثبت أن سلطة جديدة بدأت الفعل. Call-ID وCSeq يعرّفان التبادل ويرتبانه، وVia تعيد الاستجابة عبر المسار، وMax-Forwards يضع حداً جديداً للحلقات.

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

From المرئي لم يكن اعتماداً قابلاً للنقل

ينبغي أن تطابق قيمة From الصادرة قيمة From الواردة مع مراعاة الخصوصية. لا يُنسخ tag كما لو استمر endpoint الحوار نفسه، ولخدمة الخصوصية المرافقة أولوية.

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

P-Asserted-Identity تملك عقداً آخر. إذا جاءت من مصدر موثوق وخرجت إلى أول hop موثوق وجب تمريرها. وإذا كان الـ hop غير موثوق وطُلبت الخصوصية فلا يجوز إرسالها. ويمكن للخدمة إنشاء assertion عندما تصادق المستخدم وتربطه بـ SIP أو SIPS URI.

يسجل الإيصال مصدر الثقة، وطريقة المصادقة، وقاعدة الربط، وقيمة Privacy، وتصنيف أول hop، وقرار الإنشاء أو النقل أو الحجب. وجود الاسم وحده لا يشرح سلطته.

الجسم المشفّر عرف جمهوره

قد يتضمن multipart جسماً أمنياً من S/MIME أو غيره مشفراً لخدمة القائمة. يستطيع الوسيط فكّه، لكن المستلمين ليسوا جمهوره ولا يملكون بالضرورة المفتاح. لذلك لا يجوز نسخه إليهم.

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

التحقق الصحيح يعمل على مستوى الجزء: media type، وhash، وContent-Disposition، والجمهور، والتحويل المسموح، وسبب الحذف أو الإضافة. مقارنة الحزمة كلها سترفض تحويلاً صحيحاً؛ مقارنة النص المرئي وحده ستفقد المرفقات وبنية الحماية.

إذا أنشأت الخدمة حماية جديدة لـ Bob فهي علاقة تشفير جديدة، لا استمرار تلقائي للعلاقة بين Alice والخدمة.

تاريخ المستلمين كان كشفاً منشأً

يمكن للخدمة إنشاء recipient-list-history لدعم الرد للجميع. تطبق قواعد RFC 5364 على To وCc وBcc والإخفاء، فلا يكون الجسم نسخة خاماً من القائمة الأصلية.

تُبنى رؤية خاصة بـ Bob، وقد تختلف رؤية Carol. يُستحسن تشفيرها للمستلم. نجاح تسليم النص لا يثبت أن Bcc بقي مخفياً أو أن كل رؤية كشفت المقدار الصحيح.

يحتاج السجل إلى نسخة قائمة الإدخال، وقاعدة copy control، والمدخلات الظاهرة والمستبعدة، وhash الرؤية، وجمهور الحماية. هذا إيصال مستقل عن إيصال الحمولة.

بيانات URI لم تستطع تغيير نوع الفعل

يمكن لـ SIP URI أن يحمل مكونات header. تستطيع الخدمة تقييم كل مكوّن، مثل Accept-Contact، على حدة. ولا ينبغي أن يوفر hname الخاص body حمولة بديلة؛ يمكن تجاهله.

قد يحمل URI أيضاً method parameter. الحد واضح: خدمة قائمة MESSAGE تنشئ MESSAGE فقط وتتجاهل طلب طريقة أخرى. امتلاك حق تحديد هدف لا يمنح حق تحويل الخدمة إلى مولّد INVITE أو غيره.

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

202 أثبت القبول لا التسليم

ترد الخدمة بـ 202 Accepted. تنص RFC 5365 صراحة على أن ذلك لا يقدم معلومات عن نجاح تسليم رسائل MESSAGE المنشأة. هو إثبات أن الطلب وصل وأن الخدمة ستحاول.

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

تعالج RFC 5363 المجاورة تعدد النتائج. أما التركيز هنا فهو أن نفس الوسيط الذي قبل الحمولة يعيد بناء الاعتمادات والهوية والأجسام والمعاملة التي ستنتج عنها تلك النتائج.

السجل المعياري لم يكن دليلاً تشغيلياً

تسجل IANA recipient-list-message وdispositions ذات الصلة. الأسماء المشتركة تساعد التفاوض والتحليل، لكنها لا تثبت أن خادماً صنّف realm أو احترم Privacy أو سلّم رسالة.

نُشرت RFC 5365 في أكتوبر 2008 على Standards Track. أصبحت RFC 3851 قديمة ضمن تطور S/MIME الذي يشمل RFC 8551. يجب اختيار التشفير الحالي، مع بقاء سؤال الجمهور والسلطة ثابتاً.

تقدم ملاحظة Lu Heng عن الحد الأدنى للمواصفة الأولية عدسة معلنة: توحيد أقل عقد مشترك وترك القرارات اللاحقة لمن يملك المعلومات المحلية. وتمنع ملاحظة طبقات الواقع تحويل رمز مثل hash أو 202 إلى واقع تشغيلي. حقائق البروتوكول مستندة إلى RFC وIANA؛ الملاحظتان إطارا تحليل.