[standards-jig] Packet Header JEP 0033

[Jeremie]

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

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
asking/redelivering.

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
type="bcc" addresses.

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

Jer