الخلاصة

  • يطبّق RFC 5264 الفروق المقبولة على وثيقة كاملة مخزنة ضمن publication واحدة. وعندما تنتهي من دون refresh، تُمحى الحالة الكاملة الناتجة، لا آخر فرق وحده ولا نسخة سابقة يعاد بناؤها.
  • يجب أن يربط الإيصال القابل للتدقيق سلسلة entity-tag والجسم الكامل أو الجزئي وبصمتي ما قبل التطبيق وما بعده والمدة والتجديد وقرار المُركِّب وأثر المساهمة في الحالة المركبة.

بدأ الأثر عند غياب رسالة لا عند وصول رقعة

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

الحدث الأكبر لم يكن رقعة جديدة. كان غياب refresh قبل الموعد. عند انتهاء publication أزال المُركِّب مساهمة الجهاز كاملة، بما فيها كل التعديلات التي اندمجت منذ الحالة الأساسية.

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

الجزئي صفة للنقل لا لملكية الحالة

يعرّف RFC 3903 حالة أحداث رخوة لها عمر متفاوض عليه. تنشئ PUBLISH الحالة، ويطيلها refresh، ويغيرها modify، ويزيلها remove.

يضيف RFC 5264 طريقة اقتصادية لحمل التغيير. أول publication في المسار الجزئي تستخدم pidf-full كي تؤسس الحالة كاملة. وبعد ذلك يمكن إرسال pidf-diff أو حالة كاملة بديلة.

لا ينشئ ذلك عقد إيجار لكل عنصر XML. يبقى موضوع العمر هو publication. الفرق تعليمات انتقال، لا أصلاً مستقلاً يحتفظ به المُركِّب إلى الأبد.

وسم الكيان هو خط السببية

يعيد كل PUBLISH ناجح قيمة SIP-ETag. وعند تحديث publication أو تعديلها أو حذفها يضع العميل الوسم السابق في SIP-If-Match. هكذا يعرف المُركِّب الحالة التي يتوقع العميل تغييرها.

يملك PIDF الجزئي أيضاً سمة version، لكن RFC 5264 يتجنب استخدامها كنظام ترتيب ثانٍ. لو اختلفت النسخة مع الوسم لظهرت سلطتان متعارضتان بلا فرع خطأ محدد. لذلك تعتمد publication على الشرط والوسوم.

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

بعد التطبيق لا تبقى الرقعة دفتر تاريخ

ينفذ المُركِّب عمليات add وreplace وremove بالتسلسل على الوثيقة المحلية الكاملة. ثم يرسل النتيجة الكاملة إلى منطق التركيب كما لو كانت publication كاملة عادية.

ينص RFC 5264 على أن المُركِّب لا يحتفظ بسجل الرقع المطبقة بغرض الرجوع. لذلك لا توجد عودة بروتوكولية إلى نسخة أقدم بمجرد طرح آخر فرق. الاستعادة تحتاج إلى نشر حالة كاملة جديدة.

هذه ليست ثغرة في نظام نسخ؛ فالآلية لم تدّع أنها نظام نسخ أصلاً. غايتها تقليل النقل مع إبقاء انتقال الحالة محدداً.

الانتهاء يزيل المساهمة الحالية كلها

تنطبق تغييرات مدة الصلاحية على publication الكاملة بعد ترقيعها. فإذا لم يجددها PUA وجب على المُركِّب مسح كامل حالتها.

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

السؤال التشغيلي الصحيح ليس «كم تعيش هذه الرقعة؟» بل «ما publication التي تحمل أثرها، وهل ثُبِّت تجديد عمرها قبل الموعد؟»

الحالة الكاملة هنا محدودة بحدود publication

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

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

يجب أن يسمّي تقرير الحادث publication المحذوفة، والمدخلات التي بقيت، وبصمة الناتج المركب قبل الحذف وبعده. عبارة «مُسحت كل حالة الحضور» تتجاوز ما يثبته المعيار ما لم تُفحص المساهمات الأخرى.

الرفض قبل التثبيت ليس كالانتهاء بعده

لا يجوز أن يبدأ المسار بجسم pidf-diff من دون أساس كامل، ويجب رفضه. أخطاء معالجة الوثيقة تعطي 400 ويمكن أن تتضمن تشخيص RFC 5261. أما الأخطاء الأخرى قبل اكتمال معالجة publication فتعطي 500 وتعيد الحالة المحلية الأصلية.

في تلك الفروع لم تصبح المحاولة حالة معتمدة، ولذلك تُحفظ النسخة القديمة. أما الانتهاء فيقع بعد أن أصبحت التغييرات المقبولة هي الحالة الحالية، فيزيل publication بدلاً من رفض تعديل واحد بأثر رجعي.

السجل المهني يميز بين فشل الشرط، ورفض الجسم، وcommit ناجح، وحذف صريح، وانتهاء طبيعي. جمعها تحت «خطأ نشر» يلغي الدليل السببي.

إيصال الحالة المنشورة

للقرارات ذات العواقب احتفظوا بما يأتي:

  • Request-URI وحزمة الحدث والناشر وpresentity وهوية publication؛
  • entity-tag السابق وقيمة SIP-If-Match والوسم الجديد؛
  • نوع الجسم وبايتاته وبصمته ووقت استلامه؛
  • ترتيب كل عملية ترقيع ونتيجتها؛
  • بصمة الوثيقة الكاملة قبل المعالجة وبعدها؛
  • العمر المطلوب والممنوح والفعلي؛
  • موعد refresh وطلبه واستجابته وإقرار تثبيته؛
  • الحذف الصريح أو الانتهاء الطبيعي والحالة التي أزالها؛
  • المنشورات الأخرى وhard state التي ظلت نشطة؛
  • بصمة الحالة المركبة وإصدار السياسة والإشعار اللاحق؛ و
  • العرض أو القرار الآلي أو النتيجة البشرية اللاحقة.

يثبت entity-tag ترتيباً شرطياً. ويثبت commit حالة محلية. ويثبت الناتج المركب حساباً عند المُركِّب. أما وصول الحالة إلى watcher أو تصرف إنسان فيحتاجان دليلاً من طبقتهما، لا سلطة مستعارة من استجابة PUBLISH.

Sources