Subject: RE: [Syslog] WGLC: protocol, part 2

From: "Rainer Gerhards" <[email-masked]>
Date: Tue, 5 Sep 2006 02:55:04 +0200

Just one quick comment, at least this one gets on list (I'll send a more
thourough message after edit)

> In 6.5 example 1, aren't these contrsdictory statements - "The
> encoding is defined by the BOM,    and also advertised in
> STRUCTURED-DATA.  There is no STRUCTURED-DATA present in the message,
> this is indicated by "-" in the STRUCTURED-DATA field." So should this
> read ""and MAY be advertised"
> 
> 7.3.3 Let's see. If BOM and enc are both specified, believe the BOM.
> If BOM is not present and enc=UTF8 is present, then you should make no
> assumptions about the encoding. If the BOM is not present and the
> encoding is not UTF8 then enc MUST NOT be specified. So when is this
> field actually useful? Why have it if the value of the field is always
> either duplicative or not-to-be-trusted? Let's either make it useful
> when the BOM is not specified and/or when the encoding is not UTF8, or
> let's eliminate it.

I disliked the enc SD-PARAM ever since it is there. However, it was WG
consensus to include it. I opted for just the BOM and would still prefer
that. 

> Section 8.2 specifies why it is a security risk to send control
> characters in the MSG or PARAM-VALUE content. We should simply say, if
> you want to be a standard-compliant implementation, you MUST NOT send
> control characters in these fields. Period. Strip them out and add a
> section to your release notes tahat explains this decision was made by
> the IETF for security reasons.

That was a veeeeery long discussion around one or two years ago. The
bottom line was that we can not know which UTF-8 sequence is a control
character - there may even be new ones defined in the future. An
implementation is unlikely to know each of them. There were a lot of
arguments that we should support any character inside these fields
(please refer to list archive). I still back this. If we go back and
change *that* decision, we must also reconsider the octet-counting
decision for -tls. The reason is that if we would outrule control
characters in -protocol, there would be no valid reason at all to not
use LF as a stream separator.

David
Rainer

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog