الخلاصة

  • في نموذج الحضور الذي شارك Jonathan Rosenberg في صياغته، تعني OPEN في سياق الرسائل الفورية أن صندوق الوارد المرتبط جاهز لقبول رسالة. ولا تثبت مكان الشخص أو هويته أو انتباهه أو رغبته في الرد.
  • قد تتضمن وثيقة PIDF عدة وحدات tuple، بل قد تحمل الوحدة الواحدة OPEN وأخرى CLOSED لعنوان الاتصال نفسه. لذلك يفصل RFC 4479 بين الشخص والخدمة والجهاز بحسب الشيء الذي تصفه المعلومة.
  • التصريح للمراقب، ووصول الإشعار، ومصدر الحالة، وقبول الخدمة، ونشاط الجهاز، وتسليم الرسالة وعرضها وقراءتها والرد عليها إيصالات مختلفة. النقطة الخضراء مفيدة فقط إذا لم تنسب إلى الإنسان ما قاسه النظام في الخدمة.

عندما أجابت النقطة عن سؤال غير مطروح

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

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

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

OPEN تصف صندوقاً مستعداً للاستقبال

يقدم RFC 2778، من تأليف Mark Day وJonathan Rosenberg وHiroyasu Sugano، نموذجاً معلوماتياً ومفردات مشتركة، لا بروتوكول تشغيل بيني مكتمل. ويميز بين presentity التي تنشر المعلومات، وخدمة الحضور التي توزعها، وwatcher الذي يستقبلها، وخدمة الرسائل، وinstant inbox، وprincipal في العالم الخارجي.

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

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

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

PIDF لا تفرض حقيقة موحدة بالقوة

يحدد RFC 3863 صيغة Presence Information Data Format. تحتوي الوثيقة على وحدات tuple، لكل منها status ويمكن أن تلحق بها contact وtimestamp وملاحظات وامتدادات. والقيمة الأساسية open أو closed.

يسمح تعدد الوحدات بفصل البيانات القادمة من أجهزة مختلفة، أو تطبيقات متعددة على الجهاز نفسه، أو أزمنة مختلفة. ويجيز النص صراحة أن تقول وحدة OPEN وأخرى CLOSED حتى حين تحملان contact نفسه.

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

أما id الخاص بالـtuple فهو سلسلة عشوائية للتمييز والربط داخل presentity. لا يمنحه RFC 3863 معنى لهوية الإنسان أو صحة الجهاز. استعماله كمفتاح دائم للشخص إضافة لا يقدمها المعيار.

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

الإذن بالمشاهدة ليس حالة من تتم مشاهدته

يستخدم RFC 3856، الذي كتبه Rosenberg، طريقتَي SIP SUBSCRIBE وNOTIFY لنقل الحضور. يجب على presence agent مصادقة كل طلب اشتراك، ثم اتخاذ قرار تفويض مستقل. وقد يكون الاشتراك ناجحاً أو مرفوضاً أو معلقاً، وتحمل الإشعارات حالة الاشتراك وحالة presentity.

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

للخصوصية أثر مباشر. قد تُحجب بيانات نشاط الجهاز عمداً. وقد ينتهي اشتراك لأن حق الوصول أُلغي، لا لأن الخدمات توقفت. وإذا حوّل المنتج غياب الحقل إلى «idle» أو انتهاء المراقبة إلى «الشخص offline»، فإنه يعاقب اختيار عدم الإفصاح باستنتاج سلبي.

ثلاثة مكونات تمنع انتقال الصفة إلى الكائن الخطأ

يقسم RFC 4479، من تأليف Jonathan Rosenberg، presentity إلى person وservice وdevice. المبدأ المركزي أن الصفة تنتمي إلى الشيء الذي تصفه، لا بالضرورة إلى الشيء الذي أبلغ عنها.

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

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

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

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

نشاط الجهاز يرفع الاحتمال ولا يثبت الانتباه

يضيف RFC 4480، من تأليف Henning Schulzrinne وVijay Gurbani وPaul Kyzivat وRosenberg، حضوراً غنياً إلى PIDF. يمكن لعنصر user-input أن يقول active أو idle وفق عتبة زمنية قابلة للضبط. وقد يراقب تطبيقاً واحداً أو الجهاز بأكمله، ويمكن حذف وقت آخر إدخال.

يقر النص بأن tuple لم يُستخدم منذ مدة قد يبقى OPEN. ويمكن للـwatcher تفضيل عنوان مفتوح استُخدم حديثاً. الجمع بين الانفتاح وحداثة النشاط يقدّر احتمال أن يجيب المستخدم.

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

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

نسبة العمل إلى Rosenberg تحتاج الدقة نفسها

في لقطة 9 سبتمبر 2026، أدرج ملف Jonathan Rosenberg في IETF اثنين وسبعين RFC ولم يذكر أدواراً نشطة. ينسب RFC 3856 وRFC 4479 إليه وحده، بينما RFC 2778 وRFC 4480 عملان جماعيان. هذه سجلات مساهمة، لا سلطة على إجماع IETF أو منتجات بعينها أو سلوك مستخدميها.

توفر صفحة المؤلف الرسمية في Five9 والصورة العامة مرجع الهوية للصورة التحريرية. ولا تستخدم السيرة الأقدم لإثبات منصب حالي. صلاحية المصدر للصورة لا تمنحه صلاحية زمنية لكل ادعاء مهني.

سجل من الأفعال المحددة

يمكن ترتيب السلسلة هكذا: تمت مصادقة watcher؛ فُوض برؤية معينة؛ وصل NOTIFY؛ نشرت service tuple حالة OPEN؛ رصد الجهاز نشاطاً حديثاً؛ قبلت الخدمة الرسالة؛ سلمها العميل وعرضها؛ قرأها الشخص؛ جاء الرد.

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

ليس المطلوب إطفاء النقطة الخضراء، بل إعادة اسم صاحبها: الخدمة.

المصادر