الخلاصة

  • يفرّق RFC 10020 بين مجموعة CoAP المستقبِلة ومجموعة التطبيق المشتركة للموارد ومجموعة الأمان؛ قد تتقاطع هذه المجموعات دون أن تصبح سكاناً واحدين أو سلطة واحدة.
  • يقدّم الطلب الجماعي المحمي دليلاً مفيداً عن الرسالة، لا برهاناً على أن كل هدف استلم وسمح ونفذ وأنتج الأثر المطلوب.

مجموعة CoAP هي نقاط نهاية معدة لاستقبال طلبات موجهة إلى عنوان IP متعدد البث ومنفذ UDP. أما مجموعة التطبيق فهي خوادم تشترك في موارد CoAP، ومجموعة الأمان هي سياق المشاركة في الاتصال المحمي. يسمح RFC 10020 بعلاقات متعدد إلى متعدد بينها؛ بل إن العميل الذي يرسل الطلب قد لا يكون عضواً مستقبِلاً في مجموعة CoAP.

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

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

الحماية تحسن دليل الرسالة لكنها لا تغير نوعه. يمكن أن يكون الطلب سرياً وسليماً وحديثاً ومنسوباً إلى عضو محدد، ومع ذلك لا يمنح صاحبه حق تشغيل كل مورد. قيمة RFC 10020 هي إبقاء طبقة التنسيق المشتركة نافعة من دون أن تدّعي امتلاك قرار التطبيق أو دليل الأثر. وهذا ينسجم مع قراءة Heng Lu: المواصفة الدنيا المشتركة تبدأ التعاون ولا تصادر الحكم المحلي الذي يجب أن يثبت عند التنفيذ.