الخلاصة

  • اقترح RFC 1865 استبدال مكونات النقل بين أنظمة EDI القائمة ببريد الإنترنت. وكان تسليم SMTP المباشر والمضمون ينتهي عند نظام الشريك، مع بقاء اتفاق الشريكين التجاريين.
  • وضع RFC 1767 كائنات X12 وEDIFACT وEDI-consent داخل MIME من دون تغيير بنيتها أو معناها ومن دون توفير الأمن بذاته.
  • جمع RFC 3335 وRFC 4130 بين Message-ID وMIC والتوقيع وMDN، ومع ذلك كان الإيصال الموقع قادراً على تسجيل فشل، وبقيت صلاحية المعاملة قراراً بين الشريكين.

ما استلمه الخادم ليس ما وافقت عليه الشركة

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

صدر RFC 1865 في يناير 1996 بوصفه وثيقة Informational تشرح الإنترنت لمجتمع EDI. لم يقترح التخلص من برامج الأعمال أو مترجمات EDI؛ بل وضع وحدات الإنترنت مكان مكونات الاتصال.

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

بقي EDI داخل علاقة ثنائية

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

كما بقيت اتفاقات الشركاء التجاريين الثنائية. أمكن لعنوان الإنترنت أن يحل محل اسم صندوق خاص، لكنه لم يحدد وحده الهوية أو المهلة أو معالجة التكرار أو الأثر القانوني. واشترط RFC 1767 اتفاقاً ثنائياً صريحاً لاستخدام EDI-consent.

فتح مسار النقل لم يفتح سلطة إلزام الشركة. وقد يقلل الإنترنت الاعتماد على شبكة قيمة مضافة مركزية، لكن المسؤولية بقيت موزعة وفق اتفاق الطرفين.

حدّد MIME الغلاف لا القرار

أنشأ RFC 1767 أنواع MIME لـ EDI-X12 وEDIFACT وEDI-consent. يبدأ المسار من برنامج الأعمال، ثم مترجم EDI، فمعالج MIME، فتقديم البريد وSMTP. وعلى الطرف الآخر يُنزع الغلاف وتُترجم البيانات قبل وصولها إلى المعالجة التجارية.

أكد RFC أنه لا يغير صيغة EDI أو معناها ولا يقدم آلية أمنية بذاته. يحدد MIME نوع الكائن وطريقة نقله، لكنه لا يثبت صحة المحتوى أو مصدره أو عدم تغييره أو تفويض مرسله أو قبول المعاملة.

عندما تنجح قابلية التشغيل البيني يبدو وكأن العملية كلها اكتملت. تسلسل RFC يمنع هذا الاختصار، لأنه يبقي الأعمال السابقة للنقل واللاحقة له ظاهرة.

قد يكون الإيصال الموقع دليلاً على الفشل

شرح RFC 3335 التوقيع والتشفير وMDN الموقع. يربط Message-ID الأصلي الرد بالإرسال، ويمثل MIC المحتوى الذي قال المستقبل إنه استلمه، وينسب التوقيع التصريح إلى المستقبل وفق قواعد المفتاح والشهادة. وبعد ذلك يجب على المرسل التحقق من الإيصال.

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

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

وعند غياب الإيصال الموقع المطلوب، تُركت صلاحية المعاملة للشريكين لحلها، ويرجح ألا تُعد المعاملة صالحة. دعمت آليات النقل حاجة الإثبات، لكنها لم تعرف عدم الإنكار بنفسها لأنه متطلب تجاري أو قانوني.

العرض لا يثبت الفهم

سمح RFC 3798 للمستقبل بتجاهل طلب MDN، وحذر من أن disposition من نوع displayed لا تضمن قراءة المحتوى أو فهمه.

يلزم الانضباط نفسه في الأتمتة. قبول SMTP ليس معالجة EDI. وMDN ليس إقرار التطبيق. والتوقيع ليس تفويضاً تجارياً. وقد لا يكون الإقرار الوظيفي قبولاً تعاقدياً. لكل انتقال فاعله ودليله.

يحفظ السجل القابل للمراجعة الكائن الأصلي، وقبول البريد أو تسليمه، وMDN المرتبط وMIC، ونتيجة مترجم EDI، وإقرار التطبيق، والقرار التجاري الصادر عن جهة مخولة. قد تختلف الأسماء وعدد الملفات، لكن لا يجوز لدليل مرحلة أن يمارس سلطة المرحلة التالية بصمت.

نقل موزع ومسؤولية متفق عليها

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

مع ذلك ظل الشريكان يحددان العناوين والشهادات ومهل الإيصالات وسياسة الإعادة والحفظ وتسوية النزاع. اللامركزية غيّرت الطريق، لا المسؤولية.

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

المصادر