Dnia 05-07-2007, czw o godzinie 16:49 -0600, Peter Saint-Andre
napisał(a):
If the server could handle and client knows it could handle, it could
use longer names.
How does the client know?
It tried to put a long name in a minute ago and it succeeded.
640KB SHOULD be enough for anyone.
Peter Saint-Andre wrote:
Whenever a client publishes the first item to a node that ends in
+[accessmodel], the pubsub service MUST create the node with a default
access model equal to the specified model (that is open or presence
or roster or authorize or whitelist). [1] For such a node, the
On Friday 06 July 2007 06:49, XMPP Extensions Editor wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Getting a User's Attention
Abstract: This document defines an XMPP protocol extension for getting a
user's attention.
I know it doesn't have the humour tag,
On 6 Jul 2007, at 13:06, Daniel Noll wrote:
But mobile client users and authors are still going to object to
receiving
data they didn't ask for, especially if it's the same size as what was
already being sent in the presence. :-)
Remember that if the server supports the caps optimisation
On Friday 06 July 2007 01:53, Peter Saint-Andre wrote:
We *could* do that with the video phone activity. It's a bit of a
borderline case, but IMHO it's going to be common enough that we want to
define a separate activity for it.
Video phones may become common enough one day (when Cisco stop
On 6 Jul 2007, at 13:13, Daniel Noll wrote:
Title: Getting a User's Attention
I know it doesn't have the humour tag, but I still can't tell if
this is a
joke or not. Either way, it sounds like it has the potential to be
the most
abused feature ever. :-)
Some users want such a feature; I
On Jul 06, 2007, at 14:13, Daniel Noll wrote:
It may even be desirable to enable this per-user. Whether this
means giving
different users different disco results or giving the same result and
silently dropping the packet, I'm not sure. I think I would prefer
the third
option, the sender
Hello
On Fri, Jul 06, 2007 at 10:54:01AM +0100, Richard Dobson wrote:
It would be handy to also specify an extended additional error along with
the not-allowed/ so that the client can know what part of the roster item
is wrong which would add to the flexibility, e.g. name-limit-exceeded
Daniel Noll wrote:
On Friday 06 July 2007 09:00, Peter Saint-Andre wrote:
Robin Redeker wrote:
And I think announcing capabilities seems to be a great application
of PEP/PubSub. I can already imagine the client setting:
PEP depends on XEP-0115. Circular dependencies seem like a bad idea.
Andreas Monitzer wrote:
On Jul 06, 2007, at 17:55, Peter Saint-Andre wrote:
Isn't not-authorized an iq result, and thus not applicable for a message
stanza?
If the message contains only the attention element (as it certainly
should), then the recipient can simply ignore it. It's not
On Jul 06, 2007, at 18:31, Peter Saint-Andre wrote:
How do other services implement this kind of poke feature? I
assume in
the UI you can right-click or whatever to choose poke stpeter and
your
client sends this special message off to me.
Usually, it's a button in the message window I
How do other services implement this kind of poke feature? I
assume in
the UI you can right-click or whatever to choose poke stpeter and
your
client sends this special message off to me. I think it's less likely
that you'd send a message (hey pay attention!) with the poke, but
naturally you
Rachel Blackman wrote:
How do other services implement this kind of poke feature? I assume in
the UI you can right-click or whatever to choose poke stpeter and your
client sends this special message off to me. I think it's less likely
that you'd send a message (hey pay attention!) with the
Ian Paterson wrote:
Peter Saint-Andre wrote:
Whenever a client publishes the first item to a node that ends in
+[accessmodel], the pubsub service MUST create the node with a default
access model equal to the specified model (that is open or presence
or roster or authorize or whitelist). [1]
As previously mentioned, I provisionally removed server dialback from
rfc3920bis in preparation for moving that documentation to a XEP:
http://www.xmpp.org/extensions/inbox/dialback.html
Unfortunately, the Council has not yet approved publication of the
server dialback proto-XEP. Therefore I
Thanks for the helpful post, Ralph. Comments inline.
Ralph Meijer wrote:
First of I want to restate the issue: the publisher wants to publish an
item to a node that has a certain access model. There are two ways to
solve this:
1. No auto create.
In this case, there is no magical node
Since poke (or buzz) is usually just implemented on any service or
client as your message window jittering around on the recipient's
desktop like a toddler who's just drunk a venté espresso, people
tend to
send a message, then hit poke.
I guess we can't call it poke, since that's already
On Saturday 07 July 2007 02:04, Peter Saint-Andre wrote:
Daniel Noll wrote:
On Friday 06 July 2007 09:00, Peter Saint-Andre wrote:
Robin Redeker wrote:
And I think announcing capabilities seems to be a great application
of PEP/PubSub. I can already imagine the client setting:
PEP
On Friday 06 July 2007 22:19, Kevin Smith wrote:
On 6 Jul 2007, at 13:06, Daniel Noll wrote:
But mobile client users and authors are still going to object to
receiving
data they didn't ask for, especially if it's the same size as what was
already being sent in the presence. :-)
Remember
On Saturday 07 July 2007 01:55, Peter Saint-Andre wrote:
If the message contains only the attention element (as it certainly
should), then the recipient can simply ignore it. It's not necessary to
return an error, IMHO.
To some extent though I'd like to know if I prod someone whose client
20 matches
Mail list logo
