[Standards-JIG] proto-JEP: Smart Presence Distribution
richard at dobson-i.net
Tue May 30 10:55:16 UTC 2006
> | This was my original suggestion, but they seem to be very against it for
> | some reason, they have still yet to really explain why.
> Your idea was to combine JEP-0033 syntax with our idea of keeping state
> in form of context lists on the recipient side. That is a possible way
> to go about it, but it is redundant with the way presence is to be sent
> out according to RFC 3921. If you're going to make a completely new
> distribution scheme for presence, you are either being redundant, or
> disabling large parts of RFC 3921 in your interserver communications.
Huh???? "disabling large parts of RFC 3921 in your interserver
communications", sorry but what are you on about? Please explain.
> Our new proto-JEP makes use of the presence distribution according to
> RFC 3921 and only delicately extends this to re-use the information and
> save on bandwidth. I am sorry you didn't notice there is fundamental
> difference from our earlier proto-JEP to the current one. I think it
> has even doubled in size. :-)
I've seen it, but as noted and admitted to by Philipp the protocol as
outlined means the lists will need to be recreated over each new S2S
connection and will only be valid for that S2S connection, as soon as
that connection drops the list becomes invalid and needs to be
regenerated at the next connection, this is a problem because it will
not work very well with how xmpp/jabber servers are currently
implemented as the presence sending code and s2s are almost always
completely separate, also having to resend the list every time the
connection is established could mean an increase in bandwidth used
between servers where the S2S connections frequently drop and
re-establish, as normally in those cases the presence stanzas would only
get sent once, whereas with your suggestion every time the connection is
re-established the stanza's will need to be resent again to populate the
list, if that list doesn't actually end up being used before the
connection drops then all that traffic would be for nothing.
> | > Either we can expose ways to add/delete jid's to this list , or just
> | > recreate a new list depending on what gets decided here.
> Yes that's what we have. Look at the List Use Cases in 5.2 of
You do not have a reliable mechanism for that due to the fact that there
is no acknowledgement of additions and deletions which due to the
potential unreliability of xmpp (i.e. stanzas not arriving and no
undelivered error messages being returned to the sender, i.e. lost in a
black hole) means that the lists are not usable over multiple S2S
connections as over time they will get more and more out of sync as the
presence stanzas get lost.
> | don't worry, yes ive already suggested this, even though they seem to be
> | ignoring it, more fuel on the fire, good to hear minds are thinking alike :)
> No Richard, we have gone through all the suggestions we got, taken them
> seriously, and come up with an in large parts new solution, so please come
> and take a look at it.
I have looked at it, and you still seem to be missing part of the point,
as it still has some rather large holes that could easily be solved if
you just use explicit additions and deletions as suggested originally
and again above (i.e. use an IQ protocol that will have acknowledgements
so the sending server knows whether the addition or deletion was
successful or not), you cannot rely on implicit additions and deletions
as you are in this proposal.
More information about the Standards