Thanks. It's much better now IMO. :)
2009/5/13 Waqas Hussain waqa...@gmail.com:
2009/5/13 Jiří Zárevúcký zarevucky.j...@gmail.com:
2009/5/12 Peter Saint-Andre stpe...@stpeter.im:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5/9/09 12:52 PM, Jiří Zárevúcký wrote:
I have read the text again after a while and the following
2009/5/13 Matthew Wild mwi...@gmail.com:
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
2009/5/13 Leonid Evdokimov l...@darkk.net.ru:
Jiří Zárevúcký wrote:
If it is a hash of a complete roster (as Peter has told) then the
server would have to decode this hash, figure out exactly what version
that was, create a difference, figure out the version for every
change, and send every
2009/5/13 Leonid Evdokimov l...@darkk.net.ru:
Jiří Zárevúcký wrote:
You didn't understand me. I'm just talking about examples being the
worst/most difficult to implement way imaginable. If developers really
do implement XEPs the example way, I'm frightened by the way servers
would implement
2009/5/13 Dave Cridland d...@cridland.net:
Now, what Jiří is saying is that in the examples, we're illustrating what
appears to be the method described in 5.2, but giving it the behaviour of an
implementation using the method described in 5.3, whereas using a pure
sequence value is simpler to
2009/5/12 Remko Tronçon re...@el-tramo.be:
On Mon, May 11, 2009 at 5:51 PM, Dave Cridland d...@cridland.net wrote:
This did get me wondering about the issue that if there's two semantically
identical forms for the same information, then should we ever wish to have
clients sign the privacy
2009/5/12 Peter Saint-Andre stpe...@stpeter.im:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5/9/09 12:52 PM, Jiří Zárevúcký wrote:
I have read the text again after a while and the following text got my
attention:
If a series of roster modifications result in a roster item that does
(the examples have
A and B so I suppose the next 'ver' will be C and then the
client breaks when that's not the case).
That's pretty much impossible, as no server would in reality use such
scheme (I can understand when someone makes a crappy client, but a
server developer strictly
I have read the text again after a while and the following text got my
attention:
If a series of roster modifications result in a roster item that does not
differ from the
version cached by the client (e.g., a modification to the item's 'name'
attribute and
then a modification back to the
Well... I don't know whether this is the right place to ask this
question, but is there ANY client that support SI filetransfer via IBB
correctly in the spec's current revision? The closest I found to
functional is Tkabber's unannounced use of messages instead of IQ's
and I'm really tired of
2009/4/29 Will Thompson will.thomp...@collabora.co.uk:
Jiří Zárevúcký wrote:
Well... I don't know whether this is the right place to ask this
question, but is there ANY client that support SI filetransfer via IBB
correctly in the spec's current revision? The closest I found to
functional
I've noticed change in this part:
the server MUST consider the item to have been modified and therefore MUST
send the item to the client (typically via a roster push as described below).
You changed the MUSTs to MAY, which again introduces several possible
problems. You can find reasons in
2009/4/25 Paul Aurich p...@darkrain42.org:
I think it's critical to distinguish user-generated traffic from
client-generated outgoing stanzas. I agree with Will that, for the former,
this is a really frustrating UI and I'd hate my client for doing it.
I think that's exactly the problem in
2009/4/25 Will Thompson will.thomp...@collabora.co.uk:
Obviously the client should try not to expose the user without them
doing something that obviously exposes them, so prompting them if they
wouldn't expect to be exposed is reasonable. I think that's what the XEP
was trying to ensure, but
Upon receiving notice that a data packet is cannot be processed by
the recipient, the sender SHOULD consider the bytestream to be closed
and invalid but MAY attempt to correct the error and re-send the
offending data packet using the same sequence number (the recipient
MUST NOT consider a sequence
2009/4/24 Christoph Terwelp m...@seark.de:
Am 24.04.2009 um 14:10 schrieb Matthew Wild:
On Fri, Apr 24, 2009 at 1:02 PM, Christoph Terwelp m...@seark.de wrote:
If the ver attribute is some kind of a hash of the roster, a additional
feature could be added, to inform the client which method
2009/4/23 Will Thompson will.thomp...@collabora.co.uk:
Hi,
I was just glancing over XEP-0186, and I noticed the following section:
3.1.2 Client Handling
While the client is in invisible mode, the client:
* MUST maintain a temporary list of entities with which communication is
2009/4/22 Peter Saint-Andre stpe...@stpeter.im:
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
Seems fine, but it looks to me more like a best practice then a
standards track protocol... :)
2009/4/22 Dave Cridland d...@cridland.net:
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 ;)
2009/4/21 Peter Saint-Andre stpe...@stpeter.im:
I propose the following implementation note:
In some conditions, an XMPP client or server might know that the
sequence numbering is invalid (e.g., because of a catastrophic server
failure). In these cases, the entity that discovers the
2009/4/21 Peter Saint-Andre stpe...@stpeter.im:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/21/09 12:57 PM, Jiří Zárevúcký wrote:
2009/4/21 Peter Saint-Andre stpe...@stpeter.im:
I propose the following implementation note:
In some conditions, an XMPP client or server might know
2009/4/22 Peter Saint-Andre stpe...@stpeter.im:
There could be another problem, though. If the roster got reverted,
some client could update it up to the original sequence number or
further. Then if some client that wasn't used for long time came
online, it could receive wrong updates.
I
2009/4/17 Peter Saint-Andre stpe...@stpeter.im:
Jiří, it's better to raise issues than to ignore them. Sometimes we
conclude that the issue isn't very serious, but often we don't know that
until we discuss it for a while. So keep posting!
Sure, I will.
I guess the only issue now is the
2009/4/17 Leonid Evdokimov l...@darkk.net.ru:
Jiří Zárevúcký wrote:
I guess the only issue now is the unneeded restriction you added to
the SVN based on my incorrect feedback. I mean the part The client
MUST NOT process any of the interim roster pushes until I think
you can safely remove
2009/4/17 Jiří Zárevúcký zarevucky.j...@gmail.com:
2009/4/17 Leonid Evdokimov l...@darkk.net.ru:
Jiří Zárevúcký wrote:
I guess the only issue now is the unneeded restriction you added to
the SVN based on my incorrect feedback. I mean the part The client
MUST NOT process any of the interim
2009/4/17 Dave Cridland d...@cridland.net:
On Fri Apr 17 16:05:06 2009, Jiří Zárevúcký wrote:
2009/4/17 Dave Cridland d...@cridland.net:
On Fri Apr 17 15:06:36 2009, Jiří Zárevúcký wrote:
2009/4/17 Peter Saint-Andre stpe...@stpeter.im:
Jiří, it's better to raise issues than
2009/4/17 Peter Saint-Andre stpe...@stpeter.im:
We can't send an IQ-result that's unrelated to any IQ-set or IQ-get.
I was thinking more like this:
Client sends IQ get.
Server sends interim pushes.
Server sends empty result to the clients get.
Or we could respond with What you have is okay,
2009/4/17 Leonid Evdokimov l...@darkk.net.ru:
Dave Cridland wrote:
No, that's quite valid restriction. Client MAY cache some roster pushes
to resume operation from the middle of transaction in case of broken
connection, but it MUST NOT bump it's internal roster version until it
gets the full
2009/4/17 Peter Saint-Andre stpe...@stpeter.im:
On 4/17/09 9:57 AM, Peter Saint-Andre wrote:
On 4/17/09 8:18 AM, Leonid Evdokimov wrote:
Jiří Zárevúcký wrote:
I guess the only issue now is the unneeded restriction you added to
the SVN based on my incorrect feedback. I mean the part The client
2009/4/17 Peter Saint-Andre stpe...@stpeter.im:
On 4/17/09 11:51 AM, Jiří Zárevúcký wrote:
2009/4/17 Peter Saint-Andre stpe...@stpeter.im:
On 4/17/09 9:57 AM, Peter Saint-Andre wrote:
On 4/17/09 8:18 AM, Leonid Evdokimov wrote:
Jiří Zárevúcký wrote:
I guess the only issue now is the unneeded
2009/4/17 Peter Saint-Andre stpe...@stpeter.im:
On 4/17/09 11:55 AM, Jiří Zárevúcký wrote:
2009/4/17 Peter Saint-Andre stpe...@stpeter.im:
On 4/17/09 11:51 AM, Jiří Zárevúcký wrote:
2009/4/17 Peter Saint-Andre stpe...@stpeter.im:
On 4/17/09 9:57 AM, Peter Saint-Andre wrote:
On 4/17/09 8:18
2009/4/17 Leonid Evdokimov l...@darkk.net.ru:
...
So the first method works like trivial VCS and the second one works like
rsync or incremental tar. What method is actually described in the XEP ?
Seems, that will also answer Jiří's question about `treat as normal`
statement.
The general
2009/4/17 Peter Saint-Andre stpe...@stpeter.im:
On 4/17/09 12:48 PM, Peter Saint-Andre wrote:
On 4/17/09 12:43 PM, Jiří Zárevúcký wrote:
2009/4/17 Leonid Evdokimov l...@darkk.net.ru:
...
So the first method works like trivial VCS and the second one works like
rsync or incremental tar. What
2009/4/17 Jiří Zárevúcký zarevucky.j...@gmail.com:
2009/4/17 Peter Saint-Andre stpe...@stpeter.im:
On 4/17/09 12:48 PM, Peter Saint-Andre wrote:
On 4/17/09 12:43 PM, Jiří Zárevúcký wrote:
2009/4/17 Leonid Evdokimov l...@darkk.net.ru:
...
So the first method works like trivial VCS
2009/4/17 Peter Saint-Andre stpe...@stpeter.im:
I think you're making it too complicated for the typical usage.
Peter
Yeah. You are probably right. These are just nuances that would affect
very little people throughout the whole existence of the protocol, but
given they don't make anything
2009/4/17 Peter Saint-Andre stpe...@stpeter.im:
Ahoj Jirka,
On 4/16/09 8:39 PM, Jiří Zárevúcký wrote:
2009/4/17 Peter Saint-Andre stpe...@stpeter.im:
I think you're making it too complicated for the typical usage.
Peter
Yeah. You are probably right. These are just nuances that would
2009/4/14 Nicolas Vérité nicolas.ver...@gmail.com:
2009/4/14 Jiří Zárevúcký zarevucky.j...@gmail.com:
2009/4/14 Nicolas Vérité nicolas.ver...@gmail.com:
In 3rd bullet point of section 4,
http://xmpp.org/extensions/xep-0224.html#rules imho, a user could well
receive a delayed 'attention
You are raising the scenario of the stream dying right after the server
sends 303. I'm saying that client 1 MUST NOT consider itself to be up to
date when it receives 303, because the server has already told it that
the latest version is 305. Therefore, when the client reconnects it MUST
Hi, I have a question about a particular scenario (it's a bit
simplified, just for illustration).
This is the initial state:
query ver=300
item jid=conta...@jabber.org subscription=none /
item jid=conta...@jabber.org subscription=none /
...
/query
Now magine you have four pushes in
Dne 13. duben 2009 19:18 Jiří Zárevúcký zarevucky.j...@gmail.com napsal(a):
Hi, I have a question about a particular scenario (it's a bit
simplified, just for illustration).
.
Ok, I probably just made an idiot from myself. I for some reason
didn't realize that the item is still send
2009/4/11 Peter Saint-Andre stpe...@stpeter.im:
My feedback is: don't waste time on this kind of project. The problems
with backwards-compatibility make it infeasible.
Peter
Yeah. I sometimes get very stupid ideas. Sorry about that. :)
2009/4/6 Peter Saint-Andre stpe...@stpeter.im:
Ah, well you sent some RGB codes. I need a way to place a vertical
stripe down the side of the page (100% of the height), which seems to be
rather difficult in CSS (although possibly it will be part of CSS3).
Peter
This should be quite easy,
2009/4/6 Peter Saint-Andre stpe...@stpeter.im:
On 4/6/09 7:28 AM, Jiří Zárevúcký wrote:
This should be quite easy, unless you want it to have a vertical text
included.
The simplest way I can think about is adding a background image. :)
I was hoping to avoid image loads for our spec files
2009/3/10 Kurt Zeilenga kurt.zeile...@isode.com:
Also, the Security Considerations should note that it might not be
appropriate for the server to disclose the IP address it associates with the
client to the client (such as when the server is behind a NAT).
I don't think this could pose any
Repeat after me: the schemas are non-normative.
As I see it, normative or not, incorrect schema is much worse then if
there was no schema at all. If schemas don't reflect the actual
specifications (and vice-versa), it would be better to remove them
completely. They just confuse.
One example:
2009/3/4 Peter Saint-Andre stpe...@stpeter.im:
On 3/3/09 9:08 PM, Jiří Zárevúcký wrote:
Repeat after me: the schemas are non-normative.
As I see it, normative or not, incorrect schema is much worse then if
there was no schema at all. If schemas don't reflect the actual
specifications
The user interface may be easily fixed by client developers... and
possibly a very short Best Practice document.
No, it can't, since behavior required for this is explicitly forbidden
by the specification. Also, implementing client's capabilities so
differently from the actual protocol makes a
I would really appreciate if someone who has actually written an
end-user client could give me some feedback. Anyone?
2009/2/25 Pavel Simerda pav...@pavlix.net:
On Wed, 25 Feb 2009 18:14:40 +0100
Jiří Zárevúcký zarevucky.j...@gmail.com wrote:
The user interface may be easily fixed by client developers... and
possibly a very short Best Practice document.
No, it can't, since behavior required
Hello all.
I've been thinking about the current subscription management in the
XMPP-IM for some time now. I think it's not very well designed.
For example, there's an obvious redundancy in the roster pushes and
subscription stanzas. For (almost) every subscription update /
request, there is a
Are there any news on this?
2009/1/23 Peter Saint-Andre stpe...@stpeter.im:
Kevin Smith wrote:
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
I'm not entirely sure, but I think that nobody is ever supposed to
send an error message to a bare JID. Errors are sent in a response to
an invalid stanza, which always originates from a resource. As for the
groupchat, I would suggest taking a look at the relevant XEP.
2009/2/11 Waqas Hussain
Yeah, it really seems to contradict a bit..
2009/2/11 Waqas Hussain waqa...@gmail.com:
On Wed, Feb 11, 2009 at 11:27 PM, Jiří Zárevúcký
zarevucky.j...@gmail.com wrote:
I'm not entirely sure, but I think that nobody is ever supposed to
send an error message to a bare JID. Errors are sent
Sorry, I didn't notice that part.
2009/2/8 Peter Saint-Andre stpe...@stpeter.im:
Jiří Zárevúcký wrote:
If you can't connect to the domain provided in the error, then it is
probably error on the Google side. Anyway, specification clearly
states the domain is to be provided as XML character
If you can't connect to the domain provided in the error, then it is
probably error on the Google side. Anyway, specification clearly
states the domain is to be provided as XML character data of the
see-other-host/ element. The code you encountered sends it in a text
child, which is obviously
2009/1/23 Pedro Melo m...@simplicidade.org:
Hi,
On Jan 22, 2009, at 9:27 PM, Jiří Zárevúcký wrote:
2009/1/22 Matthew Wild mwi...@gmail.com:
I must say I'm inclined to agree with Olivier. Perhaps we are solving
the problem from the wrong angle? Specifically, perhaps we can solve
the need
In the Mac version (Leapfrog), we implemented XEP-0209 and used it
internally (friendly customers and those brace enough to use the nightly
builds) but we rolled to the code back to the simpler version.
At the time, delays to retrieve the private storage items would cause
temporary
2009/1/23 Pedro Melo m...@simplicidade.org:
Hi,
On Jan 22, 2009, at 9:27 PM, Jiří Zárevúcký wrote:
2009/1/22 Matthew Wild mwi...@gmail.com:
I must say I'm inclined to agree with Olivier. Perhaps we are solving
the problem from the wrong angle? Specifically, perhaps we can solve
the need
2009/1/22 Olivier Goffart ogoff...@kde.org:
Why do we need to send icons URL for status? I think it will just confuse the
user if each cotact has different icons for different statuses.
I see also that as a potential security issue that can reveal user's presence
+ IP (while following the
I have 2 question about this spec:
1) Why not use user-specified handle (meta-contact name) instead of
some opaque tag?
2) How are these meta-contact data supposed to be scattered across
multiple accounts? I really didn't get this part. (clarification
needed?)
1) Why not use user-specified handle (meta-contact name) instead of
some opaque tag?
Sure, you could do that too (unlness I overlook something, It's been
some time). I'll clarify this.
The value of the 'tag' is used as a non-human readable unique
identifier for a metacontact.
I think it
2009/1/22 Yann Leboulanger aste...@lagaule.org:
each contact has its own name, there is not a name for the group of
contacts.
I don't see how it could be usefull to have a name from the metacontact
group.
I think it could be useful in some scenarios.
Example:
cont...@whatever.org - Contact
2009/1/22 Jonathan Schleifer js-xmpp-standa...@webkeks.org:
Olivier Goffart ogoff...@kde.org wrote:
What would be the need of having different name for sub-contacts
inside the same metacontact?
If someone got two XMPP accounts, you might append the server name in
brackets. Or when using
Another thing to clarify - how to handle groups? That is.. Union?
Intersection? Should client synchronize them when merging contacts?
Etc..
I think that best approach would be union and synchronizing between
all sub-contacts.
2009/1/22 Matthew Wild mwi...@gmail.com:
I must say I'm inclined to agree with Olivier. Perhaps we are solving
the problem from the wrong angle? Specifically, perhaps we can solve
the need for users to append (Home), (Work), (ICQ) and (MSN)?
I'm not going to object to this XEP, I just can't
67 matches
Mail list logo
