Appendix A. Implementer Guidelines (实施者指南)
本节中的信息作为对实施者的帮助提供。虽然此信息被认为是有帮助的，但它不是规范性的 (Not Normative)。因此，实现无需 (NOT REQUIRED) 遵循它即可声称符合本规范。
A.1. Relationship with BSD Syslog (与 BSD Syslog 的关系)
虽然 BSD Syslog 被广泛使用，但其格式从未正式标准化。[RFC3164] 描述了观察到的格式。它是一个信息性 RFC，实践表明存在许多不同的实现。本文档创建期间的研究表明，不同平台上的不同 Syslog 实现之间几乎没有共同点。它们唯一一致的是消息以 "<" PRIVAL ">" 开头。除此之外，传统的 Syslog 消息没有以一致的方式格式化。因此，RFC 3164 没有描述 Syslog 消息内部的任何特定元素。它指出，任何发送到 Syslog UDP 端口的消息都必须被视为 Syslog 消息，无论其格式或内容如何。
本文档保留了 PRI 值的语法和语义。这将允许传统的 Syslog 实现将符合本规范的 Syslog 应用程序生成的消息放入正确的存储桶 (Bins)。
大多数现有实现支持 UDP 作为 Syslog 的传输协议。本规范支持 UDP 传输，但不推荐它。推荐部署所需的 TLS 支持。可以使用其他传输协议。
RFC 3164 描述了中继行为。本文档不指定中继行为。这可能会在单独的文档中完成。
RFC 3164 中描述的 TIMESTAMP 提供的精度低于本文档中指定的时间戳。它还缺少年份和时区信息。如果需要将根据本文档格式化的消息重新格式化为 RFC 3164 格式，建议使用发起者的本地时区，并删除时区信息和年份。如果接收到 RFC 3164 格式的消息并且必须转换为符合本文档的格式，则应该添加当前年份，并且可以 (MAY) 使用中继或收集器的时区。
RFC 3164 中的 HOSTNAME 不太具体，但本文档仍支持此格式作为备用 HOSTNAME 表示之一。
消息的 MSG 部分在 RFC 3164 中描述为 TAG 和 CONTENT。在本文档中，MSG 是 RFC 3164 中称为 CONTENT 的内容。TAG 现在是报文头的一部分，但不是单个字段。TAG 已拆分为 APP-NAME、PROCID 和 MSGID。这并不完全类似于 TAG 的用法，但在大多数情况下提供相同的功能。
在 RFC 3164 中，未描述 STRUCTURED-DATA。如果符合本文档的消息包含 STRUCTURED-DATA 并且必须根据 RFC 3164 重新格式化，则 STRUCTURED-DATA 只是成为 RFC 3164 CONTENT 自由格式文本的一部分。
总的来说，本文档试图提供一个易于解析的报文头，具有清晰的字段分隔，而传统的 BSD Syslog 遭受一些历史发展的、难以解析的字段分隔规则。
A.2. Message Length (消息长度)
实施者应注意第 6.1 节中概述的消息大小限制，并尝试将最重要的数据保留在消息的早期（在最小保证长度内）。这确保了即使消息路径上的中继处的传输接收器截断消息，收集器或中继也能看到数据。
Syslog 传输接收器只需要支持接收不超过 480 个八位字节的原因，除其他事项外，与破损网络中的困难传递问题有关。Syslog 消息可以使用具有此 480 八位字节限制的 UDP 传输映射，以避免会话开销和消息分段 (Message Fragmentation)。在有问题的网络中，成功传递一条单数据包消息的可能性高于成功传递两个消息片段。因此，使用更大的大小可能会阻止操作员获取有关问题的一些关键信息，而使用小消息可能会将该信息传递给操作员。建议用于故障排除目的的消息不应大于 480 个八位字节。为了进一步加强这一点，还观察到一些 UDP 实现通常不支持超过 480 个八位字节的消息大小。这种行为非常罕见，可能不再是一个问题。
还有其他用例，其中 Syslog 消息用于传输本质上冗长的信息，例如审计数据 (Audit Data)。通过不强制执行消息大小的任何上限，可以使用所需的任何大小实现 Syslog 应用程序，并仍然符合本文档。在这种情况下，操作员有责任确保 Syslog 基础设施中的所有组件都支持所需的消息大小。传输映射可能建议必须实现的特定消息大小限制以符合要求。
提醒实施者，消息长度以八位字节指定。对于 UTF-8 字符串，字符长度和八位字节长度之间可能存在很大差异。
必须注意，IPv6 MTU 约为 480 的 2.5 倍。因此，针对仅 IPv6 环境的实现可能假设这是一个更大的最小大小。
A.3. Severity Values (严重性值)
本节描述使用第 6.2.1 节中概述的 Severity 的指南。
所有实现都应尝试为其消息分配最合适的严重性。最重要的是，旨在启用软件调试或测试的消息应分配 Severity 7。Severity 0 应保留用于非常重要的消息（如严重的硬件故障或即将发生的电源故障）。如果由管理员配置，实现可以将 Severity 0 和 7 用于其他目的。
由于严重性非常主观，中继或收集器不应假设所有发起者对严重性具有相同的定义。
A.4. TIME-SECFRAC Precision (时间秒分数精度)
第 6.2.3 节中描述的 TIMESTAMP 支持秒的小数部分 (Fractional Seconds)。这为一个非常常见的编码错误提供了基础，其中从秒的小数部分中删除了前导零。例如，TIMESTAMP "2003-10-11T22:13:14.003" 可能被错误地写为 "2003-10-11T22:13:14.3"。这将表示 300 毫秒而不是实际意味的 3 毫秒。
A.5. Case Convention for Names (名称大小写约定)
名称在本文档的各个地方使用，例如用于 SD-ID 和 PARAM-NAME。本文档始终使用 "小驼峰命名法 (Lower Camel Case)"。这样，每个名称都以小写字母开头，每个新的嵌入单词都以大写字母开头，没有连字符或其他分隔符。这方面的一个例子是 "timeQuality"。
虽然实现可以自由地对实验性名称使用任何其他大小写约定，但建议遵循上述概述的大小写约定。
A.6. Syslog Applications Without Knowledge of Time (不知道时间的 Syslog 应用程序)
在第 6.2.3 节中，允许不知道时间的发起者使用 NILVALUE。这样做是为了支持 Syslog 应用程序完全不了解时间的特殊情况。可以争论在当今的 IT 基础设施中是否能找到这样的 Syslog 应用程序。但是，讨论表明这些东西可能在实践中存在，因此应该为这种情况建立指南。
但是，如果底层操作系统、编程系统和硬件支持时钟功能 (Clock Function)，实现应该 (SHOULD) 发出有效的 TIMESTAMP。即使很难获取系统时间，也应该发出正确的 TIMESTAMP。只有在实际上无法获取时间信息时才应该使用 NILVALUE。此规则不应该被用作懒惰实现的借口。
A.7. Notes on the timeQuality SD-ID (关于 timeQuality SD-ID 的说明)
建议值 "0" 成为 "tzKnown"（第 7.1.1 节）参数的默认值。只有在管理员明确配置时区之后，才应该将其更改为 "1"。如果底层操作系统提供准确的时区信息，则可以使用值 "1" 作为默认值。仍然建议管理员考虑时区信息的正确性。
重要的是不要用 timeQuality SD-ID（第 7.1 节）造成错误的准确性印象。发起者只有在实际知道它在这些范围内时才应该指示给定的准确性。通常假设发起者通过操作员配置获得这种深入的知识。默认情况下，不应提供准确性。
A.8. UTF-8 Encoding and the BOM (UTF-8 编码和 BOM)
本文档指定 SD-PARAM 必须始终以 UTF-8 编码。不符合本规范的设备不允许 MSG 部分中消息的其他编码，包括 ASCIIPRINT。这里需要解决两种情况。首先，符合本规范的 Syslog 应用程序可能无法确定从发起者给它的信息是以 UTF-8 编码的。如果它无法确定这一点，Syslog 应用程序可以选择不在 MSG 中包含 BOM。如果 Syslog 应用程序有良好的迹象表明消息的内容是以 UTF-8 编码的，那么它应该包括 BOM。在第二种情况下，Syslog 中继可能正在转发来自不符合本规范的设备的消息。在这种情况下，除非设备已确定接收到的消息是以 UTF-8 编码的，否则它可能不会包括 BOM。
Author's Address (作者地址)
Rainer Gerhards
Adiscon GmbH
Mozartstrasse 21
Grossrinderfeld, BW 97950
Germany
Email: <[email protected]>