كان المتصل موثّقاً. لم يكن ذلك موافقةً من كل هدف.

الخلاصة

• يسمح RFC 5367 بإنشاء اشتراكات في قائمة موارد مسطحة من خلال جسم recipient-list في طلب SUBSCRIBE الأول، لكنه لا يجعل استجابة ذلك الطلب دليلاً على نجاح الاشتراك في كل URI.
• يجب أن يقبل العميل rlmi+xml لأن NOTIFY هو الذي يحمل أدلة الحالة لكل عنصر. توثيق العميل وترخيص خدمة القوائم لا يلغي موافقة الهدف أو سياسة كل مورد.
• بعد الإنشاء تنتقل المتابعة إلى URI يقدمه الخادم، ولا معنى لجسم قائمة في SUBSCRIBE اللاحق؛ أما URI المعلّم purpose=list-management فهو قدرة ثالثة تنتهي مع عمر الاشتراك والقائمة.

أثبت التوثيق طرفاً واحداً فقط

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

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

لهذا ترث الآلية اعتبارات الأمن في RFC 4662 وRFC 5363، ومنها حماية خدمات القوائم واشتراط المشاركة الاختيارية المناسبة للأطراف المتأثرة. المجمّع لا يصبح طريقاً مختصراً حول موافقة الهدف.

ينبغي لسجل القرار أن يربط هوية الطالب بالخدمة وحزمة الأحداث والقائمة، ثم يسجل قراراً منفصلاً لكل مورد. حقل واحد باسم “authorized” يطمس جهتين مختلفتين من السلطة.

الطلب الأول أنشأ مجموعة محددة

يرسل UAC طلب SUBSCRIBE الأول إلى URI العام لمورد القائمة. يحتوي الطلب على جزء واحد على الأقل من نوع disposition recipient-list ويضع recipient-list-subscribe في Require.

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

يعتمد RFC 5367 تنسيق RFC 4826 افتراضياً، لكنه يحتاج قائمة مسطحة فقط. لا تلزم البنية الهرمية ولا entry-ref، ويجوز للخادم إسقاط معلومات إضافية.

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

قبول الحوار لم يكن تصويتاً جماعياً

ينص RFC 5367 بوضوح على أن رمز الاستجابة لطلب SUBSCRIBE لا يقدم معلومات عن نجاح الخادم في الاشتراك في عناوين URI المضمنة.

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

إذا عرض النظام عبارة “تم الاشتراك” فور 2xx، فقد غيّر موضوع الادعاء من الطلب إلى جميع الموارد. الصياغة الصحيحة هي “قَبِل خادم القوائم الطلب” حتى تصل أدلة أدق.

ينبغي أن تعرض الواجهة حالتين: قيام العلاقة المجمّعة، وتغطية الموارد داخلها. لا يجوز أن يكون عدد العناصر الواردة في أحدث إشعار هو المقام؛ المقام هو المجموعة القانونية التي أنشأها الطلب.

الإشعار أعاد الاختلاف إلى الواجهة

يوفر RFC 4662 نموذج إشعار الأحداث لقوائم الموارد. تمكّن بيانات rlmi+xml العميل من تمييز الموارد وحالاتها ضمن حوار واحد.

كل موضع يحتاج URI قانونياً، ومعرف حالة أو مثيل، وإصداراً، ووقت ملاحظة، وسبب انتهاء. وقد تكون “قيد الانتظار” أو “غير معروفة” نتيجة صادقة وليست نقصاً ينبغي إخفاؤه.

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

غياب المورد من رسالة واحدة لا يثبت نجاحه ولا حذفه. من دون دلالة الاكتمال وتسلسل الإصدارات، يتحول الصمت إلى مساحة يملؤها المنتج بأكثر تفسير ملائم.

التجديد لم يمنح سلطة تغيير النطاق

بعد قيام الحوار، يمكن لـUAC إرسال طلبات SUBSCRIBE لاحقة لتمديد المدة. تُرسل هذه الطلبات إلى URI الذي قدمه الخادم للحوار.

لا يعرّف RFC 5367 أي معنى لجسم قائمة موارد في تلك الطلبات. ينبغي للعميل حذفه، وإذا استلمه الخادم فعليه الرد بـ415 Unsupported Media Type.

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

