الخلاصة

  • في RFC 3402 تصبح نتيجة القاعدة غير النهائية مفتاحاً لجلب مجموعة القواعد التالية، لكن كل قاعدة لاحقة تظل مطبقة على Application Unique String الأصلية التي بدأت بها العملية.
  • فصل المعيار بين مسار التفويض وهوية الموضوع: تستطيع كل جهة أن تحدد أين يستمر البحث، ولا تستطيع أن تحول ناتجاً وسيطاً إلى موضوع جديد من دون إعلان.

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

اختار RFC 3402 نموذجاً مختلفاً. صدرت الوثيقة في أكتوبر 2002 على مسار المعايير بوصفها الجزء الثاني من Dynamic Delegation Discovery System. شرحت خوارزمية للربط المتأخر؛ يقدم التطبيق Application Unique String، أو AUS، ثم يجلب العميل القواعد عند الحاجة ويتنقل بين قواعد البيانات المعلنة حتى تنتج قاعدة نهائية نوع النتيجة الذي حدده التطبيق.

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

أما البداية فكانت لها آلية خاصة. يعرّف التطبيق First Well Known Rule، ولا تُجلب هذه القاعدة من قاعدة البيانات. وهي تحول AUS إلى أول مفتاح صالح. بذلك يرتبط موضع البداية بعقد معروف، ولا يستطيع العميل أن يختار قاعدة بيانات لمجرد أنها تقبل شكلاً لغوياً مناسباً ثم يقدم ذلك التوافق بوصفه تفويضاً.

يعيد البحث مجموعة مرتبة من القواعد. يجرب العميل عبارات الاستبدال بالترتيب على AUS حتى يجد نتيجة غير فارغة، ثم يفحص Services وFlags وPriority. التطابق النصي، وقبول الخدمة، والحالة النهائية، والأفضلية قرارات مختلفة؛ لا يمنح أحدها بقية القرارات تلقائياً.

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

وعندما تُقبل قاعدة غير نهائية، يجب التحقق من أن ناتجها يطابق صيغة مفاتيح قاعدة البيانات التالية. قد تولد عبارة نمطية خاطئة مفتاحاً غير قانوني رغم مظهره المعقول. يمنع التحقق استعلاماً غير صحيح، ولا يعطي المفتاح منزلة الموضوع الأصلي.

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

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

تنهي القاعدة النهائية دورة الخوارزمية، وتعيد ناتجاً يوافق عقد التطبيق مع Flags وServices. لا تعني كلمة «نهائية» أن الخدمة اللاحقة متاحة، أو أن ناشر القاعدة صاحب سلطة مشروعة، أو أن المستهلك قبل النتيجة. انتهاء الخوارزمية ونجاح العمل في العالم الخارجي واقعتان منفصلتان.

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

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

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

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

شرح RFC 3403 قاعدة DNS وسجلات NAPTR، وشرح RFC 3404 تطبيق URI Resolution، وقدم RFC 2916 سلفاً مبكراً لـ ENUM. هذه أمثلة على استخدام الخوارزمية، وليست دليلاً على أن كل عميل DDDS يفهم كل تطبيق أو يثق بكل قاعدة.

يبين سجل IANA لخدمات ENUM كيف تُنسق معرفات الخدمات في تطبيق لاحق. التسجيل دليل تنسيق، لا دليل تنفيذ أو حداثة أو سلطة أو انتهاء صحيح أو نجاح للخدمة. ويسجل RFC Editor حالياً تصويباً تحريرياً واحداً متحققاً منه للوثيقة، هو Errata 7049؛ يصحح رقم قسم مناقشة علم p في RFC 3404 من 4.4 إلى 4.3، ولا يغير المبدأ الخوارزمي.

لذلك يحتاج إيصال التشغيل إلى AUS الأصلية، وإصدار التطبيق، وFirst Well Known Rule، ونوع قاعدة البيانات، وكل مفتاح، وكل مجموعة مرتبة، وهوية القاعدة وصلاحيتها، والتطابق والناتج، ورفض الخدمة وموضع الاستئناف، وقرار Priority، والعلم النهائي، والتحقق من صيغة الناتج، وفعل المستهلك بعد ذلك.

يفسر مبدأ Lu Heng بشأن الحد الأدنى للمواصفة الأولية هذا الاقتصاد: توحيد الحد المشترك الذي تحتاجه التطبيقات المستقلة، وترك دلالة التطبيق وآلية قاعدة البيانات لعقودهما. أما أولوية الشيفرة العاملة فتطلب البرهان: إعادة تشغيل AUS على القواعد المرصودة وإثبات أن أي مفتاح وسيط لم يحتل مكان الموضوع.

حافظ RFC 3402 في النهاية على الهوية داخل التفويض. كان للمسار أن ينتقل، وللمفاتيح أن تتغير، وللسلطات أن تتعاقب. لكن كل سلطة كانت ملزمة بالإجابة عن الموضوع الأصلي نفسه.

المصادر