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

Carlo v. Loesch CvL at mail.symlynX.com
Tue May 30 15:58:20 UTC 2006

Mridul typeth:
| 1) There will not be a directed presence getting sent until the presence
| broadcast is delivered : not valid.

I have stated before that it is necessary to be able to distinguish
directed presence from normal one, and I am waiting for somebody
to discuss this with me, since it is a detail where help is actually

| 2) Privacy list issues. It makes the assumption that disabling
| presence-out implies sending an unavailable presence to the remote user.
| This is not a MUST requirement if I am not wrong.

If you are going to send an update to the other side, then you will
have to remove the user first. Philipp suggested that unavailable is
semantically equivalent. From a real world perspective it makes sense,
why leave somebody believing you are available when actually you aren't?
But if I look closely at the Business Rules in 10.2 the idea of using
unavailable for deletion from the list may have been wrong.

| 3) The 'list management' is not explicit - and is a potential landmine
| of impl bugs.
| Example from JEP where this could fail : probe getting sent before the
| broadcast is over , probe not getting sent , case (1), etc.

Sorry, I don't understand the scenario like that.

Why should my server allow any other presence packets to be sent while
it is running the fan-out?

| 4) The JEP is depending on observed behavior - not defined behavior
| (preferably should depend on MUST requirements) : this is not a good way
| to gaurentee robust behavior.

Huh? You want more MUSTs in the JEP? No, you must be meaning
something else, only you speak in riddles and I don't comprehend.

| Other than the ones mentioned above : for a list recreation , do you
| need to send a presence burst again ?

No, you can act smarter and only update the server that lost its list.

| Considering the chances of how list's could get out of sync (can be
| validated if there is a way for the initiating server to query for the
| jid's in a list) , this is a very high cost if it happens frequently
| enough ...

So far there is no reason to expect the list getting out of sync anyway.
It's just a presumption I keep hearing over and over without facts.
But yes, we can additionally provide for the cool hash trick.

| I was talking from the context of XMPP :-) For XMPP , the approach is
| broken.

No, XMPP is broken. At least be honest and admit it.
Rosters which aren't in sync because the packets don't make it
safely to the other side, that's not a feature. It's a bug.

You can criticize me for making too positive presumptions on the
usability of XMPP, you may even call me naive about it.

| I trust my local server to enforce my requirements : I can take my admin
| to task if he does not - not a remote server's admin.
| There has been enough mail traffic on that issue though :-) So I guess I
| will just leave it at that and not create more.

And the remote server will always be able to forward your communications
to the FBI or CIA, no matter which list control strategy we use. But you
are right, we have gone through this pointless discussion before.

| >| >| > The initiating server can request for a list creation with a set of bare
| >| >| > jid's and then use that as 'to' in subsequent presence stanza's -
| >| >
| >| >Yes, this is how the context lists operate.
| >| 
| >| Exactly , why not use this ?
| >| Create a new list on the fly on the remote server with the required
| >| barejid's, and use that list as recipient to send presence updates to.

That's what happens according to the proto-JEP when you send out the first
round of presence packets.

| The bounds within which the list is created are very shaky.
| You are assuming server implementation details (send presence broadcast
| , then probes , all point from 1 , 4 above , etc) for ensuring it to work.
| Mind you , if the assumptions were valid , it would work beautifully -
| unfortunately , it is not the case IMO.

We may have to add some restrictions if a server's right hand doesn't
know what its left hand is doing. Most probably the server will not be
able to relay _any_ (directed) presence without becoming aware of it and
integrating it into the list strategy, but that's okay. Awareness is good.
After all we already have a similar rule concerning directed presence,
which enforces the transmission of unavailable status when the client
connection breaks. Becoming completely aware of presence being sent and
received is a sane step to take anyway.

| Unfortunately , I do not have context about these discussions : I was
| not part of them , neither can I find the relevant archives about the
| discussions (except for jig).

Well the one in February suffices, the other one is more of historic value.
But there is a URL to that somewhere. Oh I found another discussion that
happened before the release of the RFCs. Here it is:

The one in February is here:

