[要約] RFC 6587は、TCPを介してSyslogメッセージを転送するためのプロトコル仕様です。このRFCの目的は、信頼性とセキュリティを向上させ、Syslogメッセージの効率的な転送を実現することです。
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を介したSyslogメッセージの送信
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がsyslogメッセージのトランスポートとしてどのように使用されたかについて説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for the historical record.
このドキュメントはInternet Standards Trackの仕様ではありません。歴史的な記録として掲載されています。
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（Internet Engineering Task Force）の製品です。これは、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 Note
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は、強力なセキュリティ[RFC3365]を有効にする機能がないため、このドキュメントで説明されているプレーンTCP上にsyslogを実装または展開することはお勧めしません。
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]の実装をお勧めします。これにより、安全なsyslogを配備したいオペレーターが適切なセキュリティ機能を利用できるようになります。同様に、それらのセキュリティ機能を望まない人のためにオフにすることができます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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シリーズのStandards-Trackドキュメントでは、すべてのイベントメッセージにTLSトランスポート[RFC5425]でsyslogプロトコル[RFC5424]を使用することを推奨しています。このドキュメントの作成者は、その立場を全面的にサポートし、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を介して転送されるレガシーSyslogで2つの主要なフォーマットオプションが確認されています。これらは「非透過フレーム」および「オクテットカウント」と呼ばれています。非透過フレーミングメカニズムには、いくつかの固有の問題があります。
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は、これらすべてのsyslogトランスポートが相互にどのように関連しているかを示しています。この図では、A、B、Cというラベルの付いた3つのオリジネーターと1つのコレクターが表示されています。発信者Aは、このドキュメントで説明されているTCPトランスポートを使用しています。発信者Bは、[RFC5426]で説明されているUDPトランスポートを使用しています。発信者Cは、[RFC5425]で説明されているTLSトランスポートを使用しています。コレクターには、3つのトランスポートすべてを受け入れる機能が示されています。
+---------------------+
| 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. Syslogレイヤー
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]で説明されているように、syslogメッセージ形式を使用するデバイスも参照しています。 （トランスポートに関係なく）そのメッセージ形式を引き続き使用するデバイスは、「レガシーSyslogデバイス」と呼ばれます。同様に、[RFC5424]で説明されているメッセージ形式を使用するデバイスは、「標準化されたsyslogデバイス」として説明されます。
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は本質的にシンプレックスです。 syslog over TCPの実装では、トランスポート送信者に情報を伝達するためにバックチャネルメカニズムも使用せず、その結果、受信者から送信者への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].
Syslog over TCPメッセージには、コード化された文字セット（[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.
リレーは、受信するメッセージの文字エンコード方式を使用してメッセージを転送することも確認されています。 2つの異なる送信者が異なる文字エンコード方式を使用している場合、リレーは各メッセージをその文字エンコードでコレクターに転送します。これらのメッセージのコレクターは、同じリレーから異なるエンコーディングでメッセージを受信できるように準備する必要があります。
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].
syslogトランスポートレシーバーとして機能するTCPホストは、TCPポートをリッスンします。 [RFC0793]で指定されているように、TCPトランスポート送信側は、syslogトランスポート受信側への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.
Syslog over TCPは何年も前から存在しています。 UDP上のレガシーSyslogのように、さまざまな実装が存在します。以前の非透過フレーミングの方法には問題があります。新しいオクテットカウント方式は信頼性が高く、非透過フレーミング方式で指摘された問題を引き起こすとは考えられていません。
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 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.
これらの方法の両方で、メッセージ転送フェーズ中に、syslogトランスポート送信者はメッセージのストリームをトランスポート受信者に送信します。これらは順番に送信され、1つのメッセージが各TCPフレーム内にカプセル化されます。 [RFC0793]のセクション3.5で指定されているように、どちらのTCPホストもいつでもセッションクローズを開始できます。実際には、これは長期間の非アクティブ状態の後によく見られます。
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]で使用される方法に似ています。トランスポートレシーバーは、定義されたメッセージ長を使用して、syslogメッセージを区切ります。 [RFC3164]で述べられているように、レガシーsyslogメッセージの長さの上限は1024オクテットです。その長さは、標準化されたsyslogのために拡張されました。
It can be assumed that octet-counting framing is used if a syslog frame starts with a digit.
Syslogフレームが数字で始まる場合、オクテットカウントフレーミングが使用されていると想定できます。
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:
すべてのsyslogメッセージは、伝送制御プロトコル[RFC0793]に従って、TCPの「データ」と見なすことができます。 syslogメッセージストリームには、次のABNF [RFC5234]定義があります。
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 * DIGIT
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メッセージをフレームに挿入し、TRAILER文字で終了します。トレーラーは通常単一の文字であり、ほとんどの場合ASCII LF（％d10）です。ただし、他の文字も見られ、ASCII NUL（％d00）が顕著な例です。一部のデバイスは、2文字のトレーラー（通常は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.
非透過フレーミングの問題は、トレーラー文字の使用に起因します。その場合、従来のTRAILER文字はメッセージ内でエスケープされないため、受信者に問題が発生します。
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.
たとえば、1つまたは複数のLF文字を含む[RFC3164]のスタイルのメッセージは、受信側のsyslogアプリケーションによって複数のメッセージとして誤って解釈される場合があります。
The ABNF for this is shown here:
このためのABNFを次に示します。
TCP-DATA = *SYSLOG-FRAME
SYSLOG-FRAME = SYSLOG-MSG TRAILER ; non-transparent-framing ; method
SYSLOG-FRAME = SYSLOG-MSG TRAILER;非透過フレーミング;方法
TRAILER = LF / APP-DEFINED
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).
トランスポートレシーバーは、syslogフレームが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ホストの1つがそうすることを決定すると、syslogセッションは閉じられます。次に、ローカル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シリーズのStandards-Trackドキュメントでは、syslogメッセージの転送にTLSトランスポート[RFC5425]を使用することを推奨していることを強調する必要があります。このドキュメントでは、既存のデプロイメントと相互運用するという明確な目的を除いて、新しい実装またはデプロイメントでTCP over 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.
このプロトコルとの相互運用性に関する主な問題の1つは、割り当てられた一貫したTCPポートがないことです。成功した実装のほとんどは、ポートの選択をユーザー構成可能なオプションにしています。このために最も頻繁に観察されるポートはTCP / 514で、実際にはシェルプロトコルに割り当てられています。
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を使用する利点はいくつかあります。フロー制御、エラー回復、信頼性などです。これらの理由とプログラミングの容易さにより、人々はこの送信プロトコルを使用してsyslogを送信するようになりました。
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.
1つの潜在的な欠点は、TCPで使用されるバッファリングメカニズムです。通常、TCPは、送信用のセグメントを形成するのに十分なデータがアプリケーションから受信されたときに決定します。これはタイマーで調整できます。それでも、一部のアプリケーションデータはバッファで比較的長い間待機する場合があります。 Syslogデータは通常時間に依存しませんが、この遅延が懸念される場合、Syslogトランスポート送信側は[RFC0793]で説明されているようにPUSHフラグを利用して、送信された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、およびこの提案のさまざまなバージョンにコメントした他のすべての人々に感謝します。文字エンコーディングを明確にしてくれたPeter Saint-Andreにも感謝します。
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 Presuhnに感謝し、Dan Romascanuのサポートと指導に特に感謝します。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「Transmission Control Protocol」、STD 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。、「Strong Security Requirements for Internet Engineering Task Force Standard Protocols」、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、「Network InterchangeのUnicode形式」、RFC 5198、2008年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。、「Syslogプロトコル」、RFC 5424、2009年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、「Syslogのトランスポート層セキュリティ（TLS）トランスポートマッピング」、RFC 5425、2009年3月。
[US-ASCII] ANSI, "Coded Character Set -- 7-bit American Standard Code for Information Interchange, ANSI X3.4-1986", 1986.
[US-ASCII] ANSI、「Coded Character Set-7-bit American Standard Code for Information Interchange、ANSI X3.4-1986」、1986。
[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.
[RFC3164] Lonvick、C。、「The BSD Syslog Protocol」、RFC 3164、2001年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を介したSyslogメッセージの送信」、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 Standard、バージョン6.0.0（Mountain View、CA：Unicode Consortium、2011。ISBN978-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 Germany
EMail: rgerhards@adiscon.com
Chris Lonvick Cisco Systems, Inc. 12515 Research Blvd. Austin, TX 78759 USA
Chris Lonvick Cisco Systems、Inc. 12515 Research Blvd.オースティン、テキサス州78759米国
EMail: clonvick@cisco.com