[Standards] Proposed XMPP Extension: Message Stanza Profiles

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Wed Aug 1 20:04:13 UTC 2007


On Wednesday 01 August 2007 12:21 pm, Robin Redeker wrote:
> On Wed, Aug 01, 2007 at 11:46:43AM -0500, XMPP Extensions Editor wrote:
> > The XMPP Extensions Editor has received a proposal for a new XEP.
> >
> > Title: Message Stanza Profiles
> >
> > Abstract: This document specifies best practices for handling extended
> > content in XMPP message stanzas.
> >
> > URL: http://www.xmpp.org/extensions/inbox/messageprofiles.html
> >
> > The XMPP Council will decide at its next meeting whether to accept this
> > proposal as an official XEP.
>
> Hm, this is an interesting XEP. I can imagine how client _might_ get
> confused by such a message, but at least I wouldn't have much problems
> with it.
>
> I mean, I have to scan the message for all kinds of things anyway, eg.
> for the mood and all the other rubbish.
>
> I would then transmit each part to the program module that handles it
> and let it proceed. Eg. the dataform would be displayed, the message
> would be printed in the window, geoloc and mood will be updated and the
> message module will figure out that the message is urgent and will of
> course intercept the message if it has expired.

This is precisely what I'm arguing against doing.

A MUC invite should be displayed in the same context as the body that 
accompanied it.  If IBB and body are together, only IBB should be used.  If 
IBB and x:data are used together, it is an invalid stanza.

My proposal is that a single message stanza should serve one unambiguous and 
unified purpose, and this stems from my own implementation experience.  If 
your implementation consists of filters for namespaces that trigger handlers 
(pretty much everyone does this), then I'm saying only one filter shall match 
on a given stanza.  You cannot have multiple matches, and you cannot have a 
situation where one filter wins over another due to filter installation 
order.

> How are receiving clients expected to find out which profile the message
> belongs to? Are they expected to find it out? Or are the profiles just a
> recommendation for the sender to send messages that gurantee that the
> message isn't confused by dumb clients?

Most clients (and I received additional confirmation at the devcon) filter on 
specific elements/namespaces in a message stanza, in some arbitrary order, 
and then use the stanza for a single purpose.  Everything works today as 
expected, because most senders don't mix elements of "conflicting" protocols 
in the same stanza.  The XEP aims to put the current practice down on paper, 
because otherwise I feel our implementations are simply getting lucky.

Receiving clients are not expected to have to find out what profile a message 
uses, and therefore senders should not assume a receiver knows anything about 
profiles.  So you're right, this XEP is mainly a recommendation to senders.  
However, knowing that messages must conform to a profile should allow for 
tighter receiver implementations.

-Justin



More information about the Standards mailing list