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

Dave Cridland dave at cridland.net
Thu Jun 1 08:12:31 UTC 2006

On Thu Jun 01 07:13:16 2006, Carlo v. Loesch wrote:
> 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.

I think it's the best term available, actually. In IP, multicast 
works by creating a magical address which from that point on is 
basically handled as a mixture of fanout and broadcast. "Multicast" 
in XMPP is pretty much the same thing.

Besides which, I'm afraid it's simply the accepted term in XMPP, 
whether it's "right" or not. Inventing new terms is not a good idea, 
it just confuses people.

> 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.

Actually, it wouldn't surprise me if many servers were behind "TCP 
killer firewalls". Any firewall that does connection tracking, or 
stateful inspection, might kill TCP connections when it loses the 
state due to a timeout or running out of slots in a table. It doesn't 
have to be NAT, although I'd be willing to bet that a large number of 
"federated servers" are behind NATs, too, given the enterprise usage 
of XMPP.

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list