If your SGX does not support sending "Group MMS" (MMS with multiple recipients) you may skip implementing this protocol.
Cheogram will use https://xmpp.org/extensions/xep-0033.html to communicate a desire for multicast to a supporting SGX backend. Here are the relevant parts:
Your SGX must respond to disco info on the main domain like so:
<iq type='result' from='some.sgx.soprani.ca' to='cheogram.com'> <query xmlns='http://jabber.org/protocol/disco#info'> ... <feature var='http://jabber.org/protocol/address'/> ... </query> </iq>
Outbound Message
When a user sends a Group MMS (via XEP0033 or via other porcelain UX such as tel1,tel2,tel3@cheogram.com addresses) Cheogram will relay a single stanza to your sgx domain like so:
<message to='some.sgx.soprani.ca' from="some\40user@cheogram.com" type="chat"> <addresses xmlns='http://jabber.org/protocol/address'> <address type='to' uri='sms:+12261234567' /> <address type='to' uri='sms:+12261234578' /> </addresses> <body>Hello, everyone!</body> </message>
Your SGX is then expected to relay this message to all listed recipients, via Group MMS if possible.
Inbound Message
When a number receives a Group MMS handled by your SGX, you should deliver it to cheogram as follows:
<message to="cheogram.com" from='+1234567890@some.sgx.soprani.ca' type="chat"> <addresses xmlns='http://jabber.org/protocol/address'> <address type='to' jid="some\40user@cheogram.com" /> <address type='to' uri='sms:+12261234578' delivered='true' /> </addresses> <body>Hello, everyone!</body> </message>
Cheogram will handle translating this to a porcelain, if needed.
You may send only one stanza for all numbers you handle which receive the same message, with `delivered` attribute unset appropriately, but it is not required.
Edge cases
The following will not come from a Cheogram porcelain, but are good to support, especially if a sender actually sends via the XEP.
If an `<address/>' tag contains attribute `delivered='true'` you MUST NOT deliver to that address. If you can send MMS to the other recipients while preserving the context that this address also got a copy, great. If not, you may return an error or degenerate to simply ignoring the element.
Besides `type='to'` there is also `type='cc'` with identical semantics from the Group MMS PoV, which an SGX SHOULD support. There is also `type='bcc'` with differing semantics which an SGX MAY support but would not really be part of Group MMS considerations (since a bcc would be sent outside of the group). There is no reason to support other types.
If a destination is specified with syntax you do not understand (bad URI) you should reply with `<jid-malformed/>` If a destination cannot be reached by you (jid on another server, etc), you should reply with `<forbidden/>` If there is a limit on number of recipients and the message goes over that, you should reply with `<not-acceptable/>`
You MAY choose to accept `<address jid='+12261234567@some.sgx.soprani.ca' />` or `<address uri='tel:+12261234567' />` as well.