Resumen

  • RFC 3196 dejaba inicialmente a cada implementación decidir si aceptaba todo el documento antes de dar la respuesta final de Print-Job. El Erratum técnico 2924 eliminó esa opción: primero deben aceptarse todos los datos.
  • La regla trata de la respuesta IPP final, tanto de éxito como de error. 100 Continue, un error de transporte anticipado, la creación del trabajo y la impresión física son hechos distintos.

La respuesta llegó antes que el documento

El Protocolo de Impresión de Internet, IPP, pretendía que imprimir funcionara como un servicio de red. El cliente enviaba una operación por HTTP y, en Print-Job, el documento viajaba también en el cuerpo de la petición. La respuesta devolvía un estado IPP y, si se creaba un trabajo, identificadores para consultarlo después. El intercambio dejaba una pregunta práctica: ¿cuándo puede el servidor afirmar el resultado de una solicitud cuyo cuerpo todavía está en tránsito?

La RFC 3196, guía de implementación de IPP/1.1 publicada en noviembre de 2001, dejaba inicialmente esa decisión a la implementación. Una década después, el Erratum 2924 sustituyó la frase: la impresora DEBE aceptar todos los datos del documento antes de devolver la respuesta final de éxito o error. No añadió una modalidad nueva de impresión. Delimitó mejor qué puede significar esa respuesta cuando la solicitud incluye un objeto grande que aún se está transmitiendo.

La precisión importa sobre todo en envíos en flujo. Si la aplicación anuncia un resultado mientras aún quedan datos por enviar, el cliente no sabe con claridad si el documento completo fue consumido, si existe un trabajo o si debe volver a intentarlo. La corrección asigna a la impresora una obligación concreta: no adelantar la respuesta IPP final a la recepción completa del cuerpo.

Tres señales que no son intercambiables

La regla tiene límites. 100 Continue es una respuesta HTTP provisional que permite al cliente seguir enviando el cuerpo. No declara que IPP haya tenido éxito. HTTP también admite respuestas finales tempranas de error cuando la operación no se va a ejecutar; la gestión del cuerpo y de la conexión es una cuestión de transporte. El erratum no convierte cualquier señal temprana en incumplimiento.

Tampoco significa que una respuesta satisfactoria de Print-Job garantice que haya salido una hoja. Puede incluir job-id y job-uri, que permiten consultar después el estado del trabajo. Las RFC 8010 y 8011, de 2017, sustituyeron las RFC 2910 y 2911 y conservan la separación entre transporte HTTP, operación IPP y ciclo de vida del trabajo. Recibir el documento, aceptar el trabajo, procesarlo, marcar el papel y entregarlo son etapas distintas.

El registro es más preciso sobre la regla que sobre su adopción. RFC 3196 era una guía informativa, no una nueva norma de protocolo. El editor de RFC clasifica el Erratum 2924 como técnico; Michael Sweet lo notificó en agosto de 2011 y Peter Saint-Andre lo verificó en noviembre. Esos documentos no demuestran qué productos lo aplicaron, con qué frecuencia ni si un fallo concreto se debió a la redacción anterior. Presentarlo como relato de un incidente sería inventar evidencia.

La enseñanza se resume en una pregunta: ¿qué capa confirmó exactamente qué? El comienzo de una transferencia no demuestra que el documento se recibiera completo. Un identificador de trabajo no demuestra que el papel saliera. La corrección cierra una ambigüedad específica; no promete resolver las demás.

Fuentes

Las fuentes documentan la regla y su historia editorial. No prueban adopción, rendimiento medido, comportamiento de un producto, un fallo específico ni que el éxito de la operación equivalga a impresión física o almacenamiento duradero.