Re: [Standards] UPDATED: XEP-0237 (Roster Versioning)

[Jiří Zárevúcký]

Thanks. It's much better now IMO. :)

Re: [Standards] Message Archiving - xep 0136 : Sending push to all user's resources after removing a contact specific preferences from the user archiving preferences.

[Jiří Zárevúcký]

009/5/14 Sandip Nemade :
>
> When an user modifies his archiving preferences, Push has to be sent to all
> the user's resources who had requested for the archive preferences.
> The xep-0136 is not having any example of the format in which the push has
> to be sent to the user in case of the above mentioned scenario.
>
>
> Thank You.
>
>

Hi.

All the other examples imply that the format is the same as in user's
IQ set. It just goes the opposite direction and to all resources.
(Maybe it's needed to add a note that pushes always mirror client's
request?)

Re: [Standards] UPDATED: XEP-0237 (Roster Versioning)

[Jiří Zárevúcký]

2009/5/13 Dave Cridland :
>
> 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 understand.
>

Thanks, that's exactly what I meant.

> Still, as long as not *all* examples show simple integer
> sequences, I think it might benefit some examples. (Perhaps Example 3, for
> instance).
>

Yeah, I was proposing way back including one example on integer
versions and one on simple "modified/unmodified" checking with hash.
That would illustrate pure sequential roster versions well, while
still showing other possibilities are to be expected.

Re: [Standards] UPDATED: XEP-0237 (Roster Versioning)

[Jiří Zárevúcký]

2009/5/13 Leonid Evdokimov :
> 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 this.
>
> Excuse me, I really misunderstood you. My point is that development "by
> example" is evil. Examples never show general rule, that's ultimate
> limitation of any example. Developers should know that.
>

That's exactly my point. Why should programmers, who don't know that,
be defining the form examples take? I know I'm being too talkative
about it, but it wouldn't be that way if people understood what I mean
the first time.

