2009/4/22 Dave Cridland :
>
> I'm entirely happy with it. But then again, I'm server-side, I don't have to
> do anything. :-)
>
Not exactly. Server has to add the delay element to probe responses ;)
On Wed Apr 22 21:55:10 2009, Jiří Zárevúcký wrote:
Seems fine, but it looks to me more like a best practice then a
standards track protocol... :)
No, it needs a defined meaning to work between clients - it's
standards-track work.
I'm entirely happy with it. But then again, I'm server-side,
Seems fine, but it looks to me more like a best practice then a
standards track protocol... :)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/22/09 2:45 PM, Marcus Lundblad wrote:
> ons 2009-04-22 klockan 15:04 -0500 skrev XMPP Extensions Editor:
>> This message constitutes notice of a Last Call for comments on
>> XEP-0256 (Last Activity in Presence).
>>
>> Abstract: This specification
ons 2009-04-22 klockan 15:04 -0500 skrev XMPP Extensions Editor:
> This message constitutes notice of a Last Call for comments on XEP-0256 (Last
> Activity in Presence).
>
> Abstract: This specification defines a way to use the Last Activity extension
> in XMPP presence notifications.
>
> URL:
This message constitutes notice of a Last Call for comments on XEP-0256 (Last
Activity in Presence).
Abstract: This specification defines a way to use the Last Activity extension
in XMPP presence notifications.
URL: http://www.xmpp.org/extensions/xep-0256.html
This Last Call begins today and s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
FYI.
- Original Message
Subject: [Council] meeting minutes, 2009-04-22
Date: Wed, 22 Apr 2009 13:57:56 -0600
From: Peter Saint-Andre
Reply-To: XMPP Council
To: XMPP Council
Results of the XMPP Council meeting held 2009-04-22...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp Hancke has been working to refactor XEP-0220 so that it is
easier to read, more accurate, and closer to what's in RFC 3920 than to
what is now in XEP-0220. In the XMPP Council meeting just now several
participants indicated that they like the a
Version 0.9 of XEP-0237 (Roster Versioning) has been released.
Abstract: This specification defines a proposed modification to the XMPP roster
protocol that enables versioning of rosters such that the server will not send
the roster to the client if the roster has not changed, thus saving bandwi
Jiří Zárevúcký wrote:
> All the user has to do is to delete clients cache, in case he notices
> any inconsistency. Compared to the difficulty of solving such rare
> cases on the protocol level, it is not so much problematic I guess.
The only "easy" solution I see is to have separate "base" version
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/22/09 8:55 AM, Yann Leboulanger wrote:
> Hi,
>
> 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?
I think it is historical because of the dependency on XEP-00
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/22/09 9:18 AM, Kevin Smith wrote:
>>> 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 of
>> 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
Hi,
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?
--
Yann
2009/4/22 Peter Saint-Andre :
>
> Done. Currently I have this in my working copy:
>
> ***
>
> 2.3 Server Response
>
> Whether or not the roster has changed since the version enumerated by
> the client, the server MUST either return the complete roster as
> described in RFC 3921 or return an empty I
2009/4/22 Peter Saint-Andre :
>
> If the client says it has roster version X and the server returns only a
> few roster pushes, which are inconsistent with the roster version that
> the human user sees in another client, then perhaps the user suspects
> that there is something very wrong and calls
16 matches
Mail list logo
