http://logs.xmpp.org/council/2019-02-27#2019-02-27-9be2f6891157626f
1) Role Call Present: Dave, Jonas, Georg, Link Apologies: Kev 2) Agenda Bashing Dave failed to get an agenda together, but thinks there are some ProtoXEPs or something - Jonas is not aware of any, but notes there are a bunch of PRs labelled 'Needs Council'. Dave sees PRs #752, #758, and #760; Georg points out that #752 was already voted on and vetoed. 3a) PR #758 - XEP-0060: Expose pubsub#access_model and pubsub#publish_model - https://github.com/xsf/xeps/pull/758 Jonas assumes this is still optional, so that existing services aren't suddenly non-compliant; Link confirms. Georg sees that this is adding two new fields, but without a description; Link says there is a very short description in the 'label' attribute; Dave says it updates the registration and includes a short description, and would argue the description is long enough given the values involved. Georg asks whether the description is non-normative, and the fields could be filled with arbitrary values other than the standard ones; Dave questions whether it's necessary to explicitly tell implementers that, though it could be argued any value is a valid access mode as people have invented new ones before. Georg knows of a client library that throws exceptions on unknown field values - Link knows of more than one - Dave and Jonas think that's more a problem with the library. Georg would be '1 happier' if it would explicitly reference the allowed values; Jonas is firmly against that - could state that it's about the access/publish model, but listing the allowed values should be done where those are defined (and new XEPs could define new models); Georg reiterates that he said 'reference,' not 'list.' Jonas: +1 (I think) Link: +1 (enables very valid usecases) Dave: +1 (this looks straightforward and painless) Georg: +0 Kev: [pending] 3b) PR #760 - XEP-0045: Add avatar support using XEP-0084 - https://github.com/xsf/xeps/pull/760 Georg asks whether XEP-0084 is one of the Avatar XEPs to be retained long-term - Link says it is. Link explains that a previous proposal based on XEP-0153 (vCard-Based Avatars) was rejected, so this one is based on a long-term PEP-only solution. Jonas says it looks good at first glance, and asks if there is a deployment - Link mentions an as yet unpublished Prosody module. Dave asks if this is adding a pub-sub service to MUC rooms - Link confirms that's what it does; basing it on XEP-0084 means both XEP-0054 (vcard-temp) and XEP-0153 can then be deprecated (finally!) Jonas suggests making it clearer that a full-blown pub-sub service on a MUC isn't expected, merely the specific use-cases outlined. Dave thinks this needs more than a quick vote and would like to see considerable discussion from implementers first; others concur. Georg asks whether this is the same as PEP on a MUC JID instead of an account JID - Link explains that it requires fewer features and just borrows the pub-sub elements to support XEP-0084 on a MUC. Link: +1 (l'auteur) Dave: -1 (squeezing Pubsub/PEP into a MUC room needs a lot more than just a quick vote by Council - would like to see considerable discussion on the list from implementors first) Jonas: -1 (in favour of list discussion; at the very least, this should clearly spell out which subset of XEP-0060 is required) Georg: -1 (agreed to the call to list discussion) Kev: [pending] 4) Voting Catch-Up Dave notes there are two outstanding votes: XMPP Over RELOAD (XOR), and E2E Authentication in XMPP (EAX). Jonas still doesn't know a lot about RELOAD, but doesn't see anything which should block the move to Experimental, and votes +1 for XOR. Dave sees no reason to block them, and votes +1 for both XOR and EAX. Link votes +1 for EAX (also wants to see more X86-style short names); Georg asks where the "NOP" XEP is. Georg checks that XOR is the same as the previous submission with the XSF-CA parts removed - the author confirms it is, and with a few typos fixed. Georg votes +1 for XOR. 5) AOB Georg mentions the (long expired) Last Call on Compliance Suites 2019 - Jonas blames the Editor; Georg would like to add the specific use of XEP-0066 (Out of Band Data) for inline images, since the CS should reflect current best practices. Dave suggests adding it to next week's agenda. 6) Next Meeting 2019-03-06 1600 UTC 7) Close Thanks all. Discussion of implementing "RELOAD" continues…
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
