> 3) Last Call: XEP-0353 (Jingle Message Initiation) -
https://xmpp.org/extensions/xep-0353.html
> Link: +1
> Jonas: +1
> Georg: +1
> Kev: [pending]
> Dave: +1
Actually, I'd suggest postponing 0353 just a bit. In its current form 0353
turned out to be absolutely not capable to work with clients
http://logs.xmpp.org/council/2019-06-26?p=h#2019-06-26-7db9d98e5e42b5e7
1) Roll call
Present: Jonas, Link, Kev, Georg
AWOL: Dave
2) Proposed XMPP Extension: Stanza Content Encryption -
https://xmpp.org/extensions/inbox/xep-sce.html
Kev: [on-list]
Jonas: +1
Link: [on-list]
Georg: +1
Dave: +1
3)
I agree. The empty transport elements is one of the approaches. I thought
about it. But then I thought "if every transport may declare it's own set
of obligatory transport attributes then why should I parse transport
elements at all figuring out whichi attributes are required and which not
if it
Am 22.06.19 um 17:18 schrieb Sergey Ilinykh:
In response to Council Minutes 2019-06-19
quote from
https://wiki.xmpp.org/web/XEP-Remarks/XEP-0260:_Jingle_SOCKS5_Bytestreams_Transport_Method
Another problem with early (before accept) transport replace is the fact we
have to send the same offer
I was summoned... :-)
Am 29.04.19 um 12:02 schrieb Sergey Ilinykh:
Hi
There is a problem with jingle-s5b in the way how it handles additional
candidates sent with transport-info message.
Let's imagine a situation. We have an accepted session. Both sides sent
their host candidates in
* Tedd Sterr [2019-06-24 00:47]:
> Last Call: XEP-0300 (Use of Cryptographic Hash Functions in XMPP) -
> https://xmpp.org/extensions/xep-0300.html
> Dave: +1
> Georg: [pending]
> Jonas: +1
> Kev: [pending]
> Link: +1
+1 to LastCall it. I think that "Table 1: Additional Hash Function
Textual
