1) Roll Call
Present: Link, Jonas, Georg, Dave, Kev

2) Agenda Bashing
PR #840 is noted.

3a) Proposed XMPP Extension: Message Retraction -
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 -
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

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 
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.


Standards mailing list

Reply via email to