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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
