Hi Justin,
first of all, great work. I find it a very good idea.
On 16 March 2011 02:48, Justin Karneges
justin-keyword-jabber.093...@affinix.com wrote:
On Monday 10 January 2011 04:08:23 Dave Cridland wrote:
1) A minor niggle - I hate using query as the iq/ element. Feels
very old-fashioned.
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Am 15.03.2011 um 21:53 schrieb Matthew A. Miller:
I know a couple of clients where switching the chatstates message/s to
type='headline' will break their support; I'm sure there are others since
XEP-0082 specifies the states SHOULD NOT be
On Tue, Mar 15, 2011 at 12:36 PM, Jonathan Schleifer
js-xmpp-standa...@webkeks.org wrote:
Just having looked at my offline storage, I saw that chat states are stored
by the server. But of course they are, as the type is chat and thus the
server has to store them.
Thinking about it, wouldn't
I second it as well. The don't store if there is no body standard
is recommended too, for my submitted/upcoming resubmit of Real Time
Text too. It also involves message transmissions without a body
element, sent before the completed message which contains a body
element.
On 3/16/11, Jonathan
Forwarding this because his mail doesn't seem to be happy:
--- BEGIN --
Hi,
I am the Jappix project founder (https://www.jappix.com/ -
https://project.jappix.com/ - https://mini.jappix.com), and we added
full microblogging XEP (XEP-0277) support to our webclient (desktop
edition).
We had a
On Wed, 2011-03-16 at 15:39 +, Kevin Smith wrote:
We had a strong need during its integration: the multiple/single
file(s) attachment, like Identi.ca does in its protocol. We built a
simple way (maybe not the best?!) to do this, with file / XML
elements.
Atom has this, which is also what
Version 1.2 of XEP-0237 (Roster Versioning) has been released.
Abstract: This specification defines a proposed modification to the XMPP roster
protocol that enables versioning of rosters such that the server will not send
the roster to the client if the roster has not been modified, thus saving
On Wed, Mar 16, 2011 at 4:51 PM, Matthew Wild mwi...@gmail.com wrote:
On 16 March 2011 14:23, Mark Rejhon marky...@gmail.com wrote:
I second it as well. The don't store if there is no body standard
is recommended too, for my submitted/upcoming resubmit of Real Time
Text too. It also involves
Hi,
On 16 March 2011 17:24, Kim Alvefur z...@zash.se wrote:
On Wed, 2011-03-16 at 15:39 +, Kevin Smith wrote:
We had a strong need during its integration: the multiple/single
file(s) attachment, like Identi.ca does in its protocol. We built a
simple way (maybe not the best?!) to do this,
On Wed, Mar 16, 2011 at 5:09 PM, Kevin Smith ke...@kismith.co.uk wrote:
At least, without giving it up thought, it seems to be.
*much* thought
/K
On a related note, are there situations where messsages is type=chat
but does NOT contain a body? I couldn't find a guideline relating
to this, as this is also relevant to my work-in-progress.
On 3/16/11, Kevin Smith ke...@kismith.co.uk wrote:
On Wed, Mar 16, 2011 at 5:09 PM, Kevin Smith
On Wednesday 16 March 2011 02:33:07 you wrote:
On 16 March 2011 02:48, Justin Karneges
If we're not querying for lists, then disco#items is out. But, we can
still inherit disco category and type.
How about this:
iq type=get from=al...@example.com/home to=b...@example.com
id=d1
On Mar 16, 2011, at 11:54 , Mark Rejhon wrote:
On a related note, are there situations where messsages is type=chat
but does NOT contain a body? I couldn't find a guideline relating
to this, as this is also relevant to my work-in-progress.
CSN (XEP-0082) is the most common case where we
13 matches
Mail list logo