قبول الجسم “للتسامح” ليس تحسيناً بسيطاً. إنه اختراع لعقد تعديل من دون تحديد موافقات الموارد الجديدة أو علاقة القائمة الجديدة بالقرار الأصلي.

تغيّر العنوان لأن المرحلة تغيّرت

الطلب الأول يستهدف URI العام للقائمة. أما الطلبات اللاحقة فتستخدم URI الحوار الذي يقدمه الخادم. من منظور العميل، الأول يقبل جسم recipient-list والثاني لا يقبله.

ينبغي ربط العنوانين بهوية المتصل، والحدث، وبصمة القائمة، ومعرفات الحوار، وExpires. هذا الربط يشرح كيف نشأت قدرة الاستمرار وما حدودها.

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

عندما تضيع هذه الفروق، يصبح URI قديم مدخلاً لإنشاء جديد، أو يصبح URI الحوار ذريعة لتغيير المجموعة.

رابط الإدارة كان قدرة مستقلة

قد يحمل NOTIFY الأول ترويسة Call-Info تشير إلى URI بغرض purpose=list-management. يسمح هذا العنوان بالتعامل مع القائمة المرتبطة بالاشتراك.

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

لدينا إذن ثلاث واجهات: URI عام للإنشاء، وURI للحوار للاستمرار، وURI للإدارة للتعديل. جمعها تحت تسمية “رابط الاشتراك” يزيل حدوداً أمنية مهمة.

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

عمر القائمة لم يكن مفتوحاً

يربط RFC 5367 عمر القائمة القابلة للتعديل بعمر الاشتراك، وينص على أنه ينبغي إتلافها عندما ينتهي الاشتراك أو تنقضي مدته.

هذا القيد يمنع قائمة مؤقتة للعلاقات من التحول إلى مخزون دائم. وهو يحد أيضاً من المدة التي تبقى فيها قدرة الإدارة ذات معنى.

لكن Expires: 0 أو حدث النهاية ليس إيصال حذف مادي. قد تبقى نسخ في مخزن أساسي أو ذاكرة مخبأة أو فهرس أو نسخة متماثلة أو سجل تدقيق.

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

الرفض يحتاج سبباً حتى عندما لا يُكشف

قد لا يستطيع الخادم كشف سبب رفض مورد للعميل، لأن التفصيل نفسه قد يكشف وجود الهدف أو سياسته. لكن النظام الداخلي لا يزال يحتاج تصنيفاً مضبوطاً.

غياب opt-in يختلف عن خطأ مسار، ومشكلة تفويض تختلف عن اشتراك لم يُحاول بعد. جمعها في حالة فارغة يفسد التشغيل والمراجعة.

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

وتحتاج إعادة المحاولة إلى احترام السبب. إعادة طلب مورد رفض المراقبة ليست علاجاً لعطل تقني، وقد تصبح ضغطاً آلياً على قرار سياسة.

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

تسجل IANA الوسم recipient-list-subscribe والغرض list-management. هذان اسمان مشتركَان للتوافق، لا قياسان لنجاح كل اشتراك.

وجود option-tag يثبت إعلان قدرة في رسالة. ووجود purpose يصف نوع الرابط. لا يثبت أي منهما موافقة الموارد أو صلاحية الإدارة الحالية أو اكتمال الإتلاف.

نشر RFC 5367 في أكتوبر 2008 ضمن Standards Track وحدّث RFC 3265 للسماح باستخدام Call-Info في NOTIFY. ثم أبطل RFC 6665 الوثيقة RFC 3265. ينبغي للتطبيق الحديث تتبع هذا التطور مع الحفاظ على الفصل بين المراحل.

توفر ملاحظات Lu Heng العدسة المعلنة. تشرح Minimum Initial Specification لماذا لا ينبغي للعقد الأساسي أن يختلق معنى تعديل في التجديد. وتذكر Reality Layers بأن الهوية والاستجابة والإشعار والعنوان والمؤقت رموز لحقائق مختلفة. تبقى RFCs وسجل IANA مصادر الوقائع البروتوكولية.