[Standards] Proposed XMPP Extension: MAM Fastening Collation

Florian Schmaus flo at geekplace.eu
Wed Jan 8 16:25:48 UTC 2020


On 08.01.20 16:41, Marvin W wrote:
> I feel that we disagree and I think this is perfectly fine. We can
> explore different approaches independently and see which one works out
> better and then deprecate/reject all but one later on (after all this is
> only about accepting MAM-FC to experimental, not to Draft).

I was about to write the same, but wanted to carefully read this thread
first. However I did not found the time to revisit this thread and the
related documents, hence I am sorry in advance if I misunderstood or
missed some points.

After briefly reading this thread, it is my impression that Dave wants
to pursue a generic approach to referencing/linking/fastening messages
and the related MAM retrieval, while you argue that a use-case specific
approach is required (at least in some cases). Is that summary correct?

I also think we should simply explore and experiment with both
approaches. After all, that is what the experimental stage of XEPs is for.

> The problem is however, that XEP-0422 is adjusted to match exactly your
> approach and thus may not be suitable to other approaches. At the same
> time we are starting to require all XEPs to use XEP-0422, thus
> effectively hindering exploring other, incompatible approaches. The way
> XEP-0422 is designed also makes it impossible to have an alternative to
> it and messages that are compatible with both (because the relevant
> information is moved to be a child of the <apply-to>, thus not
> "reachable" without relying on XEP-0422).

That does read like current design of xep422 and MAM-FC (?) disallows to
explore your approach. And I'd really like to understand what is causing
this. How exactly does "requiring all XEPs to use XEP-0422" hinder
exploring other approaches? Couldn't you just add the extension of those
other approaches together with the xep422 extensions? Why does the
current design of xep422 prevent messages "that are compatible with
both" (what is both here?)?

Maybe you could
 - give an simple example how the current and proposed protocols
   prevents other approaches
 - suggest how the existing and proposed protocols could be changed so
   that we can explore the two approaches?

> I think it is important that we agree on basic structures that can be
> built upon with different approaches and to not bind every future XEP to
> a specific approach.

That sounds sensible. Although I wonder why future XEPs could not use
xep422 and $another-thing together? Again, sorry if I missed this
information in the thread.

- Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200108/759335f6/attachment.sig>


More information about the Standards mailing list