From a4695de082f0f0b189baec72b14990646372ac7a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 28 Jan 2020 18:34:29 +0100 Subject: [PATCH] Accept mamfc as XEP-0427 --- xep-0427.xml | 209 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 209 insertions(+) create mode 100644 xep-0427.xml diff --git a/xep-0427.xml b/xep-0427.xml new file mode 100644 index 00000000..c9bf781a --- /dev/null +++ b/xep-0427.xml @@ -0,0 +1,209 @@ + + +%ents; + + +]> + + +
+ MAM Fastening Collation + This specification proposes a mechanism by which MAM results containing fastenings can be collated effectively. + &LEGALNOTICE; + 0427 + Experimental + Standards Track + Standards + + XMPP Core + XEP-0422 + XEP-0313 + + + + mamfc + &dcridland; + &ksmithisode; + + 0.1.0 + 2020-01-28 + XEP Editor (jsc) + Accepted by vote of Council on 2020-01-02. + + + 0.0.1 + 2019-12-19 + dwd + +
    +
  • Initial Revision
    • +
+ + +
+ + +

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, &xep0422;, 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 &nsx;

+

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 &xep0422; et al.

+ + + + + +

Support for this protocol is advertised by the Service Discovery protocol defined in &xep0030; using a feature + of &ns;.

+ + +

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 &xep0422; 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="&nsx;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="&nsx;reaction:0"/>, but the fastening summary could be + <reaction xmlns="&nsx;reaction:0" emoji="Ὁ"/>

+

The summary information against each parent message consists of, for each fastening summary:

+
    +
  • The fastening summary itself.
    • +
  • A count of the number of fastenings with this summary fastened to the parent message.
    • +
  • The full fastening for the last fastening received for the parent message.
    • +
+ + + + + + +

This specification adds an additional field to the form defined in &xep0313; with the field name + "{&ns;}summary". This may have only the following values (unless of course further values are advertised + by a future specification):

+
    +
  • simplified
    • +
  • full
    • +
  • collate
    • +
  • fastenings
    • +
+ + +

The <result/> element defined in &xep0313; is extended by adding zero or more additional elements with + a local name of "applied", qualified by the "&ns;" 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 &xep0359;) 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 "&ns;", 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:

+
    +
  • Message Delivery Receipts: &xep0184; "ack messages" - those containing a <received/> element - are + considered to be equivalent to a fastening containing just the <received/> element, applying to the message + given by the "id" attribute.
    • +
  • Chat Markers: &xep0333; A Chat Marker is similarly equivalent to a fastening containing the Chat Marker, but + applying to all previous messages (since previous messages can be assumed to have been read and or displayed, + etc).
    • +
+

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!

+ + + + + + + + + + + + + + + + + + + + + ]]> + + + + +

This specification imposes substantial workload for servers.

+ + + +

This XEP requires no interaction with &IANA;.

+ + + +

None.

+ + + +

The authors wish to share any credit with many members of the community, including Marvin Wissfield.

+ + +