[Standards] eJabberD MUC Invitation Bug

[Sergei Golovan]

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.

>
> The message that's sent out from eJabberD looks like:
>        <message from="jdev at conference.jabber.org"
>        to="cmullins at coversant.net/SoapBox Communicator"
>        type="normal"
>        xml:lang="en-us"> [...]
>
> The "type=normal" attribute is violating section 7.5 of the XEP. The way
> the XEP is worded, the client sends the message to the room, and the
> room then adds in a few elements to the message and forwards it on to
> the recipient. The "type" attribute shouldn't be on there...

It seems so, but I would fix XEP. It contradicts (not literally
probably) RFC 3921.

>
> This causes our SDK not to match the packet as an Invitation message,
> but instead matches it as a Normal message packet. This in turn causes
> invitations from eJabberD to be broken...
>
> Due to the "MUST NOT" in the XEP, our matching code for
> InvitationMessage actually checks for the presence of the attribute, and
> fails to match on the packet if it's there.

Don't check the invitations this way. Check the specific invitation
XML inside the messages. (By the way, do you treat all messages
without type attribute as invites?)

-- 
Sergei Golovan