[Standards] eJabberD MUC Invitation Bug
rcb at ceruleanstudios.com
Wed Apr 25 12:30:56 CDT 2007
> On 4/25/07, Chris Mullins <chris.mullins at coversant.net> wrote:
>> It looks like eJabberD (as running on Jabber.Org) is sending out
>> incorrect Invitation messages to MUC rooms.
>> XEP 0045 says (section 7.5):
>> "the message MUST NOT possess a 'type' attribute"
> I would say that it's a bug in XEP-0045. RFC-3921 clearly says that
> the absence of type attribute is equivalent to type 'normal' (citing
> from section 2.1.1): (if an application receives a message with no
> 'type' attribute or the application does not understand the value of
> the 'type' attribute provided, it MUST consider the message to be of
> type "normal" (i.e., "normal" is the default).
> So, it isn't reasonable to require signalling by omitting type
+1 to this. I think all debating aside, the simple answer is that
MUC should be updated to clarify that it must be a message of type
'normal' -- whether stated explicitly, or implied by the omission of
any other type attribute.
There's no real design reason to require the type attribute to be
omitted that I can see, anyway. Having it type normal makes sense,
as if someone doesn't support the invitations protocol, then you get
the plaintext form of the invite. I suspect this was the original
intent -- i.e., 'type' must be the default form -- not that it is
required to be *omitted* entirely.
Changing the XEP to basically say it must be a message stanza of type
'normal' (whether explicit or implied) clarifies the use case for
everyone, eliminates the bug for Chris Mullins (by eliminating the
RFC-breaking element of the XEP and allowing them to retain strict
compliance with the XEP without having to do something that's
arguably broken), and should basically fix everything. :)
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/
More information about the Standards