[Standards] Proposed XMPP Extension: Message Stanza Profiles

Robin Redeker elmex at x-paste.de
Thu Aug 2 07:13:32 UTC 2007


On Wed, Aug 01, 2007 at 06:55:47PM -0700, Justin Karneges wrote:
> On Wednesday 01 August 2007 1:44 pm, Robin Redeker wrote:
> > On Wed, Aug 01, 2007 at 01:04:13PM -0700, Justin Karneges wrote:
[.snip.]
> > > 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.
> 
[.snip.]
> 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:
> 
[.snip.]
> 
> But a good set of rules would work just as well, I think.

I agree, but here some of my thoughts:

Well, I also think that it's possible to come up with rules that divide
the current XEPs into a set of disctinctive profiles. But will that also
be true for future XEPs? Will the ruleset be extensible enough not to
become too complex when more (yet undefined) XEPs joining in?  I think
atleast that the <profile> element is an easy and extensible way to
ensure future compatibility.

With a profile element it will also be very easy to make a registrar
where one can simply create new profiles by defining a new namespace for
the <profile> element.  But I don't know how your solution to the
registrar stuff looks like, maybe it works as well.

Also note that old clients that don't support <profile> would of course
still work. The problem with <profile> is, I guess, that maybe clients
can't really rely on it because there will be still a lot of old clients
not sending it. At least for those cases we might still need a bit
disambiguation in the XEP.

But IMO the division of possible <message> children elements into
profiles and the then required disambiguation 'heuristic' in the client
is not optimal if the heuristic is the only way to determine it.
So I guess that a <profile> element can be of much help for a (new)
client to determine whether a disambiguation heuristic is neccessary.

I know that it can be prevented by the design of the XEP that the client
needs a 'heuristic' (heuristics can fail) for the decision algorithm for
the profile of a message stanza.

Whether it will remain possible or not to provide such a non-heuristic
way might depends on the future XEP authors. They will have to always
keep an eye on the message profile XEP and the always defined profiles
when defining new elements. So they will have the choice of joining an
existing profile and creating a new one.

The problem with an existing profile is that all clients might need an
update to recognize the new element. My point here is, that with the
<profile> element the clients have an easy way to extend their profile
decision logic. I'm unsure whether this way is easier than the way
without <profile>, but I can imagine that the way without <profile>
might become messier, if not now, maybe in future.



Robin



More information about the Standards mailing list