On 12.07.2018 12:39, Kevin Smith wrote: > On 12 Jul 2018, at 11:23, Matthew Wild <mwi...@gmail.com> wrote: >> >> On 11 July 2018 at 18:25, Florian Schmaus <f...@geekplace.eu> wrote: >>> On 11.07.2018 18:01, Matthew Wild wrote: >>>> On 11 July 2018 at 16:33, Florian Schmaus <f...@geekplace.eu> wrote: >>>>> I recently submitted PR #672 to the xeps repo >>>>> >>>>> https://github.com/xsf/xeps/pull/672 >>>>> >>>>> to make users of RSM, like MAM, aware whether the result is exact or >>>>> not. It received some scepticism from the council members in today's >>>>> council meeting. I am to blame here as I thought the abstract motivation >>>>> in the commit message was enough. It appears it wasn't. >>>>> >>>>> While I think multiple applications could exploit that information, my >>>>> particular motivation was MAM. Consider the scenario where you have a >>>>> master archive and a local archive. The local archive may have multiple >>>>> holes at unknown locations. Now you want to sync your local archive from >>>>> the master using MAM/RSM. >>>> >>>> I'm not keen on this solution for the premise you've given. >>>> >>>> I don't believe that when using MAM correctly you would ever end up >>>> with "holes at unknown locations" in your local archive. I don't think >>>> that encouraging people to use a "bisection algorithm" is the right >>>> thing to do. >>> >>> So you don't want MAM users to be able to efficiently sync archives with >>> multiple holes by a simple change because you do not want MAM to be used >>> in scenarios where this could happen? >> >> Just adding this flag will not make servers implement it, so it's >> going to add code and still need a fallback. > > And, as specified (optional but with no default or meaning for a missing > flag) it seems unhelpful
As Georg mentioned yesterday, the default is exact="maybe". There is also a sentence explaining the semantic of the missing hint: https://github.com/xsf/xeps/pull/672/files#diff-fd691aeb84210578723b940e9881ab7eR200 > and as it adds a SHOULD, in a Draft XEP, with no namespace bump or > discovery, it’s adding ambiguity and confusion.. I don't think that this is true, but we certainly can talk about making it just a recommendation if it is a blocker. - Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
