Internet Engineering Task Force (IETF) R. Gerhards
Request for Comments: 6587 Adiscon GmbH
Category: Historic C. Lonvick
ISSN: 2070-1721 Cisco Systems, Inc.
April 2012
Internet Engineering Task Force (IETF) R. Gerhards
Request for Comments: 6587 Adiscon GmbH
Category: Historic C. Lonvick
ISSN: 2070-1721 Cisco Systems, Inc.
April 2012
Transmission of Syslog Messages over TCP
通过TCP传输系统日志消息
Abstract
摘要
There have been many implementations and deployments of legacy syslog over TCP for many years. That protocol has evolved without being standardized and has proven to be quite interoperable in practice. This memo describes how TCP has been used as a transport for syslog messages.
多年来，通过TCP实现和部署了许多遗留syslog。该协议在未经标准化的情况下不断发展，并已证明在实践中具有相当的互操作性。本备忘录描述了TCP如何被用作系统日志消息的传输。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for the historical record.
本文件不是互联网标准跟踪规范；它是为了历史记录而出版的。
This document defines a Historic Document for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档定义了互联网社区的历史文档。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6587.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6587.
IESG Note
IESG注释
The IESG does not recommend implementing or deploying syslog over plain tcp, which is described in this document, because it lacks the ability to enable strong security [RFC3365].
IESG不建议通过本文档中描述的纯tcp实现或部署syslog，因为它缺乏启用强安全性的能力[RFC3365]。
Implementation of the TLS transport [RFC5425] is recommended so that appropriate security features are available to operators who want to deploy secure syslog. Similarly, those security features can be turned off for those who do not want them.
建议实施TLS传输[RFC5425]，以便希望部署安全系统日志的操作员可以使用适当的安全功能。类似地，对于不需要这些安全功能的人，可以关闭这些安全功能。
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................5
3. Message Transmission ............................................5
3.1. Character Encoding Scheme ..................................5
3.2. Session ....................................................6
3.3. Session Initiation .........................................6
3.4. Message Transfer ...........................................6
3.4.1. Octet Counting ......................................7
3.4.2. Non-Transparent-Framing .............................7
3.4.3. Method Change .......................................8
3.5. Session Closure ............................................8
4. Applicability Statement .........................................8
5. Security Considerations .........................................9
6. Acknowledgments .................................................9
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................10
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................5
3. Message Transmission ............................................5
3.1. Character Encoding Scheme ..................................5
3.2. Session ....................................................6
3.3. Session Initiation .........................................6
3.4. Message Transfer ...........................................6
3.4.1. Octet Counting ......................................7
3.4.2. Non-Transparent-Framing .............................7
3.4.3. Method Change .......................................8
3.5. Session Closure ............................................8
4. Applicability Statement .........................................8
5. Security Considerations .........................................9
6. Acknowledgments .................................................9
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................10
The Standards-Track documents in the syslog series recommend using the syslog protocol [RFC5424] with the TLS transport [RFC5425] for all event messages. The authors of this document wholeheartedly support that position and only offer this document to describe what has been observed with legacy syslog over TCP, which appears to still be widely used.
syslog系列中的标准跟踪文档建议对所有事件消息使用syslog协议[RFC5424]和TLS传输[RFC5425]。本文档的作者全力支持这一立场，并仅提供本文档来描述通过TCP的遗留syslog所观察到的情况，它似乎仍然被广泛使用。
Two primary format options have been observed with legacy syslog being transported over TCP. These have been called "non-transparent-framing" and "octet-counting". The non-transparent-framing mechanism has some inherent problems.
通过TCP传输遗留系统日志时，观察到两种主要格式选项。这些被称为“不透明帧”和“八位组计数”。非透明的框架机制有一些固有的问题。
Diagram 1 shows how all of these syslog transports relate to each other. In this diagram, three originators are seen, labeled A, B, and C, along with one collector. Originator A is using the TCP transport that is described in this document. Originator B is using the UDP transport, which is described in [RFC5426]. Originator C is using the TLS transport, which is described in [RFC5425]. The collector is shown with the capability to accept all three transports.
图1显示了所有这些系统日志传输是如何相互关联的。在此图中，可以看到三个发起人，分别标记为A、B和C，以及一个收集器。发起人A正在使用本文档中描述的TCP传输。发起者B正在使用UDP传输，如[RFC5426]所述。发起者C正在使用TLS传输，如[RFC5425]所述。收集器具有接受所有三种传输的能力。
+---------------------+
| Originator A |
|---------------------|
| syslog application |
| |
|---------------------|
| syslog transport |
| TCP |
|---------------------|
v
|
/ +---------------------+
/ | Originator B |
/ |---------------------|
/ +----------------------+ | syslog application |
/ | Collector | | |
| |----------------------| |---------------------|
| | syslog application | | syslog transport |
| | | | UDP |
| |----------------------| |---------------------|
| | syslog transport | v
| | TCP | TLS | UDP | |
| |----------------------| |
| ^ ^ ^ |
| | | | |
\ / | \ /
--------- | ------------------
|
|
| +---------------------+
| | Originator C |
| |---------------------|
| | syslog application |
| | |
| |---------------------|
| | syslog transport |
| | TLS |
| |---------------------|
| v
\ /
---------------
+---------------------+
| Originator A |
|---------------------|
| syslog application |
| |
|---------------------|
| syslog transport |
| TCP |
|---------------------|
v
|
/ +---------------------+
/ | Originator B |
/ |---------------------|
/ +----------------------+ | syslog application |
/ | Collector | | |
| |----------------------| |---------------------|
| | syslog application | | syslog transport |
| | | | UDP |
| |----------------------| |---------------------|
| | syslog transport | v
| | TCP | TLS | UDP | |
| |----------------------| |
| ^ ^ ^ |
| | | | |
\ / | \ /
--------- | ------------------
|
|
| +---------------------+
| | Originator C |
| |---------------------|
| | syslog application |
| | |
| |---------------------|
| | syslog transport |
| | TLS |
| |---------------------|
| v
\ /
---------------
Diagram 1. Syslog Layers
图1。系统日志层
The terminology defined in Section 3 of [RFC5424] is used throughout this specification. The reader should be familiar with that to follow this discussion.
本规范中使用了[RFC5424]第3节中定义的术语。读者应该熟悉这一点，以便进行讨论。
This document also references devices that use the syslog message format as described in [RFC3164]. Devices that continue to use that message format (regardless of transport) will be described as "legacy syslog devices". Similarly, devices that use the message format as described in [RFC5424] will be described as "standardized syslog devices".
本文档还引用了使用[RFC3164]中所述系统日志消息格式的设备。继续使用该消息格式（无论传输如何）的设备将被描述为“遗留系统日志设备”。类似地，使用[RFC5424]中描述的消息格式的设备将被描述为“标准化系统日志设备”。
Syslog is simplex in nature. It has been observed that implementations of syslog over TCP also do not use any back-channel mechanism to convey information to the transport sender and, consequently, do not use any application-level acknowledgement for syslog signaling from receiver to sender. Message receipt acknowledgement, reliability, and flow control are provided by the capabilities of TCP.
Syslog本质上是单一的。已经观察到，通过TCP的syslog实现也不使用任何反向通道机制来向传输发送方传递信息，因此，也不使用任何应用程序级别的确认来确认从接收方到发送方的syslog信令。TCP的功能提供了消息接收确认、可靠性和流控制。
Syslog over TCP messages contain no indication of the coded character set (e.g., [US-ASCII] or [UNICODE] ) or character encoding scheme (e.g., so-called "7-bit ASCII" or UTF-8 [RFC3629]) in use. In these messages, the predominant approach has been to include characters only from the ASCII repertoire (i.e., %d32 to %d126 inclusive) using the "Network Virtual Terminal" (NVT) encoding [RFC5198].
TCP消息上的Syslog不包含使用中的编码字符集（例如[US-ASCII]或[UNICODE]）或字符编码方案（例如所谓的“7位ASCII”或UTF-8[RFC3629]）的指示。在这些消息中，主要的方法是使用“网络虚拟终端”（NVT）编码[RFC5198]，仅包括ASCII指令集中的字符（即%d32到%d126）。
The message header usually contains characters only from the ASCII repertoire, in the NVT encoding. This has been observed even in cases where a different encoding (e.g., UTF-8) has been used for the MSG part. However, characters outside the ASCII range have been seen inside the header. In that case, some syslog applications have been known to experience problems processing those messages.
在NVT编码中，消息头通常只包含来自ASCII指令集的字符。即使在MSG部分使用了不同编码（例如UTF-8）的情况下也观察到了这一点。但是，在标题中可以看到ASCII范围之外的字符。在这种情况下，已知一些syslog应用程序在处理这些消息时遇到问题。
In some cases, it has been observed that characters outside of the ASCII range are often being transformed by receivers in an effort to "escape control characters". Some receiver implementations simply drop those characters. This is considered to be a poor practice, as it causes problems with coded character sets other than ASCII and character encodings other than NVT, most notably the UTF-8 encoding of Unicode.
在某些情况下，已经观察到，ASCII范围之外的字符经常被接收者转换，以“转义控制字符”。一些接收器实现只是删除这些字符。这被认为是一种糟糕的做法，因为它会导致ASCII以外的编码字符集和NVT以外的字符编码出现问题，尤其是Unicode的UTF-8编码。
It has also been observed that relays will forward messages using the character encoding schemes of messages they receive. In the case where two different senders are using different character encoding schemes, the relay will forward each message to a collector in that character encoding. The collector of these messages will have to be prepared to receive messages from the same relay with different encodings.
还观察到，中继器将使用其接收的消息的字符编码方案转发消息。如果两个不同的发送方使用不同的字符编码方案，中继将以该字符编码将每条消息转发给收集器。这些消息的收集器必须准备好接收来自同一中继的不同编码的消息。
Like most other protocols, the syslog transport sender is the TCP host that initiates the TCP session. After initiation, messages are sent from the transport sender to the transport receiver. No application-level data is transmitted from the transport receiver to the transport sender. The roles of transport sender and receiver seem to be fixed once the session is established.
与大多数其他协议一样，syslog传输发送方是启动TCP会话的TCP主机。启动后，消息从传输发送方发送到传输接收方。没有应用程序级数据从传输接收器传输到传输发送器。一旦建立会话，传输发送方和接收方的角色似乎就固定了。
When it has been observed, if an error occurs that cannot be corrected by TCP, the host detecting the error gracefully closes the TCP session. There have been no application-level messages seen that were sent to notify the other host about the state of the host syslog application.
观察到错误后，如果出现无法通过TCP纠正的错误，则检测到错误的主机将正常关闭TCP会话。尚未看到发送给其他主机的应用程序级消息，以通知主机syslog应用程序的状态。
The TCP host acting as a syslog transport receiver listens to a TCP port. The TCP transport sender initiates a TCP session to the syslog transport receiver as specified in [RFC0793].
充当系统日志传输接收器的TCP主机侦听TCP端口。TCP传输发送方按照[RFC0793]中的规定向系统日志传输接收方发起TCP会话。
This protocol has no standardized port assignment. In practice, network administrators generally choose something that they feel will not conflict with anything else active in their networks. This has most often been either TCP/514, which is actually allocated to another protocol, or some variant of adding 514 to a multiple of 1000. Please see Section 4 for more information.
此协议没有标准化的端口分配。在实践中，网络管理员通常会选择他们认为不会与网络中其他活动内容冲突的内容。这通常是TCP/514，它实际上分配给另一个协议，或者是将514添加到1000的倍数的某个变体。更多信息请参见第4节。
Syslog over TCP has been around for a number of years. Just like legacy syslog over UDP, different implementations exist. The older method of non-transparent-framing has problems. The newer method of octet-counting is reliable and has not been seen to cause problems noted with the non-transparent-framing method.
TCP上的Syslog已经存在很多年了。就像UDP上的遗留系统日志一样，存在不同的实现。较旧的非透明框架方法存在问题。较新的八位组计数方法是可靠的，并且还没有发现会引起不透明成帧法的问题。
In both of these methods, during the message transfer phase, the syslog transport sender sends a stream of messages to the transport receiver. These are sent in sequence and one message is encapsulated
在这两种方法中，在消息传输阶段，syslog传输发送方向传输接收方发送消息流。这些消息按顺序发送，并封装一条消息
inside each TCP frame. Either of the TCP hosts may initiate session closure at any time as specified in Section 3.5 of [RFC0793]. In practice, this is often seen after a prolonged period of inactivity.
在每个TCP帧内。任一TCP主机均可在[RFC0793]第3.5节规定的任何时间启动会话关闭。在实践中，这通常是在长时间不活动之后出现的。
This framing allows for the transmission of all characters inside a syslog message and is similar to the method used in [RFC5425]. A transport receiver uses the defined message length to delimit a syslog message. As noted in [RFC3164], the upper limit for a legacy syslog message length is 1024 octets. That length has been expanded for standardized syslog.
该帧允许在syslog消息中传输所有字符，与[RFC5425]中使用的方法类似。传输接收器使用定义的消息长度来分隔系统日志消息。如[RFC3164]所述，传统系统日志消息长度的上限为1024个八位字节。对于标准化的syslog，该长度已经扩展。
It can be assumed that octet-counting framing is used if a syslog frame starts with a digit.
可以假设，如果系统日志帧以数字开头，则使用八位计数帧。
All syslog messages can be considered to be TCP "data" as per the Transmission Control Protocol [RFC0793]. The syslog message stream has the following ABNF [RFC5234] definition:
根据传输控制协议[RFC0793]，所有系统日志消息都可视为TCP“数据”。系统日志消息流具有以下ABNF[RFC5234]定义：
TCP-DATA = *SYSLOG-FRAME
TCP-DATA = *SYSLOG-FRAME
SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG ; Octet-counting ; method
SYSLOG-FRAME=MSG-LEN SP SYSLOG-MSG；八位组计数；方法
MSG-LEN = NONZERO-DIGIT *DIGIT
MSG-LEN=非零位*位
NONZERO-DIGIT = %d49-57
NONZERO-DIGIT = %d49-57
SYSLOG-MSG is defined in the syslog protocol [RFC5424] and may also be considered to be the payload in [RFC3164]
SYSLOG-MSG在SYSLOG协议[RFC5424]中定义，也可被视为[RFC3164]中的有效负载
MSG-LEN is the octet count of the SYSLOG-MSG in the SYSLOG-FRAME.
MSG-LEN是SYSLOG-FRAME中SYSLOG-MSG的八位字节计数。
The non-transparent-framing method inserts a syslog message into a frame and terminates it with a TRAILER character. The TRAILER has usually been a single character and most often is ASCII LF (%d10). However, other characters have also been seen, with ASCII NUL (%d00) being a prominent example. Some devices have also been seen to emit a two-character TRAILER, which is usually CR and LF.
非透明成帧方法将syslog消息插入到帧中，并使用尾部字符终止它。预告片通常是单个字符，通常是ASCII LF（%d10）。但是，也可以看到其他字符，ASCII NUL（%d00）就是一个突出的例子。一些设备还可以发射两个字符的预告片，通常是CR和LF。
The problem with non-transparent-framing comes from the use of a TRAILER character. In that, the traditional TRAILER character is not escaped within the message, which causes problems for the receiver.
不透明框架的问题来自于使用拖车角色。在这种情况下，传统的尾部字符不会在消息中转义，这会给接收者带来问题。
For example, a message in the style of [RFC3164] containing one or more LF characters may be misinterpreted as multiple messages by the receiving syslog application.
例如，包含一个或多个LF字符的[RFC3164]样式的消息可能被接收系统日志应用程序误解为多条消息。
The ABNF for this is shown here:
此处显示了这方面的ABNF：
TCP-DATA = *SYSLOG-FRAME
TCP-DATA = *SYSLOG-FRAME
SYSLOG-FRAME = SYSLOG-MSG TRAILER ; non-transparent-framing ; method
SYSLOG-FRAME=SYSLOG-MSG拖车；不透明框架；方法
TRAILER = LF / APP-DEFINED
TRAILER = LF / APP-DEFINED
APP-DEFINED = 1*2OCTET
APP-DEFINED = 1*2OCTET
SYSLOG-MSG is defined in the syslog protocol [RFC5424] and may also be considered to be the payload in [RFC3164]
SYSLOG-MSG在SYSLOG协议[RFC5424]中定义，也可被视为[RFC3164]中的有效负载
A transport receiver can assume that non-transparent-framing is used if a syslog frame starts with the ASCII character "<" (%d60).
如果系统日志帧以ASCII字符“<”（%d60）开头，则传输接收器可以假定使用非透明帧。
In legacy implementations, it has been observed that the framing may change on a frame-by-frame basis. This is probably not a good idea, but it's been seen.
在传统实现中，已经观察到帧可以逐帧地改变。这可能不是一个好主意，但已经见识过了。
The syslog session is closed when one of the TCP hosts decides to do so. It then initiates a local TCP session closure. Following TCP [RFC0793], it doesn't need to notify the remote TCP host of its intention to close the session, nor does it accept any messages that are still in transit.
当其中一个TCP主机决定关闭系统日志会话时，系统日志会话将关闭。然后，它启动本地TCP会话关闭。在TCP[RFC0793]之后，它不需要通知远程TCP主机其关闭会话的意图，也不接受任何仍在传输中的消息。
Again it must be emphasized that the Standards-Track documents in the syslog series recommend using the TLS transport [RFC5425] to transport syslog messages. This document does not recommend that new implementations or deployments use syslog over TCP except for the explicit purpose of interoperating with existing deployments.
必须再次强调的是，syslog系列中的标准跟踪文档建议使用TLS传输[RFC5425]来传输syslog消息。本文档不建议新的实现或部署通过TCP使用syslog，除非出于与现有部署互操作的明确目的。
One of the major problems with interoperability with this protocol is that there is no consistent TCP port assigned. Most of the successful implementations have made the selection of a port a user-configurable option. The most frequently observed port for this has been TCP/514, which is actually assigned to the Shell protocol.
与此协议互操作性的主要问题之一是没有分配一致的TCP端口。大多数成功的实现都将端口选择作为用户可配置的选项。最常见的端口是TCP/514，它实际上被分配给Shell协议。
Operators must carefully select which port to use in their deployment and be prepared to encounter different default port assignments in implementations.
操作员必须仔细选择在其部署中使用哪个端口，并准备好在实现中遇到不同的默认端口分配。
There are several advantages to using TCP: flow control, error recovery, and reliability, to name a few. These reasons, and the ease of programming, have led people to use this transmission protocol to transmit syslog.
使用TCP有几个优点：流控制、错误恢复和可靠性等等。这些原因，以及编程的简单性，使得人们使用这种传输协议来传输系统日志。
One potential disadvantage is the buffering mechanism used by TCP. Ordinarily, TCP decides when enough data has been received from the application to form a segment for transmission. This may be adjusted through timers; but still, some application data may wait in a buffer for a relatively long time. Syslog data is not normally time-sensitive, but if this delay is a concern, the syslog transport sender may utilize the PUSH Flag as described in [RFC0793] to have the sending TCP immediately send all buffered data.
一个潜在的缺点是TCP使用的缓冲机制。通常，TCP决定何时从应用程序接收到足够的数据以形成用于传输的段。这可以通过定时器进行调整；但是，一些应用程序数据可能会在缓冲区中等待相对较长的时间。系统日志数据通常不具有时间敏感性，但如果存在此延迟问题，则系统日志传输发送方可利用[RFC0793]中所述的推送标志，让发送TCP立即发送所有缓冲数据。
This protocol makes no meaningful provisions for security. It lacks authentication, integrity checking, and privacy. It makes no provision for flow control or end-to-end confirmation of receipt, relying instead on the underlying TCP implementations to approximate these functions. It should not be used if deployment of [RFC5425] on the systems in question is feasible.
该议定书没有对安全作出任何有意义的规定。它缺乏身份验证、完整性检查和隐私。它不提供流控制或端到端的接收确认，而是依赖底层TCP实现来近似实现这些功能。如果在相关系统上部署[RFC5425]是可行的，则不应使用它。
The authors wish to thank David Harrington, Tom Petch, Richard Graveman, and all other people who commented on various versions of this proposal. We would also like to thank Peter Saint-Andre for clarifying character encodings.
作者希望感谢David Harrington、Tom Petch、Richard Graveman和所有其他对本提案的不同版本发表评论的人。我们还要感谢彼得·圣安德烈澄清了角色编码。
The authors would also like to thank Randy Presuhn for being our reviewer and document shepherd, and a special thanks to Dan Romascanu for his support and guidance.
作者还想感谢Randy Presohn作为我们的审稿人和文档管理员，并特别感谢Dan Romascanu对我们的支持和指导。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC3365] Schiller, J., "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", BCP 61, RFC 3365, August 2002.
[RFC3365]Schiller，J.“互联网工程任务组标准协议的强大安全要求”，BCP 61，RFC 3365，2002年8月。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[RFC5198]Klensin，J.和M.Padlipsky，“网络交换的Unicode格式”，RFC 51982008年3月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424]Gerhards，R.，“系统日志协议”，RFC 54242009年3月。
[RFC5425] Miao, F., Ma, Y., and J. Salowey, "Transport Layer Security (TLS) Transport Mapping for Syslog", RFC 5425, March 2009.
[RFC5425]Miao，F.，Ma，Y.，和J.Salowey，“系统日志的传输层安全性（TLS）传输映射”，RFC 54252009年3月。
[US-ASCII] ANSI, "Coded Character Set -- 7-bit American Standard Code for Information Interchange, ANSI X3.4-1986", 1986.
[US-ASCII]ANSI，“编码字符集——信息交换用7位美国标准代码，ANSI X3.4-1986”，1986年。
[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.
[RFC3164]Lonvick，C.，“BSD系统日志协议”，RFC31642001年8月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP", RFC 5426, March 2009.
[RFC5426]Okmianski，A.，“通过UDP传输系统日志消息”，RFC 5426，2009年3月。
[UNICODE] The Unicode Consortium. The Unicode Standard, Version 6.0.0, (Mountain View, CA: The Unicode Consortium, 2011. ISBN 978-1-936213-01-6), <http://www.unicode.org/versions/Unicode6.0.0/>.
[UNICODE]UNICODE联盟。Unicode标准，版本6.0.0，（加利福尼亚州山景城：Unicode联盟，2011年，ISBN 978-1-936213-01-6）<http://www.unicode.org/versions/Unicode6.0.0/>.
Authors' Addresses
作者地址
Rainer Gerhards Adiscon GmbH Mozartstrasse 21 Grossrinderfeld, BW 97950 Germany
Rainer Gerhards Adiscon GmbH Mozartstrasse 21 Grossrinderfeld，BW 97950德国
EMail: rgerhards@adiscon.com
EMail: rgerhards@adiscon.com
Chris Lonvick Cisco Systems, Inc. 12515 Research Blvd. Austin, TX 78759 USA
克里斯·朗维克思科系统公司，研究大道12515号。美国德克萨斯州奥斯汀78759
EMail: clonvick@cisco.com
EMail: clonvick@cisco.com