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
