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

[Richard Dobson]

> I know, I've seen the discussions, they are mostly on wether to whack or
> to <ack/> but not talking about the causes. I've seen that URL weeks ago,
> but all of it doesn't apply to our proto-JEP -- If a TCP is broken
> enough to get stuck, well - leave it stuck until it timeouts - maybe
> one day it can be re-established, in that case it is more than obvious
> that the list data is no longer valid, so it is resent. End of story.
>   
Well it might be the end of the story for you but its still a big 
failing in your spec, it doesn't have a decent level of error recovery, 
its a real waste (and if you ask me not something you can truly even 
describe as error recovery) to have to send the whole list again from 
scratch when you get a problem with only a single one of the stanzas, 
maybe even the last one you have sent out. Spin it how you like but it 
would be far better if your spec were able to only have to resend only 
those which did not get there.
> | request
> | ---
> | <iq type="set" id="3433" to="multicast.receiverdomain" from="senderdomain">
> | 	<list xmlns="http://jabber.org/protocol/multicast">
> | 		<add>jid1 at receiverdomain</add>
> | 		<add>jid2 at receiverdomain</add>
> | 		<add>jid3 at receiverdomain</add>
> | 		<add>jid4 at receiverdomain</add>
> | 		<add>jid5 at receiverdomain</add>
> | 		<add>jid6 at receiverdomain</add>
> | 		<del>jid6 at receiverdomain</del>
> | 	</list>
> | </iq>
> | 
> | ack
> | ---
> | <iq type="result" id="3433" to="senderdomain" 
> | from="multicast.receiverdomain" />
>
> Yes, nice. Has nothing to do with good old presence stanzas, but probably
> it can be done, too. Just please stop using the technical term 'multicast'
> the wrong way. If this was multicast, then you would have to say SMTP has
> been multicasting ever since To: Cc: and Bcc: existed. Multicast is only
> when you have a tree or mesh of hosts which distribute information, like
> the MBONE or IRC. XMPP always fans out things, and neither your nor 0033
> are proposals, which actually implement multicasting. So isn't ours, but
> at least we have a plan for that.
>   
Thank you, I know its nice, I'm glad you agree, when did I say it had 
anything to do with presence stanzas?, the whole point of it is that you 
aren't using the presence stanzas to set-up the distribution list, I 
thought you had understood that.

As noted by David, and after looking at some of the various definitions 
for the word multicast there is nothing wrong with our usage of this 
word so please stop telling us its wrong when it isn't, it all depends 
on the context, all of these definitions of multicast seem to fit with 
what we are doing:

"Like a broadcast, a multicast replicates information from one source to 
multiple recipients on a network"

"To transmit a message to a select group of recipients. A simple example 
of multicasting is sending an e-mail message to a mailing list."

"Special form of broadcast in which copies of the packet are delivered 
to multiple stations, but only a subset of all possible destinations"

"Multicast is the delivery of information to a group of destinations 
simultaneously using the most efficient strategy to deliver the messages 
over each link of the network only once and only create copies when the 
links to the destinations split. By comparison with multicast, 
conventional point-to-single-point delivery is called unicast, whereas 
delivery to every node of the network is broadcast"
> So in the end we have to do it your way because the least common denominator
> is your opinion and your degree of protocol verbosity? Hmm.
>   
Protocol verbosity??? I'm confused, how does reducing the number of 
stanzas significantly and easily providing for error recovery mean its 
verbose, if anything its less so due to the major reduction in the 
number of stanzas the receiver has to process, instead of initially 
getting say 50 presence stanzas they just get one single IQ stanza, hmm.
> | No its not at all, the unclean closing of TCP connections when you had 
> | the opportunity to do it cleanly is just a bug and is only a tiny cause 
>
> It's the one bug that affects our proto-JEP and so now that it is fixed
> we can go on working. Also, look at all the nice user statements that
> Maciek Niedzielski posted:
>
>     "oh, my connection crashed again, so I copy-paste again"
>     "just in case, I write again"
>     "my connection is sth wrong, what is the last message you received?"
>     "oh, you didn't get my message?"
>
> They all speak of temporary losses, not servers being unavailable over
> longer times. I can imagine these were either affected by the racing condition
> on closing idle streams, or they are all on GPRS or behind evil TCP killer
> firewalls. But luckily federated servers don't have those problems. 
Yes these speak of temporary losses, but these losses (that Maciek was 
talking about) will be practically all due to broken TCP connections 
that have yet to time out, not because of the unclean closing of the 
streams, so you imagine wrongly, please read the discussion again as it 
clearly talks about broken TCP connections. But in any case you will 
soon see for yourself that the bug fix you have identified will not make 
any real impact on stanza losses. Plenty of servers will be behind 
firewalls and NATs that might be uncleanly dropping TCP connections as 
David pointed out, so you will soon find for yourself that plenty of 
servers do in fact have these problems.
> | Its not a matter of the ease of changing the content of a stanza, its a 
> | matter of the desirability of doing so, allowing the content of the 
>
> Hehe, yes I knew a discussion of principles would come along.
> So why don't you introduce a framing capable syntax, so that keeping
> content as is, is actually of any use? Feeling clean isn't enough of
> a reason. In the case of presence, your relaying homeserver has all
> reasons to be absolutely in charge of what presence goes where.
> After all it is expected to send out an unavailable even for directed
> presence. So going the next step of taking control over directed presence
> is hardly a big thing.
>   
Why would we want to introduce a "framing capable syntax"? What real 
benefits would it provide over our manipulation of the to and from 
attributes? I'm sorry but "feeling clean" as you describe it is plenty 
of reason not to mess with things you don't need to be. Yes your 
"relaying homeserver" does have plenty of reason to be in charge of that 
presence goes where, that's the whole point of it controlling the 
addressing information, but just because it is in control of the 
addressing information it doesn't mean it should be freely changing the 
content of the stanza, i.e. possibly changing the status or show 
elements of the presence stanza from what they originally were, don't 
you agree?.
> Are you saying your acks will become redundant as soon as JEP-ack is
> in place, thus we should relieve XMPP of all the in-application acks
> and switch it to a general reliability ack system like JEP-acks or
> whacks? I liked the vertical tab whacks. I doubt any client sends those!
>   
No I'm not saying they will be redundant as they are still very useful 
at the application layer for ease of implementation and flow of the 
protocol. I am saying that before your protocol can really work the 
stream acking must be in place first throughout the network, otherwise 
there will be a lot of wasteful list rebuilding happening.

Richard