On 09/10/13 16:20, XMPP Extensions Editor wrote:
> Abstract: This specification defines an element to be used for encapsulating
> JSON data in XMPP.
I don't see how the example given,
<iq to="recipient.example.com" type="get" id="q1">
<query xmlns="http://example.com/user-queries";>
<json xmlns="urn:xmpp:json:tmp">
{ "name": "romeo" }
</json>
</query>
</iq>
has any advantage over using
<iq to="recipient.example.com" type="get" id="q1">
<query xmlns="http://example.com/user-queries";>
{ "name": "romeo" }
</query>
</iq>
and the namespace owner (in this case example.com) documenting that the
payload of a {http://example.com/user-queries}query element is JSON. If
the recipient understands the http://example.com/user-queries namespace,
then they know that its payload is JSON, and can perform whatever
validation is required. If the recipient doesn't understand it, they're
not going to be able to do anything useful with it anyway...
It would be useful for the text and/or examples to indicate how the
embedding in XML interacts with characters that are reserved/special in
XML. For instance, my interpretation is that this message:
<message to="[email protected]" from="[email protected]">
<json xmlns="urn:xmpp:json:tmp">
{ "name": "romeo", "age": "421", "status": "I >3 Juliet" }
</json>
</message>
is expected to be interpreted as equivalent to receiving this
application/json from a web server or whatever:
{ "name": "romeo", "age": "421", "status": "I <3 Juliet" }
If I'm right, I think it'd be good to use an example like this that
illustrates that point. If I'm wrong, then I don't see how it could work
in a generic XML parser.
> The data MUST be encoded as UTF-8 (though officially unspecified,
> this is the de facto encoding for JSON today).
The JSON RFC, RFC 4627, does in fact say "The default encoding is
UTF-8", and could be interpreted as implying that the only valid
encodings are UTF-8, UTF-16 and UTF-32 - it states that the pattern of
nulls in the first 4 bytes is sufficient to detect the encoding, which
is only true if common single-byte encodings like Latin-1 are not allowed.
In any case, if the JSON is character data in an XMPP XML stream, then
it has to be UTF-8, whether this XEP says it is or not. Non-UTF-8 can
only appear in XMPP XML if it's encoded in Base64 or something; or if
you're less concerned with the wire protocol and more concerned with
semantics, you could say that XMPP is a transport for (XML containing)
Unicode text (encoded in UTF-8 for the wire protocol), not bytes.
S
h
