الخلاصة
- وصفت RFC 1197 بنية ODA بأنها تمثيل تجريدي للوثائق المركبة؛ ولم يصبح التبادل عمليًا إلا بملف تطبيق للوثيقة وبخريطة تصل كياناته بكيانات كل برنامج مشارك.
- استخدم مشروع EXPRES، الممول من NSF، ملف NIST DAP مع قدرات Andrew وDiamond وInterleaf. تحدد RFC نطاق التجربة، لكنها لا تنشر قياسات للوفاء أو الانتشار أو نجاح رحلة ذهاب وعودة.
- حملت قواعد MIME وX.400 اللاحقة جسم ODA و
profileوclassفي سجلات منفصلة. حفظ البايتات لم يثبت أن الطرف الآخر فسّر الوثيقة أو عرضها أو حررها بالطريقة نفسها.
لم تكن الفقرة جزءًا من المفردات المشتركة تلقائيًا
نشرت RFC 1197 في ديسمبر 1990 باسم Mark Sherman. وتحفظ صفحة RFC Editor وصفحة IETF Datatracker حالتها بوصفها Informational؛ لم تحدد Internet Standard.
كان ISO 8613 Office Document Architecture، المرتبط أيضًا بـ CCITT T.410، قادرًا على تمثيل نص متعدد الخطوط وصور raster ورسوم هندسية. وظهر في معايير مرتبطة مثل X.400. كانت الغاية أوسع من تخزين أحرف أو نسخ نموذج محرر واحد.
لكن RFC وصفت ODA بأنه شديد التجريد. فهو يعرّف كيانات من نوع composite logical object classes، لا كيانات مألوفة لدى التطبيق مثل الفقرة. لا تعني العبارة أن ODA كان عاجزًا دائمًا عن حمل بنية تشبه الفقرة. تعني أن البنية العامة لم تختر وحدها الكائن اليومي الذي ستعتمد عليه التطبيقات المستقلة.
هذا التجريد يحمي المركز من سلطة منتج بعينه. لكنه يترك قرارًا يجب أن تتخذه جماعة التبادل: أي جزء من الإمكانات الواسعة سيكون وعدًا مشتركًا؟
اختار DAP الوعد، ثم نفذته خريطة عند كل طرف
سمت RFC هذا الاختيار document application profile، أو DAP. يحدد الملف كيانات مشتركة داخل ODA. وبعد ذلك يحتاج كل نظام إلى map بين تلك الكيانات وبين كياناته الأصلية.
القراران منفصلان. يقرر صاحب profile ما يدخل في العقد المشترك، ويقرر مطور البرنامج كيف يصبح ذلك العقد paragraph أو page أو graphic object أو style في نموذجه المحلي.
لذلك لا تكفي عبارة «يدعم ODA». قد يقرأ نظامان عائلة الصيغة ويستخدمان profile مختلفًا. وقد يعلنان profile واحدًا ثم يختلفان في optional property أو extension. يلزم تحديد profile ونسخته وclass والامتدادات وخريطة كل طرف.
تقليل المساحة ليس إضعافًا للمعيار. إنه تحويل عدد كبير من الخيارات إلى وعد يمكن اختباره. تبقى خصائص المنتج الخاصة نافعة محليًا، لكنها لا تصبح قابلة للنقل بمجرد وجودها داخل مستند ODA.
EXPRES بدأ من اختلاف التطبيقات لا من تطابقها
مولت National Science Foundation مشروع EXPRES لدراسة إرسال مقترحات بحثية إليها بالبريد الإلكتروني باستخدام ODA وسيطًا للتبادل. ضم المشروع مجموعتين من Carnegie Mellon University وUniversity of Michigan، وتعاونتا مع McDonnell-Douglas Aerospace Information Systems وNIST وInterleaf.
تقول RFC إن الاستراتيجيات استندت إلى NIST DAP وإلى الخصائص التي تقدمها Andrew وDiamond وInterleaf. يكشف ذلك سطح العمل: ملف مشترك واحد كان عليه أن يلتقي بثلاثة نماذج تطبيق، لا بثلاث نسخ متطابقة.
لكن المذكرة من صفحتين وتحيل التفصيل إلى كتاب صدر سنة 1991 وليس ضمن مجموعة المصادر هنا. لا تقدم معدل نجاح، ولا مقارنة rendering، ولا قياسًا لفقد البنية، ولا اختبار round trip، ولا نتيجة قبول لمقترح بعينه.
أسماء المشاركين تثبت منشأ التجربة المذكورة، لا جودة دائمة ولا دعمًا حاليًا. كما تفصل المذكرة رأي مؤلفي الكتاب عن سياسات المؤسسات المشاركة.
وضع MIME اسم profile إلى جانب اسم النوع
في 1992 عرفت RFC 1341 subtype هو application/oda. كان يعني أن body يستخدم معايير ODA وتمثيل ODIF. وكان على Content-Type أيضًا أن يحدد DAP بواسطة parameter اسمه profile؛ والمثال profile=Q112.
وجود الاسمين يحدد وظيفتين. subtype يعرف عائلة التمثيل، وprofile يضيق العقد داخلها. لو كان اسم ODA يحسم المعنى التطبيقي كله لما احتيج إلى parameter إضافي.
مع ذلك بقي header تصريحًا. يساعد المستقبل على اختيار handler أو إعلان عدم الدعم. لا يثبت أن Q112 منفذ على نحو صحيح، أو أن كل entity معروفة، أو أن layout والبنية القابلة للتحرير بقيا كما أراد المرسل.
RFC 1341 وثيقة obsolete اليوم؛ استخدامها هنا تاريخي لتحديد فصل type عن profile، لا لتقديم إرشاد MIME معاصر.
نسخت البوابة الجسم وعيّنت بيانات أخرى حوله
حددت RFC 1494 في 1993 تكافؤات بين أجسام X.400 وMIME. وسمت تحويل ODA body بأنه “Byte copy”: لا حاجة إلى إعادة كتابة بيانات ODA نفسها.
لكن القاعدة نفسها عيّنت document-application-profile في X.400 إلى profile في MIME، وعيّنت document-architecture-class إلى formatted أو processable أو formatted-processable. كانت هوية الجسم واسم profile وclass ثلاث حقائق مختلفة.
إذا غابت parameters في اتجاه MIME إلى X.400، استعملت القاعدة Q112 وformatted-processable افتراضيًا. كان للبوابة أن تبحث عنهما داخل الوثيقة، لكنها لم تُلزم بذلك لأن document characteristics الداخلية اختيارية.
يجعل default السلوك محددًا، لكنه لا يكتشف اختيارًا لم يسجله المرسل. يجب أن يبين السجل هل القيمة declared أم extracted أم defaulted، وإلا صار قرار البوابة ادعاءً منسوبًا إلى المؤلف.
كما أن Byte copy يثبت حدًا صغيرًا: لم يغير relay تلك البايتات. لا يثبت دعم المستقبل، ولا تفسير profile، ولا وفاء الخريطة المحلية.
لم تلغ عبارة “Conversion: None” الحاجة إلى التفسير
جمعت RFC 2161 في يناير 1998 تعريفات ODA في MIME وX.400. كانت Experimental ونفت أن تكون Internet Standard من أي نوع. وأبقت profile وclass وQ112 والقيم الثلاث للclass.
كتبت “Conversion: None” لبيانات ODA. المقصود أن body يبقى ODA، لا أن metadata أو defaults أو تفسير الطرف المستقبل اختفت. قد يبقى الملف مطابقًا، بينما تنتج التطبيقات هياكل أصلية مختلفة.
أشارت فقرة الأمن إلى أن ODA bodies تميل إلى بنى معقدة يصعب اكتشاف قدراتها، وأن extensibility تسمح بأجزاء محتوى جديدة قد تغير التهديد بمرور الوقت. وقالت أيضًا إنه لم تكن هناك آنذاك مخاطر معروفة خاصة بـ ODA. تبرر العبارة جرد القدرات وإعادة التقييم، لا اختراع exploit تاريخي.
يمكن أن يبقى outer type ثابتًا بينما يتغير profile وextension set وparser وadapter. لذلك يجب ربط الدعم بالنسخة والوثيقة والنتيجة المرصودة.
كان إثبات الوثيقة يمتد إلى ما بعد decoding
تبدأ سلسلة الأدلة من ODIF bytes، ثم type، ومصدر profile، وclass، وفعل gateway، وقدرة المستقبل، والخريطة المحلية. بعدها يأتي rendering والبنية المحفوظة وeditability وround trip والنتيجة المؤسسية.
يثبت hash عدم تغير الملف. يحدد profile النطاق المعلن. تسجل نسخة adapter القواعد المستخدمة. وحدها مقارنة الناتج تبين ما حدث للبنية والصفحة. كل سجل مفيد ضمن مرتبته ولا يستطيع استعارة سلطة السجل اللاحق.
لم تكن فقرة RFC 1197 اتهامًا للمعايير المجردة. كانت وصفًا صريحًا لتوزيع العمل. تحمل architecture شكلًا مشتركًا، ويختار profile لغة مشتركة، وتنجز الأطراف mapping، ويبقى للمستقبل قرار ما إذا كانت الوثيقة المطلوبة قد وصلت.
المصادر والحدود
- RFC 1197 — Using ODA for Translating Multimedia Information
- سجل RFC Editor لـ RFC 1197
- سجل IETF Datatracker لـ RFC 1197
- RFC 1341 — MIME
- RFC 1494 — Equivalences between 1988 X.400 and RFC-822 Message Bodies
- RFC 2161 — A MIME Body Part for ODA
لا تثبت المصادر استعمالًا حاليًا أو حصة سوق أو جودة منتج أو وفاءً مقاسًا لـ EXPRES أو حادثًا أمنيًا معروفًا أو نجاح مقترح محدد.
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات
