[standards-jig] JEP 0033, Packet Headers, Issues

Ben Schumacher ben at blahr.com
Fri Jul 19 15:58:37 UTC 2002

On Fri, 19 Jul 2002, Adam Theo wrote:
> First, I wonderif needing to expressly send the multi-address packet to
> a "multicast component" is really necessary? If there are more than one
> intended recipient (through to, cc, or bcc fields), the packet must be
> addressed to a "multicast.your.domain" component, which will handle the
> forking of the message to all recipients. A question, then: will this
> multicast server have to be expressly specified by the sender, or can
> they address the packet to one of the "to" fields and have their server
> catch it and fork it automatically? Otherwise, this seems to add too
> much complexity on the hands of the sender. Not even normal Jabber users
> would know to do this, since it is not like email at all. I think an
> alternative needs to be found, such as the sender's server automatically
> checking for forking, instead of a specific multicast component.

The spec does allow for a server to have built in processing of multicast
packets, it just doesn't explicitly state it. That being said, I'm not
sure what the problem is. When you say "will this multicast server have to
be expressly specified by the sender," I will assume you are using the
term sender to reference the "end user." Is this assumption correct? If it
is, then I think you should rethink the issue. A developer could easily
make a client that does this process automatically, wouldn't this be more
intunitive. For example, when I (as a user) am sending a message, and I'm
trying to send to multiple recipients, my client (Exodus) could already
know that a multicast component is available and address the packet
accordingly. Wouldn't this seem to be a more intuitive design? And since
Exodus already has support for "broadcast" (multi-recipient) messages by
simply sending out multiple packets, it would make sense to add code to
take advantage of this component and conserve bandwidth.

> Next, why not have all <address>, <field>, and <resent> elements as
> direct children of the <header> element. It's not like the <addresses>,
> <info>, and <trace> elements that are currently the direct children have
> any meta information of their own, so why not simplify things and remove
> an entire layer of nodes from the packets? No data would be lost since
> none of the elements needs any type of specific ordering to work. They
> could be easily "jumbled" together for the sake of not creating another
> layer that has to be traveled down.

I think Joe's intention here was to ease processing on the server
(component) side. The multicast component can step down (use XPath)
to quickly locate the targets of this multicast message. If they are all
at the same level, then it requires that *all* header elements are parsed,
which could be extremely expensive if there are a large number of <trace>,
<field> and <resent> elements. In the original version of the JEP, this
structure didn't exist, and it was revised for this reason (IIRC).

And Joe, if I'm off on any of this, please correct me, but I believe I
have a pretty good understanding of your goals.



More information about the Standards mailing list