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 protected] https://www1.ietf.org/mailman/listinfo/syslog
