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 side). [.snip.] > 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. Robin
