Pavel Simerda wrote:
On Tue, 05 Aug 2008 09:16:45 -0600
Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
IMHO you'd get account/* from a bare JID and client/* from a full JID.
/psa
But then account/* should never send presence, no?
Right, account/* is service discovery only, not presence. I wa
On Tue, 05 Aug 2008 09:16:45 -0600
Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> Maciek Niedzielski wrote:
> > Peter Saint-Andre wrote:
> >>> I like the part that only client/* should be interpreted as
> >>> IM-capable resources, but I don't know if that is too strict.
> >>
> >> That's probably
Maciek Niedzielski wrote:
Peter Saint-Andre wrote:
I like the part that only client/* should be interpreted as
IM-capable resources, but I don't know if that is too strict.
That's probably too strict. At the least I think we'd say that the
following identities are IM-capable:
account/*
clie
Peter Saint-Andre wrote:
I like the part that only client/* should be interpreted as IM-capable
resources, but I don't know if that is too strict.
That's probably too strict. At the least I think we'd say that the
following identities are IM-capable:
account/*
client/*
I always thought the
Pedro Melo wrote:
On Aug 5, 2008, at 12:01 AM, Peter Saint-Andre wrote:
Pedro Melo wrote:
On Jul 31, 2008, at 5:21 PM, Dave Cridland wrote:
On Thu Jul 31 17:17:40 2008, Pedro Melo wrote:
Moving forward, this would allow clever clients to observe that
it wasn't a IM client capable of handli
On Aug 5, 2008, at 12:01 AM, Peter Saint-Andre wrote:
Pedro Melo wrote:
On Jul 31, 2008, at 5:21 PM, Dave Cridland wrote:
On Thu Jul 31 17:17:40 2008, Pedro Melo wrote:
Moving forward, this would allow clever clients to observe that
it wasn't a IM client capable of handling calendaring
r
Pedro Melo wrote:
On Jul 31, 2008, at 5:21 PM, Dave Cridland wrote:
On Thu Jul 31 17:17:40 2008, Pedro Melo wrote:
Moving forward, this would allow clever clients to observe that it
wasn't a IM client capable of handling calendaring requests, but a
dumb calendaring bot working on behalf of
On Thu, 31 Jul 2008 20:47:25 +0100
Dave Cridland <[EMAIL PROTECTED]> wrote:
> On Thu Jul 31 17:54:32 2008, Pedro Melo wrote:
> >
> > On Jul 31, 2008, at 5:21 PM, Dave Cridland wrote:
> >
> >> On Thu Jul 31 17:17:40 2008, Pedro Melo wrote:
> Moving forward, this would allow clever clients to
On Thu Jul 31 17:54:32 2008, Pedro Melo wrote:
On Jul 31, 2008, at 5:21 PM, Dave Cridland wrote:
On Thu Jul 31 17:17:40 2008, Pedro Melo wrote:
Moving forward, this would allow clever clients to observe that
it wasn't a IM client capable of handling calendaring requests,
but a dumb cal
On Jul 31, 2008, at 5:21 PM, Dave Cridland wrote:
On Thu Jul 31 17:17:40 2008, Pedro Melo wrote:
Moving forward, this would allow clever clients to observe that
it wasn't a IM client capable of handling calendaring requests,
but a dumb calendaring bot working on behalf of the user.
Not f
On Jul 31, 2008, at 5:21 PM, Dave Cridland wrote:
On Thu Jul 31 17:17:40 2008, Pedro Melo wrote:
Moving forward, this would allow clever clients to observe that
it wasn't a IM client capable of handling calendaring requests,
but a dumb calendaring bot working on behalf of the user.
Not f
On Thu Jul 31 17:17:40 2008, Pedro Melo wrote:
Moving forward, this would allow clever clients to observe that it
wasn't a IM client capable of handling calendaring requests, but
a dumb calendaring bot working on behalf of the user.
Not following.
Clients could have an integrated calenda
On Jul 30, 2008, at 8:40 PM, Peter Saint-Andre wrote:
Dave Cridland wrote:
On Wed Jul 30 13:55:56 2008, Pedro Melo wrote:
The most important part of -1 resources are their caps. For
example, I can have a calendar app logged in with my own jid,
accepting some namespace for calendar update
On Jul 30, 2008, at 7:25 PM, Dave Cridland wrote:
On Wed Jul 30 13:55:56 2008, Pedro Melo wrote:
The most important part of -1 resources are their caps. For
example, I can have a calendar app logged in with my own jid,
accepting some namespace for calendar updates or meeting requests.
A
On Wed Jul 30 20:40:13 2008, Peter Saint-Andre wrote:
Dave Cridland wrote:
On Wed Jul 30 13:55:56 2008, Pedro Melo wrote:
The most important part of -1 resources are their caps. For
example, I can have a calendar app logged in with my own jid,
accepting some namespace for calendar updates
Dave Cridland wrote:
On Wed Jul 30 13:55:56 2008, Pedro Melo wrote:
The most important part of -1 resources are their caps. For example,
I can have a calendar app logged in with my own jid, accepting some
namespace for calendar updates or meeting requests.
Are you suggesting a sort of negat
On Wed Jul 30 13:55:56 2008, Pedro Melo wrote:
The most important part of -1 resources are their caps. For
example, I can have a calendar app logged in with my own jid,
accepting some namespace for calendar updates or meeting requests.
Are you suggesting a sort of negative disco feature wh
Hi,
(sorry to be late at the discussion) :)
On Jul 27, 2008, at 8:26 PM, Kevin Smith wrote:
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
Jack Moffitt wrote:
1. stanzas to the bare JID should not be send to this client
because no user will read it. Use message storage or whatever a
server may do with such a message.
Agreed, and this required by RFC 3921. (Section 11.1 Rule 4.1).
2. stanzas to the full JID should be send
> 1. stanzas to the bare JID should not be send to this client
> because no user will read it. Use message storage or whatever a
> server may do with such a message.
Agreed, and this required by RFC 3921. (Section 11.1 Rule 4.1).
> 2. stanzas to the full JID should be send to this client.
"Jack Moffitt" wrote:
>>> 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 pan
On Mon, Jul 28, 2008 at 5:53 AM, Jack Moffitt <[EMAIL PROTECTED]> wrote:
> Jabberd2 and Google Talk both refuse to send presence to resources at
> priority -1. This is fatal for us with Speeqe since this means you
> will never receive muc presence from the room. I haven't tested this
> yet with P
>> 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
Ok, fair enough, but
> 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
It's possible this is just a UI problem.
http://blog.jabber.com/filaments/2008/03/11/priority-1-presence/
-1 resources should be included in the probe response.
On Jul 24, 2008, at 11:57 AM, Jack Moffitt wrote:
At XMPP Summit 5 this past week it became clear that lots of people
are using or a
At XMPP Summit 5 this past week it became clear that lots of people
are using or are planning to use presence priorities of -1 to allow
specialized clients access to various XMPP resources. At Speeqe we do
this so that our MUC client doesn't steal private messages. I believe
that Fritzy at Seesmi
26 matches
Mail list logo
