https://logs.xmpp.org/council/2021-08-11#2021-08-11-9c0056346fa591e6
1) Roll Call Emerging from a horrifying reading, Jonas opens the meeting a tad late. Present: Jonas, Zash, Daniel, Georg 2) Agenda Bashing None. 3) Editor’s Update - Pubsub Caching Hints have been accepted as New as per council vote - The Moved 2.0 protoxep has been merged into '283 and authorship has been transferred to MattJ as discussed. 4) Items for Voting None. 5) Pending Votes - Everyone except Dave on ProtoXEP https://xmpp.org/extensions/inbox/disco-feature-attachment.html A lot of discussion following up on the mailing list thread and the discussion in xsf@. An opinionated summary by Jonas is available in the thread [1]. Referring to the discussion in xsf@ [2], Jonas changes his vote to -1, with the following rationale, quoted verbatimly: > - Any disco#info feature needs to be backed by some kind of implementation text > - Even though for some combination of features the implementation may be obvious, it should still be written down somewhere, because obvious doesn't really work > - If there is text backing the implementation of a combination of two features, that is the obvious place to declare a disco#info feature string > - If there is a place where a disco#info string is written down which needs to be read by implementors anyway, there is no benefit from having a way to construct such a string; an opaque string match is required in the implementation anyway. > and to bring this to the point which IMO makes this -1-worthy: it misleads implementations and specification authors to think that they can just slap together two feature strings and it will be immediately clear what is supposed to happen there. Daniel notes that while Jonas' concerns may be valid and he even shares them, they may not completely warrant a -1 from his perspective (while respecting Jonas' choice). Georg adds that introducing a semantic separator in an opaque string is problematic. Jonas explicitly acknowledges that there is a problem to be solved regarding the discoverability of optional RSM for various protocols. He changes his vote to -0. Dave, however, is convinced of the arguments and changes his vote to -1, with the suggestion to resolve this by explicitly writing down the missing interactions and feature combinations for RSM + * in separate documents to solve the problem "for now". With that, the ProtoXEP is vetoed (but see [1]). 6) Date of Next Everyone in for +1w. 7) AOB None. 8) Ite Meeting Est Thanks everyone. [1]: https://mail.jabber.org/pipermail/standards/2021-August/038490.html [2]: https://logs.xmpp.org/xsf/2021-08-09#2021-08-09-4407b454a06caebc ff
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
