Resumen

  • RFC 3381 añadió cuatro atributos opcionales para observar el avance de un trabajo IPP y un atributo para controlar la intercalación de hojas; ninguno era un porcentaje universal de finalización.
  • La secuencia de los contadores cambiaba con el orden de hojas, copias y documentos. Si el equipo no podía detectar el apilado, «completado» podía ser una aproximación tomada al terminar el procesamiento.

Un contador total sube mientras otro vuelve a uno. Visto desde un tablero pobre, el trabajo parece haber perdido avance. Visto desde la impresora, puede haber terminado una copia y empezado la siguiente. La diferencia no está en la aritmética, sino en la frontera que el número representa.

RFC 3381 se publicó en septiembre de 2002 como documento de la vía de estándares. Definió job-collation-type, sheet-completed-copy-number, sheet-completed-document-number e impressions-completed-current-copy. También añadió sheet-collate, con el que un cliente podía pedir hojas intercaladas o sin intercalar.

El diseño no redujo un trabajo a una barra de progreso. Expuso varias coordenadas. El total job-impressions-completed describía el trabajo entero. El contador de impresiones de la copia actual describía solo una copia de un documento y debía reiniciarse en la siguiente. Los ordinales de copia y documento indicaban en qué ámbito debía leerse ese valor.

Los atributos procedían del MIB de supervisión de trabajos del PWG, documentado en RFC 2707. También podían viajar en contenido de notificación, desarrollado más tarde por RFC 3995 y RFC 3996. El transporte de una medición no ampliaba su evidencia: una notificación inmediata seguía necesitando el tipo de intercalación y el límite de reinicio.

Para demostrarlo, RFC 3381 usó el mismo encargo bajo tres órdenes. Había tres copias de dos documentos, con tres impresiones por documento. Con hojas sin intercalar, cada hoja se repetía para las tres copias antes de pasar a la siguiente. Con documentos intercalados, la primera copia de cada documento precedía a la segunda. Con documentos sin intercalar, se agotaban todas las copias del primer documento antes de comenzar el segundo.

El total acababa siempre en dieciocho. Sin embargo, tras la cuarta impresión, la posición podía ser la segunda impresión de la primera copia del primer documento, la primera impresión del segundo documento o la primera impresión de la segunda copia del primero. Cuatro era verdadero, pero no localizaba el trabajo.

sheet-collate gobernaba el orden de las hojas dentro de una copia. multiple-document-handling gobernaba la relación entre documentos y copias. Juntos definían conjuntos lógicos de salida. Algunas combinaciones carecían de una semántica coherente y la impresora debía rechazarlas como atributos en conflicto.

La máquina física podía añadir otra capa. Un clasificador de bandejas podía entregar al usuario hojas ordenadas aunque el dispositivo declarase uncollated-sheets. Según el RFC, la aplicación de supervisión no podía distinguir ese equipo de otro sin clasificador. La salida visible podía ser mejor que lo que el contador era capaz de explicar.

La palabra «completado» también admitía dos puntos de observación. Por regla general, una impresión o una hoja estaba completada al quedar apilada. Pero, si el dispositivo no detectaba ese momento, podía aproximarlo con el final del procesamiento de la hoja. El entero seguía siendo válido; la afirmación física era más limitada.

Entre procesar y apilar podía haber transporte, acabado o un atasco. RFC 3381 no borró esa distancia. La hizo auditable al reconocer la aproximación. Un operador que tratase ambas fuentes como equivalentes convertiría una concesión de observabilidad en una promesa de entrega que el protocolo no formulaba.

Los reinicios daban sentido a los contadores locales. impressions-completed-current-copy debía regresar a cero en cada documento y en cada copia. Para no leer ese reinicio como retroceso, la supervisión necesitaba conservar la identidad del trabajo, el ordinal del documento, el ordinal de la copia, el modo de intercalación y la transición de estado.

El protocolo también distinguía cero de desconocido. Si el número de copia o documento no estaba disponible, la impresora devolvía el valor fuera de banda unknown, no el menos dos usado por algunos MIB. Cero pertenecía al estado inicial; desconocido decía que faltaba la observación. Sustituir uno por otro inventaba una muestra.

Todos los atributos eran opcionales y podían aparecer en combinaciones parciales. Una impresora podía ofrecer el total sin el documento actual, o declarar el tipo de intercalación sin cada contador de copia. La ausencia no demostraba inmovilidad. Solo estrechaba lo que el cliente podía afirmar con respaldo.

RFC 3381 actualizó RFC 2910 y utilizó el modelo de RFC 2911, con RFC 3196 como guía de implementación. RFC 3380 resolvía una cuestión vecina pero diferente: la aceptación atómica de cambios en los atributos de un trabajo. Que un cambio se aceptara no decía cuánto se había producido ni dónde estaba el papel.

RFC 8010 y RFC 8011 consolidaron después el transporte y el modelo IPP/1.1, y RFC 3381 quedó obsoleto. Esa sustitución registra la evolución del estándar; no prueba adopción, comportamiento de un producto concreto ni resultado físico. RFC 2567 y RFC 2568 ayudan a entender por qué IPP organizó estas afirmaciones alrededor de objetos y atributos.

La idea de especificación inicial mínima de Lu Heng ilumina el carácter opcional y componible de la extensión. Su análisis de capas de realidad marca el límite: petición de intercalación, ejecución interna, incremento, movimiento de la hoja, apilado y posesión por el usuario son hechos enlazados, no sinónimos.

RFC 3381 convirtió un número en evidencia condicionada. Para saber qué significaba tres había que conservar qué se contaba, dónde se reiniciaba, en qué orden se producía y qué frontera podía ver realmente el dispositivo.

Fuentes