XMPP Extensions Editor píše v St 31. 03. 2010 v 17:57 -0500:
...
URL: http://xmpp.org/extensions/xep-0184.html
Hi. The HTML seems to not have been updated.
signature.asc
Description: Toto je digitálně podepsaná část zprávy
XMPP Extensions Editor píše v Čt 11. 02. 2010 v 18:06 -0600:
Version 0.10 of XEP-0234 (Jingle File Transfer) has been released.
Abstract: This specification defines a Jingle application type for
transferring files between two entities. The protocol provides a modular
framework that enables
Peter Saint-Andre píše v Čt 11. 02. 2010 v 19:42 -0700:
On 2/11/10 5:29 PM, Jiří Zárevúcky wrote:
XMPP Extensions Editor píše v Čt 11. 02. 2010 v 18:06 -0600:
Version 0.10 of XEP-0234 (Jingle File Transfer) has been released.
Abstract: This specification defines a Jingle application type
Yann Leboulanger píše v Ne 17. 01. 2010 v 18:28 +0100:
Yann Leboulanger wrote:
Hi all,
Alexander Tsvyashchenko and I discussed changes in XEP-136, and we wrote
them in the XEP. Attached is a diff of the xep-0136.xml, and you can
see the result here:
www.lagaule.org/xep/xep-0136.html
On 09/17/2009 04:15 AM, Justin Karneges wrote:
On Wednesday 16 September 2009 18:23:32 Robert Quattlebaum wrote:
mobile clients a way to silence incoming presence (presence hush),
and give them a way to rebuild the presence state of their roster
quickly and efficiently when presence it is
On 09/15/2009 05:36 PM, XMPP Extensions Editor wrote:
Version 0.1 of XEP-0273 (Stanza Interception and Filtering Technology) has been
released.
Abstract: This specification defines an XMPP protocol extension that enables a
client to exercise control over the XML stanzas it will receive from
2009/7/18 Tomasz Sterna to...@xiaoka.com:
On wto, 2009-07-14 at 13:21 -0600, Peter Saint-Andre wrote:
Agreed -- there is no harm if the server always includes 'ver'. I'll
update the spec to say that.
We once banned non-standard x/ subelements from roster items
and now wish to allow
I think there is one way to really solve the issue in question.
As I understand it, the problem is that when user logs it, he doesn't
know whether the contact is online or not. Sending all presences
together is not an option, as it would require waiting for all the
probes to respond.
Now, I'm
2009/7/15 Pedro Melo m...@simplicidade.org:
Hi,
On 2009/07/15, at 08:36, Kevin Smith wrote:
While we're discussing upgrading roster handling, can I put my request
in for hanging arbitrary xml off the roster entries, please?
Thats the only reason I could come up with to justify changing
2009/7/15 Peter Saint-Andre stpe...@stpeter.im:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/15/09 8:18 AM, Jiří Zárevúcky wrote:
2009/7/15 Pedro Melo m...@simplicidade.org:
Hi,
On 2009/07/15, at 08:36, Kevin Smith wrote:
While we're discussing upgrading roster handling, can I put
2009/7/15 Jonathan Schleifer js-xmpp-standa...@webkeks.org:
Remko Tronçon re...@el-tramo.be wrote:
IMO, that would needlessly complicate things (duplicated
functionality/information/...) at virtually no gain.
cheers,
Remko
There _IS_ a gain: You won't get presences every few seconds for
2009/7/15 Peter Saint-Andre stpe...@stpeter.im:
On 7/15/09 8:53 AM, Jiří Zárevúcky wrote:
2009/7/15 Peter Saint-Andre stpe...@stpeter.im:
On 7/15/09 8:44 AM, Jiří Zárevúcky wrote:
The only objectively
broken thing is probably just the fact you can't be sure about the
existence of incoming
2009/7/15 Peter Saint-Andre stpe...@stpeter.im:
On 7/15/09 9:12 AM, Jiří Zárevúcky wrote:
We probably first need to sum up the additional functionality we'd
want in roster management.
Arbitrary attached XML is the first and obvious one, which wouldn't
even require a new protocol.
Correct
Section 2.3
3. If both parties send a candidate-used notification but the
candidates have a different priority, then the candidate with the
lower priority shall be considered the nominated candidate.
Shouldn't the candidate with *higher* priority be nominated?
2009/7/14 Tomasz Sterna to...@xiaoka.com:
On pon, 2009-07-13 at 15:42 -0600, Peter Saint-Andre wrote:
Whether or not the roster has been modified since the version
ID enumerated by the client, the server MUST either return the
complete roster as described in RFC 3921 (including a
2009/7/11 Tomasz Sterna to...@xiaoka.com:
I am implementing XEP-0237 in jabberd2 and I have a question.
2.3 Server Response
Whether or not the roster has been modified since the version ID
enumerated by the client, the server MUST either return the complete
roster as described in RFC 3921
2009/7/10 Me Self wmso...@gmail.com:
It looks like the explanation of None+ Pending in has been moved to
appendix A.1 in bis and it now reads:
None + Pending In = contact and user are not subscribed to each other,
and contact has sent user a subscription request but user has not replied
yet
Hello Søren.
Seems you are referring to the old version of the spec. Look at recent
http://xmpp.org/internet-drafts/draft-ietf-xmpp-3921bis-00.html , many
things are explained much more clearly there.
Dne 7. červenec 2009 20:42 Peter Saint-Andre stpe...@stpeter.im napsal(a):
btw, is it OK to respond to the tickets on this list instead of
commenting them directly?
Sure. Indeed I prefer it. I just figured I'd test the issue tracker
since that's what the IETF Tools Team has given us. :)
2009/7/7 Peter Saint-Andre stpe...@stpeter.im:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/7/09 1:06 PM, Kevin Smith wrote:
2009/7/7 Peter Saint-Andre stpe...@stpeter.im:
Sure. Indeed I prefer it. I just figured I'd test the issue tracker
since that's what the IETF Tools Team has
2009/7/8 XMPP Extensions Editor edi...@xmpp.org:
Version 0.2 of XEP-0051 (Connection Transfer) has been released.
Abstract: This specification defines an XMPP protocol extension that enables
a server to redirect connections from one connection manager or server node
to another.
Changelog:
2009/7/2 Marcus Lundblad m...@update.uu.se:
ons 2009-07-01 klockan 15:56 -0600 skrev Peter Saint-Andre:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/1/09 3:51 PM, Peter Saint-Andre wrote:
XEP-0256 talks about including last activity in auto-away notifications,
which means I'm away
2009/7/1 Peter Saint-Andre stpe...@stpeter.im:
The same might be true of MUC room history (I am
growing tired of receiving messages from yesterday when I join a quiet
room).
There is a mechanism to do this in MUC (see section 7.1.16 of
XEP-045). The problem here is more likely to be the fact
2009/7/2 Peter Saint-Andre stpe...@stpeter.im:
On 7/1/09 4:07 PM, Jiří Zárevúcky wrote:
2009/7/1 Peter Saint-Andre stpe...@stpeter.im:
The same might be true of MUC room history (I am
growing tired of receiving messages from yesterday when I join a quiet
room).
There is a mechanism to do
2009/7/2 Peter Saint-Andre stpe...@stpeter.im:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/1/09 4:18 PM, Jiří Zárevúcky wrote:
2009/7/2 Peter Saint-Andre stpe...@stpeter.im:
On 7/1/09 4:07 PM, Jiří Zárevúcky wrote:
2009/7/1 Peter Saint-Andre stpe...@stpeter.im:
The same might
2009/6/30 Dave Cridland d...@cridland.net:
On Tue Jun 30 16:20:25 2009, Jiří Zárevúcky wrote:
2009/6/30 Dave Cridland d...@cridland.net:
On Tue Jun 30 15:33:35 2009, Matthew Wild wrote:
It does. Anonymous users get given a unique (~random) JID, with an
empty roster. So you /can/ send
2009/6/30 Eloi Bail eloi.b...@gmail.com:
To authenticate to a XMPP server, I must implement encryption. I wanted to
test without it, to have a XMPP client as light as possible...
I have to go strait to SASL with encryption so...
Thanks for your reply !
Eloi
Nope, you don't need to. You can
2009/6/23 Joe Hildebrand joe.hildebr...@webex.com:
Moving the discussion to the XMPP working group mailing list since this is
RFC-related.
It looks like Google's docs for this are here:
http://code.google.com/apis/talk/jep_extensions/jid_domain_change.html
Should the client just use this
2009/6/22 Bernhard zwischenbrugger b...@datenkueche.com:
PS: I'm teaching that things and must be very correct.
As all the other questions have been answered, I'd just like to ask one.
Why are you teaching something you don't fully understand?
2009/6/17 Remko Tronçon re...@el-tramo.be:
It's possible, I suppose, that the remote client went offline before the
message/, and came back online after, just in time to get the iq/, but
it seems terribly unlikely, especially as you'd also see a presence/
update as it came back online.
Well,
2009/5/29 Justin Karneges justin-keyword-jabber.093...@affinix.com:
But yes, the advantage of XEP-199 is that it works with clients that may not
actually support XEP-199. :) For clients that aren't XMPP-compliant enough
to return errors from unsupported iq types, the server could use a
2009/5/25 Nicolas Vérité nicolas.ver...@process-one.net:
Strictly speaking:
- the sending entity does not detect the loss of connection when it sends
whitespaces
That's correct.
- the receiving entity detects the loss of connection only if it has a
mechanism that detects the absence of
2009/5/25 Artur Hefczyc artur.hefc...@tigase.org:
Hi,
I would like to provide feedback on these two sections:
5.7.3. Handling of Idle Streams
http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-09.html#streams-close-idle
12.7. Whitespace
2009/5/18 Peter Saint-Andre stpe...@stpeter.im:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5/16/09 6:45 AM, Jiří Zárevúcky wrote:
Hello. The filtering/intercepting functionality seems nice for IQ
stanzas, but I have doubts about some of the use cases.
Invisibility as defined
Hello. The filtering/intercepting functionality seems nice for IQ
stanzas, but I have doubts about some of the use cases.
Invisibility as defined by this spec would certainly ease it's
handling by both client and server, but is changes the meaning of
available and unavailable presence stanzas.
35 matches
Mail list logo
