Technical Summary
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.
This document has been written with the anticipated original design
goals for traditional syslog in mind. The reason 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.
This ballot also includes the UDP transport for syslog. This
transport is similar to that used across the internet today.
Working Group Summary
The working group had consensus to publish these documents as a
proposed standard.
Protocol Quality
This document has been reviewed by Sam Hartman for the IESG.
Note to RFC Editor
The protocol draft obsoletes RFC 3164
In the protocol draft section 6.4:
old: If a syslog application is processing a MSG starting with a BOM,
if
it contains UTF-8 that is not shortest form it 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.
new:
If a syslog application is processing a MSG starting with a BOM, if
it contains UTF-8 that is not shortest form it MUST be discarded for
the reasons outlined in
[UNICODE-TR36], section 3.1. Guidance about this is given in
Appendix A.8.