الخلاصة

  • اشترط RFC 3354 أن يسمح IOTP v2 المقترح للأطراف باقتراح أي تسلسل لخطوات التجارة، لكن الاقتراح لم يكن موافقة على الدفع ولا دليلاً على تنفيذ الخطوات.
  • ظلت الموافقة المحدودة على مشتريات مقبلة، وإشعار الشحن، وتفويض نظام الدفع، والخصم، والتسوية، والإيصال المستخدم في النزاع حقائق مستقلة.

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

صدر RFC 3354 في أغسطس 2002 بوصفه وثيقة Informational تحدد متطلبات نسخة ثانية متصورة من Internet Open Trading Protocol. كان IOTP v1 ينظم التجارة الإلكترونية من خلال أدوار وكتل ورسائل. أراد العمل الجديد الحفاظ على الأساس مع تجاوز النموذج الضيق الذي يجعل المعاملة دفعة واحدة يعقبها تسليم واحد. كان ينبغي أن تتمكن الأطراف من اقتراح تسلسل اعتباطي للخطوات.

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

كما أن RFC 3354 لم يكن مواصفة IOTP v2 النهائية. فقد قسم الأفكار إلى ما ستتضمنه المواصفة، وما قد تتضمنه، وما يقع خارج النطاق. يسجل تاريخ مجموعة TRADE في IETF اكتمال محطة متطلبات v2. هذا دليل على إنجاز عمل المتطلبات، لا على اكتمال بروتوكول أو تنفيذ أو نشر.

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

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

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

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

يكشف مثال الشحن الفصل نفسه من جهة الحدث. كان من الممكن أن تسمح رسالة موسعة بين الخوادم لـ Delivery Handler بإبلاغ Payment Handler بأن البضاعة شُحنت. وقد تصبح الرسالة شرطاً سابقاً لخصم بطاقة. الشرط السابق ليس أمراً. إنه يثبت فقط أن جهة معرّفة ادعت حالة معينة ضمن نطاق المصادقة.

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

توضح الوثائق المجاورة الطبقات. عرف RFC 2801 معاملات IOTP v1 وأدوارها ومعرّفاتها والمعالجة عديمة الأثر المكرر. مقاومة الرسائل المكررة لا تمنح تسلسلاً جديداً سلطة شراء. واستخدم RFC 2802 manifest لتحديد العناصر التي يغطيها التوقيع. يصادق التوقيع الصحيح على المادة المحددة، لكنه لا ينشئ موافقة مفقودة.

نقل RFC 2935 رسائل IOTP عبر HTTP، ووحد RFC 3106 أسماء حقول التجارة الإلكترونية. نجاح النقل أو توحيد المفردات لا يثبت سلطة المحتوى. وفر RFC 3275 قواعد XML Signature، بينما وفر RFC 2246 حماية قناة TLS.

أوضح RFC 3354 أن IOTP لا يملك آلية سرية بذاته، وأنه يعتمد على TLS أو IPsec، بينما تعتمد حماية الدفع على نظام الدفع المختار. لذلك فالقناة السرية والمحتوى الموقع وموافقة العميل والتفويض المالي خصائص مرتبطة لكنها غير متبادلة. وصول رسالة عبر قناة آمنة لا يمنحها حق الخصم.

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

استُبعدت القضايا القانونية والتنظيمية من النطاق. ومن ثم لا يثبت التوافق التقني قابلية العقد للإنفاذ أو حماية المستهلك أو حق الخصم في ولاية قضائية. هذا حد مؤسسي معقول: لا تستطيع لغة رسائل عالمية أن تجمع كل مصادر الشرعية المحلية.

قدم RFC 3538 لاحقاً ملحق SET لـ IOTP v1، وحدد RFC 3867 واجهة بين قلب تطبيق IOTP ووحدات الدفع. تؤكد الواجهة أن التنسيق والتنفيذ قد يحتفظان بحالات وأخطاء وإيصالات مختلفة. لا تثبت أي من الوثيقتين أن متطلبات v2 صارت بروتوكولاً منشوراً.

تكمن القيمة التاريخية لـ RFC 3354 في أنه وسع المرونة من دون اختلاق السلطة. التسلسل خطة؛ والموافقة المستقبلية منحة محدودة؛ وإشعار الشحن دليل حدث؛ والتوقيع يغطي محتوى معيناً؛ وTLS يحمي القناة؛ ونظام الدفع يقرر التفويض والتنفيذ والتسوية؛ أما الإنصاف عبر خدمة العملاء فيأتي بعد ذلك.

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

Sources