[standards-jig] Packet Header JEP 0033
JHildebrand at jabber.com
Fri May 24 15:45:42 UTC 2002
I've gone back and forth on the delivered='yes' attribute a couple of times.
I tried capturing the delivery information in the trace elements, but that
didn't work well. After talking with Craig, the approach in the JEP was the
one we decided would be the most implementable. I guess I could imagine a
couple of other ways of doing this, too. Let me think about it some.
Another thing that I don't like is that the rules for delivery and
re-delivery are a little complex, particularly with respect to BCC's. It
seems like there should be something simpler. Maybe this is all part of the
Also, what do people think about splitting the three sections of the header
into three different namepsaces, rather than putting them all into the
So, something like:
> -----Original Message-----
> From: Jeremie [mailto:jeremie at jabber.org]
> Sent: Thursday, May 23, 2002 4:13 PM
> To: standards-jig at jabber.org
> Subject: Re: [standards-jig] Packet Header JEP 0033
> 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
> 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... :)
> Standards-JIG mailing list
> Standards-JIG at jabber.org
More information about the Standards