On Wednesday 01 August 2007 1:44 pm, Robin Redeker wrote:
> On Wed, Aug 01, 2007 at 01:04:13PM -0700, Justin Karneges wrote:
> > On Wednesday 01 August 2007 12:21 pm, Robin Redeker wrote:
> > > 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).
This was suggested at the devcon, but we resolved that the elements already
present in the stanza were enough of an indicator.
Compare:
<message>
<x xmlns='jabber:x:data' ...>
...
</x>
</message>
with:
<message>
<profile xmlns='jabber:x:data'/>
<x xmlns='jabber:x:data' ...>
...
</x>
</message>
The fact that the former would be in the 'jabber:x:data' profile is easily
derivable without the extra <profile/> element.
Sure, the <profile/> element might help clear up a situation like this:
<message>
<profile xmlns='jabber:x:data'/>
<x xmlns='jabber:x:data' ...>
...
</x>
<data xmlns='http://jabber.org/protocol/ibb' ...>
...
</data>
</message>
But a good set of rules would work just as well, I think.
-Justin
