On 9/13/07, Tobias Markmann [EMAIL PROTECTED] wrote:
Exactly. You can't expect an IM client to handle transfers of CD or DVD
image sized files. For these large files protocols like BitTorrent have been
developed and work really nice on doing that.
I found myself receiving a file over 200MB
Hi Alex,
On 10/26/07, Alexander Gnauck [EMAIL PROTECTED] wrote:
Hello,
i recently finished my BOSH implementation and stumbled over 2 problems.
Most implementations send the stream features only once at the
beginning. Because of the missing stream headersin BOSH they send no
stream
On Fri, Apr 11, 2008 at 1:45 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
Everything in XEP-0045 covers your relationship and interactions with a
particular room, not the service. I've been hearing about more use cases
for interaction with the service itself, so perhaps it's finally time
On Fri, Apr 11, 2008 at 10:23 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
Registered with the room or with the service? Do we need to
differentiate between the two? If you are registered with the room then
you are a member, whereas nick registration has meaning across the
service.
On Wed, Aug 13, 2008 at 12:24 AM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
Has any MUC implementation coded in support for the unique room name
request feature described in Section 10.1.4 of XEP-0045? I think this
feature is unnecessary and (in the interest of simplification) I would like
to
On Wed, Aug 13, 2008 at 6:41 PM, Justin Karneges
[EMAIL PROTECTED] wrote:
There are many places where a UUID may be appropriate, but I don't think this
is one of them. You're desiring an unique handle to the MUC service, and the
MUC itself is really the authority for that.
How about:
Client
On Mon, Aug 18, 2008 at 2:21 AM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
Pavel Simerda wrote:
Ok, just... couldn't this be at least partially automated (not to
have the sure check himself)? If it's not possible, never mind.
Sure it could. I'm not sure if we really need that, given that
On Wed, Aug 20, 2008 at 3:40 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
Jonathan Schleifer wrote:
Am 20.08.2008 um 05:16 schrieb Peter Saint-Andre:
Matthew Wild wrote:
How about:
activity xmlns='http://jabber.org/protocol/activity'
other
charging xmlns='http://robotic
On Tue, Aug 26, 2008 at 1:11 PM, Lirette, Keith J. CONTR J9C618
[EMAIL PROTECTED] wrote:
I have a use case for a low bandwidth client which would benefit from
the ability to control client receipt of MUC participant presence
packets. In the use case, the user is interested in the message
On Tue, Sep 9, 2008 at 12:07 AM, Andreas Monitzer [EMAIL PROTECTED] wrote:
On Sep 08, 2008, at 21:36, Peter Saint-Andre wrote:
I had totally forgotten about that feature request.
Yes, that's what I hear every time I remind somebody of the jabber.org-team
:)
Yeah, apologies for this :)
To
Hi,
I thought I recalled some discussion on the lists already regarding
this, but I haven't been able to find it. On resource binding, the RFC
says the server MAY modify the client's chosen resource. Is there a
reason that it doesn't say If the client provides a resource, the
server SHOULD use
On Sat, Oct 4, 2008 at 2:23 AM, Justin Karneges
[EMAIL PROTECTED] wrote:
On Friday 03 October 2008 17:18:45 Matthew Wild wrote:
I thought I recalled some discussion on the lists already regarding
this, but I haven't been able to find it. On resource binding, the RFC
says the server MAY modify
On Sun, Oct 5, 2008 at 1:04 AM, Eric Will [EMAIL PROTECTED] wrote:
On Fri, Oct 3, 2008 at 10:05 PM, Matthew Wild [EMAIL PROTECTED] wrote:
While it is MAY as it is now I believe servers will begin implementing
it as a consequence of all the discussions about leaking presence
through user
On Thu, Oct 16, 2008 at 11:48 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
I've just submitted draft-saintandre-rfc3920bis-08.
You can find it here:
http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-08.html
The SVN diff is here: http://is.gd/4do1
See also:
On Tue, Oct 21, 2008 at 2:47 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
Curtis King wrote:
On 20-Oct-08, at 7:37 PM, Peter Saint-Andre wrote:
Please understand that even if we use MUST instead of SHOULD with
respect to namespace-awareness, the existing servers are not going to
be left
On Thu, Nov 13, 2008 at 3:01 AM, Jehan
[EMAIL PROTECTED] wrote:
Hi,
as it has been mentionned in some place (among others, here:
http://www.jabber.org/web/Secure_Communications_Week ), the 4th of
january 2009 will be the 10th birthday of XMPP. I thought it could be a
good occasion to
Hi,
I got into a debate today over some unit tests I wrote, which
explicitly checked that we handled JIDs such as @example.com and
[EMAIL PROTECTED]/ as invalid. However it seems the RFCs don't
explicitly disallow either of these cases.
How should they be handled? I can imagine that we currently
On Fri, Dec 5, 2008 at 2:01 AM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
Matthew Wild wrote:
Hi,
I got into a debate today over some unit tests I wrote, which
explicitly checked that we handled JIDs such as @example.com and
[EMAIL PROTECTED]/ as invalid. However it seems the RFCs don't
On Wed, Jan 7, 2009 at 9:29 PM, XMPP Extensions Editor edi...@xmpp.org wrote:
This message constitutes notice of a Last Call for comments on XEP-0245 (The
/me Command).
Abstract: This specification defines recommended handling of the /me command
in XMPP instant messaging clients.
URL:
On Thu, Jan 8, 2009 at 11:05 PM, XMPP Extensions Editor edi...@xmpp.org wrote:
Version 0.2 of XEP-0245 (The /me Command) has been released.
Abstract: This specification defines recommended handling of the /me command
in XMPP instant messaging clients.
Changelog: Clarified handling of
On Fri, Jan 9, 2009 at 2:15 AM, jlist9 jli...@gmail.com wrote:
Matthew,
Yes, I also tried using the full ID. It didn't help.
I tried capturing the traffic. It soon turns into TLS and I'm not able
to see the authentication details.
Does smack not provide a way to see the XML it is sending?
On Thu, Jan 22, 2009 at 9:05 PM, Remko Tronçon re...@el-tramo.be wrote:
Thus, I consider the Kopete behaviour rather bad.
I wouldn't call it bad. It's a good enough poor-man's metacontact,
especially in the case where private storage is not available on the
server. However, I do think
On Wed, Feb 11, 2009 at 3:01 PM, Jonathan Schleifer
js-xmpp-standa...@webkeks.org wrote:
Just a reason NOT to require a PW for the owner: Some admin might have
changed it and now the owner can't join the room anymore or change it back.
That same admin could simply remove the owner from the
On Thu, Feb 19, 2009 at 10:17 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
Curtis King wrote:
On 19-Feb-09, at 1:45 PM, Peter Saint-Andre wrote:
I don't think the bandwidth difference is that big here, but I like the
idea of putting it in rfc3921bis so that more people implement it. ;-)
On Thu, Feb 26, 2009 at 2:33 AM, Peter Saint-Andre stpe...@stpeter.im wrote:
[...]
We had rough consensus that the server would not change its processing
of your outbound presence, i.e., it would send your presence to your
entire contact list, not only contacts in the group(s) you specify via
On Thu, Feb 26, 2009 at 2:57 AM, Peter Saint-Andre stpe...@stpeter.im wrote:
Matthew Wild wrote:
On Thu, Feb 26, 2009 at 2:33 AM, Peter Saint-Andre stpe...@stpeter.im
wrote:
[...]
We had rough consensus that the server would not change its processing
of your outbound presence, i.e
On Thu, Mar 12, 2009 at 5:36 PM, Pedro Melo m...@simplicidade.org wrote:
On a side note: For the disco situation, the hash-based caps work already,
and we could ask server vendors to send a server presence on connect with
their own caps. Caps to cache server disco#info might just work.
On Thu, Mar 12, 2009 at 5:53 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
On 3/12/09 11:53 AM, Matthew Wild wrote:
On Thu, Mar 12, 2009 at 5:36 PM, Pedro Melo m...@simplicidade.org wrote:
On a side note: For the disco situation, the hash-based caps work already,
and we could ask server
On Thu, Apr 9, 2009 at 7:54 AM, Sachin Khandelwal sac...@geodesic.com wrote:
Hi,
Addition of this feature is highly appreciated.
There is a small issue which will occur in rare scenario :
In sec 2.4, Example 4. Roster result with no items
iq from='ro...@montague.lit' id='r1'
Now I'm being bad and replying to 2 mails at once, sorry :)
On Thu, Apr 9, 2009 at 3:53 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
On 4/9/09 7:57 AM, Sachin Khandelwal wrote:
Let me elaborate this :
Consider user 'xmpp1' uses two clients to login (say one from home and one
from
On Fri, Apr 17, 2009 at 10:03 PM, XMPP Extensions Editor
edi...@xmpp.org wrote:
Version 0.7 of XEP-0237 (Roster Versioning) has been released.
Just gave it a read through. I'm happy :)
Thanks!
Matthew
On Thu, Apr 23, 2009 at 7:13 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I just chatted with Jonas Lindberg via IM about the requirement in
XEP-0237 that the value of the 'ver' attribute is a strictly increasing
sequence number. Other than
On Fri, Apr 24, 2009 at 1:02 PM, Christoph Terwelp m...@seark.de wrote:
Am 23.04.2009 um 20:13 schrieb Peter Saint-Andre:
His argument was that the server might make the 'ver' attribute
something like a hash of the roster, which would be opaque to the client
but meaningful to the server so
On Wed, Apr 29, 2009 at 5:42 AM, Peter Saint-Andre stpe...@stpeter.im wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
FYI. This proposal emerged from discussions among some operators and
server vendors at XMPP Summit #6 in February...
The current proposal doesn't look bad. A few notes
On Thu, Apr 30, 2009 at 5:16 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
In its meeting yesterday, the XMPP Council agreed to issue a Call for
Experience regarding XEP-0199 (XMPP Ping), in preparation for perhaps
advancing this specification from Draft to Final in the XSF's standards
On Mon, May 4, 2009 at 11:27 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/30/09 2:53 PM, Matthew Wild wrote:
On Thu, Apr 30, 2009 at 5:16 PM, Peter Saint-Andre stpe...@stpeter.im
wrote:
In its meeting yesterday, the XMPP Council agreed
On Tue, May 5, 2009 at 7:39 AM, Philipp Hancke
fi...@goodadvice.pages.de wrote:
Peter Saint-Andre schrieb:
http://xmpp.org/extensions/tmp/xep-0220-refactored.html seems OK to me.
It lacks a when-to-piggyback section and a stream feature for the
type=error extension. There are some issues
On Tue, May 5, 2009 at 1:54 PM, Philipp Hancke
fi...@goodadvice.pages.de wrote:
Matthew Wild wrote:
[snip]
Knowing why this failed would be useful for debugging, but I dont
see a real value in knowing why there was an error - that can/should
be in the logs.
Hmm, I had the (mis
2009/5/13 Jiří Zárevúcký zarevucky.j...@gmail.com:
2009/5/13 Waqas Hussain waqa...@gmail.com:
Programmers for whom ver='qAxdnWNcA+lYf7CoN5wpBsvVVno=' would be
entirely impossible... I think those exact programmers are the reason
for not using ver='1' :-)
If it is a hash of a complete
On Thu, May 14, 2009 at 5:29 PM, Curtis King ck...@mumbo.ca wrote:
On 13-May-09, at 4:40 PM, Florian Zeitz wrote:
I'm also not really sure why anyone might ever want to use hashes.
+1
Can't you let us (the server developers) decide that? ;)
A reason for why one might use hashes is (as was
Hi all,
An issue that keeps popping up is the current inability of MUC to
relay PEP updates. I personally *really* would like to see this
resolved. So I'm going to start the ball rolling with a proposal.
Firstly though, here is some discussion we had in jdev the other day
about the topic:
On Fri, Jun 26, 2009 at 6:51 AM, Pedro Melom...@simplicidade.org wrote:
On 2009/06/25, at 18:29, Peter Saint-Andre wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6/24/09 11:22 PM, Ralph Meijer wrote:
On Wed, Jun 24, 2009 at 08:16:00PM -0600, Peter Saint-Andre wrote:
On 6/24/09
On Tue, Jun 30, 2009 at 3:01 PM, Eloi Baileloi.b...@gmail.com wrote:
Hi,
I would like to know if XMPP standard allows to push presence in case of
anonymous SASL ?
It does. Anonymous users get given a unique (~random) JID, with an
empty roster. So you /can/ send presence, you just either
On Thu, Jul 2, 2009 at 5:02 PM, Peter Saint-Andrestpe...@stpeter.im wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6/30/09 8:37 AM, Dave Cridland wrote:
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
On Wed, Jul 15, 2009 at 11:51 PM, Peter Saint-Andrestpe...@stpeter.im wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/15/09 4:44 PM, Fabio Forno wrote:
On Thu, Jul 16, 2009 at 12:38 AM, Peter Saint-Andrestpe...@stpeter.im
wrote:
It's not clear how many server codebases follow RFC
On Thu, Jul 16, 2009 at 11:57 AM, Jonathan
Schleiferjs-xmpp-standa...@webkeks.org wrote:
Am 16.07.2009 um 12:04 schrieb Kevin Smith:
If it takes 5 minutes for you to get initial presence from someone,
that means it's taking 5 minutes to establish s2s and do the presence
round-trip. Now, even
On Sat, Jul 18, 2009 at 3:16 PM, Tomasz Sternato...@xiaoka.com wrote:
Hello.
Psi-Devel list ignored this question, so I am reposting it here:
I am testing my PEP implementation with Psi 0.13-rc3.
http://xmpp.org/extensions/xep-0163.html#support
client SHOULD determine whether the account
2009/9/18 Peter Saint-Andre stpe...@stpeter.im:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As XMPP Extensions Editor I have started to maintain a Radar page
showing Draft and Final XEPs that are currently under revision, as well
as proposals in the Inbox...
2009/9/19 Peter Saint-Andre stpe...@stpeter.im:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/18/09 8:31 PM, Peter Saint-Andre wrote:
As copied from the Radar page...
Experimental XEPs are automatically deferred after 12 months of
inactivity. The following XEPs are set to be
2009/9/19 Fabio Forno fabio.fo...@gmail.com:
On Sat, Sep 19, 2009 at 12:47 PM, Matthew Wild mwi...@gmail.com wrote:
* XEP-0225: Component Connections
IMHO it would be great to work on this, although Jack Moffitt has
questioned how useful any kind of external component protocol really
2009/10/27 Justin Karneges justin-keyword-jabber.093...@affinix.com:
On Monday 26 October 2009 23:03:15 Nathan Fritz wrote:
3) XEP-0226: Message Stanza Profiles, Issue Last Call?
A consensus is reached on issuing a last call on XEP-0226, although
Matthew Wild notes that he finds the XEP
2009/10/27 Peter Saint-Andre stpe...@stpeter.im:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/27/09 9:08 AM, Matthew Wild wrote:
2009/10/27 Justin Karneges justin-keyword-jabber.093...@affinix.com:
On Monday 26 October 2009 23:03:15 Nathan Fritz wrote:
3) XEP-0226: Message Stanza
2009/12/25 XMPP Extensions Editor edi...@xmpp.org:
Version 1.1 of XEP-0169 (Twas The Night Before Christmas (Jabber Version))
has been released.
Abstract: The classic Christmas poem annotated with XMPP protocols.
Changelog: Corrected several examples and clarified the architectural
2010/1/20 Dave Cridland d...@cridland.net:
Simon McVittie has made a proposal he's called decloaking, which effectively
puts a bit of structure around the directed presence used to back up
various client-client interactions, including Jingle calls and file
transfers.
As part of the
2010/1/21 Jason Eacott ja...@hardlight.com.au:
Matthew Wild wrote:
...
Downsides are that this requires server support, especially thinking
of e.g. gmail.com here. Probably other things I'm missing too.
again this just makes me sure that XMPP as it stands is far too client
centric
On 18 February 2010 01:20, Justin Karneges
justin-keyword-jabber.093...@affinix.com wrote:
On Wednesday 17 February 2010 17:00:09 Joe Hildebrand wrote:
On 2/17/10 12:05 AM, Joe Hildebrand joe.hildebr...@webex.com wrote:
While we're in there, can we add a bit for the client to tell the server
On 18 February 2010 11:33, Dave Cridland d...@cridland.net wrote:
I've been meaning to jot down some ideas on components for some time. Here's
a largely unstructured list of ideas I'd like to float:
1) Components should authenticate with an ordinary jid.
That is, if I run Spectrum, say, I'd
On 5 March 2010 18:53, XMPP Extensions Editor edi...@xmpp.org wrote:
Version 0.1 of XEP-0279 (Server IP Check) has been released.
Abstract: This specification defines a simple XMPP extension that enables a
client to discover its external IP address.
Changelog: Initial published version.
On 6 March 2010 18:12, Justin Karneges
justin-keyword-jabber.093...@affinix.com wrote:
On Saturday 06 March 2010 01:33:25 Pedro Melo wrote:
On Sat, Mar 6, 2010 at 5:01 AM, Evgeniy Khramtsov xramt...@gmail.com
wrote:
There is already STUN support in ejabberd :P
For me it is unclear why we
2010/3/8 Remko Tronçon re...@el-tramo.be:
The clean separation of RFC 3920 and RFC 3921 allows this.
XEP-0279 breaks this and causes tight coupling of these layers.
On the other hand, if your server implementation has a hard time
figuring it out, don't support it.
Yay, I'm not alone in
with adding own
extensions to the protocol without asking us for acceptance.
Indeed, but going through the XSF is preferable.
Dnia 2010-03-08, pon o godzinie 15:10 +, Matthew Wild pisze:
Yay, I'm not alone in thinking that each implementation need not
support *every* published XEP
On 10 March 2010 21:42, XMPP Extensions Editor edi...@xmpp.org wrote:
Version 1.20 of XEP-0001 (XMPP Extension Protocols) has been released.
Abstract: This document defines the standards process followed by the XMPP
Standards Foundation.
Changelog: [See revision history] (psa)
Diff:
On 11 March 2010 03:59, Peter Saint-Andre stpe...@stpeter.im wrote:
On 2/26/10 4:10 PM, Peter Saint-Andre wrote:
Marcus Lundblad and I were chatting about XEP-0065 (SOCKS5 Bytestreams)
the other day and we concluded that the 'zeroconf' attribute for
streamhost/ element is probably unnecessary.
On 12 March 2010 10:37, Nicolas Vérité nicolas.ver...@process-one.net wrote:
On Fri, Mar 5, 2010 at 19:53, XMPP Extensions Editor edi...@xmpp.org wrote:
Version 0.1 of XEP-0279 (Server IP Check) has been released.
Abstract: This specification defines a simple XMPP extension that enables a
On 12 March 2010 11:57, Dave Cridland d...@cridland.net wrote:
On Sat Mar 6 09:33:25 2010, Pedro Melo wrote:
Besides, this is a trivial XEP. The C2S already has your IP address,
so its easier to ask your server for it.
That's not actually clear to me.
In the majority of our deployments,
On 12 March 2010 14:15, Nicolas Vérité nicolas.ver...@process-one.net wrote:
On Fri, Mar 12, 2010 at 14:02, Matthew Wild mwi...@gmail.com wrote:
On 12 March 2010 10:37, Nicolas Vérité nicolas.ver...@process-one.net
wrote:
On Fri, Mar 5, 2010 at 19:53, XMPP Extensions Editor edi...@xmpp.org
On 30/03/10 18:14, Peter Saint-Andre wrote:
On 3/30/10 8:20 AM, Ralph Meijer wrote:
On Tue, 2010-03-30 at 15:40 +0200, Remko Tronçon wrote:
As each message is in a stream with a particular direction
Well, not really. Clients usually generate IDs based on some simple
I (nobody ask me why) recently implemented a server-side IBB-TCP proxy.
Everything went smoothly, and it actually maps quite nicely, given that it is
already bidirectional.
One noticeable thing lacking though is a way to close a stream with an error. I
can add this data in a new namespace, but
Excerpts from Dave Cridland's message of Tue Apr 13 16:57:19 +0100 2010:
On Tue Apr 13 15:11:12 2010, Matthew Wild wrote:
I (nobody ask me why)
Why?
Oh, sorry.
Actually the reason may interest you especially, but it's off-topic for this
list, sorry :)
recently implemented a server
Excerpts from Peter Saint-Andre's message of Wed Apr 14 23:02:16 +0100 2010:
On 4/13/10 8:11 AM, Matthew Wild wrote:
I (nobody ask me why) recently implemented a server-side IBB-TCP
proxy. Everything went smoothly, and it actually maps quite nicely,
given that it is already bidirectional
Excerpts from Artur Hefczyc's message of Tue Apr 27 15:56:24 +0100 2010:
Hi,
I normally don't participate to such discussions because they tend to be
lengthy with no practical outcome.
However, I encountered a few problems related to xmlns handling recently both
with jabber.org (M-Link)
On 10 June 2010 14:37, Tuomas Koski koski.tuo...@gmail.com wrote:
Hello,
Would it be completely stupid idea to take the strict affiliations'
privileges definition out of the XEP and define a way to create
custom affiliations, discover what the affiliation can do and how to
handle the
On 13 June 2010 15:22, Steven te Brinke s.tebri...@student.utwente.nl wrote:
Hello,
Hello!
Ignoring Guus's mobile's fascination with your message...
When reading XEP-0136 I discovered some confusing properties. I will describe
these and propose changes that make them more intuitive to me. I
On 24 June 2010 21:33, Justin Karneges
justin-keyword-jabber.093...@affinix.com wrote:
It's a common problem to join a muc that already thinks you are joined, and
then the presence you send is interpretted as a mere status change rather
than a full join. Then you don't get the room roster,
On 25 June 2010 10:02, Dave Cridland d...@cridland.net wrote:
On Thu Jun 24 21:52:22 2010, Matthew Wild wrote:
On 24 June 2010 21:33, Justin Karneges
justin-keyword-jabber.093...@affinix.com wrote:
It's a common problem to join a muc that already thinks you are joined
On 26 June 2010 01:04, Bruce Campbell b+jab...@bruce-2010.zerlargal.org wrote:
On Fri, 25 Jun 2010, Matthew Wild wrote:
On 25 June 2010 10:02, Dave Cridland d...@cridland.net wrote:
There is, in fact, a workaround in M-Link, too, in as much as it's
possible
to strip out the XEP-0045
On 26 June 2010 03:09, Justin Karneges
justin-keyword-jabber.093...@affinix.com wrote:
Hi folks,
I noticed today that if I try to send a presence stanza of type error from
Psi's XML console, such as:
presence type=error to=u...@example.com/resource
error code=404 type=cancel
On 30 June 2010 06:13, Paul Aurich p...@darkrain42.org wrote:
While discussing XEP-0186 (Invisible Command) in
pros...@conference.prosody.im, I noticed that the specification doesn't
actually mention whether or not a server is supposed to generate any
sort of presence probes.
Waqas suggested
On 30 June 2010 08:06, Paul Aurich p...@darkrain42.org wrote:
On 2010-06-29 23:48, Matthew Wild wrote:
On 30 June 2010 06:13, Paul Aurich p...@darkrain42.org wrote:
While discussing XEP-0186 (Invisible Command) in
pros...@conference.prosody.im, I noticed that the specification doesn't
On 30 June 2010 16:16, Peter Saint-Andre stpe...@stpeter.im wrote:
On 6/30/10 12:48 AM, Matthew Wild wrote:
On 30 June 2010 06:13, Paul Aurich p...@darkrain42.org wrote:
While discussing XEP-0186 (Invisible Command) in
pros...@conference.prosody.im, I noticed that the specification doesn't
On 30 June 2010 16:56, Peter Saint-Andre stpe...@stpeter.im wrote:
On 6/30/10 9:32 AM, Paul Aurich wrote:
On 2010-06-30 08:16, Peter Saint-Andre wrote:
Invisibility is evil.
I'd say 'broken', but poe-tay-toe, poe-tah-toe. :)
On 6/29/10 11:13 PM, Paul Aurich wrote:
While discussing XEP-0186
On 12 July 2010 21:04, Dave Cridland d...@cridland.net wrote:
On Mon Jul 12 18:25:32 2010, Bruce Campbell wrote:
Of course, this is being very 3G-centric... If we're talking HF radio, where
you have a very low banwidth half-duplex link, then expecting your peer to
ack within a minute is
On 13 July 2010 08:56, Nicolas Vérité nicolas.ver...@gmail.com wrote:
Hi all,
This Twitter status says:
http://twitter.com/williamsjoe/status/18388944778
http://bit.ly/cuHUFE http://bit.ly/9wf14R http://bit.ly/bUKO8b (via
@melgray) [ed. interesting stuff, FaceTime uses HTTPS, SIP, STUN
On 14 August 2010 19:23, Joe Hildebrand joe.hildebr...@webex.com wrote:
On 8/9/10 7:25 PM, Matthew Wild mwi...@gmail.com wrote:
As primarily a server developer I have yet to encounter threads.
If you're doing logging for regulatory compliance on the server side,
threads are useful for trying
On 15 August 2010 15:48, Iñaki Baz Castillo i...@aliax.net wrote:
2010/8/15 Iñaki Baz Castillo i...@aliax.net:
Hi, I'm trying to find the user profile specification in XMPP. I've
found XEP-0154 User Profile which covers exactly what I'm looking
for, but it seems that such draft has been
On 17 August 2010 05:21, Peter Saint-Andre stpe...@stpeter.im wrote:
I'm forwarding this old message to the Standards list for further
discussion. Expect follow-ups soon.
/psa
Original Message
Subject: [TechReview] Review of XEP-0234, 0260 and 0261.
Date: Fri, 28 May 2010
On 17 August 2010 12:52, Peter Saint-Andre stpe...@stpeter.im wrote:
On 8/17/10 5:37 AM, Matthew Wild wrote:
Also I've had bad experience (as a user) with transfer resumption thus
far... I think some clients just ignore the range, and send from 0,
causing the range-supporting recipient
On 1 September 2010 18:04, Iñaki Baz Castillo i...@aliax.net wrote:
Hi, I'm documenting myself about XMPP protocol. I admire the good
level of interoperability between different implementations (in
contrast to other badly desinged presence protocols as SIMPLE/XCAP
which I know very well).
Hi,
On 17 September 2010 15:21, Fabrizio Guglielmino guglielm...@gmail.com wrote:
Hi all,
I'm trying to design a REST approach over XMPP, my idea is to transpose REST
normally used over HTTP to XMPP (a future RFC may be called REST over XMPP).
The natural choice is for IQ stanza but types
On 6 October 2010 13:41, Kevin Smith ke...@kismith.co.uk wrote:
Hi all,
We seem to have a contradiction in XEP-0045 about when to send
status code 100. From 13.4, we get:
Any thoughts?
Personally I think having 100 mark only non-anonymous makes most
sense. I think it's given that when you
From the XEP:
###
If catalog is restrictive, as indicated by the restrictive attribute
with value of true, the client SHOULD use one of the labels (or no
label) offered by the catalog.
One and only one of the items may have a default attribute with value
of true. The client should default to
On 10 November 2010 12:30, Dave Cridland d...@cridland.net wrote:
If a client sends a chatroom a message, and that message has an id, should
outbound messages from the chatroom to the occupants use the same id?
Doing so has obvious implications on id uniqueness, but apparently most
On 15 November 2010 20:12, Philipp Hancke fi...@goodadvice.pages.de wrote:
Am 15.11.2010 21:10, schrieb Maciek Niedzielski:
On Monday 15 November 2010 20:42:27 cxzadw fsdfzxca wrote:
Hi.
Hello,
I don't know if this is a right place to ask, but when XMPP will have
support for Offline
On 15 November 2010 21:21, cxzadw fsdfzxca edc...@gmail.com wrote:
So what i understand its defined in XMPP standard, but developers of
the servers applications disable/don't implement this feature ?
Some do, some don't.
It is so sad :-( If this is not enable by ALL XMPP servers it's
On 18 December 2010 22:44, David Ammouial d...@weeno.net wrote:
[Note to the list moderators: I sent the same email a moment ago,
before subscribing to the list. Please discard it.]
Hello,
In RFC 3921, it is implied that it is query. However, there's no
mention of whether this is a
2011/3/3 Gunnar Hellström gunnar.hellst...@omnitor.se:
Peter,
You have a good series of straightforward constructive proposals that I
think should be considered.
I just want to comment your first statement:
1. It seems to me that the real-time-text feature is very important to a
few small
On 15 March 2011 12:36, Jonathan Schleifer
js-xmpp-standa...@webkeks.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Hi.
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
On 25 March 2011 20:38, Gregg Vanderheiden g...@trace.wisc.edu wrote:
I think that we should be very careful with retro-editing.
Any edits should be plainly visible as edits. There will be a lot of
business carried out in this medium. And much of it will be carried out by
people who not
Following the MUC theme, we had a little discussion today in jabber@.
Something I hadn't really noticed before is that the actor element
in MUC (the one that tells you who performed an action like a kick or
a ban) specifies that you must use the bare JID of the actor.
This seems a really strange
On 6 April 2011 04:45, Brian Cully bcu...@gmail.com wrote:
On Apr 5, 2011, at 23:24, Matthew Wild mwi...@gmail.com wrote:
The only downside to this is backwards-compatibility. I haven't tested
any, but it might upset some clients to see an actor with no 'jid'.
Why can't the JID be no more
1 - 100 of 410 matches
Mail list logo
