2009/10/27 Justin Karneges <[email protected]>: > On Monday 26 October 2009 23:03:15 Nathan Fritz wrote: >> 3) XEP-0226: Message Stanza Profiles, Issue Last Call? >> >> A consensus is reached on issuing a last call on XEP-0226, although >> Matthew Wild notes that he finds the XEP pointless. > > I'll explain the rationale for the message stanza profiles XEP. > > First, I believe ambiguity in message stanza processing is a long-standing > protocol issue that needs to be solved. I initially wrote about it in 2004: > http://mail.jabber.org/pipermail/standards/2004-August/006001.html > > I was confused about how you're supposed to know if a message with extended > content is supposed to be handled as an IM with an "attachment" or simply as > a non-IM event. For example, <body> with x:oob is an IM with a URL > attachment, <body> with x:data is an XData form only (body text is for > fallback), and <body> with IBB is an IBB packet only (body text could be > fallback, but probably shouldn't be there at all). > > You would never, ever present the latter stanza to the user as an IM with an > IBB attachment. We get by today thanks to everyone's common sense. :) > However, the "monstrosity" stanza in XEP-0226 should be convincing enough > that we have a spec problem. The stanza is not illegal, yet processing of > that stanza among various implementations is surely indeterministic. >
The example stanza indeed doesn't look pretty. However just beneath it the XEP describes all the different pieces of information in it, and how they should be handled, which all seems common sense to me :) Anyway, I've read your rationale from 2004, I see why the XEP might be useful to combat a few corner cases. I'm not against it, just wasn't sure what it was making so much of a fuss about. > Second, I believe clearing this up could simplify code. Most XMPP software > does stanza processing using handlers and filters. It is easy to match IQ > stanzas to their handlers. However, for message stanzas you need more > sophisticated filtering due to the potential of mixed content. I suspect > most code out there doesn't actually support processing, say, a pubsub event > and an IBB chunk in the same message stanza. More likely, a filter for one > of the content types "wins" in some implementation-specific way (e.g. because > that filter acts first). > Indeed, this I'd say is a client bug though. If specifying how they should do it is going to make them do it properly, so be it. > Quoting the Implementation Notes section of the XEP: > > "Since each message is unambiguously determined to be of a specific profile, > implementations that use filtering to pass message stanzas to an appropriate > handler (a very common XMPP implementation approach) need not be concerned > with the filtering order. This is because only one handler should ever match > on the filter expression." > > The point being, that message stanzas could be matched to their handler with > similar exactness that we enjoy with IQs. Again, maybe common sense says > this is already possible, but as an XMPP implementor I'd feel a lot better if > it were in writing. :) > Ok :) Matthew
