Sec 6.1: Truncation
Anton Okmianski (aokmians <aokmians <at> cisco.com>
2006-01-06 20:47:41 GMT
Rainer and all:
I started reading draft #16. Since we are revisiting everything... I am not very comfortable with the
current truncation rules.
"Receivers SHOULD follow this order of preference when it comes to truncation:
1) No truncation
2) Truncation by dropping SD-ELEMENTs
3) If 2) not sufficient, truncate MSG"
I don't think that this is a good recommendation. I would assume that in many cases people would try to
tokenize more important data into structured data and use message text as a secondary user-friendly
description. For example, for LINK_DOWN message, I would probably encode link ID in the structured
elements as this is something that should be readily available for receivers. The MSGID could be
"LINK_DOWN" and the MSG text may simply be "Link down". If you truncate the structured data, it makes it
I also think, in general it is useful to put more important data first, which is another reason for putting
more valuable data into structured data in a more compact way.
Additionally, structured data can be used to provide message length or digest, which can help receiver to
determine if message was truncated.
Also, I think this statement is very convoluted:
"Please note that it is possible that the MSG field is truncated without dropping any SD-PARAMS. This is the
case if a message with an empty STRUCTURED-DATA field must be truncated."
I think I understand what you are driving at, but I don't see it as adding any requirements or clarification.
This sentence is not clear although I know what you are trying to say:
"The limits below are minimum maximum lengths, not maximum length."
I propose replacing the entire section 6.1 with this text:
"Syslog message limits are dictated by the syslog transport mapping in use. Each transport mapping MUST
define the minimum required message length support. Any syslog transport mapping MUST support messages
of up to and including 480 octets in length.
Any syslog receiver MUST be able to accept messages of up to and including 480 octets in length. All receiver
implementations SHOULD be able to accept messages of up to and including 2048 octets in length. Receivers
MAY receive messages larger than 2048 octets in length. If a receiver receives a message with a length
larger than it supports, the receiver MAY discard the message or truncate the payload.
If truncation is performed by the receiver, it MUST first truncate the MSG field as necessary to meet the
supported length limit. If truncation of the entire MSG field is not sufficient, then additionally, the
STRUCTURED-DATA field MUST be truncated by removing one or more SD-ELEMENT fields. A minimum number of
SD-ELEMENT fields MUST be truncated starting from the end as necessary to meet the supported length
limit. SD-ELEMENT field can't be truncated partially. If all SD-ELEMENT fields are removed, NILVALUE
MUST be specified for STRUCTURED-DATA field. Truncation of HEADER field MUST NOT be performed."
BTW, in your text or mine, what happens if message is malformed? A proxy won't be able to truncate it properly
then. We don't want to prevent it from truncating it in some way and sending the message further, I would
think. At least you will see something at the final destination, which maybe more useful than nothing. If
we just made truncation a simple take the first X octets out of Y octets, it would not be an issue, but then
proxy would be allowed to turn a well-formed message into malformed message upon truncation.
What do you think?
Syslog mailing list
Syslog <at> lists.ietf.org