1) Roll Call
Present: Link, Jonas, Georg, Dave, Kev
2) Agenda Bashing
PR #840 is noted.
3a) Proposed XMPP Extension: Message Retraction -
Dave: +1 (willing to be told I'm wrong later)
3b) PR #840 - XEP-0060: Clarify unlimited behaviour for node config -
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
Dave: -1 (having "-1" or empty seems sane for unlimited, but not novel unicode
Georg: -1 (agree with Dave; also don't understand the implied semantics of that
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
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
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
Georg wishes to thrash out CS-2020, see PR #841  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 , 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
Dave agrees with Evgeny's comments on ditching BOSH (XEP-0206) - Georg notes
his reply to this . 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
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.
Standards mailing list