摘要

  • RFC 1318 为 Centronics、Data Products 及相似的类并行打印机物理连接定义 MIB；它位于物理层，在 Character MIB 或 PPP MIB 等更高服务之下。
  • 输入和输出信号表包含 Power、Online、Busy、PaperOut、Fault；每个已表示信号的当前状态为 none、on 或 off，并可记录开与关之间的转换次数。
  • 这些对象证明的是一条可检测或可置位的硬件控制线。它们不证明文档、队列决定、已接受任务、渲染页面、纸张内容、收件人或人的结果。

一个提示灯并不等于一份回执

在设备旁边，PaperOut 的含义似乎不言自明。它提示缺纸，因此人们很容易接着说：打印在这里停下了。Busy 也似乎能说明工作正在发生，Online 似乎能说明设备随时可用，Fault 似乎已经给出原因。可是，RFC 1318 中的这些词首先是信号名称。它们识别的是接口线，而不是一份打印业务叙事中的阶段。

RFC 1318 没有规定如何提交文档、如何排队、如何选择纸张、如何合成页面、如何向用户交付副本。它规定的是“parallel-printer-like hardware devices”的管理对象，明确涵盖 Centronics、Data Products 和类似物理接口。RFC 将这个 MIB 放在物理层，放在 Character MIB 或 PPP MIB 这类可能使用该连接的更高层服务之下。这个位置不是背景说明，而是对象含义的一部分：它观察某些硬件线路，并不拥有线路之上每一件事的语义。

一项打印结果可能经过多个彼此独立的事实：应用生成文件，队列接受或搁置任务，驱动程序传递字节，设备机制形成标记，纸张离开设备，某个接收者看到或取得它。物理链路可以参与其中，却不因此成为所有阶段的记录者。把可见的信号当作整个结果，是把相邻关系误当作证据授权。

端口表给出的是坐标，不是用途

RFC 1318 的端口表为每个端口提供本地索引、硬件类型，以及输入和输出信号的表示数量。索引让管理器可以找到一行；硬件类型让管理器知道接口的大致类别；信号数让管理器知道还可向哪些表继续查询。这些字段都不表示建筑物中的某台打印机、某个用户、某个文件或某项任务。

更重要的是，输入表和输出表被刻意分开。输入表只为软件能够检测的信号建立行；输出表只为软件能够置位的信号建立行。因此，RFC 并不承诺每个端口都会显示同一组五个名称。某个条目不存在，可能是信号不适用于该硬件，也可能是代理不能在该 MIB 下检测或控制它。不存在的行不是已经观察到的 off。

这一点对监控界面尤其关键。若仪表盘把缺少的 PaperOut 行显示为“有纸”，它制造了代理没有给出的事实；若把没有 Fault 行显示为“无故障”，它又把可见性限制伪装成了健康结论。none、on、off 的三种表示，以及某些对象根本不出现的可能性，要求读者先问“此处究竟可观察什么”，再问设备发生了什么。

信号名称没有携带完整结论

对于已表示的信号，当前状态只能是 none、on 或 off。这个很小的枚举正好限制了可以说的话。Power 为 on，是名为 Power 的线处于该状态；它不是端到端打印路径可用的证明。Online 为 on，不是文档已提交、已接受或已解释的证明。Busy 为 on，没有说明哪项活动使设备忙碌，也没有说明该活动是否与某个指定任务有关。PaperOut 为 on，没有指认纸盒、页面、订单、用户或缺纸出现的时间。Fault 为 on，不是诊断，也不是根因或责任认定。

反向推论同样站不住。某条信号为 off，不能证明打印成功。none 更不能被读作“没有问题”；它保留了信号不适用或没有报告的可能性。三值表示阻止管理者把硬件接口的不完整可见性压扁为一个二值的业务结果。

如果问题是“代理在某时刻检测到这条线的什么状态”，RFC 1318 给出了合适的答案。如果问题是“队列是否接受了文件”“驱动是否完成传递”“页面是否形成”“副本是否到达某人”，答案必须来自拥有相应动作的队列、应用、设备或接收表面。对象的名称看起来接近打印，并不会为它取得那些其他层的发言权。

转换计数器没有计算任务数

paraInSigChanges 与 paraOutSigChanges 记录信号从 on 到 off、或从 off 到 on 的转换次数。这类计数器很适合发现不稳定的物理条件：一条看似正常的线可能频繁抖动，累计值可以让运维人员知道应当检查线缆、驱动、设备或时间段。它的价值来自准确记录“转换”，而不是宽泛地记录“发生了事情”。

十次 Busy 转换不是十个文档，也不是十页纸或十个完成任务。一次 PaperOut 转换没有说明此前正在使用什么纸、后来是否补充纸张、是否有任务恢复。一次 Fault 转换只是值得调查的观察边界，并不包括故障原因、维修责任或修复效果。计数还汇集两个方向的变化；仅凭一个累计数，人们无法还原每个状态持续多久、变化以何种次序发生、是谁或什么触发它们。

因此，任何要使用这个计数器的记录都应同时保存读取时刻、端口索引、硬件类型、输入或输出方向、信号名称和状态样本。需要顺序时，要保存独立的状态读数；需要打印结果时，要向能够产生该结果的层索取记录。相关性可以引导调查，不能让一个计数器跨层改名为结果。

检测与置位不是同一种权力

输入和输出表的分离还说明了控制权与观察权的分离。输入信号是软件能够从硬件连接检测到的东西；输出信号是软件能够在该连接上置位的东西。两个表都可能出现 Online 或 Busy，但相同的名称不会抹掉方向、来源和授权范围。

一个已置位的输出信号，是软件在定义的本地接口上采取行动的证据。它不能证明远端硬件理解了约定、接受了数据，或完成了操作者期待的动作。一个被检测到的输入信号，是本地观察；它不能说明设备为何产生该信号、设备怎样配置、或者打印队列作出了什么决定。若报告不保留方向，局部控制很容易被误写成远端确认，局部读数也容易被误写成原因。

这一区分让责任可以保留在正确位置。驱动维护者可以说明输出断言；设备操作者可以说明设备侧观察；队列拥有者可以说明接收或拒绝；文档分发者可以说明交付；接收者可以说明看到了副本。RFC 1318 并没有让这些各自的记录合并为一个信号故事。

已打印页面属于另一条证据链

“PaperOut 变了，但还不能证明打印出一页”并不是说该信号不重要。它承认信号作为物理线路观察可以非常可靠，同时拒绝把这种可靠性挪作文件回执。反过来，页面输出的可靠证据也可能存在于其他层，即使这个端口没有表示某条特定信号。

一个可复核的记录应保留端口与硬件类型、输入或输出表、信号名称、none/on/off 状态、计数值、代理与时间。若要声称文件被接受、页面被渲染、纸张被分发或读者已经看见，必须另附来自各自拥有者的独立记录。将它们相关联，可能形成严谨解释；用一个提示灯替代整条链，只会留下没有作者的结论。

来源与证据边界

本文依据 RFC 1318，《Definitions of Managed Objects for Parallel-printer-like Hardware Devices》（1992 年 4 月）。它支持物理层 MIB、端口表、输入与输出信号表、可检测与可置位的限制、Power/Online/Busy/PaperOut/Fault 名称、none/on/off 状态和转换计数器。它不支持某台打印机正在运行、某份文档、已传输字节、队列接受任务、页面已渲染或打印、纸张内容、接收者、维修或任何应用结果。