[Standards] Proposed XMPP Extension: JSON Containers
The XMPP Extensions Editor has received a proposal for a new XEP. Title: JSON Containers Abstract: This specification defines an element to be used for encapsulating JSON data in XMPP. URL: http://xmpp.org/extensions/inbox/json-containers.html The XMPP Council will decide in the next two weeks whether to accept this proposal as an official XEP.
Re: [Standards] Proposed XMPP Extension: JSON Containers
On 9 October 2013 16:20, XMPP Extensions Editor edi...@xmpp.org wrote: Abstract: This specification defines an element to be used for encapsulating JSON data in XMPP. What's the intended purpose of embedding JSON into XMPP stanzas? Provide a standard encapsulation for things like Google Cloud Messaging?
Re: [Standards] Proposed XMPP Extension: JSON Containers
I feel it's better to define a standard method to encode arbitrary
content type content type=text/json{}/content than defining
json tag specifically to say 'this is JSON'.
(I'm not sure if there are such spec already or not)
Yusuke
From: Maxim Ignatenko gelraen...@gmail.com
Subject: Re: [Standards] Proposed XMPP Extension: JSON Containers
Date: Wed, 9 Oct 2013 17:46:38 +0100
On 9 October 2013 16:20, XMPP Extensions Editor edi...@xmpp.org wrote:
Abstract: This specification defines an element to be used for encapsulating
JSON data in XMPP.
What's the intended purpose of embedding JSON into XMPP stanzas?
Provide a standard encapsulation for things like Google Cloud
Messaging?
Re: [Standards] Proposed XMPP Extension: JSON Containers
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=recipi...@example.com from=sen...@example.com
json xmlns=urn:xmpp:json:tmp
{ name: romeo, age: 421, status: I gt;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
Re: [Standards] Proposed XMPP Extension: JSON Containers
On 10/09/2013 09:58 AM, DOI Yusuke wrote:
I feel it's better to define a standard method to encode arbitrary
content type content type=text/json{}/content than defining
json tag specifically to say 'this is JSON'.
(I'm not sure if there are such spec already or not)
I like this. Kinda reminds me of what I suggested here:
http://mail.jabber.org/pipermail/standards/2013-January/027027.html
Justin
Re: [Standards] Proposed XMPP Extension: JSON Containers
Please don't top post. Reformatted below.
On 2013-10-09 18:58, DOI Yusuke wrote:
On 2013-10-09 18:46, Maxim Ignatenko wrote:
On 9 October 2013 16:20, XMPP Extensions Editor edi...@xmpp.org wrote:
Abstract: This specification defines an element to be used for
encapsulating JSON data in XMPP.
What's the intended purpose of embedding JSON into XMPP stanzas?
Provide a standard encapsulation for things like Google Cloud
Messaging?
I feel it's better to define a standard method to encode arbitrary
content type content type=text/json{}/content than defining
json tag specifically to say 'this is JSON'.
(I'm not sure if there are such spec already or not)
First off, arbitrary content cannot be represented in XMPP like that, as
it doesn't embed binary data nicely. But see Justin's reply for that, as
well.
The primary use case for me is in publish-subscribe. There, you must
have a containing element for item payloads, and specifying one
dedicated to JSON makes a lot of sense to me. If you read today's
article by Justin [1], you can easily see why.
As mentioned in the comments over at HN [2], if you want to make things
easy for (web-)developers that like to deal with simple APIs without
having to craft XML for payloads this really helps. Now the API is
basically a destination address for the Publish-Subscribe service, a
node identifier, optionally an item identifier and the payload as JSON.
Doing a generic content/ with mime type and encoding seems over-design.
--
ralphm
Re: [Standards] Proposed XMPP Extension: JSON Containers
On 2013-10-09 19:45, Ralph Meijer wrote:
Please don't top post. Reformatted below.
On 2013-10-09 18:58, DOI Yusuke wrote:
On 2013-10-09 18:46, Maxim Ignatenko wrote:
On 9 October 2013 16:20, XMPP Extensions Editor edi...@xmpp.org wrote:
Abstract: This specification defines an element to be used for
encapsulating JSON data in XMPP.
What's the intended purpose of embedding JSON into XMPP stanzas?
Provide a standard encapsulation for things like Google Cloud
Messaging?
I feel it's better to define a standard method to encode arbitrary
content type content type=text/json{}/content than defining
json tag specifically to say 'this is JSON'.
(I'm not sure if there are such spec already or not)
First off, arbitrary content cannot be represented in XMPP like that, as
it doesn't embed binary data nicely. But see Justin's reply for that, as
well.
The primary use case for me is in publish-subscribe. There, you must
have a containing element for item payloads, and specifying one
dedicated to JSON makes a lot of sense to me. If you read today's
article by Justin [1], you can easily see why.
As mentioned in the comments over at HN [2], if you want to make things
easy for (web-)developers that like to deal with simple APIs without
having to craft XML for payloads this really helps. Now the API is
basically a destination address for the Publish-Subscribe service, a
node identifier, optionally an item identifier and the payload as JSON.
Doing a generic content/ with mime type and encoding seems over-design.
[1] http://blog.fanout.io/2013/10/09/publishing-json-over-xmpp/
[2] https://news.ycombinator.com/item?id=6520524
--
ralphm
Re: [Standards] Proposed XMPP Extension: JSON Containers
On 10/9/13 11:45 AM, Ralph Meijer wrote: Doing a generic content/ with mime type and encoding seems over-design. Agreed. That opens up too much flexibility, I think. Peter -- Peter Saint-Andre https://stpeter.im/
[Standards] DRAFT: XEP-0301 (In-Band Real Time Text)
Version 1.0 of XEP-0301 (In-Band Real Time Text) has been released. Abstract: This is a specification for real-time text transmitted in-band over an XMPP session. Real-time text is text transmitted instantly while it is being typed or created. Changelog: Per a vote of the XMPP Council, advanced status to Draft. (psa) Diff: http://xmpp.org/extensions/diff/api/xep/0301/diff/0.12/vs/1.0 URL: http://xmpp.org/extensions/xep-0301.html
Re: [Standards] DRAFT: XEP-0301 (In-Band Real Time Text)
See also: http://xmpp.org/2013/10/real-time-text-to-draft-standard/ On 10/9/13 12:12 PM, XMPP Extensions Editor wrote: Version 1.0 of XEP-0301 (In-Band Real Time Text) has been released. Abstract: This is a specification for real-time text transmitted in-band over an XMPP session. Real-time text is text transmitted instantly while it is being typed or created. Changelog: Per a vote of the XMPP Council, advanced status to Draft. (psa) Diff: http://xmpp.org/extensions/diff/api/xep/0301/diff/0.12/vs/1.0 URL: http://xmpp.org/extensions/xep-0301.html
[Standards] Re-escalating update of XEP-0313: MAM
Hello everyone,I'm re-escalating my request for XEP-0313 update, which purpose is to bring a way to change the user's message archiving preferences (something very basic, so that we keep things simple and respect the philosophy of MAM which is to remove the burden of previous message archiving XEPs).Plus, we have a working implementation of the updated version of MAM in Jappix. We really needed to proceed the XEP update to make it fully usable by clients, and we'd be glad to see its support being pushed in major XMPP desktop mobile clients.You can find the Web browser-viewable version of the updated specification there:https://demo.frenchtouch.pro/valerian.saliou/xmpp/extensions/xep-0313.htmlAlso, my previous update request from August on this mailing list:http://mail.jabber.org/pipermail/standards/2013-August/027873.htmlHope we can discuss those new changes actively. For your convenience, I attached the diff file for my updated version.Cheers, --Valérian SaliouJappixFrenchTouch Web Agencyfounder.Uno IMproduct lead.More about me onmy personal page. 19a20 specXEP-0086/spec 32a34,41 urihttp://matthewwild.co.uk//uri /author author firstnameValérian/firstname surnameSaliou/surname emailvaler...@valeriansaliou.name/email jidvaler...@jappix.com/jid urihttp://valeriansaliou.name//uri 34a44,49 version0.3/version date2013-08-05/date initialsvs/initials remarkpIntroduce the ability to purge part or all of archives. Preferences more flexible: retrieval and push made possible. Starting namespace versioning./p/remark /revision revision 152c167 query xmlns='urn:xmpp:mam:tmp' queryid='f27' / --- query xmlns='urn:xmpp:mam:0' queryid='f27' / 173c188 query xmlns='urn:xmpp:mam:tmp' --- query xmlns='urn:xmpp:mam:0' 189,190c204,205 pIf omitted, the server SHOULD assume the value of lt;start/gt; to be equal to the date/time of the earliest message stored in the archive./p --- pIf omitted, the server SHOULD assume the value of lt;end/gt; to be equal to the date/time of the latest message stored in the archive./p 198c213 query xmlns='urn:xmpp:mam:tmp' --- query xmlns='urn:xmpp:mam:0' 206c221 query xmlns='urn:xmpp:mam:tmp' --- query xmlns='urn:xmpp:mam:0' 220c235 query xmlns='urn:xmpp:mam:tmp' --- query xmlns='urn:xmpp:mam:0' 234c249 iq type='error' id='q29302' --- iq type='error' id='q29302' to='ro...@montague.lit/orchard' 250,251c265,266 iq type='result' id='q29302' query xmlns='urn:xmpp:mam:tmp' --- iq type='result' id='q29302' to='jul...@capulet.lit/balcony' query xmlns='urn:xmpp:mam:0' 276c291 query xmlns='urn:xmpp:mam:tmp' --- query xmlns='urn:xmpp:mam:0' 286a302,317 section3 topic='Get latest messages' anchor='query-latest' pIn the case where the client does not build a local cache by fetching the whole archive in a chronological order, a reverse order logic is made possible by allowing the retrieval of latest archived messages. It achieves this by including a lt;setgt; element within its request, containing an empty lt;before/gt;. After the reply to this request is received, it can page through previous results normally (as defined in xep0059;)./p example caption='Querying the archive for latest messages'![CDATA[ iq type='get' id='q29304' query xmlns='urn:xmpp:mam:0' withjul...@capulet.lit/with set xmlns='http://jabber.org/protocol/rsm' max10/max before/ /set /query /iq ]]/example pNote: There is no concept of an open query, and servers MUST be prepared to receive arbitrary page requests at any time./p /section3 304c335 result xmlns='urn:xmpp:mam:tmp' queryid='f27' id='28482-98726-73623' --- result xmlns='urn:xmpp:mam:0' queryid='f27' id='28482-98726-73623' 317c348 result xmlns='urn:xmpp:mam:tmp' queryid='f27' id='5d398-28273-f7382' --- result xmlns='urn:xmpp:mam:0' queryid='f27' id='5d398-28273-f7382' 331a363,425 section1 topic='Purging the archive' anchor='purge' pWhen it comes that an user needs to do some cleanup in his archived conversations and remove all if not part of them, its client SHOULD provide him a way to remove archived messages./p pIn the case archiving is enforced by the server's policy, archive removal MAY not be allowed, resulting in the server replying with an error reply to such purge requests./p pA purge query consists of an lt;iq/gt; stanza addressed to the account or server entity hosting the archive, with a 'purge' payload. On receiving the query, the server purges the archived messages that match the client's given criteria, and finally returns the lt;iq/gt; result./p example caption='Purging the whole archive'![CDATA[ iq type='set' id='purge1' purge xmlns='urn:xmpp:mam:0' / /iq iq type='result' id='purge1'/ ]]/example pThe server MUST reply with a result lt;iq/gt; (purge successful) or an
