الخلاصة

  • أتاحت RFC 1440 لمرسل لا يملك حساباً على المضيف الهدف أن يدفع ملفاً غير بريدي إلى برنامج استقبال دائم.
  • كان NULL ACK يقر أمراً واحداً فقط، بينما أنهى EOF أو إغلاق الاتصال النقل من دون إثبات قبول المستلِم أو فتح الملف أو استعماله.
  • نقلت سهولة الإرسال إلى الطرف المستقبل مسؤوليات السعة والاحتفاظ والمصادقة والحجر وقرار المستخدم أو خدمة العمل الآلية.

وصل الطرد قبل أن يطلبه صاحبه

يبدأ التصور المعتاد لـ FTP من المستخدم الذي يفتح اتصال التحكم ويقدم بيانات الوصول عند الحاجة ويطلب عملية على الملفات. قلب SIFT/UFT نقطة البداية. لم تعن كلمة Unsolicited أن الملف غير مرغوب فيه؛ بل إن الطرف المستقبل لم يبدأ المعاملة.

استندت الفكرة إلى شبكات NJE مثل BITNET، حيث أمكن إرسال ملف خارج تجربة البريد الإلكتروني. شبه المؤلف ذلك بطرد لا برسالة. لم يحتج المرسل إلى حساب أو تسجيل على المضيف الهدف، وكان بوسع المستلِم الرجوع إلى الملف لاحقاً.

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

حمل اتصال واحد ملفي تحكم وبيانات

استمع البرنامج إلى منفذ TCP رقم 608. مرت أوامر ASCII والبيانات الثنائية عبر المقبس نفسه. وصفت الوثيقة تدفق المهمة بأنه جمع ملف تحكم وملف بيانات؛ يتجاوران في النقل من دون أن يصبحا حقيقة واحدة.

حدد FILE المرسل والحجم الدقيق أو التقريبي وبطاقة مصادقة اختيارية. عين USER مستخدماً محلياً أو خدمة، وحدد TYPE طريقة التمثيل. وجب وصول الأوامر الثلاثة قبل DATA. أضاف NAME وDATE سياقاً، وأغلق EOF الملف، وطلب ABORT التخلص من الجزء الناقص، وأنهى QUIT المهمة.

استطاع المستقبل تخزين الأوامر والجسم في ملفين منفصلين كي لا يفسر المستمع كل صيغة غريبة فوراً. نشأ مقابل ذلك واجب ربط: أي تحكم يصف أي جسم، وكم بايتاً كُتب، وما القرار الذي اتخذ لاحقاً.

أجاب البايت الصفري عن سؤال واحد

بدأ الرد الإيجابي ببايت قيمته صفر. أقر NULL ACK أمراً واحداً فقط. لم يصدق المعاملة كلها ولم يمنح الإذن لأي استعمال لاحق.

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

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

بدأت ساعة جديدة داخل مساحة الانتظار

وُضع الملف الواصل في مساحة مشتركة مثل /usr/spool/uft. بقي هناك حتى يقبله المستلِم أو يرفضه، أو يحذفه النظام بسبب العمر. عنت كلمة عامة مساحة مشتركة، لا وصولاً مفتوحاً. حددت الإدارة المحلية الحجم الأقصى ومدة الاحتفاظ.

لذلك اختلفت ثلاثة أزمنة: نهاية النقل، ومدة حيازة المضيف، ووقت قرار المستلِم. قد ينتهي TCP الآن ويبقى الجسم أياماً ثم ينقضي من دون قرار. لا يحق لشاشة واحدة أن تختصر ذلك في «تم التسليم».

الحذف بسبب العمر ليس رفضاً من المستخدم. واختفاء الملف لاحقاً لا يثبت أنه استُعمل؛ فقد عُزل أو نُظف أو فُقد أو رُفض. لا يغلق هذا الغموض إلا سجل تصرف يحدد الفاعل والوقت والنتيجة.

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

صنعت الدفعات نقاط توقف

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

أما الوضع السريع فحذف الحجم. استمر الخادم في القراءة حتى يغلق العميل الاتصال، ولم يرسل EOF أو QUIT. لم يكن ABORT ممكناً أثناء التدفق. أصبح عمر المقبس نفسه حد البيانات.

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

قد يكون USER آلة لا إنساناً

سمح USER باسم محرك خدمة أو طابور أعمال يظهر كمستخدم زائف. عندئذ قد يتحول الملف المحفوظ إلى مدخل لعمل آلي.

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

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

غيّر مسار MIME نقاط الإثبات

لم تكن كل الأجهزة متصلة مباشرة بـ IP، ولم يرد كل مشغل برنامجاً جديداً، وقد يسمح الجدار الناري بالبريد فقط. لذلك أمكن حمل UFT داخل MIME. صارت الأوامر معاملات لـ application/octet-stream، وحُول الجسم إلى Base64 داخل البريد.

حل MIME مشكلة التمثيل والعبور. لم يتخذ قرار المستلِم. كما استبدل تحية TCP وإقرارات الأوامر والدفعات بحالات التخزين والتمرير في البريد. وإذا توفرت مصادقة، فقد تركتها RFC لنظام البريد نفسه.

بقي البروتوكول تجريبياً. حافظت RFC 1499 على هذا الوصف، ولا يزال سجل IANA يعرض sift-uft والمنفذ 608. يثبت السجل وجود تخصيص موثق، لا وجود انتشار أو خدمة حالية.

لكل فعل صاحبه

تكمن قيمة RFC 1440 في سلسلة الأفعال: يبدأ المرسل، ويقبل المستمع، ويستلم المضيف، وتحفظ المساحة، ويقبل المستلِم أو يرفض، ثم قد يعمل تطبيق. لا يملك أي فعل سابق صلاحية الادعاء بأن التالي وقع.

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

المصادر