moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
Code Issues Releases Wiki Activity

Added clarifications and enhancements when interacting with Multi-User Chat (MUC)

Browse Source
This commit is contained in:
Mickael Remond 2015-08-03 13:30:14 +02:00 committed by Matthew A. Miller
parent cd4726f0eb
commit f22a0a650e
1 changed files with 51 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

53
xep-0313.xml
View File

@ -27,6 +27,14 @@
</schemaloc>
&mwild;
&ksmith;
<revision>
<version>0.5</version>
<date>2016-01-20</date>
<initials>XEP Editor (mam)</initials>
<remark>
<p>Added clarifications and enhancements when interacting with Multi-User Chat (MUC) (Mickaël Rémond)</p>
</remark>
</revision>
<revision>
<version>0.4.1</version>
<date>2015-09-29</date>
@ -448,7 +456,7 @@
</section1>
<section1 topic='Business Rules' anchor='business_rules'>
<section2 topic='What To Store'>
<section2 topic='Storage and Retrieval Rules'>
<p>Different entities will have different requirements for which data are stored, as might different deployments. This section provides general rules within which a server will act. While there may be local policy restrictions that prevent archiving of some aspects discussed here, this is a RECOMMENDED baseline. A server MAY implement any subset of possible archives for JIDs it controls (although it MUST advertise support only for those JIDs that support it).</p>
<p>No requirements are placed on how a server implements its storage beyond that it has to store data sufficient to be able to comply with this document. When this document describes storage requirements (e.g. MUST NOT store more than one copy...), it refers to what would appear to have been stored in order to satisfy the query.</p>
<p>If an entity (user's server, MUC room, pubsub node, ...) rejects an incoming message (such as from an occupant not allowed to send messages to the room, a user not authorized to publish to a pubsub node, a contact blocked by the user etc.) that message should not appear in the archive for the entity that rejected it - the archive should represent what logical entities (MUC occupants, users, pubsub subscribers...) would have received, and so only contain messages accepted for delivery to such entities.</p>
@ -460,8 +468,49 @@
<section3 topic="MUC Archives">
<p>A MUC archives allows a user to view the conversation within a room. All messages sent to the room that contain a &lt;body&gt; element SHOULD be stored, as should subject change stanzas, apart from those messages that the room rejects.</p>
<p>A MUC archive MUST store each message only once (not, for example, every copy sent out to an occupant).</p>
<p>A MUC archive MUST NOT include 'private message' results (those sent directly between occupants, not shared in the room) in the results</p>
<p>A MUC archive MUST check that the user requesting the archive has the right to enter it at the time of the query and only allow access if so. In a members-only chat room, only owners, admins or members can query a room archive. In the case of open MUC rooms, the MUC archives can generally be accessed by any users (including those who have never entered the room) who do not have an affiliation of 'outcast', but a MUC archive MAY further limit access based on other criteria as part of the deployment policy. A MUC archive MAY, if it stores historical data about previous configuration states, limit the results returned to only those that the querying user would have been authorised to see at the time (e.g. it MAY limit the results to not include results while a user was an outcast).</p>
<p>When sending out the archives to a requesting client, the 'to' of the forwarded stanza MUST be empty, and the 'from' MUST be the occupant JID of the sender of the archived message.</p>
<p>A MUC archive MUST NOT include 'private message' results (those sent directly between occupants, not shared in the room) in the results</p>
<p>In the case of non-anonymous rooms or if the recipient of the MUC archive has the right to access the sender real JID at the time of the query, the archive message will use extended message information in an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with a 'jid' attribute specifying the occupant's full JID, as defined for non-anonymous room presence in &xep0045;.</p>
<example caption='Server returns MUC messages'><![CDATA[
<message id='iasd207' from='coven@chat.shakespeare.lit' to='hag66@shakespeare.lit/pda'>
<result xmlns='urn:xmpp:mam:0' queryid='g27' id='34482-21985-73620'>
<forwarded xmlns='urn:xmpp:forward:0'>
<delay xmlns='urn:xmpp:delay' stamp='2002-10-13T23:58:37Z'/>
<message xmlns="jabber:client"
from='coven@chat.shakespeare.lit/firstwitch'
id='162BEBB1-F6DB-4D9A-9BD8-CFDCC801A0B2'
type='groupchat'>
<body>Thrice the brinded cat hath mew'd.</body>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='none'
jid='witch1@shakespeare.lit'
role='participant' />
</x>
</message>
</forwarded>
</result>
</message>
<message id='iasd207' from='coven@chat.shakespeare.lit' to='hag66@shakespeare.lit/pda'>
<result xmlns='urn:xmpp:mam:0' queryid='g27' id='34482-21985-73620'>
<forwarded xmlns='urn:xmpp:forward:0'>
<delay xmlns='urn:xmpp:delay' stamp='2002-10-13T23:58:43Z'/>
<message xmlns="jabber:client"
from='coven@chat.shakespeare.lit/secondwitch'
id='90057840-30FD-4141-AA44-103EEDF218FC'
type='groupchat'>
<body>Thrice and once the hedge-pig whined.</body>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='none'
jid='witch2@shakespeare.lit'
role='participant' />
</x>
</message>
</forwarded>
</result>
</message>
]]></example>
</section3>
<section3 topic="Pubsub Archives">
<p>A PubSub service offering MAM SHOULD store each of the items published to each node. When responding to MAM requests it MUST construct the message stanza within the &lt;forwarded&gt; element in the same manner as the notifications sent to subscribers for the item, except that specifying the 'from' 'to' and 'id' attributes are OPTIONAL. Pubsub items must be returned one per message stanza (i.e. there MUST NOT be multiple &lt;item&gt; elements within the &lt;items&gt; element).</p>