[Standards] eJabberD MUC Invitation Bug

[Rachel Blackman]

> 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  
> attribute.

+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/