Resumen

  • RFC 1318 describe objetos administrados para enlaces físicos de tipo impresora paralela, incluidos Centronics, Data Products e interfaces semejantes, por debajo de MIBs de servicios como Character MIB o PPP MIB.
  • Las tablas de señales de entrada y salida emplean Power, Online, Busy, PaperOut y Fault; cada estado actual puede ser none, on u off, y los contadores registran cambios entre encendido y apagado.
  • El MIB prueba un estado o una transición de una línea de control que el software puede detectar o afirmar. No prueba un archivo, una orden de impresión, la aceptación de una cola, una página, su contenido o que alguien recibió un ejemplar.

El panel de señales no era un recibo

Pocas palabras invitan más al salto de inferencia que PaperOut. Parece hablar de papel y, por tanto, de impresión. Busy parece hablar de trabajo. Online parece hablar de disponibilidad. Fault parece ofrecer una causa. Pero estos nombres pertenecen a señales de una interfaz. Su familiaridad no les añade la semántica de una aplicación.

RFC 1318 se ocupaba de hardware que se parecía a una impresora paralela. No definía un protocolo de documentos, ni una cola de spool, ni el formato de una página, ni un comprobante para el usuario. Situaba su MIB en la capa física y lo colocaba bajo otros MIBs capaces de dar servicio de caracteres o PPP. La decisión de ubicación es una parte central de su significado: el modelo sabe de determinadas líneas en una conexión, no de todas las cosas que podrían producirse sobre o alrededor de esa conexión.

Una ruta técnica puede tener muchas estaciones sin que una sola estación posea todas sus conclusiones. Un programa puede crear un archivo; una cola puede decidir que lo retiene o lo entrega; un controlador puede emitir datos; un mecanismo puede marcar una hoja; una persona puede encontrar esa hoja. La señal del cable no decide ni observa automáticamente cada transición. Tomarla como relato completo equivale a pedir a un termómetro que certifique una receta.

El puerto ordenaba observaciones, no documentos

La tabla de puertos de RFC 1318 da a cada entrada un índice local, un tipo de hardware y los recuentos de señales de entrada y de salida que representa. Centronics y Data Products orientan al lector sobre la forma de la interfaz. El índice permite navegar por las tablas. Ninguna de las dos cosas identifica una instalación universal, un trabajo de impresión, un archivo o una cuenta.

El RFC separa además las señales que el software puede detectar de las que el software puede afirmar. Una fila de entrada existe sólo para una señal detectable; una de salida, sólo para una señal que el software puede establecer. No todos los tipos de hardware tienen por qué exhibir el mismo conjunto. Por eso una fila que no aparece no es automáticamente una señal que vale off. Puede ser una señal no aplicable o una capacidad que el agente no expone.

Esta diferencia protege al operador contra dos tranquilidades falsas. Si no existe la fila PaperOut, no se deduce que haya papel. Si no existe Fault, no se deduce que no haya problema. Una ausencia en el modelo es información sobre el alcance del modelo. Reemplazarla por una respuesta binaria crea un dato que la máquina nunca emitió.

none, on y off no eran una historia de progreso

Para las señales representadas, el estado actual puede ser none, on u off. Son tres valores pequeños con un límite claro. on de Power dice algo sobre la línea llamada Power, no sobre el funcionamiento de todo el camino. on de Online no prueba que se ofreció o aceptó un documento. on de Busy no revela qué actividad ocupa al dispositivo, si está relacionada con un trabajo concreto o si progresa. on de PaperOut no identifica una bandeja, una página o el momento en que se suspendió una salida. on de Fault no diagnostica ni asigna la causa.

El razonamiento inverso falla de la misma manera. Una señal en off no certifica una copia satisfactoria. Y none no es el valor inocente de «todo está bien»: conserva la posibilidad de que la señal no sea aplicable o no esté informada. Este tercer valor impide que el lector cambie una frontera de visibilidad en una conclusión sobre la realidad física.

