الخلاصة

  • أصلح RFC 3504 ثلاثة أسطح تنفيذية في IOTP v1: نحو DTD، واستمرار المعاملة الأصلية بعد المصادقة، وقائمة أنواع المحتوى التي يستطيع توقيع IOTP تعريفها.
  • يثبت تطبيق التصويب التوافق مع المواصفة المصححة، ولا يثبت نجاح المصادقة أو سلطة الموقّع أو تفويض الخصم أو التسوية أو التسليم أو الانتشار.

يبدو استبدال «أُعيد بدؤها» بـ«استمرت» تحريراً بسيطاً في النثر. في آلة حالات المعاملة، تحدد الكلمة هل يحتفظ النظام بالسياق التجاري الذي وصل إلى بوابة المصادقة أم يتصرف كأن التبادل بدأ من جديد.

نُشر RFC 3504 في مارس 2003 بوصفه Informational، وجمع أخطاء ظهرت بعد مواصفات IOTP الإصدار الأول، ولا سيما RFC 2801 الكبير. كان IOTP إطار تجارة مستقلاً عن نظام الدفع، ويمكن أن تتوزع فيه المتجر ومعالجة الدفع والتسليم وخدمة العميل على مؤسسات مختلفة.

جعل هذا التوزيع الدلالة المشتركة مهمة. حين تعبر المعاملة حدود المؤسسات، يجب أن تحتفظ الرسائل بهوية المعاملة والفعل. وقد يحوّل اختلاف في النحو أو الانتقال ادعاءين متساويين بدعم RFC واحد إلى سلوكين مختلفين.

تعلق الإصلاح الأول بـPackagedContent. بدّلت DTD الأصلية نوعي Name وContent. جعل التصويب Name من نوع NMTOKEN وContent من نوع CDATA. وكان هذا الوعاء يظهر في تحديات المصادقة والطلبات والعلامات وبيانات مخطط الدفع والإيصالات والتسليم.

قد يفرض الكود المولد من التعريف القديم قيداً معجمياً على القيمة الخطأ. يقبل طرف قيمة ويرفضها آخر. وهكذا أخفت عبارة «يدعم RFC 2801» سؤالاً عن النسخة الفعلية للنحو.

كان الإصلاح الثاني أقصر: استخدم العنصر Attribute الصيغة غير الصحيحة ( ANY ) بدلاً من ANY. لا يملك المدقق سلطة تخمين النية. ومن دون تصويب مشترك يمكن لكل فريق أن يخترع رقعة أو يعطل التحقق أو يضيف استثناء غير متوافق.

ظل اجتياز DTD المصححة إيصالاً بنيوياً فقط. يثبت الأسماء والأنواع والترتيب، ولا يثبت صدق البيانات أو سلطة الطرف المقابل أو حركة المال.

مسّ الإصلاح الثالث الحالة. عند دمج المصادقة بمعاملة IOTP أخرى، قال النص إن المعاملة الأصلية يعاد بدؤها بعد النجاح. غيّر RFC 3504 ذلك إلى استمرارها.

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

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

كان في قائمة أنواع التوقيع نقص أيضاً. شملت العرض والدفع والتسليم والمصادقة وping، وأغفلت AuthenticationStatus وInquiryRequest وInquiryResponse. أضاف RFC 3504 الأنواع الثلاثة وسمح لأي دور باستخدامها.

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

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

لذلك يمكن أن يكون التصويب اعتماداً تنفيذياً. ينبغي للسجل أن يحدد الوثيقة الأساسية ومجموعة التصويبات وأثر parser أو schema والاختبارات. قد تصف عبارتا توافق تحملان الرقم نفسه آلتين مختلفتين.

وتظهر الحدود في البيانات الوصفية. لا يعلن رأس RFC 3504 عبارة Updates: 2801. ويقول erratum 2947 لدى RFC Editor، المحفوظ لتحديث الوثيقة، إن العلاقة كان يجب أن تظهر بسبب التغييرات المعيارية. غيّر النص التنفيذ قبل أن تعبّر علاقة الوثيقتين عن قوته كاملة.

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

يجيب النحو عن قابلية التفسير، والاستمرار عن السياق الباقي، والنوع عما يدعي التوقيع تغطيته. لا يعني أي منها أن الشراء دُفع ونُفذ.

المصادر