reason, I can
attest that my users actually do want it. :)
Psi has had a similar experience, and we only switched from
iq:version automatically to showing caps info.
/K
--
Kevin Smith
KTP Associate - Exeter University / ai Corporation
Psi Jabber client developer/project leader (http://psi
you'll
only receive caps when it changes, because it'll be stripped out of
subsequent presence packets to you.
/K
--
Kevin Smith
KTP Associate - Exeter University / ai Corporation
Psi Jabber client developer/project leader (http://psi-im.org/)
XMPP Standards Foundation Council Member (http
guess most clients would just have
an option to ignore the tag.
/K
--
Kevin Smith
KTP Associate - Exeter University / ai Corporation
Psi Jabber client developer/project leader (http://psi-im.org/)
XMPP Standards Foundation Council Member (http://xmpp.org)
On 12 Jul 2007, at 16:37, Peter Saint-Andre wrote:
Tobias Markmann wrote:
I just noticed that it doesn't define whether duplicates are
allowed in
jid-multi or not either.
What's the point of duplicates? IMHO the jid-multi field SHOULD NOT
include duplicates and duplicates MUST be ignored.
On 3 Aug 2007, at 10:10, Robin Redeker wrote:
Hm, and what is about http://www.xmpp.org/extensions/xep-0048.html
Some people don't like 48, but I don't really know why (apart from it
depending on iq:private, which'll be upgraded one of these days). To
me muc rooms seem substantially
On 17 Aug 2007, at 18:23, Peter Saint-Andre wrote:
Kevin Smith wrote:
On 17 Aug 2007, at 16:50, Peter Saint-Andre wrote:
I propose that we write new specs to replace XEP-0048 and XEP-0145
I don't really know what's wrong with 48 - it's deployed, it
works, and
once it's updated to the new
On 27 Aug 2007, at 17:28, Peter Saint-Andre wrote:
We had a long long discussion thread about this a few months ago, as a
result of which we modified rfc3920bis to recommend the use of random
resource identifiers that are generated by the server, not the client.
FWIW, I don't agree with the
On 28 Aug 2007, at 02:49, Peter Saint-Andre wrote:
Kevin Smith wrote:
FWIW, I don't agree with the notion that these random resources are a
good thing
Yes, you have previously expressed that opinion. :)
Sorry, I'm not really trying to harp on, I realise this battle has
been fought and lost
On 23 Oct 2007, at 09:31, Tomasz Sterna wrote:
I think, that we should document best practices to do so, and
standardize the extensions you had described, in sake of
interoperability.
This couldn't hurt
/K
On 7 Nov 2007, at 09:27, Peter Saint-Andre wrote:
2. Attach a larger color sketch -- a file, the image for which a
thumbnail is a representation, or whatever (50k to 1M?). I think we
use
HTTP-PUT (perhaps via WebDAV) and jabber:x:oob, with IBB as a
fallback.
3. Send a huge color canvas -- a
The short version for people who don't want to read: I'll +1 the spec
we voted on last night at next council unless someone posts saying
that they agree with any of my objections. I won't turn this into
another PEP if no-one agrees.
On Jan 9, 2008 11:14 PM, Peter Saint-Andre [EMAIL PROTECTED]
On Jan 11, 2008 11:29 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
Peter Saint-Andre wrote:
Based on the list discussion, I have updated the provisional version of
XEP-0115 (Entity Capabilities).
I think:
pA client SHOULD enable a human user to disable inclusion of the 'v'
attribute, which
On Jan 15, 2008 3:33 AM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
I have updated the provisional version of XEP-0115 per recent list
discussion.
I have only a minor word-smithing niggle:
The collision and preimage section is a bit unclear - for the first
halfread I though the terms were
On Jan 15, 2008 8:06 PM, Dave Cridland [EMAIL PROTECTED] wrote:
Would it be reasonable to cache iq:version results against node+ver+v
of the XEP-115 if the hash attribute exists?
It doesn't really work, since the node+ver+v doesn't contain as much
info as the iq:version does.
There's no
On Jan 17, 2008 6:42 AM, Rachel Blackman [EMAIL PROTECTED] wrote:
Seriously, we're talking about breaking a really good protocol for
information that is only mildly useful...
Sure, but then recognize some people will iq:version flood because
they'll feel the need to query an entire contact
On Jan 17, 2008 9:43 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
We'll run it up the flagpole and see who salutes. :)
I'll drink to that.
Per Dave's comment:
I don't see an attack.
What one could do, with the previously suggested method (not the
current xep proposal) is to claim to be Psi
On Jan 18, 2008 11:02 AM, Alexander Gnauck [EMAIL PROTECTED] wrote:
We also have jabber:iq:time, which is more useful for me than the os
when talking to people in other timezones. And there is many other stuff
which people want to render on their roster.
Well, timezones belong in pep really as
Another factor: how many of the server implementations support the caps
optimization feature?
As far as I know - none at the moment, but presumably if this was
deemed important, it'd go in the protocol suites and it'd get
implemented. I think it's just not a priority because no-one's asking
for
On Jan 21, 2008 4:38 PM, Joe Hildebrand [EMAIL PROTECTED] wrote:
We just had a talk about this IRL, and the upshot is, I think that
Ralph is on to something. If we give up on trying to reuse hash
values across different clients, which I think is of dubious value
particularly since I don't
On Jan 22, 2008 4:11 AM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
Are we there yet?!? ;-)
That said, this revision looks fine to me.
I've only given it a quick look over so far, but this looks ok to me.
I'll give it a more thorough read before council votes.
/K
On Jan 22, 2008 6:02 AM, Tobias Markmann [EMAIL PROTECTED] wrote:
URL: http://www.xmpp.org/extensions/inbox/clientinfo.html
What are the enhancements of this XEP compared to XEP-0092? Why should
one implement this XEP and not XEP-0092? Since both XEPs seem to do
the same job I think there is
On Jan 22, 2008 3:56 AM, XMPP Extensions Editor [EMAIL PROTECTED] wrote:
Abstract: This specification defines an XMPP protocol extension that enables
a user to broadcast a question or request to other interested parties.
Perhaps someone could talk me through this one, please? The
pep/message
urn:xmpp:tmp:foo
What's not to love?
/K
On Jan 30, 2008 11:15 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
- Kevin publishes an answer to whatever node better identifies the subject
(free tagging) AND the following metadata to the commented node:
I think Kevin might want to post both to his own node, and a reference
to Peter's
On Feb 5, 2008 12:41 AM, Gaston Dombiak [EMAIL PROTECTED] wrote:
In particular the XEP says: If a server supports PEP, it MUST return an
identity of pubsub/pep (as well as a list of the namespaces and other
features
it supports, including all supported XEP-0060 features):
So the question
Thanks very much for the extensive post Dan.
It would be great, for us, if you could keep us updated with what you
discover about mobile 'XMPP', and what changes you need to make,
because we'll undoubtedly need to look at it ourselves and wrap up and
formalise the protocols (and who likes wasted
2008/3/2 Joonas Govenius [EMAIL PROTECTED]:
I suppose these last questions are a little off topic for the list but
I'm very curious about the answers myself. In fact, I'd like to work on
this stuff again for GSoC but I have a feeling the Council will want to
give the chance to someone new
2008/3/3 Mateusz Biliński [EMAIL PROTECTED]:
I've just thought I ask them here because these are strongly connected
to standardization of whiteboarding in XMPP. Do you think that I
should post these somewhere else? Maybe end user list?
I think this is pretty much the best place for you.
/K
On Sat, Mar 22, 2008 at 9:01 AM, Michal 'vorner' Vaner [EMAIL PROTECTED]
wrote:
On Fri, Mar 21, 2008 at 11:40:08PM +0100, Carlo v. Loesch wrote:
We have thus delegated stanza delivery as follows:
.net - .com - .int - .org
I'm strictly against this kind of relying.
Let's not dismiss
On Thu, Apr 3, 2008 at 7:45 AM, Pedro Melo [EMAIL PROTECTED] wrote:
I wrote a email last week in the standards list about this one. Should I
repost it in this thread? Or move it to the jdev list?
It's still in my inbox to reply to you, it didn't go unnoticed :)
/K
On Thu, Apr 17, 2008 at 8:37 AM, kawaljeet singh chadha
[EMAIL PROTECTED] wrote:
Everytime i see the extension XEP-0054, one question comes to my mind.
Why is the extension named as Vcard-temp not Vcard itself. Do temp has
some significance ?
It was supposed to be temporary, and some people
Finally replying...
On Sat, Mar 29, 2008 at 8:44 PM, Pedro Melo [EMAIL PROTECTED] wrote:
The protocol is using private storage. I talked to one of the authors,
Kevin, that told me that a PEP-powered version will be available sometime in
the future. Using private storage is not a big problem,
On Wed, Apr 2, 2008 at 11:55 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
This is interesting. Are you saying that we don't need private data
storage or PEP at all for Metacontacts? That would certainly simplify
the deployment task. :)
No, I think it's saying there's a (inferior)
On Thu, May 22, 2008 at 10:05 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
Would it be helpful for us to define 2009 suites? If so, we need to get
that done soon, because we promised that we'd define the suites for 2009
by June 30 2008 (etc.).
We should .
/K
On Tue, May 27, 2008 at 5:50 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
I'm pretty happy with the way we previously used RECOMMENDED, I think
it's a good heads-up that it'll be required the following year.
Except that sometimes it may not be required, in which case the
RECOMMENDED is a
On Wed, Jun 11, 2008 at 12:04 AM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
XEP-0085 says:
Upon receiving a gone/ event, a client MUST NOT re-use
the same Thread ID and MUST generate a new Thread ID for
any subsequent chat messages sent to the conversation
partner.
XEP-0201 says:
On Tue, Jul 15, 2008 at 4:35 PM, Jehan
[EMAIL PROTECTED] wrote:
Anyway don't you think this would be better to improve client and
server implementations rather than adding a new layer atop all the
current one? XMPP is made to be exchanged on top of a reliable
connection (most common and the
Yes, I think you're right. So maybe we just need to define gone/ more
carefully?
Seems so to me.
/K
On Wed, Jul 16, 2008 at 3:52 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
Well, gone/ is defined as the user has effectively ended their
participation in the chat session -- i.e., the user has not interacted with
the chat interface, system, or device for a relatively long period of time
It's possible this is just a UI problem.
I remember chatting to Pedro Melo about this back in February, and I
believe our conclusion back then was just that clients will start
showing -1 as a non-chat resource, or somesuch, depending on how
general usage pans out
/K
On Mon, Jul 28, 2008 at 9:58 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
In accordance with XMPP Council consensus, I have provisionally separated
all the information about pubsub collections into a new spec:
I wonder if at the same time we might want to move the information about
presence
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
I'd buy client-asserted hashes if conferencing was some peer-to-peer thing,
but MUC is a client/server design.
Plus it's conceivable that a muc service would only want to serve
rooms at addresses it supplies.
/K
But then you have a dependency on the server side, right? Why not just
generate a UUID on the client side?
Well - turn this on its head:
There are two options on the table.
1) Do it client side, and /probably/ everything works.
2) Do it server side (where it's easier), and everything certainly
On Thu, Aug 14, 2008 at 4:50 AM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
Plus it's conceivable that a muc service would only want to serve
rooms at addresses it supplies.
What difference does it make if the MUC service generates a UUID or the
client generates a UUID? One UUID is as good as
On Wed, Sep 3, 2008 at 11:15 PM, Pedro Melo [EMAIL PROTECTED] wrote:
Sure but as a server admin I would not admit a client negotiating a larger
stanza than my own C2S or S2S limits.
Sorry - I'm jumping in mid-thread again, but I don't remember seeing
this discussed.
If stanza sizes are a stream
On Tue, Sep 9, 2008 at 10:48 AM, Jehan
[EMAIL PROTECTED] wrote:
Why did you change this all? I am not speaking about Apache/lighthttpd,
this is rather transparent, but why the Drupal to Mediawiki update?
The short version (I wrote a longer version, but it turned into a rant):
Once upon a time,
On Tue, Sep 9, 2008 at 12:06 PM, Jehan
[EMAIL PROTECTED] wrote:
So a short page summarizing the current topics in the XSF, ...
On the new wiki, we could such a page now...
We could - it just needs someone to volunteer to do it and keep it up
to date by reading the lists, mucs, etc.
/K
On Tue, Sep 9, 2008 at 4:36 PM, Dave Cridland [EMAIL PROTECTED] wrote:
urn:xmpp:protoname:1
Sane.
/K
On Tue, Sep 23, 2008 at 7:24 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
Kev and I just chatted about this via IM. So I take it that we'd start
with urn:xmpp:protoname:0 and increment from there? I'm fine with that,
and it does seem more sane than the :tmp: approach.
2.
On Sat, Oct 4, 2008 at 1:18 AM, Matthew Wild [EMAIL PROTECTED] 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 the client's chosen resource. Is there a
reason that it
On Tue, Oct 7, 2008 at 2:43 PM, Pedro Melo [EMAIL PROTECTED] wrote:
There's also that the disco spec says that identity / should be
consistent beyond what is being suggested here.
You mean section 6.3, Response Consistency?
I do.
I think overloading identity at the deployment level is a bad
Doesn't it break the purpose of the caps? I originally thought the
authors wanted to have a reasonable number of different caps to cache
at the servers.
There's also that the disco spec says that identity / should be
consistent beyond what is being suggested here.
I think overloading identity
On Thu, Oct 9, 2008 at 8:22 AM, Remko Tronçon [EMAIL PROTECTED] wrote:
Consensus that we need to determine how widely XEP-0203 is
deployed before changing this to Obsolete.
This in favor of XEP-91, right? I know XEP-0146 depends on it since
recently, but that can be changed to XEP-91.
If I'm right, this is a fairly serious spec bug.
Are people doing this in the wild?
/K
On Thu, Oct 23, 2008 at 3:58 PM, Jonathan Schleifer
[EMAIL PROTECTED] wrote:
I thought about creating a XEP that defines a basic set of emoticons
http://xmpp.org/extensions/xep-0038.html#sect-id2261834
Does define a core set of smilies, but no-one's updated the XEP recently.
/K
On Fri, Oct 24, 2008 at 3:11 PM, Maciek Niedzielski [EMAIL PROTECTED] wrote:
Does any client use JISP?
Psi does.
I'm fairly sure we're not the only ones, although I can't remember
offhand who else does.
/K
On Sat, Oct 25, 2008 at 11:48 AM, Artur Hefczyc
[EMAIL PROTECTED] wrote:
Just so you know, that parser is not a conforming XML parser. Tigase
happily accepts data that is not XML-well-formed, and happily routes
or delivers it.
That's true but please note that XMPP stream is not really XML
On Mon, Oct 27, 2008 at 5:58 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote:
For a message stanza of type groupchat, the server SHOULD NOT
deliver the stanza to any of the available resources but instead
SHOULD return an error to the sender.
That's consistent with my view of how the world
On Wed, Nov 5, 2008 at 9:19 PM, Waqas [EMAIL PROTECTED] wrote:
Hopefully this was the Right Way to post these. I was wondering if I
should have posted these separately, particularly the part about
XEP-0049.
I think posting them at all was most welcome - Peter may have views on
the most
On Tue, Nov 25, 2008 at 2:52 PM, Jonathan Schleifer
[EMAIL PROTECTED] wrote:
In Gajim, yes. In other clients it's deployed.
Yes, but that are *VERY* few, like Psi in SVN (last time I tried to build
it, it wouldn't because it's still coded for gcc 3 and after about 20
changes I got too lazy to
On Tue, Dec 2, 2008 at 7:25 PM, Jonathan Schleifer
[EMAIL PROTECTED] wrote:
I wouldn't want that, I really wouldn't want that. I have an mcabber
That's ok - when it's not the only online resource, mcabber will know
(through mine-ing) that it's not being talked to, so there's no reason
for it to
On Tue, Dec 2, 2008 at 8:55 PM, Joe Hildebrand [EMAIL PROTECTED] wrote:
That's ok - when it's not the only online resource, mcabber will know
(through mine-ing) that it's not being talked to, so there's no reason
for it to be logging the messages.
I would suggest that it could remove them from
FYI...
-- Forwarded message --
From: Kevin Smith ke...@kismith.co.uk
Date: Thu, Dec 11, 2008 at 6:01 PM
Subject: Minutes of meeting 2008-12-10
To: XMPP Council coun...@xmpp.org
Results of the XMPP Council meeting held 2008-12-10...
Agenda:
http://xmpp.org/council/agendas/2008
FYI:
-- Forwarded message --
From: Kevin Smith
Date: Wed, Jan 21, 2009 at 8:51 PM
Subject: Minutes 2009-01-21
To: XMPP Council
Date: 2009-01-21
Time: 20:00 UTC
Place: xmpp:coun...@conference.jabber.org
Log:http://logs.jabber.org/coun...@conference.jabber.org/2009-01-21
On Thu, Jan 22, 2009 at 7:15 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
Proposed text at the bottom.
WFM.
Thanks Peter,
/K
On Fri, Jan 23, 2009 at 11:30 AM, Jonathan Schleifer
js-xmpp-standa...@webkeks.org wrote:
Btw, I got one suggestion that would fix merging contacts: Give contacts a
UUID when you make them a meta contact. That UUID could be shared on the two
servers, so the client knows that the contacts from
009/1/23 Jiří Zárevúcký zarevucky.j...@gmail.com:
Really, if this is something that is going to be discussed, then you should
just allow for extra XML namespaces under each item in the roster.
I was thinking about this and it really starts to seem to me like the
best idea of this entire
On Mon, Feb 9, 2009 at 1:33 PM, Matt Ford m...@dancingfrog.co.uk wrote:
The question is is it sensible? should the spec change or is it a bug in
ejabberd?
It's both - it's a bug in ejabberd that it doesn't follow the spec,
and it's a bug in the spec because that's not sensible :)
The spec
On Tue, Feb 10, 2009 at 11:02 PM, Kurt Zeilenga kurt.zeile...@isode.com wrote:
It seems not so sensible when the admin happens to be authenticating
directly to the server hosting the chatroom. But for the case where the
administrator authenticates elsewhere, possibly to a server under separate
On Wed, Feb 11, 2009 at 12:58 PM, Kurt Zeilenga kurt.zeile...@isode.com wrote:
I'm thinking more about a non-comprised server case, but just the case of
poor administrative practices.
Ok, I follow, thanks. Given that, maybe keeping password requirements
on all affiliations is sensible.
/K
On Wed, Feb 11, 2009 at 3:08 PM, Matthew Wild mwi...@gmail.com wrote:
This single issue aside however, I do think that the total lack of any
way to track which services a JID is affiliated with is scary. This
affects transports/gateways, MUCs, etc. Are roster subscriptions even
cancelled on
On Thu, Mar 5, 2009 at 9:44 AM, Pavel Simerda pav...@pavlix.net wrote:
From an IM user's point of view, trying to settle on the highest
common permissions seems more appropriate (and less confusing).
Very bad idea. You have either to go for lowest... or negotiate with
the user. (Privacy
On Thu, Mar 5, 2009 at 5:12 PM, Klaus Hartke
klaus.har...@googlemail.com wrote:
Q4. Should stanzas directed to a bare jid always be sent
via the server, or should the client look at received
presence stanzas from that jid and, if the client has
a end-to-end connection
On Wed, Mar 18, 2009 at 9:35 AM, Kevin Smith ke...@kismith.co.uk wrote:
That sounds entirely sane to me.
Sorry, I quoted the wrong bit, try:
Eg in Muc it makes no sense to ban anonymous Jids or perform other similar
actions on such users.
Or a room owner may no allow anonymous users because
Having a read of the Security Labels XEP, it seems that it's going to
have some interesting interactions with MUC upgrading from 1-1 chats.
Particularly, you're going to invite someone with a different
catalogue, and then upload past history to the room. Any thoughts?
/K
On Thu, Mar 19, 2009 at 10:26 AM, Dave Cridland d...@cridland.net wrote:
Moreover, I don't think your client could - with the facilities in XEP-0258
- make the 1:1 - MUC transition without human intervention, and, more
probably, human knowledge about clearances.
Or, probably, the 258-enabled
FYI...
-- Forwarded message --
From: Kevin Smith
Date: Wed, Apr 1, 2009 at 8:55 PM
Subject: Meeting minutes 2009-04-01
To: XMPP Council coun...@xmpp.org
Date: 2009-04-01
Time: 19:00 UTC
Place: xmpp:coun...@conference.jabber.org
Log: http://logs.jabber.org/coun
On Tue, Apr 14, 2009 at 10:40 AM, Nicolas Vérité
nicolas.ver...@gmail.com wrote:
Not so nonsense: I wish I had the passed attention requests when I get
back to my client...
It is a worthwhile information, even if it's too late. That way, I
could contact back the guy that tried to get my
This XEP is maked as historical, why? Is it replaced by something else?
Shouldn't it be updated to use pubsub instead of XML storage?
Well, I think really we want the ability to hang arbitrary data off
roster items.
At least, that's what I'd like :)
/K
FYI:
-- Forwarded message --
Date: Wed, May 6, 2009 at 8:31 PM
Subject: [Council] Minutes for May 6
Role call:
All present
Agenda bashing:
None.
- - XEP-0166: Jingle
- - XEP-0167: Jingle RTP Sessions
- - XEP-0176: Jingle ICE-UDP Transport Method
- - XEP-0177: Jingle Raw
On Wed, Jun 17, 2009 at 12:06 PM, Sergei Golovan sgolo...@gmail.com wrote:
If you get a ping response, then - due to the ordering of all stanzas
between two endpoints - the message must have been delivered.
I'm afraid that if the previous stanza wasn't delivered for some reason then
2009/6/17 Remko Tronçon re...@el-tramo.be:
Well, there's not much worse than a reliable messaging protocol that isn't
100% reliable. If there's the slightest possibility that this fails (e.g.
client going offline and coming online with the same resource, and for some
reason the presence
On Wed, Jun 17, 2009 at 2:29 PM, Evgeniy Khramtsovxramt...@gmail.com wrote:
Dave Cridland wrote:
Well, a broken client is by its nature unreliable
I don't think you can do anything to prevent that.
We can show to the sender that the recipient didn't receive the message.
How? If the client is
On Wed, Jun 17, 2009 at 2:55 PM, Evgeniy Khramtsovxramt...@gmail.com wrote:
How? If the client is broken, you have no way of knowing that it's not
sending message receipts in error.
Message receipts in error? What do you mean?
If your message isn't processed due to an internal client error,
On Wed, Jun 17, 2009 at 3:13 PM, Brian Cully bcu...@gmail.com wrote:
Don't get me wrong, I agree that there are no perfect guarantees.
However, I think focusing too much on that is distracting. While you can
never know for sure you can establish a certain amount of trust. Message ACKs
On Fri, Jun 26, 2009 at 2:54 AM, Matthew Wildmwi...@gmail.com wrote:
I look forward to hearing the opinion of others on this,
Sounds right to me.
/K
On Mon, Jul 6, 2009 at 7:40 PM, Philipp Hanckefi...@goodadvice.pages.de wrote:
heh... xmpp should be more like irc ;-)
Another way I can see XMPP becoming more IRC-like wrt MUC and SASL
anonymous: IRC servers often do lookups on clients to check they're
not running from an open proxy - I can see
On Mon, Jul 6, 2009 at 8:10 PM, Peter Saint-Andrestpe...@stpeter.im wrote:
Another way I can see XMPP becoming more IRC-like wrt MUC and SASL
anonymous: IRC servers often do lookups on clients to check they're
not running from an open proxy - I can see a situation in which
servers will start
On Tue, Jul 14, 2009 at 5:48 PM, Peter Saint-Andrestpe...@stpeter.im wrote:
- It does a jabber:iq:roster request on gateway.example.com
This is not limited to gateways, but also to shared groups services
(e.g., you get all the XSF members in a special Members group).
This is so simple and
On Wed, Jul 15, 2009 at 4:59 AM, Peter Saint-Andrestpe...@stpeter.im wrote:
Could we just do a new urn:xmpp:roster namespace, expose your master roster
via that namespace (also), and use that new namespace to talk to external
entities?
Or we could use jabber:iq:roster as we always have in the
While we're discussing upgrading roster handling, can I put my request
in for hanging arbitrary xml off the roster entries, please?
/K
2009/7/15 Remko Tronçon re...@el-tramo.be:
I'm sure there were good reasons for both these suggestions - I can
understand why if we upgrade the usage we can upgrade the namespace,
but what is the motivation for suggesting two different namespaces for
the same job?
It will take some time until
On Wed, Jul 15, 2009 at 3:31 PM, Peter Saint-Andrestpe...@stpeter.im wrote:
While we're discussing upgrading roster handling, can I put my request
in for hanging arbitrary xml off the roster entries, please?
Look, folks, this is a major redesign of core XMPP functionality. I
think we need to
On Thu, Jul 16, 2009 at 9:18 AM, Richard Dobsonrich...@dobson-i.net wrote:
I don't need a new protocol actually. I would like to have the ability to
add extra namespaced nodes to each item, that would solve all my pet
peeves with roster entries.
Like how Google Talk works?
On Thu, Jul 16, 2009 at 10:14 AM, Richard Dobsonrich...@dobson-i.net wrote:
Yes, similar, except I'd like to hang extra elements off it, instead
of extra attributes.
Surely you can just namespace an element then instead of just an attribute
to accomplish that? As far as I can see whether its
On Thu, Jul 16, 2009 at 10:57 AM, Jonathan
Schleiferjs-xmpp-standa...@webkeks.org wrote:
The real problem with the presence flood is that they come for about 5
minutes for me. It's like there's one wave of available presences every 30
seconds. This is kind of annoying if you just connect to see
On Thu, Jul 16, 2009 at 2:19 PM, Fabio Fornofabio.fo...@gmail.com wrote:
Some more thoughts, which are the business rules for accepting roster
items? I explain with some cases:
- in the main roster on the server we have jids coming from any domain
- can rosters coming form separate services
On Thu, Jul 16, 2009 at 3:01 PM, Fabio Fornofabio.fo...@gmail.com wrote:
They can come from any domain - think of a shared roster/user groups service.
Uhm, I'm trying to think together with presence delivery too. Shared
roster is bit tricky in that, since shared.jabber.org could tell you
that
On Thu, Jul 16, 2009 at 3:53 PM, Jonathan
Schleiferjs-xmpp-standa...@webkeks.org wrote:
The
idea that some might be shown as being offline although their offline is
quite scary.
Yes, and astonishing, too.
/K
1 - 100 of 1144 matches
Mail list logo
