On 12 July 2018 at 12:24, Florian Schmaus <[email protected]> wrote: > On 12.07.2018 12:39, Kevin Smith wrote: > > On 12 Jul 2018, at 11:23, Matthew Wild <[email protected]> wrote: > >> > >> On 11 July 2018 at 18:25, Florian Schmaus <[email protected]> wrote: > >>> On 11.07.2018 18:01, Matthew Wild wrote: > >>>> On 11 July 2018 at 16:33, Florian Schmaus <[email protected]> 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. > > There's no difference.
>From RFC 2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. > - Florian > > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ > >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
