mirror of https://github.com/moparisthebest/xeps
XEP-0313: Fix indentation to be somewhat consistent
Also removes trailing whitespace in examples.
This commit is contained in:
Emmanuel Gil Peyrot
parent
21a4b3537b
commit
1a9f110832
206
xep-0313.xml
206
xep-0313.xml
|
|
@ -43,14 +43,14 @@
|
|||
<p>Update groupchat-messages-in-user-archive advice, introducing fields and disco features to make behaviour explicit in future implementations, in light of Last Call feedback.</p>
|
||||
</remark>
|
||||
</revision>
|
||||
<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.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>
|
||||
|
|
@ -163,10 +163,10 @@
|
|||
<date>2014-08-14</date>
|
||||
<initials>ka/ks</initials>
|
||||
<remark><p>Fetching current preferences,
|
||||
switch to iq-set for searching,
|
||||
switch to using a data form,
|
||||
describe how to fetch that form, remove the archived element and
|
||||
use a sentinel message instead of iq reply.</p></remark>
|
||||
switch to iq-set for searching,
|
||||
switch to using a data form,
|
||||
describe how to fetch that form, remove the archived element and
|
||||
use a sentinel message instead of iq reply.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.2</version>
|
||||
|
|
@ -230,20 +230,22 @@
|
|||
</section1>
|
||||
|
||||
<section1 topic='Message archives' anchor='archives'>
|
||||
<p>An archive contains a collection of messages relevant to a particular XMPP address, e.g. a user, MUC, pubsub node, server. Note: while a service might have many "archives" as defined here (one per JID capable of being queried) this is a conceptual distinction,
|
||||
and a server is not bound to any particular implementation or arrangement of data stores.</p>
|
||||
<p>Exactly which messages a server archives is up to implementation and deployment policy,
|
||||
<p>An archive contains a collection of messages relevant to a particular XMPP address, e.g. a user, MUC,
|
||||
pubsub node, server. Note: while a service might have many "archives" as defined here (one per JID
|
||||
capable of being queried) this is a conceptual distinction, and a server is not bound to any particular
|
||||
implementation or arrangement of data stores.</p>
|
||||
<p>Exactly which messages a server archives is up to implementation and deployment policy,
|
||||
but it is expected that all messages that hold meaningful content, rather than state changes such as Chat State Notifications, would be archived. Rules are specified later in this document.</p>
|
||||
<p>A stored message consists of at least the following pieces of information:</p>
|
||||
<ul>
|
||||
<li>A timestamp of when the message was sent (for an outgoing message) or received (for
|
||||
an incoming message).</li>
|
||||
<li>The remote JID that the stanza is to (for an outgoing message) or from (for an
|
||||
incoming message).</li>
|
||||
<li>A server-assigned UID that MUST be unpredictable and unique within the archive.</li>
|
||||
<li>The message stanza itself. The entire original stanza SHOULD be stored, but at a minimum only the &BODY; tag MUST
|
||||
be preserved (ie. the server might, at its discretion, strip certain extensions from messages before storage), in
|
||||
addition to all standard attributes of the stanza (e.g. to, from, type, id).</li>
|
||||
<li>A timestamp of when the message was sent (for an outgoing message) or received (for
|
||||
an incoming message).</li>
|
||||
<li>The remote JID that the stanza is to (for an outgoing message) or from (for an
|
||||
incoming message).</li>
|
||||
<li>A server-assigned UID that MUST be unpredictable and unique within the archive.</li>
|
||||
<li>The message stanza itself. The entire original stanza SHOULD be stored, but at a minimum only the &BODY; tag MUST
|
||||
be preserved (ie. the server might, at its discretion, strip certain extensions from messages before storage), in
|
||||
addition to all standard attributes of the stanza (e.g. to, from, type, id).</li>
|
||||
</ul>
|
||||
<p>Note that 'incoming' and 'outgoing' messages are viewed within the context of the archived JID, rather than the system as a whole. For example, if romeo@montegue.lit sent a message to juliet@capulet.lit, it would be an outgoing message in the context of archiving for Romeo, and an incoming message in the context of archiving for Juliet.</p>
|
||||
<section2 topic='Order of messages' anchor='archive_order'>
|
||||
|
|
@ -251,61 +253,61 @@
|
|||
ordering messages, as multiple messages may share the same timestamp.</p>
|
||||
</section2>
|
||||
<section2 topic='Message retention and deletion' anchor='archives_deletion'>
|
||||
<p>A server MAY impose limits on the size of an individual archive. For example a server might begin
|
||||
to discard old messages once the archive reaches a certain size, or only keep messages until they
|
||||
reach a certain age. Any such deleted messages MUST be the oldest in the archive, i.e. it is not permitted
|
||||
to create gaps or "holes" in the archive. The UIDs of deleted messages MUST NOT be reused for new messages.</p>
|
||||
<p>A server MAY impose limits on the size of an individual archive. For example a server might begin
|
||||
to discard old messages once the archive reaches a certain size, or only keep messages until they
|
||||
reach a certain age. Any such deleted messages MUST be the oldest in the archive, i.e. it is not permitted
|
||||
to create gaps or "holes" in the archive. The UIDs of deleted messages MUST NOT be reused for new messages.</p>
|
||||
|
||||
<p>However a server that wishes to remove messages from the middle of an archive, e.g. to remove accidentally transmitted
|
||||
sensitive information may omit the <message> stanza from inside the <forwarded> element or replace the
|
||||
message with an appropriate placeholder when transmitting the result in response to a query. However servers
|
||||
MUST retain the UID, timestamp and JID of the original message internally to ensure that all queries remain consistent.
|
||||
It should also be understood that clients maintaining their own local copy of the archive may still retain the original
|
||||
message locally in this case, and this protocol provides no mechanism for forcibly removing messages from any local archive
|
||||
or cache that clients may keep.</p>
|
||||
<p>However a server that wishes to remove messages from the middle of an archive, e.g. to remove accidentally transmitted
|
||||
sensitive information may omit the <message> stanza from inside the <forwarded> element or replace the
|
||||
message with an appropriate placeholder when transmitting the result in response to a query. However servers
|
||||
MUST retain the UID, timestamp and JID of the original message internally to ensure that all queries remain consistent.
|
||||
It should also be understood that clients maintaining their own local copy of the archive may still retain the original
|
||||
message locally in this case, and this protocol provides no mechanism for forcibly removing messages from any local archive
|
||||
or cache that clients may keep.</p>
|
||||
</section2>
|
||||
<section2 topic='Archiving entities' anchor='archiving_entities'>
|
||||
<p>There is no restriction on which services can expose archives, although only user and MUC archives are discussed here.</p>
|
||||
<section3 topic='User archives' anchor='archives_user'>
|
||||
<p>The most typical address is that of a user's own bare JID, within which those messages sent to or from that
|
||||
user's account would generally automatically be stored by the server. The collection
|
||||
is ordered chronologically by the time each message was sent/received.</p>
|
||||
<p>There is no restriction on which services can expose archives, although only user and MUC archives are discussed here.</p>
|
||||
<section3 topic='User archives' anchor='archives_user'>
|
||||
<p>The most typical address is that of a user's own bare JID, within which those messages sent to or from that
|
||||
user's account would generally automatically be stored by the server. The collection
|
||||
is ordered chronologically by the time each message was sent/received.</p>
|
||||
|
||||
<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>
|
||||
</section3>
|
||||
</section2>
|
||||
<section2 topic='Querying Entities' anchor='entities'>
|
||||
<p>While this document talks about 'clients' and 'servers', as these are the common cases, the querying entity (referred to as a 'client') need not be an XMPP client as defined by RFC6120, but could potentially be any type of entity, and the queried entity (referred to as a 'server') need not be an XMPP server as defined by RFC6120, although access controls might prohibit any given entity from being able to access an archive.</p>
|
||||
</section2>
|
||||
<section2 topic='Communicating the archive ID' anchor='archives_id'>
|
||||
<p>When a message is archived, the server MUST add an <stanza-id/> element as defined in &xep0359; to the message, which informs the recipient of where and under what ID the message is stored. When doing this the server MUST follow the business rules defined in XEP-0359. The 'by' attribute MUST be set to the address of the archive. For regular users that’s the bare JID of the account and for MUC that’s the bare JID of the room.</p>
|
||||
<p>Servers MUST NOT include the <stanza-id/> element in messages addressed to JIDs that do not have permissions to access the archive, such as a users’s outgoing messages to their contacts. However servers SHOULD include the element as a child of the forwarded message when using &xep0280;</p>
|
||||
<example caption='Client receives a message that has been archived'><![CDATA[
|
||||
<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>
|
||||
</section3>
|
||||
</section2>
|
||||
<section2 topic='Querying Entities' anchor='entities'>
|
||||
<p>While this document talks about 'clients' and 'servers', as these are the common cases, the querying entity (referred to as a 'client') need not be an XMPP client as defined by RFC6120, but could potentially be any type of entity, and the queried entity (referred to as a 'server') need not be an XMPP server as defined by RFC6120, although access controls might prohibit any given entity from being able to access an archive.</p>
|
||||
</section2>
|
||||
<section2 topic='Communicating the archive ID' anchor='archives_id'>
|
||||
<p>When a message is archived, the server MUST add an <stanza-id/> element as defined in &xep0359; to the message, which informs the recipient of where and under what ID the message is stored. When doing this the server MUST follow the business rules defined in XEP-0359. The 'by' attribute MUST be set to the address of the archive. For regular users that’s the bare JID of the account and for MUC that’s the bare JID of the room.</p>
|
||||
<p>Servers MUST NOT include the <stanza-id/> element in messages addressed to JIDs that do not have permissions to access the archive, such as a users’s outgoing messages to their contacts. However servers SHOULD include the element as a child of the forwarded message when using &xep0280;</p>
|
||||
<example caption='Client receives a message that has been archived'><![CDATA[
|
||||
<message to='juliet@capulet.lit/balcony'
|
||||
from='romeo@montague.lit/orchard'
|
||||
type='chat'>
|
||||
<body>Call me but love, and I'll be new baptized; Henceforth I never will be Romeo.</body>
|
||||
<stanza-id xmlns='urn:xmpp:sid:0' by='juliet@capulet.lit' id='28482-98726-73623' />
|
||||
</message>]]></example>
|
||||
<p>Note: Previous versions of this protocol did not specify any interaction with stanza-id, and clients MUST NOT interpret XEP-0359 IDs in messages as archive IDs unless the server advertises support for 'urn:xmpp:mam:2' specifically.</p>
|
||||
</section2>
|
||||
<p>Note: Previous versions of this protocol did not specify any interaction with stanza-id, and clients MUST NOT interpret XEP-0359 IDs in messages as archive IDs unless the server advertises support for 'urn:xmpp:mam:2' specifically.</p>
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Querying an archive' anchor='query'>
|
||||
<p>An entity is able to query (subject to appropriate access rights) an archive for all messages within a certain timespan, optionally
|
||||
restricting results to those to/from a particular JID. To allow limiting the results or paging
|
||||
through them a client may use &xep0059;, which MUST be supported by both the client and the server.</p>
|
||||
<p>A query consists of an &IQ; stanza of type 'set' addressed to the account or server entity hosting
|
||||
the archive, with a 'query' payload. On receiving the query, the server pushes to the client a
|
||||
series of messages in chronological order from the archive that match the client's given criteria. After the
|
||||
results it then returns the &IQ; result to indicate that the query is completed.</p>
|
||||
<p>The final &IQ; result response MUST include an RSM <set/> element, wrapped into a <fin/>
|
||||
element qualified by the 'urn:xmpp:mam:2' namespace, indicating the
|
||||
UID of the first and last message of the (possibly limited) result set. This
|
||||
allows clients to accurately page through messages.</p>
|
||||
<p>An entity is able to query (subject to appropriate access rights) an archive for all messages within a certain timespan, optionally
|
||||
restricting results to those to/from a particular JID. To allow limiting the results or paging
|
||||
through them a client may use &xep0059;, which MUST be supported by both the client and the server.</p>
|
||||
<p>A query consists of an &IQ; stanza of type 'set' addressed to the account or server entity hosting
|
||||
the archive, with a 'query' payload. On receiving the query, the server pushes to the client a
|
||||
series of messages in chronological order from the archive that match the client's given criteria. After the
|
||||
results it then returns the &IQ; result to indicate that the query is completed.</p>
|
||||
<p>The final &IQ; result response MUST include an RSM <set/> element, wrapped into a <fin/>
|
||||
element qualified by the 'urn:xmpp:mam:2' namespace, indicating the
|
||||
UID of the first and last message of the (possibly limited) result set. This
|
||||
allows clients to accurately page through messages.</p>
|
||||
<example caption='A user queries their archive for messages'><![CDATA[
|
||||
<iq type='set' id='juliet1'>
|
||||
<query xmlns='urn:xmpp:mam:2' queryid='f27' />
|
||||
|
|
@ -379,7 +381,7 @@
|
|||
</x>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
]]></example>
|
||||
<p>If (and only if) the supplied JID is a bare JID (i.e. no resource is present), then
|
||||
the server SHOULD return messages if their bare to/from address for a user archive, or from address otherwise, would match it. For example,
|
||||
if the client supplies a 'with' of "juliet@capulet.lit" a query to their own archive would also match messages to
|
||||
|
|
@ -414,7 +416,7 @@
|
|||
</x>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
]]></example>
|
||||
<example caption='Querying the archive for all messages after a certain time'><![CDATA[
|
||||
<iq type='set' id='juliet1'>
|
||||
<query xmlns='urn:xmpp:mam:2'>
|
||||
|
|
@ -428,7 +430,7 @@
|
|||
</x>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
]]></example>
|
||||
</section3>
|
||||
<section3 topic='Limiting results by id' anchor='query-limit-id'>
|
||||
<p>If the client has already seen some messages, it may choose to restrict its query to
|
||||
|
|
@ -451,7 +453,7 @@
|
|||
</x>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
]]></example>
|
||||
|
||||
<example caption='Querying the archive for all messages between two known messages'><![CDATA[
|
||||
<iq type='set' id='juliet1'>
|
||||
|
|
@ -469,7 +471,7 @@
|
|||
</x>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
]]></example>
|
||||
|
||||
<p>If the client already knows the UID of one or more messages it wants to fetch, it can use
|
||||
the 'ids' field:</p>
|
||||
|
|
@ -487,7 +489,7 @@
|
|||
</x>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
]]></example>
|
||||
|
||||
<p>If any UID requested by the client in any of the 'before-id', 'after-id' or 'ids' form fields is not present in the archive, the server MUST return an item-not-found error in response to the query.</p>
|
||||
|
||||
|
|
@ -509,7 +511,7 @@
|
|||
</x>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
]]></example>
|
||||
<p>If the server advertises that it includes groupchat messages in the archive, or it advertises that it doesn't, a client may request that they not be included by setting the 'include-groupchat' field to 'false'.</p>
|
||||
<example caption='Querying the archive and excluding groupchat messages from results'><![CDATA[
|
||||
<iq type='set' id='juliet1'>
|
||||
|
|
@ -525,7 +527,7 @@
|
|||
</x>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
]]></example>
|
||||
<p>Note that where the client doesn't specify the 'include-groupchat' field, it is implementation-defined whether groupchat messages are included in the results (see <link url='#business_rules'>Business Rules</link>). Clients MUST NOT include this field where servers don't advertise support, as the server would reject such a form.</p>
|
||||
</section3>
|
||||
<section3 topic='Retrieving form fields' anchor='query-form'>
|
||||
|
|
@ -629,7 +631,7 @@
|
|||
</forwarded>
|
||||
</result>
|
||||
</message>
|
||||
]]></example>
|
||||
]]></example>
|
||||
</section2>
|
||||
|
||||
<section2 topic='Paging through results' anchor='query-paging'>
|
||||
|
|
@ -656,7 +658,7 @@
|
|||
</set>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
]]></example>
|
||||
<p>To conserve resources, a server MAY place a reasonable limit on how many stanzas may be
|
||||
pushed to a client in one request. Whether or not the client query included a <set/> element, the server MAY simply return
|
||||
its limited results, modifying the <set/> element it returns appropriately.</p>
|
||||
|
|
@ -671,7 +673,7 @@
|
|||
</set>
|
||||
</fin>
|
||||
</iq>
|
||||
]]></example>
|
||||
]]></example>
|
||||
</section3>
|
||||
<section3 topic='Requesting pages' anchor='query-paging-request'>
|
||||
<p>The <first> and <last> elements specify the UID of the first and last returned
|
||||
|
|
@ -697,7 +699,7 @@
|
|||
</set>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
]]></example>
|
||||
<p>Note: There is no concept of an "open query", and servers MUST be prepared to receive arbitrary page requests at any time.</p>
|
||||
<p>RSM does not define the behaviour of including both <before> and <after> in the same request. To retrieve a range of items between two known ids, use before-id and after-id in the query form instead.</p>
|
||||
<p>If the UID contained within an <after> or <before> element is not present in the archive, the server MUST return an item-not-found error in response to the query.</p>
|
||||
|
|
@ -707,7 +709,7 @@
|
|||
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
||||
</error>
|
||||
</iq>
|
||||
]]></example>
|
||||
]]></example>
|
||||
<p>When the results returned by the server are complete (that is: when they have not been limited by the maximum size of the result page (either as specified or enforced by the server)), the server MUST include a 'complete' attribute on the <fin> element, with a value of 'true'; this informs the client that it doesn't need to perform further paging to retreive the requested data. If it is not the last page of the result set, the server MUST either omit the 'complete' attribute, or give it a value of 'false'.</p>
|
||||
<example caption='Server completes a result with the last page of messages'><![CDATA[
|
||||
<!-- result messages -->
|
||||
|
|
@ -720,7 +722,7 @@
|
|||
</set>
|
||||
</fin>
|
||||
</iq>
|
||||
]]></example>
|
||||
]]></example>
|
||||
<p>Sometimes (e.g. due to network or storage partitioning, or other transient errors) the server might return results to a client that are unstable (e.g. they might later change in sequence or content). In such a situation the server MUST stamp the <fin> element with a 'stable' attribute with a value of 'false'. If the server knows that the data it's serving are stable it MUST either stamp a 'stable' attribute with a value of 'true', or no such attribute. An example of when unstable might legitimately be returned is if the MAM service uses a clustered data store and a query covers a time period for which the data store has not yet converged; it the server could return best-guess results and tell the client that they may be unstable. A client SHOULD NOT cache unstable results long-term without later confirming (by reissuing appropriate queries) that they have become stable.</p>
|
||||
</section3>
|
||||
<section3 topic='Requesting the last page'>
|
||||
|
|
@ -738,7 +740,7 @@
|
|||
</set>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
]]></example>
|
||||
<p>Within the returned page, all results are still in chronological order, that is, the first result you receive will be the oldest item in the page, and the last result you receive will be the last item in the archive.</p>
|
||||
</section3>
|
||||
<section3 topic='Flipped pages' anchor='query-paging-flip'>
|
||||
|
|
@ -760,7 +762,7 @@
|
|||
<flip-page/>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
]]></example>
|
||||
<p>It is important to note that flipping a page does not affect what results are returned in response to the query. It only affects the
|
||||
order in which they are transmitted from the server to the client.</p>
|
||||
<p>A client that wishes to use flipped pages MUST ensure that the server advertises the 'urn:xmpp:mam:2#extended' feature.</p>
|
||||
|
|
@ -779,7 +781,7 @@
|
|||
<iq type='get' id='jui8921rr9'>
|
||||
<metadata xmlns='urn:xmpp:mam:2'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
]]></example>
|
||||
|
||||
<example caption='Server returns archive metadata'><![CDATA[
|
||||
<iq type='result' id='jui8921rr9'>
|
||||
|
|
@ -788,7 +790,7 @@
|
|||
<end id='b21lZ2Eg' timestamp='2020-04-20T14:34:21Z' />
|
||||
</metadata>
|
||||
</iq>
|
||||
]]></example>
|
||||
]]></example>
|
||||
|
||||
<p>The server response includes a <metadata/> element containing information about the archive. This element MUST include <start/> and <end/>
|
||||
elements, which each have an 'id' and XEP-0082 formatted 'timestamp of the first and last messages in the archive respectively.</p>
|
||||
|
|
@ -796,24 +798,24 @@
|
|||
|
||||
<section1 topic='Business Rules' anchor='business_rules'>
|
||||
<section2 topic='Storage and Retrieval Rules' anchor='business-storeret'>
|
||||
<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>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>
|
||||
<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 <body> element. A server MAY include additional non-conversation messages. A server MAY include messages of type 'headline', but this is not generally suggested.</p>
|
||||
<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 <body> element. A server MAY include additional non-conversation messages. A server MAY include messages of type 'headline', but this is not generally suggested.</p>
|
||||
<p>Previous versions of this specification stated that a server SHOULD also include messages of type 'groupchat' that have a <body> - however many deployments did not follow this (although some did). This advice has now been dropped, and servers MAY include groupchat messages in their archives. Whether a server stores groupchat messages or not is now left as an implementation (or deployment) decision. Whether a client wants to receive groupchat messages in results can be signalled with the 'include-groupchat' field (if supported by the server - see <link url='#support'>Determining support</link>) - where the server doesn't support this field, or where a client doesn't specify it in the query, whether groupchat messages are included in the result is implementation-defined; this allows existing deployments to not break with the introduction of the 'include-groupchat' query field in a later version of this specification, but it is RECOMMENDED that all client implementations of the current version of this specification always include the field where the server supports it, and RECOMMENDED that servers support it.</p>
|
||||
<p>At a minimum, the server MUST store the <body> 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>At a minimum, the server MUST store the <body> 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>A server MAY choose not to deliver offline messages to a client that has already queried their MAM archive and received the archived copies of those messages that would otherwise be delivered - while not required of an implementation, this is helpful to avoid duplicate messages for clients, so is suggested.</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 <body> 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 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 <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> 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 <x> element from MUC messages (as MUC rooms are not required to do this).</p>
|
||||
<example caption='Server returns MUC messages'><![CDATA[
|
||||
</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 <body> 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 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 <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> 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 <x> element from MUC messages (as MUC rooms are not required to do this).</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:2' queryid='g27' id='34482-21985-73620'>
|
||||
<forwarded xmlns='urn:xmpp:forward:0'>
|
||||
|
|
@ -851,7 +853,7 @@
|
|||
</forwarded>
|
||||
</result>
|
||||
</message>
|
||||
]]></example>
|
||||
]]></example>
|
||||
</section3>
|
||||
<section3 topic='Pubsub archives' anchor='business-storeret-pubsub-archives'>
|
||||
<p>
|
||||
|
|
@ -942,9 +944,9 @@
|
|||
access. For example authorized parties for a user's archive would likely include
|
||||
just the user, and a MUC archive for a private room might be restricted
|
||||
to room members. An implementation MAY choose to allow access to any archive
|
||||
by server administrators. If a client
|
||||
requests access to an archive it does not have permissions for the server MUST
|
||||
return an iq with type error, and the error condition SHOULD be 'forbidden'.</p>
|
||||
by server administrators. If a client requests access to an archive it does not
|
||||
have permissions for the server MUST return an iq with type error, and the error
|
||||
condition SHOULD be 'forbidden'.</p>
|
||||
<p>A server SHOULD provide a mechanism for a user to disable archiving of
|
||||
messages with all or specific contacts, such as via the configuration
|
||||
protocol described in &xep0441;. This allows the user to prevent the
|
||||
|
|
|
|||
Loading…
Reference in New Issue