[Problem] Extend xmpp message for xml elements with Chinese attribute name and value

When I try to extend the xmpp message with some custom xml element to transport custom data, I find Openfire was unstable with the Chinese words appear as attribute name or value, I send out those data from a component implied with Whack 1.0.0, which is also a igniterealtime project.

Technically, xmpp xml should be used with UTF-8 encoding and Whack 1.0.0 actually does, and the Chinese words comes from a UTF-8 encoding Java source files so thay are definitely UTF-8 encoded themself, but when the openfire recved the xml data, it will throw out some exception like:

org.xmlpull.v1.XmlPullParserException: expected = after attribute name (position: TEXT seen … <UserData id=“5” \u7ea7\u522b=“0” \u519b\u529f=“0” \u91d1\u5e01=“0” \u94f6\u5e01=“0” \u94f6\u5e01\u4e0a\u9650=“0” \u5175\u529b=“0” \u5175\ufffd… @5:70)
at org.xmlpull.mxp1.MXParser.parseAttribute(MXParser.java:2004)
at org.xmlpull.mxp1.MXParser.parseStartTag(MXParser.java:1799)
at org.jivesoftware.openfire.net.MXParser.nextImpl(MXParser.java:191)
at org.xmlpull.mxp1.MXParser.nextToken(MXParser.java:1100)
at org.dom4j.io.XMPPPacketReader.parseDocument(XMPPPacketReader.java:317)
at org.dom4j.io.XMPPPacketReader.read(XMPPPacketReader.java:154)
at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:141)
at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandl er.java:133)
at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived (AbstractIoFilterChain.java:570)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)

This problem is UNSTABLE, which mean that when I send out the same data again and again some times Openfire will accept it and some times will throw exception.

This problem was find in Openfire 3.6.4 rpm version in CentOS 5.4 and the 3.7.0 beta aslo. Is it a Openfire bug or Whack bug?