| If similar functionality is achieved without breaking the spec and gives
| similar performance metrics , then what is wrong or useless with the
| approach ?

Okay, let's presume both strategies aren't breaking the RFC, or if they
do we are going to fix it. Then what remains is that Richard wants to
add overhead with a clumsier list syntax and - seriously bad - unnecessary
acknowledgments. Why unnecessary? Because TCP gives you reliable transfer
_or_ an exceptional error situation. Retransmission on error is much cheaper
than continous acknowledgments, and just as safe.

| If nothing , this JEP has brought some interesting points to ponder over :-)

At least one thing. :-)))

| Not just from the point of view of breaking the spec , but also from the
| fact that you are totally ignoring hosted domains and similar features.

No no no why are you digging up things we have buried before. When you
open up a stream you have a stream:to field that contains a server name.
Our suggestion was, that leaving out the to means that the stream:to
is intended, just a way to say to='stream:to/route' is implicit.

| I think there might be more implementation of JEP 0033 than what you
| propose :-)
| So it would be easier to get something along those lines accepted as
| compared to something new.

JEP-0033 has no syntax for modifying existing lists. It was never
conceived with the idea that lists could be kept on the receiving
side. It is to a large extent completely useless to the job at hand.
All the to/cc/bcc are of no semantic value here. When you say JEP-0033
you are actually thinking of a large new protocol with at least as
much complexity as JEP-0033, but not JEP-0033 itself.

The way the rosters operate is much more like such lists instead,
but alas, we found out we can't rely on them.

The way presence is handled with groupchats is also more like what
we need here for smart presence, so maybe we should indeed first
submit the proto-JEP on 'smart multi-user chat', then make presence
a derivate of that. Hmm, that could work. After all it's still
presence stanzas.

| Not that this is a good enough reason not to innovate ! Just pointing
| out the obvious...

The apparent obvious  :)

| Operations are useless unless the initiating entity knows what it is
| operating on.
| I did not see a list-jids/query operation on the list : so the rest of
| the operations may not be very useful.

If the initiating entity is no longer aware of what is going on, then
restarting anew is just as (in)expensive as trying to query what the
state is. But this only happens when a connection breaks faulty, or
a server is restarted without persisting this information (which is ok).
So there is never a situation where another round-trip to ensure this is
of any use. But yes, we can add hashes to the plan so the receiving side
can additionally ensure, that it is doing the intended job.

| Assuming you add that too , validation of the list will be as expensive
| as creating a new one !

That's why we're not doing that.

| In our case , the presence handlers are pretty much abstracted away from
| the actual stream - by more than one layer.
| This sort of tight coupling as espoused by the JEP is not very practical
| (reset lists when stream is closed , etc) ... but that is a different
| discussion altogether.

That is probably all very nice looking, but decoupling the application
from network exceptions can't be a healthy idea. All you need to do is
to let the application know that something went wrong on the stream.
That's all we are talking about. You don't even have to provide the reason.

No, I'm not talking about each close of connection. Only about ERRORS.
You need to HANDLE ERRORS. Imagine a programming language where all
exceptions are never reported but simply ignored. Hehe, what fun!
You can never trust your application will actually do what you want it to!

| If the idea makes sense , we will need to re-design :-)

I'm sorry, but even if you only pass around XML, then maybe the introduction
of an inner-server XML code for network errors will do the job. I however
hope you pass parsed DOMs between your modules, not re-render and re-parse
actual XML text.

| >I could use a virtual beer now.
| Have fun :-)

No no it's useless if I can't share it with you.
It may as well be a tamarind juice or an indian tea.
I just think Richard, you and me should be meeting over
a cup of something, cool down and laugh about things.   :-)

It takes so much patience to find out what the other side is
actually trying to criticize, when reducing it to this or that
won't work because that's just the way it is. So it is just
normal to reject criticism until you have solid facts.

» Carlo v. Loesch » http://symlynX.com » psyc://ve.symlynX.com/~lynX
	    xmpp:lynX at ve.symlynX.com » irc://ve.symlynX.com/#symlynX
        CryptoChat » https://ve.symlynX.com:34443/LynX/?room=symlynX

More information about the Standards mailing list