Hi Tom and All,
What I've seen discussed:
- There is no character or character sequence that cannot be used in the
syslog payload, which might confuse a parser looking to delineate
messages in a single packet based upon a character or character
sequence.
- Byte counting can provide assurance for the delineation of messages.
- {Some | Most | All} syslog daemons already escape LF so a non-escaped LF
could be used to delineate messages.
Is this correct?
Since it's come up on the list before as a concern, what will be done if
people start putting binary information into the syslog message payload?
Will that always have to be escaped by the sender and reversed by the
receiver?
Thanks,
Chris
On Mon, 14 Aug 2006, Tom Petch wrote:
----- Original Message -----
From: "David Harrington" <[EMAIL PROTECTED]>
To: "'Chris Lonvick'" <[EMAIL PROTECTED]>; "'Miao Fuyou'" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "'Tom Petch'" <[EMAIL PROTECTED]>
Sent: Friday, August 04, 2006 7:59 PM
Subject: RE: [Syslog] delineated datagrams
As you probably know by now, I like to see design reuse across IETF NM
solutions, especially across SNMP, syslog, ipfix, and netconf where
feasible.
As all the IETF NM protocols move toward similar secure transport
solutions, including moving from datagrams to streams, it would be a
good thing to use consistent aproaches to framing.
Here is what is happening in the other IETF NM protocols:
<snip>
>
The NETCONF protocol uses an RPC-based communication model.
From
http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-12.txt:
NETCONF peers use <rpc> and <rpc-reply> elements to provide
transport
protocol-independent framing of NETCONF requests and responses.
Ok as far as it goes but incomplete. As the ssh mapping says,
" As the previous example illustrates, a special character sequence,
]]>]]>, MUST be sent by both the client and the server after each XML
document in the NETCONF exchange. This character sequence cannot
legally appear in an XML document, so it can be unambigiously used to
indentify the end of the current document in the event of an XML
syntax or parsing error, allowing resynchronization of the NETCONF
exchange."
.
Wishing to promote design reuse across IETF NM solutions, especially across the
character-based ones, I did propose the same separator for syslog over tls and
still see it as the technically best solution (even though our message content
can be anything and so, unlike NETCONF, we cannot rely 100% on that not
appearing in our message content).
David Harrington
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
