Hi, folks.
I think the WG made a mistake trying to address Chris Newman's comment
about Unicode TR36 and made the situation worse.
My understanding of what the WG was trying to do is to require that if
a BOM is present in a string, then the implementation can enforce
strict checks because it knows the message is Unicode and UTF-8.
Without the BOM, there's not a lot you can do. The goal here is to
have consistent and secure internationalization between two new
implementations--that is a sender that includes the BOM and a receiver
that understands it. So, basically the BOM is a signal that "Hi,
there; I'm new and you can trust my i18n to be reasonably well thought
through."
The following change seems to break this.
- If a syslog application is processing a MSG starting with a BOM, then
- it MUST be interpreted as being encoded in UTF-8 for the reasons
- outlined in UNICODE TR36 [UNICODE-TR36], section 3.1. If a syslog
- application does not encode MSG in UTF-8, the string MUST NOT start
- with the Unicode BOM. Guidance about this is given in Appendix A.8.
+ If a syslog application is processing a MSG starting with a BOM, if
+ it contains UTF-8 that is not shortest form it MUST NOT be
+ interpreted as being encoded in UTF-8 for the reasons outlined in
+ [UNICODE-TR36], section 3.1. Guidance about this is given in
+ Appendix A.8.
In particular if you get text from a new implementation that is not
shortest-form, it is an error. You want to throw it away , or do
something else to indicate you have a security problem, not just treat
it as another encoding.
I propose the following text but would be open to alternatives:
If a syslog application is processing a MSG starting with a BOM, if
it contains UTF-8 that is not shortest form it MUST be discarded for the reasons outlined in
[UNICODE-TR36], section 3.1. Guidance about this is given in
Appendix A.8.
_______________________________________________
Syslog mailing list
Syslog at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
