الخلاصة

  • أعطى RFC 3510 خدمات IPP ومهامها عنواناً مطلقاً من نوع ipp:، لكنه قال صراحة إن التحويل العكسي من عنوان المهمة إلى عنوان Printer الذي أنشأها لم يكن محدداً.
  • كانت إضافة مكوّن واحد إلى المسار توصية لتحسين التشغيل البيني، لا إثباتاً لهوية الخدمة أو دوام العنوان أو قبول المهمة أو خروج الورق أو وصوله.

يوحي العنوان ipp://example.com/printer/123 بحكاية جاهزة. الرقم هو المهمة، وما قبله هو الطابعة الأم. ويبدو أن حذف الجزء الأخير يكشف المنشئ. أهمية RFC 3510 أنه رفض تحويل هذا الانطباع البصري إلى قاعدة لا يستند إليها البروتوكول.

نُشر المستند في أبريل 2003 ضمن Standards Track لتوسيع وتوضيح قسم عناوين IPP في RFC 2910. حدّد مجال استخدام ipp:، والمنفذ الافتراضي 631، ونوع الوسائط application/ipp، والترميز، والبنية، وقواعد المقارنة. ولم يضف معلمات جديدة إلى العنوان.

يشير عنوان ipp: إلى خدمة طباعة تدعم IPP أو إلى مورد شبكي تديره الخدمة، مثل Job. ولا يقبل إلا الصيغة المطلقة. فهو يربط النموذج المجرد في RFC 2911 بنقل HTTP في RFC 2910؛ أما أي وسيلة نقل أخرى فتحتاج مخطط عنوان مختلفاً. لذلك لا تعني البادئة «طباعة عبر الشبكة» بإطلاق، بل ارتباطاً محدداً بين نموذج ونقل.

إذا غاب المنفذ يُستخدم 631. وعند المقارنة، يكون غياب المنفذ مكافئاً لكتابة :631. وإذا غاب المسار تصبح Request-URI هي /. وتتبادل الأطراف الرسائل بصيغة application/ipp. أزالت هذه القواعد خلافات كان يمكن أن تنشأ من طريقتين لكتابة المدخل نفسه.

لكن المسار لا يرسم الأجهزة. يمكن لمضيف واحد أن يعرض عدة كائنات Printer مستقلة منطقياً. قد يمثل أحدها جهازاً مادياً، والثاني spooler يوزع الحمل، والثالث مجموعة أجهزة. وقد تظهر طوابير لمستلمين مختلفين كأنها Printers مستقلة فوق الجهاز نفسه.

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

تظهر المشكلة بوضوح في Job URL. كان RFC 2911 قد جعل الصيغة الدقيقة لـ Job URI معتمدة على التنفيذ. وبذلك أصبحت العلاقة بين printer-uri في طلب Print-Job وjob-uri في الرد معتمدة على التنفيذ أيضاً. ووصف RFC 3510 قولاً سابقاً بأنه خاطئ: لا يستطيع العميل تحديد Printer المنشئ من URI المهمة وحده، لأن التحويل العكسي لم يُحدّد قط.

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

حتى عند اتباع العرف، يبقى سجل التبادل أقوى من قصّ النص لاحقاً. ينبغي حفظ printer-uri المُرسل، وjob-uri المُعاد، وهوية الخادم الموثقة، والرد، والوقت. يمكن للوكيل أن يعيد كتابة المسار، ويمكن للخدمة أن تعيد استخدام الاسم. أما التبادل فيربط الاسم بالجهة التي أصدرته في لحظة محددة.

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

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

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

كما لا يحمل العنوان معلمات تحدد وسيلة توثيق العميل أو الأمن المطلوب. يمكن لبروتوكولات الاكتشاف أو الدليل أن توفر هذه المعلومات. ناقشت مجموعة العمل إضافة معلمات، لكنها أبقت البنية الأصلية من أجل التوافق مع تنفيذات IPP/1.1 الكثيرة التي كانت قد شُحنت.

تبدأ سلسلة الدليل بعنوان صحيح، ثم حل المضيف والمنفذ والمسار، ثم endpoint يتحدث IPP عبر HTTP، وهوية خادم موثقة، وعميل مأذون، وقبول العملية، وإنشاء Job، وحفظ عنوانها مع الجهة المصدرة والعمر. وبعد ذلك تأتي الحالة النهائية، والخروج المادي، والتسليم. لا تثبت درجةٌ الدرجةَ التي تليها.

قد ترفض خدمة حقيقية المهمة. وقد تُلغى مهمة مقبولة. وقد يعلن البرنامج الاكتمال قبل خروج الورق. وقد يصل الناتج إلى درج أو شخص غير مقصود. نظّم RFC 3510 العنوان ولم يختصر هذه الوقائع في إشارة نجاح واحدة.

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

كانت قيمة RFC 3510 في هذا الانضباط. قلل الغموض في تحديد الموقع، وسجل في الوقت نفسه ما لا يثبته المحدد. كان عنوان المهمة يستطيع تسمية Job. ومن دون سياق التبادل والتنفيذ، لم يكن يستطيع إخبارك أي Printer أنشأها.

المصادر