[standards-jig] Packet Header JEP 0033
jeremie at jabber.org
Thu May 23 22:13:24 UTC 2002
First off, this JEP is a nice step forward, it makes a few possibly
non-obvious features possible and can be used to nicely layer on some
things jabber has always needed.
A couple questions/thoughts, in particular with the addresses element.
Any time I want to or see attributes used as a yes/no it's usually a red
flag for me, and in this case it's flagging that an "address" field is
being used to store two distinctly different data types, an address and
I see two things going on here, the expression of address information (who
received what and their role as a recipient) and instructions on the
re-delivery of the given packet between two trusted entities capable of
Why not separate them?
It could be done several different ways, either having a few new element
types just for delivery addresses or using a new namespace entirely. But
just separating the delivery instructions from the address information
seems like a good thing. This is particularly helpful when two entities
are communicating just the delivery instructions to each other.
It can also be used if sending to a user at host jid, and asking that jid to
multicast to multiple resources for that user. Any entity receiving
delivery instructions should only re-deliver the packets if it is
authoritative for the recipient jids. This also removes the need for
The second part of all this that spurr'd the digging into x:header in the
first place is a particular feature that has always been missing from
Jabber. When not using the delivery instructions/multicast agent aspects
of this JEP, it is still immediately useful: client-driven multiparty
chat (poor-mans conferencing).
What I mean is, any client can _today_ use the header namespace to stamp
it's outgoing messaging with a list of the others that are part of that
conversation. Some of the other IM clients/systems have the concept of
adding additional buddies to a conversation on the fly, and although it
could be implemented using the existing conferencing/groupchat, it isn't
nearly as smooth and would take a great deal of implementation work. But
by using the extra recipient information in a header on a message, the
client can display it in a room style interface, and reply to all the
recipients again stamping the reply w/ the same list. Non-supporting
clients would only reply to the sender, which would just see that reply as
a direct/normal message/chat.
Anyway, just some rambling... :)
More information about the Standards