Hi Sam, I'm going to wait a day or so for any input from the WG. However, the proposed text seems to be acceptable. Do you want a new ID, or is this something that we can change in AUTH24?
Thanks, Chris On Fri, 7 Sep 2007, Sam Hartman wrote:
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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
_______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
