Hi all, Sorry about last Wednesday, unfortunately I've had a bit of a family crisis which needed a lot of attention - it should now be in hand, but my head hasn't really had the space to think until now.
On Thu, 15 Nov 2018 at 19:40, Tedd Sterr <[email protected]> wrote: > http://logs.xmpp.org/council/2018-11-14/#16:01:26 > > Kev rounds up the troops. > > *1) Roll call* > Present: Georg, Kev, Sam > Apologies: Daniel > Missing, presumed alive: Dave > > *2) Agenda* > Kev takes one look at the long list of potential items and proposes > putting everything off until next week, under the mistaken belief there > will be an extra week to work with - he's soon corrected. > Georg and Sam would prefer to get the voting started now and have a week > for on-list discussion - Kev gives in to popular opinion. > > *3) Advance XEP-0357 (Push Notifications) to DRAFT* - > https://xmpp.org/extensions/xep-0357.html > Kev: [on-list] > Sam: [on-list] (don't really have the necessary background knowledge for a > good opinion) > Georg: -1 (high priority topic hasn't been addressed; but really liked the > stripped stanza proposal) > Daniel: [pending] > Dave: [pending] > > Kev is very much in favour of allowing pushing through the real data. > Georg thinks the current XEP is much better than it was half a year ago, > but the feedback from August hasn't been addressed. > Kev thinks privacy does need to be supported, but it's useful to allow > users/deployments to decide the trade-off between utility and privacy; > Georg says a tri-state of none/stripped/full would make that possible; Sam > thinks that seems over-complicated, but supports allowing data. > Kev admits some responsibility for 0357, and should put time in, but a > time-machine might be required. > > I believe this is awaiting a bit of processing of feedback - so I'm a -1 on advancing it right now. > *4) Advance XEP-0359 (Unique and Stable Stanza IDs) to DRAFT* - > https://xmpp.org/extensions/xep-0359.html > Georg thinks the current status quo of hard-coding "you have a new > message" into the server module is non-ideal; has submitted some feedback > and would like to see it addressed, but won't block on that basis. > > I don't quite understand that - is the new message thing to do with '357? > Georg: +0 (+1 if above feedback is properly addressed) > Kev: [on-list] > Sam: [on-list] > Daniel: [pending] > Dave: [pending] > > +1 I don't particularly like the stanza-id concept, but I'll grudgingly admit it's needed. I'm a little concerned that the structure means that there's be lots of elements in the message under the same namespace which all need an explicit namespace declaration - that said, the alternative would be harder for processors to slip into stanzas on the way past, so perhaps this is the lesser of two evils. > *5) PR #692 - XEP-0060: correct "entity" to "<subscription/>"* - > https://github.com/xsf/xeps/pull/692 > Kev: [on-list] > Sam: +0 > Georg: [on-list] > Daniel: [pending] > Dave: [pending] > > +1 > *6) PR #693 - XEP-0060: Remove unused 'node' attribute on pubsub#event > item* - https://github.com/xsf/xeps/pull/693 > Kev: [on-list] > Georg: [on-list] > Sam: +0 (not confident enough with pub-sub to review it, no matter how > many times I re-read it) > Daniel: [pending] > Dave: [pending] > > Georg thinks this meeting is so productive! > > +1 > *7) PR #715 - XEP-0045: Add missing disco#info feature to example 4, 9, 78 > and 218* - https://github.com/xsf/xeps/pull/715 > Kev: [on-list] > Georg: [on-list] > Sam: +1 > Daniel: [pending] > Dave: [pending] > > +0 - this is reasonable, but I don't think it matters that much. See below. > *8) PR #716 - XEP-0030: Clarify 'disco#info' feature in 'disco#info' > responses* - https://github.com/xsf/xeps/pull/716 > Kev: [on-list] > Sam: -1 > Georg: [on-list] > Daniel: [pending] > Dave: [pending] > > Sam agrees that it's weird to always include 'disco#info' when it's > obviously supported, but doesn't see the need to modify a Final XEP and add > optional behaviour, and recommends just following the standard as written. > Jonas thinks that's the most sensible word on the subject so far. > Jonas could ensure that the feature is present in every relevant example > in the XEP, if Council so wishes. > Kev isn't keen on making non-vital changes to XEP-0030. Sam doesn't think > leaving it as-is will cause anything to break. > Georg isn't sure it's needed in all examples in all XEPs, and would rather > add a note in 0030 that the feature may not be present in examples but must > still be implemented; Sam thinks that sounds reasonable. Georg and Sam > agree this would be an editorial change, and would be happy for Editors to > just change it. Jonas requests wording - Sam provides "Note that this is > sometimes omitted in examples in the XEP series"; Georg amends that to > "Note that the disco#info feature is …" > > +1 - If we say that disco#info responses MUST include the disco#info feature, we have a MUST that has no impact on interoperability, and that's wrong. It's also not what people actually do - which demonstrates that there's no point to the requirement. > *9) Date of next* > 2018-11-21 1600 UTC > > [Note: this will be the final meeting of the current council; any > remaining votes should preferably be made before the end of the day to > allow processing by Editors.] > > *10) AOB* > Georg asks whether there were any expired votes to recast, or open votes > remaining from last week. Kev says the PR #717 vote is still open. Jonas > and Kev think the expired were already covered. [PRs #692 and #693 are the > resurrected-from-expired votes.] > > Georg has started working on the Moved XEP, but it turned out to be a huge > mess implementation-wise; will submit it to the next Council. > > *11) Close* > Thanks all. > Kev reaches end-of-file. > > > *Discussion of 'Moved' continues…* > > _______________________________________________ > 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] _______________________________________________
