moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 15:18:51 -05:00
Code Issues Releases Wiki Activity

XEP-0313: Editorial: Missing paragraph FULL STOP

Browse Source
This commit is contained in:
Kim Alvefur 2021-09-24 16:13:40 +02:00
parent 52534c62e0
commit 0836bf6d36
1 changed files with 12 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
xep-0313.xml
View File

@ -29,6 +29,14 @@
</schemaloc>
&mwild;
&ksmith;
<revision>
<version>0.7.5</version>
<date>2021-09-24</date>
<initials>ka</initials>
<remark>
<p>End some sentences with full stop.</p>
</remark>
</revision>
<revision>
<version>0.7.4</version>
<date>2021-08-23</date>
@ -252,7 +260,7 @@
<p>Servers that expose archive messages of sent/received messages on behalf of local users MUST expose these archives to the user on the user's bare JID.</p>
</section3>
<section3 topic='MUC archives' anchor='archives_muc'>
<p>A MUC service allowing MAM queries for a room MUST expose the MAM archive on the room's bare JID</p>
<p>A MUC service allowing MAM queries for a room MUST expose the MAM archive on the room's bare JID.</p>
</section3>
</section2>
<section2 topic='Querying Entities' anchor='entities'>
@ -521,7 +529,7 @@
</query>
</iq>
]]></example>
<p>Note that as the 'with', 'start' and 'end' fields MUST be implemented by servers, clients are able to submit forms using combinations of only these fields without needing to first fetch the form from the server and the types of these fields MUST be 'jid-single', 'text-single' and 'text-single' respectively. A server MUST NOT rely on a client having first requested the form before submitting queries</p>
<p>Note that as the 'with', 'start' and 'end' fields MUST be implemented by servers, clients are able to submit forms using combinations of only these fields without needing to first fetch the form from the server and the types of these fields MUST be 'jid-single', 'text-single' and 'text-single' respectively. A server MUST NOT rely on a client having first requested the form before submitting queries.</p>
<p>If a client includes a form field that the server does not recognise, the server MUST respond with a 'feature-not-implemented' error.</p>
</section3>
</section2>
@ -743,12 +751,12 @@
<section3 topic="User Archives" anchor='business-storeret-user-archives'>
<p>A user archive is anticipated to provide the user with the ability to access their prior conversations. To this end, a server SHOULD include in a user archive all of the messages a user sends or receives of type 'normal' or 'chat' that contain a &lt;body&gt; element. A server SHOULD also include messages of type 'groupchat' that have a &lt;body&gt;, but where such history is accessible through another method (e.g. through an archive on the MUC JID), a server MAY exclude these from the archive. A server MAY include additional non-conversation messages. A server MAY include messages of type 'headline', but this is not generally suggested.</p>
<p>At a minimum, the server MUST store the &lt;body&gt; elements of a stanza. It is suggested that other elements that are used in a given deployment to supplement conversations (e.g. XHTML-IM payloads) are also stored. Other elements MAY be stored.</p>
<p>If a server supports mechanisms that multiply copies of a stanza (e.g. Carbons, or forking a stanza to a bare JID), it MUST store such a staza within a given archive only once, irrespective of multiple connected clients receiving copies</p>
<p>If a server supports mechanisms that multiply copies of a stanza (e.g. Carbons, or forking a stanza to a bare JID), it MUST store such a staza within a given archive only once, irrespective of multiple connected clients receiving copies.</p>
</section3>
<section3 topic="MUC Archives" anchor='business-storeret-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 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 forwarded stanza MUST NOT have a 'to' attribute, and the 'from' MUST be the occupant JID of the sender of the archived message.</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;. The archiving entity MUST strip any pre-existing &lt;x&gt; element from MUC messages (as MUC rooms are not required to do this).</p>