>
> Anyway, I really doubt that content of `ver' attribute in examples
> matters that much. IMHO, any content is good enough.
>

Yes, but some is still better illustration than other, don't you agree?

Re: [Standards] UPDATED: XEP-0237 (Roster Versioning)

[Jiří Zárevúcký]

2009/5/13 Leonid Evdokimov :
> 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 change with the appropriate full roster
>> checksum again.
>
> No, there is easier way that still conforms to the XEP:
>
> if hash matches - send nothing,
> if hash does not match - send whole roster.
>
> See  Implementation Guidelines[1] for details.
>
> [1] http://xmpp.org/extensions/xep-0237.html#impl
>
>
> Version string is up to server developer - he may do anything he wants
> to. Almost. The developer should conform to following precondition:
>
> if only part of roster is sent (as set of pushes) then every push should
> be treated as separate transaction and every push should leave
> conforming client in consistent state.
>

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 this. If they are not, I don't see the point in making
such crazy examples. That's all.

Re: [Standards] UPDATED: XEP-0237 (Roster Versioning)

[Jiří Zárevúcký]

2009/5/13 Matthew Wild :
> 2009/5/13 Jiří Zárevúcký :
>> 2009/5/13 Waqas Hussain :
>>>
>>> Programmers for whom ver='qAxdnWNcA+lYf7CoN5wpBsvVVno=' would be
>>> entirely impossible... I think those exact programmers are the reason
>>> for not using ver='1' :-)
>>>
>>
>> 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 change with the appropriate full roster
>> checksum again. I'm not that much into cryptography, and it depends on
>> the kind of hashing used, but if that possible, someone implementing
>> this would at least be completely out of his/her mind.
>>
>
> There is no "decoding" a hash. It is used to give each version of the
> roster an "automatic" version number if you like. In almost all
> respects it is otherwise the same as incremental numeric versions.
>
>>> The XEP is short and clear. The 'ver' attribute is an opaque string
>>> for clients, and client programmers shouldn't care what it's value is.
>>> I don't see a problem here.
>>>
>>
>> XEP is short and clear and nobody will ever have any problem reading
>> it. Examples are way more confusing because of some theoretical idiot
>> that's implementing example and not the XEP. Do we really want to make
>> obscure examples because of people that are probably incapable of
>> implementing it at all?
>>
>
> Obscure? And so what if they implement the examples and not the text
> of the XEP? The examples are valid too you know :)
>

But that's exactly what those examples try to prevent in a very
questionable way, isn't it?

> I for one don't think that this particular issue warrants further
> discussion. The XEP is absolutely fine as-is.
>
> Matthew
>

Ok, I give up. But let me explain it's not so much about the examples
being worse to read and understand (which they are). It's about taking
some ethereal idiot programmers into account when designing specs.
Next time we will binary encode them so someone doesn't try a human
language parser on the protocol. :)

Re: [Standards] UPDATED: XEP-0237 (Roster Versioning)

[Jiří Zárevúcký]

2009/5/13 Waqas Hussain :
> 2009/5/13 Jiří Zárevúcký :
>> 2009/5/12 Peter Saint-Andre :
>>> -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 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 original value), the server SHOULD NOT 
>>>>> consider the
>>>>> item to have been modified for purposes of roster versioning and 
>>>>> therefore SHOULD NOT
>>>>> push the item to the client in an interim roster push.
>>>>
>>>> That part is not very useful, since servers will hardly keep track of
>>>> every previous roster version. I don't even want to think about the
>>>> CPU overhead that will kill the cluster every 30 minutes (that's a
>>>> hyperbole of course). > The simplest "full featured" implementation
>>>> consists of integer version numbers and "mver" field for every roster
>>>> item.
>>>
>>> This is purely an implementation decision and I think we need to remove
>>> the conformance language here (i.e., no MUST, SHOULD, SHOULD NOT, MAY).
>>> If the server chooses the "hash complete roster" approach then it won't
>>> send the push. If the server chooses the "integer version numbers"
>>> approach then it will send the push. End of story.
>>>
>>>> Server will then send all the items whose mver is greater than
>>>> client's ver. Any throughout checking would hardly ever have any
>>>> benefit.
>>>
>>> What is mver?
>>>
>>
>> The same relation as with time and mtime on files. It's the version of
>> last change.
>>
>>>> -
>>>>
>>>> About the opaque vs. integer examples dilemma. I think if someone
>>>> really doesn't read the text, his implementation won't work at all
>>>> anyway. The examples are kinda confusing this way. If you really want
>>>> some opaque strings there, use "A", "B", "C" or something
>>>> like that, so the sequentiality is obvious.
>>>
>>> A sequence number is not really opaque, is it? The examples currently
>>> use the "hash complete roster" approach. I would prefer to err on the
>>> side of not misleading clients about sequentiality ("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).
>>>
>>> Peter
>>>
>>
>> Ok, so in order to not confuse stupid programmers with a specific
>> implementation, we will confuse them with one entirely impossible. I
>> get your thinking *THUMBS UP*
>>
>
> Programmers for whom ver='qAxdnWNcA+lYf7CoN5wpBsvVVno=' would be
> entirely impossible... I think those exact programmers are the reason
> for not using ver='1' :-)
>

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 change with the appropriate full roster
checksum again. I'm not that much into cryptography, and it depends on
the kind of hashing used, but if that possible, someone implementing
this would at least be completely out of his/her mind.

> The XEP is short and clear. The 'ver' attribute is an opaque string
> for clients, and client programmers shouldn't care what it's value is.
> I don't see a problem here.
>

XEP is short and clear and nobody will ever have any problem reading
it. Examples are way more confusing because of some theoretical idiot
that's implementing example and not the XEP. Do we really want to make
obscure examples because of people that are probably incapable of
implementing it at all?

Re: [Standards] UPDATED: XEP-0237 (Roster Versioning)

[Jiří Zárevúcký]

>> ("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 following example? who would use his work?).
So every such stupid client programmer would figure the catch on the
first try.

(sorry about two separate messages)

Re: [Standards] UPDATED: XEP-0237 (Roster Versioning)

[Jiří Zárevúcký]

2009/5/12 Peter Saint-Andre :
> -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 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 original value), the server SHOULD NOT 
>>> consider the
>>> item to have been modified for purposes of roster versioning and therefore 
>>> SHOULD NOT
>>> push the item to the client in an interim roster push.
>>
>> That part is not very useful, since servers will hardly keep track of
>> every previous roster version. I don't even want to think about the
>> CPU overhead that will kill the cluster every 30 minutes (that's a
>> hyperbole of course). > The simplest "full featured" implementation
>> consists of integer version numbers and "mver" field for every roster
>> item.
>
> This is purely an implementation decision and I think we need to remove
> the conformance language here (i.e., no MUST, SHOULD, SHOULD NOT, MAY).
> If the server chooses the "hash complete roster" approach then it won't
> send the push. If the server chooses the "integer version numbers"
> approach then it will send the push. End of story.
>
>> Server will then send all the items whose mver is greater than
>> client's ver. Any throughout checking would hardly ever have any
>> benefit.
>
> What is mver?
>

The same relation as with time and mtime on files. It's the version of
last change.

>> -
>>
>> About the opaque vs. integer examples dilemma. I think if someone
>> really doesn't read the text, his implementation won't work at all
>> anyway. The examples are kinda confusing this way. If you really want
>> some opaque strings there, use "A", "B", "C" or something
>> like that, so the sequentiality is obvious.
>
> A sequence number is not really opaque, is it? The examples currently
> use the "hash complete roster" approach. I would prefer to err on the
> side of not misleading clients about sequentiality ("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).
>
> Peter
>

Ok, so in order to not confuse stupid programmers with a specific
implementation, we will confuse them with one entirely impossible. I
get your thinking *THUMBS UP*

Re: [Standards] Privacy lists and the order of items

[Jiří Zárevúcký]

2009/5/12 Remko Tronçon :
> On Mon, May 11, 2009 at 5:51 PM, Dave Cridland  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 list, we have a C14N problem.
>
> Well, semantical equivalence  should be checked at the XML level, not
> at the XMPP level. Wouldn't you otherwise have problems with plain
> messages as well, since
> ab is equivalent to
> ba in XMPP (but not
> in XML).
>
> cheers,
> Remko
>

That's another problem. As Peter pointed out to me earlier, no XMPP
spec ever enforced a particular child order (if the order wouldn't
make a semantic difference in XMPP). If it comes to signing, we can
specify that unordered elements are to be ordered by some algorithm.

Re: [Standards] UPDATED: XEP-0237 (Roster Versioning)

[Jiří Zárevúcký]

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 original value), the server SHOULD NOT 
> consider the
> item to have been modified for purposes of roster versioning and therefore 
> SHOULD NOT
> push the item to the client in an interim roster push.

That part is not very useful, since servers will hardly keep track of
every previous roster version. I don't even want to think about the
CPU overhead that will kill the cluster every 30 minutes (that's a
hyperbole of course). The simplest "full featured" implementation
consists of integer version numbers and "mver" field for every roster
item. Server will then send all the items whose mver is greater than
client's ver. Any throughout checking would hardly ever have any
benefit.

-

About the opaque vs. integer examples dilemma. I think if someone
really doesn't read the text, his implementation won't work at all
anyway. The examples are kinda confusing this way. If you really want
some opaque strings there, use "A", "B", "C" or something
like that, so the sequentiality is obvious.

Re: [Standards] IBB filetransfer implementations?

[Jiří Zárevúcký]

2009/4/29 Will Thompson :
> 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 is Tkabber's unannounced use of messages instead of IQ's
>> and I'm really tired of devising workarounds for crappy
>> implementations... I just want to test and debug my implementation
>> with something working. Is there any?
>
> telepathy-gabble does IBB as the final fallback if it can't do SOCKS5
> with or without a relay.
>

Hmm... Empathy can't connect at all and there is no debug output
whatsoever... any other ideas?

[Standards] IBB filetransfer implementations?

[Jiří Zárevúcký]

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 devising workarounds for crappy
implementations... I just want to test and debug my implementation
with something working. Is there any?

Re: [Standards] UPDATED: XEP-0237 (Roster Versioning)

[Jiří Zárevúcký]

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 one of previous threads.

In addition, this passage doesn't make any sense after the change:

> In addition, if the client signals a version ID that is different from the 
> version currently on file at the server for that JID, the server MUST return 
> the whole current roster as if client announced its version to be the empty 
> string, thus bootstrapping the client's local cache.

If the server uses incremental numbering and client returns a lesser
ver, it will always bootstrap, never sending incremental pushes. Maybe
it need rephrasing to something like "if server can't associate the
request to any previous version".

Also, I think the examples should still have the sequence numbers
(which is I believe preferred implementation). Use of hashes can be
noted in implementation notes.

Oh... and a typo:

> During that time, the client might have received roster pushes related to 
> *varous* roster versions.



Regards, George

[Standards] Unclarified behavior in XEP-0047 (in-band bytestreams)

[Jiří Zárevúcký]

"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 number to have been used until the data
packet has been successfully processed)."

The sender must either resend data or explicitly close the stream by
sending the "close" query. Otherwise the recipient doesn't know
whether the sender wants to resend or not. Right?

What confuses me it that in the case of invalid sequence number, the
one responsible for closing of the stream is the receiver:

"The recipient MUST NOT process the data of such an out-of-sequence
packet, nor any that follow it within the same bytestream; instead,
the recipient MUST consider the bytestream invalid and SHOULD close
the bytestream as described in the next section."

But that's also "SHOULD", not "MUST"... what happens if the recipient
doesn't close it?


Can this part be clarified and made sure that stream invalidation is
in all cases obvious to both entities? Thanks :)

Re: [Standards] XEP-0816 (Invisible Command) mandates ridiculous UI

[Jiří Zárevúcký]

2009/4/25 Will Thompson :
>
> 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 I think it goes too far.
>
>

The XEP says that based on configuration, client can auto-populate
communication list with trusted entities. You can (for the purposes of
end-user implementation) say that everyone in your roster, who you
explicitly start communicating with, is a trusted entity and as such
can be automatically (without prompting) added to the white-list, if
your configuration allows it.

Or am I understanding something incorrectly?

Re: [Standards] XEP-0816 (Invisible Command) mandates ridiculous UI

[Jiří Zárevúcký]

2009/4/25 Paul Aurich :
>
> 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 question. User can explicitly
generate traffic without him knowing. You generate traffic by opening
a window. You generate it by displaying your contact's information.
You can even generate it by hovering mouse over your contact in
roster. Ordinary users don't understand the technology and should be
warned. I still think it is implementation and configuration issue.
The "don't ask again" checkbox is really a no-brainer.

Re: [Standards] XEP-0237: version == sequence number?

[Jiří Zárevúcký]

2009/4/24 Christoph Terwelp :
>
> Am 24.04.2009 um 14:10 schrieb Matthew Wild:
>
>> On Fri, Apr 24, 2009 at 1:02 PM, Christoph Terwelp  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 was used to
>>> generate the hash. So the client can check the current roster. This way
>>> corrupted rosters can be detected and no user interaction is required.
>>>
>>
>> I'd rather keep it opaque to the client. Rosters shouldn't get
>> corrupted during transfer, that's what TCP is for :)
>
> I don't suggest they could get corrupted during transfer, but because of a
> client malfunction or a system crash.
>


I think you are complicating things way too much. If the client's
cache gets corrupted, it probably isn't loadable anyway.

I would let the ver be opaque for client. The implementation notes
would then simply explain the ideas behind minimal implementation with
hashes and more sophisticated implementation with integer numbers.

Re: [Standards] XEP-0816 (Invisible Command) mandates ridiculous UI

[Jiří Zárevúcký]

2009/4/23 Will Thompson :
> 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 
>> allowed, and prompt the user before adding any entity to that "communicants 
>> list" for this invisibility session; the list MAY be auto-populated with 
>> trusted entities if so configured by the user.
>
>>     * MUST prompt the user before sending any outbound traffic (message, 
>> presence, or IQ stanza) to a contact even if the user generated such 
>> traffic; upon receiving authorization from the user, the client SHOULD add 
>> the authorized entity to the communicants list for this invisibility session.
>
> This UI seems ridiculous to me: if my client did this, it would really
> annoy me. If I'm invisible but want to message a contact, that's my
> choice. My client shouldn't get in the way (unless I want it to, which I
> don't). Unfortunately, per the XEP a client that behaves how I want
> rather than as above is buggy.
>
> Perhaps this section could be removed, or rephrased as one possible UI?
> XEPs mandating particular UI behaviour seems like a bad idea in general,
> especially when the mandated behaviour is undesirable. :)
>
> Regards,
> --
> Will
>
>

I don't think it's ridiculous. I guards against accidental leaking of presence.
You can leak for example by requesting users client's version or
service discovery information. I can imagine very little ordinary
users realize it.

You can still add some sort of checkbox saying "Don't ask again".
That's not against the rules IMO, as this way the user configures the
client to autopopulate trusted list with any contacts he interacts
with. It's all just implementation details.

Re: [Standards] LAST CALL: XEP-0256 (Last Activity in Presence)

[Jiří Zárevúcký]

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 ;)

Re: [Standards] LAST CALL: XEP-0256 (Last Activity in Presence)

[Jiří Zárevúcký]

Seems fine, but it looks to me more like a best practice then a
standards track protocol... :)

Re: [Standards] UPDATED: XEP-0237 (Roster Versioning)

[Jiří Zárevúcký]

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 IQ-result (thus indicating that
> any roster modifications will be sent via roster pushes, as described
> below). In general, unless returning the complete roster would use less
> bandwidth than sending individual roster pushes to the client (e.g., if
> the roster contains only a few items), the server SHOULD send an empty
> IQ-result and then send the modifications (if any) via roster pushes. In
> addition, if the client signals a sequence number that is greater than
> the sequence number currently on file at the server for that JID, the
> server MUST return the whole current roster as if client announced its
> version to be zero, thus bootstrapping the client's local cache.
>
> ***
>
> Peter
>

I like it. Thanks :)

Re: [Standards] UPDATED: XEP-0237 (Roster Versioning)

[Jiří Zárevúcký]

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 the sysadmin. I see this
> problem as quite rare. Perhaps we don't need to solve it in our protocol
> and instead deal with it at the human layer. Not everything needs a
> technical solution.
>

Yeah, you are right. 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.

Re: [Standards] UPDATED: XEP-0237 (Roster Versioning)

[Jiří Zárevúcký]

2009/4/22 Peter Saint-Andre :
>>
>> 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 think it is up to the server to return the complete roster in this case.
>

There would be no difference from an ordinary request. In this case
the server has no way of knowing that the client's cache differs from
the real current state.

>
>> Is such scenario worth attention? I don't know how often could
>> something like that happen. The only way to fix it (I can think of)
>> would be including some identifier of roster (another number?) that
>> server would have to reset in case of any failure/reverting. The
>> client would then send requests based on both roster's ID and sequence
>> number. But I don't like the idea much.
>
> Yeah, I don't like that, either. Perhaps the solution is to use a better
> server. :)
>

Well... that's probably truth :) But I don't think something like
fail-proof server really exists... I'll need to think about it
further.

Re: [Standards] UPDATED: XEP-0237 (Roster Versioning)

[Jiří Zárevúcký]

2009/4/21 Peter Saint-Andre :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 4/21/09 12:57 PM, Jiří Zárevúcký wrote:
>> 2009/4/21 Peter Saint-Andre :
>>> 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 problem
>>>   SHOULD return a roster version of zero (in the case of the server) or
>>>   request a roster version of zero (in the case of the client).
>>>
>>> Peter
>>>
>>
>> That doesn't seem very clear to me. And what if the roster was already
>> modified with another client? I think that better formulation would be
>> something like:
>>
>>    If client announces it's version number to be bigger than the
>> version of currently server-side stored roster (for example because a
>> catastrophic server failure erased all roster information), the server
>> MUST return the whole current roster as if client announced it's
>> version to be zero, thus bootstrapping client's local cache.
>
> Something like that is good for the case when the client sends a roster
> request with a version number greater than what the server has on hand.

That's the general idea.

> But are there other cases of corrupted / invalid sequence numbering on
> server side? Or do we say that in such cases the server needs to in
> essence reset its sequence number back to zero?
>

I the server's database gets corrupted or lost, it doesn't know the
correct roster for that sequence number anyway, so it is pretty
implicit to revert it to the last known uncorrupted version (if any
exists.. backup for example? does not necessarily need to be zero).
But it doesn't hurt to make it explicit, too.


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.

Is such scenario worth attention? I don't know how often could
something like that happen. The only way to fix it (I can think of)
would be including some identifier of roster (another number?) that
server would have to reset in case of any failure/reverting. The
client would then send requests based on both roster's ID and sequence
number. But I don't like the idea much.

Re: [Standards] UPDATED: XEP-0237 (Roster Versioning)

[Jiří Zárevúcký]

2009/4/21 Peter Saint-Andre :
> 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 problem
>   SHOULD return a roster version of zero (in the case of the server) or
>   request a roster version of zero (in the case of the client).
>
> Peter
>

That doesn't seem very clear to me. And what if the roster was already
modified with another client? I think that better formulation would be
something like:

   If client announces it's version number to be bigger than the
version of currently server-side stored roster (for example because a
catastrophic server failure erased all roster information), the server
MUST return the whole current roster as if client announced it's
version to be zero, thus bootstrapping client's local cache.

The local corrupted cache scenario is already in the spec (under
request example). No need to include it again.

Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]

[Jiří Zárevúcký]

2009/4/17 Jiří Zárevúcký :
> 2009/4/17 Peter Saint-Andre :
>> 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 :
>>>>> ...
>>>>>
>>>>> 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 idea of this thread is to say what should XEP actually
>>>> describe, right? ;) Can you please comment my example? I'd like to
>>>> know what you think.
>>>
>>> I *think* we have consensus, but I'm still pondering it. I will update
>>> the spec accordingly to make sure that I understand it.
>>
>> Before I get too far in the spec updates, here is an example.
>>
>> Client thinks version is 299. Server thinks it is 309. To simplify,
>> consider every odd version number to be significant (the server will be
>> pushing 301, 303, 305, 307, 309). So:
>>
>> C: IQ-get [299]
>> S: IQ-result
>> S: push [301]
>> S: push [303]
>> S: push [305]
>> 
>> C: IQ-get [305]
>> S: push [307]
>> S: push [309]
>>
>> Yes?
>>
>
> That's right.
>

But you forget the second IQ-result. :)

Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]

[Jiří Zárevúcký]

2009/4/17 Peter Saint-Andre :
> 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 :
>>>> ...
>>>>
>>>> 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 idea of this thread is to say what should XEP actually
>>> describe, right? ;) Can you please comment my example? I'd like to
>>> know what you think.
>>
>> I *think* we have consensus, but I'm still pondering it. I will update
>> the spec accordingly to make sure that I understand it.
>
> Before I get too far in the spec updates, here is an example.
>
> Client thinks version is 299. Server thinks it is 309. To simplify,
> consider every odd version number to be significant (the server will be
> pushing 301, 303, 305, 307, 309). So:
>
> C: IQ-get [299]
> S: IQ-result
> S: push [301]
> S: push [303]
> S: push [305]
> 
> C: IQ-get [305]
> S: push [307]
> S: push [309]
>
> Yes?
>

That's right.

Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]

[Jiří Zárevúcký]

2009/4/17 Leonid Evdokimov :
> ...
>
> 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 idea of this thread is to say what should XEP actually
describe, right? ;) Can you please comment my example? I'd like to
know what you think.

Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]

[Jiří Zárevúcký]

2009/4/17 Peter Saint-Andre :
> On 4/17/09 11:59 AM, Jiří Zárevúcký wrote:
>> 2009/4/17 Peter Saint-Andre :
>>> On 4/17/09 11:55 AM, Jiří Zárevúcký wrote:
>>>> 2009/4/17 Peter Saint-Andre :
>>>>> On 4/17/09 11:51 AM, Jiří Zárevúcký wrote:
>>>>>> 2009/4/17 Peter Saint-Andre :
>>>>>>> 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
>>>>>>>>>> MUST NOT process any of the interim roster pushes until...". I think
>>>>>>>>>> you can safely remove it again, as the reason for the change was
>>>>>>>>>> proven invalid.
>>>>>>>>> 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 "transaction" of pushes.
>>>>>>>> That seems right to me. I think we just need to change "process" to
>>>>>>>> something else (you can process the push, but don't think that you are
>>>>>>>> up to date until you receive the last one).
>>>>>>> How is this text?
>>>>>>>
>>>>>>> "The client can determine when the interim roster pushes have ended by
>>>>>>> comparing the version number it received on the empty  element
>>>>>>> against the version number it receives in roster pushes. The client MUST
>>>>>>> process the interim roster pushes as it would process any normal roster
>>>>>>> push and MAY cache those items in case it loses its connection to the
>>>>>>> server during the update process, but MUST NOT increment its internal
>>>>>>> roster version until it receives the full set of pushes."
>>>>>>>
>>>>>> Waitaminit... Didn't we agree that treating interim pushes the same
>>>>>> way as normal ones is the best approach? Otherwise we yet need to
>>>>>> solve the empty roster case somehow.
>>>>> Processing them means you handle them as normal. Just don't think that
>>>>> you are completely up to date until you receive the last one.
>>>>>
>>>> Ok... now I definitely don't follow... processing them as normal also
>>>> means you won't know what the last one it... and we agreed (at least
>>>> with Dave) we don't need to know that anyway...
>>> For the purposes of Roster Versioning, you MUST NOT think that you are
>>> up to date if you've received only some of the roster pushes. What is
>>> not clear about that?
>>>
>>
>> That it contradicts the "treat as normal" statement. Client is always
>> as up-to-date as the version number of the last push it processed.
>> There is no up-to-date state. There is just client's roster version.
>
> You treat the roster push itself as normal -- update your local version
> of the roster, update your local presence database if appropriate,
> change the cute little icon in the GUI that shows the subscription
> state, and whatever all else you care about. But because you are a
> client that knows about roster versioning, you don't yet modify the
> internal counter that keeps track of which roster version is the most
> recent -- so in our example you still think that you have version 299,
> not 307 or whatever the numbers are. If you then get disconnected before
> you receive the roster push that matches the last version number that
> the server communicated to you, you request the version number that you
> have in your local counter (e.g., 299). Once you receive 307, you change
> the counter from 299 to 307.
>
> What is unclear?
>
> /psa
>
>

We definitely got out of sync. Such holding back of version isn't
needed and is impossible if we are to use the way Dave proposed and I
agreed with.

Now to be completely clear, a little use case: (based on the current spec)

However, if returning the complete roster would use more bandwidth
than sending individual roster pushes to the client (e.g., if the
roster contains many items, only a few of which have changed), the
server SHOULD return an empty IQ result, then send individual roster
pushes.

Example 4. Roster result with no content




Example 5. Server sends any changes since the clients state as ordinary pushes


  

  



  

  



The client can't figure out which push is the last change, but that
doesn't matter, since all pushes are atomic.

To rule out several possible corner cases, server MUST always send
pushes for every changed item, even if there were several changes that
in fact reverted itself. That means the server MUST NOT send a simple
difference, but instead MUST send all the items that were modified at
any point in history.


-

Now we are hopefully resynced and can talk about the same problem again.

Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]

[Jiří Zárevúcký]

2009/4/17 Peter Saint-Andre :
> On 4/17/09 11:55 AM, Jiří Zárevúcký wrote:
>> 2009/4/17 Peter Saint-Andre :
>>> On 4/17/09 11:51 AM, Jiří Zárevúcký wrote:
>>>> 2009/4/17 Peter Saint-Andre :
>>>>> 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
>>>>>>>> MUST NOT process any of the interim roster pushes until...". I think
>>>>>>>> you can safely remove it again, as the reason for the change was
>>>>>>>> proven invalid.
>>>>>>> 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 "transaction" of pushes.
>>>>>> That seems right to me. I think we just need to change "process" to
>>>>>> something else (you can process the push, but don't think that you are
>>>>>> up to date until you receive the last one).
>>>>> How is this text?
>>>>>
>>>>> "The client can determine when the interim roster pushes have ended by
>>>>> comparing the version number it received on the empty  element
>>>>> against the version number it receives in roster pushes. The client MUST
>>>>> process the interim roster pushes as it would process any normal roster
>>>>> push and MAY cache those items in case it loses its connection to the
>>>>> server during the update process, but MUST NOT increment its internal
>>>>> roster version until it receives the full set of pushes."
>>>>>
>>>> Waitaminit... Didn't we agree that treating interim pushes the same
>>>> way as normal ones is the best approach? Otherwise we yet need to
>>>> solve the empty roster case somehow.
>>> Processing them means you handle them as normal. Just don't think that
>>> you are completely up to date until you receive the last one.
>>>
>>
>> Ok... now I definitely don't follow... processing them as normal also
>> means you won't know what the last one it... and we agreed (at least
>> with Dave) we don't need to know that anyway...
>
> For the purposes of Roster Versioning, you MUST NOT think that you are
> up to date if you've received only some of the roster pushes. What is
> not clear about that?
>

That it contradicts the "treat as normal" statement. Client is always
as up-to-date as the version number of the last push it processed.
There is no up-to-date state. There is just client's roster version.

Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]

[Jiří Zárevúcký]

2009/4/17 Peter Saint-Andre :
> On 4/17/09 11:51 AM, Jiří Zárevúcký wrote:
>> 2009/4/17 Peter Saint-Andre :
>>> 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
>>>>>> MUST NOT process any of the interim roster pushes until...". I think
>>>>>> you can safely remove it again, as the reason for the change was
>>>>>> proven invalid.
>>>>> 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 "transaction" of pushes.
>>>> That seems right to me. I think we just need to change "process" to
>>>> something else (you can process the push, but don't think that you are
>>>> up to date until you receive the last one).
>>> How is this text?
>>>
>>> "The client can determine when the interim roster pushes have ended by
>>> comparing the version number it received on the empty  element
>>> against the version number it receives in roster pushes. The client MUST
>>> process the interim roster pushes as it would process any normal roster
>>> push and MAY cache those items in case it loses its connection to the
>>> server during the update process, but MUST NOT increment its internal
>>> roster version until it receives the full set of pushes."
>>>
>>
>> Waitaminit... Didn't we agree that treating interim pushes the same
>> way as normal ones is the best approach? Otherwise we yet need to
>> solve the empty roster case somehow.
>
> Processing them means you handle them as normal. Just don't think that
> you are completely up to date until you receive the last one.
>

Ok... now I definitely don't follow... processing them as normal also
means you won't know what the last one it... and we agreed (at least
with Dave) we don't need to know that anyway...

Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]

[Jiří Zárevúcký]

2009/4/17 Peter Saint-Andre :
> 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
>>>> MUST NOT process any of the interim roster pushes until...". I think
>>>> you can safely remove it again, as the reason for the change was
>>>> proven invalid.
>>> 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 "transaction" of pushes.
>>
>> That seems right to me. I think we just need to change "process" to
>> something else (you can process the push, but don't think that you are
>> up to date until you receive the last one).
>
> How is this text?
>
> "The client can determine when the interim roster pushes have ended by
> comparing the version number it received on the empty  element
> against the version number it receives in roster pushes. The client MUST
> process the interim roster pushes as it would process any normal roster
> push and MAY cache those items in case it loses its connection to the
> server during the update process, but MUST NOT increment its internal
> roster version until it receives the full set of pushes."
>

Waitaminit... Didn't we agree that treating interim pushes the same
way as normal ones is the best approach? Otherwise we yet need to
solve the empty roster case somehow.

Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]

[Jiří Zárevúcký]

2009/4/17 Leonid Evdokimov :
> 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 "transaction" of pushes.
>>
>> We decided that each roster push was in and of itself atomic, so the
>> "transaction" you're referring to doesn't exist - each roster push can
>> be effectively treated as an atomic commit point in and of itself.
>
> I still think it exists, let me explain my point of view more precisely.
>
> Here is set of versions:
>
>  
>    
>  
>
>  
>    
>  
>
>  
>    
>  
>
>  
>    
>  
>
> Client knowns 305, current version is 308. The server will send 307, 308
> and the notification that the latest version is 308.
>
> Let's assume that connection was broken and client got 307 but not 308,
>  client does not know version 307 at the moment, as it *does* *not* know
> that bill@ has subscription="to". That's why I name the set of stanzas a
> "transaction" and that's why I'm against of processing interim roster
> pushes until client has received all pushes.
>

That's what I was talking about earlier, isn't it?

>
> XEP-0237 does not state that server should send "final state of all
> touched roster items", it should send "the final result of all changes
> applied" and the result may be understood as the difference.
>
> Am I mistaken somewhere?
>

No, that's also the reason for the ultra-rare corner case I posted earlier.

Changing the definition to "final state of all touched roster items"
as you suggest will solve every possible problem and allow us to treat
interim pushes as normal ones.

Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]

[Jiří Zárevúcký]

2009/4/17 Peter Saint-Andre :
>
> 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, I may send you some
>> pushes", by returning an empty result
>
> That seems better.
>

That's quite the same except for the order of sending. It's better in
case we treat interim pushes exactly the same as normal ones.

Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]

[Jiří Zárevúcký]

2009/4/17 Dave Cridland :
> On Fri Apr 17 16:05:06 2009, Jiří Zárevúcký wrote:
>>
>> 2009/4/17 Dave Cridland :
>> > On Fri Apr 17 15:06:36 2009, Jiří Zárevúcký wrote:
>> >>
>> >> 2009/4/17 Peter Saint-Andre :
>> >> >
>> >> > 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 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 it again, as the reason for the change was
>> >> proven invalid.
>> >
>> > While you're looking at this, what's your opinion on the empty roster
>> > case?
>> > (That is, when a roster becomes empty).
>> >
>> > It's an odd edge case, but I'm not sure the protocol handles this
>> > usefully.
>> >
>>
>> That's really tricky. And surely can't stay that way, since client
>> wouldn't know, how to interpret it in some cases.
>>
>> I think it could be solved by sending interim pushes _first_, then an
>> empty IQ result to mark interim pushes were all sent.
>> What do you think?
>
> Or we could respond with "What you have is okay, I may send you some
> pushes", by returning an empty result - we've established there's no need to
> treat these pushes any differently to normal ones, after all.
>
> This then means that an empty roster is different to an empty result, and
> means fewer octets for the optimal case.
>

I completely agree. I think that knowing, how many versions are to be
expected on startup, doesn't matter for any implementation.

Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]

[Jiří Zárevúcký]

2009/4/17 Dave Cridland :
> On Fri Apr 17 15:06:36 2009, Jiří Zárevúcký wrote:
>>
>> 2009/4/17 Peter Saint-Andre :
>> >
>> > 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 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 it again, as the reason for the change was
>> proven invalid.
>
> While you're looking at this, what's your opinion on the empty roster case?
> (That is, when a roster becomes empty).
>
> It's an odd edge case, but I'm not sure the protocol handles this usefully.
>

That's really tricky. And surely can't stay that way, since client
wouldn't know, how to interpret it in some cases.

I think it could be solved by sending interim pushes _first_, then an
empty IQ result to mark interim pushes were all sent.
What do you think?

Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]

[Jiří Zárevúcký]

2009/4/17 Jiří Zárevúcký :
> 2009/4/17 Leonid Evdokimov :
>> 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 it again, as the reason for the change was
>>> proven invalid.
>>
>> 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 "transaction" of pushes.
>>
>
> Ok, that seems like a retelling of the restriction. What is the reason
> for it? The reason I posted was invalid. Do you know of some other way
> it could negatively affect the retrieval?
>

I think you misunderstood the sentence. It forbids any processing at
all until the full transaction is finished. You can't cache anything.

Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]

[Jiří Zárevúcký]

2009/4/17 Leonid Evdokimov :
> 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 it again, as the reason for the change was
>> proven invalid.
>
> 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 "transaction" of pushes.
>

Ok, that seems like a retelling of the restriction. What is the reason
for it? The reason I posted was invalid. Do you know of some other way
it could negatively affect the retrieval?

Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]

[Jiří Zárevúcký]

2009/4/17 Peter Saint-Andre :
>
> 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 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 it again, as the reason for the change was
proven invalid.

Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]

[Jiří Zárevúcký]

2009/4/17 Peter Saint-Andre :
> Ahoj Jirka,
>
> On 4/16/09 8:39 PM, Jiří Zárevúcký wrote:
>> 2009/4/17 Peter Saint-Andre :
>>> 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 more complex or introduce any
>> inconveniences for anyone, I think they are worth doing. For all we
>> know, someone's aggravation over few second longer delay when loading
>> roster can ultimately lead to World War III... :-D
>
> I think that the things you are describing fall into the category of
> optimizations that a smart client can implement to improve the user
> experience. But we don't need to describe all that in the spec ("in the
> unlikely event that you get disconnected after receiving some but not
> all of the roster pushes, cache what you've received so far but then
> when you reconnect you can shave a few seconds off the reconnection
> process by requesting the roster based on the version of the last roster
> push you cached, not the last full roster update"). That kind of thing
> is great but IMHO it doesn't really belong in an RFC.
>

Actually, I described an error scenario that could occur (but probably
never would, and even if it did, nobody would likely notice) when both
client and server utilize a specific optimization. :)  which is
probably making half of this thread a truly regrettable waste of your
time... sorry about that... :)

Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]

[Jiří Zárevúcký]

2009/4/17 Peter Saint-Andre :
> 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 more complex or introduce any
inconveniences for anyone, I think they are worth doing. For all we
know, someone's aggravation over few second longer delay when loading
roster can ultimately lead to World War III... :-D

Re: [Standards] [Fwd: Re: LAST CALL: XEP-0237 (Roster Versioning)]

[Jiří Zárevúcký]

>
> 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
> behave as if it never received the roster push for version 303 and
> instead send the exact same roster get it sent when it came back online
>  (i.e., 299).
>

Client does not consider itself up-to-date but it would retrieve a
complete state if it starts retrieving again from that particular
point. So it could save the interim pushes as they arrive (if we
disregard the last change to the spec, which was based on wrong
assumptions).
That could make a huge difference if the client is on very low
bandwidth, or expensive connection based on transfered data (which for
example GPRS on mobile phones).

Re: [Standards] XEP-0224 Attention

[Jiří Zárevúcký]

2009/4/14 Nicolas Vérité :
> 2009/4/14 Jiří Zárevúcký :
>> 2009/4/14 Nicolas Vérité :
>>> In 3rd bullet point of section 4,
>>> http://xmpp.org/extensions/xep-0224.html#rules imho, a user could well
>>> receive a delayed 'attention', though I propose the change from MUST
>>> to SHOULD.
>>
>> That's nonsense. When user receives your delayed attention request,
>> you could very well be in work, school, with girlfriend, etc by then.
>> Attention is a way to get him to talk to you immediately.
>
> 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 attention.
>

You won't generally try an "attention" to someone you haven't send
several classic messages already and didn't get response... That would
be considered rude and maybe even spamming.

Re: [Standards] XEP-0224 Attention

[Jiří Zárevúcký]

2009/4/14 Nicolas Vérité :
> Hi,
>
> Small typo in http://xmpp.org/extensions/xep-0224.html#intro
> s/Notificaitons/Notifications/
>
> In 3rd bullet point of section 4,
> http://xmpp.org/extensions/xep-0224.html#rules imho, a user could well
> receive a delayed 'attention', though I propose the change from MUST
> to SHOULD.
>

That's nonsense. When user receives your delayed attention request,
you could very well be in work, school, with girlfriend, etc by then.
Attention is a way to get him to talk to you immediately.

> In 5th bullet point, I propose a change to
> "The attention extension MUST NOT use  stanzas, since use this
> feature is part of the conversation."
>

No objections against that. There's a typo though, "since use *of*
this feature" (it's in the original text, too).

Re: [Standards] LAST CALL: XEP-0237 (Roster Versioning)

[Jiří Zárevúcký]

Dne 14. duben 2009 11:06 Jiří Zárevúcký  napsal(a):
> If I'm mistaken in this and one of the attributes can be left out to
> signify "don't change it", it has to be made explicit in the spec
> anyway, as normally leaving out name means "remove".
>

No, I can't be mistaken since that behavior is relevant to updates
client generate (which is already defined in XMPP-IM)...

Re: [Standards] LAST CALL: XEP-0237 (Roster Versioning)

[Jiří Zárevúcký]

2009/4/14 Dave Cridland :
>
> I shouldn't reply to these things so late at night.
>

I shouldn't write them so late at night in the first place... :)

>
> I'm not sure they replace, as such - collapse might be a better word.
>
> Changing both subscription state, and, later, changing name, results in a
> single roster push containing both changes. However, changing name twice
> will effectively replace.
>

You can't do that. See:


  



  



  


Now there is no name, as the last push erased it.
If I'm mistaken in this and one of the attributes can be left out to
signify "don't change it", it has to be made explicit in the spec
anyway, as normally leaving out name means "remove".

---

But I realized there is a rare scenario where it could really cause problem.


  



  



  



  



  



  


Client knows 300. The roster would send 303 first, and 305 second. If
connection failed after sending 303, client would next request 303+,
but never received 302 in the first place.
Now (only) in case the server checks the last state client should
know, it will find out it doesn't need to send the push since there is
the same state as in 302. Client wouldn't receive bob's name until
next change.

That is easily fixed by disallowing servers such checks.

Re: [Standards] LAST CALL: XEP-0237 (Roster Versioning)

[Jiří Zárevúcký]

2009/4/14 Dave Cridland :
> On Mon Apr 13 18:18:39 2009, Jiří Zárevúcký wrote:
>>
>> Am I right?
>
> Yes, you are, well spotted.
>

Actually, I'm not. My reasoning would require that the items
themselves are partial, which they are not. So the push includes the
complete last known state of the item, not a change.

That means there is no such problem, as even though the client is not
guaranteed to have a complete state on failure, it will have it when
it resumes receiving from the point it left of.

That also means this part can be somewhat misleading:

4. The interim roster pushes would not include all of the
intermediate steps, only the final
result of all changes applied while the client was in fact offline.

.. as it suggests that the changes (to a single item) combine, while
in fact they replace each other.

Re: [Standards] LAST CALL: XEP-0237 (Roster Versioning)

[Jiří Zárevúcký]

Dne 13. duben 2009 19:18 Jiří Zárevúcký  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 complete. :( Sorry...

Re: [Standards] LAST CALL: XEP-0237 (Roster Versioning)

[Jiří Zárevúcký]

Hi, I have a question about a particular scenario (it's a bit
simplified, just for illustration).

This is the initial state:


   
   
   ...



Now magine you have four pushes in the following order:


   



   



   



   



So, when the client requests a difference from ver="300", it should
receive only the final state, but when it receives the final state of
contact1:





,the client now thinks it has the full state for ver="303". If for
some reason connection fails at the moment, the client would next
request state 303, losing information about contact2's new name.

Am I right? Any idea how to handle it fool-proof way without actually
sending two interim pushes for contact1?
Or maybe just specify that the client must not store the new changes
until everything is received.

Re: [Standards] XMPP-IM - presence subscription handling

[Jiří Zárevúcký]

2009/4/11 Peter Saint-Andre :
>
> 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. :)

Re: [Standards] unavailable presence from bare JID

[Jiří Zárevúcký]

2009/4/8 Robin Redeker :
> Imagine these presence stanzas are received by a client for contact a...@b:
>
>   
>
>   
>      10
>      xa
>   
>
>   
>      away
>   
>
> What should I display? Is the last presence from 'the "empty" resource'?  
> Empty
> resources make no sense, as any resource's name must not be empty anyways (see
> BNF in RFC 3920). But whats the alternative interpretation of presence from a
> bare JID? Does it shadow any other presence? Is it guaranteed that a client 
> will
> not receive presence for a bare JID and full JID from the same contact?
>

Such behavior is clearly not correct. It deserves some clarification I guess.
I would handle it this way:

If it's available presence -> handle it normally as if the resource
was an empty string.
If it's unavailable presence -> consider all resources unavailable.
Handling of error presences is defined in the spec.

It's the best possible handling I think, since any entity sending
presence from full JID does that for the reason that it never needs
more resources.


>
> This means a server only remembers the last received unavailable presence, but
> a client _must_ display all unavailable presences it receives. That feels a 
> bit
> inconsistent to me. Also imagine what happens when people use random 
> resources,
> then the list of unavailable presences (which MUST be displayed
> "appropriately") will grow indefinitely! Ok, this is maybe no "appropriate",
> but what _IS_ actually appropriate in this case?
>
>

Again, that needs to be clarified. Most clients these days (as far as
I know) don't display unavailable presences in the roster, except the
last one. That is, you will display the status message in roster only
if it causes the contact itself to "go offline". Or does anyone handle
it differently?

Re: [Standards] XEPs in Pretty Colours.

[Jiří Zárevúcký]

2009/4/6 Peter Saint-Andre :
> 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. But I'll look into
> it. I think we've wasted enough list bandwidth on this now. :)
>

If you want just a vertical stripe over the whole page, a single pixel
line is all it takes. That should fit within a few hundred bytes,
including the http request. :)

If you decide an explanatory text is to be included in it (like on the
W3C specs), the image is probably the only possibility anyway.

Re: [Standards] XEPs in Pretty Colours.

[Jiří Zárevúcký]

2009/4/6 Peter Saint-Andre :
>
> 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, unless you want it to have a vertical text included.
The simplest way I can think about is adding a background image. :)

Re: [Standards] Fwd: Meeting minutes 2009-04-01

[Jiří Zárevúcký]

> 6b. Schemas.
>
> Discussion followed about the normativeness and syntax of schemas.
> Dave proposed that schemas be marked as normative or not, depending on
> the XEP, and Peter suggested that we might like to move to Relax NG.
> Discussion to continue on-list.

I certainly support Relax NG. I just took a look at it and it seems to
be very easy to learn and use, while being more flexible and
descriptive. I could even help with moving, eventually.

Re: [Standards] Proposed XMPP Extension: File Transfer Thumbnails

[Jiří Zárevúcký]

2009/3/31 Jonathan Schleifer :
> Am 31.03.2009 um 15:45 schrieb Peter Saint-Andre:
>
>> Typically our protocol documents don't specify user interface details
>> like that.
>
> Hm, ok. But sometimes, it would make sense if a particular feature is
> presented the same way to the user in every client. This looks more
> consistent for the user if two users are using different clients.
>

It makes sense for some features, but I don't think it's important for
file thumbnails. It can be displayed in a chat window, or it can be
part of a confirmation dialog. There is no difference in
functionality. One is just convenient for some people (but can be
annoying for others). IMHO the whole point of having different clients
is to have different ways of doing things such as this, that suit
different people.

Re: [Standards] Kitchen Sinks. Discount Kitchen Sinks. Kohler Kitchen Sinks

[Jiří Zárevúcký]

I never realized how many kinds of kitchen sinks there are... o.o

Re: [Standards] Proposed XMPP Extension: OutOfBand Stream Data

[Jiří Zárevúcký]

2009/3/14 Dirk Meyer :
> XMPP Extensions Editor wrote:
>> The XMPP Extensions Editor has received a proposal for a new XEP.
>>
>> Title: OutOfBand Stream Data
>>
>> Abstract: This specification defines how to send parts of an XML
>> stream over a direct connection between peers. This allows to send
>> large stanzas or binary data without blocking the XML stream for other
>> stanzas.
>>
>> URL: http://www.xmpp.org/extensions/inbox/outofband.html
>
> I would like to know what others think about this idea. I know it is
> kind of strange but would be very usefull for large stanzas and emedded
> binary data.

I think it's a good idea, but there should be some size requirement
for OOB data.
For example to define it should be bigger than 5kB, so the sender
doesn't open OOB stream for small data, where it would have no
benefits (or cause loop, if it was IBB transport for another OOB
data).

Re: [Standards] Proposed XMPP Extension: Server IP Check

[Jiří Zárevúcký]

2009/3/10 Kurt Zeilenga :
>
> 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 problem. Even if the server itself
is behind a NAT, it still sees the public IP of the client (most
probably it's ISP's router).

Re: [Standards] XEP-0065 and encryption

[Jiří Zárevúcký]

2009/3/9 Robbie Hanson :
> 2) When the target tells the initiator which streamhost it used (section
> 4.7), it simply sends it's public key in the message.  This might be done
> like so:
>      from='tar...@example.org/bar'
>     to='initia...@example.com/foo'
>     id='initiate'>
>   
>     
>     5AF9...[publicKeyInHex]...2C4
>   
> 
> The initiator and target can now secure their connection using SSL/TLS.  The
> initiator will simply allow self-signed certificates, and then, upon
> successful TLS handshake, it will make sure the public key used matches the
> public key it received via XMPP.
> -Robbie Hanson
> -Deusty Designs
>

I don't really know much about encryption and security, but aren't
public/private keys related to PGP? For TLS, I think it would be
sufficient to just send the certificate's fingerprint that the
initiator can check. Am I not correct?

Re: [Standards] vs. in sequence

[Jiří Zárevúcký]

2009/3/4 Peter Saint-Andre :
> 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 (and vice-versa), it would be better to remove them
>> completely. They just confuse.
>>
>> One example:
>> If schema says it's sequence (and so it has a specified order), I let
>> code read strictly in that order to save some processor time. That
>> means anything out of order messes up reading of the stanza.
>
> We have *never* enforced the order of elements, since the very beginning
> of Jabber time in 1999. If someone wants to invest the time into fixing
> up all the schemas or converting them to Relax NG, have at it.

Ok, I just never seen (or don't remember) any explicit mention of it,
so I figured the restriction applies.
Perhaps it wouldn't be a bad idea to add a note about it next to schemas.

> I don't
> have time to fiddle with that right now because I still have 750+ emails
> to catch up on, not to mention action items from the Brussels meetings
> (and for all I know Portland meetings!).
>
> Peter
>

In that case, I really don't envy you. Hope I didn't take much of your time.

Re: [Standards] vs. in sequence

[Jiří Zárevúcký]

>
> 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:
If schema says it's sequence (and so it has a specified order), I let
code read strictly in that order to save some processor time. That
means anything out of order messes up reading of the stanza.

Re: [Standards] XMPP-IM - presence subscription handling

[Jiří Zárevúcký]

>>
>> Sorry, you are right in this. I overlooked a part defining it as
>> subject to configuration.
>> I still think this can't be done without numerous problem.
>>
>
> Ok, I might forget your bullying... and You might try to look again and
> reconsider, with the rfc3920-1 and also the bis variants (as I will of
> course do also, but I don't have so much time, you can imagine).
>
> I recommend to finish this thread... and start a new one, rather
> concentrating on the technical points and correct reasoning.
>

If that works for you. I think I'll just wait until I have some time
to code it. Seems that some people don't settle for simple description
of the idea and problems.

Re: [Standards] XMPP-IM - presence subscription handling

[Jiří Zárevúcký]

2009/2/25 Pavel Simerda :
> On Wed, 25 Feb 2009 18:14:40 +0100
> Jiří Zárevúcký  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 for this is explicitly forbidden
>> by the specification. Also, implementing client's capabilities so
>> differently from the actual protocol makes a terrible mess.
>
> Uh?
>
> I'm afraid one of us must be very very mistaken then. As I read the
> spec, it's not forbidden at all, on the contrary. I would like too see
> something that shows I'm wrong.
>

Sorry, you are right in this. I overlooked a part defining it as
subject to configuration.
I still think this can't be done without numerous problem.

For example:

You get an inbound request. You approve, believing that once you click
"Approve", you are both subscribed. This can't be done, since you
still depend on the other side to fulfill it's part of a "contract".
If you wait for the other side to approve first, you are deadlocked if
the other side implements the same behavior.

>> >> As for the problems you described, any
>> >> inconsistency could just be reset to a clean no-subscription state.
>> >> How often could this happen?
>> >
>> > Too often to ignore. You cannot require users to reset it
>> > manually... users don't care about protocols!
>> >
>>
>> Read "Would it be so often for user to be bothered by vanishing of
>> subscription?". I really don't get the difference from current spec in
>> this area.
>
> Vanishing of subscription is unrelated.
>

Then I misunderstood you. What problems with the authority did you mean?

>>
>> >> Then look at the end-user client interface. I find it a bit
>> >> unintuitive.
>> >
>> > Go and file a bug report or feature request to your client's
>> > developer.
>> >
>>
>> I'm my client's developer.
>
> That doesn't prevent you from filing a bug report, does it? Pardon my
> ignorance.
>

Sure. It doesn't. It would still be closed as WONTFIX, since it can't be fixed.

>> >> Also, the mutual subscription round-trips always annoy
>> >> me. You get the request, user approves and sends his request,
>> >> contact needs to approve again.
>> >
>> > This is simply not true.
>> >
>>
>> Yet in practice, this is completely ordinary work-flow.
>>
>
> In practice, it is done, but I believe it is not needed.
>

That's exactly my point.

>> >> This has been considered in the specification
>> >> by allowing preliminary approval, but that just adds need for the
>> >> server to track this,
>> >
>> > Which is very easy...
>> >
>>
>> Yes.
>>
>> >> and there is no way to tell if there is one. I
>> >
>> > One what?
>> >
>>
>> Preliminary approval.
>>
>
> It's not forbidden anywhere AFAIK.
>

I meant that there is no way to figure out, whether the contact
auto-approves my request before I actually send it. That's just a
completely unimportant cosmetic flaw.

>> >> I already stated the benefits.
>> >
>> > I haven't seen any.
>> >
>> >> Cleaner protocol,
>> >
>> > I don't think so.
>> >
>>
>> Now I'm beginning to think you either have a very bad taste or haven't
>> read XMPP-IM at all. No offense intended.
>>
>
> I like my taste...
>
> And I will not be as arrogant as you are... and will just say you
> probably haven't read carefully and invented limitations that are not
> there.
>
> None taken :).
>

If you don't consider writing twice as much code because of protocols
"flexibility", making user interaction unreliable, being a valid
reason, then I'm inventing limitations. Yes.

>> >> simpler implementation
>> >
>> > I don't see the difference.
>> >
>>
>> As I already told, you probably never written any.
>>
>
> You seem to use your arrogance instead of real evidence.
>

Once I have time for changing my code to use protocol no one else
uses, I'll send you a diff. Forgive me, if I consider you being
arrogant in the first place. Even reducing number of possible states
from nine to four IS a simplification. You simply ignore everything
and generalize to "there is no difference".

>> >> an

Re: [Standards] XMPP-IM - presence subscription handling

[Jiří Zárevúcký]

I would really appreciate if someone who has actually written an
end-user client could give me some feedback. Anyone?

Re: [Standards] XMPP-IM - presence subscription handling

[Jiří Zárevúcký]

> 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 terrible mess.

>> I see it the other way around. IMO the current way is too complicated
>> to fit in the common needs.
>
> I believe it is equally complicated to your proposal but more flexible.
>
> From the client perspective, the current variant can work, according to
> the specs:
>
> Client A: [subscribed],[subscribe*]
> Client B: [subscribed*],[subscribe*]
>
> with some roster management stanzas around and A's server automatically
> answering with [subscribed*].
>
> (Hope I didn't do any mistake here, * denotes a more basic flow here,
> if A's server doesn't respond - some IMO misinterpret the  type="subscribed"/>, A's client does)
>
> From user's perspective it's:
>
> User A: Add contact B.
> User B: Accept contact A (means to both grant subscription and add, of
> course)
>
>
> Unfortunately, due to some server's not handling  type="subscribed"/>
>
> This seems perfectly correct and pretty easy to me.
>

Forbidden and not really a clean solution.

>> As for the problems you described, any
>> inconsistency could just be reset to a clean no-subscription state.
>> How often could this happen?
>
> Too often to ignore. You cannot require users to reset it manually...
> users don't care about protocols!
>

Read "Would it be so often for user to be bothered by vanishing of
subscription?". I really don't get the difference from current spec in
this area.

>> >> Yes, I
>> >> agree that immediate effect would be increasing complexity and
>> >> need of additional effort to maintain backward compatibility. That
>> >> would be a tricky task, but I believe that with proper
>> >> interoperability rules, it would be possible to make transition
>> >> relatively painless. I believe that in a long run, such change
>> >> would be a huge improvement.
>> >
>> > You'd need to know if the transition gives or takes.
>> >
>>
>> First compare the protocol interface itself. My approach would
>> simplify new implementations significantly, once it is widely used.
>
> I don't believe it would simplify them significantly.
>

That's probably because you never tried.

>> Then look at the end-user client interface. I find it a bit
>> unintuitive.
>
> Go and file a bug report or feature request to your client's developer.
>

I'm my client's developer.

>> Also, the mutual subscription round-trips always annoy
>> me. You get the request, user approves and sends his request, contact
>> needs to approve again.
>
> This is simply not true.
>

Yet in practice, this is completely ordinary work-flow.

>> This has been considered in the specification
>> by allowing preliminary approval, but that just adds need for the
>> server to track this,
>
> Which is very easy...
>

Yes.

>> and there is no way to tell if there is one. I
>
> One what?
>

Preliminary approval.

>> would like a simple work-flow "Request presence sharing" - "Sharing
>> approved, both are subscribed" / "Sharing declined, nobody is
>> subscribed".
>
> This usecase works well with the current specification
>

Possible, but not really simple. Just thinking a moment about it gives
me a few possible problems.

>> I already stated the benefits.
>
> I haven't seen any.
>
>> Cleaner protocol,
>
> I don't think so.
>

Now I'm beginning to think you either have a very bad taste or haven't
read XMPP-IM at all. No offense intended.

>> simpler implementation
>
> I don't see the difference.
>

As I already told, you probably never written any.

>> and user interface much closer to the
>> real-life needs.
>
> And this is definitely your client's problem.
>

User interface is always constrained by the underlying protocol's
possibilities. That's not really a client's problem, is it?

>> Just a question... did you ever need to have someone's subscription,
>> while he must not have it?
>
> Not yet.
>
>> Or the other way around?
>
> Probably yes.
>
>> Now I'm talking
>> about human contacts. I never needed something like that. There are of
>> course automated services, that don't care about your presence, so it
>> is reasonable not to send any to cut down bandwidth. That could be
>> very easily done via an extension, that would allow discarding
>> unnecessary stanzas at the source server.
>
> That seems unnecessarily complicated to me.
>

It would move complication from the current protocol to the extension.
It wouldn't just pop up anywhere.
The "flexibility", you have been talking about, is completely useless
in more than 99% of real world usage. Don't you think it's an
unnecessary complication to define it in the core protocol, when it is
very simply possible separately?

>> User doesn't really care,
>> whether a dictionary sees his presence or not.
>
> User doesn't really care about protocol det

Re: [Standards] XMPP-IM - presence subscription handling

[Jiří Zárevúcký]

2009/2/24 Pavel Simerda :
>
> It has some flaws. See my post about subscriptions, please.
>

I've seen them. The difference is you are looking at the problems from
the server perspective. I'm concentrating on the client perspective
and human interface itself.

>> Originally, I wanted to propose modifying roster pushes so they
>> contain all the state information (including eventual inbound
>> subscription request message), essentially leaving
>> subscription-managing presence stanzas only as the mean of requesting
>> the change, not presenting it to the other entity or the other
>> resources. Then one thing occured to me. Do we really need a separate
>> subscription handling for inbound and outbound presences? Users
>> generally don't want it separate. Users want mutual subscription. Is
>> there ever need to have one-side subscription?
>
> This would need a clean redesign. Not just a bunch of ideas.
>

What do you imagine under "clean redesign"?

>> Providing mechanism for just a mutual subscription, where there would
>> be only both-direction or pending or no subscription at all, would
>> immensely simplify things for both users and implementers.
>
> This would break things even further see my other post and consider
> what this change will do with the authority. Bidi-only association
> seems too simple to fit in the common needs IMO.
>

I see it the other way around. IMO the current way is too complicated
to fit in the common needs. As for the problems you described, any
inconsistency could just be reset to a clean no-subscription state.
How often could this happen?

>> Yes, I
>> agree that immediate effect would be increasing complexity and need of
>> additional effort to maintain backward compatibility. That would be a
>> tricky task, but I believe that with proper interoperability rules, it
>> would be possible to make transition relatively painless. I believe
>> that in a long run, such change would be a huge improvement.
>
> You'd need to know if the transition gives or takes.
>

First compare the protocol interface itself. My approach would
simplify new implementations significantly, once it is widely used.
Then look at the end-user client interface. I find it a bit
unintuitive. Also, the mutual subscription round-trips always annoy
me. You get the request, user approves and sends his request, contact
needs to approve again. This has been considered in the specification
by allowing preliminary approval, but that just adds need for the
server to track this, and there is no way to tell if there is one. I
would like a simple work-flow "Request presence sharing" - "Sharing
approved, both are subscribed" / "Sharing declined, nobody is
subscribed".

>> So, in case you are interested in this idea, I will continue with some
>> semantics I have on my mind. Otherwise, just tell me why do you think
>> it is not possible / feasible / wanted to implement it. I'm pretty
>> sure there is some hidden problem with this I don't realize. I suppose
>> many of you won't take me too seriously, since it would require too
>> massive change to the core protocol, but I'd appreciate if you thought
>> about it a bit. Thanks for any feedback.
>
> I believe it is impossible.
>
> But please provide your-words comparison and what it would bring. I
> might try to be the devil's advocate and add problems it would make :D.
>
> Pavel
>

I already stated the benefits. Cleaner protocol, simpler
implementation and user interface much closer to the real-life needs.

Just a question... did you ever need to have someone's subscription,
while he must not have it? Or the other way around? Now I'm talking
about human contacts. I never needed something like that. There are of
course automated services, that don't care about your presence, so it
is reasonable not to send any to cut down bandwidth. That could be
very easily done via an extension, that would allow discarding
unnecessary stanzas at the source server. User doesn't really care,
whether a dictionary sees his presence or not. If there is some
paranoid user who does, he can use privacy lists.

[Standards] XMPP-IM - presence subscription handling

[Jiří Zárevúcký]

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 presence stanza and a roster push. But that only
applies to the contact, who receives the change. Also, the "ask"
attribute looks like a maimed boolean and roster pushes do not contain
all the state information - inbound request is missing.

Even though the client can track most of the changes by tracking
roster pushes and subscription stanzas, there is one change client can
never track. When there is an inbound subscription request with no
item and user declines it, other resources get no push and no presence
stanza - no notification. That is not really a big problem, but all
this inconsistency in pushes and presence stanzas makes it all seem
very chaotic and untidy.

Originally, I wanted to propose modifying roster pushes so they
contain all the state information (including eventual inbound
subscription request message), essentially leaving
subscription-managing presence stanzas only as the mean of requesting
the change, not presenting it to the other entity or the other
resources. Then one thing occured to me. Do we really need a separate
subscription handling for inbound and outbound presences? Users
generally don't want it separate. Users want mutual subscription. Is
there ever need to have one-side subscription?

Providing mechanism for just a mutual subscription, where there would
be only both-direction or pending or no subscription at all, would
immensely simplify things for both users and implementers. Yes, I
agree that immediate effect would be increasing complexity and need of
additional effort to maintain backward compatibility. That would be a
tricky task, but I believe that with proper interoperability rules, it
would be possible to make transition relatively painless. I believe
that in a long run, such change would be a huge improvement.

So, in case you are interested in this idea, I will continue with some
semantics I have on my mind. Otherwise, just tell me why do you think
it is not possible / feasible / wanted to implement it. I'm pretty
sure there is some hidden problem with this I don't realize. I suppose
many of you won't take me too seriously, since it would require too
massive change to the core protocol, but I'd appreciate if you thought
about it a bit. Thanks for any feedback.



 element would have the children defined in the current XMPP-IM except:
  • there is no "ask" attribute
  • the "subscription" attribute has following values
∘ none - means there is no subscription sharing
∘ pending-in - means the contact requests subscription sharing
∘ pending-out - means the user requests subscription sharing
∘ subscribed - means user is sharing presences with the contact
  • there are three new optional child elements:
∘ "request", whose character data is the message associated with
the subscription request
∘ "ghost" (empty), which would work as a marker for items, that
are not yet in the roster (just holding information about the
request).
∘ "remove" (empty) - same as the subscription="remove" in the
current specification; it's changed to a separate element because the
subscription attribute should only contain information about the
subscription, not a removal request

As for the  stanza:
  • "unsubscribed" and "subscribed" types are removed, since they are
no longer needed

=== Subscription request:

Contact requesting the subscription would send the presence stanza as usual:


Please subscribe me.


The stanza would be delivered to the server and possibly forwarded to
the contact's server, but it would NOT be delivered to the contact
itself. Instead, contact would get an updated item.

Scenario 1: contact is already in the roster




Please subscribe me.
Friends




Success case:



When there is a pending request and user includes the "status" child,
it is ignored.
Server then updates subscription.




Friends




Failure case:



Server responds:




Friends




Scenario 2: contact in not in the roster

Contact is added automatically to the roster with the "ghost" marker.




Please subscribe me.





Success case:









Failure case:











Note that "ghost" item is promoted to a normal item upon success and
removed upon failure. If the contact is added via a roster set while
it is in "ghost" state, it is promoted 

Re: [Standards] [Roster|Data] Versioning

[Jiří Zárevúcký]

It wouldn't make much difference in the roster. That's true. But
imagine some other mechanism, that sends requests to all your contacts
on startup. :) Every stanza, and therefore the whole chain of
requests, would be almost twice as big.

2009/2/19 Peter Saint-Andre :
> Jiří Zárevúcký wrote:
>> As has been said, a separate namespace is a more in the spirit of XML.
>> It would need no modification to existing specifications. On the other
>> hand, it adds a lot of unnecessary data. As a programmer, I say
>> namespace. As a user of mobile devices, I say attribute. Since the
>> whole point of sequencing is to cut down bandwidth, I think the latter
>> is, though it's not very clean approach, more reasonable.
>
> I don't think the bandwidth difference is that big here, but I like the
> idea of putting it in rfc3921bis so that more people implement it. ;-)
>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>
>

Re: [Standards] [Roster|Data] Versioning

[Jiří Zárevúcký]

As has been said, a separate namespace is a more in the spirit of XML.
It would need no modification to existing specifications. On the other
hand, it adds a lot of unnecessary data. As a programmer, I say
namespace. As a user of mobile devices, I say attribute. Since the
whole point of sequencing is to cut down bandwidth, I think the latter
is, though it's not very clean approach, more reasonable.

Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)

[Jiří Zárevúcký]

Are there any news on this?

2009/1/23 Peter Saint-Andre :
> Kevin Smith wrote:
>> 009/1/23 Jiří Zárevúcký :
>>>> Really, if this is something that is going to be discussed, then you should
>>>> just allow for extra XML namespaces under each  in the roster.
>>
>>> I was thinking about this and it really starts to seem to me like the
>>> best idea of this entire thread.
>>
>> Yes, storing arbitrary data in the roster would be tremendously
>> useful. Really stonkingly useful.
>
> I was talking with someone else about that recently. Perhaps we can
> discuss it at FOSDEM with some server developers. Rosters are so core to
> everything that we need to tread carefully here, but the benefits could
> be significant...
>
> /psa
>

Re: [Standards] groupchat and error message routing

[Jiří Zárevúcký]

Yeah, it really seems to contradict a bit..

2009/2/11 Waqas Hussain :
> On Wed, Feb 11, 2009 at 11:27 PM, Jiří Zárevúcký
>  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 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 :
>>> Hi,
>>>
>>> When messages of type 'groupchat' and 'error' are sent to a
>>> non-existing resource, they are routed to the set of highest priority
>>> available resources. IMHO this behaviour in counter-intuitive. I don't
>>> see why an unintended resource would want a groupchat or error
>>> message, or how it's supposed to deal with it. Also note that the 'to'
>>> attribute gets overwritten, so the recieving resource doesn't even
>>> know to which resource the messages were originally directed. Could
>>> someone describe some cases where this is useful?
>>>
>>>
>>> Relevent rfc3921bis-07 sections:
>>>
>>> 8.2.2.  No Resource Matches
>>> <http://xmpp.org/internet-drafts/draft-saintandre-rfc3921bis-07.html#rules-fulljid-nomatch>
>>> "For a message stanza, the server SHOULD treat the stanza as if it
>>> were addressed to  as described in the next section (but
>>> without modifying the value of the 'to' attribute)."
>>>
>>> 8.3.1.1.  Message
>>> <http://xmpp.org/internet-drafts/draft-saintandre-rfc3921bis-07.html#rules-barejid-resource-message>
>>> "For a message stanza of type "chat", "error", "groupchat", or
>>> "normal", the server SHOULD deliver the stanza to the highest-priority
>>> available resource."
>>>
>>> --
>>> Waqas Hussain
>>>
>>
>
> It does happen. A resource can send a message, and go offline before
> it gets a reply. A MUC component can send a message at the same time a
> resource goes offline. Also stanzas do get lost sometimes.
>
> Note that the RFC explicitly defines what should happen, which means
> these cases are expected to happen.
>
> And no, the XEP doesn't say anything about these cases. This is stanza
> routing (from some service to local user), and must be dealt with by
> the RFC anyway.
>
> --
> Waqas Hussain
>

Re: [Standards] groupchat and error message routing

[Jiří Zárevúcký]

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 :
> Hi,
>
> When messages of type 'groupchat' and 'error' are sent to a
> non-existing resource, they are routed to the set of highest priority
> available resources. IMHO this behaviour in counter-intuitive. I don't
> see why an unintended resource would want a groupchat or error
> message, or how it's supposed to deal with it. Also note that the 'to'
> attribute gets overwritten, so the recieving resource doesn't even
> know to which resource the messages were originally directed. Could
> someone describe some cases where this is useful?
>
>
> Relevent rfc3921bis-07 sections:
>
> 8.2.2.  No Resource Matches
> 
> "For a message stanza, the server SHOULD treat the stanza as if it
> were addressed to  as described in the next section (but
> without modifying the value of the 'to' attribute)."
>
> 8.3.1.1.  Message
> 
> "For a message stanza of type "chat", "error", "groupchat", or
> "normal", the server SHOULD deliver the stanza to the highest-priority
> available resource."
>
> --
> Waqas Hussain
>

Re: [Standards] Error handling for "stream:error" like "see-other-host"

[Jiří Zárevúcký]

Sorry, I didn't notice that part.

2009/2/8 Peter Saint-Andre :
> 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 data of the
>>  element. The code you encountered sends it in a text
>> child, which is obviously wrong. I suggest you implement the right
>> behavior according to the specification (which needs some
>> clarification, but I suppose you are expected to connect to the
>> proposed domain) and ignore google's.
>
> As always, refer to rfc3920bis for clearer definitions. I have pasted
> the current text below. Available here:
>
> http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-08.html#streams-error-conditions-see-other-host
>
> ***
>
> The server will not provide service to the initiating entity but is
> redirecting traffic to another host; the XML character data of the
>  element returned by the server SHOULD specify the
> alternate hostname or IP address at which to connect, which SHOULD be a
> valid domain identifier but MAY also include a port number; if no port
> is specified, the initiating entity SHOULD perform a [DNS-SRV]
> (Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the
> location of services (DNS SRV)," February 2000.) lookup on the provided
> domain identifier but MAY assume that it can connect to that domain
> identifier at the standard XMPP ports (i.e., 5222 for client-to-server
> connections and 5269 for server-to-server connections).
>
> C: 
>  from='jul...@im.example.com'
>   to='im.example.com'
>   version='1.0'
>   xmlns='jabber:client'
>   xmlns:stream='http://etherx.jabber.org/streams'>
>
> S: 
>  from='im.example.com'
>   id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
>   to='jul...@im.example.com'
>   version='1.0'
>   xml:lang='en'
>   xmlns='jabber:client'
>   xmlns:stream='http://etherx.jabber.org/streams'>
>   
>  xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
>   im.example.com:9090
> 
>   
>   
>
> ***
>
>
>

Re: [Standards] Error handling for "stream:error" like "see-other-host"

[Jiří Zárevúcký]

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
 element. The code you encountered sends it in a text
child, which is obviously wrong. I suggest you implement the right
behavior according to the specification (which needs some
clarification, but I suppose you are expected to connect to the
proposed domain) and ignore google's.

2009/2/7 imoracle :
>
> Hi,
>
> Yeah I already saw that but what should be an appropriate action by the
> client?
>
> I tried sending end stream and then reconnect, but server doesn't
> respond.
>
> Regards,
> Abhinav
>
>
> --
> imoracle
>
> 
> JAXL - Jabber XMPP Library in PHP
> http://code.google.com/p/jaxl
> 
> 
> imoracle's Profile: http://www.jabberforum.org/member.php?userid=17412
> View this thread: http://www.jabberforum.org/showthread.php?t=1425
>
>

Re: [Standards] for sale Apple iphone 3G------$300, Nokia N96 16Gb......$350, NOKIA AEON 16GB...$600

[Jiří Zárevúcký]

I wonder, what kind of idiots are these people. I wouldn't buy
anything from anyone whose preferred form of advertisement is
spamming. It only shows how stupid the company is.

Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)

[Jiří Zárevúcký]

2009/1/23 Pedro Melo :
> Hi,
>
> On Jan 22, 2009, at 9:27 PM, Jiří Zárevúcký wrote:
>
>> 2009/1/22 Matthew Wild :
>>>
>>> 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 help wondering if
>>> the same could be achieved in a simpler way.
>>>
>>> Matthew.
>>>
>>
>> Custom contact tagging? I smell a new XEP... :D
>
> Really, if this is something that is going to be discussed, then you should
> just allow for extra XML namespaces under each  in the roster. That,
> with the incremental roster XEPs discussed (resulted in XEP-0237, Data
> Sequencing) is probably the best answer for anything contact related.
>
> Best regards,
> --
> Pedro Melo
> Blog: http://www.simplicidade.org/notes/
> XMPP ID: m...@simplicidade.org
> Use XMPP!
>
>
>

I was thinking about this and it really starts to seem to me like the
best idea of this entire thread. Allowing extra information to be
stored for every contact would solve a lot of issues. Noted
incremental roster retrieving would also solve problem of unnecessary
bandwidth overhead. I said earlier that there would be problem with
adopting such feature, but as this would reflect directly in XMPP-IM,
it may not be such a problem after all. Anyway, I think this idea
deserves more consideration.

Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)

[Jiří Zárevúcký]

> 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 mis-aggregation of contacts, who look like "bugs" or erratic
> behavior. Also, the size of the iq set for each simple change to a
> meta-contact is also a negative aspect of the protocol as it stands.

You could retrieve metacontact information before the roster itself,
couldn't you? Or just cache last known state of metacontacts.

Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)

[Jiří Zárevúcký]

2009/1/23 Pedro Melo :
> Hi,
>
> On Jan 22, 2009, at 9:27 PM, Jiří Zárevúcký wrote:
>
>> 2009/1/22 Matthew Wild :
>>>
>>> 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 help wondering if
>>> the same could be achieved in a simpler way.
>>>
>>> Matthew.
>>>
>>
>> Custom contact tagging? I smell a new XEP... :D
>
> Really, if this is something that is going to be discussed, then you should
> just allow for extra XML namespaces under each  in the roster. That,
> with the incremental roster XEPs discussed (resulted in XEP-0237, Data
> Sequencing) is probably the best answer for anything contact related.
>
> Best regards,
> --
> Pedro Melo
> Blog: http://www.simplicidade.org/notes/
> XMPP ID: m...@simplicidade.org
> Use XMPP!
>
>
>

That would be just another way of storing data. If some servers don't
support classic XML storage, how soon would they support this?

Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)

[Jiří Zárevúcký]

2009/1/22 Matthew Wild :
>
> 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 help wondering if
> the same could be achieved in a simpler way.
>
> Matthew.
>

Custom contact tagging? I smell a new XEP... :D

Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)

[Jiří Zárevúcký]

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.

Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)

[Jiří Zárevúcký]

2009/1/22 Jonathan Schleifer :
> Olivier Goffart  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 transports, you might want to append something
> like (ICQ). Or one got a work accound and a private account, you might
> want to add (Work) and (Home). Or someone still uses his old account,
> but only for a short amount of time, so you might append (old). Or you
> added the other account as a fallback, so you might want to append
> (fallback). There are 1000 of reasons. Thus, I consider the Kopete
> behaviour rather bad.
>
> --
> Jonathan
>

Exactly my point.

Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)

[Jiří Zárevúcký]

2009/1/22 Yann Leboulanger :
> 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 - Company"
cont...@google.com - "Contact - GTalk"
123456...@icq.whatever.org - "Contact - ICQ"

Metacontact - "Contact"

Rationale: every sub-contact can have some
explanation/specification/location specified in name

Perhaps it would not be very useful for most people, I don't know. I
personally would use it in this way.

Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)

[Jiří Zárevúcký]

>> 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 would be nice to drop the "non-human readable" part.
Actually, making it a human readable name would allow users to name
metacontacts.

>> 2) How are these meta-contact data supposed to be scattered across
>> multiple accounts? I really didn't get this part. (clarification
>> needed?)
>
> Every account needs to store the tags of its contacts separately. Same
> tag on different account == same metacontact.
>
> I'll add some clarification about this.
>

So this apply only for clients that allow multiple accounts connected
simultaneously, without rosters being separated (Gajim's merged mode),
right? Ok, that was obvious... sorry for asking.. :)

Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)

[Jiří Zárevúcký]

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?)

Re: [Standards] LAST CALL: XEP-0232 (Software Information)

[Jiří Zárevúcký]

2009/1/22 Olivier Goffart :
> 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 links)
>

I agree. IMO there is no reason, why should one client tell another
how to display it's states. I would certainly not implement (or enable
in client supporting this) such behavior. Noted security issue is also
a problem. On the other hand, if some client really used it, it would
have no way of knowing, whether cached images are up-to-date.

Other thing: every client can have different sizes of icons. I imagine
one could solve this by offering big images for client to scale down.
Now we can download 50+ (probably more) 128x128px images every
startup.

So.. I think it is nice reinterpretation of XEP-92, but these icons
are way too useless.

[Standards] Notification about subscription request declination

[Jiří Zárevúcký]

Hello,

I'm implementing a new XMPP client with it's own library and I've come
across a problem.
When a client declines some contact's subscription request, the server
doesn't notify any other resources about it in any way. Therefore, it
is impossible to track, whether the contacts request still apply.
That's a bit of a problem, as you don't know the exact state of the
subscription. Perhaps I have missed something and there is a way to
get this information, but I haven't found it in the current rfc3921bis
draft. So in case I'm not mistaken and this problem really exists, it
would be nice to add such notification to the protocol, wouldn't it?
Any ideas?