[Standards] Council Minutes 2019-06-05

Tedd Sterr teddsterr at outlook.com
Wed Jun 12 14:24:34 UTC 2019


http://logs.xmpp.org/council/2019-06-05?p=h#2019-06-05-6a6f6e1be3ab8a62

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

2) Agenda Bashing
Dave saw nothing for the agenda, but notes Georg wanted to say some things in AOB; nobody else has anything.

3) No Items For A Vote

4) Outstanding Votes
Link Mauve is outstanding, and also has a remaining vote expiring today.

Link votes on PR #690: +1 (own PR; obviously)

5) Next Meeting
2019-06-12 1500 UTC

Georg will probably be absent for the next two weeks.

6a) AOB i
Georg has an issue with the handling of ephemeral messages for offline users: the latest version of ejabberd only accepts messages to offline users if they will be stored in offline storage/MAM, and rejects otherwise - leading to multiple errors when sending CSNs to an offline contact.
Jonas thinks this behaviour is sane - the sending entity needs to deal with errors to ephemeral messages.
Georg says Holger said this is strictly following the RFC and XEP-0160, but Georg doesn't think it's helpful to bounce ephemeral messages because then each of your clients needs to track all in-flight messages.
Jonas says this is a case where including the original payload would be valuable as it saves on tracking - Georg says ejabberd does this.
Georg would rather change XEP-0160 to allow silently dropping ephemeral messages because there is no benefit to responding with errors - Dave would agree for some messages (CSN), but not necessarily others (receipts); Kev says receipts aren't ephemeral.
Jonas thinks OTR should be treated as ephemeral, and dropping those wouldn't be so great - Georg asks whether that would be worse than delivering OTR messages to another client - Jonas says they would not be re-routed under IM-NG.
Georg would even argue that message errors shouldn't be ephemeral if they are a bounce of a non-ephemeral message - Jonas says this would require the original payload in the error, which would also help with bouncing of ephemeral messages as clients could recognize that the errors belong to ephemeral messages.
Jonas says OTR messages should be rejected, rather than being dropped or rerouted; so maybe XEP-0160 should be amended to require the bouncer to include the original payload, giving clients the ability to treat bounces of ephemeral messages as such, without needing to track them.
Dave asks whether Georg has enough material to start an argument on the Standards mailing list - Georg thinks so, but lacks the time to actually write it down.

6b) AOB ii
Dave suggests: given the quiet period, is it worth us looking for any XEPs worth advancing?
Georg and Jonas think it's a good idea; Georg proposes XEP-0280 (Message Carbons).
Dave asks that each Council member find an XEP to advance (even if everyone picks the same), as it might be nice to advance some stuff.
Kev would prefer to have a few weeks with a lighter workload.

6c) AOB iii
Dave notes that MLS (Message Layer Encryption, basically an IETF spec for E2EE) has reached a stable point in its development and looks very promising; doesn't think there's anything needed at this stage, but might look at an MLS/XMPP XEP if he can find the time.
Kev requests a summary of its properties - Dave obliges: a ratchet-based solution built around groups, not 1:1; Post-Compromise, rather than PFS, since it ratchets on demand and on group membership changes, not on every message; standardized encrypted form syntax and concepts; downside is that it blocks server-side archiving as usual.

6d) AOB iv
Georg wonders whether gremlins are meddling with interactions between 0198 (Stream Management) and 0357 (Push Notifications): should there be a Push notification if there are un-acked stanzas when a session gets hibernated?
Dave thinks so, as a 'maybe live' SM disconnected session won't get pushes until after some timeout. Jonas thinks it sounds like a good thing, but isn't a mobile person.

Dave says this sounds reasonable, and is interested, but would like to end the meeting on time.

7) Close
Thanks all.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20190612/c083ebb1/attachment.html>


More information about the Standards mailing list