La frase correcta depende de la pregunta. Para saber cómo estaba una línea de control observada por un agente, el objeto es pertinente. Para saber si una cola admitió un trabajo, se requiere el registro de la cola. Para saber si una página se compuso o quedó disponible, se requieren señales del renderizador, del dispositivo o de la distribución. Para saber si alguien la vio, hace falta evidencia de ese receptor. El objeto de capa física no puede heredar esas respuestas solo porque se llame «impresora».

Un contador de cambios no contaba páginas

paraInSigChanges y paraOutSigChanges miden cuántas veces una señal pasa de on a off o de off a on. Un contador así sirve para descubrir una condición intermitente. Puede mostrar que una línea aparentemente estable ha oscilado repetidamente y puede orientar una inspección de cableado, controlador o periférico. Su valor está en preservar ese hecho estrecho.

No mide trabajos, páginas, copias ni lectores. Diez cambios de Busy no equivalen a diez documentos. Un cambio de PaperOut no indica cuál fue el papel previo, si hubo reabastecimiento ni si después se retomó una tarea. Un cambio de Fault es un borde observado, no un informe de causa raíz. Además, el total acumula ambos sentidos de transición: por sí solo no contiene la duración de cada estado, el orden detallado, la fuente de las transiciones ni su relación con una aplicación.

Una lectura responsable conserva el valor con un instante, el puerto y su tipo, la dirección de la señal y el estado muestreado. Cuando se necesita un orden, se guardan muestras adicionales; cuando se necesita un resultado de impresión, se buscan los registros de la capa que puede producir ese resultado. Correlacionar no es sumar indicios hasta que uno cambie de naturaleza.

Detectar y afirmar eran operaciones diferentes

La arquitectura de dos tablas expresa también dos direcciones de autoridad. Una entrada describe una línea que el software puede detectar. Una salida describe una línea que el software puede afirmar. Ambas pueden llamarse Online o Busy, pero el nombre igual no convierte una observación local en una acción local ni hace que cualquiera de ellas sea una respuesta del dispositivo remoto.

Una salida afirmada prueba como mucho que el software actuó sobre la interfaz definida por el MIB. No garantiza que el otro equipo cumpliera la convención, aceptara los datos o completara una operación. Una entrada detectada es igualmente local: no muestra por qué el equipo generó la señal, qué configuración tenía ni qué regla usó la cola. La dirección debe viajar con todo informe; sin ella, una afirmación de control puede disfrazarse de confirmación y una lectura puede disfrazarse de causa.

Ese cuidado reparte bien las responsabilidades. Quien opera el controlador puede responder por su aserción. Quien opera el dispositivo puede responder por su observación física. Quien posee una cola puede responder por la admisión o el rechazo. Quien distribuye un documento puede responder por su entrega. RFC 1318 no borra estas fronteras para dar una frase más cómoda.

La hoja terminada pertenecía a otra cadena de evidencia

El título no afirma que un PaperOut sea irrelevante. Afirma algo más disciplinado: un cambio de esa señal no había demostrado aún que se imprimiera una página. La señal puede ser excelente evidencia de una línea física en un momento determinado. Su uso se vuelve frágil cuando se la transforma en el sustituto de un resultado que otro sistema debe registrar.

Un registro útil conserva el índice del puerto, el tipo de hardware, la tabla de entrada o salida, el nombre de señal, none/on/off, el contador, el agente y la hora. Si el informe dice que se aceptó un archivo, se completó una página, se entregó una copia o la leyó un destinatario, añade registros independientes con dueño y tiempo propios. Esa cadena puede explicar una operación. Un único indicador no puede apropiarse de toda la cadena sin perder lo que lo hacía confiable.

Fuentes y límites de la evidencia

Este artículo se basa en RFC 1318, Definitions of Managed Objects for Parallel-printer-like Hardware Devices (abril de 1992). El RFC respalda el MIB de capa física, la tabla de puertos, las tablas de señales de entrada y salida, los límites de detección y aserción, los nombres Power/Online/Busy/PaperOut/Fault, los estados none/on/off y los contadores de transición. No respalda una impresora activa, un documento, bytes transferidos, una cola que acepta un trabajo, una página renderizada o impresa, contenido en papel, un destinatario, una reparación o un resultado de aplicación.