[Standards] Proposed XMPP Extension: Message Stanza Profiles

Robin Redeker elmex at x-paste.de
Wed Aug 1 20:44:29 UTC 2007

On Wed, Aug 01, 2007 at 01:04:13PM -0700, Justin Karneges wrote:
> 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.

Ok, then we really need an XEP clearing this up. The easiest for the
receiving client would be a <profile/> element with a specific namespace
attribute specifying the meaning and purpose of the message then.
(Unfortunately this would also mean new behaviour for the receiving

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

Ah, ok.


More information about the Standards mailing list