الخلاصة

  • RFC 1287 وثيقة معلوماتية من ديسمبر 1991 تسجل مناقشات IAB/IESG، وأربعة افتراضات للسنوات الخمس إلى العشر التالية، وخمسة مجالات لتطور معماري محتمل.
  • يناقش التجميع وصيغ العناوين والهجرة والاتصال الجزئي ووسطاء التطبيقات، ويحتفظ بخلافات معلنة. لذلك فهو دليل على أجندة وأسئلة مقترحة، لا على معيار مختار أو شبكة منشورة أو وصول أو تفويض أو نتيجة.

سجل النقاش لا يتحول إلى قرار بمجرد أن المستقبل معروف للقارئ

يصف RFC 1287 نقاشاً مشتركاً لـ IAB وIESG في يناير 1991، ثم Architecture Retreat في يونيو شارك فيها أعضاء من IAB وIESG وIRSG وضيوف. جُمعت تقارير المجموعات في الوثيقة وعُرضت في اجتماع IETF. هذا يثبت أن جهات تقنية رأت ضغوط النمو وقررت أن تجعلها موضوع عمل منظم.

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

الافتراضات الأربعة كانت اختباراً للخطط لا عقداً مع المستقبل

توافق المجتمع على بقاء TCP/IP وOSI معاً مدة طويلة، واستمرار تنوع الشبكات والخدمات، وإدخال شبكات تجارية وخاصة من دون توقع أن يقدم الناقلون العموميون الخدمة كلها، وضرورة أن تستطيع المعمارية التوسع إلى 10**9 شبكات. ويقول RFC نفسه إن الأس 9 ضبابي وإن التقديرات تراوحت بين 7 و10.

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

تسمية خمسة مجالات رتبت العمل ولم تحسمه

يجعل النص التوجيه والعناوين القضية الأكثر إلحاحاً، ثم يذكر المعمارية متعددة البروتوكولات، ومعمارية الأمن، والتحكم في المرور والحالة، والتطبيقات المتقدمة. في العناوين، يناقش تجميع الأرقام ضمن Autonomous Systems أو Administrative Domains، ومسارات عادية وخاصة، وصيغاً موسعة أو معاد استعمالها، وهجرة قد تحتاج إلى إعادة كتابة رؤوس وحالة في عناصر التحويل.

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

مشاركة الوصلة ليست تشغيلاً بينياً، ووسيط التطبيق ليس نتيجة كاملة

لا يفرض RFC إنترنتاً متعدد البروتوكولات بعدد محدد من الحزم، بل يقدم نموذجاً موجهاً بالعملية. ويفصل بين نواة TCP/IP، ومشاركة الوصلة، والتشغيل البيني للتطبيقات. في مشاركة الوصلة قد تتقاسم حزم مختلفة وسط النقل والواجهات من دون أن تتفاعل؛ ويسميها النص “ships in the night”.

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

الأجندة توزع أسئلة المسؤولية ولا تحل محل أصحاب القرار

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

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

المصادر وحدود الدليل

يستند هذا المقال إلى RFC 1287 — Towards the Future Internet Architecture. يدعم المصدر صفته المعلوماتية، ومناقشات 1991، والافتراضات، والمجالات الخمسة، وخيارات وخلافات العناوين، والنموذج متعدد البروتوكولات، والأعمال المقترحة. ولا يثبت معمارية مختارة أو معياراً أو نشراً أو حالة راهنة أو مساراً أو تخصيصاً أو تفويضاً أو خدمة قابلة للوصول أو نتيجة.