메모 : 구글 번역 및 파파고 번역으로 진행하였습니다.
```
Network Working Group R. Gerhards
Request for Comments: 5424 Adiscon GmbH
Obsoletes: 3164 March 2009
Category: Standards Track
```
# The Syslog Protocol
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.
이 문서는 인터넷 커뮤니티를 위한 인터넷 표준 추적 프로토콜을 지정하고, 개선을 위한 논의와 제안을 요청합니다. 이 프로토콜의 표준화 상태(state) 와 상태(status)에 대해서는 "인터넷 공식 프로토콜 표준" (STD 1)의 현재 버전을 참조하십시오. 이 메모의 배포는 무제한입니다.
Copyright Notice
저작권 고지
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2009 IETF Trust 및 문서 작성자로 식별된 사람. 모든 권리 보유.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
이 문서는 BCP 78 및 이 문서가 발행된 날짜에 효력이 있는 IETF 문서와 관련된 IETF Trust의 법적 조항(http://trustee.ietf.org/license-info)의 적용을 받습니다. 이 문서와 관련된 귀하의 권리와 제한 사항을 설명하므로 이러한 문서를 주의 깊게 검토하십시오.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
이 문서에는 2008년 11월 10일 이전에 발행되거나 공개적으로 제공된 IETF 문서 또는 IETF 기여 자료의 자료가 포함되어 있을 수 있습니다. 이 자료의 일부에 대한 저작권을 관리하는 사람은 IETF Trust에 IETF 표준 프로세스 외부에서 이러한 자료를 수정할 수 있는 권한을 부여하지 않았을 수 있습니다. 해당 자료의 저작권을 관리하는 사람으로부터 적절한 라이선스를 받지 않고는 이 문서를 IETF 표준 절차 외부에서 수정할 수 없으며, RFC로 출판하기 위해 형식을 지정하거나 영어가 아닌 다른 언어로 번역하는 경우를 제외하고는 IETF 표준 절차 외부에서 이 문서의 파생 작품을 만들 수 없습니다.
Abstract
초록(抄錄)
This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way.
이 문서는 이벤트 알림 메시지를 전달하는 데 사용되는 syslog 프로토콜을 설명합니다. 이 프로토콜은 계층화된 아키텍처를 활용하여 syslog 메시지를 전송하기 위해 원하는 수의 전송 프로토콜을 사용할 수 있습니다. 또한 공급업체별 확장을 구조화된 방식으로 제공할 수 있는 메시지 형식을 제공합니다.
This document has been written with the original design goals for traditional syslog in mind. The need for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a Standards-Track and transport-independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport.
이 문서는 기존 syslog의 원래 설계 목표를 염두에 두고 작성되었습니다. 안정적이고 안전한 syslog 확장에 대한 표준화 노력이 Standards-Track 및 전송 독립 RFC의 부족으로 어려움을 겪기 때문에 새로운 계층화된 사양이 필요하게 되었습니다. 이 문서가 없으면 다른 모든 표준이 자체 syslog 패킷 형식과 전송 메커니즘을 정의해야 하며, 시간이 지남에 따라 미묘한 호환성 문제가 발생합니다. 이 문서는 syslog 확장이 구축할 수 있는 기반을 제공하려고 합니다. 이 계층화된 아키텍처 방식은 각 전송에 대해 한 번이 아니라 각 syslog 기능에 대해 한 번 코드를 작성할 수 있는 견고한 기반을 제공합니다.
This document obsoletes RFC 3164.
이 문서는 RFC 3164를 폐기합니다.
# 1. Introduction
This document describes a layered architecture for syslog. The goal of this architecture is to separate message content from message transport while enabling easy extensibility for each layer.
이 문서에서는 syslog의 계층적 아키텍처를 설명합니다. 이 아키텍처의 목표는 각 계층에 대한 쉬운 확장성을 가능하게 하면서 메시지 콘텐츠를 메시지 전송에서 분리하는 것입니다.
This document describes the standard format for syslog messages and outlines the concept of transport mappings. It also describes structured data elements, which can be used to transmit easily parseable, structured information, and allows for vendor extensions.
이 문서에서는 syslog 메시지의 표준 형식을 설명하고 전송 매핑의 개념을 설명합니다. 또한 쉽게 구문 분석할 수 있는 구조화된 정보를 전송하는 데 사용할 수 있는 구조화된 데이터 요소를 설명하고 공급업체 확장을 허용합니다.
This document does not describe any storage format for syslog messages. It is beyond of the scope of the syslog protocol and is unnecessary for system interoperability.
이 문서에서는 syslog 메시지의 저장 형식을 설명하지 않습니다. syslog 프로토콜의 범위를 벗어나며 시스템 상호 운용성에 필요하지 않습니다.
This document has been written with the original design goals for traditional syslog in mind. The need for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a Standards-Track and transport-independent RFC. Without this document, each other standard would need to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature instead of once for each transport.
이 문서는 기존 syslog의 원래 설계 목표를 염두에 두고 작성되었습니다. 안정적이고 안전한 syslog 확장에 대한 표준화 노력은 Standards-Track 및 전송 독립 RFC가 부족하여 어려움을 겪기 때문에 새로운 계층적 사양이 필요하게 되었습니다. 이 문서가 없다면 다른 각 표준은 자체 syslog 패킷 형식과 전송 메커니즘을 정의해야 하며, 시간이 지남에 따라 미묘한 호환성 문제가 발생합니다. 이 문서에서는 syslog 확장을 구축할 수 있는 기반을 제공하려고 합니다. 이 계층적 아키텍처 접근 방식은 또한 각 전송에 대해 한 번이 아니라 각 syslog 기능에 대해 한 번 코드를 작성할 수 있는 견고한 기반을 제공합니다.
This document obsoletes RFC 3164, which is an Informational document describing some implementations found in the field.
이 문서는 현장에서 발견된 일부 구현을 설명하는 정보 문서인 RFC 3164를 폐기합니다.
# 2. Conventions Used in This Document
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 `[RFC2119]`.
이 문서의 핵심 단어 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL"은 RFC 2119 `[RFC2119]`에 설명된 대로 해석해야 합니다.
# 3. Definitions
Syslog utilizes three layers:
Syslog는 세 가지 계층을 활용합니다.
- "syslog content" is the management information contained in a syslog message.
- "syslog 콘텐츠"는 syslog 메시지에 포함된 관리 정보입니다.
- The "syslog application" layer handles generation, interpretation, routing, and storage of syslog messages.
- "syslog 애플리케이션" 계층은 syslog 메시지의 생성, 해석, 라우팅 및 저장을 처리합니다.
- The "syslog transport" layer puts messages on the wire and takes them off the wire.
- "syslog 전송" 계층은 메시지를 와이어에 넣고 와이어에서 제거합니다.
Certain types of functions are performed at each conceptual layer:
각 개념적 계층에서 특정 유형의 기능이 수행됩니다.
- An "originator" generates syslog content to be carried in a message.
- "발신자"는 메시지에 포함될 syslog 콘텐츠를 생성합니다.
- A "collector" gathers syslog content for further analysis.
- "수집자"는 추가 분석을 위해 syslog 콘텐츠를 수집합니다.
- A "relay" forwards messages, accepting messages from originators or other relays and sending them to collectors or other relays.
- "릴레이"는 메시지를 전달하고, 발신자 또는 다른 릴레이에서 메시지를 수신하여 수집자 또는 다른 릴레이로 보냅니다.
- A "transport sender" passes syslog messages to a specific transport protocol.
- "전송 발신자"는 syslog 메시지를 특정 전송 프로토콜로 전달합니다.
- A "transport receiver" takes syslog messages from a specific transport protocol.
- "전송 수신자"는 특정 전송 프로토콜에서 syslog 메시지를 가져옵니다.
Diagram 1 shows the different entities separated by layer.
다이어그램 1은 계층별로 구분된 다양한 엔터티를 보여줍니다.
```
+---------------------+ +---------------------+
| content | | content |
|---------------------| |---------------------|
| syslog application | | syslog application | (originator,
| | | | collector, relay)
|---------------------| |---------------------|
| syslog transport | | syslog transport | (transport sender,
| | | | (transport receiver)
+---------------------+ +---------------------+
^ ^
| |
--------------------------
```
Diagram 1. Syslog Layers
# 4. Basic Principles
The following principles apply to syslog communication:
다음 원칙은 syslog 통신에 적용됩니다.
- The syslog protocol does not provide acknowledgment of message delivery. Though some transports may provide status information, conceptually, syslog is a pure simplex communications protocol.
- syslog 프로토콜은 메시지 전달에 대한 확인을 제공하지 않습니다. 일부 전송은 상태 정보를 제공할 수 있지만 개념적으로 syslog는 순수한 심플렉스 통신 프로토콜입니다.
- Originators and relays may be configured to send the same message to multiple collectors and relays.
- 발신자와 릴레이는 여러 수집자와 릴레이에 동일한 메시지를 보내도록 구성될 수 있습니다.
- Originator, relay, and collector functionality may reside on the same system.
- 발신자, 릴레이 및 수집자 기능은 동일한 시스템에 있을 수 있습니다.
## 4.1. Example Deployment Scenarios
Sample deployment scenarios are shown in Diagram 2. Other arrangements of these examples are also acceptable. As noted, in the following diagram, relays may send all or some of the messages that they receive and also send messages that they generate internally. The boxes represent syslog-enabled applications.
배포 시나리오 예는 다이어그램 2에 나와 있습니다. 이러한 예의 다른 배열도 허용됩니다. 다음 다이어그램에서 언급했듯이 릴레이는 수신한 메시지의 일부 또는 전부를 보내고 내부적으로 생성한 메시지도 보낼 수 있습니다. 상자는 syslog가 활성화된 애플리케이션을 나타냅니다.
```
+----------+ +---------+
|Originator|---->----|Collector|
+----------+ +---------+
+----------+ +-----+ +---------+
|Originator|---->----|Relay|---->----|Collector|
+----------+ +-----+ +---------+
+----------+ +-----+ +-----+ +---------+
|Originator|-->--|Relay|-->--..-->--|Relay|-->--|Collector|
+----------+ +-----+ +-----+ +---------+
+----------+ +-----+ +---------+
|Originator|---->----|Relay|---->----|Collector|
| |-+ +-----+ +---------+
+----------+ \
\ +-----+ +---------+
+->--|Relay|---->----|Collector|
+-----+ +---------+
+----------+ +---------+
|Originator|---->----|Collector|
| |-+ +---------+
+----------+ \
\ +-----+ +---------+
+->--|Relay|---->----|Collector|
+-----+ +---------+
+----------+ +-----+ +---------+
|Originator|---->----|Relay|---->-------|Collector|
| |-+ +-----+ +---| |
+----------+ \ / +---------+
\ +-----+ /
+->--|Relay|-->--/
+-----+
+----------+ +-----+ +---------+
|Originator|---->----|Relay|---->--------------|Collector|
| |-+ +-----+ +--| |
+----------+ \ / +---------+
\ +------------+ /
\ |+----------+| /
+->-||Relay ||->---/
|+----------|| /
||Originator||->-/
|+----------+|
+------------+
```
Diagram 2. Some Possible Syslog Deployment Scenarios
# 5. Transport Layer Protocol
This document does not specify any transport layer protocol. Instead, it describes the format of a syslog message in a transport layer independent way. Syslog transports are defined in other documents. One such transport is defined in `[RFC5426]` and is consistent with the traditional UDP transport. This transport is needed to maintain interoperability as the UDP transport has historically been used for the transmission of syslog messages.
이 문서는 전송 계층 프로토콜을 지정하지 않습니다. 대신 전송 계층에 독립적인 방식으로 syslog 메시지의 형식을 설명합니다. syslog 전송은 다른 문서에 정의되어 있습니다. 이러한 전송 중 하나는 `[RFC5426]`에 정의되어 있으며 기존 UDP 전송과 일치합니다. 이 전송은 UDP 전송이 역사적으로 syslog 메시지 전송에 사용되었기 때문에 상호 운용성을 유지하는 데 필요합니다.
Any syslog transport protocol MUST NOT deliberately alter the syslog essage. If the transport protocol needs to perform temporary transformations at the transport sender, these transformations MUST be reversed by the transport protocol at the transport receiver so that the relay or collector will see an exact copy of the message generated by the originator or relay. Otherwise, end-to-end cryptographic verifiers (such as signatures) will be broken. Of course, message alteration might occur due to transmission errors or other problems. Guarding against such alterations is not within the scope of this document.
모든 syslog 전송 프로토콜은 syslog 메시지를 의도적으로 변경해서는 안 됩니다. 전송 프로토콜이 전송 발신자에서 임시 변환을 수행해야 하는 경우 이러한 변환은 전송 수신자에서 전송 프로토콜에 의해 역전되어야 릴레이 또는 수집자가 발신자 또는 릴레이에서 생성한 메시지의 정확한 사본을 볼 수 있습니다. 그렇지 않으면 종단 간 암호화 검증자(예: 서명)가 손상됩니다. 물론 전송 오류 또는 기타 문제로 인해 메시지가 변경될 수 있습니다. 이러한 변경을 방지하는 것은 이 문서의 범위에 포함되지 않습니다.
## 5.1. Minimum Required Transport Mapping
All implementations of this specification MUST support a TLS-based ransport as described in `[RFC5425]`.
이 사양의 모든 구현은 `[RFC5425]`에 설명된 대로 TLS 기반 전송을 지원해야 합니다.
All implementations of this specification SHOULD also support a DP-based transport as described in `[RFC5426]`.
이 사양의 모든 구현은 `[RFC5426]`에 설명된 대로 DP 기반 전송도 지원해야 합니다.
이 사양의 배포는 TLS 기반 전송을 사용하는 것이 좋습니다.
It is RECOMMENDED that deployments of this specification use the TLS- ased transport.
# 6. Syslog Message Format
The syslog message has the following ABNF `[RFC5234]` definition:
syslog 메시지 ABNF `[RFC5234]` 정의를 따릅니다.
```
SYSLOG-MSG = HEADER SP STRUCTURED-DATA [SP MSG]
HEADER = PRI VERSION SP TIMESTAMP SP HOSTNAME
SP APP-NAME SP PROCID SP MSGID
PRI = "<" PRIVAL ">"
PRIVAL = 1*3DIGIT ; range 0 .. 191
VERSION = NONZERO-DIGIT 0*2DIGIT
HOSTNAME = NILVALUE / 1*255PRINTUSASCII
APP-NAME = NILVALUE / 1*48PRINTUSASCII
PROCID = NILVALUE / 1*128PRINTUSASCII
MSGID = NILVALUE / 1*32PRINTUSASCII
TIMESTAMP = NILVALUE / FULL-DATE "T" FULL-TIME
FULL-DATE = DATE-FULLYEAR "-" DATE-MONTH "-" DATE-MDAY
DATE-FULLYEAR = 4DIGIT
DATE-MONTH = 2DIGIT ; 01-12
DATE-MDAY = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
; month/year
FULL-TIME = PARTIAL-TIME TIME-OFFSET
PARTIAL-TIME = TIME-HOUR ":" TIME-MINUTE ":" TIME-SECOND
[TIME-SECFRAC]
TIME-HOUR = 2DIGIT ; 00-23
TIME-MINUTE = 2DIGIT ; 00-59
TIME-SECOND = 2DIGIT ; 00-59
TIME-SECFRAC = "." 1*6DIGIT
TIME-OFFSET = "Z" / TIME-NUMOFFSET
TIME-NUMOFFSET = ("+" / "-") TIME-HOUR ":" TIME-MINUTE
STRUCTURED-DATA = NILVALUE / 1*SD-ELEMENT
SD-ELEMENT = "[" SD-ID *(SP SD-PARAM) "]"
SD-PARAM = PARAM-NAME "=" %d34 PARAM-VALUE %d34
SD-ID = SD-NAME
PARAM-NAME = SD-NAME
PARAM-VALUE = UTF-8-STRING ; characters '"', '\' and
; ']' MUST be escaped.
SD-NAME = 1*32PRINTUSASCII
; except '=', SP, ']', %d34 (")
MSG = MSG-ANY / MSG-UTF8
MSG-ANY = *OCTET ; not starting with BOM
MSG-UTF8 = BOM UTF-8-STRING
BOM = %xEF.BB.BF
UTF-8-STRING = *OCTET ; UTF-8 string as specified
; in RFC 3629
OCTET = %d00-255
SP = %d32
PRINTUSASCII = %d33-126
NONZERO-DIGIT = %d49-57
DIGIT = %d48 / NONZERO-DIGIT
NILVALUE = "-"
```
## 6.1. Message Length
Syslog message size limits are dictated by the syslog transport mapping in use. There is no upper limit per se. Each transport mapping defines the minimum maximum required message length support, and the minimum maximum MUST be at least 480 octets in length.
syslog 메시지 크기 제한은 사용 중인 syslog 전송 매핑에 따라 결정됩니다. 상한은 없습니다. 각 전송 매핑은 최소 최대 필요한 메시지 길이 지원을 정의하며, 최소 최대 길이는 최소 480옥텟이어야 합니다.
Any transport receiver MUST be able to accept messages of up to and including 480 octets in length. All transport receiver implementations SHOULD be able to accept messages of up to and including 2048 octets in length. Transport receivers MAY receive messages larger than 2048 octets in length. If a transport receiver receives a message with a length larger than it supports, the transport receiver SHOULD truncate the payload. Alternatively, it MAY discard the message.
모든 전송 수신기는 최대 480옥텟 길이의 메시지를 수신할 수 있어야 합니다. 모든 전송 수신기 구현은 최대 2048옥텟 길이의 메시지를 수신할 수 있어야 합니다. 전송 수신기는 2048옥텟 길이보다 큰 메시지를 수신할 수 있습니다. 전송 수신기가 지원하는 길이보다 긴 메시지를 수신하는 경우 전송 수신기는 페이로드를 잘라야 합니다. 또는 메시지를 삭제할 수 있습니다.
If a transport receiver truncates messages, the truncation MUST occur at the end of the message. After truncation, the message MAY contain invalid UTF-8 encoding or invalid STRUCTURED-DATA. The transport receiver MAY discard the message or MAY try to process as much as possible in this case.
전송 수신기가 메시지를 잘라내는 경우 잘라내기는 메시지 끝에서 발생해야 합니다. 잘라낸 후 메시지에는 잘못된 UTF-8 인코딩이나 잘못된 STRUCTURED-DATA가 포함될 수 있습니다. 이 경우 전송 수신자는 메시지를 삭제하거나 가능한 한 많은 내용을 처리하려고 시도할 수 있습니다.
## 6.2. HEADER
The character set used in the HEADER MUST be seven-bit ASCII in an eight-bit field as described in `[RFC5234]`. These are the ASCII codes as defined in "USA Standard Code for Information Interchange" `[ANSI.X3-4.1968]`.
HEADER에 사용된 문자 집합은 `[RFC5234]`에 설명된 대로 8비트 필드에 7비트 ASCII여야 합니다. 이는 "USA Standard Code for Information Interchange"`[ANSI.X3-4.1968]`에 정의된 ASCII 코드입니다.
The header format is designed to provide some interoperability with older BSD-based syslog. For details on this, see Appendix A.1.
헤더 형식은 이전 BSD 기반 syslog와의 일부 상호 운용성을 제공하도록 설계되었습니다. 이에 대한 자세한 내용은 부록 A.1을 참조하십시오.
### 6.2.1. PRI
The PRI part MUST have three, four, or five characters and will be bound with angle brackets as the first and last characters. The PRI part starts with a leading "<" ('less-than' character, %d60), followed by a number, which is followed by a ">" ('greater-than' character, %d62). The number contained within these angle brackets is known as the Priority value (PRIVAL) and represents both the Facility and Severity. The Priority value consists of one, two, or three decimal integers (ABNF DIGITS) using values of %d48 (for "0") through %d57 (for "9").
PRI 부분은 3, 4 또는 5개의 문자가 있어야 하며 첫 번째와 마지막 문자로 꺾쇠 괄호로 묶입니다. PRI 부분은 선행 "<"('보다 작음' 문자, %d60)로 시작하고 그 뒤에 숫자가 오고 그 뒤에 ">"('보다 큼' 문자, %d62)가 옵니다. 이러한 꺾쇠 괄호 안에 있는 숫자는 우선순위 값(PRIVAL)이라고 하며, 시설과 심각도를 모두 나타냅니다. 우선순위 값은 %d48("0")에서 %d57("9")까지의 값을 사용하는 1, 2 또는 3개의 10진수 정수(ABNF DIGITS)로 구성됩니다.
Facility and Severity values are not normative but often used. They are described in the following tables for purely informational purposes. Facility values MUST be in the range of 0 to 23 inclusive.
시설 및 심각도 값은 규범적이지 않지만 종종 사용됩니다. 순전히 정보 제공을 목적으로 다음 표에 설명되어 있습니다. 시설 값은 0에서 23까지의 범위에 있어야 합니다.
```
Numerical Facility
Code
0 kernel messages
1 user-level messages
2 mail system
3 system daemons
4 security/authorization messages
5 messages generated internally by syslogd
6 line printer subsystem
7 network news subsystem
8 UUCP subsystem
9 clock daemon
10 security/authorization messages
11 FTP daemon
12 NTP subsystem
13 log audit
14 log alert
15 clock daemon (note 2)
16 local use 0 (local0)
17 local use 1 (local1)
18 local use 2 (local2)
19 local use 3 (local3)
20 local use 4 (local4)
21 local use 5 (local5)
22 local use 6 (local6)
23 local use 7 (local7)
```
Table 1. Syslog Message Facilities
Each message Priority also has a decimal Severity level indicator. These are described in the following table along with their numerical values. Severity values MUST be in the range of 0 to 7 inclusive.
각 메시지 우선 순위에는 소수점 심각도 수준 표시기도 있습니다. 이는 다음 표에 숫자 값과 함께 설명되어 있습니다. 심각도 값은 0~7 범위에 있어야 합니다.
```
Numerical Severity
Code
0 Emergency: system is unusable
1 Alert: action must be taken immediately
2 Critical: critical conditions
3 Error: error conditions
4 Warning: warning conditions
5 Notice: normal but significant condition
6 Informational: informational messages
7 Debug: debug-level messages
```
Table 2. Syslog Message Severities
표 2. syslog 메세지 심각도
The Priority value is calculated by first multiplying the Facility number by 8 and then adding the numerical value of the Severity. For example, a kernel message (Facility=0) with a Severity of Emergency (Severity=0) would have a Priority value of 0. Also, a "local use 4" message (Facility=20) with a Severity of Notice (Severity=5) would have a Priority value of 165. In the PRI of a syslog message, these values would be placed between the angle brackets as <0> and <165> respectively. The only time a value of "0" follows the "<" is for the Priority value of "0". Otherwise, leading "0"s MUST NOT be used.
우선순위 값은 먼저 시설 번호에 8을 곱한 다음 심각도의 숫자 값을 더하여 계산합니다. 예를 들어, 심각도가 Emergency(심각도=0)인 커널 메시지(시설=0)는 우선순위 값이 0입니다. 또한 심각도가 Notice(심각도=5)인 "local use 4" 메시지(시설=20)는 우선순위 값이 165입니다. syslog 메시지의 PRI에서 이러한 값은 각각 <0>과 <165>로 꺾쇠 괄호 사이에 배치됩니다. "<" 뒤에 "0" 값이 오는 유일한 경우는 우선순위 값이 "0"일 때입니다. 그렇지 않은 경우 선행 "0"을 사용해서는 안 됩니다.
### 6.2.2. VERSION
The VERSION field denotes the version of the syslog protocol specification. The version number MUST be incremented for any new syslog protocol specification that changes any part of the HEADER format. Changes include the addition or removal of fields, or a change of syntax or semantics of existing fields. This document uses a VERSION value of "1". The VERSION values are IANA-assigned (Section 9.1) via the Standards Action method as described in `[RFC5226]`.
VERSION 필드는 syslog 프로토콜 사양의 버전을 나타냅니다. HEADER 형식의 어떤 부분이든 변경하는 새로운 syslog 프로토콜 사양의 경우 버전 번호를 반드시 증가시켜야 합니다. 변경 사항에는 필드 추가 또는 제거, 기존 필드의 구문 또는 의미 변경이 포함됩니다. 이 문서는 VERSION 값 "1"을 사용합니다. VERSION 값은 `[RFC5226]`에 설명된 대로 표준 조치 방법을 통해 IANA에서 할당(섹션 9.1)합니다.
### 6.2.3. TIMESTAMP
The TIMESTAMP field is a formalized timestamp derived from `[RFC3339]`.
TIMESTAMP 필드는 `[RFC3339]`에서 파생된 공식화된 타임스탬프입니다.
Whereas `[RFC3339]` makes allowances for multiple syntaxes, this document imposes further restrictions. The TIMESTAMP value MUST follow these restrictions:
`[RFC3339]`는 여러 구문을 허용하는 반면, 이 문서는 추가적인 제한을 부과합니다. TIMESTAMP 값은 다음 제한을 따라야 합니다.
- The "T" and "Z" characters in this syntax MUST be upper case.
- 이 구문의 "T" 및 "Z" 문자는 대문자여야 합니다.
- Usage of the "T" character is REQUIRED.
- "T" 문자 사용은 필수입니다.
- Leap seconds MUST NOT be used.
- 윤초는 사용해서는 안 됩니다.
The originator SHOULD include TIME-SECFRAC if its clock accuracy and performance permit. The "timeQuality" SD-ID described in Section 7.1 allows the originator to specify the accuracy and trustworthiness of the timestamp.
발신자는 시계 정확도와 성능이 허용하는 경우 TIME-SECFRAC를 포함해야 합니다. 섹션 7.1에 설명된 "timeQuality" SD-ID를 통해 발신자는 타임스탬프의 정확도와 신뢰성을 지정할 수 있습니다.
A syslog application MUST use the NILVALUE as TIMESTAMP if the syslog application is incapable of obtaining system time.
syslog 애플리케이션은 시스템 시간을 얻을 수 없는 경우 TIMESTAMP로 NILVALUE를 사용해야 합니다.
#### 6.2.3.1 Examples
Example 1
`1985-04-12T23:20:50.52Z`
This represents 20 minutes and 50.52 seconds after the 23rd hour of 12 April 1985 in UTC.
이것은 UTC 기준으로 1985년 4월 12일 23시 20분 50.52초 후를 나타냅니다.
Example 2
`1985-04-12T19:20:50.52-04:00`
This represents the same time as in example 1, but expressed in US Eastern Standard Time (observing daylight savings time).
이것은 예제 1과 동일한 시간을 나타내지만 미국 동부 표준시(일광 절약 시간제 준수)로 표시됩니다.
Example 3
`2003-10-11T22:14:15.003Z`
This represents 11 October 2003 at 10:14:15pm, 3 milliseconds into the next second. The timestamp is in UTC. The timestamp provides millisecond resolution. The creator may have actually had a better resolution, but providing just three digits for the fractional part of a second does not tell us.
이것은 2003년 10월 11일 오후 10시 14분 15초, 다음 초의 3밀리초를 나타냅니다. 타임스탬프는 UTC입니다. 타임스탬프는 밀리초 단위의 해상도를 제공합니다. 작성자는 실제로 더 나은 해결책을 가지고 있었을 수 있지만, 초의 소수 부분에 대해 세 자리 숫자만 제공한다고 해서 알 수 있는 것은 아닙니다.
Example 4
`2003-08-24T05:14:15.000003-07:00`
This represents 24 August 2003 at 05:14:15am, 3 microseconds into the next second. The microsecond resolution is indicated by the additional digits in TIME-SECFRAC. The timestamp indicates that its local time is -7 hours from UTC. This timestamp might be created in the US Pacific time zone during daylight savings time.
이것은 2003년 8월 24일 오전 5시 14분 15초, 다음 초의 3마이크로초를 나타냅니다. 마이크로초 해상도는 TIME-SECFRAC의 추가 숫자로 표시됩니다. 타임스탬프는 현지 시간이 UTC에서 -7시간임을 나타냅니다. 이 타임스탬프는 일광 절약 시간제 동안 미국 태평양 표준시에 생성되었을 수 있습니다.
Example 5 - An Invalid TIMESTAMP
`2003-08-24T05:14:15.000000003-07:00`
This example is nearly the same as Example 4, but it is specifying TIME-SECFRAC in nanoseconds. This results in TIME-SECFRAC being longer than the allowed 6 digits, which invalidates it.
이 예제는 예제 4와 거의 동일하지만 TIME-SECFRAC를 나노초로 지정합니다. 이로 인해 TIME-SECFRAC이 허용된 6자리보다 길어져 무효화됩니다.
### 6.2.4. HOSTNAME
The HOSTNAME field identifies the machine that originally sent the syslog message.
HOSTNAME 필드는 원래 syslog 메시지를 보낸 컴퓨터를 식별합니다.
The HOSTNAME field SHOULD contain the hostname and the domain name of the originator in the format specified in STD 13 `[RFC1034]`. This format is called a Fully Qualified Domain Name (FQDN) in this document.
HOSTNAME 필드에는 STD 13 `[RFC1034]`에 지정된 형식으로 발신자의 호스트 이름과 도메인 이름이 포함되어야 합니다. 이 형식은 이 문서에서 FQDN(Fully Qualified Domain Name)이라고 합니다.
In practice, not all syslog applications are able to provide an FQDN. As such, other values MAY also be present in HOSTNAME. This document makes provisions for using other values in such situations. A syslog application SHOULD provide the most specific available value first. The order of preference for the contents of the HOSTNAME field is as follows:
실제로 모든 syslog 애플리케이션이 FQDN을 제공할 수 있는 것은 아닙니다. 따라서 HOSTNAME에 다른 값도 있을 수 있습니다. 이 문서에서는 이러한 상황에서 다른 값을 사용하도록 규정합니다. syslog 애플리케이션은 가장 구체적인 사용 가능한 값을 먼저 제공해야 합니다. HOSTNAME 필드의 내용에 대한 우선 순위는 다음과 같습니다.
```
1. FQDN
2. Static IP address
3. hostname
4. Dynamic IP address
5. the NILVALUE
```
If an IPv4 address is used, it MUST be in the format of the dotted decimal notation as used in STD 13 `[RFC1035]`. If an IPv6 address is used, a valid textual representation as described in `[RFC4291]`, Section 2.2, MUST be used.
IPv4 주소를 사용하는 경우 STD 13 `[RFC1035]`에서 사용하는 점분 10진수 표기법 형식이어야 합니다. IPv6 주소를 사용하는 경우 `[RFC4291]`, 섹션 2.2에 설명된 대로 유효한 텍스트 표현을 사용해야 합니다.
Syslog applications SHOULD consistently use the same value in the HOSTNAME field for as long as possible.
syslog 애플리케이션은 가능한 한 오랫동안 HOSTNAME 필드에 동일한 값을 일관되게 사용해야 합니다.
The NILVALUE SHOULD only be used when the syslog application has no way to obtain its real hostname. This situation is considered highly unlikely.
NILVALUE는 syslog 애플리케이션이 실제 호스트 이름을 얻을 방법이 없는 경우에만 사용해야 합니다. 이 상황은 매우 가능성이 낮은 것으로 간주됩니다.
### 6.2.5. APP-NAME
The APP-NAME field SHOULD identify the device or application that originated the message. It is a string without further semantics. It is intended for filtering messages on a relay or collector.
APP-NAME 필드는 메시지를 생성한 장치 또는 애플리케이션을 식별해야 합니다. 이는 추가 의미론이 없는 문자열입니다. 릴레이 또는 수집기에서 메시지를 필터링하기 위한 것입니다.
The NILVALUE MAY be used when the syslog application has no idea of its APP-NAME or cannot provide that information. It may be that a device is unable to provide that information either because of a local policy decision, or because the information is not available, or not applicable, on the device.
NILVALUE는 syslog 애플리케이션이 APP-NAME을 전혀 모르거나 해당 정보를 제공할 수 없는 경우 사용할 수 있습니다. 로컬 정책 결정으로 인해 장치가 해당 정보를 제공할 수 없거나 장치에서 정보를 사용할 수 없거나 적용할 수 없기 때문일 수 있습니다.
This field MAY be operator-assigned.
이 필드는 운영자가 할당할 수 있습니다.
### 6.2.6. PROCID
PROCID is a value that is included in the message, having no interoperable meaning, except that a change in the value indicates there has been a discontinuity in syslog reporting. The field does not have any specific syntax or semantics; the value is implementation-dependent and/or operator-assigned. The NILVALUE MAY be used when no value is provided.
PROCID는 메시지에 포함된 값으로, 상호 운용 가능한 의미가 없지만 값의 변경은 syslog 보고에 불연속성이 있음을 나타냅니다. 이 필드에는 특정 구문이나 의미가 없습니다. 값은 구현에 따라 달라지거나 연산자에 따라 할당됩니다. 값이 제공되지 않을 때 NILVALUE를 사용할 수 있습니다.
The PROCID field is often used to provide the process name or process ID associated with a syslog system. The NILVALUE might be used when a process ID is not available. On an embedded system without any operating system process ID, PROCID might be a reboot ID.
PROCID 필드는 종종 syslog 시스템과 연관된 프로세스 이름이나 프로세스 ID를 제공하는 데 사용됩니다. NILVALUE는 프로세스 ID를 사용할 수 없는 경우 사용될 수 있습니다. 운영 체제 프로세스 ID가 없는 임베디드 시스템에서 PROCID는 재부팅 ID일 수 있습니다.
PROCID can enable log analyzers to detect discontinuities in syslog reporting by detecting a change in the syslog process ID. However, PROCID is not a reliable identification of a restarted process since the restarted syslog process might be assigned the same process ID as the previous syslog process.
PROCID를 사용하면 로그 분석기가 syslog 프로세스 ID의 변경을 감지하여 syslog 보고의 불연속성을 감지할 수 있습니다. 그러나 PROCID는 다시 시작된 프로세스를 신뢰할 수 있게 식별하는 데 사용할 수 없습니다. 다시 시작된 syslog 프로세스에 이전 syslog 프로세스와 동일한 프로세스 ID가 할당될 수 있기 때문입니다.
PROCID can also be used to identify which messages belong to a group of messages. For example, an SMTP mail transfer agent might put its SMTP transaction ID into PROCID, which would allow the collector or relay to group messages based on the SMTP transaction.
PROCID는 또한 어떤 메시지가 메시지 그룹에 속하는지 식별하는 데 사용될 수 있습니다. 예를 들어, SMTP 메일 전송 에이전트는 SMTP 트랜잭션 ID를 PROCID에 넣을 수 있으며, 이를 통해 수집기 또는 릴레이는 SMTP 트랜잭션을 기반으로 메시지를 그룹화할 수 있습니다.
### 6.2.7. MSGID
The MSGID SHOULD identify the type of message. For example, a firewall might use the MSGID "TCPIN" for incoming TCP traffic and the MSGID "TCPOUT" for outgoing TCP traffic. Messages with the same MSGID should reflect events of the same semantics. The MSGID itself is a string without further semantics. It is intended for filtering messages on a relay or collector.
MSGID는 메시지 유형을 식별해야 합니다. 예를 들어 방화벽은 들어오는 TCP 트래픽에 MSGID "TCPIN"을 사용하고 나가는 TCP 트래픽에 MSGID "TCPOUT"을 사용할 수 있습니다. 동일한 MSGID를 가진 메시지는 동일한 의미론의 이벤트를 반영해야 합니다. MSGID 자체는 추가 의미론이 없는 문자열입니다. 릴레이 또는 수집기에서 메시지를 필터링하기 위한 것입니다.
The NILVALUE SHOULD be used when the syslog application does not, or cannot, provide any value.
NILVALUE는 syslog 애플리케이션이 값을 제공하지 않거나 제공할 수 없는 경우 사용해야 합니다.
This field MAY be operator-assigned.
이 필드는 운영자가 할당할 수 있습니다.
## 6.3. STRUCTURED-DATA
STRUCTURED-DATA provides a mechanism to express information in a well defined, easily parseable and interpretable data format. There are multiple usage scenarios. For example, it may express meta-information about the syslog message or application-specific information such as traffic counters or IP addresses.
구조화된 데이터는 잘 정의되고 쉽게 구문 분석하고 해석할 수 있는 데이터 형식으로 정보를 표현하는 메커니즘을 제공합니다. 여러 가지 사용 시나리오가 있습니다. 예를 들어, syslog 메시지에 대한 메타 정보나 트래픽 카운터 또는 IP 주소와 같은 애플리케이션별 정보를 표현할 수 있습니다.
STRUCTURED-DATA can contain zero, one, or multiple structured data elements, which are referred to as "SD-ELEMENT" in this document.
구조화된 데이터는 이 문서에서 "SD-ELEMENT"라고 하는 0개, 1개 또는 여러 개의 구조화된 데이터 요소를 포함할 수 있습니다.
In case of zero structured data elements, the STRUCTURED-DATA field MUST contain the NILVALUE.
구조화된 데이터 요소가 0개인 경우, 구조화된 데이터 필드에는 NILVALUE가 포함되어야 합니다.
The character set used in STRUCTURED-DATA MUST be seven-bit ASCII in an eight-bit field as described in `[RFC5234]`. These are the ASCII codes as defined in "USA Standard Code for Information Interchange" `[ANSI.X3-4.1968]`. An exception is the PARAM-VALUE field (see Section 6.3.3), in which UTF-8 encoding MUST be used.
구조화된 데이터에서 사용되는 문자 집합은 `[RFC5234]`에 설명된 대로 8비트 필드에 7비트 ASCII여야 합니다. 이는 "USA Standard Code for Information Interchange"`[ANSI.X3-4.1968]`에 정의된 ASCII 코드입니다. 예외는 PARAM-VALUE 필드(섹션 6.3.3 참조)로, UTF-8 인코딩을 사용해야 합니다.
A collector MAY ignore malformed STRUCTURED-DATA elements. A relay MUST forward malformed STRUCTURED-DATA without any alteration.
수집기는 잘못된 STRUCTURED-DATA 요소를 무시할 수 있습니다. 릴레이는 잘못된 STRUCTURED-DATA를 변경 없이 전달해야 합니다.
### 6.3.1. SD-ELEMENT
An SD-ELEMENT consists of a name and parameter name-value pairs. The name is referred to as SD-ID. The name-value pairs are referred to as "SD-PARAM".
SD-ELEMENT는 이름과 매개변수 이름-값 쌍으로 구성됩니다. 이름은 SD-ID라고 합니다. 이름-값 쌍은 "SD-PARAM"이라고 합니다.
### 6.3.2. SD-ID
SD-IDs are case-sensitive and uniquely identify the type and purpose of the SD-ELEMENT. The same SD-ID MUST NOT exist more than once in a message.
SD-ID는 대소문자를 구분하며 SD-ELEMENT의 유형과 목적을 고유하게 식별합니다. 동일한 SD-ID는 메시지에 두 번 이상 존재해서는 안 됩니다.
There are two formats for SD-ID names:
SD-ID 이름에는 두 가지 형식이 있습니다.
- Names that do not contain an at-sign ("@", ABNF %d64) are reserved to be assigned by IETF Review as described in BCP26 `[RFC5226]`. Currently, these are the names defined in Section 7. Names of this format are only valid if they are first registered with the IANA. Registered names MUST NOT contain an at-sign ('@', ABNF %d64), an equal-sign ('=', ABNF %d61), a closing brace (']', ABNF %d93), a quote-character ('"', ABNF %d34), whitespace, or control characters (ASCII code 127 and codes 32 or less).
- at-sign ("@", ABNF %d64)이 포함되지 않은 이름은 BCP26 `[RFC5226]`에 설명된 대로 IETF 검토에서 지정하도록 예약되어 있습니다. 현재 이러한 이름은 섹션 7에 정의되어 있습니다. 이 형식의 이름은 IANA에 처음 등록한 경우에만 유효합니다. 등록된 이름에는 at-sign('@', ABNF %d64), 등호('=', ABNF %d61), 닫는 중괄호(']', ABNF %d93), 따옴표 문자('"', ABNF %d34), 공백 또는 제어 문자(ASCII 코드 127 및 코드 32 이하)가 포함되어서는 안 됩니다.
- Anyone can define additional SD-IDs using names in the `formatname@<private enterprise number>`, e.g., "ourSDID@32473". The format of the part preceding the at-sign is not specified; however, these names MUST be printable US-ASCII strings, and MUST NOT contain an at-sign ('@', ABNF %d64), an equal-sign ('=', ABNF %d61), a closing brace (']', ABNF %d93), a quote-character ('"', ABNF %d34), whitespace, or control characters. The part following the at-sign MUST be a private enterprise number as specified in Section 7.2.2. Please note that throughout this document the value of 32473 is used for all private enterprise numbers. This value has been reserved by IANA to be used as an example number in documentation. Implementors will need to use their own private enterprise number for the enterpriseId parameter, and when creating locally extensible SD-ID names.
- 누구나 `formatname@<private enterprise number>` 형식의 이름을 사용하여 추가 SD-ID를 정의할 수 있습니다(예: "ourSDID@32473"). at-sign 앞 부분의 형식은 지정되지 않았지만 이러한 이름은 인쇄 가능한 US-ASCII 문자열이어야 하며 at-sign('@', ABNF %d64), 등호('=', ABNF %d61), 닫는 중괄호(']', ABNF %d93), 따옴표 문자('"', ABNF %d34)가 포함되어서는 안 됩니다. 공백 또는 제어 문자. at-sign 뒤에 오는 부분은 섹션 7.2.2에 명시된 대로 개인 기업 번호여야 합니다. 이 문서 전체에서 모든 개인 기업 번호에 32473이라는 값이 사용된다는 점에 유의하세요. 이 값은 IANA에서 설명서에서 예시 번호로 사용하도록 예약했습니다. 구현자는 enterpriseId 매개변수에 대해 자체 개인 기업 번호를 사용해야 하며 로컬로 확장 가능한 SD-ID 이름을 생성할 때 사용해야 합니다.
### 6.3.3. SD-PARAM
Each SD-PARAM consists of a name, referred to as PARAM-NAME, and a value, referred to as PARAM-VALUE.
각 SD-PARAM은 PARAM-NAME이라고 하는 이름과 PARAM-VALUE라고 하는 값으로 구성됩니다.
PARAM-NAME is case-sensitive. IANA controls all PARAM-NAMEs, with the exception of those in SD-IDs whose names contain an at-sign. The PARAM-NAME scope is within a specific SD-ID. Thus, equally named PARAM-NAME values contained in two different SD-IDs are not the same.
PARAM-NAME은 대소문자를 구분합니다. IANA는 이름에 at-sign이 포함된 SD-ID의 PARAM-NAME을 제외한 모든 PARAM-NAME을 제어합니다. PARAM-NAME 범위는 특정 SD-ID 내에 있습니다. 따라서 두 개의 다른 SD-ID에 포함된 동일한 이름의 PARAM-NAME 값은 동일하지 않습니다.
To support international characters, the PARAM-VALUE field MUST be encoded using UTF-8. A syslog application MAY issue any valid UTF-8 sequence. A syslog application MUST accept any valid UTF-8 sequence in the "shortest form". It MUST NOT fail if control characters are present in PARAM-VALUE. The syslog application MAY modify messages containing control characters (e.g., by changing an octet with value 0 (USASCII NUL) to the four characters "#000"). For the reasons outlined in UNICODE TR36 `[UNICODE-TR36]`, section 3.1, an originator MUST encode messages in the "shortest form" and a collector or relay MUST NOT interpret messages in the "non-shortest form".
국제 문자를 지원하려면 PARAM-VALUE 필드는 UTF-8을 사용하여 인코딩해야 합니다. syslog 애플리케이션은 유효한 UTF-8 시퀀스를 발행할 수 있습니다. syslog 애플리케이션은 "최단 형식"의 유효한 UTF-8 시퀀스를 허용해야 합니다. PARAM-VALUE에 제어 문자가 있는 경우 실패해서는 안 됩니다. syslog 애플리케이션은 제어 문자가 포함된 메시지를 수정할 수 있습니다(예: 값이 0인 옥텟(USASCII NUL)을 4개의 문자 "#000"으로 변경). UNICODE TR36 `[UNICODE-TR36]`, 섹션 3.1에 설명된 이유로 발신자는 "가장 짧은 형식"으로 메시지를 인코딩해야 하며 수집기 또는 릴레이는 "가장 짧은 형식이 아닌 형식"으로 메시지를 해석해서는 안 됩니다.
Inside PARAM-VALUE, the characters '"' (ABNF %d34), '\' (ABNF %d92), and ']' (ABNF %d93) MUST be escaped. This is necessary to avoid parsing errors. Escaping ']' would not strictly be necessary but is REQUIRED by this specification to avoid syslog application implementation errors. Each of these three characters MUST be escaped as '\"', '\\', and '\]' respectively. The backslash is used for control character escaping for consistency with its use for escaping in other parts of the syslog message as well as in traditional syslog.
PARAM-VALUE 내부에서 문자 '"'(ABNF %d34), '\'(ABNF %d92), ']'(ABNF %d93)는 반드시 이스케이프해야 합니다. 이는 구문 분석 오류를 방지하기 위해 필요합니다. ']'를 이스케이프하는 것은 반드시 필요하지는 않지만 syslog 애플리케이션 구현 오류를 방지하기 위해 이 사양에 따라 필수입니다. 이 세 문자는 각각 '\"', '\\', '\]'로 이스케이프해야 합니다. 백슬래시는 syslog 메시지의 다른 부분과 기존 syslog에서 이스케이프하는 데 사용되는 것과 일관성을 유지하기 위해 제어 문자 이스케이프에 사용됩니다.
A backslash ('\') followed by none of the three described characters is considered an invalid escape sequence. In this case, the backslash MUST be treated as a regular backslash and the following character as a regular character. Thus, the invalid sequence MUST not be altered.
설명된 세 문자 중 어느 것도 뒤에 오지 않는 백슬래시('\')는 잘못된 이스케이프 시퀀스로 간주됩니다. 이 경우 백슬래시는 일반 백슬래시로 처리해야 하며 그 뒤의 문자는 일반 문자로 처리해야 합니다. 따라서 잘못된 시퀀스는 변경해서는 안 됩니다.
An SD-PARAM MAY be repeated multiple times inside an SD-ELEMENT.
SD-ELEMENT 내에서 SD-PARAM을 여러 번 반복할 수 있습니다.
### 6.3.4. Change Control
Once SD-IDs and PARAM-NAMEs are defined, syntax and semantics of these objects MUST NOT be altered. Should a change to an existing object be desired, a new SD-ID or PARAM-NAME MUST be created and the old one remain unchanged. OPTIONAL PARAM-NAMEs MAY be added to an existing SD-ID.
SD-ID와 PARAM-NAME이 정의되면 이러한 객체의 구문과 의미는 변경해서는 안 됩니다. 기존 객체를 변경해야 하는 경우 새 SD-ID 또는 PARAM-NAME을 만들어야 하며 이전 이름은 변경되지 않아야 합니다. 선택적 PARAM-NAME은 기존 SD-ID에 추가할 수 있습니다.
### 6.3.5. Examples
All examples in this section show only the structured data part of the message. Examples should be considered to be on one line. They are wrapped on multiple lines in this document for readability purposes. A description is given after each example.
이 섹션의 모든 예제는 메시지의 구조화된 데이터 부분만 보여줍니다. 예제는 한 줄로 간주해야 합니다. 이 문서에서는 가독성을 위해 여러 줄로 래핑했습니다. 각 예제 뒤에 설명이 제공됩니다.
Example 1 - Valid
```
[exampleSDID@32473 iut="3" eventSource="Application"
eventID="1011"]
```
This example is a structured data element with a non-IANA controlled SD-ID of type "exampleSDID@32473", which has three parameters.
이 예제는 세 개의 매개변수가 있는 "exampleSDID@32473" 유형의 비 IANA 제어 SD-ID가 있는 구조화된 데이터 요소입니다.
Example 2 - Valid
```
[exampleSDID@32473 iut="3" eventSource="Application"
eventID="1011"][examplePriority@32473 class="high"]
```
This is the same example as in 1, but with a second structured data element. Please note that the structured data element immediately follows the first one (there is no SP between them).
이것은 1과 동일한 예이지만 두 번째 구조화된 데이터 요소가 있습니다. 구조화된 데이터 요소가 첫 번째 요소 바로 뒤에 나온다는 점에 유의하세요(두 요소 사이에 SP가 없습니다)
Example 3 - Invalid
```
[exampleSDID@32473 iut="3" eventSource="Application"
eventID="1011"] [examplePriority@32473 class="high"]
```
This is nearly the same example as 2, but it has a subtle error -- there is an SP character between the two structured data elements (`"]SP["`). This is invalid. It will cause the STRUCTURED-DATA field to end after the first element. The second element will be interpreted as part of the MSG field.
이것은 2와 거의 동일한 예이지만 미묘한 오류가 있습니다. 두 구조화된 데이터 요소 사이에 SP 문자가 있습니다(`"]SP["`). 이것은 무효합니다. 이로 인해 STRUCTURED-DATA 필드가 첫 번째 요소 뒤에 끝납니다. 두 번째 요소는 MSG 필드의 일부로 해석됩니다.
Example 4 - Invalid
```
[ exampleSDID@32473 iut="3" eventSource="Application"
eventID="1011"][examplePriority@32473 class="high"]
```
This example is nearly the same as 2. It has another subtle error -- the SP character occurs after the initial bracket. A structured data element SD-ID MUST immediately follow the beginning bracket, so the SP character invalidates the STRUCTURED-DATA. A syslog application MAY discard this message.
이 예는 2와 거의 같습니다. 또 다른 미묘한 오류가 있습니다. SP 문자가 초기 대괄호 뒤에 있습니다. 구조화된 데이터 요소 SD-ID는 시작 대괄호 바로 뒤에 있어야 하므로 SP 문자는 구조화된 데이터를 무효화합니다. syslog 애플리케이션은 이 메시지를 무시할 수 있습니다.
Example 5 - Valid
```
[sigSig ver="1" rsID="1234" ... signature="..."]
```
Example 5 is a valid example. It shows a hypothetical IANA-assigned SD-ID. The ellipses denote missing content, which has been left out of this example for brevity.
예 5는 유효한 예입니다. 가상의 IANA 할당 SD-ID를 보여줍니다. 생략 부호는 누락된 콘텐츠를 나타내며, 간결성을 위해 이 예에서는 제외되었습니다.
## 6.4. MSG
The MSG part contains a free-form message that provides information about the event.
MSG 부분에는 이벤트에 대한 정보를 제공하는 자유형 메시지가 들어 있습니다.
The character set used in MSG SHOULD be UNICODE, encoded using UTF-8 as specified in `[RFC3629]`. If the syslog application cannot encode the MSG in Unicode, it MAY use any other encoding.
MSG에 사용되는 문자 집합은 `[RFC3629]`에 지정된 대로 UTF-8을 사용하여 인코딩된 UNICODE여야 합니다. syslog 애플리케이션이 MSG를 유니코드로 인코딩할 수 없는 경우 다른 인코딩을 사용할 수 있습니다.
The syslog application SHOULD avoid octet values below 32 (the traditional US-ASCII control character range except DEL). These values are legal, but a syslog application MAY modify these characters upon reception. For example, it might change them into an escape sequence (e.g., value 0 may be changed to "\0"). A syslog application SHOULD NOT modify any other octet values.
syslog 애플리케이션은 32 미만의 옥텟 값(DEL을 제외한 기존 US-ASCII 제어 문자 범위)을 피해야 합니다. 이러한 값은 합법적이지만 syslog 애플리케이션은 수신 시 이러한 문자를 수정할 수 있습니다. 예를 들어, 이를 이스케이프 시퀀스로 변경할 수 있습니다(예: 값 0은 "\0"으로 변경될 수 있음). syslog 애플리케이션은 다른 옥텟 값을 수정해서는 안 됩니다.
If a syslog application encodes MSG in UTF-8, the string MUST start with the Unicode byte order mask (BOM), which for UTF-8 is ABNF %xEF.BB.BF. The syslog application MUST encode in the "shortest form" and MAY use any valid UTF-8 sequence.
syslog 애플리케이션이 MSG를 UTF-8로 인코딩하는 경우 문자열은 반드시 유니코드 바이트 순서 마스크(BOM)로 시작해야 하며, UTF-8의 경우 ABNF %xEF.BB.BF입니다. syslog 애플리케이션은 반드시 "가장 짧은 형식"으로 인코딩해야 하며 유효한 UTF-8 시퀀스를 사용할 수 있습니다.
If a syslog application is processing an MSG starting with a BOM and the MSG contains UTF-8 that is not shortest form, the MSG MUST NOT be interpreted as being encoded in UTF-8, for the reasons outlined in `[UNICODE-TR36]`, Section 3.1. Guidance about this is given in Appendix A.8.
syslog 애플리케이션이 BOM으로 시작하는 MSG를 처리하고 MSG에 최단 형식이 아닌 UTF-8이 포함되어 있는 경우, `[UNICODE-TR36]` 섹션 3.1에 설명된 이유로 MSG를 UTF-8로 인코딩된 것으로 해석해서는 안 됩니다. 이에 대한 지침은 부록 A.8에 나와 있습니다.
Also, according to UNICODE TR36 `[UNICODE-TR36]`, a syslog application MUST NOT interpret messages in the "non-shortest form". It MUST NOT interpret invalid UTF-8 sequences.
또한 UNICODE TR36 `[UNICODE-TR36]`에 따르면 syslog 애플리케이션은 "최단 형식이 아닌" 메시지를 해석해서는 안 됩니다. 잘못된 UTF-8 시퀀스를 해석해서는 안 됩니다.
## 6.5. Examples
The following are examples of valid syslog messages. A description of each example can be found below it. The examples are based on similar examples from `[RFC3164]` and may be familiar to readers. The otherwise-unprintable Unicode BOM is represented as "BOM" in the examples.
다음은 유효한 syslog 메시지의 예입니다. 각 예에 대한 설명은 아래에서 찾을 수 있습니다. 예는 `[RFC3164]`의 유사한 예를 기반으로 하며 독자에게 익숙할 수 있습니다. 그렇지 않으면 인쇄할 수 없는 유니코드 BOM은 예에서 "BOM"으로 표시됩니다.
Example 1 - with no STRUCTURED-DATA
```
<34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47
- BOM'su root' failed for lonvick on /dev/pts/8
```
In this example, the VERSION is 1 and the Facility has the value of 4. The Severity is 2. The message was created on 11 October 2003 at 10:14:15pm UTC, 3 milliseconds into the next second. The message originated from a host that identifies itself as "mymachine.example.com". The APP-NAME is "su" and the PROCID is unknown. The MSGID is "ID47". The MSG is "'su root' failed for lonvick...", encoded in UTF-8. The encoding is defined by the BOM. There is no STRUCTURED-DATA present in the message; this is indicated by "-" in the STRUCTURED-DATA field.
이 예에서 VERSION은 1이고 Facility는 값 4입니다. Severity는 2입니다. 메시지는 2003년 10월 11일 오후 10시 14분 15초 UTC에 생성되었으며, 다음 1초의 3밀리초입니다. 메시지는 자신을 "mymachine.example.com"으로 식별하는 호스트에서 시작되었습니다. APP-NAME은 "su"이고 PROCID는 알 수 없습니다. MSGID는 "ID47"입니다. MSG는 "'su root' failed for lonvick..."이며 UTF-8로 인코딩되었습니다. 인코딩은 BOM에서 정의합니다. 메시지에 구조화된 데이터가 없습니다. 이것은 STRUCTURED-DATA 필드에 "-"로 표시됩니다.
Example 2 - with no STRUCTURED-DATA
```
<165>1 2003-08-24T05:14:15.000003-07:00 192.0.2.1
myproc 8710 - - %% It's time to make the do-nuts.
```
In this example, the VERSION is again 1. The Facility is 20, the Severity 5. The message was created on 24 August 2003 at 5:14:15am, with a -7 hour offset from UTC, 3 microseconds into the next second. The HOSTNAME is "192.0.2.1", so the syslog application did not know its FQDN and used one of its IPv4 addresses instead. The APP-NAME is "myproc" and the PROCID is "8710" (for example, this could be the UNIX PID). There is no STRUCTURED-DATA present in the message; this is indicated by "-" in the STRUCTURED-DATA field. There is no specific MSGID and this is indicated by the "-" in the MSGID field.
이 예에서 VERSION은 다시 1입니다. 시설은 20이고 심각도는 5입니다. 메시지는 2003년 8월 24일 오전 5시 14분 15초에 생성되었으며, UTC에서 -7시간 오프셋이 적용되어 다음 초에서 3마이크로초가 되었습니다. HOSTNAME은 "192.0.2.1"이므로 syslog 애플리케이션은 FQDN을 알지 못하고 대신 IPv4 주소 중 하나를 사용했습니다. APP-NAME은 "myproc"이고 PROCID는 "8710"입니다(예를 들어, UNIX PID일 수 있음). 메시지에 STRUCTURED-DATA가 없습니다. 이는 STRUCTURED-DATA 필드에 "-"로 표시됩니다. 특정 MSGID가 없으며 이는 MSGID 필드에 "-"로 표시됩니다.
The message is `"%% It's time to make the do-nuts."`. As the Unicode BOM is missing, the syslog application does not know the encoding of the MSG part.
메시지는 `"%% It's time to make the do-nuts."`입니다. 유니코드 BOM이 없으므로 syslog 애플리케이션은 MSG 부분의 인코딩을 알지 못합니다.
Example 3 - with STRUCTURED-DATA
```
<165>1 2003-10-11T22:14:15.003Z mymachine.example.com
evntslog - ID47 [exampleSDID@32473 iut="3" eventSource=
"Application" eventID="1011"] BOMAn application
event log entry...
```
This example is modeled after Example 1. However, this time it contains STRUCTURED-DATA, a single element with the value `"[exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"]"`. The MSG itself is "An application event log entry..." The BOM at the beginning of MSG indicates UTF-8 encoding.
이 예는 예 1을 모델로 했습니다. 그러나 이번에는 `"[exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"]"` 값을 가진 단일 요소인 STRUCTURED-DATA가 포함되어 있습니다. MSG 자체는 "An application event log entry..."입니다. MSG 시작 부분의 BOM은 UTF-8 인코딩을 나타냅니다.
Example 4 - STRUCTURED-DATA Only
```
<165>1 2003-10-11T22:14:15.003Z mymachine.example.com
evntslog - ID47 [exampleSDID@32473 iut="3" eventSource=
"Application" eventID="1011"][examplePriority@32473
class="high"]
```
This example shows a message with only STRUCTURED-DATA and no MSG part. This is a valid message.
이 예에서는 STRUCTURED-DATA만 있고 MSG 부분이 없는 메시지를 보여줍니다. 이는 유효한 메시지입니다.
# 7. Structured Data IDs
This section defines the initial IANA-registered SD-IDs. See Section 6.3 for a definition of structured data elements. All SD-IDs defined here are OPTIONAL.
이 섹션에서는 초기 IANA 등록 SD-ID를 정의합니다. 구조화된 데이터 요소의 정의는 섹션 6.3을 참조하세요. 여기에 정의된 모든 SD-ID는 선택 사항입니다.
In some of the following, a maximum length is quantified for the parameter values. In each of those cases, the syslog application MUST be prepared to receive the number of defined characters in any valid UTF-8 code point. Since each character may be up to 6 octets, it is RECOMMENDED that each syslog application be prepared to receive up to 6 octets per character.
다음 중 일부에서 매개변수 값의 최대 길이가 정량화됩니다. 이러한 각 경우에 syslog 애플리케이션은 유효한 UTF-8 코드 포인트에서 정의된 문자 수를 수신할 준비가 되어 있어야 합니다. 각 문자는 최대 6옥텟일 수 있으므로 각 syslog 애플리케이션은 문자당 최대 6옥텟을 수신할 준비가 되어 있어야 합니다.
## 7.1. timeQuality
The SD-ID "timeQuality" MAY be used by the originator to describe its notion of system time. This SD-ID SHOULD be written if the originator is not properly synchronized with a reliable external time source or if it does not know whether its time zone information is correct. The main use of this structured data element is to provide some information on the level of trust it has in the TIMESTAMP described in Section 6.2.3. All parameters are OPTIONAL.
SD-ID "timeQuality"는 발신자가 시스템 시간 개념을 설명하는 데 사용할 수 있습니다. 발신자가 신뢰할 수 있는 외부 시간 소스와 적절하게 동기화되지 않았거나 표준 시간대 정보가 올바른지 알 수 없는 경우 이 SD-ID를 작성해야 합니다. 이 구조화된 데이터 요소의 주요 용도는 섹션 6.2.3에 설명된 TIMESTAMP에 대한 신뢰 수준에 대한 정보를 제공하는 것입니다. 모든 매개변수는 선택 사항입니다.
### 7.1.1. tzKnown
The "tzKnown" parameter indicates whether the originator knows its time zone. If it does, the value "1" MUST be used. If the time zone information is in doubt, the value "0" MUST be used. If the originator knows its time zone but decides to emit time in UTC, the value "1" MUST be used (because the time zone is known).
"tzKnown" 매개변수는 발신자가 시간대를 알고 있는지 여부를 나타냅니다. 알고 있는 경우 값 "1"을 사용해야 합니다. 시간대 정보가 의심스러운 경우 값 "0"을 사용해야 합니다. 발신자가 시간대를 알고 있지만 UTC로 시간을 내보내기로 결정한 경우 값 "1"을 사용해야 합니다(시간대가 알려져 있기 때문).
### 7.1.2. isSynced
The "isSynced" parameter indicates whether the originator is synchronized to a reliable external time source, e.g., via NTP. If the originator is time synchronized, the value "1" MUST be used. If not, the value "0" MUST be used.
"isSynced" 매개변수는 발신자가 신뢰할 수 있는 외부 시간 소스(예: NTP)에 동기화되었는지 여부를 나타냅니다. 발신자가 시간 동기화된 경우 값 "1"을 사용해야 합니다. 그렇지 않은 경우 값 "0"을 사용해야 합니다.
### 7.1.3. syncAccuracy
The "syncAccuracy" parameter indicates how accurate the originator thinks its time synchronization is. It is an integer describing the maximum number of microseconds that its clock may be off between synchronization intervals.
"syncAccuracy" 매개변수는 발신자가 시간 동기화가 얼마나 정확한지 생각하는지 나타냅니다. 동기화 간격 사이에 클록이 꺼질 수 있는 최대 마이크로초 수를 설명하는 정수입니다.
If the value "0" is used for "isSynced", this parameter MUST NOT be specified. If the value "1" is used for "isSynced" but the "syncAccuracy" parameter is absent, a collector or relay can assume that the time information provided is accurate enough to be considered correct. The "syncAccuracy" parameter MUST be written only if the originator actually has knowledge of the reliability of the external time source. In most cases, it will gain this in-depth knowledge through operator configuration.
"isSynced"에 값 "0"을 사용하는 경우 이 매개변수를 지정해서는 안 됩니다. "isSynced"에 값 "1"을 사용하지만 "syncAccuracy" 매개변수가 없는 경우 수집기 또는 릴레이는 제공된 시간 정보가 정확하여 올바른 것으로 간주될 수 있다고 가정할 수 있습니다. "syncAccuracy" 매개변수는 발신자가 실제로 외부 시간 소스의 안정성을 알고 있는 경우에만 작성해야 합니다. 대부분의 경우 운영자 구성을 통해 이러한 심층적인 지식을 얻게 됩니다.
### 7.1.4. Examples
The following is an example of an originator that does not know its time zone or whether it is being synchronized:
다음은 시간대를 모르거나 동기화되는지 여부를 모르는 발신자의 예입니다.
```[timeQuality tzKnown="0" isSynced="0"]```
With this information, the originator indicates that its time information is unreliable. This may be a hint for the collector or relay to use its local time instead of the message-provided TIMESTAMP for correlation of multiple messages from different originators.
발신자는 이 정보를 사용하여 시간 정보가 신뢰할 수 없음을 나타냅니다. 이는 수집기 또는 릴레이가 여러 발신자의 여러 메시지를 상관시키기 위해 메시지에서 제공하는 TIMESTAMP 대신 로컬 시간을 사용하도록 하는 힌트가 될 수 있습니다.
The following is an example of an originator that knows its time zone and knows that it is properly synchronized to a reliable external source:
다음은 시간대를 알고 신뢰할 수 있는 외부 소스에 적절하게 동기화되었음을 아는 발신자의 예입니다.
```[timeQuality tzKnown="1" isSynced="1"]```
The following is an example of an originator that knows both its time zone and that it is externally synchronized. It also knows the accuracy of the external synchronization:
다음은 시간대와 외부에서 동기화되었음을 모두 아는 발신자의 예입니다. 또한 외부 동기화의 정확도도 알고 있습니다.
```[timeQuality tzKnown="1" isSynced="1" syncAccuracy="60000000"]```
The difference between this and the previous example is that the originator expects that its clock will be kept within 60 seconds of the official time. Thus, if the originator reports it is 9:00:00, it is no earlier than 8:59:00 and no later then 9:01:00.
이 예와 이전 예의 차이점은 발신자가 시계가 공식 시간에서 60초 이내로 유지될 것으로 예상한다는 것입니다. 따라서 발신자가 9:00:00이라고 보고하면 8:59:00 이전이 아니고 9:01:00 이후가 아닙니다.
## 7.2. origin
The SD-ID "origin" MAY be used to indicate the origin of a syslog message. The following parameters can be used. All parameters are OPTIONAL.
SD-ID "origin"은 syslog 메시지의 출처를 나타내는 데 사용할 수 있습니다. 다음 매개변수를 사용할 수 있습니다. 모든 매개변수는 선택 사항입니다.
Specifying any of these parameters is primarily an aid to log analyzers and similar applications.
이러한 매개변수 중 하나를 지정하는 것은 주로 로그 분석기 및 유사한 애플리케이션에 도움이 됩니다.
### 7.2.1. ip
The "ip" parameter denotes an IP address that the originator knows it had at the time of originating the message. It MUST contain the textual representation of an IP address as outlined in Section 6.2.4.
"ip" 매개변수는 발신자가 메시지를 발신할 당시에 가지고 있었던 IP 주소를 나타냅니다. 섹션 6.2.4에 설명된 대로 IP 주소의 텍스트 표현을 포함해야 합니다.
This parameter can be used to provide identifying information in addition to what is present in the HOSTNAME field. It might be especially useful if the host's IP address is included in the message while the HOSTNAME field still contains the FQDN. It is also useful for describing all IP addresses of a multihomed host.
이 매개변수는 HOSTNAME 필드에 있는 것 외에도 식별 정보를 제공하는 데 사용할 수 있습니다. 특히 호스트의 IP 주소가 메시지에 포함되어 있고 HOSTNAME 필드에 여전히 FQDN이 포함되어 있는 경우 유용할 수 있습니다. 또한 멀티홈 호스트의 모든 IP 주소를 설명하는 데 유용합니다.
If an originator has multiple IP addresses, it MAY either list one of its IP addresses in the "ip" parameter or it MAY include multiple "ip" parameters in a single "origin" structured data element.
발신자가 여러 IP 주소를 가지고 있는 경우 IP 주소 중 하나를 "ip" 매개변수에 나열하거나 단일 "origin" 구조화된 데이터 요소에 여러 "ip" 매개변수를 포함할 수 있습니다.
### 7.2.2. enterpriseId
The "enterpriseId" parameter MUST be a 'SMI Network Management Private Enterprise Code', maintained by IANA, whose prefix is iso.org.dod.internet.private.enterprise (1.3.6.1.4.1). The number that follows MUST be unique and MUST be registered with IANA as per RFC 2578 `[RFC2578]`. An enterprise is only authorized to assign values within the iso.org.dod.internet.private.enterprise.`<private enterprise number>` subtree assigned by IANA to that enterprise. The enterpriseId MUST contain only a value from the iso.org.dod.internet.private.enterprise.`<private enterprise number>` subtree. In general, only the IANA-assigned private enterprise number is needed (a single number). An enterprise might decide to use sub-identifiers below its private enterprise number. If sub- identifiers are used, they MUST be separated by periods and be represented as decimal numbers. An example for that would be "32473.1.2". Please note that the ID "32473.1.2" is just an example and MUST NOT be used. The complete up-to-date list of Private Enterprise Numbers (PEN) is maintained by IANA.
"enterpriseId" 매개변수는 IANA에서 유지 관리하는 'SMI Network Management Private Enterprise Code'여야 하며, 접두사는 iso.org.dod.internet.private.enterprise(1.3.6.1.4.1)입니다. 뒤에 오는 번호는 고유해야 하며 RFC 2578 `[RFC2578]`에 따라 IANA에 등록되어야 합니다. 기업은 IANA에서 해당 기업에 할당한 iso.org.dod.internet.private.enterprise.`<private enterprise number>` 하위 트리 내에서만 값을 할당할 수 있습니다. enterpriseId는 iso.org.dod.internet.private.enterprise.`<private enterprise number>` 하위 트리의 값만 포함해야 합니다. 일반적으로 IANA에서 할당한 private enterprise number(단일 번호)만 필요합니다. 기업은 private enterprise number 아래에 하위 식별자를 사용하기로 결정할 수 있습니다. 하위 식별자를 사용하는 경우 마침표로 구분하고 10진수로 표현해야 합니다. 이에 대한 예로는 "32473.1.2"가 있습니다. ID "32473.1.2"는 단지 예일 뿐이므로 사용해서는 안 됩니다. 최신 Private Enterprise Numbers(PEN) 목록은 IANA에서 관리합니다.
By specifying a private enterprise number, the vendor allows more specific processing of the message.
private enterprise number를 지정하면 공급업체에서 메시지를 더 구체적으로 처리할 수 있습니다.
### 7.2.3. software
The "software" parameter uniquely identifies the software that generated the message. If it is used, "enterpriseId" SHOULD also be specified, so that a specific vendor's software can be identified. The "software" parameter is not the same as the APP-NAME header field. It MUST always contain the name of the generating software, whereas APP-NAME can contain anything else, including an operator-configured value.
"software" 매개변수는 메시지를 생성한 소프트웨어를 고유하게 식별합니다. 사용하는 경우 특정 공급업체의 소프트웨어를 식별할 수 있도록 "enterpriseId"도 지정해야 합니다. "software" 매개변수는 APP-NAME 헤더 필드와 다릅니다. 항상 생성 소프트웨어의 이름을 포함해야 하지만 APP-NAME은 운영자가 구성한 값을 포함한 다른 모든 것을 포함할 수 있습니다.
The "software" parameter is a string. It MUST NOT be longer than 48 characters.
"software" 매개변수는 문자열입니다. 48자를 넘을 수 없습니다.
### 7.2.4. swVersion
The "swVersion" parameter uniquely identifies the version of the software that generated the message. If it is used, the "software" and "enterpriseId" parameters SHOULD be provided, too.
"swVersion" 매개변수는 메시지를 생성한 소프트웨어의 버전을 고유하게 식별합니다. 사용하는 경우 "software" 및 "enterpriseId" 매개변수도 제공해야 합니다.
The "swVersion" parameter is a string. It MUST NOT be longer than 32 characters.
"swVersion" 매개변수는 문자열입니다. 32자를 넘을 수 없습니다.
### 7.2.5. Example
The following is an example with multiple IP addresses:
다음은 여러 IP 주소가 있는 예입니다.
```[origin ip="192.0.2.1" ip="192.0.2.129"]```
In this example, the originator indicates that it has two IP addresses, one being 192.0.2.1 and the other one being 192.0.2.129.
이 예에서 발신자는 두 개의 IP 주소가 있음을 나타냅니다. 하나는 192.0.2.1이고 다른 하나는 192.0.2.129입니다.
## 7.3. meta
The SD-ID "meta" MAY be used to provide meta-information about the message. The following parameters can be used. All parameters are OPTIONAL. If the "meta" SD-ID is used, at least one parameter SHOULD be specified.
SD-ID "meta"는 메시지에 대한 메타 정보를 제공하는 데 사용할 수 있습니다. 다음 매개변수를 사용할 수 있습니다. 모든 매개변수는 선택 사항입니다. "meta" SD-ID를 사용하는 경우 적어도 하나의 매개변수를 지정해야 합니다.
### 7.3.1. sequenceId
The "sequenceId" parameter tracks the sequence in which the originator submits messages to the syslog transport for sending. It is an integer that MUST be set to 1 when the syslog function is started and MUST be increased with every message up to a maximum value of 2147483647. If that value is reached, the next message MUST be sent with a sequenceId of 1.
"sequenceId" 매개변수는 발신자가 메시지를 syslog 전송에 제출하여 전송하는 순서를 추적합니다. syslog 함수가 시작될 때 1로 설정해야 하는 정수이며, 최대 2147483647까지 모든 메시지에 대해 증가해야 합니다. 해당 값에 도달하면 다음 메시지는 sequenceId가 1인 상태로 전송해야 합니다.
### 7.3.2. sysUpTime
The "sysUpTime" parameter MAY be used to include the SNMP "sysUpTime" parameter in the message. Its syntax and semantics are as defined in `[RFC3418]`.
"sysUpTime" 매개변수는 메시지에 SNMP "sysUpTime" 매개변수를 포함하는 데 사용할 수 있습니다. 구문과 의미는 `[RFC3418]`에 정의된 대로입니다.
As syslog does not support the SNMP "INTEGER" syntax directly, the value MUST be represented as a decimal integer (no decimal point) using only the characters "0", "1", "2", "3", "4", "5", "6", "7", "8", and "9".
syslog는 SNMP "INTEGER" 구문을 직접 지원하지 않으므로 값은 "0", "1", "2", "3", "4", "5", "6", "7", "8", "9" 문자만 사용하여 소수점 없는 10진수 정수로 표현해야 합니다.
Note that the semantics in RFC 3418 are "The time (in hundredths of a second) since the network management portion of the system was last re-initialized." This of course relates to the SNMP-related management portion of the system, which MAY be different than the syslog-related management portion of the system.
RFC 3418의 의미는 "시스템의 네트워크 관리 부분이 마지막으로 재초기화된 이후의 시간(1/100초)"입니다. 물론 이는 시스템의 SNMP 관련 관리 부분과 관련이 있으며, 시스템의 syslog 관련 관리 부분과 다를 수 있습니다.
### 7.3.3. language
The "language" parameter MAY be specified by the originator to convey information about the natural language used inside MSG. If it is specified, it MUST contain a language identifier as defined in BCP 47 `[RFC4646]`.
"언어" 매개변수는 MSG 내부에서 사용되는 자연어에 대한 정보를 전달하기 위해 발신자가 지정할 수 있습니다. 지정된 경우 BCP 47 `[RFC4646]`에 정의된 언어 식별자를 포함해야 합니다.
# 8. Security Considerations
## 8.1. UNICODE
This document uses UTF-8 encoding for the PARAM-VALUE and MSG fields. There are a number of security issues with UNICODE. Any implementer and operator is advised to review UNICODE TR36 `[UNICODE-TR36]` (UTR36) to learn about these issues. This document guards against the technical issues outlined in UTR36 by REQUIRING "shortest form" encoding for syslog applications. However, the visual spoofing due to character confusion still persists. This document tries to minimize the effects of visual spoofing by allowing UNICODE only where local script is expected and needed. In all other fields, US-ASCII is REQUIRED. Also, the PARAM-VALUE and MSG fields should not be the primary source for identifying information, further reducing the risks associated with visual spoofing.
이 문서에서는 PARAM-VALUE 및 MSG 필드에 UTF-8 인코딩을 사용합니다. UNICODE에는 여러 가지 보안 문제가 있습니다. 모든 구현자와 운영자는 이러한 문제에 대해 알아보기 위해 UNICODE TR36 `[UNICODE-TR36]` (UTR36)을 검토하는 것이 좋습니다. 이 문서는 syslog 애플리케이션에 "최단 형식" 인코딩을 요구함으로써 UTR36에 설명된 기술적 문제를 방지합니다. 그러나 문자 혼동으로 인한 시각적 스푸핑은 여전히 지속됩니다. 이 문서는 로컬 스크립트가 예상되고 필요한 경우에만 UNICODE를 허용하여 시각적 스푸핑의 영향을 최소화하려고 합니다. 다른 모든 필드에서는 US-ASCII가 필수입니다. 또한 PARAM-VALUE 및 MSG 필드는 정보를 식별하는 주요 소스가 되어서는 안 되며, 시각적 스푸핑과 관련된 위험을 더욱 줄여줍니다.
## 8.2. Control Characters
This document does not impose any mandatory restrictions on the MSG or PARAM-VALUE content. As such, they MAY contain control characters, including the NUL character.
이 문서는 MSG 또는 PARAM-VALUE 콘텐츠에 대한 어떠한 의무적 제한도 부과하지 않습니다. 따라서 NUL 문자를 포함한 제어 문자가 포함될 수 있습니다.
In some programming languages (most notably C and C++), the NUL character (ABNF %d00) traditionally has a special significance as string terminator. Most implementations of these languages assume that a string will not extend beyond the first NUL character. This is primarily a restriction of the supporting run-time libraries. This restriction is often carried over to programs and script languages written in those languages. As such, NUL characters must be considered with great care and be properly handled. An attackermay deliberately include NUL characters to hide information after them. Incorrect handling of the NUL character may also invalidate cryptographic checksums that are transmitted inside the message.
일부 프로그래밍 언어(특히 C 및 C++)에서 NUL 문자(ABNF %d00)는 전통적으로 문자열 종료자로 특별한 의미를 갖습니다. 이러한 언어의 대부분 구현은 문자열이 첫 번째 NUL 문자를 넘어 확장되지 않는다고 가정합니다. 이는 주로 지원하는 런타임 라이브러리의 제한 사항입니다. 이 제한 사항은 종종 해당 언어로 작성된 프로그램과 스크립트 언어로 이전됩니다. 따라서 NUL 문자는 매우 신중하게 고려하고 올바르게 처리해야 합니다. 공격자는 의도적으로 NUL 문자를 포함하여 그 뒤에 정보를 숨길 수 있습니다. NUL 문자를 잘못 처리하면 메시지 내부에서 전송되는 암호화 체크섬이 무효화될 수도 있습니다.
Many popular text editors are also written in languages with this restriction. Encoding NUL characters when writing to text files is advisable. If they are stored without encoding, the file can become unreadable.
많은 인기 있는 텍스트 편집기도 이러한 제한 사항이 있는 언어로 작성됩니다. 텍스트 파일에 쓸 때 NUL 문자를 인코딩하는 것이 좋습니다. 인코딩 없이 저장하면 파일을 읽을 수 없게 될 수 있습니다.
Other control characters may also be problematic. For example, an attacker may deliberately include backspace characters to render parts of the log message unreadable. Similar issues exist for almost all control characters.
다른 제어 문자도 문제가 될 수 있습니다. 예를 들어, 공격자는 의도적으로 백스페이스 문자를 포함하여 로그 메시지의 일부를 읽을 수 없게 만들 수 있습니다. 거의 모든 제어 문자에 유사한 문제가 있습니다.
Finally, invalid UTF-8 sequences may be used by an attacker to inject ASCII control characters.
마지막으로, 공격자는 잘못된 UTF-8 시퀀스를 사용하여 ASCII 제어 문자를 삽입할 수 있습니다.
This specification permits a syslog application to reformat control characters received. Among others, the security risks associated with control characters were an important driving force behind this restriction. Originators are advised that if any encoding other than ASCII and UTF8 are used, the receiver may corrupt the message in an attempt to filter ASCII control characters.
이 사양은 syslog 애플리케이션이 수신된 제어 문자를 다시 포맷할 수 있도록 허용합니다. 무엇보다도 제어 문자와 관련된 보안 위험은 이 제한의 중요한 원동력이었습니다. 발신자는 ASCII 및 UTF8 이외의 인코딩을 사용하는 경우 수신자가 ASCII 제어 문자를 필터링하려고 시도하여 메시지를 손상시킬 수 있다는 점에 유의해야 합니다.
## 8.3. Message Truncation
Message truncation can be misused by an attacker to hide vital log information. Messages over the minimum supported size may be discarded or truncated by the transport receiver. As such, vital log information may be lost.
공격자는 메시지 잘림을 오용하여 중요한 로그 정보를 숨길 수 있습니다. 지원되는 최소 크기를 초과하는 메시지는 전송 수신기에서 삭제되거나 잘릴 수 있습니다. 따라서 중요한 로그 정보가 손실될 수 있습니다.
In order to prevent information loss, messages should not be longer than the minimum maximum size required by Section 6.1. For best performance and reliability, messages should be as small as possible. Important information should be placed as early in the message as possible because information at the beginning of the message is less likely to be discarded by a size-limited transport receiver.
정보 손실을 방지하기 위해 메시지는 섹션 6.1에서 요구하는 최소 최대 크기보다 길어서는 안 됩니다. 최상의 성능과 안정성을 위해 메시지는 가능한 한 작아야 합니다. 중요한 정보는 가능한 한 메시지의 앞부분에 배치해야 합니다. 메시지 시작 부분에 있는 정보는 크기가 제한된 전송 수신기에서 삭제될 가능성이 낮기 때문입니다.
An originator should limit the size of any user-supplied data within a syslog message. If it does not, an attacker may provide large data in hopes of exploiting a potential weakness.
발신자는 syslog 메시지 내에서 사용자가 제공한 모든 데이터의 크기를 제한해야 합니다. 그렇지 않으면 공격자가 잠재적인 취약점을 악용하기 위해 대량의 데이터를 제공할 수 있습니다.
## 8.4. Replay
There is no mechanism in the syslog protocol to detect message replay. An attacker may record a set of messages that indicate normal activity of a machine. At a later time, that attacker may remove that machine from the network and replay the syslog messages to the relay or collector. Even with the TIMESTAMP field in the HEADER part, an attacker may record the packets and could simply modify them to reflect the current time before retransmitting them. The administrators may find nothing unusual in the received messages, and their receipt would falsely indicate normal activity of the machine.
syslog 프로토콜에는 메시지 재생을 감지하는 메커니즘이 없습니다. 공격자는 머신의 정상적인 활동을 나타내는 메시지 세트를 기록할 수 있습니다. 나중에 공격자는 해당 머신을 네트워크에서 제거하고 릴레이 또는 수집기에 syslog 메시지를 재생할 수 있습니다. HEADER 부분에 TIMESTAMP 필드가 있어도 공격자는 패킷을 기록하고 간단히 수정하여 현재 시간을 반영한 다음 다시 전송할 수 있습니다. 관리자는 수신된 메시지에서 비정상적인 것을 발견하지 못할 수 있으며, 수신 시 머신의 정상적인 활동을 잘못 나타낼 수 있습니다.
Cryptographically signing messages could prevent the alteration of TIMESTAMPs and thus the replay attack.
암호학적으로 메시지에 서명하면 TIMESTAMP 변경을 방지하고 재생 공격도 방지할 수 있습니다.
## 8.5. Reliable Delivery
Because there is no mechanism described within this document to ensure delivery, and the underlying transport may be unreliable (e.g., UDP), some messages may be lost. They may either be dropped through network congestion, or they may be maliciously intercepted and discarded. The consequences of dropping one or more syslog messages cannot be determined. If the messages are simple status updates, then their non-receipt may not be noticed or may cause an annoyance for the system operators. On the other hand, if the messages are more critical, then the administrators may not become aware of a developing and potentially serious problem. Messages may also be intercepted and discarded by an attacker as a way to hide unauthorized activities.
이 문서에는 전달을 보장하는 메커니즘이 설명되어 있지 않고 기본 전송이 신뢰할 수 없을 수 있기 때문에(예: UDP) 일부 메시지가 손실될 수 있습니다. 네트워크 혼잡으로 인해 삭제되거나 악의적으로 가로채서 삭제될 수 있습니다. 하나 이상의 syslog 메시지를 삭제하는 결과를 결정할 수 없습니다. 메시지가 간단한 상태 업데이트인 경우 수신되지 않은 것을 알아차리지 못하거나 시스템 운영자에게 성가신 일이 될 수 있습니다. 반면 메시지가 더 중요한 경우 관리자는 발생하고 잠재적으로 심각한 문제를 인식하지 못할 수 있습니다. 공격자가 무단 활동을 숨기기 위해 메시지를 가로채서 삭제할 수도 있습니다.
It may also be desirable to include rate-limiting features in syslog originators and relays. This can reduce potential congestion problems when message bursts happen.
syslog 발신자와 릴레이에 속도 제한 기능을 포함하는 것도 바람직할 수 있습니다. 이렇게 하면 메시지 버스트가 발생할 때 잠재적인 혼잡 문제를 줄일 수 있습니다.
Reliable delivery may not always be desirable. Reliable delivery means that the syslog originator or relay must block when the relay or collector is not able to accept any more messages. In some operating systems, namely Unix/Linux, the syslog originator or relay runs inside a high-priority system process (syslogd). If that process blocks, the system at large comes to a stand-still. The same occurs if there is a deadlock situation between syslogd and e.g., the DNS server.
안정적인 전달이 항상 바람직한 것은 아닙니다. 안정적인 전달은 릴레이 또는 수집기가 더 이상 메시지를 수락할 수 없을 때 syslog 발신자 또는 릴레이가 차단되어야 함을 의미합니다. 일부 운영 체제, 즉 Unix/Linux에서 syslog 발신자 또는 릴레이는 우선순위가 높은 시스템 프로세스(syslogd) 내부에서 실행됩니다. 해당 프로세스가 차단되면 전체 시스템이 정지됩니다. syslogd와 예를 들어 DNS 서버 사이에 교착 상태가 있는 경우에도 마찬가지입니다.
To prevent these problems, reliable delivery can be implemented in a way that intentionally discards messages when the syslog application would otherwise block. The advantage of reliable delivery in this case is that the syslog originator or relay knowingly discards the message and is able to notify the relay or collector about that fact. So the relay or collector receives the information that something is lost. With unreliable delivery, the message would simply be lost without any indication that loss occurred.
이러한 문제를 방지하기 위해 syslog 애플리케이션이 차단될 때 의도적으로 메시지를 삭제하는 방식으로 안정적인 전달을 구현할 수 있습니다. 이 경우 안정적인 전달의 장점은 syslog 발신자 또는 릴레이가 의도적으로 메시지를 삭제하고 릴레이 또는 수집기에 그 사실을 알릴 수 있다는 것입니다. 따라서 릴레이 또는 수집기는 무언가가 손실되었다는 정보를 받습니다. 신뢰할 수 없는 전달의 경우 손실이 발생했다는 표시 없이 메시지가 손실됩니다.
## 8.6. Congestion Control
Because syslog can generate unlimited amounts of data, transferring this data over UDP is generally problematic, because UDP lacks congestion control mechanisms. Congestion control mechanisms that respond to congestion by reducing traffic rates and establish a degree of fairness between flows that share the same path are vital to the stable operation of the Internet `[RFC2914]`. This is why the syslog TLS transport is REQUIRED to implement and RECOMMENDED for general use.
syslog는 무제한의 데이터를 생성할 수 있기 때문에 UDP를 통해 이 데이터를 전송하는 것은 일반적으로 문제가 됩니다. UDP에는 혼잡 제어 메커니즘이 없기 때문입니다. 혼잡에 대응하여 트래픽 속도를 줄이고 동일한 경로를 공유하는 흐름 간에 일정 수준의 공평성을 확립하는 혼잡 제어 메커니즘은 인터넷의 안정적인 운영에 필수적입니다`[RFC2914]`. 이것이 Syslog TLS 전송이 구현되어야 하고 일반적인 용도로 권장되는 이유입니다.
The only environments where the syslog UDP transport MAY be used as an alternative to the TLS transport are managed networks, where the network path has been explicitly provisioned for UDP syslog traffic through traffic engineering mechanisms, such as rate limiting or capacity reservations. In all other environments, the TLS transport SHOULD be used.
syslog UDP 전송을 TLS 전송의 대안으로 사용할 수 있는 유일한 환경은 관리되는 네트워크로, 네트워크 경로가 속도 제한 또는 용량 예약과 같은 트래픽 엔지니어링 메커니즘을 통해 UDP Syslog 트래픽에 대해 명시적으로 프로비저닝된 경우입니다. 다른 모든 환경에서는 TLS 전송을 사용해야 합니다.
In any implementation, the situation may arise in which an originator or relay would need to block sending messages. A common case is when an internal queue is full. This might happen due to rate-limiting or slow performance of the syslog application. In any event, it is highly RECOMMENDED that no messages be dropped but that they should be temporarily stored until they can be transmitted. However, if they must be dropped, it is RECOMMENDED that the originator or relay drop messages of lower severity in favor of higher severity messages.
모든 구현에서 발신자 또는 릴레이가 메시지 전송을 차단해야 하는 상황이 발생할 수 있습니다. 일반적인 경우는 내부 대기열이 가득 찬 경우입니다. 이는 Syslog 애플리케이션의 속도 제한 또는 성능 저하로 인해 발생할 수 있습니다. 어떤 경우에도 메시지를 삭제하지 말고 전송할 수 있을 때까지 일시적으로 저장하는 것이 좋습니다. 그러나 삭제해야 하는 경우 발신자 또는 릴레이가 심각도가 낮은 메시지를 삭제하고 심각도가 높은 메시지를 삭제하는 것이 좋습니다.
Messages with a lower numerical SEVERITY value have a higher practical severity than those with a numerically higher value. In that situation, the messages that are to be dropped SHOULD simply be discarded. The syslog application may notify a collector or relay about the fact that it has dropped messages.
숫자로 표시된 SEVERITY 값이 낮은 메시지는 숫자로 표시된 SEVERITY 값이 높은 메시지보다 실제 심각도가 높습니다. 이 경우 삭제할 메시지를 그냥 삭제해야 합니다. syslog 애플리케이션은 수집기 또는 릴레이에 메시지를 삭제했다는 사실을 알릴 수 있습니다.
## 8.7. Message Integrity
Besides being discarded, syslog messages may be damaged in transit, or an attacker may maliciously modify them. In such cases, the original contents of the message will not be delivered to the collector or relay. Additionally, if an attacker is positioned between the transport sender and transport receiver of syslog messages, they may be able to intercept and modify those messages while in-transit to hide unauthorized activities.
syslog 메시지는 삭제될 뿐만 아니라 전송 중에 손상되거나 공격자가 악의적으로 수정할 수 있습니다. 이러한 경우 메시지의 원래 내용은 수집기 또는 릴레이에 전달되지 않습니다. 또한 공격자가 syslog 메시지의 전송 발신자와 전송 수신자 사이에 위치하는 경우 전송 중에 해당 메시지를 가로채서 수정하여 무단 활동을 숨길 수 있습니다.
## 8.8. Message Observation
While there are no strict guidelines pertaining to the MSG format,most syslog messages are generated in human-readable form with the assumption that capable administrators should be able to read them and understand their meaning. The syslog protocol does not have mechanisms to provide confidentiality for the messages in transit. In most cases, passing clear-text messages is a benefit to the operations staff if they are sniffing the packets from the wire. The operations staff may be able to read the messages and associate them with other events seen from other packets crossing the wire to track down and correct problems. Unfortunately, an attacker may also be able to observe the human-readable contents of syslog messages. The attacker may then use the knowledge gained from those messages to compromise a machine or do other damage.
MSG 형식과 관련된 엄격한 지침은 없지만 대부분의 syslog 메시지는 유능한 관리자가 메시지를 읽고 의미를 이해할 수 있어야 한다는 가정 하에 사람이 읽을 수 있는 형태로 생성됩니다. syslog 프로토콜에는 전송 중인 메시지에 대한 기밀성을 제공하는 메커니즘이 없습니다. 대부분의 경우, 운영 직원이 전선에서 패킷을 스니핑하는 경우 일반 텍스트 메시지를 전달하는 것이 이점이 됩니다. 운영 직원은 메시지를 읽고 전선을 통과하는 다른 패킷에서 본 다른 이벤트와 연결하여 문제를 추적하고 수정할 수 있습니다. 불행히도 공격자는 syslog 메시지의 사람이 읽을 수 있는 내용을 관찰할 수도 있습니다. 그런 다음 공격자는 해당 메시지에서 얻은 지식을 사용하여 기계를 손상시키거나 다른 손상을 입힐 수 있습니다.
Operators are advised to use a secure transport mapping to avoid this problem.
운영자는 이 문제를 피하기 위해 안전한 전송 매핑을 사용하는 것이 좋습니다.
## 8.9. Inappropriate Configuration
Because there is no control information distributed about any messages or configurations, it is wholly the responsibility of the network administrator to ensure that the messages are actually going to the intended recipients. Cases have been noted where syslog applications were inadvertently configured to send syslog messages to the wrong relays or collectors. In many cases, the inadvertent relays or collectors may not be configured to receive syslog messages and will probably discard them. In certain other cases, the receipt of syslog messages has been known to cause problems for the unintended recipient. If messages are not going to the intended recipient, then they cannot be reviewed or processed.
메시지나 구성에 대한 제어 정보가 배포되지 않기 때문에 메시지가 실제로 의도한 수신자에게 전송되는지 확인하는 것은 전적으로 네트워크 관리자의 책임입니다. syslog 애플리케이션이 실수로 syslog 메시지를 잘못된 릴레이나 수집기로 보내도록 구성된 사례가 발견되었습니다. 많은 경우 실수로 구성된 릴레이나 수집기는 syslog 메시지를 수신하도록 구성되지 않았을 수 있으며 아마도 메시지를 삭제할 것입니다. 다른 특정한 경우 syslog 메시지를 수신하면 의도하지 않은 수신자에게 문제가 발생하는 것으로 알려져 있습니다. 메시지가 의도한 수신자에게 전송되지 않으면 검토하거나 처리할 수 없습니다.
Using a reliable transport mapping can help identify some of these problems. For example, it can identify a problem where a message is being sent to a system that is not configured to receive messages. It cannot identify sending messages to a wrong machine that is accepting messages.
안정적인 전송 매핑을 사용하면 이러한 문제 중 일부를 식별하는 데 도움이 될 수 있습니다. 예를 들어 메시지를 수신하도록 구성되지 않은 시스템으로 메시지가 전송되는 문제를 식별할 수 있습니다. 메시지를 수신하는 잘못된 시스템으로 메시지를 보내는 것은 식별할 수 없습니다.
## 8.10. Forwarding Loop
As shown in Diagram 2, machines may be configured to relay syslog messages to subsequent relays before reaching a collector. In one particular case, an administrator found that he had mistakenly configured two relays to forward messages with certain SEVERITY values to each other. When either of these machines either received or generated that type of message, it would forward it to the other relay. That relay would, in turn, forward it back. This cycle did cause degradation to the intervening network as well as to the processing availability on the two devices. Network administrators must take care not to cause such a death spiral.
다이어그램 2에 표시된 대로, 머신은 수집기에 도달하기 전에 후속 릴레이에 syslog 메시지를 전달하도록 구성될 수 있습니다. 한 가지 특정한 사례에서, 관리자는 특정 SEVERITY 값이 있는 메시지를 서로 전달하도록 두 개의 릴레이를 실수로 구성했다는 것을 발견했습니다. 이 머신 중 하나가 해당 유형의 메시지를 수신하거나 생성하면 다른 릴레이로 전달합니다. 그러면 해당 릴레이가 다시 전달합니다. 이 사이클은 두 장치의 처리 가용성과 중재 네트워크의 저하를 초래했습니다. 네트워크 관리자는 이러한 죽음의 나선을 일으키지 않도록 주의해야 합니다.
## 8.11. Load Considerations
Network administrators must take the time to estimate the appropriate capacity of the syslog collector. An attacker may perform a Denial of Service attack by filling the disk of the collector with false messages. Placing the records in a circular file may alleviate this but has the consequence of not ensuring that an administrator will be able to review the records in the future. Along this line, a transport receiver must have a network interface capable of receiving the messages sent to it.
네트워크 관리자는 syslog 수집기의 적절한 용량을 추정하는 데 시간을 할애해야 합니다. 공격자는 수집기의 디스크를 거짓 메시지로 채워 서비스 거부 공격을 수행할 수 있습니다. 레코드를 순환 파일에 배치하면 이를 완화할 수 있지만 관리자가 나중에 레코드를 검토할 수 없다는 결과가 발생합니다. 이와 관련하여 전송 수신기는 전송된 메시지를 수신할 수 있는 네트워크 인터페이스를 가져야 합니다.
Administrators and network planners must also critically review the network paths between the originators, the relays, and the collectors. Generated syslog messages should not overwhelm any of the network links.
관리자와 네트워크 계획자는 또한 발신자, 릴레이 및 수집자 간의 네트워크 경로를 비판적으로 검토해야 합니다. 생성된 syslog 메시지는 네트워크 링크를 압도해서는 안 됩니다.
In order to reduce the impact of this issue, using transports with guaranteed delivery is recommended.
이 문제의 영향을 줄이려면 보장된 전달이 있는 전송을 사용하는 것이 좋습니다.
## 8.12. Denial of Service
As with any system, an attacker may just overwhelm a transport receiver by sending more messages to it than can be handled by the infrastructure or the device itself. Implementers should attempt to provide features that minimize this threat, such as only accepting syslog messages from known IP addresses.
모든 시스템에서 공격자는 인프라나 장치 자체에서 처리할 수 있는 것보다 많은 메시지를 전송하여 전송 수신기를 압도할 수 있습니다. 구현자는 알려진 IP 주소에서만 syslog 메시지를 허용하는 것과 같이 이 위협을 최소화하는 기능을 제공해야 합니다.
# 9. IANA Considerations
## 9.1. VERSION
IANA has created a registry entitled "syslog Version Values" of VERSION values as described in Section 6.2.2. Version numbers MUST be incremented for any new syslog protocol specification that changes any part of the HEADER. Changes include addition or removal of fields or a change of syntax or semantics of existing fields.
IANA는 섹션 6.2.2에 설명된 대로 VERSION 값의 "syslog 버전 값"이라는 레지스트리를 만들었습니다. 버전 번호는 HEADER의 어떤 부분이든 변경하는 모든 새로운 syslog 프로토콜 사양에 대해 증가해야 합니다. 변경 사항에는 필드 추가 또는 제거 또는 기존 필드의 구문 또는 의미 변경이 포함됩니다.
VERSION numbers must be registered via the Standards Action method as described in `[RFC5226]`. IANA has registered the VERSIONs shown in Table 3 below.
VERSION 번호는 `[RFC5226]`에 설명된 대로 표준 조치 방법을 통해 등록해야 합니다. IANA는 아래 표 3에 표시된 VERSION을 등록했습니다.
```
VERSION FORMAT
1 Defined in [RFC5424]
```
Table 3. IANA-Registered VERSIONs
## 9.2. SD-IDs
IANA has created a registry entitled "syslog Structured Data ID Values" of Structured Data ID (SD-ID) values together with their associated PARAM-NAME values as described in Section 7.
IANA는 섹션 7에 설명된 대로 구조화된 데이터 ID(SD-ID) 값과 연관된 PARAM-NAME 값의 "syslog 구조화된 데이터 ID 값"이라는 레지스트리를 만들었습니다.
New SD-ID and new PARAM-NAME values must be registered through the IETF Review method as described in `[RFC5226]`.
새로운 SD-ID와 새로운 PARAM-NAME 값은 `[RFC5226]`에 설명된 대로 IETF 검토 방법을 통해 등록해야 합니다.
Once SD-IDs and SD-PARAMs are defined, syntax and semantics of these objects MUST NOT be altered. Should a change to an existing object be desired, a new SD-ID or SD-PARAM MUST be created and the old one remain unchanged.
SD-ID와 SD-PARAM이 정의되면 이러한 객체의 구문과 의미는 변경해서는 안 됩니다. 기존 객체를 변경해야 하는 경우 새 SD-ID 또는 SD-PARAM을 만들어야 하며 이전 객체는 변경하지 않아야 합니다.
A provision is made here for locally extensible names. The IANA will not register, and will not control names with the at-sign (ABNF %d64) in them.
여기에는 로컬 확장 가능한 이름에 대한 조항이 있습니다. IANA는 등록하지 않으며, at 기호(ABNF %d64)가 있는 이름을 제어하지 않습니다.
IANA has registered the SD-IDs and PARAM-NAMEs shown in Table 4 below.
IANA는 아래 표 4에 표시된 SD-ID와 PARAM-NAME을 등록했습니다.
```
SD-ID PARAM-NAME
timeQuality OPTIONAL
tzKnown OPTIONAL
isSynced OPTIONAL
syncAccuracy OPTIONAL
origin OPTIONAL
ip OPTIONAL
enterpriseId OPTIONAL
software OPTIONAL
swVersion OPTIONAL
meta OPTIONAL
sequenceId OPTIONAL
sysUpTime OPTIONAL
language OPTIONAL
```
Table 4. IANA-Registered SD-IDs and their PARAM-NAMEs
# 10. Working Group
The working group can be contacted via the mailing list:
작업 그룹은 메일링 목록을 통해 연락할 수 있습니다.
```
syslog@ietf.org
```
The current Chairs of the Working Group may be contacted at:
작업 그룹의 현재 의장은 다음 주소로 연락할 수 있습니다.
```
Chris Lonvick
Cisco Systems
EMail: clonvick@cisco.com
David Harrington
Huawei Technologies USA
EMail: dbharrington@comcast.net
```
# 11. Acknowledgments
The authors wish to thank Chris Lonvick, Jon Callas, Andrew Ross, Albert Mietus, Anton Okmianski, Tina Bird, Devin Kowatch, David Harrington, Sharon Chisholm, Richard Graveman, Tom Petch, Dado Colussi, Clement Mathieu, Didier Dalmasso, and all the other people who commented on various versions of this proposal.
저자는 Chris Lonvick, Jon Callas, Andrew Ross, Albert Mietus, Anton Okmianski, Tina Bird, Devin Kowatch, David Harrington, Sharon Chisholm, Richard Graveman, Tom Petch, Dado Colussi, Clement Mathieu, Didier Dalmasso 및 이 제안의 다양한 버전에 대해 의견을 제시한 다른 모든 사람들에게 감사드리고자 합니다.
# 12. References
## 12.1. Normative References
```
[ANSI.X3-4.1968] American National Standards Institute, "USA Code
for Information Interchange", ANSI X3.4, 1968.
[RFC1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578,
April 1999.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, September 2000.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002.
[RFC3418] Presuhn, R., "Management Information Base (MIB) for
the Simple Network Management Protocol (SNMP)",
STD 62, RFC 3418, December 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 4646, September 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 5226, May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234,
January 2008.
[RFC5425] Fuyou, M., Yuzhi, M., and J. Salowey, "TLS
Transport Mapping for Syslog", RFC 5425, March
2009.
[RFC5426] Okmianski, A., "Transmission of Syslog Messages
over UDP", RFC 5426, March 2009.
[UNICODE-TR36] Davis, M. and M. Suignard, "UNICODE Security
Considerations", July 2005.
```
## 12.2. Informative References
```
[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
August 2001.
```
# Appendix A. Implementer Guidelines
Information in this section is given as an aid to implementers. While this information is considered to be helpful, it is not normative. As such, an implementation is NOT REQUIRED to follow it in order to claim compliance to this specification.
이 섹션의 정보는 구현자를 돕기 위해 제공됩니다. 이 정보는 도움이 되는 것으로 간주되지만 규범적이지 않습니다. 따라서 구현이 이 사양을 준수한다고 주장하기 위해 이를 따를 필요는 없습니다.
## A.1. Relationship with BSD Syslog
While BSD syslog is in widespread use, its format has never been formally standardized. `[RFC3164]` describes observed formats. It is an Informational RFC, and practice shows that there are many different implementations. Research during creation of this document showed that there is very little in common between different syslog implementations on different platforms. The only thing that all of them agree upon is that messages start with` "<" PRIVAL ">"`. Other than that, legacy syslog messages are not formatted in a consistent way. Consequently, RFC 3164 describes no specific elements inside a syslog message. It states that any message destined to the syslog UDP port must be treated as a syslog message, no matter what its format or content is.
BSD syslog는 널리 사용되고 있지만 형식은 공식적으로 표준화된 적이 없습니다. `[RFC3164]`는 관찰된 형식을 설명합니다. 정보 RFC이며 실제로는 다양한 구현이 있음을 보여줍니다. 이 문서를 작성하는 동안의 조사에 따르면 서로 다른 플랫폼의 서로 다른 syslog 구현 간에 공통점이 거의 없습니다. 모든 구현이 동의하는 유일한 사항은 메시지가 `"<" PRIVAL ">`"로 시작한다는 것입니다. 그 외에 레거시 syslog 메시지는 일관된 방식으로 형식이 지정되지 않습니다. 결과적으로 RFC 3164는 syslog 메시지 내부의 특정 요소를 설명하지 않습니다. syslog UDP 포트로 전송되는 모든 메시지는 형식이나 내용에 관계없이 syslog 메시지로 처리해야 한다고 명시되어 있습니다.
This document retains the PRI value syntax and semantics. This will allow legacy syslog implementations to put messages generated by syslog applications compliant to this specification into the right bins.
이 문서는 PRI 값 구문과 의미 체계를 유지합니다. 이를 통해 레거시 syslog 구현에서 이 사양을 준수하는 syslog 애플리케이션에서 생성된 메시지를 올바른 빈에 넣을 수 있습니다.
Most existing implementations support UDP as the transport protocol for syslog. This specification supports UDP transport, but does not recommend it. Deployment of the required TLS support is recommended. Additional transport protocols may be used.
대부분의 기존 구현은 syslog의 전송 프로토콜로 UDP를 지원합니다. 이 사양은 UDP 전송을 지원하지만 권장하지는 않습니다. 필요한 TLS 지원의 배포가 권장됩니다. 추가 전송 프로토콜을 사용할 수 있습니다.
RFC 3164 describes relay behavior. This document does not specify relay behavior. This might be done in a separate document.
RFC 3164는 릴레이 동작을 설명합니다. 이 문서는 릴레이 동작을 지정하지 않습니다. 이는 별도의 문서에서 수행될 수 있습니다.
The TIMESTAMP described in RFC 3164 offers less precision than the timestamp specified in this document. It also lacks the year and time zone information. If a message formatted according to this document needs to be reformatted to be in RFC 3164 format, it is suggested that the originator's local time zone be used, and the time zone information and the year be dropped. If an RFC 3164 formatted message is received and must be transformed to be compliant to this document, the current year should be added and the time zone of the relay or collector MAY be used.
RFC 3164에 설명된 TIMESTAMP는 이 문서에 지정된 타임스탬프보다 정확도가 낮습니다. 또한 연도 및 시간대 정보가 없습니다. 이 문서에 따라 포맷된 메시지를 RFC 3164 포맷으로 재포맷해야 하는 경우, 발신자의 로컬 시간대를 사용하고 시간대 정보와 연도를 삭제하는 것이 좋습니다. RFC 3164 포맷의 메시지를 수신하여 이 문서를 준수하도록 변환해야 하는 경우, 현재 연도를 추가해야 하며 릴레이 또는 수집기의 시간대를 사용할 수 있습니다.
The HOSTNAME in RFC 3164 is less specific, but this format is still supported in this document as one of the alternate HOSTNAME representations.
RFC 3164의 HOSTNAME은 덜 구체적이지만, 이 포맷은 이 문서에서 대체 HOSTNAME 표현 중 하나로 여전히 지원됩니다.
The MSG part of the message is described as TAG and CONTENT in RFC 3164. In this document, MSG is what was called CONTENT in RFC 3164. The TAG is now part of the header, but not as a single field. The TAG has been split into APP-NAME, PROCID, and MSGID. This does not totally resemble the usage of TAG, but provides the same functionality for most of the cases.
메시지의 MSG 부분은 RFC 3164에서 TAG와 CONTENT로 설명됩니다. 이 문서에서 MSG는 RFC 3164에서 CONTENT라고 불렸던 것입니다. TAG는 이제 헤더의 일부이지만 단일 필드는 아닙니다. TAG는 APP-NAME, PROCID 및 MSGID로 분할되었습니다. 이것은 TAG의 사용과 완전히 유사하지는 않지만 대부분의 경우에 동일한 기능을 제공합니다.
In RFC 3164, STRUCTURED-DATA was not described. If a message compliant with this document contains STRUCTURED-DATA and must be reformatted according to RFC 3164, the STRUCTURED-DATA simply becomes part of the RFC 3164 CONTENT free-form text.
RFC 3164에서는 STRUCTURED-DATA가 설명되지 않았습니다. 이 문서를 준수하는 메시지에 STRUCTURED-DATA가 포함되어 있고 RFC 3164에 따라 다시 포맷해야 하는 경우 STRUCTURED-DATA는 단순히 RFC 3164 CONTENT 자유 형식 텍스트의 일부가 됩니다.
In general, this document tries to provide an easily parseable header with clear field separations, whereas traditional BSD syslog suffers from some historically developed, hard to parse field separation rules.
일반적으로 이 문서는 명확한 필드 분리를 사용하여 쉽게 구문 분석할 수 있는 헤더를 제공하려고 하는 반면, 기존 BSD syslog는 역사적으로 개발되어 구문 분석하기 어려운 필드 분리 규칙이 있습니다.
## A.2. Message Length
Implementers should note the message size limitations outlined in Section 6.1 and try to keep the most important data early in the message (within the minimum guaranteed length). This ensures the data will be seen by the collector or relay even if a transport receiver at a relay on the message path truncates the message.
구현자는 섹션 6.1에 설명된 메시지 크기 제한을 유의하고 가장 중요한 데이터를 메시지의 앞부분(최소 보장 길이 내)에 유지해야 합니다. 이렇게 하면 메시지 경로의 릴레이에 있는 전송 수신기가 메시지를 잘라내더라도 수집기 또는 릴레이에서 데이터를 볼 수 있습니다.
The reason syslog transport receivers need only support receiving up to and including 480 octets has, among other things, to do with difficult delivery problems in a broken network. Syslog messages may use a UDP transport mapping with this 480 octet restriction to avoid session overhead and message fragmentation. In a network with problems, the likelihood of getting one single-packet message delivered successfully is higher than getting two message fragments delivered successfully. Therefore, using a larger size may prevent the operator from getting some critical information about the problem, whereas using small messages might get that information to the operator. It is recommended that messages intended for troubleshooting purposes should not be larger than 480 octets. To further strengthen this point, it has also been observed that some UDP implementations generally do not support message sizes of more than 480 octets. This behavior is very rare and may no longer be an issue.
syslog 전송 수신기가 최대 480옥텟까지만 수신하면 되는 이유는 무엇보다도 끊어진 네트워크에서 어려운 전달 문제와 관련이 있습니다. syslog 메시지는 세션 오버헤드와 메시지 조각화를 피하기 위해 이 480옥텟 제한이 있는 UDP 전송 매핑을 사용할 수 있습니다. 문제가 있는 네트워크에서 하나의 단일 패킷 메시지를 성공적으로 전달할 가능성은 두 개의 메시지 조각이 성공적으로 전달될 가능성보다 높습니다. 따라서 더 큰 크기를 사용하면 운영자가 문제에 대한 중요한 정보를 얻지 못할 수 있지만 작은 메시지를 사용하면 해당 정보를 운영자에게 전달할 수 있습니다. 문제 해결 목적으로 의도된 메시지는 480옥텟보다 크지 않아야 합니다. 이 점을 더욱 강화하기 위해 일부 UDP 구현은 일반적으로 480옥텟을 초과하는 메시지 크기를 지원하지 않는다는 사실도 관찰되었습니다. 이러한 동작은 매우 드물며 더 이상 문제가 되지 않을 수 있습니다.
There are other use cases where syslog messages are used to transmit inherently lengthy information, e.g., audit data. By not enforcing any upper limit on the message size, syslog applications can be implemented with any size needed and still be compliant with this document. In such cases, it is the operator's responsibility to ensure that all components in a syslog infrastructure support the required message sizes. Transport mappings may recommend specific message size limits that must be implemented to be compliant.
syslog 메시지를 사용하여 본질적으로 긴 정보(예: 감사 데이터)를 전송하는 다른 사용 사례가 있습니다. 메시지 크기에 대한 상한을 적용하지 않으면 syslog 애플리케이션을 필요한 크기로 구현할 수 있으며 이 문서를 준수할 수 있습니다. 이러한 경우 syslog 인프라의 모든 구성 요소가 필요한 메시지 크기를 지원하는지 확인하는 것은 운영자의 책임입니다. 전송 매핑은 준수를 위해 구현해야 하는 특정 메시지 크기 제한을 권장할 수 있습니다.
Implementers are reminded that the message length is specified in octets. There is a potentially large difference between the length in characters and the length in octets for UTF-8 strings.
구현자는 메시지 길이가 옥텟으로 지정된다는 점을 상기해야 합니다. UTF-8 문자열의 경우 문자 길이와 옥텟 길이 사이에는 잠재적으로 큰 차이가 있습니다.
It must be noted that the IPv6 MTU is about 2.5 times 480. An implementation targeted towards an IPv6-only environment might thus assume this as a larger minimum size.
IPv6 MTU는 약 480의 2.5배라는 점에 유의해야 합니다. 따라서 IPv6 전용 환경을 대상으로 하는 구현은 이를 더 큰 최소 크기로 가정할 수 있습니다.
## A.3. Severity Values
This section describes guidelines for using Severity as outlined in Section 6.2.1.
이 섹션에서는 섹션 6.2.1에 설명된 대로 심각도를 사용하기 위한 지침을 설명합니다.
All implementations should try to assign the most appropriate severity to their message. Most importantly, messages designed to enable debugging or testing of software should be assigned Severity 7. Severity 0 should be reserved for messages of very high importance (like serious hardware failures or imminent power failure). An implementation may use Severities 0 and 7 for other purposes if this is configured by the administrator.
모든 구현은 메시지에 가장 적절한 심각도를 지정해야 합니다. 가장 중요한 것은 소프트웨어 디버깅이나 테스트를 가능하게 하도록 설계된 메시지에 심각도 7을 지정해야 한다는 것입니다. 심각도 0은 매우 중요한 메시지(심각한 하드웨어 오류나 임박한 정전 등)에 예약해야 합니다. 구현은 관리자가 구성한 경우 심각도 0과 7을 다른 용도로 사용할 수 있습니다.
Because severities are very subjective, a relay or collector should not assume that all originators have the same definition of severity.
심각도는 매우 주관적이므로 릴레이 또는 수집기는 모든 발신자가 동일한 심각도 정의를 가지고 있다고 가정해서는 안 됩니다.
## A.4. TIME-SECFRAC Precision
The TIMESTAMP described in Section 6.2.3 supports fractional seconds. This provides grounds for a very common coding error, where leading zeros are removed from the fractional seconds. For example, the TIMESTAMP `"2003-10-11T22:13:14.003"` may be erroneously written as `"2003-10-11T22:13:14.3"`. This would indicate 300 milliseconds instead of the 3 milliseconds actually meant.
섹션 6.2.3에 설명된 TIMESTAMP는 소수 초를 지원합니다. 이는 소수 초에서 선행 0이 제거되는 매우 일반적인 코딩 오류의 근거를 제공합니다. 예를 들어, TIMESTAMP `"2003-10-11T22:13:14.003"`은 `"2003-10-11T22:13:14.3"`으로 잘못 작성될 수 있습니다. 이는 실제로 의미하는 3밀리초 대신 300밀리초를 나타냅니다.
## A.5. Case Convention for Names
Names are used at various places in this document, for example for SD-IDs and PARAM-NAMEs. This document uses `"lower camel case"` consistently. With that, each name begins with a lower case letter and each new embedded word starts with an upper case letter, with no hyphen or other delimiter. An example of this is `"timeQuality"`.
이 문서의 다양한 곳에서 이름이 사용됩니다(예: SD-ID 및 PARAM-NAME). 이 문서에서는 일관되게 `"lower camel case"`를 사용합니다. 이에 따라 각 이름은 소문자로 시작하고 각 새 임베디드 단어는 하이픈이나 다른 구분 기호 없이 대문자로 시작합니다. 이에 대한 예는 `"timeQuality"`입니다.
While an implementation is free to use any other case convention for experimental names, it is suggested that the case convention outlined above is followed.
구현은 실험적 이름에 대해 다른 대소문자 규칙을 자유롭게 사용할 수 있지만 위에 설명된 대소문자 규칙을 따르는 것이 좋습니다.
## A.6. Syslog Applications Without Knowledge of Time
In Section 6.2.3, the NILVALUE has been allowed for usage by originators without knowledge of time. This is done to support a special case when a syslog application is not aware of time at all. It can be argued whether such a syslog application can actually be found in today's IT infrastructure. However, discussion has indicated that those things may exist in practice and as such there should be a guideline established for this case.
6.2.3절에서 NILVALUE는 시간 지식이 없는 발신자가 사용하도록 허용되었습니다. 이는 Syslog 애플리케이션이 시간을 전혀 알지 못하는 특수한 경우를 지원하기 위해 수행됩니다. 그러한 Syslog 애플리케이션이 오늘날의 IT 인프라에서 실제로 발견될 수 있는지에 대해서는 논쟁의 여지가 있습니다. 그러나 논의 결과 실제로 그러한 것이 존재할 수 있으며 따라서 이 경우에 대한 지침이 수립되어야 한다는 것이 나타났습니다.
However, an implementation SHOULD emit a valid TIMESTAMP if the underlying operating system, programming system, and hardware supports a clock function. A proper TIMESTAMP should be emitted even if it is difficult to obtain the system time. The NILVALUE should only be used when it is actually impossible to obtain time information. This rule should not be used as an excuse for lazy implementations.
그러나 기본 운영 체제, 프로그래밍 시스템 및 하드웨어가 시계 기능을 지원하는 경우 구현은 유효한 TIMESTAMP를 방출해야 합니다. 시스템 시간을 얻기 어렵더라도 적절한 TIMESTAMP를 방출해야 합니다. NILVALUE는 시간 정보를 얻는 것이 실제로 불가능한 경우에만 사용해야 합니다. 이 규칙은 게으른 구현에 대한 변명으로 사용되어서는 안 됩니다.
## A.7. Notes on the timeQuality SD-ID
It is recommended that the value of "0" be the default for the "tzKnown" (Section 7.1.1) parameter. It should only be changed to "1" after the administrator has specifically configured the time zone. The value "1" may be used as the default if the underlying operating system provides accurate time zone information. It is still advised that the administrator consider the correctness of the time zone information.
"tzKnown"(섹션 7.1.1) 매개변수의 기본값은 "0"인 것이 좋습니다. 관리자가 시간대를 구체적으로 구성한 후에만 "1"로 변경해야 합니다. 기본 운영 체제가 정확한 시간대 정보를 제공하는 경우 기본값으로 "1" 값을 사용할 수 있습니다. 그래도 관리자는 시간대 정보의 정확성을 고려하는 것이 좋습니다.
It is important not to create a false impression of accuracy with the timeQuality SD-ID (Section 7.1). An originator should only indicate a given accuracy if it actually knows it is within these bounds. It is generally assumed that the originator gains this in-depth knowledge through operator configuration. By default, an accuracy should not be provided.
timeQuality SD-ID(섹션 7.1)로 정확성에 대한 잘못된 인상을 주지 않는 것이 중요합니다. 발신자는 실제로 이러한 범위 내에 있음을 알고 있는 경우에만 주어진 정확도를 표시해야 합니다. 일반적으로 발신자는 운영자 구성을 통해 이러한 심층적인 지식을 얻는다고 가정합니다. 기본적으로 정확도는 제공되지 않아야 합니다.
## A.8. UTF-8 Encoding and the BOM
This document specifies that SD-PARAMS must always be encoded in UTF-8. Other encodings of the message in the MSG portion, including ASCIIPRINT, are not permitted by a device conforming to this specification. There are two cases that need to be addressed here. First, a syslog application conforming to this specification may not be able to ascertain that the information given to it from an originator is encoded in UTF-8. If it cannot determine that with certainty, the syslog application may choose to not incorporate the BOM in the MSG. If the syslog application has a good indication that the content of the message is encoded in UTF-8, then it should include the BOM. In the second case, a syslog relay may be forwarding a message from a device that does not conform to this specification. In that case, the device would likely not include the BOM unless it has ascertained that the received message was encoded in UTF-8.
이 문서에서는 SD-PARAMS가 항상 UTF-8로 인코딩되어야 한다고 명시합니다. ASCIIPRINT를 포함하여 MSG 부분의 메시지에 대한 다른 인코딩은 이 사양을 준수하는 장치에서 허용되지 않습니다. 여기서 다루어야 할 두 가지 사례가 있습니다. 첫째, 이 사양을 준수하는 syslog 애플리케이션은 발신자로부터 제공된 정보가 UTF-8로 인코딩되었는지 확인할 수 없습니다. 이를 확실하게 확인할 수 없는 경우 syslog 애플리케이션은 MSG에 BOM을 통합하지 않기로 선택할 수 있습니다. syslog 애플리케이션에서 메시지 내용이 UTF-8로 인코딩되었다는 확실한 표시가 있는 경우 BOM을 포함해야 합니다. 두 번째 사례에서 syslog 릴레이는 이 사양을 준수하지 않는 장치에서 메시지를 전달할 수 있습니다. 이 경우 장치는 수신된 메시지가 UTF-8로 인코딩되었다는 것을 확인하지 않는 한 BOM을 포함하지 않을 가능성이 큽니다.
```
Author's Address
Rainer Gerhards
Adiscon GmbH
Mozartstrasse 21
Grossrinderfeld, BW 97950
Germany
EMail: rgerhards@adiscon.com
```