Resumen

  • RFC 1179 describía LPD como práctica existente de Internet: un daemon TCP en el puerto 515 recibía órdenes sobre una cola con nombre, incluida la orden de iniciar los trabajos en espera.
  • En Receive job, el daemon acusaba primero el subcomando de archivo; el cliente anunciaba con un octeto cero que terminaba la secuencia de bytes declarada, y el daemon debía emitir un segundo acuse. Ninguno de esos hechos probaba una página impresa.

Un trabajo cambiaba de dueño varias veces

Una orden de impresión no viaja de una aplicación a una hoja en un solo acto. La aplicación presenta una solicitud. El daemon admite o rechaza un paso. La cola conserva trabajo pendiente. Un proceso recibe la orden de comenzar. Un archivo de control determina cómo interpretar un archivo de datos. Un dispositivo puede, después, producir una salida. Cada transición tiene su propio actor y su propio tipo de evidencia.

RFC 1179, publicada en agosto de 1990, documentó un protocolo de servidores de impresión que ya se utilizaba ampliamente en Internet. Era un texto informativo, no una norma de Internet. Su alcance es práctico: define comandos, formatos y respuestas de un line printer daemon. No promete que una respuesta de red contenga el veredicto de los procesos físicos que siguen.

LPD utilizaba TCP y el daemon escuchaba en el puerto 515. Para cada comando se abría una conexión nueva. Un código binario iba seguido por el nombre ASCII de una cola y, si hacían falta, más operandos. Es una petición dirigida al daemon. La propia RFC pide leer los verbos de comando como imperativos. Que un daemon reciba un imperativo no significa que el mundo que el imperativo nombra ya haya cambiado.

La orden Print any waiting jobs revela la diferencia. Inicia el proceso de impresión si todavía no se está ejecutando. No informa que un trabajo concreto fue elegido, que el formato era válido, que había papel o que una persona tiene una página. Iniciar el proceso está después de recibir ficheros y antes de poder observar un resultado.

La recepción de archivo no tenía un solo sí

Una vez emitida la orden de recibir un trabajo, el cliente podía mandar subcomandos para el archivo de control y para el archivo de datos. Después de un subcomando tenía que esperar una confirmación del daemon. Un octeto de valor cero era positivo; otro patrón era negativo. Esa primera respuesta se refería al siguiente paso del protocolo.

Luego aparecía el límite de archivo. El subcomando incluía un conteo de bytes y un nombre. El cliente enviaba esa cantidad por la misma conexión y, al terminar, enviaba un octeto cero para indicar que consideraba completo el archivo transmitido. Tras ello debía existir un segundo nivel de confirmación. Para un archivo de datos con longitud especificada se aplicaba el mismo esquema.

La secuencia evita atribuir a un solo recibo más de lo que contiene. El primer acuse afirma algo sobre el subcomando. El cero del cliente afirma que su transmisión alcanzó el límite declarado. El segundo acuse es la reacción del daemon después de ese límite. Es una cadena de progreso de la transferencia, no una observación del trabajo de impresión.

El conteo tampoco interpreta el documento. RFC 1179 permite valores de ocho bits en el archivo de datos y deja su interpretación al archivo de control correspondiente. Por tanto, el número de octetos no demuestra que el contenido fuera un documento válido, que el formateador lo entendiera ni que el dispositivo lo hubiese convertido en páginas.

La cola guardaba instrucciones, no una sentencia de entrega

El archivo de control podía proporcionar nombre de host, identificación de usuario, nombre del archivo fuente, formato y una petición de correo cuando se imprimiera. Son instrucciones para el daemon. No son prueba independiente de la identidad de una persona, de la titularidad del documento o del correo efectivamente enviado. Un número de trabajo distingue dentro del modelo limitado de la cola; no crea una identidad global.

Las operaciones administrativas conservan ese límite. LPD podía devolver el estado de cola y aceptar una solicitud para borrar trabajos. La RFC impone condiciones a la eliminación de trabajos ajenos por un agente que no sea root. Esa es una regla para un comando local. No es una teoría general de autorización, ni una prueba de quién leyó, liberó o recibió un documento.

La contribución histórica de LPD es hacer rastreable la parte que realmente controlaba. Se puede afirmar que un daemon recibió un subcomando, que el cliente declaró completos ciertos bytes, que el daemon respondió después y que recibió una orden de iniciar la cola. Para afirmar una impresión física, una entrega o un efecto ulterior hacen falta testigos de otro tramo.

Fuentes