http://logs.xmpp.org/council/2020-01-02?p=h#2020-01-02-a37a199502a4581c
1) Roll call Present: Zash, Daniel, Jonas, Dave Apologies: Georg 2) Agenda Bashing Jonas notes three proto-XEPs, and Dave's proposal to get rid of XEP-0384 - would prefer to move the latter to next week due to short notice and controversy; Dave would like to at least discuss it. 3a) Proposed XMPP Extension: MAM Fastening Collation - https://xmpp.org/extensions/inbox/mamfc.html Daniel: [on-list] Jonas: [on-list] Zash: [on-list] Dave: +1 Georg: [pending] 3b) Proposed XMPP Extension: User-defined Data Transfer - https://xmpp.org/extensions/inbox/udt.html Jonas thinks valid points were made on-list about the API description in a Standards Track XEP. Daniel tries not to -1 XEPs, but is unsure this 'fills a gap.' Jonas queries the author (Dave) on mingling API and protocol in the document - Dave is confident it's useful, but only with buy-in from library developers. Daniel thinks it's unnecessary as, with buy-in from library developers, development will then be super easy. Zash thinks mandating an API is a bit weird, but maybe a strongly worded implementation note is fine. Dave is expecting at least one high-profile use-case to be dropped due to the lack of a simple JSON blob exchange mechanism. Jonas queries Dave on splitting off the API description into an Informational document - Dave would be okay with dropping it entirely and just having an implementation note on terminology; it doesn't need an API, so much as consistent terminology. Daniel has seen people cram things into the body, but that's better solved by improving communication on what XMPP is - Pep agrees on pushing for documentation. Jonas liked Dave's point about the target audience not being the ones reading the specifications. Dave would feel happier if there were a technical approach for when people feel the need to stuff content into the body; and it's only library authors who are reading XEPs. Jonas notes that XEP-0335 (JSON Containers) already exists, but libraries typically don't have an API for throwing JSON into a message; and this extension adding the type field is a nice touch essential for interoperation. Daniel requests removal of the IQ part - Dave is okay with this, but assumes people will still try to write a REST-like interface inside messages, but that's less awful than what they're currently doing. Jonas: -0 (in its current state; +1 with removal of IQ usecase and change wording around the API) Daniel: -0 (don't want to block) Zash: +1 Dave: +1 (with Jonas's changes) Georg: [pending] 3c) Proposed XMPP Extension: Fallback Indication - https://xmpp.org/extensions/inbox/fallback.html Daniel: [on-list] Jonas: [on-list] (can't form an ad hoc opinion about this versus hints) Dave: +0 (think it's better as a hint, but should revisit why that was rejected) Zash: [on-list] Georg: [pending] Dave notes that Hints wasn't actually rejected, but it moved back to Experimental, Sam rejected no-copy, and there was some discussion about fixes. 3d) Most Likely Not For A Vote: Reject XEP-0384 OMEMO (in whatever way) Dave has been told by different people that OMEMO both can and cannot be implemented without libsignal. Jonas thinks Dave's argument is sound - only knows of implementations which either use libsignal or are GPL through fear of repercussions. Daniel agrees on the basis that it is actually a bad standard, but wonders whether there should be communication to explain what this would and wouldn't mean - Jonas suggests Daniel might take this on, given his perceived E2EE advocacy. Dave notes that it should be Deferred regardless, which will cause confusion, but this doesn't mean people can't implement or use it. Zash isn't fond of some parts of the XEP, e.g. the PIP bits are weird. Dave says that both Sam and Larma insist it's possible to implement without using libsignal, but that libsignal's author doesn't think it's allowed. Jonas mentions that Syndace did successfully implement it without directly depending on libsignal, but the wire format plugin is still under GPL. Jonas thinks this is all a grey area and not likely winnable in court. 4) Date of next 2020-01-08 1600 UTC 5) AOB Jonas forbids anything but quick announcements - nobody has anything. 6) Close Thanks all Dave will try to have an Inbox specification submitted by the end of tomorrow.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
