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. 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). 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. :) -Justin
