doc: Add RFC documents

1 files changed, 2019 insertions, 0 deletions

diff --git a/doc/rfc/rfc3195.txt b/doc/rfc/rfc3195.txt
new file mode 100644
index 0000000..d52c9a2
--- /dev/null
+++ b/doc/rfc/rfc3195.txt
@@ -0,0 +1,2019 @@
+
+
+
+
+
+
+Network Working Group                                             D. New
+Request for Comments: 3195                                       M. Rose
+Category: Standards Track                   Dover Beach Consulting, Inc.
+                                                           November 2001
+
+
+                      Reliable Delivery for syslog
+
+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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   The BSD Syslog Protocol describes a number of service options related
+   to propagating event messages.  This memo describes two mappings of
+   the syslog protocol to TCP connections, both useful for reliable
+   delivery of event messages.  The first provides a trivial mapping
+   maximizing backward compatibility.  The second provides a more
+   complete mapping.  Both provide a degree of robustness and security
+   in message delivery that is unavailable to the usual UDP-based syslog
+   protocol, by providing encryption and authentication over a
+   connection-oriented protocol.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+New & Rose                  Standards Track                     [Page 1]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+Table of Contents
+
+   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.    The Model  . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.    The RAW Profile  . . . . . . . . . . . . . . . . . . . . . .  7
+   3.1   RAW Profile Overview . . . . . . . . . . . . . . . . . . . .  7
+   3.2   RAW Profile Identification and Initialization  . . . . . . .  9
+   3.3   RAW Profile Message Syntax . . . . . . . . . . . . . . . . . 10
+   3.4   RAW Profile Message Semantics  . . . . . . . . . . . . . . . 10
+   4.    The COOKED Profile . . . . . . . . . . . . . . . . . . . . . 11
+   4.1   COOKED Profile Overview  . . . . . . . . . . . . . . . . . . 11
+   4.2   COOKED Profile Identification and Initialization . . . . . . 11
+   4.3   COOKED Profile Message Syntax  . . . . . . . . . . . . . . . 11
+   4.4   COOKED Profile Message Semantics . . . . . . . . . . . . . . 12
+   4.4.1 The IAM Element  . . . . . . . . . . . . . . . . . . . . . . 12
+   4.4.2 The ENTRY Element  . . . . . . . . . . . . . . . . . . . . . 14
+   4.4.3 The PATH Element . . . . . . . . . . . . . . . . . . . . . . 19
+   5.    Additional Provisioning  . . . . . . . . . . . . . . . . . . 25
+   5.1   Message Authenticity . . . . . . . . . . . . . . . . . . . . 25
+   5.2   Message Replay . . . . . . . . . . . . . . . . . . . . . . . 25
+   5.3   Message Integrity  . . . . . . . . . . . . . . . . . . . . . 25
+   5.4   Message Observation  . . . . . . . . . . . . . . . . . . . . 26
+   5.5   Summary of Recommended Practices . . . . . . . . . . . . . . 26
+   6.    Initial Registrations  . . . . . . . . . . . . . . . . . . . 27
+   6.1   Registration: The RAW Profile  . . . . . . . . . . . . . . . 27
+   6.2   Registration: The COOKED Profile . . . . . . . . . . . . . . 27
+   7.    The syslog DTD . . . . . . . . . . . . . . . . . . . . . . . 28
+   8.    Reply Codes  . . . . . . . . . . . . . . . . . . . . . . . . 32
+   9.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 33
+   9.1   Registration: BEEP Profiles  . . . . . . . . . . . . . . . . 33
+   9.2   Registration: The System (Well-Known) TCP port number for
+            syslog-conn . . . . . . . . . . . . . . . . . . . . . . . 33
+   10.   Security Considerations  . . . . . . . . . . . . . . . . . . 34
+   11.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
+   12.   References . . . . . . . . . . . . . . . . . . . . . . . . . 34
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 36
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+New & Rose                  Standards Track                     [Page 2]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+1. Introduction
+
+   The syslog protocol [1] presents a spectrum of service options for
+   provisioning an event-based logging service over a network.  Each
+   option has associated benefits and costs.  Accordingly, the choice as
+   to what combination of options is provisioned is both an engineering
+   and administrative decision.  This memo describes how to realize the
+   syslog protocol when reliable delivery is selected as a required
+   service.  It is beyond the scope of this memo to argue for, or
+   against, the use of reliable delivery for the syslog protocol.
+
+   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 [2].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+New & Rose                  Standards Track                     [Page 3]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+2. The Model
+
+   The syslog service supports three roles of operation: device, relay,
+   and collector.
+
+   Devices and collectors act as sources and sinks, respectively, of
+   syslog entries.  In the simplest case, only a device and collector
+   are present.  E.g.,
+
+     +--------+        +-----------+
+     | Device | -----> | Collector |
+     +--------+        +-----------+
+
+   The relationship between devices and collectors is potentially many-
+   to-many.  I.e., a device might communicate with many collectors;
+   similarly, a collector might communicate with many devices.
+
+   A relay operates in both modes, accepting syslog entries from devices
+   and other relays and forwarding those entries to collectors and other
+   relays.
+
+   For example,
+
+     +--------+      +-------+        +-------+      +-----------+
+     | Device | ---> | Relay | -...-> | Relay | ---> | Collector |
+     +--------+      +-------+        +-------+      +-----------+
+
+   As shown, more than one relay may be present between any particular
+   device and collector.
+
+   A relay may be necessary for administrative reasons.  For example, a
+   relay might run as an application proxy on a firewall.  Also, there
+   might be one relay per company department, which authenticates all
+   the devices in the department, and which in turn authenticates itself
+   to a company-wide collector.
+
+   A relay can also serve to filter messages.  For example, one relay
+   may collect the syslog information from an entire web server farm,
+   summarizing hit counts for report generation, forwarding "page not
+   found" messages (indicating a possible broken link) to a collector
+   that presents it to the webmaster, and sending more urgent messages
+   (such as hardware failure reports) to a collector that gateways them
+   to a pager.  A relay may also be used to convert formats from a
+   device's output to a collector's input.
+
+   It should be noted that a role of device, relay, or collector is
+   relevant only to a particular BEEP channel (q.v., below).  A single
+   server can serve as a device, a relay, and a collector, all at once,
+
+
+
+New & Rose                  Standards Track                     [Page 4]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+   if so configured.  It can even serve as a relay and a collector to
+   the same device at the same time using different BEEP channels over
+   the same connection-oriented session; this might be useful to collect
+   status yet relay urgent error messages.
+
+   To provide reliable delivery when realizing the syslog protocol, this
+   memo defines two BEEP profiles.  BEEP [3] is a generic application
+   protocol framework for connection-oriented, asynchronous
+   interactions.  Within BEEP, features such as authentication, privacy,
+   and reliability through retransmission are provided.  There are two
+   profiles defined in this memo:
+
+   o  The RAW profile is designed to provide a high-performance, low-
+      impact footprint, using essentially the same format as the
+      existing UDP-based syslog service.
+
+   o  The COOKED profile is designed to provide a structured entry
+      format, in which individual entries are acknowledged (either
+      positively or negatively).
+
+   Note that both profiles run over BEEP.  BEEP defines "transport
+   mappings," specifying how BEEP messages are carried over the
+   underlying transport technologies.  At the time of this writing, only
+   one such transport is defined, in [4], which specifies BEEP over TCP.
+   All transport mappings are required to support enough reliability and
+   sequencing to allow all BEEP messages on a given channel to be
+   delivered reliably and in order.  Hence, both the RAW and COOKED
+   profile provide reliable delivery of their messages.
+
+   The choice of profile is independent of the operational roles
+   discussed above.
+
+   For example, in
+
+     +--------+        +-------+        +-----------+
+     | Device | -----> | Relay | -----> | Collector |
+     +--------+        +-------+        +-----------+
+
+   the device-to-relay link could be configured to use the RAW profile,
+   while the relay-to-collector link could be configured to use the
+   COOKED profile.  (For example, the relay may be parsing the RAW
+   syslog messages from the device, knowing the details of their
+   formats, before passing them to a more generic collector.) Indeed,
+   the same device may use different profiles, depending on the
+   collector to which it is sending entries.
+
+
+
+
+
+
+New & Rose                  Standards Track                     [Page 5]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+   Devices and relays MAY discover relays and collectors via the DNS SRV
+   algorithm [5].  If so configured, the service used is "syslog" and
+   the protocol used is "tcp".  This allows for central administration
+   of addressing, fallback for failed relays and collectors, and static
+   load balancing.  Security policies and hardware configurations may be
+   such that device configuration is more secure than the DNS server.
+   Hardware devices may be of such limited resources that DNS SRV access
+   is inappropriate.  Firewalls and other restrictive routing mechanisms
+   may need to be dealt with before a reliable syslog connection can be
+   established.  In these cases, DNS might not be the most appropriate
+   configuration mechanism.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+New & Rose                  Standards Track                     [Page 6]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+3. The RAW Profile
+
+3.1 RAW Profile Overview
+
+   The RAW profile is designed for minimal implementation effort, high
+   efficiency, and backwards compatibility.  It is appropriate
+   especially in cases where legacy syslog processing will be applied.
+
+   It should be noted that even though the RAW profile uses the same
+   format for message payloads as the UDP version of syslog uses,
+   delivery is reliable.  The RAW syslog profile is a profile of BEEP
+   [3], and BEEP guarantees ordered reliable delivery of messages within
+   each individual channel.
+
+   When the profile is started, no piggyback data is supplied.  All BEEP
+   messages in the RAW profile are specified as having a MIME Content-
+   Type [6] of application/octet-stream.  Once the channel is open, the
+   listener (not the initiator) sends a MSG message indicating it is
+   ready to act as a syslog sink.  (Refer to [3]'s Section 2.1 for a
+   discussion of roles that a BEEP peer may perform, including
+   definitions of the terms "listener", "initiator", "client", and
+   "server".)
+
+   The initiator uses ANS replies to supply one or more syslog entries
+   in the current UDP format, as specified in [1]'s Section 3.  When the
+   initiator has no more entries to send, it finishes with a NUL reply
+   and closes the channel.
+
+   An example might appear as follows:
+
+      L: <wait for incoming connection>
+      I: <establish connection>
+      L: RPY 0 0 . 0 201
+      L: Content-type: application/beep+xml
+      L:
+      L: <greeting>
+      L:   <profile
+      L:     uri='http://xml.resource.org/profiles/syslog/COOKED' />
+      L:   <profile uri='http://xml.resource.org/profiles/syslog/RAW' />
+      L: </greeting>
+      L: END
+      I: RPY 0 0 . 0 52
+      I: Content-type: application/beep+xml
+      I:
+      I: <greeting />
+      I: END
+      I: MSG 0 1 . 52 133
+      I: Content-type: application/beep+xml
+
+
+
+New & Rose                  Standards Track                     [Page 7]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+      I:
+      I: <start number='1'>
+      I:   <profile uri='http://xml.resource.org/profiles/syslog/RAW' />
+      I: </start>
+      I: END
+      L: RPY 0 1 . 201 100
+      L: Content-type: application/beep+xml
+      L:
+      L: <profile uri='http://xml.resource.org/profiles/syslog/RAW' />
+      L: END
+      L: MSG 1 0 . 0 50
+      L:
+      L: Central Services. This has not been a recording.
+      L: END
+      I: ANS 1 0 . 0 61 0
+      I:
+      I: <29>Oct 27 13:21:08 ductwork imxpd[141]: Heating emergency.END
+      I: ANS 1 0 . 61 58 1
+      I:
+      I: <29>Oct 27 13:22:15 ductwork imxpd[141]: Contact Tuttle.END
+      I: NUL 1 0 . 119 0
+      I: END
+      L: MSG 0 3 . 301 70
+      L: Content-Type: application/beep+xml
+      L:
+      L: <close number='1' code='200' />
+      L: END
+      I: RPY 0 3 . 185 46
+      I: Content-Type: application/beep+xml
+      I:
+      I: <ok />
+      I: END
+      I: MSG 0 4 . 231 72
+      I: Content-Type: application/beep+xml
+      I:
+      I: <close number='0' code='200' />
+      I: END
+      L: RPY 0 4 . 371 46
+      L: Content-type: application/beep+xml
+      L:
+      L: <ok />
+      L: END
+      L: <closes connection>
+      I: <closes connection>
+      L: <awaits next connection>
+
+
+
+
+
+
+New & Rose                  Standards Track                     [Page 8]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+   Here we see a BEEP session established, followed by the use of the
+   RAW profile.  The initiator is a device, while the listener is a
+   collector.  The initiator opens the channel, but the listener sends
+   the first MSG.  This allows the initiator to send any number of ANS
+   replies carrying syslog event messages.  The initiator sends a NUL
+   reply to indicate it is finished.  Upon receiving the NUL, the
+   listener closes the RAW channel.  The initiator has the choice of
+   closing the entire BEEP session or opening a new syslog channel (RAW
+   or COOKED) for more transfers.  In this example, the initiator
+   chooses to close the entire BEEP session.
+
+   The overhead for one ANS frame is about thirty octets, once the
+   initial handshakes have been exchanged.  If this overhead is too
+   high, then messages are likely being generated at a high rate.  In
+   this case, multiple syslog messages can be aggregated into a single
+   ANS frame, each separated by a CRLF sequence from the preceding.  The
+   final message still MUST NOT end with a CRLF.
+
+   For example,
+
+      L: MSG 1 0 . 0 50
+      L:
+      L: Central Services. This has not been a recording.
+      L: END
+      I: ANS 1 0 . 0 119 0
+      I:
+      I: <29>Oct 27 13:21:08 ductwork imxpd[141]: Heating emergency.
+      I: <29>Oct 27 13:21:09 ductwork imxpd[141]: Contact Tuttle.END
+      I: NUL 1 0 . 119 0
+      I: END
+
+3.2 RAW Profile Identification and Initialization
+
+   The RAW syslog profile is identified as
+
+           http://xml.resource.org/profiles/syslog/RAW
+
+   in the BEEP "profile" element during channel creation.
+
+   No data is piggybacked during channel creation.
+
+
+
+
+
+
+
+
+
+
+
+New & Rose                  Standards Track                     [Page 9]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+3.3 RAW Profile Message Syntax
+
+   All BEEP messages in this profile have a MIME content-type of
+   application/octet-stream.  The listener's first BEEP message is
+   ignored and indeed may be empty except for headers; hence, any syntax
+   is acceptable.
+
+   The ANS replies the initiator sends in response MUST be formatted
+   according to Section 4 of [1].  In particular, If the receiver is
+   acting as a relay, then it MUST follow the rules as laid out in
+   Section 4.2.2 of [1].
+
+   If multiple syslog messages are included in a single ANS reply, each
+   is separated from the preceding with a CRLF.  There is no ending
+   delimiter, but each syslog event message body length MUST be 1024
+   bytes or less, excluding BEEP framing overhead.  Note that there MUST
+   NOT be a CRLF between the text of the final syslog event message and
+   the "END" marking the trailer of the BEEP frame.
+
+3.4 RAW Profile Message Semantics
+
+   The listener's opening BEEP MSG message has no semantics.  (It is a
+   good place to put in an identifying greeting.) The initiator's ANS
+   replies MUST specify a facility, severity, and textual message, as
+   described in [1].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+New & Rose                  Standards Track                    [Page 10]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+4. The COOKED Profile
+
+4.1 COOKED Profile Overview
+
+   The COOKED profile is designed for new implementations of syslog
+   protocol handlers.  It provides a much finer grain of information
+   tagging, allowing a better degree of automation in processing.
+   Naturally, it includes more overhead as well in support of this.
+
+   The COOKED profile supports three elements of interest:
+
+   o  The "iam" element identifies the sender to the receiver, allowing
+      each peer to name itself for the other, and specifying the roles
+      (device, relay, or collector) each is taking on.
+
+   o  The "entry" element provides a parsed version of the syslog entry,
+      with the various fields of interest broken out.
+
+   o  The "path" element identifies a list of relays through which a
+      tagged collection of "entry" elements has passed, along with a set
+      of flags indicating what assurances of security have been in
+      effect throughout its delivery.
+
+4.2 COOKED Profile Identification and Initialization
+
+   The COOKED syslog profile is identified as
+
+       http://xml.resource.org/profiles/syslog/COOKED
+
+   in the BEEP "profile" element during channel creation.
+
+   During channel creation, the corresponding "profile" element in the
+   BEEP "start" element may contain an "iam" element.  If channel
+   creation is successful, then before sending the corresponding reply,
+   the BEEP peer processes the "iam" element and includes the resulting
+   response in the reply.  This response will be an "ok" element or an
+   "error" element.  The choice of which element is returned is
+   dependent on local provisioning of the recipient.  Including an "iam"
+   in the initial "start" element has exactly the same semantics as
+   passing it as the first MSG message on the channel.
+
+4.3 COOKED Profile Message Syntax
+
+   All BEEP messages in this profile have a MIME Content-Type [6] of
+   application/beep+xml.  The syntax of the individual elements is
+   specified in Section 7.
+
+
+
+
+
+New & Rose                  Standards Track                    [Page 11]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+4.4 COOKED Profile Message Semantics
+
+   Initiators issue two elements: "iam" and "entry", each using a "MSG"
+   message.  The listener issues "ok" in "RPY" messages and "error" in
+   "ERR" messages.  (See [3]'s Section 2.3.1 for the definitions of the
+   "error" and "ok" elements.)
+
+4.4.1 The IAM Element
+
+   The "iam" element serves to identify a device, relay, or collector at
+   one end of the BEEP channel to the device, relay, or collector at the
+   other end of the channel.  The "iam" element includes the type of
+   peer (device, relay, or collector), the fully qualified domain name
+   of the peer, and an IP address of the peer.  (The IP address chosen
+   SHOULD be the IP address associated with the underlying transport
+   protocol carrying the channel.)  The character data of the element is
+   free-form human-readable text.  It may be used to further identify
+   the peer, such as by describing the physical location of the machine.
+
+   An "iam" element may be sent by the initiator of the channel at any
+   time.  The listener responds to an "iam" element with an "ok"
+   (indicating acceptance), or an "error" (indicating rejection).  The
+   identity and role in effect is specified by the most recent "iam"
+   answered with an "ok".
+
+   An "iam" could be rejected (with an "error" element) by the listener
+   if the privacy or authentication that has been negotiated is
+   inadequate or if the authenticated user does not have authorization
+   to serve in the specified role.  It is expected that most
+   installations will require an "iam" from the peer before accepting
+   any "entry" messages.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+New & Rose                  Standards Track                    [Page 12]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+   For example, a successful creation might look like this:
+
+      I: MSG 0 10 . 1832 259
+      I: Content-type: application/beep+xml
+      I:
+      I: <start number='1'>
+      I:   <profile
+      I:       uri='http://xml.resource.org/profiles/syslog/COOKED'>
+      I:     <![CDATA[ <iam fqdn='lowry.example.com' ip='10.0.0.27'
+      I:       type='device'/> ]]>
+      I:   </profile>
+      I: </start>
+      L: END
+      L: RPY 0 10 . 704 138
+      L: Content-type: application/beep+xml
+      L:
+      L: <profile uri='http://xml.resource.org/profiles/syslog/COOKED'>
+      L:   <![CDATA[ <ok /> ]]>
+      L: </profile>
+      L: END
+
+   A creation with an embedded "iam" that fails might look like this:
+
+      C: MSG 0 12 . 1832 259
+      C: Content-type: application/beep+xml
+      C:
+      C: <start number='1'>
+      C:   <profile
+      C:       uri='http://xml.resource.org/profiles/syslog/COOKED'>
+      C:     <![CDATA[ <iam fqdn='tuttle.example.com' ip='10.0.0.29'
+      C:       type='relay'/> ]]>
+      C:   </profile>
+      C: </start>
+      C: END
+      S: RPY 0 12 . 704 241
+      S: Content-type: application/beep+xml
+      S:
+      S: <profile uri='http://xml.resource.org/profiles/syslog/COOKED'>
+      S:   <![CDATA[
+      S:     <error code='535'>User 'buttle.example.com' not allowed
+      S:       to "iam" for 'tuttle.example.com'</error> ]]>
+      S: </profile>
+      S: END
+
+   In this case, the error code indicates that the user
+   "buttle.example.com" has logged in via some SASL profile, but the
+   syslog COOKED profile implementation is claiming to be
+   "tuttle.example.com", a mismatch that the server is disallowing.
+
+
+
+New & Rose                  Standards Track                    [Page 13]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+4.4.2 The ENTRY Element
+
+   The "entry" element carries the details of a single syslog entry. The
+   attributes of an "entry" element include "facility", "severity",
+   "timestamp", "hostname", and "tag".  "Facility" and "severity" have
+   the semantics defined in [1]'s 4.1.  The other attributes have the
+   semantics as in Sections 4.2.1 and 4.2.3 of [1].  An "entry" element
+   can also contain a "pathID" attribute, described below.
+
+   If the client is a relay, the "entry" SHOULD also contain the
+   attributes "deviceFQDN" and "deviceIP", specifying the FQDN and IP
+   address of the device that originally created the entry.  These
+   attributes may be added by either the relay or the originating
+   device.  If possible, the device SHOULD add these entries, referring
+   to the interface most closely associated with the syslog entry.
+   Before a relay forwards an entry from a device that does not carry
+   these attributes, it SHOULD add them based on the "iam" element it
+   has received from the device, or based on the underlying transport
+   connection address.  A relay MUST NOT add these fields if they are
+   missing and an "iam" element on the channel has indicated that
+   messages are coming from another relay.
+
+   The "pathID" attribute indicates the path over which this entry has
+   travelled, from device through relays to the final collector.
+   Syntactically, its value is a string of digits that must match the
+   "pathID" attribute of a "path" element sent earlier over the current
+   channel.  Semantically, it indicates that the list of relays and
+   flags indicated in that earlier "path" element apply to this "entry"
+   element.
+
+   The character data for the element is the unstructured syslog event
+   message being logged.  If the original device delivers the message
+   for the first time via the COOKED profile, it may have any structure
+   inside the CDATA.  However, for maximum compatibility, the device
+   SHOULD format the CDATA of the message in accordance with Sections
+   4.2.1 through 4.2.3 of [1].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+New & Rose                  Standards Track                    [Page 14]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+   In the message is being relayed, "tag" SHOULD be those of the
+   original device generating the entry (unless the device cannot supply
+   a tag).  The "timestamp" SHOULD be that of the original entry
+   generation time, rather than the time the entry was passed outward
+   from the relay.  The "hostname" SHOULD be the host name or IP address
+   by which the device knows itself; this MUST follow the rules
+   established in Sections 4.2.1 through 4.2.3 of [1].  The original
+   contents of the syslog message MUST be preserved in the CDATA of the
+   "entry" element; this includes preservation of exact content during
+   translation from the UDP or RAW formats.  In particular, the
+   timestamps MUST NOT be rewritten in the CDATA of the "entry" element,
+   the tag MUST NOT be removed from the CDATA even if presented in the
+   "entry" attributes as well, and so on.
+
+   To be consistent with the spirit of [1], a relay receiving a message
+   that does not contain a valid priority, timestamp or hostname will
+   follow the same general rules as described in section 4.2.2 of [1]
+   while including the exact contents of the received syslog packet as
+   the CDATA.  The values of the facility and severity will be construed
+   to be 8 and 6 respectively and will be placed into the appropriate
+   attributes of the "entry" element.  The hostname will be the name of
+   the device as it is known to the relay and will also be inserted into
+   the "entry" element's attributes.  The timestamp would be set to the
+   received time, inserted only into the attributes of the "entry"
+   element.  As an example, consider this message received on UDP port
+   514 and interpreted as a traditional syslog message, assuming the
+   underlying IP source address is that of the "pipeworks" machine:
+
+     <.....eeeek!
+
+   To be relayed, it must be modified as follows:
+
+         C: MSG 1 0 . 2079 156
+         C: Content-Type: application/beep+xml
+         C:
+         C: <entry facility='8' severity='6'
+         C:   hostname='pipeworks'
+         C:   timestamp='Oct 31 23:59:59'
+         C:  >&lt;.....eeeek!</entry>
+         C: END
+         S: RPY 1 0 . 933 45
+         S: Content-Type: application/beep+xml
+         S:
+         S: <ok/>
+         S: END
+
+
+
+
+
+
+New & Rose                  Standards Track                    [Page 15]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+   As another example, consider a message being received that does not
+   properly adhere to the conventions described in Section 4.2.2 of [1].
+   In particular, the timestamp has a year, making it a nonstandard
+   format:
+
+        <166> 1990 Oct 22 01:00:00 bomb tick[0]: BOOM!
+
+   This would be relayed as follows:
+
+         C: MSG 1 0 . 2235 242
+         C: Content-Type: application/beep+xml
+         C:
+         C: <entry facility='160' severity='6'
+         C:   hostname='bomb'
+         C:   deviceFQDN='bomb.terrorist.net' deviceIP='10.0.0.83'
+         C:   timestamp='Oct 22 01:00:04'
+         C:  >&lt;166> 1990 Oct 22 01:00:00 bomb tick[0]: BOOM!</entry>
+         C: END
+         S: RPY 1 0 . 978 45
+         S: Content-Type: application/beep+xml
+         S:
+         S: <ok/>
+         S: END
+
+   Note that the tag value was not readily apparent from the received
+   message (due to the failed parsing of the timestamp), so it was not
+   included in the "entry" element.
+
+   It is explicitly permitted for a relay to parse raw messages in a
+   more sophisticated way, but all implementations MUST be able to parse
+   messages presented in the format described in [1].  A more
+   sophisticated relay could have recognized the year and completely
+   parsed out the correct time, tag, and hostname, but such additional
+   parsing capability is OPTIONAL.
+
+   Consider the following example, in contrast:
+
+        <166> Oct 22 01:00:00 bomb tick[0]: BOOM!
+
+
+
+
+
+
+
+
+
+
+
+
+
+New & Rose                  Standards Track                    [Page 16]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+   This conformant message would be relayed as follows:
+
+         C: MSG 1 0 . 2477 248
+         C: Content-Type: application/beep+xml
+         C:
+         C: <entry facility='160' severity='6'
+         C:   hostname='bomb'
+         C:   deviceFQDN='bomb.terrorist.net' deviceIP='10.0.0.83'
+         C:   timestamp='Oct 22 01:00:00' tag='tick'
+         C:  >&lt;166> Oct 22 01:00:00 bomb tick[0]: BOOM!</entry>
+         C: END
+         S: RPY 1 0 . 1023 45
+         S: Content-Type: application/beep+xml
+         S:
+         S: <ok/>
+         S: END
+
+   In this case, the tag is detected and the timestamp represents the
+   message generation time rather than the message reception time.
+
+   Finally, the "entry" element may also contain an "xml:lang"
+   attribute, indicating the language in which the CDATA content of the
+   tag is presented, as described in [7].
+
+   The "entry" element is answered with either an empty "ok" element if
+   everything was successful, or a standard "error" element if there was
+   a problem.  An "entry" element can be rejected if no "iam" element
+   has been accepted by the listener.  It can also be rejected if the
+   user authenticated on the BEEP session (if any) does not have the
+   authority to generate (as a device) or relay that entry.  An error is
+   also possible if the "pathID" attribute refers to an unknown (or
+   rejected) "path" element.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+New & Rose                  Standards Track                    [Page 17]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+   A successful exchange of an "entry" element may look like this:
+
+      C: MSG 1 0 . 2725 173
+      C: Content-Type: application/beep+xml
+      C:
+      C: <entry facility='24' severity='5'
+      C:   timestamp='Jan 26 15:16:17'
+      C:   hostname='pipework' tag='imxp'>
+      C:     No 27B/6 available</entry>
+      C: END
+      S: RPY 1 0 . 1068 45
+      S: Content-Type: application/beep+xml
+      S:
+      S: <ok/>
+      S: END
+
+   Here, the device IP address and FQDN are taken from the "iam"
+   element, if any, or from the underlying connection information.
+
+   An example where an "entry" element is rejected with an "error"
+   element:
+
+      C: MSG 1 2 . 2898 223
+      C: Content-Type: application/beep+xml
+      C:
+      C: <entry facility='24' severity='5' timestamp='Jan 02 13:22:15'
+      C:   deviceFQDN='jack.example.net' deviceIP='10.0.0.83'
+      C:   tag='imxpd'>
+      C:     Replacement device found in nostril.
+      C: </entry>
+      C: END
+      S: ERR 1 2 . 1113 111
+      S: Content-Type: application/beep+xml
+      S:
+      S: <error code='554'>Not allowed to relay for
+      S:    jack.example.net</error>
+      S: END
+
+   Here, the client attempts to relay an entry on behalf of
+   jack.example.com, but the entry is refused by the collector for
+   administrative reasons.  This may occur, for example, if
+   lowry.example.com is in a different department than jack.example.com.
+
+
+
+
+
+
+
+
+
+New & Rose                  Standards Track                    [Page 18]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+4.4.3 The PATH Element
+
+   The "path" element serves to describe a list of the relays through
+   which that element has passed, along with a set of flags that
+   indicate the properties that all links from the device to the relay
+   have shared in common.  Each "path" element contains either another
+   "path" element or is empty.  An empty "path" element identifies a
+   device, while a "path" element with a nested "path" element
+   identifies a relay.  Each "path" element names a FQDN and IP address
+   of the interface that sent the element.  Each "path" element also
+   names a FQDN and IP address for the interface that received the
+   element.  Each "path" element also carries a "linkprops" attribute,
+   specifying the properties of the link it describes.
+
+   Each "path" element has a "pathID" attribute which must be unique for
+   all "path" elements sent on this channel since its inception.
+   Syntactically, the "pathID" attribute is a string of digits.
+   Semantically, it serves to identify one "path" element out of many,
+   and it serves to link a "path" element with one or more "entry"
+   elements.  Any "pathID" attribute is unrelated to any "pathID"
+   attribute in nested "path" elements or on other channels.
+
+   Each "path" element has a "fromFQDN" attribute and an "fromIP"
+   attribute.  The "fromFQDN" attribute SHOULD be the fully qualified
+   domain name of the interface over which the "path" element was sent.
+   (The "fromFQDN" can be omitted if that interface has no DNS entry.)
+   Similarly, the "fromIP" attribute MUST be the IP address of the
+   interface over which the "path" element was sent.
+
+   Each "path" element has a "toFQDN" attribute and an "toIP" attribute.
+   The "toFQDN" attribute SHOULD be the fully qualified domain name of
+   the interface over which the "path" element was received.  (The
+   "toFQDN" can be omitted if that interface has no DNS entry.)
+   Similarly, the "toIP" attribute MUST be the IP address of the
+   interface over which the "path" element was received.
+
+   Finally, each "path" element carries a "linkprops" attribute.  This
+   is syntactically a string of individual characters, each indicating
+   one property of the channel over which this "path" element is being
+   carried.  Note that outer "path" elements may have stronger
+   guarantees than inner "path" elements; care should be taken in the
+   interpretation of flags.  The semantics of each possible character in
+   this string are as follows:
+
+
+
+
+
+
+
+
+New & Rose                  Standards Track                    [Page 19]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+   o: When present, "o" (lower-case letter "o") indicates that weak
+      privacy has been negotiated over this link, weakly protecting from
+      observation the content of entries associated with this "path"
+      element.  (Weak privacy is encryption with less than 80 bits of
+      key.)
+
+   O: When present, "O" (upper-case letter "O") indicates that strong
+      privacy has been negotiated over this link, strongly protecting
+      from observation the content of entries associated with this
+      "path" element.  (Strong privacy is encryption with 80 bits or
+      more of key, or a transfer mechanism that is otherwise impossible
+      to eavesdrop upon.)
+
+   U: When present, "U" indicates that a valid user has been
+      authenticated (via SASL or TLS) and an "iam" element has been
+      accepted.
+
+   A: When present, "A" indicates that this link has been protected by
+      an authentication layer, authenticating the source of every
+      "entry" associated with this path.
+
+   R: When present, "R" indicates that this link has been protected
+      against message replay.
+
+   I: When present, "I" indicates that this link has been protected
+      against modifications of messages in passing.  ("I" stands for
+      message Integrity.)
+
+   L: When present, "L" indicates that this link has been protected
+      against loss of messages.  That is, this is a reliable delivery
+      link.
+
+   D: When present, "D" indicates that the "from" side of this link is a
+      device.  If this is not present on the innermost "path" element,
+      "entry" elements associated with this path have not been carried
+      by the COOKED profile for their entire lifetime.
+
+   Upon receiving a "path" element, the peer MUST perform the following
+   checks:
+
+   o  The "fromFQDN" and "fromIP" must match the underlying transport
+      connection.
+
+   o  The flags in the "linkprops" attribute must match the attributes
+      of the session.
+
+   o  The "toFQDN" and "toIP" must match the underlying transport
+      connection.
+
+
+
+New & Rose                  Standards Track                    [Page 20]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+   o  The "pathID" attribute must be unique with respect to all other
+      "path" elements received on this channel.
+
+   If all these checks pass, the "path" element is accepted with an "ok"
+   element.  Otherwise, an "error" element is generated with an
+   appropriate code.  In addition, if any of the nested "path" elements
+   refer to the machine receiving the element, it may indicate a routing
+   loop in the configuration for the so-identified path, and appropriate
+   measures should be taken.
+
+   If the peer receiving an "entry" element is receiving it directly
+   from a device via either syslog-conn profile, and the device has not
+   generated a "path" element, the receiver may itself generate an
+   appropriate "path" element, either to be recorded in the logs (if
+   this peer is a collector) or passed to the next peer (if this peer is
+   a relay).  If a peer receives a syslog message via UDP, it may
+   optionally generate an appropriate "peer" element based on any
+   cryptographic information provided in the message itself.
+
+   When a peer receives a "path" element, it remembers it for future
+   use.  A collector will store it in the log for later reference.  A
+   relay will remember it.  When an "entry" arrives referencing the
+   received "path" element, and that entry needs to be forwarded to
+   another relay or collector, and no appropriate "path" element has
+   already been generated, an appropriate "path" element is generated
+   and sent over the outbound channel before the entry is forwarded.  An
+   appropriate "path" element is created by taking the received "path"
+   element, wrapping it in a new "path" element with the appropriate
+   attributes, and assigning it a new "pathID" attribute.  When future
+   "entry" elements arrive with the same incoming "pathID" attribute,
+   and they need to be forwarded to a channel over which an appropriate
+   "pathID" attribute has already been sent, only the "pathID" attribute
+   of the "entry" element needs to be rewritten to refer to the "path"
+   element on the outgoing channel.
+
+   It should be noted that the majority of the complexity in managing
+   "path" elements arises only in relays.  In particular, devices never
+   need to generate "path" elements and collectors need only verify
+   them, log them, and possibly use them in displays and reports.
+   Collectors do not need to generate "path" elements or rewrite "entry"
+   elements.  Hence, only in complex configurations (where they are most
+   useful) do complex "path" configurations occur.
+
+
+
+
+
+
+
+
+
+New & Rose                  Standards Track                    [Page 21]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+   For example, here is a path element sent from
+   lowry.records.example.com to kurtzman.records.example.com.  It
+   indicates that entries from lowry to kurtzman tagged with
+   pathID='173' originated from screen.lowry.records.example.com.  It
+   indicates that screen.lowry.records.example.com is believed by
+   lowry.records.example.com to be the originating device, and that
+   entries over this path are delivered without loss and without
+   modification, although messages might be replayed or observed.  The
+   link between lowry and kurtzman, however, avoids replay attacks, lost
+   messages, and modifications to messages.  While
+   screen.lowry.records.example.com has not authenticated itself to
+   lowry.records.example.com, lowry claims to have authenticated itself
+   to kurtzman.
+
+      C: MSG 2 1 . 3121 426
+      C: Content-type: application/beep+xml
+      C:
+      C: <path fromFQDN='lowry.records.example.com'
+      C:       fromIP='10.0.0.50'
+      C:       toFQDN='kurtzman.records.example.com'
+      C:       toIP='10.0.0.51'
+      C:       linkprops='ULRI'
+      C:       pathID='173'>
+      C: <path fromFQDN='screen.lowry.records.example.com'
+      C:       fromIP='10.0.0.47'
+      C:       toFQDN='lowry.records.example.com'
+      C:       toIP='10.0.0.50'
+      C:       linkprops='DLI'
+      C:       pathID='24'>
+      C: </path>
+      C: </path>
+      C: END
+      S: ERR 2 1 . 1224 114
+      S: Content-type: application/beep+xml
+      S:
+      S: <error code='530'>linkprops includes 'U'
+      S:   but no 'iam' received</error>
+      S: END
+
+   However, kurtzman.records.example.com rejects the "path" element,
+   since the "linkprops" attribute claims that lowry has authenticated
+   itself, but kurtzman disagrees, not having received an "iam" element.
+
+
+
+
+
+
+
+
+
+New & Rose                  Standards Track                    [Page 22]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+   In a second example, this "path" element informs
+   collector.example.com that the records department's firewall will be
+   forwarding "entry" elements with a "pathID" attribute whose value is
+   "17".  These "entry" elements will be coming in on the "10.0.0.2"
+   interface of the firewall, to be forwarded out the "134.130.74.56"
+   interface of the firewall.  The final hop has all possible
+   guarantees, although the entries transferred within the records
+   department (behind the firewall) may have been observed in passing.
+
+      C: MSG 2 2 . 3547 813
+      C: Content-type: application/beep+xml
+      C:
+      C: <path fromFQDN='fwall.records.example.com'
+      C:       fromIP='134.130.74.56'
+      C:       toFQDN='collector.example.com'
+      C:       toIP='134.130.74.12'
+      C:       linkprops='OUARIL'
+      C:       pathID='17'>
+      C: <path fromFQDN='kurtzman.records.example.com'
+      C:       fromIP='10.0.0.50'
+      C:       toFQDN='fwall.records.example.com'
+      C:       toIP='10.0.0.2'
+      C:       linkprops='ULRI'
+      C:       pathID='120'>
+      C: <path fromFQDN='lowry.records.example.com'
+      C:       fromIP='10.0.0.50'
+      C:       toFQDN='kurtzman.records.example.com'
+      C:       toIP='10.0.0.51'
+      C:       linkprops='ULRI'
+      C:       pathID='173'>
+      C: <path fromFQDN='screen.lowry.records.example.com'
+      C:       fromIP='10.0.0.47'
+      C:       toFQDN='lowry.records.example.com'
+      C:       toIP='10.0.0.50'
+      C:       linkprops='DLI'
+      C:       pathID='24'>
+      C: </path></path></path></path>
+      C: END
+      S: RPY 2 2 . 1338 45
+      S: Content-type: application/beep+xml
+      S:
+      S: <ok/>
+      S: END
+
+
+
+
+
+
+
+
+New & Rose                  Standards Track                    [Page 23]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+   As a final example, an "entry" element from Lowry's screen arrives at
+   the firewall.  The "path" attribute is rewritten, and it is forwarded
+   on to the collector.
+
+      The entry arrives on the 10.0.0.2 interface:
+
+      C: MSG 2 3 . 4360 250
+      C: Content-Type: application/beep+xml
+      C:
+      C: <entry facility='24' severity='5'
+      C:   timestamp='Oct 27 13:24:12'
+      C:   deviceFQDN='screen.lowry.records.example.com'
+      C:   deviceIP='10.0.0.47'
+      C:   pathID='173'
+      C:   tag='dvd'>
+      C:     Job paused - Boss watching.
+      C: </entry>
+      C: END
+      S: RPY 2 3 . 1383 45
+      S: Content-Type: application/beep+xml
+      S:
+      S: <ok/>
+      S: END
+
+      It is forwarded out the 134.130.74.56 interface:
+
+      C: MSG 7 9 . 9375 276
+      C: Content-Type: application/beep+xml
+      C:
+      C: <entry facility='24' severity='5'
+      C:   timestamp='Oct 27 13:24:12'
+      C:   deviceFQDN='screen.lowry.records.example.com'
+      C:   deviceIP='10.0.0.47'
+      C:   pathID='17'
+      C:   tag='dvd'>
+      C:     Job paused - Boss watching.
+      C: </entry>
+      C: END
+      S: RPY 7 9 . 338 45
+      S: Content-Type: application/beep+xml
+      S:
+      S: <ok/>
+      S: END
+
+   A discussion of the wisdom of configuring Lowry's machine to forward
+   such messages via Kurtzman's machine is beyond the scope of this
+   document.
+
+
+
+
+New & Rose                  Standards Track                    [Page 24]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+5. Additional Provisioning
+
+   In more advanced configurations, syslog devices, relays, and
+   collectors can be configured to support various delivery priorities.
+   Multiple channels running the same profile can be opened between two
+   peers, with higher priority syslog messages routed to a channel that
+   is given more bandwidth.  Such provisioning is a local matter.
+
+   syslog [1] discusses a number of reasons why privacy and
+   authentication of syslog entry messages may be important in a
+   networked computing environment.  The nature of BEEP allows for
+   convenient layering of authentication and privacy over any BEEP
+   channel.
+
+5.1 Message Authenticity
+
+   Section 6.2 of [1] discusses the dangers of unauthenticated syslog
+   entries.  To prevent inauthentic syslog event messages from being
+   accepted, configure syslog peers to require the use of a strong
+   authentication technology for the BEEP session.
+
+   If provisioned for message authentication, implementations SHOULD use
+   SASL mechanism DIGEST-MD5 [8] to provision this service.
+
+5.2 Message Replay
+
+   Section 6.3.4 of [1] discusses the dangers of syslog message replay.
+   To prevent syslog event messages from being replayed, configure
+   syslog peers to require the use of a strong authentication technology
+   for the BEEP session.
+
+   If provisioned to detect message replay, implementations SHOULD use
+   SASL mechanism DIGEST-MD5 [8] to provision this service.
+
+5.3 Message Integrity
+
+   Section 6.5 of [1] discusses the dangers of syslog event messages
+   being maliciously altered by an attacker.  To prevent messages from
+   being altered, configure syslog peers to require the use of a strong
+   authentication technology for the BEEP session.
+
+   If provisioned to protect message integrity, implementations SHOULD
+   use SASL mechanism DIGEST-MD5 [8] to provision this service.
+
+
+
+
+
+
+
+
+New & Rose                  Standards Track                    [Page 25]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+5.4 Message Observation
+
+   Section 6.6 of [1] discusses the dangers (and benefits) of syslog
+   messages being visible at intermediate points along the transmission
+   path between device and collector.  To prevent messages from being
+   viewed by an attacker, configure syslog peers to require the use of a
+   transport security profile for the BEEP session.  (However, other
+   traffic characteristics, e.g., volume and timing of transmissions,
+   remain observable.)
+
+   If provisioned to secure messages against unauthorized observation,
+   implementations SHOULD use the TLS profile [3] to provision this
+   service.  The cipher algorithm used SHOULD be
+   TLS_RSA_WITH_3DES_EDE_CBC_SHA.
+
+5.5 Summary of Recommended Practices
+
+   For the indicated protections, implementations SHOULD be configured
+   to use the indicated mechanisms:
+
+    Desired Protection  SHOULD tune using
+    ------------------  -----------------
+    Authentication      http://iana.org/beep/SASL/DIGEST-MD5
+      + Replay          http://iana.org/beep/SASL/DIGEST-MD5
+        + Integrity     http://iana.org/beep/SASL/DIGEST-MD5
+          + Observation http://iana.org/beep/TLS
+
+   BEEP peer identities used for authentication SHOULD correspond to the
+   FQDN of the initiating peer.  That is, a relay running on
+   relay.example.com should use a "user ID" of "relay.example.com"
+   within the SASL authentication profiles, as well as in the FQDN of
+   the "iam" element.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+New & Rose                  Standards Track                    [Page 26]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+6. Initial Registrations
+
+6.1 Registration: The RAW Profile
+
+   Profile Identification: http://xml.resource.org/profiles/syslog/RAW
+
+   Messages exchanged during Channel Creation: None
+
+   Messages starting one-to-one exchanges: Anything
+
+   Messages in positive replies: None
+
+   Messages in negative replies: None
+
+   Messages in one-to-many exchanges: Anything
+
+   Message Syntax: See Section 3.3
+
+   Message Semantics: See Section 3.4
+
+   Contact Information: See the "Authors' Addresses" section of this
+      memo
+
+6.2 Registration: The COOKED Profile
+
+   Profile Identification:
+      http://xml.resource.org/profiles/syslog/COOKED
+
+   Messages exchanged during Channel Creation: iam
+
+   Messages starting one-to-one exchanges: iam, entry, path
+
+   Messages in positive replies: ok
+
+   Messages in negative replies: error
+
+   Messages in one-to-many exchanges: None
+
+   Message Syntax: See Section 4.3
+
+   Message Semantics: See Section 4.4
+
+   Contact Information: See the "Authors' Addresses" section of this
+      memo
+
+
+
+
+
+
+
+New & Rose                  Standards Track                    [Page 27]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+7. The syslog DTD
+
+   The following is the DTD defining the valid elements for the syslog
+   over BEEP mapping.
+
+   <!--
+     DTD for syslog over BEEP, as of 2000-10-10
+
+     Refer to this DTD as:
+
+       <!ENTITY % SYSLOG PUBLIC "-//Blocks//DTD SYSLOGRELIABLE//EN" "">
+       %SYSLOG;
+     -->
+
+   <!--
+     Contents
+
+       Overview
+
+       Includes
+       Profile Summaries
+       Entity Definitions
+
+       Operations
+           iam
+           entry
+           path
+     -->
+
+   <!--
+     Overview
+
+       Syslog packets delivered via BEEP
+
+     -->
+
+   <!-- Includes -->
+
+          <!ENTITY % BEEP PUBLIC "-//Blocks//DTD BEEP//EN"
+                     "">
+          %BEEP;
+
+
+
+
+
+
+
+
+
+
+New & Rose                  Standards Track                    [Page 28]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+   <!--
+     Profile summaries
+
+       BEEP profile SYSLOG-RAW
+
+       role        MSG        ANS        ERR
+       ====        ===        ===        ===
+        L          text       text       text
+
+       BEEP profile SYSLOG-COOKED
+
+       role        MSG        RPY        ERR
+       ====        ===        ===        ===
+       I or L      iam        ok         error
+       I or L      entry      ok         error
+       I or L      path       ok         error
+
+   -->
+
+   <!--
+     Entity Definitions
+
+           entity        syntax/reference     example
+           ======        ================     =======
+       a fully qualified domain name
+           FQDN          See [RFC-1034]       www.example.com
+
+       a dotted-quad IP address
+           IP            1*3DIGIT "." 1*3DIGIT "."
+                          1*3DIGIT "." 1*3DIGIT
+                                              10.0.0.27
+       a syslog facility
+           FACILITY      See [1]
+                         1*3DIGIT             80
+
+       a syslog severity
+           SEVERITY      See [1]
+                         DIGIT                 4
+
+       a timestamp       See [1]               Jan 03 18:43:12
+           TIMESTAMP
+
+       an identifying integer
+           IDINT         1*DIGIT               1027
+
+   -->
+
+
+
+
+
+New & Rose                  Standards Track                    [Page 29]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+   <!ENTITY % FQDN         "CDATA">
+   <!ENTITY % IP           "CDATA">
+   <!ENTITY % FACILITY     "CDATA">
+   <!ENTITY % SEVERITY     "CDATA">
+   <!ENTITY % TIMESTAMP    "CDATA">
+   <!ENTITY % IDINT        "CDATA">
+
+
+   <!--
+     The iam element declares the role and identity of the peer
+     issuing it. The contents of the element may include human-readable
+     informative text, such as the physical location of the computer
+     issuing the "iam".
+
+     -->
+
+   <!ELEMENT iam         (#PCDATA)>
+   <!ATTLIST iam
+             fqdn        %FQDN;                   #REQUIRED
+             ip          %IP;                     #REQUIRED
+             type        (device|relay|collector) #REQUIRED>
+
+   <!--
+     The entry element conveys a single syslog message.
+     -->
+
+   <!ELEMENT entry       (#PCDATA)>
+   <!ATTLIST entry
+             xml:lang    %LANG;                   "i-default"
+             facility    %FACILITY;                #REQUIRED
+             severity    %SEVERITY;                #REQUIRED
+             timestamp   %TIMESTAMP;               #IMPLIED
+             tag         %ATEXT;                   #IMPLIED
+             deviceFQDN  %FQDN;                    #IMPLIED
+             deviceIP    %IP;                      #IMPLIED
+             pathID      %IDINT;                   #IMPLIED>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+New & Rose                  Standards Track                    [Page 30]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+   <!--
+     The path element conveys a list of relays through which
+     entries have passed.
+     -->
+
+   <!ELEMENT path        (path?)>
+   <!ATTLIST path
+             pathID      %IDINT;                   #REQUIRED
+             fromFQDN    %FQDN;                    #IMPLIED
+             fromIP      %IP;                      #REQUIRED
+             toFQDN      %FQDN;                    #IMPLIED
+             toIP        %IP;                      #REQUIRED
+             linkprops   %ATEXT;                   #REQUIRED>
+
+   <!-- End of DTD -->
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+New & Rose                  Standards Track                    [Page 31]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+8. Reply Codes
+
+   The following error codes are used in the protocol:
+
+   code    meaning
+   ====    =======
+   200     success
+
+   421     service not available
+
+   451     requested action aborted
+           (e.g., local error in processing)
+
+   454     temporary authentication failure
+
+   500     general syntax error
+           (e.g., poorly-formed XML)
+
+   501     syntax error in parameters
+           (e.g., non-valid XML)
+
+   504     parameter not implemented
+
+   530     authentication required
+
+   534     authentication mechanism insufficient
+           (e.g., too weak, sequence exhausted, etc.)
+
+   535     authentication failure
+
+   537     action not authorized for user
+
+   538     authentication mechanism requires encryption
+
+   550     requested action not taken
+           (e.g., no requested profiles are acceptable)
+
+   553     parameter invalid
+
+   554     transaction failed
+           (e.g., policy violation)
+
+
+
+
+
+
+
+
+
+
+New & Rose                  Standards Track                    [Page 32]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+9. IANA Considerations
+
+9.1 Registration: BEEP Profiles
+
+   The IANA registers the profiles specified in Section 6, and selects
+   IANA-specific URIs "http://iana.org/beep/SYSLOG/RAW" and
+   "http://iana.org/beep/SYSLOG/COOKED".
+
+9.2 Registration: The System (Well-Known) TCP port number for syslog-
+    conn
+
+   A single well-known port (601) is allocated to syslog-conn.  In-band
+   negotiation determines whether COOKED or RAW syslog-conn is in use.
+
+   Protocol Number: TCP
+
+   Message Formats, Types, Opcodes, and Sequences: See Section 3.3 and
+      Section 4.4.
+
+   Functions: See Section 3.4 and Section 4.4.
+
+   Use of Broadcast/Multicast: none
+
+   Proposed Name: Reliable syslog service
+
+   Short name: syslog-conn
+
+   Contact Information: See the "Authors' Addresses" section of this
+      memo
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+New & Rose                  Standards Track                    [Page 33]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+10. Security Considerations
+
+   Consult Section 6 of [1] for a discussion of security issues for the
+   syslog service.  In addition, since the RAW and COOKED profiles are
+   defined using the BEEP framework, consult [3]'s Section 8 for a
+   discussion of BEEP-specific security issues.
+
+   BEEP is used to provide communication security but not object
+   integrity.  In other words, the messages "on the wire" can be
+   protected, but a compromised device may undetectably generate
+   incorrect messages, and relays and collectors can modify, insert, or
+   delete messages undetectably.  Other techniques must be used to
+   assure that such compromises are detectable.
+
+11. Acknowledgements
+
+   The authors gratefully acknowledge the contributions of Christopher
+   Calabrese, Keith McCloghrie, Balazs Scheidler, and David Waitzman.
+
+12. References
+
+   [1]  Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.
+
+   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [3]  Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
+        3080, March 2001.
+
+   [4]  Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March
+        2001.
+
+   [5]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
+        specifying the location of services (DNS SRV)", RFC 2782,
+        February 2000.
+
+   [6]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+        Extensions (MIME) Part Two: Media Types", RFC 2046, November
+        1996.
+
+   [7]  Alvestrand, H., "Tags for the Identification of Languages", BCP
+        47, RFC 3066, January 2001.
+
+   [8]  Leach, P. and C. Newman, "Using Digest Authentication as a SASL
+        Mechanism", RFC 2831, May 2000.
+
+
+
+
+
+
+New & Rose                  Standards Track                    [Page 34]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+Authors' Addresses
+
+   Darren New
+   5390 Caminito Exquisito
+   San Diego, CA  92130
+   US
+
+   Phone: +1 858 350 9733
+   EMail: dnew@san.rr.com
+
+
+   Marshall T. Rose
+   Dover Beach Consulting, Inc.
+   POB 255268
+   Sacramento, CA  95865-5268
+   US
+
+   Phone: +1 916 483 8878
+   EMail: mrose@dbc.mtview.ca.us
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+New & Rose                  Standards Track                    [Page 35]
+
+RFC 3195              Reliable Delivery for syslog         November 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+New & Rose                  Standards Track                    [Page 36]
+