Byte order marks and character sets

[Robert Burbidge <robert.burbidge@poptel.coop>]

>While it MAY be used it's certainly not necessary and most people I talked
>to strongly suggested that it's use should be discouraged.  Thus, this is
>what I intend to add to Section 2 of the EPP document to address the issue:

>"Normative section 4.3.3 and non-normative appendix F of [XML] describe
>use of a byte order mark (BOM) to identify the character encoding in
>the absence of an XML declaration or encapsulating headers.  Appendix F
>includes a BOM to represent UTF-8 encoding, though section 4.3.3
>notes that a BOM is not needed to identify UTF-8 encoding.  Section
>4.3.3 was later amended (see [XMLE]) to clarify that a BOM MAY be used
>to identify UTF-8 encoding.  EPP clients and servers MUST accept a
>UTF-8 BOM if present, though emitting a UTF-8 BOM is NOT RECOMMENDED."

This seems to me to be a significant improvement in the specification which
I support. As I mentioned before, we've decided to supress outgoing UTF-8
BOMs from our server, although we can handle incoming UTF8 BOMS if they are
provided by a client.

One longer-term issue remains, and it's not urgent in my mind, but I will
mention it for completeness. Can you forsee any situations (right now or in
the future) where UTF16 or other encodings would be desirable and/or
necessary? If so, can we ensure that the spec doesn't make too many
assumptions about UTF8 encoding. If UTF8 is RECOMMENDED that's probably
enough in most cases, but would it be either valid and/or desirable to have
an EPP server that works entirely in UTF16 for example? Let me stress I have
no strong views on the subject, although vague topics like "chinese domain
names" or "use of EPP as a generic provisioning protocol" do occasionally
cross my mind in this context.

Thanks for your quick action on clarifying this.

Rob Burbidge