idnits 2.17.1 draft-ietf-syslog-protocol-23.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1753. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1764. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1771. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1777. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 5, 2007) is 6040 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 4646 (Obsoleted by RFC 5646) -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE-TR36' == Outdated reference: A later version (-12) exists of draft-ietf-syslog-transport-udp-10 == Outdated reference: A later version (-14) exists of draft-ietf-syslog-transport-tls-10 -- Obsolete informational reference (is this intentional?): RFC 3164 (Obsoleted by RFC 5424) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 syslog Working Group R. Gerhards 3 Internet-Draft Adiscon GmbH 4 Obsoletes: 3164 (if approved) September 5, 2007 5 Intended status: Standards Track 6 Expires: March 8, 2008 8 The syslog Protocol 9 draft-ietf-syslog-protocol-23 11 Status of This Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 8, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes the syslog protocol, which is used to convey 43 event notification messages. This protocol utilizes a layered 44 architecture, which allows the use of any number of transport 45 protocols for transmission of syslog messages. It also provides a 46 message format that allows vendor-specific extensions to be provided 47 in a structured way. 49 This document has been written with the original design goals for 50 traditional syslog in mind. The reason for a new layered 51 specification has arisen because standardization efforts for reliable 52 and secure syslog extensions suffer from the lack of a standards- 53 track and transport independent RFC. Without this document, each 54 other standard needs to define its own syslog packet format and 55 transport mechanism, which over time will introduce subtle 56 compatibility issues. This document tries to provide a foundation 57 that syslog extensions can build on. This layered architecture 58 approach also provides a solid basis that allows code to be written 59 once for each syslog feature rather than once for each transport. 61 This document obsoletes RFC3164. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 67 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Basic Principles . . . . . . . . . . . . . . . . . . . . . . . 5 69 4.1. Example Deployment Scenarios . . . . . . . . . . . . . . . 6 70 5. Transport Layer Protocol . . . . . . . . . . . . . . . . . . . 8 71 5.1. Minimum Required Transport Mapping . . . . . . . . . . . . 8 72 6. Syslog Message Format . . . . . . . . . . . . . . . . . . . . 8 73 6.1. Message Length . . . . . . . . . . . . . . . . . . . . . . 10 74 6.2. HEADER . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 6.2.1. PRI . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 6.2.2. VERSION . . . . . . . . . . . . . . . . . . . . . . . 12 77 6.2.3. TIMESTAMP . . . . . . . . . . . . . . . . . . . . . . 12 78 6.2.4. HOSTNAME . . . . . . . . . . . . . . . . . . . . . . . 13 79 6.2.5. APP-NAME . . . . . . . . . . . . . . . . . . . . . . . 14 80 6.2.6. PROCID . . . . . . . . . . . . . . . . . . . . . . . . 15 81 6.2.7. MSGID . . . . . . . . . . . . . . . . . . . . . . . . 15 82 6.3. STRUCTURED-DATA . . . . . . . . . . . . . . . . . . . . . 15 83 6.3.1. SD-ELEMENT . . . . . . . . . . . . . . . . . . . . . . 16 84 6.3.2. SD-ID . . . . . . . . . . . . . . . . . . . . . . . . 16 85 6.3.3. SD-PARAM . . . . . . . . . . . . . . . . . . . . . . . 17 86 6.3.4. Change Control . . . . . . . . . . . . . . . . . . . . 17 87 6.3.5. Examples . . . . . . . . . . . . . . . . . . . . . . . 18 88 6.4. MSG . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 6.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 7. Structured Data IDs . . . . . . . . . . . . . . . . . . . . . 21 91 7.1. timeQuality . . . . . . . . . . . . . . . . . . . . . . . 21 92 7.1.1. tzKnown . . . . . . . . . . . . . . . . . . . . . . . 21 93 7.1.2. isSynced . . . . . . . . . . . . . . . . . . . . . . . 21 94 7.1.3. syncAccuracy . . . . . . . . . . . . . . . . . . . . . 22 95 7.1.4. Examples . . . . . . . . . . . . . . . . . . . . . . . 22 96 7.2. origin . . . . . . . . . . . . . . . . . . . . . . . . . . 23 97 7.2.1. ip . . . . . . . . . . . . . . . . . . . . . . . . . . 23 98 7.2.2. enterpriseId . . . . . . . . . . . . . . . . . . . . . 23 99 7.2.3. software . . . . . . . . . . . . . . . . . . . . . . . 24 100 7.2.4. swVersion . . . . . . . . . . . . . . . . . . . . . . 24 101 7.2.5. Example . . . . . . . . . . . . . . . . . . . . . . . 24 102 7.3. meta . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 103 7.3.1. sequenceId . . . . . . . . . . . . . . . . . . . . . . 24 104 7.3.2. sysUpTime . . . . . . . . . . . . . . . . . . . . . . 25 105 7.3.3. language . . . . . . . . . . . . . . . . . . . . . . . 25 106 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 107 8.1. UNICODE . . . . . . . . . . . . . . . . . . . . . . . . . 25 108 8.2. Control Characters . . . . . . . . . . . . . . . . . . . . 25 109 8.3. Message Truncation . . . . . . . . . . . . . . . . . . . . 26 110 8.4. Replay . . . . . . . . . . . . . . . . . . . . . . . . . . 27 111 8.5. Reliable Delivery . . . . . . . . . . . . . . . . . . . . 27 112 8.6. Congestion Control . . . . . . . . . . . . . . . . . . . . 28 113 8.7. Message Integrity . . . . . . . . . . . . . . . . . . . . 28 114 8.8. Message Observation . . . . . . . . . . . . . . . . . . . 29 115 8.9. Inappropriate Configuration . . . . . . . . . . . . . . . 29 116 8.10. Forwarding Loop . . . . . . . . . . . . . . . . . . . . . 29 117 8.11. Load Considerations . . . . . . . . . . . . . . . . . . . 30 118 8.12. Denial of Service . . . . . . . . . . . . . . . . . . . . 30 119 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 120 9.1. VERSION . . . . . . . . . . . . . . . . . . . . . . . . . 30 121 9.2. SD-IDs . . . . . . . . . . . . . . . . . . . . . . . . . . 31 122 10. Working Group . . . . . . . . . . . . . . . . . . . . . . . . 32 123 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 124 12. Notes to the RFC Editor . . . . . . . . . . . . . . . . . . . 32 125 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 126 13.1. Normative References . . . . . . . . . . . . . . . . . . . 32 127 13.2. Informative References . . . . . . . . . . . . . . . . . . 34 128 Appendix A. implementer Guidelines . . . . . . . . . . . . . . . 34 129 A.1. Relationship with BSD Syslog . . . . . . . . . . . . . . . 34 130 A.2. Message Length . . . . . . . . . . . . . . . . . . . . . . 35 131 A.3. Severity Values . . . . . . . . . . . . . . . . . . . . . 36 132 A.4. TIME-SECFRAC Precision . . . . . . . . . . . . . . . . . . 37 133 A.5. Case Convention for Names . . . . . . . . . . . . . . . . 37 134 A.6. Syslog Applications Without Knowledge of Time . . . . . . 37 135 A.7. Notes on the timeQuality SD-ID . . . . . . . . . . . . . . 37 136 A.8. UTF-8 encoding and the BOM . . . . . . . . . . . . . . . . 38 138 1. Introduction 140 This document describes a layered architecture for syslog. The goal 141 of this architecture is to separate message content from message 142 transport while enabling easy extensibility for each layer. 144 This document describes the standard format for syslog messages and 145 outlines the concept of transport mappings. It also describes 146 structured data elements, which can be used to transmit easily 147 parseable, structured information and allows for vendor extensions. 149 This document does not describe any storage format for syslog 150 messages. It is beyond of the scope of the syslog protocol and is 151 not necessary for system interoperability. 153 This document has been written with the original design goals for 154 traditional syslog in mind. The reason for a new layered 155 specification has arisen because standardization efforts for 156 reliable, and secure syslog extensions suffer from the lack of a 157 standards-track and transport independent RFC. Without this 158 document, each other standard would need to define its own syslog 159 packet format and transport mechanism which, over time will introduce 160 subtle compatibility issues. It tries to provide a foundation that 161 syslog extensions can build on. This layered architecture approach 162 also provides a solid basis that allows code to be written once 163 instead of once for each syslog feature. 165 This document obsoletes RFC3164, which is only an Informational 166 document describing some implementations found in the field. 168 2. Conventions Used in This Document 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in RFC 2119 [RFC2119]. 174 3. Definitions 176 Syslog utilizes three layers: 178 o "syslog content" is the management information contained in a 179 syslog message. 181 o The "syslog application" layer handles generation, interpretation, 182 routing and storage of syslog messages. 184 o The "syslog transport" layer puts messages on the wire and takes 185 them off the wire. 187 Certain types of functions are performed at each conceptual layer: 189 o An "originator" generates syslog content to be carried in a 190 message. 192 o A "collector" gathers syslog content for further analysis. 194 o A "relay" forwards messages, accepting messages from originators 195 or other relays, and sending them to collectors or other relays. 197 o A "transport sender" passes syslog messages to a specific 198 transport protocol 200 o A "transport receiver" takes syslog messages from a specific 201 transport protocol. 203 Diagram 1 shows the different entities separated by layer. 205 +---------------------+ +---------------------+ 206 | content | | content | 207 |---------------------| |---------------------| 208 | syslog application | | syslog application | (originator, 209 | | | | collector, relay) 210 |---------------------| |---------------------| 211 | syslog transport | | syslog transport | (transport sender, 212 | | | | (transport receiver) 213 +---------------------+ +---------------------+ 214 ^ ^ 215 | | 216 -------------------------- 218 Diagram 1. Syslog Layers 220 4. Basic Principles 222 The following principles apply to syslog communication: 224 o The syslog protocol does not provide acknowledgement of message 225 delivery. Though some transports may provide status information, 226 conceptually, syslog is a pure simplex communications protocol. 228 o Originators and Relays may be configured to send the same message 229 to multiple collectors and relays. 231 o Originator, relay, and collector functionality may reside on the 232 same system. 234 4.1. Example Deployment Scenarios 236 Sample deployment scenarios are shown in Diagram 2. Other 237 arrangements of these examples are also acceptable. As noted, in the 238 following diagram, relays may send all or some of the messages that 239 they receive and also send messages that they generate internally. 240 The boxes represent syslog-enabled applications. 242 +----------+ +---------+ 243 |Originator|---->----|Collector| 244 +----------+ +---------+ 246 +----------+ +-----+ +---------+ 247 |Originator|---->----|Relay|---->----|Collector| 248 +----------+ +-----+ +---------+ 250 +----------+ +-----+ +-----+ +---------+ 251 |Originator|-->--|Relay|-->--..-->--|Relay|-->--|Collector| 252 +----------+ +-----+ +-----+ +---------+ 254 +----------+ +-----+ +---------+ 255 |Originator|---->----|Relay|---->----|Collector| 256 | |-+ +-----+ +---------+ 257 +----------+ \ 258 \ +-----+ +---------+ 259 +->--|Relay|---->----|Collector| 260 +-----+ +---------+ 262 +----------+ +---------+ 263 |Originator|---->----|Collector| 264 | |-+ +---------+ 265 +----------+ \ 266 \ +-----+ +---------+ 267 +->--|Relay|---->----|Collector| 268 +-----+ +---------+ 270 +----------+ +-----+ +---------+ 271 |Originator|---->----|Relay|---->-------|Collector| 272 | |-+ +-----+ +---| | 273 +----------+ \ / +---------+ 274 \ +-----+ / 275 +->--|Relay|-->--/ 276 +-----+ 278 +----------+ +-----+ +---------+ 279 |Originator|---->----|Relay|---->--------------|Collector| 280 | |-+ +-----+ +--| | 281 +----------+ \ / +---------+ 282 \ +------------+ / 283 \ |+----------+| / 284 +->-||Relay ||->---/ 285 |+----------|| / 286 ||Originator||->-/ 287 |+----------+| 288 +------------+ 290 Diagram 2. Some possible syslog deployment scenarios. 292 5. Transport Layer Protocol 294 This document does not specify any transport layer protocol. 295 Instead, it describes the format of a syslog message in a transport 296 layer independent way. Syslog transports are defined in other 297 documents. The first transport is defined in 298 [I-D.ietf-syslog-transport-udp] and is consistent with the 299 traditional UDP transport. This transport is needed to maintain 300 interoperability as the UDP transport has historically been used for 301 the transmission of syslog messages. 303 Any syslog transport protocol MUST NOT deliberately alter the syslog 304 message. If the transport protocol needs to perform temporary 305 transformations at the transport sender, these transformations MUST 306 be reversed by the transport protocol at the transport receiver, so 307 that relay or collector will see an exact copy of the message 308 generated by the originator or relay. Otherwise end-to-end 309 cryptographic verifiers (such as signatures) will be broken. Of 310 course, message alteration might occur due to transmission errors or 311 other problems. Guarding against such alterations is not within the 312 scope of this document. 314 5.1. Minimum Required Transport Mapping 316 All implementations of this specification MUST support a TLS-based 317 transport as described in [I-D.ietf-syslog-transport-tls]. 319 All implementations of this specification SHOULD also support a UDP- 320 based transport as described in [I-D.ietf-syslog-transport-udp]. 322 It is RECOMMENDED that implementations of this specification use the 323 TLS-based transport. 325 6. Syslog Message Format 327 The syslog message has the following ABNF [RFC4234] definition: 329 SYSLOG-MSG = HEADER SP STRUCTURED-DATA [SP MSG] 331 HEADER = PRI VERSION SP TIMESTAMP SP HOSTNAME 332 SP APP-NAME SP PROCID SP MSGID 333 PRI = "<" PRIVAL ">" 334 PRIVAL = 1*3DIGIT ; range 0 .. 191 335 VERSION = NONZERO-DIGIT 0*2DIGIT 336 HOSTNAME = NILVALUE / 1*255PRINTUSASCII 337 APP-NAME = NILVALUE / 1*48PRINTUSASCII 338 PROCID = NILVALUE / 1*128PRINTUSASCII 339 MSGID = NILVALUE / 1*32PRINTUSASCII 341 TIMESTAMP = NILVALUE / FULL-DATE "T" FULL-TIME 342 FULL-DATE = DATE-FULLYEAR "-" DATE-MONTH "-" DATE-MDAY 343 DATE-FULLYEAR = 4DIGIT 344 DATE-MONTH = 2DIGIT ; 01-12 345 DATE-MDAY = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on 346 ; month/year 347 FULL-TIME = PARTIAL-TIME TIME-OFFSET 348 PARTIAL-TIME = TIME-HOUR ":" TIME-MINUTE ":" TIME-SECOND 349 [TIME-SECFRAC] 350 TIME-HOUR = 2DIGIT ; 00-23 351 TIME-MINUTE = 2DIGIT ; 00-59 352 TIME-SECOND = 2DIGIT ; 00-59 353 TIME-SECFRAC = "." 1*6DIGIT 354 TIME-OFFSET = "Z" / TIME-NUMOFFSET 355 TIME-NUMOFFSET = ("+" / "-") TIME-HOUR ":" TIME-MINUTE 357 STRUCTURED-DATA = NILVALUE / 1*SD-ELEMENT 358 SD-ELEMENT = "[" SD-ID *(SP SD-PARAM) "]" 359 SD-PARAM = PARAM-NAME "=" %d34 PARAM-VALUE %d34 360 SD-ID = SD-NAME 361 PARAM-NAME = SD-NAME 362 PARAM-VALUE = UTF-8-STRING ; characters '"', '\' and 363 ; ']' MUST be escaped. 364 SD-NAME = 1*32PRINTUSASCII 365 ; except '=', SP, ']', %d34 (") 367 MSG = MSG-ANY / MSG-UTF8 368 MSG-ANY = *OCTET ; not starting with BOM 369 MSG-UTF8 = BOM UTF-8-STRING 370 BOM = %xEF.BB.BF 371 UTF-8-STRING = *OCTET ; UTF-8 string as specified 372 ; in RFC 3629 374 OCTET = %d00-255 375 SP = %d32 376 PRINTUSASCII = %d33-126 377 NONZERO-DIGIT = %d49-57 378 DIGIT = %d48 / NONZERO-DIGIT 379 NILVALUE = "-" 381 6.1. Message Length 383 Syslog message size limits are dictated by the syslog transport 384 mapping in use. There is no upper limit per se. Each transport 385 mapping defines the minimum maximum required message length support, 386 and the minimum maximum MUST be at least 480 octets in length. 388 Any transport receiver MUST be able to accept messages of up to and 389 including 480 octets in length. All transport receiver 390 implementations SHOULD be able to accept messages of up to and 391 including 2048 octets in length. Transport receivers MAY receive 392 messages larger than 2048 octets in length. If a transport receiver 393 receives a message with a length larger than it supports, the 394 transport receiver SHOULD truncate the payload. Alternatively, it 395 MAY discard the message. 397 If a transport receiver truncates messages, the truncation MUST occur 398 at the end of the message. After truncation, the message MAY contain 399 invalid UTF-8 encoding or invalid STRUCTURED-DATA. The transport 400 receiver MAY discard the message or MAY try to process as much as 401 possible in this case. 403 6.2. HEADER 405 The character set used in the HEADER MUST be seven-bit ASCII in an 406 eight-bit field as described in [RFC4234] . These are the ASCII 407 codes as defined in "USA Standard Code for Information Interchange" 408 [ANSI.X3-4.1968]. 410 The header format is designed to provide some interoperability with 411 older BSD-based syslog. For details on this, see Appendix A.1. 413 6.2.1. PRI 415 The PRI part MUST have three, four, or five characters and will be 416 bound with angle brackets as the first and last characters. The PRI 417 part starts with a leading "<" ('less-than' character, %d60), 418 followed by a number, which is followed by a ">" ('greater-than' 419 character, %d62). The number contained within these angle brackets 420 is known as the Priority value (PRIVAL) and represents both the 421 Facility and Severity. The Priority value consists of one, two, or 422 three decimal integers (ABNF DIGITS) using values of %d48 (for "0") 423 through %d57 (for "9"). 425 Facility and Severity values are not normative but often used. They 426 are described in the following tables for purely informational 427 purposes. Facility values MUST be in the range of 0 to 23 inclusive. 429 Numerical Facility 430 Code 432 0 kernel messages 433 1 user-level messages 434 2 mail system 435 3 system daemons 436 4 security/authorization messages 437 5 messages generated internally by syslogd 438 6 line printer subsystem 439 7 network news subsystem 440 8 UUCP subsystem 441 9 clock daemon 442 10 security/authorization messages 443 11 FTP daemon 444 12 NTP subsystem 445 13 log audit 446 14 log alert 447 15 clock daemon (note 2) 448 16 local use 0 (local0) 449 17 local use 1 (local1) 450 18 local use 2 (local2) 451 19 local use 3 (local3) 452 20 local use 4 (local4) 453 21 local use 5 (local5) 454 22 local use 6 (local6) 455 23 local use 7 (local7) 457 Table 1. syslog Message Facilities 459 Each message Priority also has a decimal Severity level indicator. 460 These are described in the following table along with their numerical 461 values. Severity values MUST be in the range of 0 to 7 inclusive. 463 Numerical Severity 464 Code 466 0 Emergency: system is unusable 467 1 Alert: action must be taken immediately 468 2 Critical: critical conditions 469 3 Error: error conditions 470 4 Warning: warning conditions 471 5 Notice: normal but significant condition 472 6 Informational: informational messages 473 7 Debug: debug-level messages 475 Table 2. syslog Message Severities 477 The Priority value is calculated by first multiplying the Facility 478 number by 8 and then adding the numerical value of the Severity. For 479 example, a kernel message (Facility=0) with a Severity of Emergency 480 (Severity=0) would have a Priority value of 0. Also, a "local use 4" 481 message (Facility=20) with a Severity of Notice (Severity=5) would 482 have a Priority value of 165. In the PRI of a syslog message, these 483 values would be placed between the angle brackets as <0> and <165> 484 respectively. The only time a value of "0" follows the "<" is for 485 the Priority value of "0". Otherwise, leading "0"s MUST NOT be used. 487 6.2.2. VERSION 489 The VERSION field denotes the version of the syslog protocol 490 specification. The version number MUST be incremented for any new 491 syslog protocol specification that changes any part of the HEADER 492 format. Changes include the addition or removal of fields, or a 493 change of syntax or semantics of existing fields. This document uses 494 a VERSION value of "1". The VERSION values are IANA-assigned 495 (Section 9.1) via the Standards Action method as described in 496 [RFC2434]. 498 6.2.3. TIMESTAMP 500 The TIMESTAMP field is a formalized timestamp derived from [RFC3339]. 502 Whereas [RFC3339] makes allowances for multiple syntaxes, this 503 document imposes further restrictions. The TIMESTAMP value MUST 504 follow these restrictions: 506 o The "T" and "Z" characters in this syntax MUST be upper case. 508 o Usage of the "T" character is REQUIRED. 510 o Leap seconds MUST NOT be used. 512 The originator SHOULD include TIME-SECFRAC if its clock accuracy and 513 performance permit. The "timeQuality" SD-ID described in Section 7.1 514 allows the originator to specify the accuracy and trustworthiness of 515 the timestamp. 517 A syslog application MUST use the NILVALUE as TIMESTAMP if the syslog 518 application is incapable of obtaining system time. 520 6.2.3.1. Examples 522 Example 1 524 1985-04-12T23:20:50.52Z 526 This represents 20 minutes and 50.52 seconds after the 23rd hour of 527 12 April 1985 in UTC. 529 Example 2 531 1985-04-12T19:20:50.52-04:00 533 This represents the same time as in example 1, but expressed in the 534 Eastern US time zone (daylight savings time being observed). 536 Example 3 538 2003-10-11T22:14:15.003Z 540 This represents 11 October 2003 at 10:14:15pm, 3 milliseconds into 541 the next second. The timestamp is in UTC. The timestamp provides 542 millisecond resolution. The creator may have actually had a better 543 resolution, but by providing just three digits for the fractional 544 part of a second, it does not tell us. 546 Example 4 548 2003-08-24T05:14:15.000003-07:00 550 This represents 24 August 2003 at 05:14:15am, 3 microseconds into the 551 next second. The microsecond resolution is indicated by the 552 additional digits in TIME-SECFRAC. The timestamp indicates that its 553 local time is -7 hours from UTC. This timestamp might be created in 554 the US Pacific time zone during daylight savings time. 556 Example 5 - An Invalid TIMESTAMP 558 2003-08-24T05:14:15.000000003-07:00 560 This example is nearly the same as Example 4, but it is specifying 561 TIME-SECFRAC in nanoseconds. This results in TIME-SECFRAC being 562 longer than the allowed 6 digits, which invalidates it. 564 6.2.4. HOSTNAME 566 The HOSTNAME field identifies the machine that originally sent the 567 syslog message. 569 The HOSTNAME field SHOULD contain the host name and the domain name 570 of the originator in the format specified in STD 13 [RFC1034]. This 571 format is called a Fully Qualified Domain Name (FQDN) in this 572 document. 574 In practice, not all syslog applications are able to provide a FQDN. 575 As such, other values MAY also be present in HOSTNAME. This document 576 makes provisions for using other values in such situations. A syslog 577 application SHOULD provide the most specific available value first. 578 The order of preference for the contents of the HOSTNAME field is as 579 follows: 581 1. FQDN 583 2. Static IP address 585 3. hostname 587 4. Dynamic IP address 589 5. the NILVALUE 591 If an IPv4 address is used, it MUST be in the format of the dotted 592 decimal notation as used in STD 13 [RFC1035]. If an IPv6 address is 593 used, a valid textual representation as described in [RFC4291], 594 Section 2.2, MUST be used. 596 Syslog applications SHOULD consistently use the same value in the 597 HOSTNAME field for as long as possible. 599 The NILVALUE SHOULD only be used when the syslog application has no 600 way to obtain its real hostname. This situation is considered highly 601 unlikely. 603 6.2.5. APP-NAME 605 The APP-NAME field SHOULD identify the device or application that 606 originated the message. It is a string without further semantics. 607 It is intended for filtering messages on a relay or collector. 609 The NILVALUE MAY be used when the syslog application has no idea of 610 its APP-NAME or cannot provide that information. It may be that a 611 device may not be able to provide that information either because of 612 a local policy decision, or because the information is not available, 613 or not applicable, on the device. 615 This field MAY be operator-assigned. 617 6.2.6. PROCID 619 PROCID is a value that is included in the message, having no 620 interoperable meaning, except that a change in the value indicates 621 there has been a discontinuity in syslog reporting. The field does 622 not have any specific syntax or semantics; the value is 623 implementation-dependent and/or operator-assigned. The NILVALUE MAY 624 be used when no value is provided. 626 The PROCID field is often used to provide the process name or process 627 ID associated with a syslog system. The NILVALUE might be used when 628 a process ID is not available. On an embedded system without any 629 operating system process ID, PROCID might be a reboot ID. 631 PROCID can enable log analyzers to detect discontinuities in syslog 632 reporting, by detecting a change in the syslog process ID. However, 633 PROCID is not a reliable identification of a restarted process, since 634 the restarted syslog process might be assigned the same process ID as 635 the previous syslog process. 637 PROCID can also be used to identify which messages belong to a group 638 of messages. For example, a SMTP MTA might put its SMTP transaction 639 ID into PROCID, which would allow the collector or relay to group 640 messages based on the SMTP transaction. 642 6.2.7. MSGID 644 The MSGID SHOULD identify the type of message. For example, a 645 firewall might use the MSGID "TCPIN" for incoming TCP traffic and the 646 MSGID "TCPOUT" for outgoing TCP traffic. Messages with the same 647 MSGID should reflect events of the same semantics. The MSGID itself 648 is a string without further semantics. It is intended for filtering 649 messages on a relay or collector. 651 The NILVALUE SHOULD be used when the syslog application does not, or 652 can not, provide any value. 654 This field MAY be operator-assigned. 656 6.3. STRUCTURED-DATA 658 STRUCTURED-DATA provides a mechanism to express information in a well 659 defined, easily parseable and interpretable data format. There are 660 multiple usage scenarios. For example, it may express meta- 661 information about the syslog message or application-specific 662 information such as traffic counters or IP addresses. 664 STRUCTURED-DATA can contain zero, one, or multiple structured data 665 elements, which are referred to as "SD-ELEMENT" in this document. 667 In case of zero structured data elements, the STRUCTURED-DATA field 668 MUST contain the NILVALUE. 670 The character set used in STRUCTURED-DATA MUST be seven-bit ASCII in 671 an eight-bit field as described in [RFC4234]. These are the ASCII 672 codes as defined in "USA Standard Code for Information Interchange" 673 [ANSI.X3-4.1968]. An exception is the PARAM-VALUE field (see 674 Section 6.3.3), in which UTF-8 encoding MUST be used. 676 A collector MAY ignore malformed STRUCTURED-DATA elements. A relay 677 MUST forward malformed STRUCTURED-DATA without any alteration. 679 6.3.1. SD-ELEMENT 681 A SD-ELEMENT consists of a name and parameter name-value pairs. The 682 name is referred to as SD-ID. The name-value pairs are referred to 683 as "SD-PARAM". 685 6.3.2. SD-ID 687 SD-IDs are case-sensitive and uniquely identify the type and purpose 688 of the SD-ELEMENT. The same SD-ID MUST NOT exist more than once in a 689 message. 691 There are two formats for SD-ID names: 693 o Names that do not contain an at-sign ("@", ABNF %d64) are reserved 694 to be assigned by IETF CONSENSUS as described in BCP26 [RFC2434]. 695 Currently, these are the names defined in Section 7. Names of 696 this format are only valid if they are first registered with the 697 IANA. Registered names MUST NOT contain an at-sign ('@', ABNF 698 %d64), an equal-sign ('=', ABNF %d61), a closing brace (']', ABNF 699 %d93), a quote-character ('"', ABNF %d34), or whitespace, or 700 control characters (ASCII code 127 and codes 32 or less). 702 o Anyone can define additional SD-IDs using names in the format 703 name@enterpriseId, e.g., "ourSDID@0". The format of the part 704 preceding the at-sign is not specified, however these names MUST 705 be printable US-ASCII strings, and MUST NOT contain an at-sign 706 ('@', ABNF %d64), the equal-sign ('=', ABNF %d61), a closing brace 707 (']', ABNF %d93), a quote-character ('"', ABNF %d34), or 708 whitespace, or control characters. The part following the at-sign 709 MUST be an enterpriseId as specified in Section 7.2.2. 711 6.3.3. SD-PARAM 713 Each SD-PARAM consists of a name, referred to as PARAM-NAME, and a 714 value, referred to as PARAM-VALUE. 716 PARAM-NAME is case-sensitive. IANA controls all PARAM-NAMEs, with 717 the exception of those in SD-IDs whose names contain an at-sign. The 718 PARAM-NAME scope is within a specific SD-ID. Thus, equally-named 719 PARAM-NAME values contained in two different SD-IDs are not the same. 721 To support international characters, the PARAM-VALUE field MUST be 722 encoded using UTF-8. A syslog application MAY issue any valid UTF-8 723 sequence. A syslog application MUST accept any valid UTF-8 sequence 724 in the "shortest form". It MUST NOT fail if control characters are 725 present in PARAM-VALUE. The syslog application MAY modify messages 726 containing control characters (e.g. by changing an octet with value 0 727 (USASCII NUL) to the four characters "#000"). For the reasons 728 outlined in UNICODE TR36 [UNICODE-TR36], section 3.1, an originator 729 MUST encode messages in the "shortest form" and a collector or relay 730 MUST NOT interpret messages in the "non-shortest form". 732 Inside PARAM-VALUE, the characters '"' (ABNF %d34), '\' (ABNF %d92) 733 and ']' (ABNF %d93) MUST be escaped. This is necessary to avoid 734 parsing errors. Escaping ']' would not strictly be necessary but is 735 REQUIRED by this specification to avoid syslog application 736 implementation errors. Each of these three characters MUST be 737 escaped as '\"', '\\' and '\]' respectively. The backslash is used 738 for control character escaping for consistency with its use for 739 escaping in other parts of the syslog message as well as in 740 traditional syslog. 742 A backslash ('\') followed by none of the three described characters 743 is considered an invalid escape sequence. In this case, the 744 backslash MUST be treated as a regular backslash and the following 745 character as a regular character. Thus, the invalid sequence MUST 746 not be altered. 748 A SD-PARAM MAY be repeated multiple times inside a SD-ELEMENT. 750 6.3.4. Change Control 752 Once SD-IDs and PARAM-NAMEs are defined, syntax and semantics of 753 these objects MUST NOT be altered. Should a change to an existing 754 object be desired, a new SD-ID or PARAM-NAME MUST be created and the 755 old one remain unchanged. OPTIONAL PARAM-NAMEs MAY be added to an 756 existing SD-ID. 758 6.3.5. Examples 760 All examples in this section show only the structured data part of 761 the message. Examples should be considered to be on one line. They 762 are wrapped on multiple lines in this document for readability 763 purposes. A description is given after each example. 765 Example 1 - Valid 767 [exampleSDID@0 iut="3" eventSource="Application" 768 eventID="1011"] 770 This example is a structured data element with a non-IANA controlled 771 SD-ID of type "exampleSDID@0" which has three parameters. 773 Example 2 - Valid 775 [exampleSDID@0 iut="3" eventSource="Application" 776 eventID="1011"][examplePriority@0 class="high"] 778 This is the same example as in 1, but with a second structured data 779 element. Please note that the structured data element immediately 780 follows the first one (there is no SP between them). 782 Example 3 - Invalid 784 [exampleSDID@0 iut="3" eventSource="Application" 785 eventID="1011"] [examplePriority@0 class="high"] 787 This is nearly the same example as 2, but it has a subtle error - 788 there is a SP character between the two structured data elements 789 ("]SP["). This is invalid. It will cause the STRUCTURED-DATA field 790 to end after the first element. The second element will be 791 interpreted as part of the MSG field. 793 Example 4 - Invalid 795 [ exampleSDID@0 iut="3" eventSource="Application" 796 eventID="1011"][examplePriority@0 class="high"] 798 This example is nearly the same as 2. It has another subtle error - 799 the SP character occurs after the initial bracket. A structured data 800 element SD-ID MUST immediately follow the beginning bracket, so the 801 SP character invalidates the STRUCTURED-DATA. A syslog application 802 MAY discard this message. 804 Example 5 - Valid 806 [sigSig ver="1" rsID="1234" ... signature="..."] 808 Example 5 is a valid example. It shows a hypothetical IANA-assigned 809 SD-ID. The ellipses denote missing content, which has been left out 810 of this example for brevity. 812 6.4. MSG 814 The MSG part contains a free-form message that provides information 815 about the event. 817 The character set used in MSG SHOULD be UNICODE, encoded using UTF-8 818 as specified in [RFC3629]. If the syslog application can not encode 819 the MSG in Unicode, it MAY use any other encoding. 821 The syslog application SHOULD avoid octet values below 32 (the 822 traditional US-ASCII control character range except DEL). These 823 values are legal, but a syslog application MAY modify these 824 characters upon reception. For example, it might change them into an 825 escape sequence (e.g. value 0 may be changed to "\0"). A syslog 826 application SHOULD NOT modify any other octet values. 828 If a syslog application encodes MSG in UTF-8, the string MUST start 829 with the Unicode byte order mask (BOM), which for UTF-8 is ABNF 830 %xEF.BB.BF. The syslog application MUST encode in the "shortest 831 form" and MAY use any valid UTF-8 sequence. 833 If a syslog application is processing a MSG starting with a BOM, if 834 it contains UTF-8 that is not shortest form it MUST NOT be 835 interpreted as being encoded in UTF-8 for the reasons outlined in 836 [UNICODE-TR36], section 3.1. Guidance about this is given in 837 Appendix A.8. 839 Also, according to UNICODE TR36 [UNICODE-TR36], a syslog application 840 MUST NOT interpret messages in the "non-shortest form". It MUST NOT 841 interpret invalid UTF-8 sequences. 843 6.5. Examples 845 The following are examples of valid syslog messages. A description 846 of each example can be found below it. The examples are based on 847 similar examples from [RFC3164] and may be familiar to readers. The 848 otherwise-unprintable Unicode BOM is represented as "BOM" in the 849 examples. 851 Example 1 853 <34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47 854 - BOM'su root' failed for lonvick on /dev/pts/8 856 In this example, the VERSION is 1 and the Facility has the value of 857 4. The severity is 2. The message was created on 11 October 2003 at 858 10:14:15pm UTC, 3 milliseconds into the next second. The message 859 originated from a host that identifies itself as 860 "mymachine.example.com". The APP-NAME is "su" and the PROCID is 861 unknown. The MSGID is "ID47". The MSG is "'su root' failed for 862 lonvick...", encoded in UTF-8. The encoding is defined by the BOM. 863 There is no STRUCTURED-DATA present in the message, this is indicated 864 by "-" in the STRUCTURED-DATA field. The MSG is "'su root' failed 865 for lonvick...". 867 Example 2 869 <165>1 2003-08-24T05:14:15.000003-07:00 192.0.2.1 870 myproc 8710 - - %% It's time to make the do-nuts. 872 In this example, the VERSION is again 1. The Facility is 20, the 873 Severity 5. The message was created on 24 August 2003 at 5:14:15am, 874 with a -7 hour offset from UTC, 3 microseconds into the next second. 875 The HOSTNAME is "192.0.2.1", so the syslog application did not know 876 its FQDN and used one of its IPv4 addresses instead. The APP-NAME is 877 "myproc" and the PROCID is "8710" (for example this could be the UNIX 878 PID). There is no STRUCTURED-DATA present in the message, this is 879 indicated by "-" in the STRUCTURED-DATA field. There is no specific 880 MSGID and this is indicated by the "-" in the MSGID field. The 881 message is "%% It's time to make the do-nuts.". As the Unicode BOM 882 is missing, the syslog application does not know the encoding of the 883 MSG part. 885 Example 3 - with STRUCTURED-DATA 887 <165>1 2003-10-11T22:14:15.003Z mymachine.example.com 888 evntslog - ID47 [exampleSDID@0 iut="3" eventSource= 889 "Application" eventID="1011"] BOMAn application 890 event log entry... 892 This example is modeled after example 1. However, this time it 893 contains STRUCTURED-DATA, a single element with the value 894 "[exampleSDID@0 iut="3" eventSource="Application" eventID="1011"]". 895 The MSG itself is "An application event log entry..." The BOM at the 896 beginning of MSG indicates UTF-8 encoding. 898 Example 4 - STRUCTURED-DATA Only 900 <165>1 2003-10-11T22:14:15.003Z mymachine.example.com 901 evntslog - ID47 [exampleSDID@0 iut="3" eventSource= 902 "Application" eventID="1011"][examplePriority@0 903 class="high"] 905 This example shows a message with only STRUCTURED-DATA and no MSG 906 part. This is a valid message. 908 7. Structured Data IDs 910 This section defines the initial IANA-registered SD-IDs. See 911 Section 6.3 for a definition of structured data elements. All SD-IDs 912 defined here are OPTIONAL. 914 In some of the following, a maximum length is quantified for the 915 parameter values. In each of those cases, the syslog application 916 MUST be prepared to receive the number of defined characters in any 917 valid UTF-8 code point. Since each character may be up to 6 octets, 918 it is RECOMMENDED that each syslog application be prepared to receive 919 up to six octets per character. 921 7.1. timeQuality 923 The SD-ID "timeQuality" MAY be used by the originator to describe its 924 notion of system time. This SD-ID SHOULD be written if the 925 originator is not properly synchronized with a reliable external time 926 source or if it does not know whether its time zone information is 927 correct. The main use of this structured data element is to provide 928 some information on the level of trust it has in the TIMESTAMP 929 described in Section 6.2.3. All parameters are OPTIONAL. 931 7.1.1. tzKnown 933 The "tzKnown" parameter indicates whether the originator knows its 934 time zone. If it does so, the value "1" MUST be used. If the time 935 zone information is in doubt, the value "0" MUST be used. If the 936 originator knows its time zone but decides to emit time in UTC, the 937 value "1" MUST be used (because the time zone is known). 939 7.1.2. isSynced 941 The "isSynced" parameter indicates whether the originator is 942 synchronized to a reliable external time source, e.g., via NTP. If 943 the originator is time synchronized, the value "1" MUST be used. If 944 not, the value "0" MUST be used. 946 7.1.3. syncAccuracy 948 The "syncAccuracy" parameter indicates how accurate the originator 949 thinks its time synchronization is. It is an integer describing the 950 maximum number of microseconds that its clock may be off between 951 synchronization intervals. 953 If the value "0" is used for "isSynced", this parameter MUST NOT be 954 specified. If the value "1" is used for "isSynced" but the 955 "syncAccuracy" parameter is absent, a collector or relay can assume 956 that the time information provided is accurate enough to be 957 considered correct. The "syncAccuracy" parameter MUST be written 958 only if the originator actually has knowledge of the reliability of 959 the external time source. In most cases, it will gain this in-depth 960 knowledge through operator configuration. 962 7.1.4. Examples 964 The following is an example of an originator that does not know its 965 time zone nor whether it is being synchronized: 967 [timeQuality tzKnown="0" isSynced="0"] 969 With this information, the originator indicates that its time 970 information is unreliable. This may be a hint for the collector or 971 relay to use its local time instead of the message-provided TIMESTAMP 972 for correlation of multiple messages from different originators. 974 The following is an example of an originator that knows its time zone 975 and knows that it is properly synchronized to a reliable external 976 source: 978 [timeQuality tzKnown="1" isSynced="1"] 980 The following is an example of an originator that knows both its time 981 zone and that it is externally synchronized. It also knows the 982 accuracy of the external synchronization: 984 [timeQuality tzKnown="1" isSynced="1" syncAccuracy="60000000"] 986 The difference between this and the previous example is that the 987 originator expects that its clock will be kept within 60 seconds of 988 the official time. Thus if the originator reports it is 9:00:00, it 989 is no earlier than 8:59:00 and no later then 9:01:00. 991 7.2. origin 993 The SD-ID "origin" MAY be used to indicate the origin of a syslog 994 message. The following parameters can be used. All parameters are 995 OPTIONAL. 997 Specifying any of these parameters is primarily an aid to log 998 analyzers and similar applications. 1000 7.2.1. ip 1002 The "ip" parameter denotes an IP address that the originator knows it 1003 had at the time of originating the message. It MUST contain the 1004 textual representation of an IP address as outlined in Section 6.2.4. 1006 This parameter can be used to provide identifying information in 1007 addition to what is present in the HOSTNAME field. It might be 1008 especially useful if the host's IP address is included in the message 1009 while the HOSTNAME field still contains the FQDN. It is also useful 1010 for describing all IP addresses of a multihomed host. 1012 If an originator has multiple IP addresses, it MAY either list one of 1013 its IP addresses in the "ip" parameter or it MAY include multiple 1014 "ip" parameters in a single "origin" structured data element. 1016 7.2.2. enterpriseId 1018 The "enterpriseId" parameter MUST be a 'SMI Network Management 1019 Private Enterprise Code', maintained by IANA, whose prefix is 1020 iso.org.dod.internet.private.enterprise (1.3.6.1.4.1). The number 1021 that follows is unique and may be registered by an on-line form at 1022 . An enterprise is only 1023 authorized to assign values within the 1024 iso.org.dod.internet.private.enterprise. subtree 1025 assigned by IANA to that enterprise. The enterpriseId MUST contain 1026 only a value from the 1027 iso.org.dod.internet.private.enterprise. subtree. In 1028 general, only the IANA-assigned enterpriseID is needed (a single 1029 number). An enterprise might decide to use sub-identifiers below its 1030 enterpriseID. If sub-identifiers are used, they MUST be separated by 1031 periods and be represented as decimal numbers. An example for that 1032 would be "0.1.2". Please note that the id "0.1.2" is just an example 1033 and MUST NOT be used. The complete up-to-date list of Enterprise 1034 Numbers is maintained by IANA at 1035 . 1037 By specifying an enterpriseId, the vendor allows more specific 1038 processing of the message. 1040 7.2.3. software 1042 The "software" parameter uniquely identifies the software that 1043 generated the message. If it is used, "enterpriseId" SHOULD also be 1044 specified, so that a specific vendor's software can be identified. 1045 The "software" parameter is not the same as the APP-NAME header 1046 field. It MUST always contain the name of the generating software, 1047 whereas APP-NAME can contain anything else, including an operator- 1048 configured value. 1050 The "software" parameter is a string. It MUST NOT be longer than 48 1051 characters. 1053 7.2.4. swVersion 1055 The "swVersion" parameter uniquely identifies the version of the 1056 software that generated the message. If it is used, the "software" 1057 and "enterpriseId" parameters SHOULD be provided, too. 1059 The "swVersion" parameter is a string. It MUST NOT be longer than 32 1060 characters. 1062 7.2.5. Example 1064 The following is an example with multiple IP addresses: 1066 [origin ip="192.0.2.1" ip="192.0.2.129"] 1068 In this example, the originator indicates that it has two ip 1069 addresses, one being 192.0.2.1 and the other one being 192.0.2.129. 1071 7.3. meta 1073 The SD-ID "meta" MAY be used to provide meta-information about the 1074 message. The following parameters can be used. All parameters are 1075 OPTIONAL. If the "meta" SD-ID is used, at least one parameter SHOULD 1076 be specified. 1078 7.3.1. sequenceId 1080 The "sequenceId" parameter tracks the sequence in which the syslog 1081 application submits messages to the syslog transport for sending. It 1082 is an integer that MUST be set to 1 when the syslog function is 1083 started and MUST be increased with every message up to a maximum 1084 value of 2147483647. If that value is reached, the next message MUST 1085 be sent with a sequenceId of 1. 1087 7.3.2. sysUpTime 1089 The "sysUpTime" parameter MAY be used to include the SNMP "sysUpTime" 1090 parameter in the message. Its syntax and semantics are as defined in 1091 [RFC3418]. 1093 As syslog does not support the SNMP "INTEGER" syntax directly, the 1094 value MUST be represented as a decimal integer (no decimal point) 1095 using only the characters "0", "1", "2", "3", "4", "5", "6", "7", 1096 "8", and "9". 1098 Note that the semantics in RFC3418 are "The time (in hundredths of a 1099 second) since the network management portion of the system was last 1100 re-initialized." This of course relates to the SNMP-related 1101 management portion of the system, which MAY be different than the 1102 syslog-related management portion of the system. 1104 7.3.3. language 1106 The "language" parameter MAY be specified by the originator to convey 1107 information about the natural language used inside MSG. If it is 1108 specified, it MUST contain a language identifier as defined in BCP 47 1109 [RFC4646]. 1111 8. Security Considerations 1113 8.1. UNICODE 1115 This document uses UTF-8 encoding for the PARAM-VALUE and MSG fields. 1116 There are a number of security issues with UNICODE. Any implementer 1117 and operator is advised to review UNICODE TR36 [UNICODE-TR36] (UTR36) 1118 to learn about these issues. This document guards against the 1119 technical issues outlined in UTR36 by REQUIRING "shortest form" 1120 encoding for syslog applications. However, the visual spoofing due 1121 to character confusability still persists. This document tries to 1122 minimize the effects of visual spoofing by allowing UNICODE only 1123 where local script is expected and needed. In all other fields, US- 1124 ASCII is REQUIRED. Also, the PARAM-VALUE and MSG fields should not 1125 be the primary source for identifying information, further reducing 1126 the risks associated with visual spoofing. 1128 8.2. Control Characters 1130 This document does not impose any mandatory restrictions on the MSG 1131 or PARAM-VALUE content. As such, they MAY contain control 1132 characters, including the NUL character. 1134 In some programming languages (most notably C and C++), the NUL 1135 character (ABNF %d00) traditionally has a special significance as 1136 string terminator. Most implementations of these languages assume 1137 that a string will not extend beyond the first NUL character. This 1138 is primarily a restriction of the supporting run-time libraries. 1139 This restriction is often carried over to programs and script 1140 languages written in those languages. As such, NUL characters must 1141 be considered with great care and be properly handled. An attacker 1142 may deliberately include NUL characters to hide information after 1143 them. Incorrect handling of the NUL character may also invalidate 1144 cryptographic checksums that are transmitted inside the message. 1146 Many popular text editors are also written in languages with this 1147 restriction. Encoding NUL characters when writing to text files is 1148 advisable. If they are stored without encoding, the file can become 1149 unreadable. 1151 Other control characters may also be problematic. For example, an 1152 attacker may deliberately include backspace characters to render 1153 parts of the log message unreadable. Similar issues exist for almost 1154 all control characters. 1156 Finally, invalid UTF-8 sequences may be used by an attacker to inject 1157 ASCII control characters. 1159 This specification permits a syslog application to reformat control 1160 characters received. Among others, the security risks associated 1161 with control characters were an important driving force behind this 1162 restriction. Originators are advised that if any encoding other than 1163 ASCII and UTF8 are used, the receiver may corrupt the message in an 1164 attempt to filter ASCII control characters. 1166 8.3. Message Truncation 1168 Message truncation can be misused by an attacker to hide vital log 1169 information. Messages over the minimum supported size may be 1170 discarded or truncated by the transport receiver. As such, vital log 1171 information may be lost. 1173 In order to prevent information loss, messages should not be longer 1174 than the minimum maximum size required by Section 6.1. For best 1175 performance and reliability, messages should be as small as possible. 1176 Important information should be placed as early in the message as 1177 possible because information at the beginning of the message is less 1178 likely to be discarded by a size-limited transport receiver. 1180 An originator should limit the size of any user-supplied data within 1181 a syslog message. If it does not, an attacker may provide large data 1182 in hopes of exploiting a potential weakness. 1184 8.4. Replay 1186 There is no mechanism in the syslog protocol to detect message 1187 replay. An attacker may record a set of messages that indicate 1188 normal activity of a machine. At a later time, that attacker may 1189 remove that machine from the network and replay the syslog messages 1190 to the relay or collector. Even with the TIMESTAMP field in the 1191 HEADER part, an attacker may record the packets and could simply 1192 modify them to reflect the current time before retransmitting them. 1193 The administrators may find nothing unusual in the received messages, 1194 and their receipt would falsely indicate normal activity of the 1195 machine. 1197 Cryptographically signing messages could prevent the alteration of 1198 TIMESTAMPs and thus the replay attack. 1200 8.5. Reliable Delivery 1202 Because there is no mechanism described within this document to 1203 ensure delivery, and the underlying transport may be unreliable 1204 (e.g., UDP) some messages may be lost. They may either be dropped 1205 through network congestion, or they may be maliciously intercepted 1206 and discarded. The consequences of dropping one or more syslog 1207 messages cannot be determined. If the messages are simple status 1208 updates, then their non-receipt may not be noticed, or it may cause 1209 an annoyance for the system operators. On the other hand, if the 1210 messages are more critical, then the administrators may not become 1211 aware of a developing and potentially serious problem. Messages may 1212 also be intercepted and discarded by an attacker as a way to hide 1213 unauthorized activities. 1215 It may also be desirable to include rate-limiting features in syslog 1216 originators and relays. This can reduce potential congestion 1217 problems when message bursts happen. 1219 Reliable delivery may not always be desirable. Reliable delivery 1220 means that the syslog originator or relay must block when the relay 1221 or collector is not able to accept any more messages. In some 1222 operating systems, namely Unix/Linux, the syslog originator or relay 1223 runs inside a high-priority system process (syslogd). If that 1224 process blocks, the system at large comes to a stand-still. The same 1225 occurs if there is a deadlock situation between syslogd and e.g. the 1226 DNS server. 1228 To prevent these problems, reliable delivery can be implemented in a 1229 way that intentionally discards messages when the syslog application 1230 would otherwise block. The advantage of reliable delivery in this 1231 case is that the syslog originator or relay knowingly discards the 1232 message and is able to notify the relay or collector about that fact. 1233 So the relay or collector receives the information that something is 1234 lost. With unreliable delivery, the message would simply be lost 1235 without any indication that loss occurred. 1237 8.6. Congestion Control 1239 Because syslog can generate unlimited amounts of data, transferring 1240 this data over UDP is generally problematic, because UDP lacks 1241 congestion control mechanisms. Congestion control mechanisms that 1242 respond to congestion by reducing traffic rates and establish a 1243 degree of fairness between flows that share the same path are vital 1244 to the stable operation of the Internet [RFC2914]. This is why the 1245 syslog TLS transport is REQUIRED to implement and RECOMMENDED for 1246 general use. 1248 The only environments where the syslog UDP transport MAY be used as 1249 an alternative to the TLS transport are managed networks, where the 1250 network path has been explicitly provisioned for UDP syslog traffic 1251 through traffic engineering mechanisms, such as rate limiting or 1252 capacity reservations. In all other environments, the TLS transport 1253 SHOULD be used. 1255 In any implementation, the situation may arise in which an originator 1256 or relay would need to block sending messages. A common case is when 1257 an internal queue is full. This might happen due to rate-limiting or 1258 slow performance of the syslog application. In any event, it is 1259 highly RECOMMENDED that no messages be dropped but that they should 1260 be temporarily stored until they can be transmitted. However, if 1261 they must be dropped, it is RECOMMENDED that the originator or relay 1262 drop messages of lower severity in favor of higher severity messages. 1263 Messages with a lower numberical SEVERITY value have a higher 1264 practical severity than those with a numerically higher value. In 1265 that situation, the messages that are to be dropped SHOULD simply be 1266 discarded. The syslog application may notify a collector or relay 1267 about the fact that it has dropped messages. 1269 8.7. Message Integrity 1271 Besides being discarded, syslog messages may be damaged in transit, 1272 or an attacker may maliciously modify them. In such cases, the 1273 original contents of the message will not be delivered to the 1274 collector or relay. Additionally, if an attacker is positioned 1275 between the transport sender and transport receiver of syslog 1276 messages, they may be able to intercept and modify those messages 1277 while in-transit to hide unauthorized activities. 1279 8.8. Message Observation 1281 While there are no strict guidelines pertaining to the MSG format, 1282 most syslog messages are generated in human readable form with the 1283 assumption that capable administrators should be able to read them 1284 and understand their meaning. The syslog protocol does not have 1285 mechanisms to provide confidentiality for the messages in transit. 1286 In most cases passing clear-text messages is a benefit to the 1287 operations staff if they are sniffing the packets from the wire. The 1288 operations staff may be able to read the messages and associate them 1289 with other events seen from other packets crossing the wire to track 1290 down and correct problems. Unfortunately, an attacker may also be 1291 able to observe the human-readable contents of syslog messages. The 1292 attacker may then use the knowledge gained from those messages to 1293 compromise a machine or do other damage. 1295 Operators are advised to use a secure transport mapping to avoid this 1296 problem. 1298 8.9. Inappropriate Configuration 1300 Because there is no control information distributed about any 1301 messages or configurations, it is wholly the responsibility of the 1302 network administrator to ensure that the messages are actually going 1303 to the intended recipients. Cases have been noted where syslog 1304 applications were inadvertently configured to send syslog messages to 1305 the wrong relays or collectors. In many cases, the inadvertent 1306 relays or collectors may not be configured to receive syslog messages 1307 and it will probably discard them. In certain other cases, the 1308 receipt of syslog messages has been known to cause problems for the 1309 unintended recipient. If messages are not going to the intended 1310 recipient, then they cannot be reviewed or processed. 1312 Using a reliable transport mapping can help identify some of these 1313 problems. For example, it can identify a problem where a message is 1314 being sent to a system that is not configured to receive messages. 1315 It cannot identify sending messages to a wrong machine that is 1316 accepting messages. 1318 8.10. Forwarding Loop 1320 As shown in Diagram 2, machines may be configured to relay syslog 1321 messages to subsequent relays before reaching a collector. In one 1322 particular case, an administrator found that he had mistakenly 1323 configured two relays to forward messages with certain SEVERITY 1324 values to each other. When either of these machines either received 1325 or generated that type of message, it would forward it to the other 1326 relay. That relay would, in turn, forward it back. This cycle did 1327 cause degradation to the intervening network as well as to the 1328 processing availability on the two devices. Network administrators 1329 must take care not to cause such a death spiral. 1331 8.11. Load Considerations 1333 Network administrators must take the time to estimate the appropriate 1334 capacity of the syslog collector. An attacker may perform a Denial 1335 of Service attack by filling the disk of the collector with false 1336 messages. Placing the records in a circular file may alleviate this 1337 but that has the consequence of not ensuring that an administrator 1338 will be able to review the records in the future. Along this line, a 1339 transport receiver must have a network interface capable of receiving 1340 the messages sent to it. 1342 Administrators and network planners must also critically review the 1343 network paths between the originators, the relays, and the 1344 collectors. Generated syslog messages should not overwhelm any of 1345 the network links. 1347 In order to reduce the impact of this issue, using transports with 1348 guaranteed delivery is recommended. 1350 8.12. Denial of Service 1352 As with any system, an attacker may just overwhelm a transport 1353 receiver by sending more messages to it than can be handled by the 1354 infrastructure or the device itself. implementers should attempt to 1355 provide features that minimize this threat, such as only accepting 1356 syslog messages from known IP addresses. 1358 9. IANA Considerations 1360 9.1. VERSION 1362 IANA is requested to create a registry entitled "syslog version 1363 values" of VERSION values as described in Section 6.2.2. Version 1364 numbers MUST be incremented for any new syslog protocol specification 1365 that changes any part of the HEADER. Changes include addition or 1366 removal of fields or a change of syntax or semantics of existing 1367 fields. 1369 VERSION numbers must be registered via the Standards Action method as 1370 described in [RFC2434]. IANA is requested to register the VERSIONs 1371 shown in table 4 below. 1373 VERSION FORMAT 1374 1 Defined in RFCYYYY 1376 Table 4. IANA-registered VERSIONs. 1378 9.2. SD-IDs 1380 IANA is requested to create a registry entitled "syslog structured 1381 data id values" of Structured Data ID (SD-ID) values together with 1382 their associated PARAM-NAME values as described in Section 7. 1384 New SD-ID and new PARAM-NAME values must be registered through the 1385 IETF CONSENSUS method as described in [RFC2434]. 1387 Once SD-IDs and SD-PARAMs are defined, syntax and semantics of these 1388 objects MUST NOT be altered. Should a change to an existing object 1389 be desired, a new SD-ID or SD-PARAM MUST be created and the old one 1390 remain unchanged. 1392 A provision is made here for locally extensible names. The IANA will 1393 not register, and will not control names with the at-sign (ABNF %d64) 1394 in them. 1396 IANA is requested to register the SD-IDs and PARAM-NAMEs shown in 1397 table 5 below. 1399 SD-ID PARAM-NAME 1400 timeQuality OPTIONAL 1401 tzKnown OPTIONAL 1402 isSynced OPTIONAL 1403 syncAccuracy OPTIONAL 1405 origin OPTIONAL 1406 ip OPTIONAL 1407 enterpriseId OPTIONAL 1408 software OPTIONAL 1409 swVersion OPTIONAL 1411 meta OPTIONAL 1412 sequenceId OPTIONAL 1413 sysUpTime OPTIONAL 1414 language OPTIONAL 1416 Table 5. IANA-registered SD-IDs and their PARAM-NAMEs. 1418 10. Working Group 1420 The working group can be contacted via the mailing list: 1422 syslog@ietf.org 1424 The current Chairs of the Working Group may be contacted at: 1426 Chris Lonvick 1427 Cisco Systems 1428 Email: clonvick@cisco.com 1430 David Harrington 1431 Huawei Technologies USA 1432 Email: dbharrington@comcast.net 1434 11. Acknowledgments 1436 The authors wish to thank Chris Lonvick, Jon Callas, Andrew Ross, 1437 Albert Mietus, Anton Okmianski, Tina Bird, Devin Kowatch, David 1438 Harrington, Sharon Chisholm, Richard Graveman, Tom Petch, Dado 1439 Colussi, Clement Mathieu, Didier Dalmasso, and all other people who 1440 commented on various versions of this proposal. 1442 12. Notes to the RFC Editor 1444 This is a note to the RFC editor. This ID is submitted along with 1445 draft-ietf-syslog-transport-udp and draft-ietf-syslog-transport-tls. 1446 These documents cross-reference each other. When RFC numbers are 1447 determined for each of these IDs, replace ietf-syslog-transport-udp 1448 with the proper RFC number for draft-ietf-syslog-transport-udp and 1449 replace I-D.ietf-syslog-transport-tls with the proper RFC number for 1450 draft-ietf-syslog-transport-tls and remove this note. 1452 This document uses the term "RFCYYYY" for self-references. When a 1453 RFC number is assigned to it, replace YYYY with the proper RFC number 1454 and remove this note. 1456 13. References 1458 13.1. Normative References 1460 [ANSI.X3-4.1968] American National Standards 1461 Institute, "USA Code for Information 1462 Interchange", ANSI X3.4, 1968. 1464 [RFC1034] Mockapetris, P., "Domain names - 1465 concepts and facilities", STD 13, 1466 RFC 1034, November 1987. 1468 [RFC1035] Mockapetris, P., "Domain names - 1469 implementation and specification", 1470 STD 13, RFC 1035, November 1987. 1472 [RFC2119] Bradner, S., "Key words for use in 1473 RFCs to Indicate Requirement 1474 Levels", BCP 14, RFC 2119, 1475 March 1997. 1477 [RFC3629] Yergeau, F., "UTF-8, a 1478 transformation format of ISO 10646", 1479 STD 63, RFC 3629, November 2003. 1481 [RFC4234] Crocker, D., Ed. and P. Overell, 1482 "Augmented BNF for Syntax 1483 Specifications: ABNF", RFC 4234, 1484 October 2005. 1486 [RFC3339] Klyne, G. and C. Newman, "Date and 1487 Time on the Internet: Timestamps", 1488 RFC 3339, July 2002. 1490 [RFC2434] Narten, T. and H. Alvestrand, 1491 "Guidelines for Writing an IANA 1492 Considerations Section in RFCs", 1493 BCP 26, RFC 2434, October 1998. 1495 [RFC2914] Floyd, S., "Congestion Control 1496 Principles", BCP 41, RFC 2914, 1497 September 2000. 1499 [RFC4291] Hinden, R. and S. Deering, "IP 1500 Version 6 Addressing Architecture", 1501 RFC 4291, February 2006. 1503 [RFC3418] Presuhn, R., "Management Information 1504 Base (MIB) for the Simple Network 1505 Management Protocol (SNMP)", STD 62, 1506 RFC 3418, December 2002. 1508 [RFC4646] Phillips, A. and M. Davis, "Tags for 1509 Identifying Languages", BCP 47, 1510 RFC 4646, September 2006. 1512 [UNICODE-TR36] Davis, M. and M. Suignard, "UNICODE 1513 Security Considerations", July 2005, 1514 . 1517 [I-D.ietf-syslog-transport-udp] Okmianski, A., "Transmission of 1518 syslog messages over UDP", 1519 draft-ietf-syslog-transport-udp-10 1520 (work in progress), August 2007. 1522 [I-D.ietf-syslog-transport-tls] Miao, F. and Y. Ma, "TLS Transport 1523 Mapping for Syslog", 1524 draft-ietf-syslog-transport-tls-10 1525 (work in progress), May 2007. 1527 13.2. Informative References 1529 [RFC3164] Lonvick, C., "The BSD Syslog 1530 Protocol", RFC 3164, August 2001. 1532 Appendix A. implementer Guidelines 1534 Information in this section is given as an aid to implementers. 1535 While this information is considered to be helpful, it is not 1536 normative. As such, an implementation is NOT REQUIRED to follow it 1537 in order to claim compliance to this specification. 1539 A.1. Relationship with BSD Syslog 1541 While BSD syslog is in widespread use, its format has never been 1542 formally standardized. [RFC3164] describes observed formats. It is 1543 an INFORMATIONAL RFC, and practice shows that there are many 1544 different implementations. Research during creation of this document 1545 showed that there is very little in common between different syslog 1546 implementations on different platforms. The only thing that all of 1547 them agree upon is that messages start with "<" PRIVAL ">". Other 1548 than that, legacy syslog messages are not formatted in a consistent 1549 way. Consequently, RFC 3164 describes no specific elements inside a 1550 syslog message. It states that any message destined to the syslog 1551 UDP port must be treated as a syslog message, no matter what its 1552 format or content is. 1554 This document retains the PRI value syntax and semantics. This will 1555 allow legacy syslog implementations to put messages generated by 1556 syslog applications compliant to this specification into the right 1557 bins. 1559 Most existing implementations support UDP as the transport protocol 1560 for syslog. This specification REQUIRES UDP support in compliant 1561 implementations, and allows additional transport protocols to be 1562 used. 1564 RFC 3164 describes relay behavior. This document does not specify 1565 relay behavior. This might be done in a separate document. 1567 The TIMESTAMP described in RFC 3164 offers less precision than the 1568 timestamp specified in this document. It also lacks the year and 1569 time zone information. If a message formatted according to this 1570 document needs to be reformatted to be in RFC 3164 format, it is 1571 suggested that the originator's local time zone be used, and the time 1572 zone information and the year be dropped. If a RFC 3164 formatted 1573 message is received and must be transformed to be compliant to this 1574 document, the current year should be added and the time zone of the 1575 relay or collector MAY be used. 1577 The HOSTNAME in RFC 3164 is less specific, but this format is still 1578 supported in this document as one of the alternate HOSTNAME 1579 representations. 1581 The MSG part of the message is described as TAG and CONTENT in RFC 1582 3164. In this document, MSG is what was called CONTENT in RFC 3164. 1583 The TAG is now part of the header, but not as a single field. The 1584 TAG has been split into APP-NAME, PROCID, and MSGID. This does not 1585 totally resemble the usage of TAG, but provides the same 1586 functionality for most of the cases. 1588 In RFC 3164, STRUCTURED-DATA was not described. If a message 1589 compliant with this document contains STRUCTURED-DATA and must be 1590 reformatted according to RFC 3164, the STRUCTURED-DATA simply becomes 1591 part of the RFC 3164 CONTENT free-form text. 1593 In general, this document tries to provide an easily parseable header 1594 with clear field separations whereas traditional BSD syslog suffers 1595 from some historically developed, hard to parse field separation 1596 rules. 1598 A.2. Message Length 1600 Implementers should note the message size limitations outlined in 1601 Section 6.1 and try to keep the most important data early in the 1602 message (within the minimum guaranteed length). This ensures the 1603 data will be seen by the collector or relay even if a transport 1604 receiver at a relay on the message path truncates the message. 1606 The reason syslog transport receivers need only support receiving up 1607 to and including 480 octets has, among other things, to do with 1608 difficult delivery problems in a broken network. Syslog messages may 1609 use a UDP transport mapping with this 480 octet restriction to avoid 1610 session overhead and message fragmentation. In a network with 1611 problems, the likelihood of getting one single-packet message 1612 delivered successfully is higher than getting two message fragments 1613 delivered successfully. Therefore using a larger size may prevent 1614 the operator from getting some critical information about the 1615 problem, whereas using small messages might get that information to 1616 the operator. It is recommended that messages intended for 1617 troubleshooting purposes should not be larger than 480 octets. To 1618 further strengthen this point, it has also been observed that some 1619 UDP implementations generally do not support message sizes of more 1620 then 480 octets. This behavior is very rare and may no longer be an 1621 issue. 1623 There are other use cases where syslog messages are used to transmit 1624 inherently lengthy information, e.g. audit data. By not enforcing 1625 any upper limit on the message size, syslog applications can be 1626 implemented with any size needed and still be compliant with this 1627 document. In such cases, it is the operator's responsibility to 1628 ensure that all components in a syslog infrastructure support the 1629 required message sizes. Transport mappings may recommend specific 1630 message size limits that must be implemented to be compliant. 1632 Implementers are reminded that the message length is specified in 1633 octets. There is a potentially large difference between the length 1634 in characters and the length in octets for UTF-8 strings. 1636 It must be noted that the IPv6 MTU is about 2.5 times 480. An 1637 implementation targeted towards an IPv6-only environment might thus 1638 assume this as a larger minimum size. 1640 A.3. Severity Values 1642 This section describes guidelines for using Severity as outlined in 1643 Section 6.2.1. 1645 All implementations should try to assign the most appropriate 1646 severity to their message. Most importantly, messages designed to 1647 enable debugging or testing of software should be assigned severity 1648 7. Severity 0 should be reserved for messages of very high 1649 importance (like serious hardware failures or imminent power 1650 failure). An implementation may use severities 0 and 7 for other 1651 purposes if this is configured by the administrator. 1653 Because severities are very subjective, a relay or collector should 1654 not assume that all originators have the same definition of severity. 1656 A.4. TIME-SECFRAC Precision 1658 The TIMESTAMP described in Section 6.2.3 supports fractional seconds. 1659 This provides grounds for a very common coding error, where leading 1660 zeros are removed from the fractional seconds. For example, the 1661 TIMESTAMP "2003-10-11T22:13:14.003" may be erroneously written as 1662 "2003-10-11T22:13:14.3". This would indicate 300 milliseconds 1663 instead of the 3 milliseconds actually meant. 1665 A.5. Case Convention for Names 1667 Names are used at various places in this document, for example for 1668 SD-IDs and PARAM-NAMEs. This document uses "lower camel case" 1669 consistently. With that, each name begins with a lower case letter 1670 and each new embedded word starts with an upper case letter, with no 1671 hyphen or other delimiter. An example of this is "timeQuality". 1673 While an implementation is free to use any other case convention for 1674 experimental names, it is suggested that the case convention outlined 1675 above is followed. 1677 A.6. Syslog Applications Without Knowledge of Time 1679 In Section 6.2.3, the NILVALUE has been allowed for usage by 1680 originators without knowledge of time. This is done to support a 1681 special case when a syslog application is not aware of time at all. 1682 It can be argued whether such a syslog application can actually be 1683 found in today's IT infrastructure. However, discussion has 1684 indicated that those things may exist in practice and as such there 1685 should be a guideline established for this case. 1687 However, an implementation SHOULD emit a valid TIMESTAMP if the 1688 underlying operating system, programming system, and hardware 1689 supports a clock function. A proper TIMESTAMP should be emitted even 1690 if it is difficult to obtain the system time. The NILVALUE should 1691 only be used when it is actually impossible to obtain time 1692 information. This rule should not be used as an excuse for lazy 1693 implementations. 1695 A.7. Notes on the timeQuality SD-ID 1697 It is recommended that the value of "0" be the default for the 1698 "tzKnown" (Section 7.1.1) parameter. It should only be changed to 1699 "1" after the administrator has specifically configured the time 1700 zone. The value "1" may be used as the default if the underlying 1701 operating system provides accurate time zone information. It is 1702 still advised that the administrator consider the correctness of the 1703 time zone information. 1705 It is important not to create a false impression of accuracy with the 1706 timeQuality SD-ID (Section 7.1). An originator should only indicate 1707 a given accuracy if it actually knows it is within these bounds. It 1708 is generally assumed that the originator gains this in-depth 1709 knowledge through operator configuration. By default, an accuracy 1710 should not be provided. 1712 A.8. UTF-8 encoding and the BOM 1714 This document specifies that SD-PARAMS must always be encoded in 1715 UTF-8. Other encodings of the message in the MSG portion, including 1716 ASCIIPRINT, are not permitted by a device conforming to this 1717 specification. There are two cases that need to be addressed here. 1718 First, a syslog application conforming to this specification may not 1719 be able to ascertain that the information given to it from an 1720 originator is encoded in UTF-8. If it cannot determine that with 1721 certainty, the syslog application may choose to not incorporate the 1722 BOM in the MSG. If the syslog application has a good indication that 1723 the content of the message is encoded in UTF-8 then it should include 1724 the BOM. In the second case, a syslog relay may be forwarding a 1725 message from a device that does not conform to this specification. 1726 In that case, the device would likely not include the BOM unless it 1727 has ascertained that the received message was encoded in UTF-8. 1729 Author's Address 1731 Rainer Gerhards 1732 Adiscon GmbH 1733 Mozartstrasse 21 1734 Grossrinderfeld, BW 97950 1735 Germany 1737 EMail: rgerhards@adiscon.com 1739 Full Copyright Statement 1741 Copyright (C) The IETF Trust (2007). 1743 This document is subject to the rights, licenses and restrictions 1744 contained in BCP 78, and except as set forth therein, the authors 1745 retain all their rights. 1747 This document and the information contained herein are provided on an 1748 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1749 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1750 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1751 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1752 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1753 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1755 Intellectual Property 1757 The IETF takes no position regarding the validity or scope of any 1758 Intellectual Property Rights or other rights that might be claimed to 1759 pertain to the implementation or use of the technology described in 1760 this document or the extent to which any license under such rights 1761 might or might not be available; nor does it represent that it has 1762 made any independent effort to identify any such rights. Information 1763 on the procedures with respect to rights in RFC documents can be 1764 found in BCP 78 and BCP 79. 1766 Copies of IPR disclosures made to the IETF Secretariat and any 1767 assurances of licenses to be made available, or the result of an 1768 attempt made to obtain a general license or permission for the use of 1769 such proprietary rights by implementers or users of this 1770 specification can be obtained from the IETF on-line IPR repository at 1771 http://www.ietf.org/ipr. 1773 The IETF invites any interested party to bring to its attention any 1774 copyrights, patents or patent applications, or other proprietary 1775 rights that may cover technology that may be required to implement 1776 this standard. Please address the information to the IETF at 1777 ietf-ipr@ietf.org. 1779 Acknowledgement 1781 Funding for the RFC Editor function is provided by the IETF 1782 Administrative Support Activity (IASA).