[Standards-JIG] proto-JEP: Smart Presence Distribution

[Richard Dobson]

> | 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
> http://smarticast.psyced.org/jep-smart-presence.html
>   
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.

Richard