http://logs.xmpp.org/council/2019-10-09?p=h#2019-10-09-90b52b87bf5531f9
1) Roll Call Present: Link, Jonas, Georg, Dave, Kev 2) Agenda Bashing PR #840 is noted. 3a) Proposed XMPP Extension: Message Retraction - https://xmpp.org/extensions/inbox/message-retraction.html Georg: [on-list] Jonas: [on-list] Link: [on-list] Dave: +1 (willing to be told I'm wrong later) Kev: [pending] 3b) PR #840 - XEP-0060: Clarify unlimited behaviour for node config - https://github.com/xsf/xeps/pull/840 Jonas is unsure if this needs a feature. Dave clarifies that this is suggesting the use of the infinity symbol as a legal value - Pep suggests it might be a placeholder, and Council could decide on a replacement - Dave says that's not something Council should really be doing. Dave: -1 (having "-1" or empty seems sane for unlimited, but not novel unicode glyphs) Georg: -1 (agree with Dave; also don't understand the implied semantics of that value) Link: -1 (indicating an arbitrarily high value wouldn't be nice) Jonas: -1 (text needs to be clearer on the actual value for "use the server limit") Kev: -1 (for untypable glyphs in particular) Kev would have thought "" would be better than "∞", but so would be anything one can type. Georg thinks a distinct "unlimited" value is needed, while "" may not be - Kev doesn't think it is unlimited, rather the largest server-allowed value. Georg suggests the value could simply be "-"; Kev thinks "", "-", "unlimited", or "max" are all better options than "∞"; Dave could go along with "", which 'probably' works on servers now (if they don't mandate an integer value.) Jonas thinks servers could default to "1" for "" and so wouldn't trust it; Georg adds that it would be ambiguous and could be taken as 'unset'. Kev thinks "max" sounds good. Link says the value must be something current servers won't understand, otherwise there could be implementation dependencies. The author requests a clear direction on how to fix the PR - Jonas clarifies that some text value should be used in place of "∞", and make clear what value that represents. Georg adds that it would be nice to have an explanation of the semantics of the value when sent by the client versus by the server. Dave thinks a feature will be needed if it's something servers won't otherwise understand. 4) Outstanding Votes Georg notes that two expire today - Dave intends to do his after the meeting. 5) Next Meeting 2019-10-16 1500 UTC 6) AOB Georg wishes to thrash out CS-2020, see PR #841 [1] for details. Georg has added new text to the introduction, some more XEPs, and the "Future Work" section; asks for more XEPs to be added. Jonas had already sent some feedback [2], which still seems valid - Georg would like comments on Jonas's proposed XEP additions. Dave thinks everything in #841 looks good. Link was unaware of this until now, but thinks it looks nice. Georg is pushing to get this XEP to Draft before the end of this Council session, so feedback closes on November 5th. Georg feels inclined to add XEP-0379 (Pre-Authenticated Roster Subscription) to "Advanced Mobile." Dave agrees with Evgeny's comments on ditching BOSH (XEP-0206) - Georg notes his reply to this [3]. Kev would keep BOSH, but note that WebSockets is a better option. Link thinks deprecating BOSH might be a plan, but it seems to still be supported by servers, so should still be included. Dave asks whether BOSH could be deprecated for clients, but not servers - Georg says this was what Jonas suggested; Jonas actually said that clients could pick one, which isn't deprecating BOSH, but then its use might be phased out. Dave asks everyone to keep an eye on Georg's work on CS-2020 and Council revisit this every meeting until it's ready. Georg says the Last Call needs to happen two weeks before the final vote, which means it has to be next week. Georg would like to use the LC phase to sort out the "Future Development" section. Jonas calls upon Council to make this work, i.e. vote quickly to let it enter LC. Link will propose any changes he has before next week. Jonas is +1 on the LC after #841 has been included, and his feedback should be considered LC feedback. 7) Close Thanks everyone. [1] https://github.com/xsf/xeps/pull/841 [2] https://mail.jabber.org/pipermail/standards/2019-October/036515.html [3] https://mail.jabber.org/pipermail/standards/2019-October/036517.html
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
