الخلاصة

  • عرّفت RFC 2122 عنواناً لخدمة وسائط متعددة تفاعلية لا لكائن بيانات؛ وكان عميل VEMMI يحافظ عادة على جلسة TCP مستمرة عبر المنفذ 575.
  • أمكن للعنوان اختيار الخدمة وحمل معاملات مسماة، لا اسم المستخدم وكلمة المرور. ظل دعم المتصفح والتحقق من الهوية وVEMMI_Open مراحل لاحقة مستقلة.
  • أدّى application/vemmi دوراً منفصلاً لنقل الكائنات، وبعضها برامج قابلة للتنفيذ. لذلك كان الاستلام والموافقة والتنفيذ والنتيجة الآمنة سجلات مختلفة.

عنوان لخدمة

نُشرت RFC 2122 في مارس 1997 بوصفها Proposed Standard، وعرّفت مخطط VEMMI للواجهة المحسنة بين الإنسان والآلة لخدمات الفيديوتكـس والاسترجاع متعدد الوسائط. وتقول بوضوح إن العنوان لا يحدد كائن بيانات، بل خدمة تفاعلية.

أتاح الشكل vemmi://<host>:<port>/<vemmiservice>;<attribute>=<value> تحديد المضيف والمنفذ والخدمة وأزواج السمة والقيمة. كان 575 هو المنفذ الافتراضي، مع إمكان تجاهل منفذ آخر في العنوان لأسباب أمنية. تصف هذه الحقول محاولة بدء؛ ولا تثبت حل الاسم أو وجود مستمع أو توفر الخدمة أو قبول المعاملات.

حافظ VEMMI عادة على وصلة TCP/IP طوال الجلسة لإدارة الكائنات وإبلاغ أفعال المستخدم. كان الويب نقطة لقاء، لا بيئة التشغيل ذاتها.

بدأ الحوار بعد النقرة

بعد الاتصال، استطاع الخادم طلب service: وusername: وpassword:. يجيب العميل من العنوان أو الإعداد أو بعد سؤال المستخدم. ويبقى الطرف في الوضع القياسي المتوافق مع videotex أو telnet حتى يستقبل VEMMI_Open.

حظرت الوثيقة وضع اسم المستخدم وكلمة المرور في العنوان، فاختيار الخدمة ليس إثبات هوية. أما 200 OK و401 Unauthorized فهما مثالان لمسارين، لا قياسان ميدانيان. اختيار الرابط، وتشغيل المعالج، وفتح TCP، وقبول الهوية، وبدء الجلسة خمسة إيصالات مستقلة.

قد يفشل المتصفح قبل بلوغ VEMMI

كان الدعم مدمجاً أو موفراً ببرنامج مرافق. من دونه قد يرفض المتصفح المخطط المجهول، أو يسيء فهمه كعنوان نسبي ويرسله إلى خادم HTTP الذي قد يعيد not found. وجود vemmi:// في HTML لا يثبت حتى وجود معالج محلي.

اقترحت RFC رابطاً منفصلاً لتنزيل العميل، أو التعرف على الطلب النسبي الخاطئ، أو الاستدلال من Accept: application/vemmi. لكنها لم تقس مدى تنفيذ ذلك. الاقتراح المعياري ليس دليلاً على الانتشار.

كان نقل الكائن مساراً آخر

سمح application/vemmi بنقل كائنات عبر HTTP أو البريد من دون فتح الجلسة المستمرة، وقد يحمل ملفاً نصياً فيه عنوان VEMMI. أطلق المخطط طريقاً إلى خدمة، بينما وصف نوع الوسائط كائناً للنقل وفك الترميز.

لا تزال IANA تسجل vemmi مخططاً دائماً وapplication/vemmi والمنفذ 575. هذه حقائق سجلية وليست قياسات تشغيل. لا تثبت صيانة برنامج أو خدمة حية أو حركة أو توافقاً أو تبنياً.

احتاج التنفيذ إلى موافقة مستقلة

أمكن لكائنات metacode حمل أوامر، ولكائنات operative أن تكون برامج تُشغّل على جهاز العميل. أوصت RFC بقوة بتعطيل التشغيل التلقائي أو طلب موافقة المستخدم أولاً.

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

سمحت RFC 1738 لكل مخطط بتعريف طريقة وصوله. وتُظهر RFC 2122 نتيجة محددة: صفحة ويب تسلّم إلى بيئة ذات حالة. وتمنع قراءة Running-Code Primacy منح الوثيقة أو التسجيل سلطة التنفيذ الفعلي.

السجل الدقيق هو: تسمية، تعرف، تسليم، اتصال، اختيار، تحقق، فتح، نقل، موافقة، تنفيذ، ملاحظة. عبارة «نجح الرابط» تمحو الحدود التي جعلت RFC 2122 مهمة تاريخياً.

المصادر