الخلاصة

  • تركت RFC 3196 في البداية لكل تنفيذ أن يقرر استلام المستند كاملاً قبل الرد النهائي على Print-Job. ألغى التصحيح التقني 2924 هذا الخيار، فألزم الطابعة باستلام كل البيانات أولاً.
  • ينطبق ذلك على رد IPP النهائي، سواء أكان نجاحاً أم خطأ. أما 100 Continue في HTTP، والخطأ المبكر في النقل، وإنشاء المهمة، وخروج الورقة فعلياً، فهي وقائع مختلفة.

ردّ يسبق المستند

صُمم بروتوكول الطباعة عبر الإنترنت (IPP) كي تصبح الطباعة خدمة شبكية. يرسل العميل عملية عبر HTTP، وتحمل رسالة Print-Job المستند في متن الطلب أيضاً. تعيد الطابعة حالة IPP، وقد تعيد مع النجاح معرّفات تتيح الاستعلام عن المهمة لاحقاً. لكن هذا التبادل المعتاد يطرح سؤالاً عملياً: متى يحق للخادم إعلان نتيجة طلب لا يزال متنه قيد الإرسال؟

كانت RFC 3196، المنشورة في نوفمبر 2001 بوصفها دليلاً لتنفيذ IPP/1.1، تترك في نصها الأصلي قرار استلام المستند كاملاً قبل الرد النهائي لكل تنفيذ على حدة. وفي 2011 غيّر Erratum 2924 العبارة: يجب على الطابعة استلام جميع بيانات المستند قبل إعادة رد النجاح أو الخطأ النهائي. لم يضف ذلك وظيفة طباعة جديدة؛ بل حدّد ما الذي يمكن أن يعنيه الرد النهائي حين يكون المستند نفسه ما زال في الطريق.

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

ثلاث إشارات لا تؤدي المعنى نفسه

لكن نطاق القاعدة محدد. 100 Continue رد HTTP مؤقت يسمح للعميل بمواصلة إرسال المتن؛ ولا يعني نجاح عملية IPP. كما قد يعيد HTTP خطأً نهائياً مبكراً في حالات لن تُنفذ فيها الطريقة؛ ويظل التعامل مع المتن والاتصال مسألة نقل منفصلة. لا يصنّف التصحيح كل إشارة مبكرة على أنها مخالفة.

كذلك لا يثبت نجاح Print-Job أن ورقة خرجت من الجهاز. قد يعيد الرد job-id وjob-uri كي يتابع العميل حالة المهمة لاحقاً. حدّثت RFC 8010 وRFC 8011 في 2017 الوثيقتين RFC 2910 وRFC 2911 واستبدلتهما، مع الإبقاء على الفصل بين نقل HTTP، وعملية IPP، ودورة حياة المهمة. استلام المستند، وقبول المهمة، ومعالجتها، والطباعة، وتسليم الناتج خطوات مستقلة.

السجل واضح بشأن القاعدة لكنه لا يثبت انتشارها. RFC 3196 وثيقة إرشادية من فئة Informational وليست مواصفة بروتوكول جديدة ضمن المسار المعياري. صنّف RFC Editor التصحيح 2924 على أنه Technical؛ أبلغ عنه Michael Sweet في أغسطس 2011 وتحقق منه Peter Saint-Andre في نوفمبر. لا تحدد المصادر المنتجات التي تبنته ولا تسجل عطلاً تسبب فيه النص القديم. لذلك لا يصح اختلاق قصة حادثة صناعية.

الدرس هو أن نسأل: أي طبقة أكدت ماذا تحديداً؟ بدء النقل لا يثبت استلام المستند كله، ومعرّف المهمة لا يثبت خروج الورق. أغلق التصحيح غموضاً واحداً محدداً، لا جميع الأسئلة التي تأتي بعده.

المصادر

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