الخلاصة

  • أعاد RFC 3529 النتيجة العادية وخطأ XML-RPC كلاهما داخل BEEP RPY؛ ولم يحول خطأ التطبيق إلى BEEP ERR.
  • أثبت حل الاسم والقناة الجاهزة والخصوصية وهوية النظير وقائع محدودة، لا تفويض الطريقة ولا نجاحها ولا دوام أثرها.

يظهر الحد الفاصل في السؤال التالي: أين يوضع الخبر السيئ؟ في هذا البروتوكول أرسل العميل methodCall داخل BEEP MSG، وأعاد الخادم methodResponse داخل RPY. وإذا احتوت الاستجابة على fault خاص بـ XML-RPC بقي الإطار الخارجي RPY. هكذا نجح BEEP في نقل حكم سلبي أصدره التطبيق.

لم يكن RPY شهادة بنجاح الإجراء. كان دليلاً على أن نمط التبادل الأحادي حصل على استجابة مرتبطة بطلبه. أما التمييز بين قيمة عادية وfault فكان داخل وثيقة XML. ولو عدّ المشغل الإطارات فقط لسجل الإخفاق المعلن على أنه نجاح.

سبق الاستدعاء انتقال مستقل بين حالتين. بدأ profile في boot. أرسل الطرف البادئ bootmsg يحوي مورداً. إذا تعرف الخادم إلى المورد أعاد bootrpy وانتقل profile إلى ready. أما الرسالة سيئة الصياغة أو المورد غير المعروف فأنتجا error أو ERR من دون انتقال. ذلك إخفاق في تهيئة profile، لا في طريقة XML-RPC.

حتى ready لم يثبت صلاحية كل شيء. أثبت أن القناة ارتبطت بمورد معروف، لكنه لم يثبت وجود كل اسم طريقة، أو صحة الوسائط، أو امتلاك المتصل للتفويض، أو بقاء تغيير بعد العطل. بدأت مسؤولية التطبيق من تلك النقطة ولم تنتهِ عندها.

كوّن عنوان URI سلسلة أسبق. تحولت authority في xmlrpc.beep إلى serverName، وتحول path إلى مورد الإقلاع. عند غياب منفذ صريح أمكن البحث عن _xmlrpc-beep._tcp بواسطة SRV، ثم حل العنوان واستعمال المنفذ المسجل إذا لم يوجد سجل مناسب. نجاح DNS اختار وجهة فقط؛ لم يثبت وجود مستمع أو profile صالح أو طريقة ناجحة.

أضاف xmlrpc.beeps شرط ضبط جلسة BEEP للخصوصية قبل تشغيل profile. وعند استخدام TLS كان على العميل مطابقة authority مع هوية الخادم في الشهادة. عزز ذلك الدليل على النظير المحمي الذي تم الوصول إليه. لكنه لم يمنح حق استدعاء الطريقة، ولم يصدق قاعدة العمل، ولم يثبت أن النتيجة كتبت بصورة دائمة.

تكشف متطلبات الأمن تاريخ الوثيقة. فقد طلبت DIGEST-MD5 للمصادقة، وTLS مع RSA و3DES للسرية. غيرت وثائق SASL وTLS اللاحقة مكانة هذه الخيارات. لذلك لا يصح تحويل RFC 3529 إلى وصفة تشفير معاصرة؛ قيمته المستمرة في رسم حدود الأدلة.

للسجلات حدود مماثلة. نسق RFC profile لـ BEEP، ومخططي xmlrpc.beep وxmlrpc.beeps، واسم الخدمة xmlrpc-beep على TCP 602. يثبت سجل IANA وجود اسم مشترك ومرجع، ولا يثبت تطبيقاً أو انتشاراً أو حركة أو نتيجة طريقة.

جاءت التجربة في زمن كان BEEP يقترح جلسة قابلة لإعادة الاستخدام لقنوات متعددة، وكانت XML-RPC وSOAP تحملان استدعاءات في XML. وفر BEEP core إدارة الجلسة، ووفر mapping على TCP النقل والتحكم في التدفق، وقدّم SOAP over BEEP مثالاً مجاوراً. لكن كثرة الطبقات لم تمنح الطبقة الخارجية حق الحكم على الداخل.

احتاج تدقيق استدعاء واحد إلى ربط authority والوجهة وهوية النظير والقناة والمورد ورقم الرسالة ونوع الإطار، ثم قراءة methodResponse نفسها. وإذا غيرت الطريقة حالةً، لزم دليل إضافي يملكه التطبيق: معرف عملية أو إصدار أو سجل تدقيق أو قراءة لاحقة.

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

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

Sources