[Standards] Council Minutes 2020-05-06

Daniel Gultsch daniel at gultsch.de
Tue May 19 17:19:12 UTC 2020

Am Di., 12. Mai 2020 um 19:04 Uhr schrieb Tedd Sterr <teddsterr at outlook.com>:
> https://logs.xmpp.org/council/2020-05-06?p=h#2020-05-06-203d250e68ba702f
> 1) Roll Call
> Present: Jonas, Zash, Daniel, Georg
> Apologies: Dave
> 2) Agenda Bashing
> Nothing to add/modify.
> 3) Editor's Update
> * Expired calls:
>   - LC for XEP-0280 expired without feedback.
> * Calls in progress:
>   - LC for XEP-0320 (ends at 2020-05-19)
>   - LC for XEP-0339 (ends at 2020-05-19)
> * ProtoXEPs:
>   - Channel Binding Pseudomechanisms
> 4a) Advance XEP-0280 (Message Carbons) - https://xmpp.org/extensions/xep-0280.html
> Georg is torn - likes most of the XEP, except for the line "contains payload elements typically used in IM" - would rather roll back Carbons and fix message routing than entrench 'the mess' (but doesn't expect that to happen). Zash thinks it's already entrenched, but XEP-0409 (IM Routing-NG) can obsolete Carbons once it's ready.
> Daniel used to think similar to Georg, but came to the conclusion that IM-NG won't be easy and will share many of the same problems as Carbons - Jonas thinks having clear semantics is at least a good start. Georg hopes some work can be invested into Carbons to make IM-NG profit from those rules later - Daniel doesn't expect such rules to ever be defined. Georg suggests checking whether the rules in section 6.1 are adequate for Daniel's use cases - Daniel asks whether it covers Jingle messages - Georg expects Jingle may be one of the many XEPs that don't define an appropriate message type.
> Zash currently has an implementation which varies slightly from the rules in the XEP - time and deployment experience will tell whether it's better. Georg thinks that sounds like it would be worth postponing Carbons' advancement.
> Georg wants Carbons and MAM sync to become type 'headline' - Daniel says that Conversations makes them type 'chat' to get around 6.1's rules - Georg suggests fixing the rules instead - Daniel doesn't like the idea of fixing Carbons (and implementations) every time a new XEP appears. Georg concludes that Carbons has no meaning outside of IM, and Jingle is kinda-sorta-possibly-maybe-probably-approximately-IM now. Zash notes that his new mod_carbons acts on anything which has been archived.
> Jonas floats the idea of a Routing-WG, in the same vein as the E2EE-WG - Zash and Georg think that would be good. Zash also wonders if there is a Jingle-WG to comment on the batch of Jingle XEPs. Jonas thinks those with a vested interest could sit down for a sprint and work out rules for the different use cases, also driving IM-NG forward; Georg expects most of the rules will apply equally to IM-NG, Carbons, and MAM. Jonas looks for volunteers to organise the sprint and get people on-board; eventually concedes to doing it himself.
> Jonas: -1
> Daniel: -1
> Zash: -1
> Georg: [pending]
> Dave: [on-list] (need to look at what was discussed at the Summit)
> 4b) Last Call: XEP-0393 (Message Styling) - https://xmpp.org/extensions/xep-0393.html
> Jonas: +1
> Daniel: +1
> Zash: +1
> Georg: +1
> Dave: +1
> 4c) Proposed XMPP Extension: Channel Binding Pseudomechanisms - https://xmpp.org/extensions/inbox/cb-pseudomechanisms.html
> Jonas is fairly certain this needs to be addressed at the IETF level - the author, Sam, points out it will never really be addressed there, as it's protocol specific and the XMPP-WG is shut down - Jonas concurs, but is still not sure that mangling the mechanism names is a great way to do this. Zash approves of the overall goal; Daniel feels the approach is wrong, and fantasizes about a world where namespaced attributes are a thing.
> Jonas: [on-list]
> Georg: [on-list]
> Zash: [on-list]
> Daniel: [on-list]
> Dave: [on-list] (need to think, but would be a firm +1 if it weren't using pseudo-mechanisms)


I would prefer that we use explicit childs of mechanisms with a
different namespace to announce what channel binding methods are
available. (Basically what Florian suggested in the other thread)
But the future is important enough to bring it to the XSF.


More information about the Standards mailing list