[Standards] XEP-136 and XEP-59 implementation comments
lists at ndl.kiev.ua
Tue Mar 25 14:40:49 UTC 2008
This time I'll try to respond quicker hoping you haven't done full
"context switch" yet ;-)
>>>> Duplicate items
... skipped ...
> My working copy now has:
> "The XML character data of the <last/> element is a unique, persistent
> identifier created by the server, which MUST be treated as opaque by the
OK, that seems to be just what is needed, thanks!
>>>> XEP-59: detecting the change
>> But <changed/> element might still be useful if somebody else decides to
>> go that route, and also for other cases such as you've described with
>> However, if you agree to proceed with some kind of "change notification"
>> item for RSM, I think that my original <changed/> element proposal
>> should be upgraded to versioning-like scheme: so, instead of including
>> UTC, it should include just opaque integer which is increased when items
>> in requesting range are changed, but not necessarily by +1 for each
>> change. In this way it's still possible to include UTC by converting it
>> to integer first, or use any more reliable way of versioning if that's
> You mean like XEP-0237? :-)
Well, I do not track other XEPs discussions in detail, but as far as I
understand: yes - only hoping it will not cause such high debates here
as roster did ;-)
(especially considering the fact that strict increasing is an
important property here which cannot be substituted by just "differs"
>>>> Resource modification when auto archiving
... skipped ...
>> 1. By that we increase possibility of collections collisions. As due to
>> XEP-136 each collection has to be uniquely identified by "with" and
>> "start" if we strip resource there's higher probability of two
>> collections colliding by these attributes; while it's highly unlikely
>> I'm going to have two different conversations with the same person under
>> the same client started at the same time, it's more likely to happen if
>> resources are not used, so in fact these could be two or more different
> That's true for IM use cases between human users, but no one ever said
> that XMPP was limited to human users.
Correct, but the conclusion "by that we increase possibility of
collections collisions" still holds, doesn't it? ;-)
Anyway that probably doesn't matter too much as we seems to agree on
the way to specify the desired behavior below.
... skipped ...
>> From the client side, if <thread/> elements are used, one possibility,
>> it seems, is to use "parent" attribute according to XEP-201 in all
>> children conversations pointing to the "root" <thread> element of the
>> original message and use different <thread> elements for each conversation.
>> For XEP-136 this can be mapped to storing all these conversations
>> separately in different collections, store original message in its own
>> collection and put links from all children collections to this parent
>> collection (probably there has to be "parent" element in collections
>> linking besides "prev/next" then?)
> Heh, that's creative. It might work best.
>> To be true, I think that this issue is out of the scope of XEP-136 - I
>> would expect that <thread> behavior either should be specified by
>> XEP-201 (or somewhere else) or left as implementation-defined; on the
>> other hand, XEP-136, probably, should just take into account <thread>
>> values and use them for its business like described above.
> Agreed. So perhaps we need to say how threads are used in archiving. I
> see that we've left that out so far.
Does the description below cover completely things that should be
specified for "how threads are used in archiving"? Or do you have in
mind some other cases that need to be discussed / analysed?
>> So, for me it looks like the following could be specified in XEP-136:
>> 1) If no <thread> element exist, server may use its own
>> implementation-defined strategies for mapping messages and conversations
>> to collections and also may treat resources in implementation-defined way.
>> Maybe some heuristic can be suggested such as the one I described in my
>> first letter for "conversations tracking", but I doubt anything 100%
>> reliable can be proposed.
>> 2) If <thread> element is present, the mapping is exactly 1 <-> 1 (one
>> thread element to one collection). If "parent" attribute is present for
>> thread - the link should be created of type "parent" to the appropriate
> That seems reasonable.
>> Resources can be treated as follows: when receiving first message with
>> full JID it's allowed to overwrite previous bare JID of collection by
>> new, full JID; if previous JID was already full and the new one is also
>> full, and differs from the previous one - assume that we have
>> "multi-resource" case, modify collection's JID to bare one and forbid
>> all its further overwrites.
> That, too, seems reasonable.
>>>> Duplicate messages times
... skipped ...
>>> By "duplicate entities" do you mean <from/> or <to/> elements with the
>>> same dateTime?
>> Yes. As I said I think it's more or less deducible what the required
>> behavior here is, but probably it can be useful to clarify it in specs,
>> as at least I had some doubts thinking about it. Maybe it's just me,
>> though ;-)
> OK, I'll add a note about that.
>>>> List collections for Bare JID / Domain
... skipped ...
>> Well, in fact I think I've found already one case when this is a
>> problem, not only for collections listing, but also for their removal
>> and for preferences storing, see my message:
>> Basically, current approach means we have no real control over the
>> messages with bare/domain JIDs: so I can nor delete messages from/to
>> icq.example.com transport, neither forbid auto-archiving them without
>> affecting all messages to all ICQ users.
> Yes, but do you exchange messages with icq.example.com? We have the same
> problem in MUC rooms -- you can't block all users at example.com from
> joining the room without at the same time blocking example.com itself
> from joining the room. Is that a big problem? I don't think so. We use
> the same matching method in MUC, privacy lists, and now also message
> archiving. If we want to fix that, I suggest that we fix it everywhere.
Well, I think you have better overview as to judge if that's a big
problem or not, as I can use here only my, quite limited, experience.
To provide at least some example, if I haven't screwed up smth in SQL
queries, my current stats for collections database (basically almost
single-user installation) show the following, starting from 2007.06.01
(somewhere around that date both ICQ and MSN gateways were installed
and operational on my server):
Total collections with *@msn.example.com: 229
Total collections with msn.example.com: 124 (about 54% of all collections)
Total collections with *@icq.example.com: 837
Total collections with icq.example.com: 88 (about 10% of all collections)
Of course I do not claim to be representative user here: I use ICQ
and, especially, MSN gateways not that much recently, but error
messages from gateways (wich comprise all of the "direct" messages
from these domain JIDs) are coming regardless whether I use these
gateways or not.
You may very well say (and be 100% right) this is not a problem that
should be solved on XMPP specs level ;-) I agree it isn't that hard to
just modify gateways so that they do not send users any direct error
However, I believe that specs should be flexible enough to cover
real-world usage cases - and it seems that with at least one such
real-world usage case I have no real way to manage my archived
collections/messages using the specs (so, remove or block from auto
archiving error messages from gateways) - as to me this may imply lack
of specs flexibility in this particular area, so even if particular
problem with gateways can be sorted out by other means - I still
thought it may be a good idea at least to discuss it.
Good luck! Alexander
This message was sent using IMP, the Internet Messaging Program.
More information about the Standards