الخلاصة

  • كان RFC 3380 يقيّم طلب Set-Job-Attributes المتوافق بوصفه حالة كاملة مقترحة، لا مجموعة حقول يمكن تطبيق بعضها فقط.
  • كان وجود صفة أو قيمة غير متوافقة يوجب رفض الطلب كله والإبقاء على المهمة دون تغيير؛ ولم يكن ذلك إلغاءً للمهمة أو دليلًا على خروج نسخة مطبوعة.

في سبتمبر 2002، وضع بروتوكول الطباعة عبر الإنترنت IPP حدًا إداريًا أوضح. فقد يكتشف المستخدم أو المشغّل بعد الإرسال غياب تعليمات للتشطيب. وأتاح RFC 3380 خيارًا اختياريًا بدل الإلغاء وإعادة الإرسال: تعديل صفات كائن المهمة الموجود.

كان على الطابعة تقييم القيم المقترحة إلى جانب الصفات التي أبقاها العميل كما هي. والسؤال افتراضي: هل كان سيُقبل عمل جديد بهذه المجموعة النهائية عند ضبط ipp-attribute-fidelity=true؟ إن كان الجواب نعم، يُقبل التعديل؛ وإلا يُرفض وتبقى المهمة الموجودة بلا تغيير. لم يكن مسموحًا إسقاط صفة غير مدعومة أو غير قابلة للضبط أو متعارضة، ثم تطبيق البقية. فالطلب إما كله أو لا شيء.

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

حدّد RFC أيضًا تحديثًا ذريًا لصفات الطابعة، وأضاف Get-Printer-Supported-Values لاكتشاف القيم المقبولة لبعض الصفات القابلة للضبط. وأتاح printer-xri-supported تحديث أوصاف URI والمصادقة والأمان المرتبطة معًا. لكن عمليات Set كانت اختيارية. تحدد المواصفة العقد، ولا تثبت أن طابعة بعينها نفذته أو أن عميلًا استخدمه أو أن صفحة طُبعت.

يتناول RFC 3196 لحظة مختلفة: متى يمكن للطابعة أن ترسل ردًا نهائيًا بعد استلام بيانات المستند. أما RFC 3380 فيتناول تعديل صفات المهمة. ولا يثبت قبول التعديل أو رفضه اكتمال الاستلام أو المعالجة أو الطباعة. يسجل حدث البروتوكول تغيرًا في الحالة، لا نتيجة مادية. المصادر الأولية: RFC 3380، وRFC 2911، وRFC 3196. كان الامتداد اختياريًا؛ ولا تثبت النصوص اعتماده أو قابلية التشغيل البيني.

المصادر