الخلاصة

  • اقترح RFC 1681 ترميز فئة من يتحمل الكلفة، أو مؤشر إلى جدول خوارزميات احتسابها، في عنوان الوجهة كي يقرر العميل وموجّه الحدود قبل بدء الاتصال.
  • رفضت الوثيقة أن يعرف المستخدم الكلفة بعد وقوعها، وبيّنت أن التحذير عند الاتصال قد يفشل في التفاعلات الآلية أو عند تحويل Gopher صامت إلى عنوان مدفوع.
  • كان العنوان يستطيع اختيار سياسة، لكنه لا يثبت وحده هوية الشخص أو الشروط السارية أو الموافقة الواعية أو الخدمة المفيدة أو صحة القياس أو استحقاق الفاتورة أو دفعها.

قد يسبق التحويل لحظة الاختيار

تعرض فقرة قصيرة في RFC 1681 لبّ المشكلة. ماذا لو حوّل خادم Gopher المتصل إلى عنوان «pay-to-play» من دون إظهار التحذير المطلوب؟ ليست هذه رواية لحادثة احتيال موثقة على Gopher. إنها حالة اختبار تكشف أن البرنامج قد يعبر حداً تجارياً قبل أن يجد الإنسان موضعاً يقبل فيه الكلفة أو يرفضها.

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

كان الاقتراح أن تنتقل معلومة تجارية واحدة إلى مرحلة أبكر. تحدد بعض بتات عنوان الوجهة من يدفع. ويمكن لعدد أكبر من البتات أن يجعل العنوان مؤشراً إلى جدول لخوارزميات الاحتساب. عندئذ يستطيع موجّه على حدود مؤسسة أن يتعرف على فئة خدمة مدفوعة ويطبق قاعدة محلية قبل تمرير الحركة.

لم تكن الفاتورة ستوجد داخل العنوان. كان العنوان إشارة مبكرة قابلة للقراءة آلياً، في موضع يسمح بالمنع قبل الاتصال بدلاً من الاعتراض بعد ظهور التكلفة.

لم يعد عدّ الأجهزة كافياً لقياس الحاجة إلى العناوين

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

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

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

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

أربع علاقات للدفع لا تكفي لبناء فاتورة

عدّد RFC 1681 أربعة نماذج ممكنة للاحتساب بحسب الاستخدام. في النموذج التقليدي يدفع كل جهاز ثمن حزمه، فيتحمل طرفا المحادثة كلفة. وفي نموذج «caller pays» يدفع من بدأ الاتصال. أما المكالمة على حساب المتلقي فتنقل العبء إلى الطرف الآخر. وهناك خدمة ممتازة تشبه رقم «900» الأميركي، يدفع فيها المتصل زيادة إلى الخادم.

لهذا كان لا بد أن يعرف المتصل والمتلقي مسبقاً من سيدفع. معرفة ذلك بعد تكبد الكلفة أمر غير مقبول بحسب الوثيقة.

لكن هوية الدافع ليست إلا خانة واحدة. فقد فصل RFC 1125 بين وحدة المحاسبة، وأساس الاحتساب، والمبلغ الفعلي، ومن يُحاسب أو يُدفع له، وعدّاد الحزم المعتمد، وحدود الإنفاق. لا تخبر بتة صحيحة تقول «يدفع المتصل» إن الحساب بالبايت أو بالحزمة أو بالجلسة، ولا تحدد نسخة التعرفة أو العداد المرجعي أو السقف المأذون.

ويجعل اقتراح المؤشر في RFC 1681 هذا الاعتماد أوضح. فإذا أشار العنوان إلى صف، كانت القاعدة في الصف كما أداره طرف محدد خلال مدة محددة. من يحفظ العنوان ويفقد الجدول يحتفظ بالمفتاح ويضيّع المعنى.

يملك موجّه الحدود حق الرفض، لا حق الموافقة باسم المستخدم

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

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

اقترح RFC 1681 أيضاً تخصيص عنوان IP منفصل لكل مستخدم طوال جلسة الدخول. يواصل الموجّه جمع القياس بحسب العنوان؛ ويسجل الجهاز علاقة العنوان بالجلسة؛ ويجري إصدار الفواتير لاحقاً خارج الخط. ويمكن أن تحصل فئات المستخدمين على أشكال عناوين تسمح بالخدمات المكلفة أو تمنعها.

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

النشر في السجل التاريخي لم يكن اعتماداً تشغيلياً

تصنف صفحة RFC Editor الوثيقة على أنها Informational. جاءت استجابة لدعوة أوراق IPng في RFC 1550، ونص ملخصها على أن النشر لا يعني قبول منطقة IPng للأفكار. ووصف RFC 1550 تلك الأوراق بأنها مواد لعملية الاختيار وجزء من سجلها التاريخي.

توفر الوثائق اللاحقة مقارنة لا تصديقاً بأثر رجعي. يسمح RFC 4291 لواجهة IPv6 واحدة بأن تحمل عناوين متعددة من أنواع ونطاقات مختلفة. يثبت ذلك تعدد العناوين في معمارية IPv6، ولا يثبت اعتماد بتات للاحتساب أو علاقة سببية مع RFC 1681.

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

أما التوصية بترك مجال لـ 2^6 وربما 2^8 عناوين إضافية لكل جهاز، فكانت هامش تخطيط لاستهلاكات محتملة، ولا سيما النموذج المكلف لعنوان لكل مستخدم. لم تكن متوسطاً مقاساً أو حصة مضمونة.

من الإشارة إلى السداد سلسلة من إيصالات مستقلة

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

لا تثبت درجة ما يليها. التعرف على الفئة لا يثبت حداثة الجدول. مرور الحزمة لا يثبت الموافقة. نجاح الاتصال لا يثبت خدمة مفيدة. عدّ الحزم لا يثبت السعر. إصدار الفاتورة لا يثبت سدادها.

يمنع مبدأ Heng Lu المسمى Running-Code Primacy تحويل الاقتراح أو النشر أو الملصق إلى واقع معتمد ومرصود. ويفصل Minimum Initial Specification بين الحد المشترك اللازم للتشغيل البيني والترتيبات التجارية التي يمكن أن تبقى محلية. أما Reality, Not Advocacy فيضبط السرد: لا إحياء للآلية ولا سخرية منها، بل وصف ما تثبته المصادر وحده.

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

المصادر