الخلاصة
- يضيف RFC 5196 قدرات الخدمة والجهاز إلى معلومات الحضور كي يختار المراقب وسيلة اتصال أفضل قبل البدء، لكنه ينص صراحة على أن هذه الإشارات لا تستبدل تفاوض الوسائط مثل SDP.
- يجب فصل ما نشره المصدر، وما سمحت السياسة بكشفه، وما رآه مراقب بعينه، عن الدعوة والعرض والإجابة والجهاز المستجيب وإرادة الإنسان والنتيجة الحية.
حين تتحول الخاصية إلى وعد بشري
يوفر RFC 5196 حلاً لمشكلة محددة. قد يحتوي PIDF على URI للاتصال من دون أن يبيّن هل يمثل الـ tuple صوتاً أم فيديو أم رسائل أم خدمة أخرى. تستخدم الإضافة مفردات قدرات RFC 3840، وتضع خصائص الخدمة والجهاز ضمن نموذج الشخص والخدمة والجهاز الذي يصفه RFC 4479.
يمكن لخاصية اللغة أن تساعد المراقب في اختيار قناة مناسبة. لكنها قد تصف تنسيق محتوى تفهمه خدمة أو قدرة يعلنها جهاز. لا تثبت وجود شخص يتكلم اللغة، ولا موافقته على الرد، ولا أن الجهاز الذي سيتلقى الدعوة هو الجهاز الذي نشر الخاصية. كل استنتاج من هذه الاستنتاجات يحتاج دليله الخاص.
يصف نطاق RFC المعلومات بأنها تلميحات قبل الاتصال عن التفضيلات والاستعداد والقدرات. ويضع الحد مباشرة: لا تستبدل الإضافة آليات تفاوض وسائط SIP، مثل SDP. الحضور قد يبرر محاولة، أما الطلب والرد والعرض والإجابة فهي التي تبين ما تفاوضت عليه الجلسة فعلاً.
منظر مصمم لمراقب محدد
ليست معلومات الحضور كشفاً عاماً وحتمياً لكل ما يستطيع الجهاز فعله. يجوز للـ presentity ألا ينشر قدرة حقيقية؛ ويورد RFC مثال خدمة تدعم الصوت بينما لا يريد المستخدم إظهار ذلك. كما يمكن لقواعد التفويض أو لخادم الحضور أن تحد المعلومات أو تعدلها.
لهذا لا يعني غياب خاصية أنها غير مدعومة. قد تكون غير مكشوفة، أو مجهولة، أو منتهية، أو تخص خدمة أخرى. يخصص التنسيق supported للإثبات الإيجابي وnotsupported للنفي الصريح، ولا يشجع على ملء المستند بقائمة شاملة من النفي غير ذي الصلة.
إذا ظهرت القيمة نفسها في القائمتين، يمكن للمراقب افتراض الدعم. هذه قاعدة لقراءة تعارض، وليست تصريحاً بحذف أحد المصدرين. كما أنها لا تسمح بتحويل كل فراغ إلى نفي. يجب أن يبقى سياق الاشتراك وهوية المراقب وإصدار قاعدة التفويض جزءاً من معنى القيمة.
التجميع لا ينتج حقيقة محايدة
قد ينشر الهاتف المكتبي والعميل المحمول وبرنامج الحاسوب وخدمة السياسة معلومات عن الشخص نفسه. يقر RFC 5196 بأن جمع مصادر متعددة قد يفقد معلومات أو يخلق عدم تطابق. لذلك يتخذ المجمّع قراراً، حتى إن قدم نفسه كأنبوب.
اتحاد جميع القدرات يمكن أن يصنع جهازاً خيالياً يجمع ما توزع على أجهزة مختلفة. التقاطع يمكن أن يخفي قدرة الجهاز الذي سيرد فعلاً. قاعدة «الأحدث يفوز» تحتاج إلى تحديد الساعة والموضوع اللذين تجوز مقارنتهما. وقد يكون أحدث بيان عن خدمة مختلفة تماماً.
ينبغي الاحتفاظ مع كل قيمة بهوية ناشرها، وموضوعها ـ خدمة أو جهازاً ـ ونسختها ووقت نشرها وانتهائها ونطاق التفويض. وعند التعارض يجب حفظ مجموعة المدخلات وقاعدة الحسم. الناتج وحده لا يستطيع تفسير نفسه بعد وقوع الخطأ.
الزمن يغير الفاعل
يصف RFC خصائص الخدمة والجهاز بأنها ديناميكية. بعد النشر قد يتبدل الجهاز، أو يعاد تشغيل العميل، أو تتغير سياسة الخصوصية، أو يبقى مستند قديم في ذاكرة وسيطة. لا يفرض RFC تطابقاً كاملاً بين الحضور والقدرة الفعلية، ويحذر المراقب من توقع ذلك.
هناك أزمنة عدة: ملاحظة المصدر، النشر، استقبال الخادم، التحويل، التجميع، التسليم للمراقب، ثم إرسال الدعوة. حقل تحديث واحد يمحو موضع التأخر. كذلك يجب أن يتعلق الانتهاء بالقيمة وبالجهاز أو الخدمة، لا بهوية الشخص بصورة فضفاضة.
يمكن للمعلومات الناقصة أو الخاطئة أن تجعل المراقب يستبعد اتصالاً ممكناً، أو يحاول قدرة ستفشل. الحالتان مذكورتان في RFC. العلاج ليس تجاهل الحضور، بل منع التلميح القديم أو المحدود من أن يصبح حكماً نهائياً.
إيصال يضع كل سلطة في مكانها
يسجل إيصال الحضور الأدنى هوية presentity والمراقب والاشتراك؛ وهوية الـ tuple أو الخدمة أو الجهاز؛ ووكيل النشر؛ وإصدار المصدر؛ وأوقات النشر والانتهاء؛ والحالة الإيجابية أو السلبية أو غير المكشوفة؛ والقيمة الدقيقة. ثم يسجل قاعدة التفويض، وتحويلات الخادم، ومدخلات التجميع وحسم التعارض، وبصمة المستند الذي وصل إلى المراقب ووقت استلامه.
بعد ذلك تبدأ سلسلة أخرى: أي إشارة أثرت في قرار الاتصال؟ ما URI والـ endpoint المختاران؟ ما طلب SIP وردّه، وعرض SDP وإجابته، والوسيط المتفاوض عليه، وإرادة الشخص، والنتيجة المرصودة؟ ترتبط السلسلتان بمرجع، لكن لا تحل إحداهما محل الأخرى.
هذا مخطط للمساءلة التشغيلية، لا متطلباً سلكياً جديداً في RFC 5196. يطبق انضباط Heng Lu في طبقات الواقع: يظل الرمز تابعاً للنظام الجاري الذي يلخصه. اللغة المعلنة مفيدة في الاختيار، لكنها لا تصبح إنساناً حاضراً بقرار من قاعدة بيانات.
Sources
- RFC 5196 بصيغة HTML
- نص RFC 5196
- صفحة معلومات RFC 5196
- IETF Datatracker: RFC 5196
- تاريخ RFC 5196
- مراجع RFC 5196
- تصويبات RFC 5196
- RFC 3840
- RFC 3863
- RFC 4479
- RFC 3859
- RFC 4566
- RFC 3261
- RFC 2778
- RFC 3856
- RFC 3903
- RFC 5025
- Heng Lu ـ طبقات الواقع والقوة الرمزية
- Heng Lu ـ المواصفة الأولية الدنيا
- Heng Lu ـ أولوية الشفرة العاملة
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات
