In XMPP, all messages are not equal. Some are semantically actual human messages; these are referred to in this document as "instant messages". Others are ancillary messages - reactions, receipts, and so on - that are useful and important, but do not conform to the concept of an instant message in the sense that a user might reasonably expect.
Fastenings, Message Fastening (XEP-0422) [1], provides a generic mechanism for a sending entity to indicate that a particular message is associated closely to an instant message. But in doing so, this presents the problem that if many messages are not in fact actual human messages, an archive query might end up downloading dozens or even hundreds of messages in order to present just a handful of actual instant messages to the user. Much of the information downloaded is not required.
For example, to display a message, a client may need to download all the "likes" for it - whereas a simply number of likes might be sufficient for most users' needs.
This specification tackles the problem by allowing these to be filtered, collated, or presented in full depending on the needs of the client. The client now downloads just the instant messages from the archive, and any likes, reactions, or receipts are simply summarized.
Because this document defines mechanisms for dealing generically with potential types of fastenings, it does not offer any real examples of actual fastenings that might be used.
Instead, example fastenings are used within an XML namespace prefixed by urn:example:
Pseudo-fastenings are messages that are semantically equivalent to fastenings, but use a different syntax, see Pseudo Fastenings.
Nomenclature used for instant messages versus ancillary messages will need to be adjusted to make it consistent with Message Fastening (XEP-0422) [1] et al.
Support for this protocol is advertised by the Service Discovery protocol defined in Service Discovery (XEP-0030) [2] using a feature
of urn:xmpp:mamfc:0.
This specification provides for four types of summary listing.
The first form, "simplified", is the default, and essentially represents the status quo. MAM queries
behave as if the archive contains only traditional IM traffic. No summary is provided.
The second form, "full", presents every message stanza in the results, including all fastenings,
errors, and so on.
The third form, "collate", presents each traditional IM message, as "simplified", but within
the result includes summary information about the fastenings (and pseudo-fastenings) encountered.
Finally a fourth form, "fastenings", returns only the fastenings for a particular message.
The "collate" form is the bulk of the specification presented herein.
The <apply-to/> element of Message Fastening (XEP-0422) [1] contains a number of fastening elements. These in turn consist of a qualified element, with a number of attributes, and potentially some content within the element.
This specification refers to the qualified name (the tuple of XML namespace and local-name) as the "fastening type" (represented as an XML element herein), and the top-level element (including attributes and their values), as the "fastening summary".
For example, a hypothetical edit fastening type might be <edit xmlns="urn:example:edit:0"/>, and that would
be the fastening summary as well. The full fastening would include any children (text or further XML elements)
of the top-level element. But a hypothetical reaction fastening type might be
<reaction xmlns="urn:example:reaction:0"/>, but the fastening summary could be
<reaction xmlns="urn:example:reaction:0" emoji="Ὁ"/>
The summary information against each parent message consists of, for each fastening summary:
This specification adds an additional field to the form defined in Message Archive Management (XEP-0313) [3] with the field name
"{urn:xmpp:mamfc:0}summary". This may have only the following values (unless of course further values are advertised
by a future specification):
The <result/> element defined in Message Archive Management (XEP-0313) [3] is extended by adding zero or more additional elements with
a local name of "applied", qualified by the "urn:xmpp:mamfc:0" namespace.
Each <applied/> element is associated with precisely one fastening summary.
This element contains, as its first child element, the full fastening for the last fastening received by the
server for the parent message. This is not included for "shell" fastenings, which are untyped.
There is a "count" attribute, consisting of an integral count of the fastenings with the same summary
as the first child element (or the count of shell fastenings when this is not included). This count, if absent,
defaults to 1. For "shell" fastenings, the attribute "shell" is set to true (or another value
with the same semantics for an XML boolean).
The <applied/> elements are only included in the <result/> element when the requested
summary type is "collate".
The latest archive id can usually be deduced either from the last message stanza received (and its stanza-id,
see Unique and Stable Stanza IDs (XEP-0359) [4]) or by the id attribute of the last <result/> element from a query extending to the
latest message.
Since this specification can cause the latest message to be only in a summarized form when presented in the
archive, it also adds an additional element to the <fin/> element which terminates the query, to
indicate the latest id held in the archive (which may be that of a fastening).
This element, qualified by the "urn:xmpp:mamfc:0", has the local name of "latest" and a single attribute,
"id", containing the latest archive id.
A MAM query where the MAM summary type is "collate", and where "start" and "end" (or
the RSM <after/> element) would exclude the parent message but include the fastening, then the MAM
result is sent with the <forwarded/> element omitted but the summary present (including all
fastenings, not just those that have changed).
A number of previous specifications exist that - if they were rewritten today - might use fastenings.
For the purposes of this specification, it is convenient to treat these as pseudo-fastenings, behaving as if they were a fastening for the purposes of the "collate" and "fastenings" summary types.
This specification defines two such types. Both MUST be supported by servers:
<received/> element - are
considered to be equivalent to a fastening containing just the <received/> element, applying to the message
given by the "id" attribute.In both cases, the fastening summary SHOULD omit the id attribute.
A firm TODO; contributions are welcome - and a good test of whether I've written the rest right!
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="urn:xmpp:mamfc:0" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="applied" type="mamfc:appliedType" xmlns:mamfc="urn:xmpp:mamfc:0"/>
<xs:complexType name="appliedType">
<xs:sequence>
<xs:any minOccurs="0" maxOccurs="1"/>
<!-- Fastening summary, absent when shell is true -->
</xs:sequence>
<xs:attribute type="xs:positiveInteger" name="count" default="1"/>
<xs:attribute type="xs:boolean" name="shell" default="false"/>
</xs:complexType>
<xs:element name="latest" type="mamfc:latestType" xmlns:mamfc="urn:xmpp:mamfc:0"/>
<xs:complexType name="latestType">
<xs:attribute type="xs:string"/>
</xs:complexType>
</xs:schema>
This specification imposes substantial workload for servers.
This XEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [7].
None.
The authors wish to share any credit with many members of the community, including Marvin Wissfield.
This document in other formats: XML PDF
This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF).
Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.
## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##
In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.
This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).
The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.
Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.
Errata can be sent to <editor@xmpp.org>.
The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
1. XEP-0422: Message Fastening <https://xmpp.org/extensions/xep-0422.html>.
2. XEP-0030: Service Discovery <https://xmpp.org/extensions/xep-0030.html>.
3. XEP-0313: Message Archive Management <https://xmpp.org/extensions/xep-0313.html>.
4. XEP-0359: Unique and Stable Stanza IDs <https://xmpp.org/extensions/xep-0359.html>.
5. XEP-0184: Message Delivery Receipts <https://xmpp.org/extensions/xep-0184.html>.
6. XEP-0333: Chat Markers <https://xmpp.org/extensions/xep-0333.html>.
7. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/
END