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'
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <feature var='http://jabber.org/protocol/address'/>

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' />
   <body>Hello, everyone!</body>

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' />
   <body>Hello, everyone!</body>

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.

SGX/GroupMMS (last edited 2020-106 01:30:45 by Singpolyma)