Network Working Group D. New
Request for Comments: 3195 M. Rose
Category: Standards Track Dover Beach Consulting, Inc.
November 2001
Network Working Group D. New
Request for Comments: 3195 M. Rose
Category: Standards Track Dover Beach Consulting, Inc.
November 2001
Reliable Delivery for syslog
syslog的可靠交付
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
The BSD Syslog Protocol describes a number of service options related to propagating event messages. This memo describes two mappings of the syslog protocol to TCP connections, both useful for reliable delivery of event messages. The first provides a trivial mapping maximizing backward compatibility. The second provides a more complete mapping. Both provide a degree of robustness and security in message delivery that is unavailable to the usual UDP-based syslog protocol, by providing encryption and authentication over a connection-oriented protocol.
BSD Syslog协议描述了与传播事件消息相关的许多服务选项。此备忘录描述了syslog协议到TCP连接的两个映射，这两个映射都有助于可靠地传递事件消息。第一个提供了一个简单的映射，最大化了向后兼容性。第二种方法提供了更完整的映射。通过在面向连接的协议上提供加密和身份验证，两者都在消息传递中提供了一定程度的健壮性和安全性，这是通常基于UDP的系统日志协议所无法提供的。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Model . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The RAW Profile . . . . . . . . . . . . . . . . . . . . . . 7
3.1 RAW Profile Overview . . . . . . . . . . . . . . . . . . . . 7
3.2 RAW Profile Identification and Initialization . . . . . . . 9
3.3 RAW Profile Message Syntax . . . . . . . . . . . . . . . . . 10
3.4 RAW Profile Message Semantics . . . . . . . . . . . . . . . 10
4. The COOKED Profile . . . . . . . . . . . . . . . . . . . . . 11
4.1 COOKED Profile Overview . . . . . . . . . . . . . . . . . . 11
4.2 COOKED Profile Identification and Initialization . . . . . . 11
4.3 COOKED Profile Message Syntax . . . . . . . . . . . . . . . 11
4.4 COOKED Profile Message Semantics . . . . . . . . . . . . . . 12
4.4.1 The IAM Element . . . . . . . . . . . . . . . . . . . . . . 12
4.4.2 The ENTRY Element . . . . . . . . . . . . . . . . . . . . . 14
4.4.3 The PATH Element . . . . . . . . . . . . . . . . . . . . . . 19
5. Additional Provisioning . . . . . . . . . . . . . . . . . . 25
5.1 Message Authenticity . . . . . . . . . . . . . . . . . . . . 25
5.2 Message Replay . . . . . . . . . . . . . . . . . . . . . . . 25
5.3 Message Integrity . . . . . . . . . . . . . . . . . . . . . 25
5.4 Message Observation . . . . . . . . . . . . . . . . . . . . 26
5.5 Summary of Recommended Practices . . . . . . . . . . . . . . 26
6. Initial Registrations . . . . . . . . . . . . . . . . . . . 27
6.1 Registration: The RAW Profile . . . . . . . . . . . . . . . 27
6.2 Registration: The COOKED Profile . . . . . . . . . . . . . . 27
7. The syslog DTD . . . . . . . . . . . . . . . . . . . . . . . 28
8. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . . 32
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 33
9.1 Registration: BEEP Profiles . . . . . . . . . . . . . . . . 33
9.2 Registration: The System (Well-Known) TCP port number for
syslog-conn . . . . . . . . . . . . . . . . . . . . . . . 33
10. Security Considerations . . . . . . . . . . . . . . . . . . 34
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Model . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The RAW Profile . . . . . . . . . . . . . . . . . . . . . . 7
3.1 RAW Profile Overview . . . . . . . . . . . . . . . . . . . . 7
3.2 RAW Profile Identification and Initialization . . . . . . . 9
3.3 RAW Profile Message Syntax . . . . . . . . . . . . . . . . . 10
3.4 RAW Profile Message Semantics . . . . . . . . . . . . . . . 10
4. The COOKED Profile . . . . . . . . . . . . . . . . . . . . . 11
4.1 COOKED Profile Overview . . . . . . . . . . . . . . . . . . 11
4.2 COOKED Profile Identification and Initialization . . . . . . 11
4.3 COOKED Profile Message Syntax . . . . . . . . . . . . . . . 11
4.4 COOKED Profile Message Semantics . . . . . . . . . . . . . . 12
4.4.1 The IAM Element . . . . . . . . . . . . . . . . . . . . . . 12
4.4.2 The ENTRY Element . . . . . . . . . . . . . . . . . . . . . 14
4.4.3 The PATH Element . . . . . . . . . . . . . . . . . . . . . . 19
5. Additional Provisioning . . . . . . . . . . . . . . . . . . 25
5.1 Message Authenticity . . . . . . . . . . . . . . . . . . . . 25
5.2 Message Replay . . . . . . . . . . . . . . . . . . . . . . . 25
5.3 Message Integrity . . . . . . . . . . . . . . . . . . . . . 25
5.4 Message Observation . . . . . . . . . . . . . . . . . . . . 26
5.5 Summary of Recommended Practices . . . . . . . . . . . . . . 26
6. Initial Registrations . . . . . . . . . . . . . . . . . . . 27
6.1 Registration: The RAW Profile . . . . . . . . . . . . . . . 27
6.2 Registration: The COOKED Profile . . . . . . . . . . . . . . 27
7. The syslog DTD . . . . . . . . . . . . . . . . . . . . . . . 28
8. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . . 32
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 33
9.1 Registration: BEEP Profiles . . . . . . . . . . . . . . . . 33
9.2 Registration: The System (Well-Known) TCP port number for
syslog-conn . . . . . . . . . . . . . . . . . . . . . . . 33
10. Security Considerations . . . . . . . . . . . . . . . . . . 34
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 36
The syslog protocol [1] presents a spectrum of service options for provisioning an event-based logging service over a network. Each option has associated benefits and costs. Accordingly, the choice as to what combination of options is provisioned is both an engineering and administrative decision. This memo describes how to realize the syslog protocol when reliable delivery is selected as a required service. It is beyond the scope of this memo to argue for, or against, the use of reliable delivery for the syslog protocol.
syslog协议[1]提供了一系列服务选项，用于通过网络提供基于事件的日志记录服务。每个选项都有相关的收益和成本。因此，关于提供何种选项组合的选择是工程和行政决策。本备忘录描述了在选择可靠交付作为必需服务时如何实现syslog协议。支持或反对使用syslog协议的可靠交付超出了本备忘录的范围。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2]中所述进行解释。
The syslog service supports three roles of operation: device, relay, and collector.
syslog服务支持三种操作角色：设备、中继和收集器。
Devices and collectors act as sources and sinks, respectively, of syslog entries. In the simplest case, only a device and collector are present. E.g.,
设备和收集器分别充当系统日志项的源和汇。在最简单的情况下，只存在一个设备和收集器。例如。，
+--------+ +-----------+
| Device | -----> | Collector |
+--------+ +-----------+
+--------+ +-----------+
| Device | -----> | Collector |
+--------+ +-----------+
The relationship between devices and collectors is potentially many-to-many. I.e., a device might communicate with many collectors; similarly, a collector might communicate with many devices.
设备和收集器之间的关系可能是多对多的。即，一个设备可能与多个采集器通信；类似地，收集器可能与许多设备通信。
A relay operates in both modes, accepting syslog entries from devices and other relays and forwarding those entries to collectors and other relays.
中继器在两种模式下工作，接受来自设备和其他中继器的系统日志条目，并将这些条目转发给采集器和其他中继器。
For example,
例如
+--------+ +-------+ +-------+ +-----------+
| Device | ---> | Relay | -...-> | Relay | ---> | Collector |
+--------+ +-------+ +-------+ +-----------+
+--------+ +-------+ +-------+ +-----------+
| Device | ---> | Relay | -...-> | Relay | ---> | Collector |
+--------+ +-------+ +-------+ +-----------+
As shown, more than one relay may be present between any particular device and collector.
如图所示，任何特定设备和收集器之间可能存在多个继电器。
A relay may be necessary for administrative reasons. For example, a relay might run as an application proxy on a firewall. Also, there might be one relay per company department, which authenticates all the devices in the department, and which in turn authenticates itself to a company-wide collector.
出于管理原因，可能需要继电器。例如，中继可以作为防火墙上的应用程序代理运行。此外，每个公司部门可能有一个中继，它对部门中的所有设备进行身份验证，然后向公司范围的收集器进行身份验证。
A relay can also serve to filter messages. For example, one relay may collect the syslog information from an entire web server farm, summarizing hit counts for report generation, forwarding "page not found" messages (indicating a possible broken link) to a collector that presents it to the webmaster, and sending more urgent messages (such as hardware failure reports) to a collector that gateways them to a pager. A relay may also be used to convert formats from a device's output to a collector's input.
中继也可以用于过滤消息。例如，一个中继可以从整个web服务器场收集系统日志信息，汇总生成报告的点击次数，将“未找到页面”消息（指示可能的断开链接）转发给将其呈现给网站管理员的收集器，并发送更紧急的消息（如硬件故障报告）将它们传送到寻呼机的收集器。继电器也可用于将格式从设备的输出转换为采集器的输入。
It should be noted that a role of device, relay, or collector is relevant only to a particular BEEP channel (q.v., below). A single server can serve as a device, a relay, and a collector, all at once,
应该注意的是，设备、继电器或采集器的角色仅与特定的蜂鸣声通道相关（q.v.，下文）。单个服务器可以同时充当设备、中继和收集器，
if so configured. It can even serve as a relay and a collector to the same device at the same time using different BEEP channels over the same connection-oriented session; this might be useful to collect status yet relay urgent error messages.
如果是这样配置的话。它甚至可以在同一个面向连接的会话中使用不同的BEEP通道，同时充当同一设备的中继和收集器；这可能有助于收集状态信息，同时传递紧急错误消息。
To provide reliable delivery when realizing the syslog protocol, this memo defines two BEEP profiles. BEEP [3] is a generic application protocol framework for connection-oriented, asynchronous interactions. Within BEEP, features such as authentication, privacy, and reliability through retransmission are provided. There are two profiles defined in this memo:
为了在实现syslog协议时提供可靠的交付，此备忘录定义了两个BEEP配置文件。BEEP[3]是面向连接的异步交互的通用应用程序协议框架。在BEEP中，提供了身份验证、隐私和通过重传实现的可靠性等功能。本备忘录中定义了两个配置文件：
o The RAW profile is designed to provide a high-performance, low-impact footprint, using essentially the same format as the existing UDP-based syslog service.
o 原始配置文件旨在提供高性能、低影响的占用空间，使用与现有基于UDP的系统日志服务基本相同的格式。
o The COOKED profile is designed to provide a structured entry format, in which individual entries are acknowledged (either positively or negatively).
o COOKED配置文件旨在提供结构化的条目格式，其中单个条目得到确认（肯定或否定）。
Note that both profiles run over BEEP. BEEP defines "transport mappings," specifying how BEEP messages are carried over the underlying transport technologies. At the time of this writing, only one such transport is defined, in [4], which specifies BEEP over TCP. All transport mappings are required to support enough reliability and sequencing to allow all BEEP messages on a given channel to be delivered reliably and in order. Hence, both the RAW and COOKED profile provide reliable delivery of their messages.
请注意，这两个配置文件都会在BEEP上运行。BEEP定义“传输映射”，指定BEEP消息如何通过底层传输技术传输。在撰写本文时，在[4]中只定义了一个这样的传输，它指定了TCP上的BEEP。所有传输映射都需要支持足够的可靠性和顺序，以允许可靠且有序地传递给定通道上的所有BEEP消息。因此，生的和熟的配置文件都提供了可靠的消息传递。
The choice of profile is independent of the operational roles discussed above.
配置文件的选择独立于上面讨论的操作角色。
For example, in
例如，在
+--------+ +-------+ +-----------+
| Device | -----> | Relay | -----> | Collector |
+--------+ +-------+ +-----------+
+--------+ +-------+ +-----------+
| Device | -----> | Relay | -----> | Collector |
+--------+ +-------+ +-----------+
the device-to-relay link could be configured to use the RAW profile, while the relay-to-collector link could be configured to use the COOKED profile. (For example, the relay may be parsing the RAW syslog messages from the device, knowing the details of their formats, before passing them to a more generic collector.) Indeed, the same device may use different profiles, depending on the collector to which it is sending entries.
设备到中继链路可以配置为使用原始配置文件，而中继到采集器链路可以配置为使用熟配置文件。（例如，中继器可能正在解析来自设备的原始系统日志消息，知道其格式的详细信息，然后再将其传递给更通用的收集器。）事实上，同一设备可能使用不同的配置文件，这取决于它向其发送条目的收集器。
Devices and relays MAY discover relays and collectors via the DNS SRV algorithm [5]. If so configured, the service used is "syslog" and the protocol used is "tcp". This allows for central administration of addressing, fallback for failed relays and collectors, and static load balancing. Security policies and hardware configurations may be such that device configuration is more secure than the DNS server. Hardware devices may be of such limited resources that DNS SRV access is inappropriate. Firewalls and other restrictive routing mechanisms may need to be dealt with before a reliable syslog connection can be established. In these cases, DNS might not be the most appropriate configuration mechanism.
设备和中继器可通过DNS SRV算法发现中继器和收集器[5]。如果这样配置，则使用的服务是“syslog”，使用的协议是“tcp”。这允许集中管理寻址、故障继电器和收集器的回退以及静态负载平衡。安全策略和硬件配置可以使得设备配置比DNS服务器更安全。硬件设备可能资源有限，因此DNS SRV访问不合适。在建立可靠的系统日志连接之前，可能需要处理防火墙和其他限制性路由机制。在这些情况下，DNS可能不是最合适的配置机制。
The RAW profile is designed for minimal implementation effort, high efficiency, and backwards compatibility. It is appropriate especially in cases where legacy syslog processing will be applied.
原始配置文件旨在实现最小的实现工作量、高效率和向后兼容性。它特别适用于将应用遗留系统日志处理的情况。
It should be noted that even though the RAW profile uses the same format for message payloads as the UDP version of syslog uses, delivery is reliable. The RAW syslog profile is a profile of BEEP [3], and BEEP guarantees ordered reliable delivery of messages within each individual channel.
应该注意的是，即使原始配置文件使用与syslog的UDP版本相同的消息有效负载格式，传递也是可靠的。原始系统日志配置文件是BEEP[3]的配置文件，BEEP保证在每个通道内有序可靠地传递消息。
When the profile is started, no piggyback data is supplied. All BEEP messages in the RAW profile are specified as having a MIME Content-Type [6] of application/octet-stream. Once the channel is open, the listener (not the initiator) sends a MSG message indicating it is ready to act as a syslog sink. (Refer to [3]'s Section 2.1 for a discussion of roles that a BEEP peer may perform, including definitions of the terms "listener", "initiator", "client", and "server".)
启动概要文件时，不提供任何背载数据。原始配置文件中的所有BEEP消息都指定为具有应用程序/八位字节流的MIME内容类型[6]。一旦通道打开，侦听器（而不是启动器）将发送一条消息，指示它已准备好充当系统日志接收器。（请参阅[3]的第2.1节，了解BEEP对等方可能执行的角色的讨论，包括术语“侦听器”、“启动器”、“客户端”和“服务器”的定义。）
The initiator uses ANS replies to supply one or more syslog entries in the current UDP format, as specified in [1]'s Section 3. When the initiator has no more entries to send, it finishes with a NUL reply and closes the channel.
启动器使用ANS应答以当前UDP格式提供一个或多个系统日志条目，如[1]第3节所述。当启动器没有更多要发送的条目时，它将以NUL应答结束并关闭通道。
An example might appear as follows:
下面可能会出现一个示例：
L: <wait for incoming connection>
I: <establish connection>
L: RPY 0 0 . 0 201
L: Content-type: application/beep+xml
L:
L: <greeting>
L: <profile
L: uri='http://xml.resource.org/profiles/syslog/COOKED' />
L: <profile uri='http://xml.resource.org/profiles/syslog/RAW' />
L: </greeting>
L: END
I: RPY 0 0 . 0 52
I: Content-type: application/beep+xml
I:
I: <greeting />
I: END
I: MSG 0 1 . 52 133
I: Content-type: application/beep+xml
L: <wait for incoming connection>
I: <establish connection>
L: RPY 0 0 . 0 201
L: Content-type: application/beep+xml
L:
L: <greeting>
L: <profile
L: uri='http://xml.resource.org/profiles/syslog/COOKED' />
L: <profile uri='http://xml.resource.org/profiles/syslog/RAW' />
L: </greeting>
L: END
I: RPY 0 0 . 0 52
I: Content-type: application/beep+xml
I:
I: <greeting />
I: END
I: MSG 0 1 . 52 133
I: Content-type: application/beep+xml
I:
I: <start number='1'>
I: <profile uri='http://xml.resource.org/profiles/syslog/RAW' />
I: </start>
I: END
L: RPY 0 1 . 201 100
L: Content-type: application/beep+xml
L:
L: <profile uri='http://xml.resource.org/profiles/syslog/RAW' />
L: END
L: MSG 1 0 . 0 50
L:
L: Central Services. This has not been a recording.
L: END
I: ANS 1 0 . 0 61 0
I:
I: <29>Oct 27 13:21:08 ductwork imxpd[141]: Heating emergency.END
I: ANS 1 0 . 61 58 1
I:
I: <29>Oct 27 13:22:15 ductwork imxpd[141]: Contact Tuttle.END
I: NUL 1 0 . 119 0
I: END
L: MSG 0 3 . 301 70
L: Content-Type: application/beep+xml
L:
L: <close number='1' code='200' />
L: END
I: RPY 0 3 . 185 46
I: Content-Type: application/beep+xml
I:
I: <ok />
I: END
I: MSG 0 4 . 231 72
I: Content-Type: application/beep+xml
I:
I: <close number='0' code='200' />
I: END
L: RPY 0 4 . 371 46
L: Content-type: application/beep+xml
L:
L: <ok />
L: END
L: <closes connection>
I: <closes connection>
L: <awaits next connection>
I:
I: <start number='1'>
I: <profile uri='http://xml.resource.org/profiles/syslog/RAW' />
I: </start>
I: END
L: RPY 0 1 . 201 100
L: Content-type: application/beep+xml
L:
L: <profile uri='http://xml.resource.org/profiles/syslog/RAW' />
L: END
L: MSG 1 0 . 0 50
L:
L: Central Services. This has not been a recording.
L: END
I: ANS 1 0 . 0 61 0
I:
I: <29>Oct 27 13:21:08 ductwork imxpd[141]: Heating emergency.END
I: ANS 1 0 . 61 58 1
I:
I: <29>Oct 27 13:22:15 ductwork imxpd[141]: Contact Tuttle.END
I: NUL 1 0 . 119 0
I: END
L: MSG 0 3 . 301 70
L: Content-Type: application/beep+xml
L:
L: <close number='1' code='200' />
L: END
I: RPY 0 3 . 185 46
I: Content-Type: application/beep+xml
I:
I: <ok />
I: END
I: MSG 0 4 . 231 72
I: Content-Type: application/beep+xml
I:
I: <close number='0' code='200' />
I: END
L: RPY 0 4 . 371 46
L: Content-type: application/beep+xml
L:
L: <ok />
L: END
L: <closes connection>
I: <closes connection>
L: <awaits next connection>
Here we see a BEEP session established, followed by the use of the RAW profile. The initiator is a device, while the listener is a collector. The initiator opens the channel, but the listener sends the first MSG. This allows the initiator to send any number of ANS replies carrying syslog event messages. The initiator sends a NUL reply to indicate it is finished. Upon receiving the NUL, the listener closes the RAW channel. The initiator has the choice of closing the entire BEEP session or opening a new syslog channel (RAW or COOKED) for more transfers. In this example, the initiator chooses to close the entire BEEP session.
在这里，我们看到建立了一个BEEP会话，然后使用原始配置文件。启动器是一个设备，而侦听器是一个收集器。启动器打开通道，但侦听器发送第一条消息。这允许启动器发送任意数量的ANS回复，其中包含系统日志事件消息。发起者发送NUL应答以指示它已完成。接收到NUL后，侦听器关闭原始通道。启动器可以选择关闭整个BEEP会话或打开新的系统日志通道（原始或已烹调）以进行更多传输。在本例中，启动器选择关闭整个BEEP会话。
The overhead for one ANS frame is about thirty octets, once the initial handshakes have been exchanged. If this overhead is too high, then messages are likely being generated at a high rate. In this case, multiple syslog messages can be aggregated into a single ANS frame, each separated by a CRLF sequence from the preceding. The final message still MUST NOT end with a CRLF.
一旦交换了初始握手，一个ANS帧的开销约为30个八位字节。如果此开销太高，则消息可能以很高的速率生成。在这种情况下，可以将多个系统日志消息聚合到一个ANS帧中，每个ANS帧由前面的CRLF序列分隔。最后一条消息仍然不能以CRLF结尾。
For example,
例如
L: MSG 1 0 . 0 50
L:
L: Central Services. This has not been a recording.
L: END
I: ANS 1 0 . 0 119 0
I:
I: <29>Oct 27 13:21:08 ductwork imxpd[141]: Heating emergency.
I: <29>Oct 27 13:21:09 ductwork imxpd[141]: Contact Tuttle.END
I: NUL 1 0 . 119 0
I: END
L: MSG 1 0 . 0 50
L:
L: Central Services. This has not been a recording.
L: END
I: ANS 1 0 . 0 119 0
I:
I: <29>Oct 27 13:21:08 ductwork imxpd[141]: Heating emergency.
I: <29>Oct 27 13:21:09 ductwork imxpd[141]: Contact Tuttle.END
I: NUL 1 0 . 119 0
I: END
The RAW syslog profile is identified as
原始系统日志配置文件标识为
http://xml.resource.org/profiles/syslog/RAW
http://xml.resource.org/profiles/syslog/RAW
in the BEEP "profile" element during channel creation.
在频道创建过程中，在“配置文件”元素中。
No data is piggybacked during channel creation.
在通道创建期间没有数据被携带。
All BEEP messages in this profile have a MIME content-type of application/octet-stream. The listener's first BEEP message is ignored and indeed may be empty except for headers; hence, any syntax is acceptable.
此配置文件中的所有BEEP消息都具有MIME内容类型application/octet stream。监听器的第一条蜂鸣声信息被忽略，除标题外，可能为空；因此，任何语法都是可以接受的。
The ANS replies the initiator sends in response MUST be formatted according to Section 4 of [1]. In particular, If the receiver is acting as a relay, then it MUST follow the rules as laid out in Section 4.2.2 of [1].
发起者在响应中发送的ANS回复必须按照[1]的第4节进行格式化。特别是，如果接收器作为继电器，则必须遵守[1]第4.2.2节中规定的规则。
If multiple syslog messages are included in a single ANS reply, each is separated from the preceding with a CRLF. There is no ending delimiter, but each syslog event message body length MUST be 1024 bytes or less, excluding BEEP framing overhead. Note that there MUST NOT be a CRLF between the text of the final syslog event message and the "END" marking the trailer of the BEEP frame.
如果单个ANS回复中包含多个系统日志消息，则每个消息都用CRLF与前面的消息分开。没有结束分隔符，但每个syslog事件消息正文长度必须小于等于1024字节，不包括BEEP帧开销。请注意，在最后一条syslog事件消息的文本和标记蜂鸣器帧尾部的“END”之间不得有CRLF。
The listener's opening BEEP MSG message has no semantics. (It is a good place to put in an identifying greeting.) The initiator's ANS replies MUST specify a facility, severity, and textual message, as described in [1].
侦听器的打开蜂鸣消息没有语义。（这是放置识别问候语的好地方。）发起者的ANS回复必须指定设施、严重性和文本消息，如[1]所述。
The COOKED profile is designed for new implementations of syslog protocol handlers. It provides a much finer grain of information tagging, allowing a better degree of automation in processing. Naturally, it includes more overhead as well in support of this.
COOKED概要文件是为syslog协议处理程序的新实现而设计的。它提供了更细粒度的信息标记，允许在处理过程中实现更高程度的自动化。当然，为了支持这一点，它还包括更多的开销。
The COOKED profile supports three elements of interest:
熟食配置文件支持三个感兴趣的元素：
o The "iam" element identifies the sender to the receiver, allowing each peer to name itself for the other, and specifying the roles (device, relay, or collector) each is taking on.
o “iam”元素将发送方标识给接收方，允许每个对等方为另一方命名自己，并指定每个对等方承担的角色（设备、中继或收集器）。
o The "entry" element provides a parsed version of the syslog entry, with the various fields of interest broken out.
o “entry”元素提供了syslog条目的解析版本，其中包含各种感兴趣的字段。
o The "path" element identifies a list of relays through which a tagged collection of "entry" elements has passed, along with a set of flags indicating what assurances of security have been in effect throughout its delivery.
o “path”元素标识了一个继电器列表，带标签的“entry”元素集合通过该列表传递，并带有一组标志，指示在整个传递过程中安全保证的有效性。
The COOKED syslog profile is identified as
系统日志配置文件标识为
http://xml.resource.org/profiles/syslog/COOKED
http://xml.resource.org/profiles/syslog/COOKED
in the BEEP "profile" element during channel creation.
在频道创建过程中，在“配置文件”元素中。
During channel creation, the corresponding "profile" element in the BEEP "start" element may contain an "iam" element. If channel creation is successful, then before sending the corresponding reply, the BEEP peer processes the "iam" element and includes the resulting response in the reply. This response will be an "ok" element or an "error" element. The choice of which element is returned is dependent on local provisioning of the recipient. Including an "iam" in the initial "start" element has exactly the same semantics as passing it as the first MSG message on the channel.
在频道创建过程中，蜂鸣“开始”元素中相应的“配置文件”元素可能包含“iam”元素。如果通道创建成功，则在发送相应的回复之前，BEEP对等方将处理“iam”元素，并在回复中包含结果响应。此响应将是“ok”元素或“error”元素。返回哪个元素的选择取决于收件人的本地设置。在初始“start”元素中包含“iam”与在通道上传递第一条MSG消息的语义完全相同。
All BEEP messages in this profile have a MIME Content-Type [6] of application/beep+xml. The syntax of the individual elements is specified in Section 7.
此配置文件中的所有BEEP消息的MIME内容类型[6]为application/BEEP+xml。第7节规定了各个元素的语法。
Initiators issue two elements: "iam" and "entry", each using a "MSG" message. The listener issues "ok" in "RPY" messages and "error" in "ERR" messages. (See [3]'s Section 2.3.1 for the definitions of the "error" and "ok" elements.)
发起者发出两个元素：“iam”和“entry”，每个元素使用“MSG”消息。侦听器在“RPY”消息中发出“ok”，在“ERR”消息中发出“error”。（有关“错误”和“正常”元素的定义，请参见[3]第2.3.1节。）
The "iam" element serves to identify a device, relay, or collector at one end of the BEEP channel to the device, relay, or collector at the other end of the channel. The "iam" element includes the type of peer (device, relay, or collector), the fully qualified domain name of the peer, and an IP address of the peer. (The IP address chosen SHOULD be the IP address associated with the underlying transport protocol carrying the channel.) The character data of the element is free-form human-readable text. It may be used to further identify the peer, such as by describing the physical location of the machine.
“iam”元素用于将蜂鸣音通道一端的设备、继电器或采集器识别为通道另一端的设备、继电器或采集器。“iam”元素包括对等方的类型（设备、中继或收集器）、对等方的完全限定域名以及对等方的IP地址。（选择的IP地址应该是与承载通道的底层传输协议关联的IP地址。）元素的字符数据是自由格式的人类可读文本。它可用于进一步识别对等方，例如通过描述机器的物理位置。
An "iam" element may be sent by the initiator of the channel at any time. The listener responds to an "iam" element with an "ok" (indicating acceptance), or an "error" (indicating rejection). The identity and role in effect is specified by the most recent "iam" answered with an "ok".
信道的发起者可随时发送“iam”元素。侦听器用“ok”（表示接受）或“error”（表示拒绝）响应“iam”元素。有效的身份和角色由最新的“iam”指定，回答为“ok”。
An "iam" could be rejected (with an "error" element) by the listener if the privacy or authentication that has been negotiated is inadequate or if the authenticated user does not have authorization to serve in the specified role. It is expected that most installations will require an "iam" from the peer before accepting any "entry" messages.
如果协商的隐私或身份验证不充分，或者如果经过身份验证的用户没有授权担任指定角色，则侦听器可能会拒绝“iam”（带有“错误”元素）。预计大多数安装在接受任何“输入”消息之前都需要来自对等方的“iam”。
For example, a successful creation might look like this:
例如，成功的创建可能如下所示：
I: MSG 0 10 . 1832 259
I: Content-type: application/beep+xml
I:
I: <start number='1'>
I: <profile
I: uri='http://xml.resource.org/profiles/syslog/COOKED'>
I: <![CDATA[ <iam fqdn='lowry.example.com' ip='10.0.0.27'
I: type='device'/> ]]>
I: </profile>
I: </start>
L: END
L: RPY 0 10 . 704 138
L: Content-type: application/beep+xml
L:
L: <profile uri='http://xml.resource.org/profiles/syslog/COOKED'>
L: <![CDATA[ <ok /> ]]>
L: </profile>
L: END
I: MSG 0 10 . 1832 259
I: Content-type: application/beep+xml
I:
I: <start number='1'>
I: <profile
I: uri='http://xml.resource.org/profiles/syslog/COOKED'>
I: <![CDATA[ <iam fqdn='lowry.example.com' ip='10.0.0.27'
I: type='device'/> ]]>
I: </profile>
I: </start>
L: END
L: RPY 0 10 . 704 138
L: Content-type: application/beep+xml
L:
L: <profile uri='http://xml.resource.org/profiles/syslog/COOKED'>
L: <![CDATA[ <ok /> ]]>
L: </profile>
L: END
A creation with an embedded "iam" that fails might look like this:
带有嵌入式“iam”的创建失败可能如下所示：
C: MSG 0 12 . 1832 259
C: Content-type: application/beep+xml
C:
C: <start number='1'>
C: <profile
C: uri='http://xml.resource.org/profiles/syslog/COOKED'>
C: <![CDATA[ <iam fqdn='tuttle.example.com' ip='10.0.0.29'
C: type='relay'/> ]]>
C: </profile>
C: </start>
C: END
S: RPY 0 12 . 704 241
S: Content-type: application/beep+xml
S:
S: <profile uri='http://xml.resource.org/profiles/syslog/COOKED'>
S: <![CDATA[
S: <error code='535'>User 'buttle.example.com' not allowed
S: to "iam" for 'tuttle.example.com'</error> ]]>
S: </profile>
S: END
C: MSG 0 12 . 1832 259
C: Content-type: application/beep+xml
C:
C: <start number='1'>
C: <profile
C: uri='http://xml.resource.org/profiles/syslog/COOKED'>
C: <![CDATA[ <iam fqdn='tuttle.example.com' ip='10.0.0.29'
C: type='relay'/> ]]>
C: </profile>
C: </start>
C: END
S: RPY 0 12 . 704 241
S: Content-type: application/beep+xml
S:
S: <profile uri='http://xml.resource.org/profiles/syslog/COOKED'>
S: <![CDATA[
S: <error code='535'>User 'buttle.example.com' not allowed
S: to "iam" for 'tuttle.example.com'</error> ]]>
S: </profile>
S: END
In this case, the error code indicates that the user "buttle.example.com" has logged in via some SASL profile, but the syslog COOKED profile implementation is claiming to be "tuttle.example.com", a mismatch that the server is disallowing.
在本例中，错误代码表示用户“buttle.example.com”已通过某个SASL配置文件登录，但syslog-COOKED配置文件实现声称为“tuttle.example.com”，这是服务器不允许的不匹配。
The "entry" element carries the details of a single syslog entry. The attributes of an "entry" element include "facility", "severity", "timestamp", "hostname", and "tag". "Facility" and "severity" have the semantics defined in [1]'s 4.1. The other attributes have the semantics as in Sections 4.2.1 and 4.2.3 of [1]. An "entry" element can also contain a "pathID" attribute, described below.
“entry”元素包含单个syslog条目的详细信息。“entry”元素的属性包括“facility”、“severity”、“timestamp”、“hostname”和“tag”。“设施”和“严重性”具有[1]的4.1中定义的语义。其他属性具有[1]第4.2.1节和第4.2.3节所述的语义。“entry”元素还可以包含“pathID”属性，如下所述。
If the client is a relay, the "entry" SHOULD also contain the attributes "deviceFQDN" and "deviceIP", specifying the FQDN and IP address of the device that originally created the entry. These attributes may be added by either the relay or the originating device. If possible, the device SHOULD add these entries, referring to the interface most closely associated with the syslog entry. Before a relay forwards an entry from a device that does not carry these attributes, it SHOULD add them based on the "iam" element it has received from the device, or based on the underlying transport connection address. A relay MUST NOT add these fields if they are missing and an "iam" element on the channel has indicated that messages are coming from another relay.
如果客户端是中继，“条目”还应包含属性“DeviceQDN”和“deviceIP”，指定最初创建条目的设备的FQDN和IP地址。这些属性可以由中继或发起设备添加。如果可能，设备应该添加这些条目，引用与syslog条目最密切相关的接口。在中继转发来自不携带这些属性的设备的条目之前，它应该根据从设备接收到的“iam”元素或基础传输连接地址添加这些属性。如果缺少这些字段并且通道上的“iam”元素指示消息来自另一个中继，则中继不得添加这些字段。
The "pathID" attribute indicates the path over which this entry has travelled, from device through relays to the final collector. Syntactically, its value is a string of digits that must match the "pathID" attribute of a "path" element sent earlier over the current channel. Semantically, it indicates that the list of relays and flags indicated in that earlier "path" element apply to this "entry" element.
“pathID”属性表示该条目从设备通过继电器到最终采集器的路径。从语法上讲，它的值是一个数字字符串，必须与先前通过当前通道发送的“path”元素的“pathID”属性相匹配。从语义上讲，它表示在前面的“path”元素中指示的继电器和标志列表适用于这个“entry”元素。
The character data for the element is the unstructured syslog event message being logged. If the original device delivers the message for the first time via the COOKED profile, it may have any structure inside the CDATA. However, for maximum compatibility, the device SHOULD format the CDATA of the message in accordance with Sections 4.2.1 through 4.2.3 of [1].
元素的字符数据是正在记录的非结构化syslog事件消息。如果原始设备第一次通过熟食配置文件发送消息，则它可能在CDATA中具有任何结构。但是，为了实现最大兼容性，设备应按照[1]第4.2.1节至第4.2.3节的规定格式化消息的CDATA。
In the message is being relayed, "tag" SHOULD be those of the original device generating the entry (unless the device cannot supply a tag). The "timestamp" SHOULD be that of the original entry generation time, rather than the time the entry was passed outward from the relay. The "hostname" SHOULD be the host name or IP address by which the device knows itself; this MUST follow the rules established in Sections 4.2.1 through 4.2.3 of [1]. The original contents of the syslog message MUST be preserved in the CDATA of the "entry" element; this includes preservation of exact content during translation from the UDP or RAW formats. In particular, the timestamps MUST NOT be rewritten in the CDATA of the "entry" element, the tag MUST NOT be removed from the CDATA even if presented in the "entry" attributes as well, and so on.
在正在中继的消息中，“标签”应为生成条目的原始设备的标签（除非该设备无法提供标签）。“时间戳”应该是原始条目生成时间的时间戳，而不是条目从中继器向外传递的时间戳。“主机名”应该是设备知道自己的主机名或IP地址；这必须遵循[1]第4.2.1节至第4.2.3节规定的规则。syslog消息的原始内容必须保留在“entry”元素的CDATA中；这包括在从UDP或原始格式翻译时保留准确内容。特别是，时间戳不得在“entry”元素的CDATA中重写，标记不得从CDATA中删除，即使在“entry”属性中也显示，以此类推。
To be consistent with the spirit of [1], a relay receiving a message that does not contain a valid priority, timestamp or hostname will follow the same general rules as described in section 4.2.2 of [1] while including the exact contents of the received syslog packet as the CDATA. The values of the facility and severity will be construed to be 8 and 6 respectively and will be placed into the appropriate attributes of the "entry" element. The hostname will be the name of the device as it is known to the relay and will also be inserted into the "entry" element's attributes. The timestamp would be set to the received time, inserted only into the attributes of the "entry" element. As an example, consider this message received on UDP port 514 and interpreted as a traditional syslog message, assuming the underlying IP source address is that of the "pipeworks" machine:
为了与[1]的精神保持一致，接收不包含有效优先级、时间戳或主机名的消息的中继将遵循与[1]第4.2.2节所述相同的一般规则，同时将接收到的syslog数据包的确切内容作为CDATA。设施值和严重性值将分别解释为8和6，并将放入“输入”元素的适当属性中。主机名将是中继器已知的设备名称，也将插入到“entry”元素的属性中。时间戳将被设置为接收时间，仅插入“entry”元素的属性中。作为一个例子，考虑UDP端口514上接收到的消息，并将其解释为传统的SysLogo消息，假设底层IP源地址是“PiPEWorkS”机器：
<.....eeeek!
<.....eeeek!
To be relayed, it must be modified as follows:
要进行中继，必须对其进行如下修改：
C: MSG 1 0 . 2079 156
C: Content-Type: application/beep+xml
C:
C: <entry facility='8' severity='6'
C: hostname='pipeworks'
C: timestamp='Oct 31 23:59:59'
C: ><.....eeeek!</entry>
C: END
S: RPY 1 0 . 933 45
S: Content-Type: application/beep+xml
S:
S: <ok/>
S: END
C: MSG 1 0 . 2079 156
C: Content-Type: application/beep+xml
C:
C: <entry facility='8' severity='6'
C: hostname='pipeworks'
C: timestamp='Oct 31 23:59:59'
C: ><.....eeeek!</entry>
C: END
S: RPY 1 0 . 933 45
S: Content-Type: application/beep+xml
S:
S: <ok/>
S: END
As another example, consider a message being received that does not properly adhere to the conventions described in Section 4.2.2 of [1]. In particular, the timestamp has a year, making it a nonstandard format:
作为另一个例子，考虑正在接收的消息，该消息不正确地遵守在[4.2]第4.2.2节中所描述的约定。特别是，时间戳有一年，使其成为非标准格式：
<166> 1990 Oct 22 01:00:00 bomb tick[0]: BOOM!
<166> 1990 Oct 22 01:00:00 bomb tick[0]: BOOM!
This would be relayed as follows:
这将按如下方式进行转播：
C: MSG 1 0 . 2235 242
C: Content-Type: application/beep+xml
C:
C: <entry facility='160' severity='6'
C: hostname='bomb'
C: deviceFQDN='bomb.terrorist.net' deviceIP='10.0.0.83'
C: timestamp='Oct 22 01:00:04'
C: ><166> 1990 Oct 22 01:00:00 bomb tick[0]: BOOM!</entry>
C: END
S: RPY 1 0 . 978 45
S: Content-Type: application/beep+xml
S:
S: <ok/>
S: END
C: MSG 1 0 . 2235 242
C: Content-Type: application/beep+xml
C:
C: <entry facility='160' severity='6'
C: hostname='bomb'
C: deviceFQDN='bomb.terrorist.net' deviceIP='10.0.0.83'
C: timestamp='Oct 22 01:00:04'
C: ><166> 1990 Oct 22 01:00:00 bomb tick[0]: BOOM!</entry>
C: END
S: RPY 1 0 . 978 45
S: Content-Type: application/beep+xml
S:
S: <ok/>
S: END
Note that the tag value was not readily apparent from the received message (due to the failed parsing of the timestamp), so it was not included in the "entry" element.
请注意，标记值在收到的消息中并不明显（由于时间戳解析失败），因此它没有包含在“entry”元素中。
It is explicitly permitted for a relay to parse raw messages in a more sophisticated way, but all implementations MUST be able to parse messages presented in the format described in [1]. A more sophisticated relay could have recognized the year and completely parsed out the correct time, tag, and hostname, but such additional parsing capability is OPTIONAL.
明确允许中继以更复杂的方式解析原始消息，但所有实现必须能够解析以[1]中所述格式呈现的消息。更复杂的中继可以识别年份并完全解析出正确的时间、标记和主机名，但这种额外的解析功能是可选的。
Consider the following example, in contrast:
对比一下下面的例子：
<166> Oct 22 01:00:00 bomb tick[0]: BOOM!
<166> Oct 22 01:00:00 bomb tick[0]: BOOM!
This conformant message would be relayed as follows:
该一致性信息将按如下方式传递：
C: MSG 1 0 . 2477 248
C: Content-Type: application/beep+xml
C:
C: <entry facility='160' severity='6'
C: hostname='bomb'
C: deviceFQDN='bomb.terrorist.net' deviceIP='10.0.0.83'
C: timestamp='Oct 22 01:00:00' tag='tick'
C: ><166> Oct 22 01:00:00 bomb tick[0]: BOOM!</entry>
C: END
S: RPY 1 0 . 1023 45
S: Content-Type: application/beep+xml
S:
S: <ok/>
S: END
C: MSG 1 0 . 2477 248
C: Content-Type: application/beep+xml
C:
C: <entry facility='160' severity='6'
C: hostname='bomb'
C: deviceFQDN='bomb.terrorist.net' deviceIP='10.0.0.83'
C: timestamp='Oct 22 01:00:00' tag='tick'
C: ><166> Oct 22 01:00:00 bomb tick[0]: BOOM!</entry>
C: END
S: RPY 1 0 . 1023 45
S: Content-Type: application/beep+xml
S:
S: <ok/>
S: END
In this case, the tag is detected and the timestamp represents the message generation time rather than the message reception time.
在这种情况下，检测到标签，并且时间戳表示消息生成时间而不是消息接收时间。
Finally, the "entry" element may also contain an "xml:lang" attribute, indicating the language in which the CDATA content of the tag is presented, as described in [7].
最后，“entry”元素还可能包含一个“xml:lang”属性，表示标记的CDATA内容所使用的语言，如[7]所述。
The "entry" element is answered with either an empty "ok" element if everything was successful, or a standard "error" element if there was a problem. An "entry" element can be rejected if no "iam" element has been accepted by the listener. It can also be rejected if the user authenticated on the BEEP session (if any) does not have the authority to generate (as a device) or relay that entry. An error is also possible if the "pathID" attribute refers to an unknown (or rejected) "path" element.
如果一切都成功，“entry”元素将用空的“ok”元素回答，如果出现问题，则用标准的“error”元素回答。如果侦听器未接受任何“iam”元素，则可以拒绝“entry”元素。如果在BEEP会话（如果有）上经过身份验证的用户没有生成（作为设备）或中继该条目的权限，也可以拒绝该条目。如果“pathID”属性引用未知（或被拒绝的）“path”元素，也可能出现错误。
A successful exchange of an "entry" element may look like this:
成功交换“entry”元素可能如下所示：
C: MSG 1 0 . 2725 173
C: Content-Type: application/beep+xml
C:
C: <entry facility='24' severity='5'
C: timestamp='Jan 26 15:16:17'
C: hostname='pipework' tag='imxp'>
C: No 27B/6 available</entry>
C: END
S: RPY 1 0 . 1068 45
S: Content-Type: application/beep+xml
S:
S: <ok/>
S: END
C: MSG 1 0 . 2725 173
C: Content-Type: application/beep+xml
C:
C: <entry facility='24' severity='5'
C: timestamp='Jan 26 15:16:17'
C: hostname='pipework' tag='imxp'>
C: No 27B/6 available</entry>
C: END
S: RPY 1 0 . 1068 45
S: Content-Type: application/beep+xml
S:
S: <ok/>
S: END
Here, the device IP address and FQDN are taken from the "iam" element, if any, or from the underlying connection information.
这里，设备IP地址和FQDN取自“iam”元素（如果有）或基础连接信息。
An example where an "entry" element is rejected with an "error" element:
“entry”元素被“error”元素拒绝的示例：
C: MSG 1 2 . 2898 223
C: Content-Type: application/beep+xml
C:
C: <entry facility='24' severity='5' timestamp='Jan 02 13:22:15'
C: deviceFQDN='jack.example.net' deviceIP='10.0.0.83'
C: tag='imxpd'>
C: Replacement device found in nostril.
C: </entry>
C: END
S: ERR 1 2 . 1113 111
S: Content-Type: application/beep+xml
S:
S: <error code='554'>Not allowed to relay for
S: jack.example.net</error>
S: END
C: MSG 1 2 . 2898 223
C: Content-Type: application/beep+xml
C:
C: <entry facility='24' severity='5' timestamp='Jan 02 13:22:15'
C: deviceFQDN='jack.example.net' deviceIP='10.0.0.83'
C: tag='imxpd'>
C: Replacement device found in nostril.
C: </entry>
C: END
S: ERR 1 2 . 1113 111
S: Content-Type: application/beep+xml
S:
S: <error code='554'>Not allowed to relay for
S: jack.example.net</error>
S: END
Here, the client attempts to relay an entry on behalf of jack.example.com, but the entry is refused by the collector for administrative reasons. This may occur, for example, if lowry.example.com is in a different department than jack.example.com.
在这里，客户端试图代表jack.example.com中继条目，但由于管理原因，该条目被收集器拒绝。例如，如果lowry.example.com与jack.example.com所在的部门不同，则可能会发生这种情况。
The "path" element serves to describe a list of the relays through which that element has passed, along with a set of flags that indicate the properties that all links from the device to the relay have shared in common. Each "path" element contains either another "path" element or is empty. An empty "path" element identifies a device, while a "path" element with a nested "path" element identifies a relay. Each "path" element names a FQDN and IP address of the interface that sent the element. Each "path" element also names a FQDN and IP address for the interface that received the element. Each "path" element also carries a "linkprops" attribute, specifying the properties of the link it describes.
“path”元素用于描述该元素经过的继电器列表，以及一组标志，这些标志指示从设备到继电器的所有链路共享的属性。每个“路径”元素包含另一个“路径”元素或为空。空的“path”元素标识设备，而带有嵌套的“path”元素的“path”元素标识继电器。每个“path”元素都命名发送该元素的接口的FQDN和IP地址。每个“path”元素还为接收该元素的接口命名FQDN和IP地址。每个“path”元素还带有一个“linkprops”属性，指定它所描述的链接的属性。
Each "path" element has a "pathID" attribute which must be unique for all "path" elements sent on this channel since its inception. Syntactically, the "pathID" attribute is a string of digits. Semantically, it serves to identify one "path" element out of many, and it serves to link a "path" element with one or more "entry" elements. Any "pathID" attribute is unrelated to any "pathID" attribute in nested "path" elements or on other channels.
每个“path”元素都有一个“pathID”属性，该属性对于自通道开始以来在此通道上发送的所有“path”元素都必须是唯一的。从语法上讲，“pathID”属性是一个数字字符串。从语义上讲，它用于标识多个“path”元素中的一个，并用于将“path”元素与一个或多个“entry”元素链接。任何“pathID”属性都与嵌套的“path”元素或其他通道上的任何“pathID”属性无关。
Each "path" element has a "fromFQDN" attribute and an "fromIP" attribute. The "fromFQDN" attribute SHOULD be the fully qualified domain name of the interface over which the "path" element was sent. (The "fromFQDN" can be omitted if that interface has no DNS entry.) Similarly, the "fromIP" attribute MUST be the IP address of the interface over which the "path" element was sent.
每个“path”元素都有一个“fromFQDN”属性和一个“fromIP”属性。“fromFQDN”属性应该是发送“path”元素的接口的完全限定域名。（如果接口没有DNS条目，“fromFQDN”可以省略。）类似地，“fromIP”属性必须是发送“path”元素的接口的IP地址。
Each "path" element has a "toFQDN" attribute and an "toIP" attribute. The "toFQDN" attribute SHOULD be the fully qualified domain name of the interface over which the "path" element was received. (The "toFQDN" can be omitted if that interface has no DNS entry.) Similarly, the "toIP" attribute MUST be the IP address of the interface over which the "path" element was received.
每个“path”元素都有一个“toFQDN”属性和一个“toIP”属性。“toFQDN”属性应该是接收“path”元素的接口的完全限定域名。（如果接口没有DNS条目，“toFQDN”可以省略。）类似地，“toIP”属性必须是接收“path”元素的接口的IP地址。
Finally, each "path" element carries a "linkprops" attribute. This is syntactically a string of individual characters, each indicating one property of the channel over which this "path" element is being carried. Note that outer "path" elements may have stronger guarantees than inner "path" elements; care should be taken in the interpretation of flags. The semantics of each possible character in this string are as follows:
最后，每个“path”元素都带有一个“linkprops”属性。这在语法上是一个由单个字符组成的字符串，每个字符表示承载此“路径”元素的通道的一个属性。注意，外部“路径”元素可能比内部“路径”元素具有更强的保证；在解释旗帜时应小心。此字符串中每个可能字符的语义如下所示：
o: When present, "o" (lower-case letter "o") indicates that weak privacy has been negotiated over this link, weakly protecting from observation the content of entries associated with this "path" element. (Weak privacy is encryption with less than 80 bits of key.)
o：存在时，“o”（小写字母“o”）表示已通过此链接协商弱隐私，弱保护与此“路径”元素关联的条目内容不被观察。（弱隐私是密钥少于80位的加密。）
O: When present, "O" (upper-case letter "O") indicates that strong privacy has been negotiated over this link, strongly protecting from observation the content of entries associated with this "path" element. (Strong privacy is encryption with 80 bits or more of key, or a transfer mechanism that is otherwise impossible to eavesdrop upon.)
O：存在时，“O”（大写字母“O”）表示已通过此链接协商了强烈的隐私，强烈保护与此“路径”元素相关的条目内容不被观察。（强隐私是使用80位或更多密钥进行加密，或者是一种不可能被窃听的传输机制。）
U: When present, "U" indicates that a valid user has been authenticated (via SASL or TLS) and an "iam" element has been accepted.
U：存在时，“U”表示有效用户已通过身份验证（通过SASL或TLS），并且“iam”元素已被接受。
A: When present, "A" indicates that this link has been protected by an authentication layer, authenticating the source of every "entry" associated with this path.
答：存在时，“A”表示此链接已受身份验证层保护，对与此路径关联的每个“条目”的源进行身份验证。
R: When present, "R" indicates that this link has been protected against message replay.
R：存在时，“R”表示此链接已受到消息重播的保护。
I: When present, "I" indicates that this link has been protected against modifications of messages in passing. ("I" stands for message Integrity.)
I：当存在时，“I”表示此链接已受到保护，以防止在传递过程中修改消息。（“I”代表消息完整性。）
L: When present, "L" indicates that this link has been protected against loss of messages. That is, this is a reliable delivery link.
L：当存在时，“L”表示此链接已受到保护，防止消息丢失。也就是说，这是一个可靠的交付链接。
D: When present, "D" indicates that the "from" side of this link is a device. If this is not present on the innermost "path" element, "entry" elements associated with this path have not been carried by the COOKED profile for their entire lifetime.
D：当存在时，“D”表示此链接的“发件人”端是一个设备。如果在最里面的“path”元素上不存在此项，则与此路径相关联的“entry”元素在其整个生命周期内都没有被烹调的概要文件携带。
Upon receiving a "path" element, the peer MUST perform the following checks:
收到“路径”元素后，对等方必须执行以下检查：
o The "fromFQDN" and "fromIP" must match the underlying transport connection.
o “fromFQDN”和“fromIP”必须与基础传输连接匹配。
o The flags in the "linkprops" attribute must match the attributes of the session.
o “linkprops”属性中的标志必须与会话的属性匹配。
o The "toFQDN" and "toIP" must match the underlying transport connection.
o “toFQDN”和“toIP”必须与基础传输连接匹配。
o The "pathID" attribute must be unique with respect to all other "path" elements received on this channel.
o “pathID”属性相对于此通道上接收的所有其他“path”元素必须是唯一的。
If all these checks pass, the "path" element is accepted with an "ok" element. Otherwise, an "error" element is generated with an appropriate code. In addition, if any of the nested "path" elements refer to the machine receiving the element, it may indicate a routing loop in the configuration for the so-identified path, and appropriate measures should be taken.
如果所有这些检查都通过，则接受“path”元素和“ok”元素。否则，将使用适当的代码生成一个“error”元素。此外，如果任何嵌套的“路径”元素指的是接收该元素的机器，则该元素可能在配置中指示所标识路径的路由循环，并且应采取适当的措施。
If the peer receiving an "entry" element is receiving it directly from a device via either syslog-conn profile, and the device has not generated a "path" element, the receiver may itself generate an appropriate "path" element, either to be recorded in the logs (if this peer is a collector) or passed to the next peer (if this peer is a relay). If a peer receives a syslog message via UDP, it may optionally generate an appropriate "peer" element based on any cryptographic information provided in the message itself.
如果接收“条目”元素的对等方通过syslog conn配置文件直接从设备接收该元素，且该设备尚未生成“路径”元素，则接收方可自行生成适当的“路径”元素，以记录在日志中（如果该对等方是收集器）或传递给下一个对等方（如果该对等方是中继）。如果对等方通过UDP接收系统日志消息，它可以根据消息本身中提供的任何加密信息选择性地生成适当的“对等”元素。
When a peer receives a "path" element, it remembers it for future use. A collector will store it in the log for later reference. A relay will remember it. When an "entry" arrives referencing the received "path" element, and that entry needs to be forwarded to another relay or collector, and no appropriate "path" element has already been generated, an appropriate "path" element is generated and sent over the outbound channel before the entry is forwarded. An appropriate "path" element is created by taking the received "path" element, wrapping it in a new "path" element with the appropriate attributes, and assigning it a new "pathID" attribute. When future "entry" elements arrive with the same incoming "pathID" attribute, and they need to be forwarded to a channel over which an appropriate "pathID" attribute has already been sent, only the "pathID" attribute of the "entry" element needs to be rewritten to refer to the "path" element on the outgoing channel.
当对等方收到“path”元素时，它会记住它以备将来使用。收集器会将其存储在日志中以供以后参考。继电器会记住它。当参考接收到的“路径”元素的“条目”到达时，需要将该条目转发给另一个中继器或采集器，并且尚未生成适当的“路径”元素，则在转发条目之前，会生成适当的“路径”元素并通过出站通道发送。通过获取接收到的“path”元素，将其包装在具有适当属性的新“path”元素中，并为其分配新的“pathID”属性，可以创建适当的“path”元素。当将来的“entry”元素到达时具有相同的传入“pathID”属性，并且需要将它们转发到已经发送了相应“pathID”属性的通道时，只需要重写“entry”元素的“pathID”属性，以引用传出通道上的“path”元素。
It should be noted that the majority of the complexity in managing "path" elements arises only in relays. In particular, devices never need to generate "path" elements and collectors need only verify them, log them, and possibly use them in displays and reports. Collectors do not need to generate "path" elements or rewrite "entry" elements. Hence, only in complex configurations (where they are most useful) do complex "path" configurations occur.
应注意的是，管理“路径”元素的大多数复杂性仅出现在继电器中。特别是，设备不需要生成“路径”元素，收集器只需验证、记录它们，并可能在显示和报告中使用它们。收集器不需要生成“path”元素或重写“entry”元素。因此，只有在复杂配置（最有用的配置）中才会出现复杂的“路径”配置。
For example, here is a path element sent from lowry.records.example.com to kurtzman.records.example.com. It indicates that entries from lowry to kurtzman tagged with pathID='173' originated from screen.lowry.records.example.com. It indicates that screen.lowry.records.example.com is believed by lowry.records.example.com to be the originating device, and that entries over this path are delivered without loss and without modification, although messages might be replayed or observed. The link between lowry and kurtzman, however, avoids replay attacks, lost messages, and modifications to messages. While screen.lowry.records.example.com has not authenticated itself to lowry.records.example.com, lowry claims to have authenticated itself to kurtzman.
例如，下面是从lowry.records.example.com发送到kurtzman.records.example.com的path元素。它表示从lowry到kurtzman的带有pathID='173'标记的条目来自screen.lowry.records.example.com。它表明lowry.records.example.com认为screen.lowry.records.example.com是始发设备，通过此路径传递的条目不会丢失，也不会修改，尽管消息可能会被重播或观察。然而，lowry和kurtzman之间的链接避免了重播攻击、丢失消息和修改消息。虽然screen.lowry.records.example.com尚未向lowry.records.example.com进行身份验证，但lowry声称已向kurtzman进行了身份验证。
C: MSG 2 1 . 3121 426
C: Content-type: application/beep+xml
C:
C: <path fromFQDN='lowry.records.example.com'
C: fromIP='10.0.0.50'
C: toFQDN='kurtzman.records.example.com'
C: toIP='10.0.0.51'
C: linkprops='ULRI'
C: pathID='173'>
C: <path fromFQDN='screen.lowry.records.example.com'
C: fromIP='10.0.0.47'
C: toFQDN='lowry.records.example.com'
C: toIP='10.0.0.50'
C: linkprops='DLI'
C: pathID='24'>
C: </path>
C: </path>
C: END
S: ERR 2 1 . 1224 114
S: Content-type: application/beep+xml
S:
S: <error code='530'>linkprops includes 'U'
S: but no 'iam' received</error>
S: END
C: MSG 2 1 . 3121 426
C: Content-type: application/beep+xml
C:
C: <path fromFQDN='lowry.records.example.com'
C: fromIP='10.0.0.50'
C: toFQDN='kurtzman.records.example.com'
C: toIP='10.0.0.51'
C: linkprops='ULRI'
C: pathID='173'>
C: <path fromFQDN='screen.lowry.records.example.com'
C: fromIP='10.0.0.47'
C: toFQDN='lowry.records.example.com'
C: toIP='10.0.0.50'
C: linkprops='DLI'
C: pathID='24'>
C: </path>
C: </path>
C: END
S: ERR 2 1 . 1224 114
S: Content-type: application/beep+xml
S:
S: <error code='530'>linkprops includes 'U'
S: but no 'iam' received</error>
S: END
However, kurtzman.records.example.com rejects the "path" element, since the "linkprops" attribute claims that lowry has authenticated itself, but kurtzman disagrees, not having received an "iam" element.
但是，kurtzman.records.example.com拒绝使用“path”元素，因为“linkprops”属性声明lowry已经对自己进行了身份验证，但是kurtzman不同意，因为他没有收到“iam”元素。
In a second example, this "path" element informs collector.example.com that the records department's firewall will be forwarding "entry" elements with a "pathID" attribute whose value is "17". These "entry" elements will be coming in on the "10.0.0.2" interface of the firewall, to be forwarded out the "134.130.74.56" interface of the firewall. The final hop has all possible guarantees, although the entries transferred within the records department (behind the firewall) may have been observed in passing.
在第二个示例中，此“path”元素通知collector.example.com记录部门的防火墙将转发具有值为“17”的“pathID”属性的“entry”元素。这些“入口”元素将进入防火墙的“10.0.0.2”界面，并转发至防火墙的“134.130.74.56”界面。最后一个跃点具有所有可能的保证，尽管记录部门（防火墙后面）内传输的条目可能在传递过程中被观察到。
C: MSG 2 2 . 3547 813
C: Content-type: application/beep+xml
C:
C: <path fromFQDN='fwall.records.example.com'
C: fromIP='134.130.74.56'
C: toFQDN='collector.example.com'
C: toIP='134.130.74.12'
C: linkprops='OUARIL'
C: pathID='17'>
C: <path fromFQDN='kurtzman.records.example.com'
C: fromIP='10.0.0.50'
C: toFQDN='fwall.records.example.com'
C: toIP='10.0.0.2'
C: linkprops='ULRI'
C: pathID='120'>
C: <path fromFQDN='lowry.records.example.com'
C: fromIP='10.0.0.50'
C: toFQDN='kurtzman.records.example.com'
C: toIP='10.0.0.51'
C: linkprops='ULRI'
C: pathID='173'>
C: <path fromFQDN='screen.lowry.records.example.com'
C: fromIP='10.0.0.47'
C: toFQDN='lowry.records.example.com'
C: toIP='10.0.0.50'
C: linkprops='DLI'
C: pathID='24'>
C: </path></path></path></path>
C: END
S: RPY 2 2 . 1338 45
S: Content-type: application/beep+xml
S:
S: <ok/>
S: END
C: MSG 2 2 . 3547 813
C: Content-type: application/beep+xml
C:
C: <path fromFQDN='fwall.records.example.com'
C: fromIP='134.130.74.56'
C: toFQDN='collector.example.com'
C: toIP='134.130.74.12'
C: linkprops='OUARIL'
C: pathID='17'>
C: <path fromFQDN='kurtzman.records.example.com'
C: fromIP='10.0.0.50'
C: toFQDN='fwall.records.example.com'
C: toIP='10.0.0.2'
C: linkprops='ULRI'
C: pathID='120'>
C: <path fromFQDN='lowry.records.example.com'
C: fromIP='10.0.0.50'
C: toFQDN='kurtzman.records.example.com'
C: toIP='10.0.0.51'
C: linkprops='ULRI'
C: pathID='173'>
C: <path fromFQDN='screen.lowry.records.example.com'
C: fromIP='10.0.0.47'
C: toFQDN='lowry.records.example.com'
C: toIP='10.0.0.50'
C: linkprops='DLI'
C: pathID='24'>
C: </path></path></path></path>
C: END
S: RPY 2 2 . 1338 45
S: Content-type: application/beep+xml
S:
S: <ok/>
S: END
As a final example, an "entry" element from Lowry's screen arrives at the firewall. The "path" attribute is rewritten, and it is forwarded on to the collector.
最后一个例子是，Lowry屏幕上的“entry”元素到达防火墙。重写“path”属性，并将其转发给收集器。
The entry arrives on the 10.0.0.2 interface:
条目到达10.0.0.2界面：
C: MSG 2 3 . 4360 250
C: Content-Type: application/beep+xml
C:
C: <entry facility='24' severity='5'
C: timestamp='Oct 27 13:24:12'
C: deviceFQDN='screen.lowry.records.example.com'
C: deviceIP='10.0.0.47'
C: pathID='173'
C: tag='dvd'>
C: Job paused - Boss watching.
C: </entry>
C: END
S: RPY 2 3 . 1383 45
S: Content-Type: application/beep+xml
S:
S: <ok/>
S: END
C: MSG 2 3 . 4360 250
C: Content-Type: application/beep+xml
C:
C: <entry facility='24' severity='5'
C: timestamp='Oct 27 13:24:12'
C: deviceFQDN='screen.lowry.records.example.com'
C: deviceIP='10.0.0.47'
C: pathID='173'
C: tag='dvd'>
C: Job paused - Boss watching.
C: </entry>
C: END
S: RPY 2 3 . 1383 45
S: Content-Type: application/beep+xml
S:
S: <ok/>
S: END
It is forwarded out the 134.130.74.56 interface:
它被转发到134.130.74.56接口：
C: MSG 7 9 . 9375 276
C: Content-Type: application/beep+xml
C:
C: <entry facility='24' severity='5'
C: timestamp='Oct 27 13:24:12'
C: deviceFQDN='screen.lowry.records.example.com'
C: deviceIP='10.0.0.47'
C: pathID='17'
C: tag='dvd'>
C: Job paused - Boss watching.
C: </entry>
C: END
S: RPY 7 9 . 338 45
S: Content-Type: application/beep+xml
S:
S: <ok/>
S: END
C: MSG 7 9 . 9375 276
C: Content-Type: application/beep+xml
C:
C: <entry facility='24' severity='5'
C: timestamp='Oct 27 13:24:12'
C: deviceFQDN='screen.lowry.records.example.com'
C: deviceIP='10.0.0.47'
C: pathID='17'
C: tag='dvd'>
C: Job paused - Boss watching.
C: </entry>
C: END
S: RPY 7 9 . 338 45
S: Content-Type: application/beep+xml
S:
S: <ok/>
S: END
A discussion of the wisdom of configuring Lowry's machine to forward such messages via Kurtzman's machine is beyond the scope of this document.
关于配置Lowry机器以通过Kurtzman机器转发此类消息的智慧的讨论超出了本文档的范围。
In more advanced configurations, syslog devices, relays, and collectors can be configured to support various delivery priorities. Multiple channels running the same profile can be opened between two peers, with higher priority syslog messages routed to a channel that is given more bandwidth. Such provisioning is a local matter.
在更高级的配置中，可以将系统日志设备、继电器和收集器配置为支持各种传输优先级。可以在两个对等方之间打开运行相同配置文件的多个通道，并将更高优先级的syslog消息路由到给定更多带宽的通道。这样的供应是本地事务。
syslog [1] discusses a number of reasons why privacy and authentication of syslog entry messages may be important in a networked computing environment. The nature of BEEP allows for convenient layering of authentication and privacy over any BEEP channel.
syslog[1]讨论了在网络计算环境中，syslog条目消息的隐私和身份验证可能很重要的一些原因。BEEP的特性允许在任何BEEP通道上方便地分层身份验证和隐私。
Section 6.2 of [1] discusses the dangers of unauthenticated syslog entries. To prevent inauthentic syslog event messages from being accepted, configure syslog peers to require the use of a strong authentication technology for the BEEP session.
[1]的第6.2节讨论了未经验证的系统日志条目的危险。要防止接受不真实的系统日志事件消息，请将系统日志对等方配置为要求对BEEP会话使用强身份验证技术。
If provisioned for message authentication, implementations SHOULD use SASL mechanism DIGEST-MD5 [8] to provision this service.
如果为消息身份验证而设置，则实现应使用SASL机制摘要-MD5[8]来设置此服务。
Section 6.3.4 of [1] discusses the dangers of syslog message replay. To prevent syslog event messages from being replayed, configure syslog peers to require the use of a strong authentication technology for the BEEP session.
[1]的第6.3.4节讨论了系统日志消息重播的危险。要防止重播syslog事件消息，请将syslog对等方配置为要求对BEEP会话使用强身份验证技术。
If provisioned to detect message replay, implementations SHOULD use SASL mechanism DIGEST-MD5 [8] to provision this service.
如果设置为检测消息重播，则实现应使用SASL机制摘要-MD5[8]来设置此服务。
Section 6.5 of [1] discusses the dangers of syslog event messages being maliciously altered by an attacker. To prevent messages from being altered, configure syslog peers to require the use of a strong authentication technology for the BEEP session.
[1]的第6.5节讨论了系统日志事件消息被攻击者恶意更改的危险。要防止消息被更改，请将syslog对等点配置为要求对BEEP会话使用强身份验证技术。
If provisioned to protect message integrity, implementations SHOULD use SASL mechanism DIGEST-MD5 [8] to provision this service.
如果设置为保护消息完整性，则实现应使用SASL mechanism DIGEST-MD5[8]来设置此服务。
Section 6.6 of [1] discusses the dangers (and benefits) of syslog messages being visible at intermediate points along the transmission path between device and collector. To prevent messages from being viewed by an attacker, configure syslog peers to require the use of a transport security profile for the BEEP session. (However, other traffic characteristics, e.g., volume and timing of transmissions, remain observable.)
[1]的第6.6节讨论了syslog消息在设备和收集器之间传输路径的中间点可见的危险（和好处）。为防止攻击者查看消息，请将syslog对等方配置为要求在BEEP会话中使用传输安全配置文件。（但是，其他流量特性，例如传输的音量和定时，仍然可以观察到。）
If provisioned to secure messages against unauthorized observation, implementations SHOULD use the TLS profile [3] to provision this service. The cipher algorithm used SHOULD be TLS_RSA_WITH_3DES_EDE_CBC_SHA.
如果设置为保护消息免受未经授权的观察，则实现应使用TLS配置文件[3]来设置此服务。使用的密码算法应为TLS_RSA_和_3DES_EDE_CBC_SHA。
For the indicated protections, implementations SHOULD be configured to use the indicated mechanisms:
对于指示的保护，应将实施配置为使用指示的机制：
Desired Protection SHOULD tune using
------------------ -----------------
Authentication http://iana.org/beep/SASL/DIGEST-MD5
+ Replay http://iana.org/beep/SASL/DIGEST-MD5
+ Integrity http://iana.org/beep/SASL/DIGEST-MD5
+ Observation http://iana.org/beep/TLS
Desired Protection SHOULD tune using
------------------ -----------------
Authentication http://iana.org/beep/SASL/DIGEST-MD5
+ Replay http://iana.org/beep/SASL/DIGEST-MD5
+ Integrity http://iana.org/beep/SASL/DIGEST-MD5
+ Observation http://iana.org/beep/TLS
BEEP peer identities used for authentication SHOULD correspond to the FQDN of the initiating peer. That is, a relay running on relay.example.com should use a "user ID" of "relay.example.com" within the SASL authentication profiles, as well as in the FQDN of the "iam" element.
用于身份验证的BEEP对等身份应与发起对等身份验证的FQDN相对应。也就是说，在relay.example.com上运行的中继应该在SASL身份验证配置文件中以及在“iam”元素的FQDN中使用“user ID”为“relay.example.com”。
Profile Identification: http://xml.resource.org/profiles/syslog/RAW
Profile Identification: http://xml.resource.org/profiles/syslog/RAW
Messages exchanged during Channel Creation: None
通道创建期间交换的消息：无
Messages starting one-to-one exchanges: Anything
开始一对一交换的消息：任何东西
Messages in positive replies: None
正面回复中的邮件：无
Messages in negative replies: None
否定回复中的消息：无
Messages in one-to-many exchanges: Anything
一对多交换中的消息：任何内容
Message Syntax: See Section 3.3
消息语法：见第3.3节
Message Semantics: See Section 3.4
消息语义：参见第3.4节
Contact Information: See the "Authors' Addresses" section of this memo
联系方式：参见本备忘录的“作者地址”部分
Profile Identification:
http://xml.resource.org/profiles/syslog/COOKED
Profile Identification:
http://xml.resource.org/profiles/syslog/COOKED
Messages exchanged during Channel Creation: iam
频道创建期间交换的消息：iam
Messages starting one-to-one exchanges: iam, entry, path
开始一对一交换的消息：iam、条目、路径
Messages in positive replies: ok
正面回复中的消息：ok
Messages in negative replies: error
否定回复中的消息：错误
Messages in one-to-many exchanges: None
一对多交换中的消息：无
Message Syntax: See Section 4.3
消息语法：见第4.3节
Message Semantics: See Section 4.4
消息语义：参见第4.4节
Contact Information: See the "Authors' Addresses" section of this memo
联系方式：参见本备忘录的“作者地址”部分
The following is the DTD defining the valid elements for the syslog over BEEP mapping.
以下是DTD，它定义了syslog over BEEP映射的有效元素。
<!-- DTD for syslog over BEEP, as of 2000-10-10
<!-- 自2000年10月10日起，通过BEEP发送系统日志的DTD
Refer to this DTD as:
将此DTD称为：
<!ENTITY % SYSLOG PUBLIC "-//Blocks//DTD SYSLOGRELIABLE//EN" "">
%SYSLOG;
-->
<!ENTITY % SYSLOG PUBLIC "-//Blocks//DTD SYSLOGRELIABLE//EN" "">
%SYSLOG;
-->
<!-- Contents
<!-- 目录
Overview
概述
Includes Profile Summaries Entity Definitions
包括概要文件摘要和实体定义
Operations iam entry path -->
操作iam入口路径-->
<!-- Overview
<!-- 概述
Syslog packets delivered via BEEP
通过BEEP发送的系统日志数据包
-->
-->
<!-- Includes -->
<!-- Includes -->
<!ENTITY % BEEP PUBLIC "-//Blocks//DTD BEEP//EN"
"">
%BEEP;
<!ENTITY % BEEP PUBLIC "-//Blocks//DTD BEEP//EN"
"">
%BEEP;
<!-- Profile summaries
<!-- 简介摘要
BEEP profile SYSLOG-RAW
BEEP配置文件SYSLOG-RAW
role MSG ANS ERR
==== === === ===
L text text text
role MSG ANS ERR
==== === === ===
L text text text
BEEP profile SYSLOG-COOKED
BEEP配置文件SYSLOG-HOKED
role MSG RPY ERR
==== === === ===
I or L iam ok error
I or L entry ok error
I or L path ok error
role MSG RPY ERR
==== === === ===
I or L iam ok error
I or L entry ok error
I or L path ok error
-->
-->
<!-- Entity Definitions
<!-- 实体定义
entity syntax/reference example
====== ================ =======
a fully qualified domain name
FQDN See [RFC-1034] www.example.com
entity syntax/reference example
====== ================ =======
a fully qualified domain name
FQDN See [RFC-1034] www.example.com
a dotted-quad IP address IP 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 10.0.0.27 a syslog facility FACILITY See [1] 1*3DIGIT 80
虚线四位IP地址IP 1*3DIGIT“.”1*3DIGIT“.”1*3DIGIT“.”1*3DIGIT 10.0.27系统日志工具请参见[1]1*3DIGIT 80
a syslog severity SEVERITY See [1] DIGIT 4
系统日志严重性请参见[1]第4位
a timestamp See [1] Jan 03 18:43:12 TIMESTAMP
时间戳参见[1]Jan 03 18:43:12时间戳
an identifying integer IDINT 1*DIGIT 1027
标识整数IDINT 1*位1027
-->
-->
<!ENTITY % FQDN "CDATA">
<!ENTITY % IP "CDATA">
<!ENTITY % FACILITY "CDATA">
<!ENTITY % SEVERITY "CDATA">
<!ENTITY % TIMESTAMP "CDATA">
<!ENTITY % IDINT "CDATA">
<!ENTITY % FQDN "CDATA">
<!ENTITY % IP "CDATA">
<!ENTITY % FACILITY "CDATA">
<!ENTITY % SEVERITY "CDATA">
<!ENTITY % TIMESTAMP "CDATA">
<!ENTITY % IDINT "CDATA">
<!-- The iam element declares the role and identity of the peer issuing it. The contents of the element may include human-readable informative text, such as the physical location of the computer issuing the "iam".
<!-- iam元素声明发布它的对等方的角色和标识。元素的内容可以包括人类可读的信息文本，例如发出“iam”的计算机的物理位置。
-->
-->
<!ELEMENT iam (#PCDATA)>
<!ATTLIST iam
fqdn %FQDN; #REQUIRED
ip %IP; #REQUIRED
type (device|relay|collector) #REQUIRED>
<!ELEMENT iam (#PCDATA)>
<!ATTLIST iam
fqdn %FQDN; #REQUIRED
ip %IP; #REQUIRED
type (device|relay|collector) #REQUIRED>
<!-- The entry element conveys a single syslog message. -->
<!-- entry元素传递一条syslog消息。-->
<!ELEMENT entry (#PCDATA)>
<!ATTLIST entry
xml:lang %LANG; "i-default"
facility %FACILITY; #REQUIRED
severity %SEVERITY; #REQUIRED
timestamp %TIMESTAMP; #IMPLIED
tag %ATEXT; #IMPLIED
deviceFQDN %FQDN; #IMPLIED
deviceIP %IP; #IMPLIED
pathID %IDINT; #IMPLIED>
<!ELEMENT entry (#PCDATA)>
<!ATTLIST entry
xml:lang %LANG; "i-default"
facility %FACILITY; #REQUIRED
severity %SEVERITY; #REQUIRED
timestamp %TIMESTAMP; #IMPLIED
tag %ATEXT; #IMPLIED
deviceFQDN %FQDN; #IMPLIED
deviceIP %IP; #IMPLIED
pathID %IDINT; #IMPLIED>
<!-- The path element conveys a list of relays through which entries have passed. -->
<!-- path元素传递条目通过的继电器列表。-->
<!ELEMENT path (path?)>
<!ATTLIST path
pathID %IDINT; #REQUIRED
fromFQDN %FQDN; #IMPLIED
fromIP %IP; #REQUIRED
toFQDN %FQDN; #IMPLIED
toIP %IP; #REQUIRED
linkprops %ATEXT; #REQUIRED>
<!ELEMENT path (path?)>
<!ATTLIST path
pathID %IDINT; #REQUIRED
fromFQDN %FQDN; #IMPLIED
fromIP %IP; #REQUIRED
toFQDN %FQDN; #IMPLIED
toIP %IP; #REQUIRED
linkprops %ATEXT; #REQUIRED>
<!-- End of DTD -->
<!-- End of DTD -->
The following error codes are used in the protocol:
协议中使用了以下错误代码：
code meaning
==== =======
200 success
code meaning
==== =======
200 success
421 service not available
421服务不可用
451 requested action aborted (e.g., local error in processing)
451请求的操作已中止（例如，处理中的本地错误）
454 temporary authentication failure
454临时身份验证失败
500 general syntax error (e.g., poorly-formed XML)
500一般语法错误（例如，格式错误的XML）
501 syntax error in parameters (e.g., non-valid XML)
501参数中的语法错误（例如，无效XML）
504 parameter not implemented
504参数未实现
530 authentication required
530需要身份验证
534 authentication mechanism insufficient (e.g., too weak, sequence exhausted, etc.)
534身份验证机制不足（例如，太弱、序列用尽等）
535 authentication failure
535身份验证失败
537 action not authorized for user
537未授权用户执行的操作
538 authentication mechanism requires encryption
538身份验证机制需要加密
550 requested action not taken (e.g., no requested profiles are acceptable)
550未采取请求的行动（例如，不接受请求的配置文件）
553 parameter invalid
553参数无效
554 transaction failed (e.g., policy violation)
554事务失败（例如，违反策略）
The IANA registers the profiles specified in Section 6, and selects IANA-specific URIs "http://iana.org/beep/SYSLOG/RAW" and "http://iana.org/beep/SYSLOG/COOKED".
IANA注册第6节中指定的配置文件，并选择IANA特定的URI“http://iana.org/beep/SYSLOG/RAW“和”http://iana.org/beep/SYSLOG/COOKED".
9.2 Registration: The System (Well-Known) TCP port number for syslog-conn
9.2 注册：syslog conn的系统（已知）TCP端口号
A single well-known port (601) is allocated to syslog-conn. In-band negotiation determines whether COOKED or RAW syslog-conn is in use.
一个已知端口（601）分配给syslog-conn。带内协商确定使用的是熟的还是生的syslog conn。
Protocol Number: TCP
协议编号：TCP
Message Formats, Types, Opcodes, and Sequences: See Section 3.3 and Section 4.4.
消息格式、类型、操作码和序列：见第3.3节和第4.4节。
Functions: See Section 3.4 and Section 4.4.
功能：见第3.4节和第4.4节。
Use of Broadcast/Multicast: none
使用广播/多播：无
Proposed Name: Reliable syslog service
建议名称：可靠的系统日志服务
Short name: syslog-conn
短名称：syslog conn
Contact Information: See the "Authors' Addresses" section of this memo
联系方式：参见本备忘录的“作者地址”部分
Consult Section 6 of [1] for a discussion of security issues for the syslog service. In addition, since the RAW and COOKED profiles are defined using the BEEP framework, consult [3]'s Section 8 for a discussion of BEEP-specific security issues.
有关syslog服务的安全问题的讨论，请参阅[1]的第6节。此外，由于生的和熟的配置文件是使用BEEP框架定义的，请参阅[3]的第8节，以了解BEEP特定安全问题的讨论。
BEEP is used to provide communication security but not object integrity. In other words, the messages "on the wire" can be protected, but a compromised device may undetectably generate incorrect messages, and relays and collectors can modify, insert, or delete messages undetectably. Other techniques must be used to assure that such compromises are detectable.
BEEP用于提供通信安全性，但不提供对象完整性。换句话说，“在线”消息可以得到保护，但受损设备可能无法检测到生成错误消息，而继电器和采集器可以无法检测到修改、插入或删除消息。必须使用其他技术来确保此类妥协是可检测的。
The authors gratefully acknowledge the contributions of Christopher Calabrese, Keith McCloghrie, Balazs Scheidler, and David Waitzman.
作者衷心感谢克里斯托弗·卡拉布雷斯、基思·麦克洛赫里、巴拉兹·谢伊勒和大卫·韦茨曼的贡献。
[1] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.
[1] Lonvick，C.，“BSD系统日志协议”，RFC 3164，2001年8月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[3] Rose，M.，“块可扩展交换协议核心”，RFC 30802001年3月。
[4] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001.
[4] Rose，M.“将BEEP核心映射到TCP”，RFC 3081，2001年3月。
[5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[5] Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[6] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[7] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[7] Alvestrand，H.，“语言识别标签”，BCP 47，RFC 3066，2001年1月。
[8] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.
[8] Leach，P.和C.Newman，“使用摘要认证作为SASL机制”，RFC 28312000年5月。
Authors' Addresses
作者地址
Darren New 5390 Caminito Exquisito San Diego, CA 92130 US
美国加利福尼亚州圣地亚哥Darren New 5390 Caminito Exquisito 92130
Phone: +1 858 350 9733
EMail: dnew@san.rr.com
Phone: +1 858 350 9733
EMail: dnew@san.rr.com
Marshall T. Rose Dover Beach Consulting, Inc. POB 255268 Sacramento, CA 95865-5268 US
马歇尔T.罗斯多佛海滩咨询公司POB 255268萨克拉门托，加利福尼亚州95865-5268美国
Phone: +1 916 483 8878
EMail: mrose@dbc.mtview.ca.us
Phone: +1 916 483 8878
EMail: mrose@dbc.mtview.ca.us
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。